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?
We don't need all these APIs. Just disable everything by default and provide just static web pages for 99% of web browsing and provide opt in explicit consent for the small amount of use case that actually need scripting. I'm tempted to fork the web and provide a modern equivalent of gopher.
Waterfox and Pale Moon, if your listening, disable your APIs by default and get away from Mo$illa Spyfox.
Why not default to "ask" like all the others? They just did that with canvas too, as annoying as it is, at least be consistent. Provide a single toggle "Prompt when site tries to use privacy-risky apis?" so someone can make that choice if they want. This isn't rocket science.
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.
this seems like it should have been caught on the way in due to better general abstract policy. Maybe their advertiser partners objected.
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).
Use a very scaled down VM and run your browser in it. Most of the invasiveness issues go away. Reset the VM daily.
this is bullshit,
more features for fingerprinting, and tracking you.
why was this even coded and added to begin with?
this shit will just get turned on at a later date again, i'm sure of it.
"Dinner and a movie" is traditional before that level of commitment.
Inheritance is the sincerest form of nepotism.
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?
As a matter of fact, I see absolutely no reason why we should be trusting web sites to run scripts at all.
You can't trust the internet. You sure as hell shouldn't be trusting every random website to be allowed to run code.
I don't trust the average web page at all, and especially not all of the 3rd party parasites all over the place.
That the default behaviour of every browser is to say "oh, sure, you and all of your friends can execute scripts, why not?" is pathetic, and likely is a huge source of malware.
Who gives a fuck?
Between ads, analytics, malware, cypto-mining bullshit ... trusting most sites, especially the 3rd party crap, to run scripts is a terrible idea.
We really need to put more security back into the web browser, instead of "just enable everything by default".
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
This feels the same as saying "the girls' locker room got a privacy boost because we nailed a board over the peep hole."
Mozilla creates the problem, then wants applause for fixing it. Still not dead yet?
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 ]
Privacy is dead to them, I don't see how they get to bring it up.
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
Last I heard, it was best practice to ignore the existence of the <noscript> tag ...
What? When was it that ignoring the existence of the tage is the best practice???
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?
Rip out everything that doesn't deal with BROWSING, idiots.
Load a website and show it to me. Can you do that, or do you need to see the light temperature of my fucking room?
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 ]