Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login
Stealing sensitive browser data with the W3C Ambient Light Sensor API (2017) (blog.lukaszolejnik.com) similar stories update story
113 points by chrixs | karma 51 | avg karma 51.0 2019-10-14 14:03:26 | hide | past | favorite | 53 comments



view as:

That’s insane but kind of valid - maybe restrict access to the light sensor api to same-origin sources?

Wouldn't work as the links are already on the same page. It's just shifting through different links and styling them differently.

From the article:

> Perhaps the most obvious solution is to require the user to grant permission to the website requesting access to the sensor

Which makes sense... a light sensor is really a 1 pixel camera.


> There is currently an ongoing discussion within a W3C Device and Sensors Working Group whether to allow websites access the light sensor without requiring the user’s permission.

Why is this even a thing?

Just make this the same as location or microphone prompts? I never understood the fear of being transparent or give choice to users.

I hope at least firefox has a setting to permanently disable this feature.


What a dumb idea. We just wised up and took away the battery API because it was being used for fingerprinting, and now they want to add more permissionless hardware info back in.

You just know the argument being made is "Light sensor input changes frequently enough that it isn't useful for fingerprinting." But history tells us that literally everything will be used for fingerprinting.

Provides a tiny amount of differentiation to maybe identify particular devices? Scoop it up!

Or if you're already able to identify a particular person, how about keeping a persistent log of whether they're indoors or outdoors and aggregating that from as many different sites as possible? Collect all the data and store it forever! Maybe it will help sell ads 0.004% more effectively, and there's no downside!

IMO, whatever amount of risk this carries clearly outweighs the benefit of websites being able to access my light sensor without asking for permission, because the value of that is 0.


It's the web trying to take back share from native by integrating more hardware related APIs i.e. storage, authentication, etc. - driven by large corporations with disproportionate voices in these working groups.

I doubt it's even this particular feature, just an ethos of: let's add as much as possible because it'll increase our relevance.


Agreed, and I assume the main use case is for websites to be able to offer a "dark UI" like maps apps do, so if you're using it for navigation at night it won't blind you.

But here's a crazy idea for them:

    @media (prefers-color-scheme: dark) {
        color: white;
        background-color: black;
    }
That way it doesn't leak any uncontrollable information, and it makes the UI look how I want it to! It can even happen automatically at night if I've set my phone to do that. Downside, if I drive through a tunnel during the day the UI stays bright. I'll live.

If they really think they need to access my light sensor, they can ask. Maybe someone wants to make a light meter web app, I don't know. But I do know they have no business accessing sensor hardware without permission.

It's like with the battery API, people had this idea that web developers could say "Oh your battery is low, we'll throttle back into low power mode to respect that."

But instead, websites are happy to continue burning all the CPU, data, and battery life in the world, because by and large developers aren't paid to give a shit about your battery. They're paid to ship features and make whatever metrics go up. So the only thing it gets used for is identifying phones for advertiser targeting.


> But history tells us that literally everything will be used for fingerprinting

I don't think you realize how right you are. Fingerprinting is eventually going to be a lost cause. In 10 years or so, we will have the tech to fingerprint anyone just by their writing style (some companies even claim to be able to do this already today). What do you do then? Ban posting stuff online?


>In 10 years or so, we will have the tech to fingerprint anyone just by their writing style (some companies even claim to be able to do that already today).

...given a large enough corpus of text. I doubt that you're able to pick up much from a dozen 1 sentence replies on reddit, for instance. You could even use some sort of neural network based sentence transformer to scramble the structure without significantly altering the meaning.


I am not sure it has to be too large.

It only takes 33 bits of information to identify 1 person out of 7 billion. How many bits did you lose just by talking about neural networks in that one sentence? How many bits did you lose from the timing/time zone of your comment? By the language of your comment?


I imagine that there's a lot of information in the specific cadence of typing, in addition to the final text.

https://en.wikipedia.org/wiki/Keystroke_dynamics


As a low tech solution, you can always compose the contents in a separate window and paste it in when you're done. Hardened browsers (eg. Firefox with resistfingerprinting) can frustrate attempts by throttling key events (key events get coalesced into 1s/5s/10s intervals).

First time I hear about this (edit: Firefox with resistfingerprinting) and I'm the kind of person who finds this interesting.

Which means anyone who does this will probably have made themselves unique, or - I guess- at least narrow down the scope of possible users more than the typing speed would do.


This is another browser stupidity. Dont send anything until the submit button is pressed. It's the browsers job to implement the text edit box and spell check, not every website.

Being able to see keystrokes in Javascript is pretty useful for things like autocomplete. Say you want to send an invoice to "Foo Bar, Inc.". Do you really want to type that every time? Do you want to type "Foo" and then click submit, and then be taken to search results? Why make a 700ms task into a 5s task, especially when you're doing it hundreds of times a day.

There are hardened browsers that will make the script wait for a while to get the key events. That seems like the right solution; most people using controlled enterprise apps don't have to deal with huge amounts of input lag, while people that are paranoid won't be profiled by their typing cadence.


How limiting would it be to have auto complete implemented in the browser? Probably not quite as nice as Google but still useful.

>How many bits did you lose just by talking about neural networks in that one sentence? How many bits did you lose from the timing/time zone of your comment? By the language of your comment?

uhh, probably 2 or 3 at most? Given the demographics of Hacker News (technical background, mostly American), probably half the site have the attributes you have listed.


Provide tools to anonymize writing, probably.

How does that help companies trying to track what I search for on webshops?

Imagine light beacons in any graphical media same as the audio beacons that already exist.

This is about technology that identifies people based on their writing style which is claimed to be some kind of panopticon that can be used for tracking you everywhere you go.

> we will have the tech to fingerprint anyone just by their writing style

we're far beyond that; I have successfully fingerprinted users by buttons they press in Office 365


One benefit of only WebKit being allowed on iOS is that it gives Apple the market power to shape web standards in favor of privacy.

Apple may be happy to differentiate on privacy but surely they don't care or might even prefer that android and others get worse in that regard.

It doesn't really matter if Apple is for privacy in their heart of hearts or because they're ruthless capitalists if the end result is in favor of privacy.

In fact it's better if there's a profit incentive. Alignment of interests is what's been Apple's superpower for a long time now.


Sure, but I'd guess their incentives align with being better than median, and thus not necessarily with improving the standards with their market power.

Exactly this. Otherwise they'd push their things to standards processes or open them to non-Apple users. Like their login thing, which is genius but useless to non-Apple users.

you can have an apple id and not have any apple device.

>but surely they don't care or might even prefer that android and others get worse in that regard

There are more levels than just their own direct position though right? Apple's more data/ad-driven competitors directly gain revenue from having more information. In some cases if Apple is able to shape standards themselves in favor of more privacy, their business model enables them to profit in that environment while it starves others of oxygen. Competitors can't just necessarily take the same privacy stance without suffering harm (and conversely, Apple can't fight battles on pricing or data-driven features like AI as effectively). Businesses seeking to alter the environment itself to match their strengths isn't unheard of and can make a lot of sense.


On the flip side, Chrome can ram through implementations before their standardized and people will start using them.

But not on iOS, which as of this writing is still a big deal.

> I hope at least firefox has a setting to permanently disable this feature.

I'd like to see all the sensors permissions lumped together behind a sufficiently scary name ("Permission to spy on you"?), off by default, and for the browser to enforce strict security requirements before it's even willing to prompt the user for the permissions the site's requested.

Web apps aren't going away, but we could have a better UI to enforce a separation between full-fat web apps with similar capabilities to native apps, and the rest of the web that's just trying to abuse those features for spying.


> I'd like to see all the sensors permissions lumped together behind a sufficiently scary name ("Permission to spy on you"?)

That might be a renamed JavaScript toggle.


Well, currently switching off JS entirely is the single best way to block abusive web site behaviors, but there's obviously room for improvement. There are valid use cases for ordinary websites (as opposed to full-featured web apps) to use JavaScript, but that shouldn't by default extend to sensor APIs, messing with scrolling behavior, using unrestricted CPU time, or loading third-party scripts.

Maybe I'm lacking imagination, but the only good usecase I can come up with is dimming the website or switching to dark mode. Unless I visit that page very frequently that use case is killed completely by a permission promt. It's easier to let me do it manually than to ask for my permission to do it automagically.

Websites already get informed if your phone is set to dark mode, you can darken your page with just CSS. So you don't need actual access to the light sensor for that, and in fact you probably shouldn't use it for that... since you might be overriding the user's dark mode preferences.

can this be lumped in with the camera permissions? also, why do websites even need to know this? i dont think ive ever seen a native program use my light sensor, just the OS.

You've not used e.g. Google Maps and have it switch to dark mode when you're driving at night or through a tunnel?

But regardless of whether this can be useful or not, why not just let the OS/browser on behalf of the user enable or disable dark mode, by choosing the appropriate CSS? Because as someone else has already pointed out, having the app "guess" whether I want to enable automatic dark mode or not, rather than just obeying my settings (perhaps I always want it on, regardless of ambient light?) is just stupid.


I think I remember hearing that the accelerometer and gyroscope work the same way, which is of course even more sensitive information. It makes no sense to me.

> Why is this even a thing?

Do you think that this point was never raised with them? It was, look at w3c lists, look at mozilla bugzilla, look at chrome bug tracker and long lists of WONTFIX bugs asking to let user disable those sensors. It goes almost like this "I do not need the website know how I hold the phone, — No, you really have no reason to disable sensors," after them being asked for the tenth time. HOW DO YOU REASON WITH SUCH PEOPLE?

Whomever ever came first with this idea must be found and fired, and people should make sure that no contributions to web standards to be accepted from that person. Whomever followed, allowed, and collaborated on that process should also be fired along.

People who got to write web standards today are unqualified for this role in their prime majority. Some of those "software engineers" speak in more lawyery, MBA-like manner than real lawyers do. They are really hired as lobbyist, to push, push, push their client's proposals to approval in any way possible, no matter how much they have to break the browser to do that. People can't work with them. They are toxic.

It should be a default presumption that people hired to write standards should be highly professional in their demeanour, experienced, trusted, and give no favours to one vendor or another, be direct, and above all be helpful. There should be no second thought about that.

Now, how many of people involved with WhatWG will meet these criteria?


I agree with your points and am not sure why your response is light grey. Those criteria are too wordy for my liking - I think the summary from Tron works just as well here and is slightly more succinct:

I fight for the user.


It's not even a web sites job to worry about my environment. Stick to sending data TO ME rather than pulling it from me.

At some point asking for too many permissions because such an annoyance that it actually leads to people basically agreeing to everything, sight-unseen. Just look at Windows UAC, or previous iterations of Android's permission system. My guess is they are trying to avoid this sort of situation.

A logical evolution of what I did 5 years ago and other people did before me. I can only assume what are ad networks doing...

https://news.ycombinator.com/item?id=7863418

Though this one is much cooler :)


I think in practice people would close a website that was flashing the screen at them in black and white. Maybe you can make it work with a more subtle change but I bet your signal to noise ratio would be abysmal.

Totally impractical but a neat idea anyway!


Can this also be exploited using CSS `@media (prefers-color-scheme: dark)` if the device's configured to use dark mode in low-light conditions (as opposed to time-based switching)?

That wouldn't work for a lot of people (like me), who have a dark theme on all the time.

I don't have any statistics to back it up, but most everyone I know just leaves dark theme on all the time (or in the case of one light theme on all the time).


Automatic dark mode switching is also usually based on time, not lighting. And even if it is based on lighting, it usually has a very low temporal resolution -- if the user is in a dark room with occasional flashes of bright light (say, a disco), the UI isn't expected to flash in synchrony.

I miss the time when web sites were just simple documents.

I don't. The number of people who wanted to publish things online but couldn't due to the technical barriers was huge. I'd much rather deal with the complexities of browser security than keep the internet the exclusive domain of technically-minded nerds. The internet as a platform is far better now even if the technology that drives it sucks.

Why not just ask the user for permission for all APIs that interact with hardware?

Not all apps need it, and the ones who do, should be able to explain why.

The Battery API was removed due to fingerprinting concerns, but a permission-asking battery API would still be helpful to bring web apps closer to native apps.


Legal | privacy