1436874 - Restrict device motion and orientation events to secure contexts

Status: RESOLVED INACTIVE

(Firefox for Android Graveyard :: General, defect, P3)

Description

[gunesacar]

Attachment: sensor_test.html

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180131005501

Steps to reproduce:

Visit an HTTP page that access sensor APIs, motion, orientation, light and proximity:
http://homes.esat.kuleuven.be/~gacar/dev/test/sensor/


Actual results:

The scripts on the insecure context could access sensor data.


Expected results:

W3C spec says [0] the sensor data should only be available on insecure contexts. 

[0]: https://w3c.github.io/sensors/#secure-context

Comment 1

[gunesacar]

MDN page titled "Features restricted to secure contexts"[0] mentions Generic sensor API as one of the "Future features that will be available only in secure contexts". This is a bit confusing since Firefox for Android already supports motion, orientation, light and proximity sensor APIs.

[0]: https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts

PS: My collaborators and I noticed this issue during our research on sensor API usage. I'm reporting on behalf of them as well.

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

This probably needs a general decision from Product/DOM?

Comment 3

[Andrew Overholt [:overholt]]

jkt has been coordinating a bunch of this work.

Comment 4

[Jonathan Kingston [:jkt] he/him]

- devicelight, deviceproximity and userproximity events. I plan to remove this in 60 for all connections: https://bugzilla.mozilla.org/show_bug.cgi?id=1359076
- Device motion and orientation - We support and outside the scope of Bug 1359076 I think we should do this however there isn't telemetry
- Battery isn't supported

Did I miss any?

> mentions Generic sensor API as one of the "Future features that will be available only in secure contexts"

We actually don't support these at all yet, I think only Chrome supports them behind a flag. The generic sensor APIs aren't event based.

Comment 5

[gunesacar]

> - devicelight, deviceproximity and userproximity events. I plan to remove this in 60 for all connections: https://bugzilla.mozilla.org/show_bug.cgi?id=1359076

That's great!

> - Device motion and orientation - We support and outside the scope of Bug 1359076 I think we should do this however there isn't telemetry

Do you need a specific measurement, like usage on secure vs. insecure origins? We have a paper in submission where we measured the use of device motion, orientation, light and proximity on homepages of Alexa top 100K websites. Happy to share the pre-print if it helps. We plan to make it public soon anyway.

We didn't specifically measure the HTTP vs HTTPS usage, but should be possible to add this and other measurements you may need.

Also, data from Chrome Status:
- https://www.chromestatus.com/metrics/feature/timeline/popularity/668
- https://www.chromestatus.com/metrics/feature/timeline/popularity/670

Comment 6

[Jonathan Kingston [:jkt] he/him]

> Do you need a specific measurement, like usage on secure vs. insecure origins?

We would need % of pageloads mostly, I can add a deprecation notice into Firefox and we would get the numbers we need.

> Happy to share the pre-print if it helps.

I'm interested in this paper, in this case I don't know if this will help establish if we can deprecate though.

Chrome's measurements of insecure suggests we can't remove directly however if I remember correctly their implementation has differences so we will need our own numbers anyway.

Comment 7

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

[triage] Jonathan, iiuc, these events are being removed in the ~60 timeframe, or are not yet implemented, and so can this be duped to one of those bugs?

Comment 8

[Jonathan Kingston [:jkt] he/him]

I renamed this bug to cover the cases that won't be covered by Bug 1359076 which is tracking 60 (but might not make it). I think this is fine to keep open unless there are other bugs?

Comment 9

[gunesacar]

> I'm interested in this paper, in this case I don't know if this will help establish if we can deprecate though.

Will share the paper once we finish doing some edits.

When making decisions as to what to deprecate (or limit the access to secure origins, for instance) do you take into account how the API is being used: i.e. tracking, advertising related uses vs. "functional" uses? IIRC this was taken into account when removing the Battery Status API.

For instance, according to our preliminary results, devicemotion event is used on 10% of the 100K sites that we crawled. But 97% of the accesses was due to advertisement or tracking related scripts*.

*: As determined by EasyList or EasyPrivacy lists, which are likely to have some false negatives.

Comment 10

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Daniel, how might you prioritize this from a security/privacy perspective? I'm having trouble wrapping my head around the user implications here. I'm wondering if I should triage this as critical and get some resources in the near future to work on it or if it can wait.

Comment 11

[Daniel Veditz [:dveditz]]

(In reply to Michael Comella (:mcomella) [needinfo or I won't see it] from comment #10)
> Daniel, how might you prioritize this from a security/privacy perspective?

Restricting it to secure contexts is probably only moderate, definitely not "critical".

> I'm having trouble wrapping my head around the user implications here.

It reveals personal information, and by being available on insecure sites it can be injected by MITM. As we move toward an "always https" internet in the future we still have the privacy implication of every site being able to silently gather this information (see comment 9). For me personally I'd rather put work into gating sensor APIs on a user permission grant. There are extremely few sites putting these to good use, and for those it would be easy to get a user to opt-in to the experience.

Comment 12

[Jonathan Kingston [:jkt] he/him]

For further discussion on this there was also a recent dev platform thread: https://groups.google.com/forum/#!msg/mozilla.dev.platform/oMUvorKmYYc/DLw8JBHMCwAJ

> For me personally I'd rather put work into gating sensor APIs on a user permission grant.

Restricting APIs to secure only is covered under the HTTPS Everything project. I'm tracking this there however I agree our job isn't complete once this is restricted to Secure Context.

As this is unsupported in other browsers I think we are safe to restrict, gating with a prompt might break things and is more work.

Comment 13

[Firefox Bug Husbandry Bot]

Closing per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Contact :susheel if you think this bug should be re-opened