Security issues when used in combination with other APIs

[tobie]

For example:

• wake-lock and ALS,
• motion sensors and input fields,
• etc. …

[lknik]

This looks like sensor-specific bug, any reason to have it open in the Generic Sensor?

I listed some ALS-related things here.

[tobie]

This looks like sensor-specific bug, any reason to have it open in the Generic Sensor?

It's not. The idea that risk can increase because of a specific combination of APIs is generic.

[lknik]

Oh, rightly so. Sorry I am actually signalling the issue for a while now. Happy we're taking it here. So short thing: probably difficult to make an exhaustive list :)

[tobie]

We shouldn't be making that list (as it'll evolve over time). Just describing the threat.

[pozdnyakov]

wake-lock and ALS

this case is addressed in a dedicated ALS issue

motion sensors and input fields

this case is addressed with Loosing Focus mitigation strategy

This issue looks too generic to handle it: the list of possible combinations with other APIs is endless.
Let's close it and make separate issues for every new known case when sensors security risks increase because of simultaneous using of some other API.

[anssiko]

I agree. The known attack vectors have now been documented and mitigated, so I'd be fine closing this issue (this issue was opened as a response to my verbal feedback at the WG teleconference).

If we are made aware of new combinations of APIs that could be used for malicious purposes we should open a new topic-specific issue.

[lknik]

I would only add that it's difficult to comply such a list. Maybe include something "general" in the generic sensors API text?

Would it make sense to include a "data exfiltration" point there?

[anssiko]

@lknik, concrete suggestions welcome.

[lknik]

Something along these:

Data exfiltration and leaks across origins or devices can become a risk when devices could communicate via out-of-band channels, or a device would be able to emit a signal and subsequently detect it via a specific sensor

Note, there are a number of sensors that could come to mind here.

[anssiko]

I feel that is too generic to be useful for implementers. In my opinion, a better approach is to be specific, and define the concrete threats in concrete sensor specifications similarly to the Ambient Light Sensor: https://w3c.github.io/ambient-light/#security-and-privacy

I'd be inclined to close this issue with a note that we should document concrete attacks in applicable concrete specs.

[dontcallmedom]

I think that @lknik 's warning is probably worth putting in the generic sensor spec - after all, a key security challenge posed by sensors is that they expose a new communication channel not protected by the SOP, so calling that out both to implementors and concrete-sensor spec writers seem relevant.

[anssiko]

I feel we should make https://w3c.github.io/sensors/#security-and-privacy as concise and actionable as possible to make it useful for implementers. Said differently, I'd like to avoid turning that section into an elaborate and ambiguous kitchen sink of unknowns. The risk of SOP violations is indeed a key concrete thing to flag out there.

Re the proposed text. The S&P section contains the following text already:

A combination of selected sensors can potentially be used to form an out of band communication channel between devices.

Sensors can potentially be used in cross-device linking and tracking of a user.

There's redundancy with the proposed text, so it would need some rewording to better fit the overall flow.

The SOP violations should be caught latest in https://w3ctag.github.io/security-questionnaire/#sop-violations, but since authors should consider this up front adding some links to https://w3c.github.io/sensors/#security would be a good thing to make concrete spec authors aware of threats, mitigations they inherit from the Generic Sensor API, and mitigations they need to consider on a case by case basis.

[lknik]

Wouldn't it be actionable if you'd include that point and link to ALS spec as an "example"? ;) (but then it would end up in a cyclical reference;) )