Firefox Gets Privacy Boost By Disabling Proximity and Ambient Light Sensor APIs (bleepingcomputer.com)

Stating with Firefox 60 -- expected to be released in May 2018 -- websites won't be able to use Firefox to access data from sensors that provide proximity distances and ambient light information. From a report: Firefox was allowing websites to access this data via the W3C Proximity and Ambient Light APIs. But at the start of the month, Mozilla engineers decided to disable access to these two APIs by default. The APIs won't be removed, but their status is now controlled by two Firefox flags that will ship disabled by default. This means users will have to manually enable the two flags before any website can use Firefox to extract proximity and ambient light data from the device's underlying sensors. The two flags will be available in Firefox's about:config settings page. The screenshot below shows the latest Firefox Nightly version, where the two flags are now disabled, while other sensor APIs are enabled.

Comments

What are these API for?

[Chatterton]

Why does these API have been created for? I don't really se a use case for them :( What other API are being put in without any really interesting use-case?

Why was this even possible?

[Anonymous Coward]

Why the hell would there even be APIs to allow websites to interrogate information about your machine?

The answer to any website asking for anything more than the user agent should be no, sorry, fuck off.

I can't imagine why any of this information should ever be given to a damned website.

Proximity? To what? Fingers to keyboard?

[jabberw0k]

Why would anyone even want a device that has invasive sensors in it?

Re:Stop putting the operating system in the browse

[fibonacci8]

"Dinner and a movie" is traditional before that level of commitment.

Re:Stop putting the operating system in the browse

[FatdogHaiku]

So you would prefer a policy such that newly encountered domains default to script off. Under this policy, how would a web application that falls into "the small amount of use case that actually need scripting" demonstrate to the user that it is worthy of "opt in explicit consent"?

Isn't that exactly what the noscript HTML tag is for?
You hit a page that thinks it needs scripting and you get a message asking you to enable it... maybe showing a GIF promising all kinds of wonderful things the site can do for you..

Proximity: Wrong scale

[DrYak]

you've got the wrong scale regarding proximity. it's not about the number of meters from the device to the user.
it's more "is there something pressed against the screen ?" (like the user's cheek and ear in case of a smartphone).
That's the thing that turn off the screen and (even more important) the touch screen while you're talking into the phone (that is : with the whole smartphone's body against your head. Not using earphones / bluetooth).

Web apps are a thing, and in some case, such as Skype, the web app (http://web.skype.com in this case) *is* the app. The new "native" Linux client is basically the web app, but packaged together with chrome, thanks to Electron framework. (and initially, wrapped together with the necessary plug-in to enable voice-chat, back when it used microsoft-edge-only api instead of webrtc. things have moved since and call work in bare firefox without any plugin and only webrtc).

(I haven't bothered to check, but I strongly suspect that the android app also shares code heavily this web app)

By providing an API to light and proximity sensors, it gives the web app a (web-)standard way to be able to behave like a normal phone app during calls and have the screen shut down so your cheek won't accidentally click on stuff.
Thus SkypeWeb opened in Firefox will act the same as the regular app, and all of them could potentially use the exact same API (instead of the Android App, iOS App, Windows APP all using their system's specific sensors API and Firefox not even being able to).

Same way of thinking could be applied to any other on-line voice calling platform's web app, or even "native" for the cases where "native" is just a wrapped up web app.

The problem, is that some rogue script on some mailicious website/ad could abuse it: e.g only do nefarious things such as mining cpu-cryptocoin only when the user isn't looking.
So these API will go the same way as all other sensitive API such as Location/GPS API : diabled by default, let user only enabled them on the sites where it's genuinely needs (Location: e.g. on google maps).