Firefox Gets Privacy Boost By Disabling Proximity and Ambient Light Sensor APIs (bleepingcomputer.com) 79
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.
What are these API for? (Score:4, Insightful)
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?
Re: (Score:1)
I suppose you could adjust styling based on light and proximity. Bigger fonts at longer distances, different color / contrast based on lighting. Who would go to the trouble of actually implementing that I have no idea, so anyone that is using it is probably fingerprinting.
Proximity: Wrong scale (Score:5, Informative)
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).
Re: (Score:2)
"That's the thing that turn off the screen and (even more important) the touch screen while you're talking into the phone"
So that one can take a picture of the ear, a very distinctive mark that allows to identify the user among millions of people.
API abuse (Score:2)
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 c
Re: What are these API for? (Score:1)
Sounds great. Any actual real world uses or are these just more features dreamed up by "designers" that never get used by any majority of ppl and just contribute to feature bloat?
Voice calls (Score:2)
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 toget
Re: (Score:2)
Re: (Score:2)
That's what black electrical tape is for.
Re: (Score:2)
If you need black electrical for wanking and nose-picking, you're doing it wrong.
Re: (Score:2)
Black electrical tape, dammit.
Re: (Score:2)
Re: (Score:2)
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?
Support for irrelevant features by an irrelevant browser. Surprise surprise.
Re: (Score:2)
Re: (Score:2)
Actually this is a W3C API and chrome also support it... at least in mobile. In desktop i think they disabled it as there is usually no sensors... in firefox they are also enabled, but without sensors (almost everyone), the value is fixed
remember that many of this are there to test if it is useful and if sites start to use it for cool things... sadly several features are just abused by trackers and later disabled.
Re: (Score:2)
I can see a page switching between a night time and day time theme like the GPS in my car does for one thing. Is that worth the loss of privacy in a networked application, probably not but you asked for a use case so I gave you one.
Re: (Score:2)
"I can see a page switching between a night time and day time theme like the GPS in my car does for one thing."
OTOH a gizmo with a GPS, a calendar and a clock knows when it gets dark anywhere in the world and also when you enter a tunnel so an ambient light detector is somewhat superfluous.
Re: (Score:2)
Right but my desktop PC does not have GPS and neither does my laptop. The clock on either may or may not reflect the desired condition. In the interior of some office building if you are pulling an all nigher you might be under bright fluorescent light even if its 11pm where you are according to the clock and time zone data. A laptop might be in use in an dimmed air craft cabin or train car even in the middle of the day..
An ambient light sensor IS the right type of sensor for this consideration.
Re: (Score:2)
It may be a relic from FirefoxOS.
There is this idea that the browser is now an OS where all apps are essentially web pages. To make this work, apps need a way to access the hardware, just like executables can do in more traditional OSes.
Re: (Score:2)
Web based apps. Not traditional web apps that go over the network and talk to a webserver via AJAX and the like (though you can to retrieve data), but fully self-contained applications using HTML, CSS and Javascript.
I wouldn't be surprised if it was an Apple initiative - remember, Steve Jobs wanted people to code in HTML/CSS/JavaScript to write apps for
Re: (Score:1)
Re: (Score:2)
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"?
Re:Stop putting the operating system in the browse (Score:5, Funny)
Good luck running a Mac app on a non-Mac (Score:2)
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 wi
Re: (Score:2)
So, your solution is to let everyone run javascript, in case someone you trust need to? All the while letting places you shouldn't trust run scripts because that's the default?
No. I was commenting on Anonymous Coward #56247539's proposed policy of whitelisting script site and asking how a site would go about expressing to the user that it is worthy of opting in. To this, Anonymous Coward #56247827 replied:
Correct me if I'm wrong, but this implied to me that no site ought to be trusted. If this is the case, and if there is no generic "application player" for all major opera
Re: (Score:3, Interesting)
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..
Re: (Score:2)
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 applic
Re: (Score:2)
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 [stackoverflow.com].
Re: (Score:2)
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.
Re: (Score:2)
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?
Re: (Score:2)
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)
Why was this even possible? (Score:4, Insightful)
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? (Score:4, Interesting)
Re: (Score:2)
These aren't invasive sensors --- they're not collecting individually-identifiable information like a Camera or Microphone does, and the readings could be used to provide a friendlier browsing experience..... for example: lower light could default to a darker theme to reduce eye-strain.
Greater distance could select a "Big Screen/Big Picture/Dashboard" view versus an "Near view"
It might not be something every website needs, but I can think of at least a few web-based applications such as "Cloud-b
Re: (Score:2)
Why would anyone even want a device that has invasive sensors in it?
Because it is handy that the phone adjusts backlight based on ambient light. Also, phones (and most laptops) have much more invasive sensors known as camera and microphone.
Re: (Score:2)
Say the user wants the ambient light to control not only the OS-controlled backlight brightness but also a website's color scheme, in particular light on dark vs. dark on light. With what markup should a website declare both color schemes to the browser in order to allow the browser to choose one based on the brightness level read from the operating system?
Re: (Score:2)
multiple CSS style sheets, one of them being the default
https://www.w3.org/TR/html401/... [w3.org]
Alternatively, they don't. The user configures user-specific style overrides in their UA and the UA applies them depending on sensor output.
With what UI control in each major browser does the user so configure it to apply one of "multiple CSS style sheets, one of them being the default" during high ambient light and the other during low?
Re: (Score:2)
The phone's OS handles backlight control based on ambient light, not your damn web browser.
Read my post before going off on a tirade. It is only 3 sentences, including the quote that I replied to.
Proximity of smartphone to ear (Score:2)
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).
Re: (Score:2)
The phone's own dialer doesn't even do that. Probably because there's a lot of use cases and you'd rather have direct control anyway.
Standard feature (Score:2)
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 t
Re: (Score:2)
Yeah, that's not what I'm saying the phone's dialer doesn't do. 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.
Patchable (Score:2)
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.)
Re: (Score:2)
Put the smartphone against your ear: the screen shuts down
I think the claim is that proximity ought to disable the screen and touch screen at the level of the operating system, not that of the browser. The dialer (be it built-in or Skype for Web) would always request that the operating system display the number pad. And then based on proximity, the operating system would choose whether or not to display what the dialer has requested and whether or not to pass on touch events to the dialer. If the dialer absolutely needs to determine whether the number pad is displ
Re: (Score:2)
it's a standard feature on the phone's cell voice calling on nearly any smartphone I've had.
Except on TV and movies. It annoys me (very mildly, but still) that when actors "talk" on the phone the screen stays lit.
Re: (Score:2)
It works that way with the location API: The browser informs the user that the website wants to access the location and it's up to the user to authorize it. Same with notifications.
Re: (Score:2)
you are only thinking in desktop, but in tablets and phones you may want to change the white background to a warm white background if the light is lower, so it does not hurt the human eye or require user adjusting the brightness level. Also, interactive sites and specially WebRTC may want to disable touch input if the proximity sensor flags in, so you do not submit any bad email or ruin a game or simply hangup or turn on video chat.
This was very important for Firefox OS, but without it they are less importa
Re: (Score:2)
but in tablets and phones you may want to change the white background to a warm white background if the light is lower, so it does not hurt the human eye or require user adjusting the brightness level.
That would be at the level of the operating system, not the browser, and certainly not an individual web application.
Also, interactive sites and specially WebRTC may want to disable touch input if the proximity sensor flags in
That would also be at the level of the operating system.
Re: (Score:2)
in firefox OS, firefox was almost all the OS... even the apps were mostly web pages.
Even ignoring that, sites could change the css theme depending of the light sensor values, or web games use the proximity sensor to add new game features (like a very poor xbox kinetics feature).
Again, the idea was to give access to it and see how people used it, sometimes there are weird ideas that do use small and simple features.
This one didn't work, that is why is being disabled
Re: (Score:1)
I can't imagine why any of this information should ever be given to a damned website.
So what you're saying is you lack imagination?
Re: (Score:2)
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.
Safari and Firefox (Score:2)
Thank you Mozilla. Firefox and Safari are the browsers who look like they care about privacy, and they're currently my choices.
Will the anal probes be disabled too? (Score:1)
I hope they have something up the pipeline.