Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

About securing sensors data #71

Open
vgalindo opened this issue Nov 6, 2015 · 3 comments
Open

About securing sensors data #71

vgalindo opened this issue Nov 6, 2015 · 3 comments

Comments

@vgalindo
Copy link

vgalindo commented Nov 6, 2015

During the TPAC sensor session [1], the question of making sure that the sensor API allows to transfer some sensor's data which are protected from reading. The use case is : a sensor is protecting itself from reading its measures (aka, only communicating ciphered data), and transfer its data to a server which will have means to read the ciphered data. In that case, the web app handling the data may have some interest to know that sensor's data van not be interpreted without special treatment.
The API should allow to tag this kind of protected data, to avoid wrong data interpretation.

[1] http://www.w3.org/2015/10/28-dap-minutes.html

@tobie
Copy link
Member

tobie commented Nov 10, 2015

So as discussed F2F, the current design allows for this. For example, you could add a boolean encrypted member to the constructor's dictionary or pass the recipient's public key via the same mean. The sensor would then emit OpaqueSensorReading objects instead of regular ones, and the recipient only would be able to decrypt the data, the application then simply becoming a pipe for it.

So for example:

var sensor = new HeartbeatSensor({ key: CARDIOLOGIST_PUBLIC_KEY });
var buffer = [];
sensor.ondata = (e) => {
    buffer.push(e.reading);
    if (buffer.length > 15) {
        fetch(CARDIOLOGIST_URL, { body: JSON.stringify(buffer) });
        buffer.length = 0;
    }
}

Now, I don't know what interest there is for something like this at this point, so it seems very early to bake it into this spec. Have you heard from implementors interested in enabling this use case?

@vgalindo
Copy link
Author

@tobie, sounds like a good start. let me check this with my tech team and marleting team, and come back to you with implementation / use cases.

@tobie
Copy link
Member

tobie commented Nov 18, 2015

Note the key would obviously need to be provided through UA chrome during the permission step.

@tobie tobie added this to the Level 2 milestone Jan 6, 2016
@tobie tobie modified the milestones: Level 2, Future Work May 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants