Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Firefox Privacy

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.
This discussion has been archived. No new comments can be posted.

Firefox Gets Privacy Boost By Disabling Proximity and Ambient Light Sensor APIs

Comments Filter:
  • by Chatterton ( 228704 ) on Monday March 12, 2018 @12:44PM (#56247411) Homepage

    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?

    • by Anonymous Coward

      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.

      • by DrYak ( 748999 ) on Monday March 12, 2018 @02:21PM (#56248041) Homepage

        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).

        • "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.

          • 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

    • Stating with Firefox 61 -- expected to be released in June 2018 -- websites won't be able to use Firefox to access data from sensors that provide wanking and nose-picking information.

      • Stating with Firefox 61 -- expected to be released in June 2018 -- websites won't be able to use Firefox to access data from sensors that provide wanking and nose-picking information.

        That's what black electrical tape is for.

    • I don't know about the W3C but for Firefox they were probably useful in the context of Firefox OS which was a mobile OS with a web engine as its runtime.
    • by zifn4b ( 1040588 )

      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.

      • by nnull ( 1148259 )
        Which browser is still relevant?
      • by higuita ( 129722 )

        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.

    • by DarkOx ( 621550 )

      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.

      • "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.

        • by DarkOx ( 621550 )

          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.

    • by GuB-42 ( 2483988 )

      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.

    • by tlhIngan ( 30335 )

      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?

      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

    • All the things that should've been added using a robust plugin system, ... RIP XUL
  • by Anonymous Coward on Monday March 12, 2018 @01:10PM (#56247581)

    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.

    • by jabberw0k ( 62554 ) on Monday March 12, 2018 @01:15PM (#56247621) Homepage Journal
      Why would anyone even want a device that has invasive sensors in it?
      • by mysidia ( 191772 )

        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

      • by amorsen ( 7485 )

        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.

      • 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).

        • 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.

          • 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

            • 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.

              • 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.)

            • by tepples ( 727027 )

              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

            • 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.

    • While security can't ever be perfect I'm fine with these APIs as long as they're opt in.
      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.
    • by higuita ( 129722 )

      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

      • by tepples ( 727027 )

        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.

        • by higuita ( 129722 )

          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

    • 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?

  • Thank you Mozilla. Firefox and Safari are the browsers who look like they care about privacy, and they're currently my choices.

  • I hope they have something up the pipeline.

This process can check if this value is zero, and if it is, it does something child-like. -- Forbes Burkowski, CS 454, University of Washington

Working...