back to article Mozilla sends more snooping Web APIs to smartphone Siberia

Firefox has revealed it will bin more privacy-invasive APIs, deprecating access to the light sensor, device proximity sensor, and user proximity detection. The APIs in question have all been criticised for their invasive potential. For example, devicelight offered potential vectors for snooping on user browsing habits or even …

  1. redpawn

    But my Calculator App

    needs access to all sensors to accurately calculate your intentions and return the desired results.

    1. Dan 55 Silver badge

      Re: But my Calculator App

      That's good, mine also needs the Internet, phone ID, and contacts.

      1. Anonymous Coward
        Anonymous Coward

        Re: But my Calculator App

        Well how else is it to function if it doesn't have access to my Camera, storage and microphone?

  2. sabroni Silver badge

    the user is king

    Currently when a web site wants my phone's location the browser pops up a dialog asking for permission and asking if I want to allow once or indefinitely. (maybe that could do with an annual limit...). Why aren't these other APIs tweaked to work the same way? It's possible I've decided there's a good reason for the site to have access to my light sensor.

    Stop protecting me by taking stuff away and start protecting me by enabling informed choices.

    1. Charlie Clark Silver badge

      Re: the user is king

      Possibly to avoid the "Vista" effect of confronting the user with so many permission requests that they just give in and accept them all: anything for a quiet life.

      1. pip25

        Re: the user is king

        Then perhaps we should adjust the way these permission requests are made. For instance, the site could declare in advance, in a HTTP header, which privacy-sensitive features it wants to use, and then the user has to accept one single prompt, which has the option to "remember choice for this site".

        And of course the users need to realize that such choices do matter; there is no such thing as idiot-proof privacy. But I guess that's a whole different can of worms.

        1. Charles 9

          Re: the user is king

          It IS a can of worms because idiocy affects all of us, if not directly then as collateral damage. So we have to at least try for our own sakes because true idiots can't learn.

          As for the header, what if someone messes with it via a malicious proxy?

          1. Charlie Clark Silver badge

            Re: the user is king

            As for the header, what if someone messes with it via a malicious proxy?

            API access requires https so that shouldn't really be a problem. GDPR says, however, that blanket permissions cannot be asked for in any case.

            1. pip25

              Re: the user is king

              Define blanket permissions. What I had in mind was something like a list of the permission items the site wants (microphone, camera and proximity, for instance), all of which can be accepted or denied individually, if need be. Most certainly not a generic "do you allow this site to slurp your data" prompt.

  3. Christian Berger

    Making it user enableable is probably the worst thing to do

    So web applications could force the user to enable it, and you still have all the code in which means that all the security critical bugs stay in.

    It would have been better just to jank the code, or have it just return static values.

    1. Anonymous Coward
      Anonymous Coward

      Re: Making it user enableable is probably the worst thing to do

      How are they going to "force" the user to enable it? If you think by popping up a dialog asking it that will "force" the user to enable it, then I guess you can force the user to do anything that you can make a dialog pop up for?

      1. Charles 9

        Re: Making it user enableable is probably the worst thing to do

        Simple. It won't proceed until you agree, refusing to take no for an answer. You see it already in phone apps.

  4. pip25
    Unhappy

    The trend is more worrying than the security risks themselves

    Perhaps not for the most common use cases imaginable, but these were valid API features. Removing them is basically admitting that the browser vendor has no idea how to offer these features in a way that allows safe usage and/or user consent. So what are we going to remove next? There's a ton of ways you can fingerprint a device or spy on people's habits.

    Is privacy on mobile really such a lost cause? A permission-based system seems to work well for Android native apps, can't we do something similar for websites? After all, the boundary between sites and apps is getting more blurred by the minute anyway...

    1. Dan 55 Silver badge

      Re: The trend is more worrying than the security risks themselves

      Removing them is basically admitting that the browser vendor has no idea how to offer these features in a way that allows safe usage and/or user consent.

      Permission-based systems for native apps rely on a lot of filtering beforehand by Apple and Google and it still doesn't really work. If Apple have a galleon of slaves to vet app store uploads and Google can't properly vet everything in the Play Store, why offer these options to every website in the world?

      1. pip25

        Re: The trend is more worrying than the security risks themselves

        @Dan 55:

        My impression is that you are confusing privacy with security and safety. Perhaps there are some rules in the iOS/Android app store that state otherwise, but when I accept a permission for an app (SD card access, for instance), I do that with the understanding that the app can do whatever it pleases with that permission. It could potentially format my drive. Because of this, I only install apps I trust to an extent (widely used, the developer seems like a real person with contact info, etc.) and the matter of which permission to grant only comes after this decision.

        Websites are (or should be) similar. I try to identify dodgy websites before I even open them based on the search engine result. Whether I trust them with my sensor data is a question that would only come after I deem them safe enough to visit. (Other safeguards such as NoScript also help a lot with this, of course.)

        @Charles 9:

        Yet if and adult guts himself with a knife because he does not realize that it is sharp, no one calls for the banning of knives, because knowing knives are sharp is considered something every responsible person should know about. Similarly, one is expected not to cross a street during a red light, etc.

        I feel the definition of what is considered common knowledge should be changed accordingly to the dangers of the present era, which do include identity/data theft. Of course, that is far from being the case right now. :(

        1. Dan 55 Silver badge

          Re: The trend is more worrying than the security risks themselves

          Websites cannot be treated as similar to signed apps from registered developers made available from one source after being verified. There's too much scope for XSS, malvertising, DNS hijacking, the website being exploited, or a third party website which supplies fonts, JS or CSS being DNS hijacked or exploited.

    2. Charles 9

      Re: The trend is more worrying than the security risks themselves

      "Removing them is basically admitting that the browser vendor has no idea how to offer these features in a way that allows safe usage and/or user consent."

      It's called dual-use technology, and there's no real way to avoid. The same sharp knife that is essential for cutting in the kitchen also (and intrinsically) makes it a useful tool for murder. So you're left in a dilemma, particularly when you're surrounded by idiots.

      1. handleoclast
        Coat

        Re: The trend is more worrying than the security risks themselves

        The same sharp knife that is essential for cutting in the kitchen also (and intrinsically) makes it a useful tool for murder. So you're left in a dilemma, particularly when you're surrounded by idiots.

        A dilemma? I don't see a dilemma. If I'm surrounded by idiots and I have a sharp knife in my hand, there's only one obvious thing to do...

        1. Charles 9

          Re: The trend is more worrying than the security risks themselves

          Slit your throat and end the suffering? Because no other alternative will work; idiots are like weeds and hydras (remove one and two more take their place).

  5. ThatOne Silver badge
    Facepalm

    KISS principle, we hardly knew you

    There is also the question of bloat vs. usefulness to consider.

    I've been using web browsers since Mosaic and still can't imagine why a website would need to read my light sensor. I have no doubt there is a use case, but I don't think you could classify it as vital. I'm pretty sure it's rather yet another "lets see what else we can include" solution which had to look long and hard for a problem to solve.

    IMHO a web browser is for browsing remote information, not a gateway to your device (it could, but it shouldn't). But apparently that's just me...

    1. Charles 9

      Re: KISS principle, we hardly knew you

      It IS you. That horse bolted long ago, and you've been outvoted.

    2. Anonymous Coward
      Anonymous Coward

      Re: KISS principle, we hardly knew you

      I can imagine some service which makes readable versions of articles (which, OK, is a thing browsers can usually do themselves now but was not always) which might want to be able to alter what it did based on ambient light. There will be other things.

      But in fact what it should really be possible to do is to send a bunch of stuff to the browser which says 'if ambient light is in range x do y; if it is in z do q ...', where y and q are such that the service could never get any information about which had been chosen (because that would leak information about the ambient light). But I can see that getting pretty hairy to make leakproof.

      1. stephanh

        Re: KISS principle, we hardly knew you

        @tfb

        "But in fact what it should really be possible to do is to send a bunch of stuff to the browser which says 'if ambient light is in range x do y; if it is in z do q ...'"

        You can do exactly that already using the light-level media query in CSS, it lets you say: use this style if light level is low, use this style if light level is high. No need for Javascript.

        Unfortunately it can still be used to glean information, e.g. by having a 1x1 pixel image which is shown in dark conditions and another one which is shown in light conditions, and then tracking on the server which is requested.

        1. Charles 9

          Re: KISS principle, we hardly knew you

          Let's face it. The mere act of requesting a web page contains plenty of useful metadata. The request will have a return address and a timestamp; that alone can be useful, much like you can't send a letter without posting an address and the post office knowing where they picked up the letter to send.

        2. Anonymous Coward
          Anonymous Coward

          Re: KISS principle, we hardly knew you

          @stephanh Right, that sort of thng was what I was getting at: hard to avoid leaking information.

    3. Carpet Deal 'em

      Re: KISS principle, we hardly knew you

      "I'm pretty sure it's rather yet another "lets see what else we can include" solution which had to look long and hard for a problem to solve."

      You're almost certainly right. After everything previously provided by plugins was pulled into the browser, there was very little constraining idiots from adding everything they could to the "standard". Previously, there was a disincentive to go too far since most of the functionality users needed was already provided by plugins such as Flash and Java(which were in turn limited in what they could do thanks to the plugin API), but now they've been given the keys to the kingdom since there's very little the browser can't access and little to oppose them.

      If you ask me, we would've been far better served by a more secure successor to NSPAPI. You could still have sane limits that come from active content being inherently boxed and, perhaps more importantly, you'd avoid the current situation where websites are becoming less and less portable(were things anywhere near this incompatible during the browser wars? Because my dim memory doesn't recall them being that bad).

      1. Charles 9

        Re: KISS principle, we hardly knew you

        "You could still have sane limits that come from active content being inherently boxed"

        Until they BREAK OUT of the boxes. Java jailbreaks, anyone?

        1. Carpet Deal 'em
          Paris Hilton

          Re: KISS principle, we hardly knew you

          I'm not entirely sure if implementing something in a sandboxed plugin's a better defense against malware than implementing it in a browser, but it's definitely a better defense against idiot web designers. External plugins usually imply restricting yourself to one a page, but HTML and JavaScript can be sprinkled all over the place without any reason for an idiot to restrain themselves. That alone is a powerful argument against the modern era of ever-exploding web "standards", if you ask me(I'm also a bit of a fan of off-brand browsers, which these fictitious standards actively harm).

          1. Charles 9

            Re: KISS principle, we hardly knew you

            But what happens when the users rally against you? The biggest problem is that you run the risk of a revolt when someone satisfies them and they jump ship in response. As it stands, the likes of Facebook have enough power to resurrect captive portals (AOL, CompuServe, etc.) and wean people OFF the Web. Then what?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like