Slashdot Mirror
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.
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 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.
Why would anyone even want a device that has invasive sensors in it?
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"?
In a WebRTC voice and video chat application running in a web browser on a smartphone, proximity of the user's smartphone to the ear could be used to automatically switch between speakerphone mode (with half duplex, higher volume, and optional video) and non-speakerphone mode (with lower volume, full duplex, and no video).
"Dinner and a movie" is traditional before that level of commitment.
Inheritance is the sincerest form of nepotism.
My first guess is that it was coded for the dialer of Firefox OS, a phone operating system in which all applications including the dialer are web applications. The dialer needs to make certain decisions based on proximity of the phone to the user's ear. Even outside Firefox OS, so does any voice chat application.
Thank you Mozilla. Firefox and Safari are the browsers who look like they care about privacy, and they're currently my choices.
8 of 13 people found this answer helpful. Did you?
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"?
Who gives a fuck?
People who use operating systems other than the majority desktop operating system, for one. If most web browsers did not run script, developers of web applications would instead develop native applications, which are specific to a single operating system and instruction set architecture. What good is a Linux (x86-64) executable on a Linux (ARM) device? What good is a native executable for macOS on anything but a Mac? What good is even the source code for a Cocoa application on anything but a Mac?
At least with the web platform, one application can use a useful subset of the HTML5 standard to reach users across Windows desktop, Windows UWP, macOS, X11/Linux, iOS, and Android, without needing to recompile the application for multiple platforms and buy a separate software publisher certificate for each platform.
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..
You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
Isn't that exactly what the noscript HTML tag is for?
No, because a user agent that supports script but fails to fetch a particular script will neither run the script nor show the contents of the <noscript> element. Last I heard, it was best practice to ignore the existence of the <noscript> tag, instead including the no-script content in the main document and having script slap a class onto the <html> element once the script actually loads, so that CSS code in the stylesheet hides the script.
But in any case: What contents should a web application put into its elements shown when the script does not run in order to demonstrate to the user that it is worthy of "opt in explicit consent"?
maybe showing a GIF promising all kinds of wonderful things the site can do for you..
What makes a reasonable user willing to trust the information presented in said GIF?
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).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Voice calls are typically an exemple where the proximity sensors is used to shut down the screen and touch sensors.
(e.g.: If the proximity sensors senses that the whole face is against the screen, because the user is holding the phone against the ear instead of using earphones / bluetooth, then this is necessary to avoid the users' cheek clicking on random stuff on the screen).
Skype has a fully functionnal web app (web.skype.com) and on Linux, the new "native" app is basically just the web app wrapped together with a chrome browser.
Such an app would be a prime candidate for using such API.
Now a single web standard can be used whenever the user hold a smartphone to make a call, instead of each wrapped web app requiring special plugins calling into whatever that peculiar platform uses. (be it web.app in Firefox on your smartphone, web.app wrapped in a browser on your ubuntu touch phone, perhaps even web.app wrapped in an android app)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The phone's own dialer doesn't even do that.
What ?
it's a standard feature on the phone's cell voice calling on nearly any smartphone I've had.
Put the smartphone against your ear: the screen shuts down, so your cheek won't accidentally click on stuff
Put the smartphone down: the screen light ups showing you a numpad (e.g.: so you can click on a number pad for number-driven menus a.k.a. "Press 1 if you are calling regarding ###") and/or an optional toggle to increase volume.
This is just providing a web standard, so a a webapp like SkypeWeb can mimmick the same behaviour.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
you have add-on for that, install no-script and you get the 99% static page without any api (as all APIs are javascript based)
Higuita
He's talking about web browsers. You're talking about some kind of web application loader/RTS. Oh shit -- they're the same thing! No wonder we're so fucked.
"Believe me!" -- Donald Trump
I hope they have something up the pipeline.
When was it that ignoring the existence of the [<noscript> tag] is the best practice???
Since "progressive enhancement". See "Shouldn't we use <noscript> element?" by Jitendra Vyas et al.
For reaching users on Windows desktop, Windows UWP, X11/Linux, Android, macOS, and iOS, which "web application loader/RTS" is superior to the HTTPS + HTML + CSS + JavaScript stack in your opinion?
Read what I replied to more closely:
automatically switch between speakerphone mode (with half duplex, higher volume, and optional video) and non-speakerphone mode
The screen turning on is not speakerphone mode.
For the specific trick of automatically boosting the volume whenever the phone is away from the users' face, though it's not a default option on most android phones, I'm sure you'll find apps on the Play Store and a dozen of users' patchs on more hacker community oriented OSes (HP/Palm webOS, Jolla's Sailfish, etc.)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
You'd still need to find a way to persuade the victim to also enable cam access to that rogue malicious script, but yes,
that would be a typical way to abuse such modern web API, to almost-litteraly get a finger print, which can be monetized by tracking by ad provider.
A malicious chat app (like the scam clones of WhatsApp) would actually manage to have a valid reason to ask for proximity and camera.
The big pro, is that usually the selfie-cam is close to the ear speaker which in turn (for obvious reason) is close to the proximity sensors. So the ear will definitely be in-frame for the selfie cam.
The big con, is that the selfie cam isn't optimized to focus on extreme close ups. (The attacker would need to correctly time the moment the ear leaves the vicinity of the proximity sensor, with the best moment to take a sharp-enough picture of the retreating ear. e.g.: after the sensors notice ear departure, wait 500ms and take the picutre then, it's should be in the best focus range).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]