Possibility of cross-domain communication using frequency in periodic reporting mode

[lknik]

In the periodic reporting mode, the readout frequency of a sensor can be adjusted. If there already exists an instance that is already polling at some frequency f, all new instances will be polling at the same frequency f. The details are at https://w3c.github.io/sensors/#observe-a-sensor

This means that two instances in different browsing contexts (even different tabs) might receive a way of communicating across domains, by their hopping frequencies in a coordinated manner, and e.g. exchange identifiers. However, as per discussion with Tobie Langel (thanks!), the frequency polling is actually attributed uniquely to a physical sensor. If this is so, it would in theory even be possible to exchange messages (e.g. identifiers) across two different browsers (e.g. Firefox and Chrome).

[rwaldron]

. If there already exists an instance that is already polling at some frequency f, all new instances will be polling at the same frequency f

Can you explicitly cite where in the spec this behavior is defined. If a sensor has a max frequency of 100Hz, or 10ms per measurement, and two browsing contexts have created sensor instance objects that both request the max frequency, how should a spec define mitigation for something that is outside of the browser's control to begin with? Does getUserMedia have to deliver video frames at different frame rates if two contexts have requested the user's video camera?

might receive a way of communicating across domains, by their hopping frequencies in a coordinated manner, and e.g. exchange identifiers.

Can you give a concrete example?

. If this is so, it would in theory even be possible to exchange messages (e.g. identifiers) across two different browsers (e.g. Firefox and Chrome).

Again, a concrete example?

[tobie]

If there already exists an instance that is already polling at some frequency f, all new instances will be polling at the same frequency f

That's a misunderstanding of what the spec says. The idea here is that everyone is listening to the same physical sensor and that this physical sensor is polled with the intent of fulfilling the highest frequency requirements.

Hence, if context A requires 100Hz, context B requires 200Hz, and context C requires 1.2KHz, and the hardware sensor can't handle more than 1KHz, then all three contexts will get 1KHz. Note there is no guarantee that this frequency will be maintained or even possible.

Now consider context C is no longer interested in getting sensor readings: A and B will get 200Hz.

I can imagine you can use sensor frequency to transfer data between origins or across browsers by doing the following:

Listener would set frequency to something low, say 50Hz. Emitter would use high and low frequency to transfer information (e.g. 800Hz for 1 and 200Hz for 0). You could even imagine the Listener peaking to 1KHz to ack Emitter's message.

Note that, unless I'm mistaken, the threat here is mostly limited to cross-browser tracking as I suspect there are much simpler solution to transfer information between collaborating parties with different origins from within the same browser.

[tobie]

Mitigating this issue is a matter of filtering the readings from lower frequency Sensor objects at the expense of increased latency and CPU usage.

Maybe the spec should be more explicit about this issue and carve the ability for a very privacy-aware browser to mitigate that threat at the expense of performance, but that would require first a clear understanding of the threat model.

Given this new info, @lknik, could you please reassess the threat and compare it to other threats in the platform to see if it is worth dealing with?

Also, this very threat exists already on both iOS and Android to communicate between apps. Are you aware of research there showing that it has been used for attacks or is considered a threat?

[lknik]

@tobie
Now consider context C is no longer interested in getting sensor readings: A and B will get 200Hz.

I can imagine you can use sensor frequency to transfer data between origins or across browsers by doing the following:

Listener would set frequency to something low, say 50Hz. Emitter would use high and low frequency to transfer information (e.g. 800Hz for 1 and 200Hz for 0). You could even imagine the Listener peaking to 1KHz to ack Emitter's message.

This is basically what I had in mind, that issue. Thanks. If there is even a potential possibility of this kind, we should address it in the considerations. I do not intend to hinder the work on the specification, in any way. What I am saying that if there is this possibility, we should include a remark in the considerations. I can definitely write one. I think there might be a note specifying what happens in the situation with A, B, C - just to clarify how it works. I suggest including the other remark to privacy considerations sections.

I agree this may mostly relate to low frequencies, but in general it is a good idea to write in a general form, for the general case of differentiation. And a very privacy-aware browser (think "tor mobile browser") might want to know about this.

In other words, I realize there are other techniques. What I am suggesting that we should just include it in the open - in the considerations section, especially since we are aware of such possibility.

[tobie]

Privacy considerations definitely needs more love. It's something I'm planning to tackle once I'm able to refocus on this work.

[lknik]

I agree and I will be happy to participate. Actually I will definitely do so once I recover from my current stuff. I work on Vibration now, ASL later, then generic and proximity.

[tobie]

ASL later, then generic and proximity.

Keep in mind that both AmbientLight and Proximity build on top of generic.

[lknik]

@tobie sure - and it is already included in proximity sensors spec. But in general, some of the problems are, well, general. I will be differentiating between 'proximity', 'asl', and 'generic'.

[lknik]

How about including, provisionally, something along these lines in the considerations for the moment?

"In some circumstances the ability to poll sensors data at specified frequencies may allow cross-browser communication in unexpected ways. Such possibility may arise if two instances are polling sensors at different frequencies and frequency hopping is used as a messaging channel"

[tobie]

Input from implementors (thanks @alexshalamov and @pozdnyakov) is that instances will throttle the frequency of events being emitted to the frequency requested by the developer, making this concern moot in the process. (Need to reword the spec accordingly.)