▲ 105 points
back
26 comments
What was the purpose of exposing the Ambient Light Sensor to web pages in the first place?
The W3C document[0] has a few suggestions:
> A Web application provides input for a smart home system to control lighting.
> A Web aplication checks whether light level at work space is sufficient.
> A Web application calculates settings for a camera with manual controls (apperture, shutter speed, ISO).
> A Web application monitors light level changes produced by hovering hand user gesture and interprets them to control a game character.
While these applications are all potentially valid, it seems like each use case would be better served by a native app.
[0] https://www.w3.org/TR/ambient-light/#usecases-requirements
> While these applications are all potentially valid, it seems like each use case would be better served by a native app.
That is the threat. They're pushing hard to keep the "open web" competitive with native apps, so that the web is not abandoned as an app platform.
Well said. I'm surprised this is the only comment focused on this. WASM fits in that spot as well.
Eventually there's a point where the web platform is good enough that some companies choose to sunset native apps.
Delivering the same functionality across 3 disparate platforms is a waste of time and energy. Especially when the form factor in the end users hands is the same.
I get why it's that way now, but the question will come up over time. Especially for any app that needs live remote API calls to function.
The goal of keeping the open web “competitive” seems a little dubious, however, considering who’s favor shall ultimately be competed for, no?
Offering up every last conduit one could possibly expose on a general purpose platform, so that competing interests on the other side of the wire are all fighting on a level playing field to harvest all the imaginable minutia of every quiver of flesh (whether voluntary or reflexive) against a piece of smartphone glass, in an effort to line pockets, starts to feel a little obscene after a while.
And if any quarter should be given, the big bad companies will pack up their wares and refuse to conduct business in the commons, leaving the web to disintegrate and decompose back unto what geocities, myspace and aol used to look like? Not sure that’d be so terrible, tbh.
The goal of keeping the open web “competitive” seems a little dubious, however, considering who’s favor shall ultimately be competed for, no?
No.
I like my ebook reader app to automatically adjust to the light. I'd like to be able to build similar apps on the web platform.
I agree getting the security balance right is important though.
It's the "Web everything" trend, and personally I'm not too fond of it --- especially given how even the original goal of being a massively hyperlinked document repository is often being ignored now in preference to "Web applications" for everything.
Then again, here's another reason to keep JavaScript absolutely off, except for sites you really trust and actually need JS on.
It's almost like someone came up with a solution, then tried really hard to find a set of problems.
The first and last use case definitely feel that way.
A smart home system would probably use a proper light sensor so that it will work if your phone is in your pocket or face down or simply not open on the page that's controlling it. Of course, all of these issues apply to an app version as well.
Controlling a character via gestures sounds like a job for the front-facing camera, not the light sensor.
I think those use-cases are something a user should have to opt into through a permission prompt (just like cameras are ... the light sensor is sort of like a camera so it makes sense).
i'd appreciate it if websites could load dark instead of white if the room I'm in is dark, and there was a well supported (and actually implemented) API for doing that.
I absolutely agree that this would be a great idea, but it would be much better to solve this at a higher level - the website should provide a light and dark stylesheet, and then the browser should pick based on whether the user has a dark theme or not. Giving a website information about your physical surroundings (GPS coordinates, ambient light, audio input, etc) should be an extremely conscious choice, made only when there is not a better option (Google Maps cannot recalculate your route upon making a wrong turn if it doesn't know where you are, for example).
The server still knows you're requesting those resources. And the browser will always have to request those to check if it can offer you a different layout anyway.
What if I don't want to give you binary light/dark choice. Perhaps the site is flux offering you an app the change your colour balance. It could show you what the app would do now with your existing light levels.
Such evil genius - and what is the solution? Yet another popup so sites can ask for permission to access the ambient light sensor?
We're already past the point where the average consumer is confused by what they are actually allowing when they click "Allow" for the various permissions.
The obvious solution is not having an ambient light sensor API, or a much more granular one, like the battery API should've been.
Exactly. Same with vibration, accelerometer, and gyro. For me personally there is zero reason why my browser should ever need these yet they can use them without any permission on Android Chrome and they cannot be disabled without rooting your phone.
Games can use all three of those very effectively. Agree they should be behind a permission prompt, though.
Gyro is really nice for VR. But it should not be allowed in background tabs. No clue whether it is right now.
Part of the problem (the big one) lies here: "(filters in SVG work on cross-origin resources)" - without it, second attack (more serious) is not possible.
Mozilla response: ignore problem.[1]
Component:▸ Security
Importance: P3 normal
Status: NEW
Reported: 6 months ago
So (for Firefox) setting this in about:config should disable usage of the light sensor API (plus other sensors that could be also working against you), right?
> device.sensors.enabled = false
> Filter the signal down to about 0.5Hz, which is comparable to how fast most displays auto-adjust for brightness.
No, that wouldn't help.
From the article: For the light sensor, limiting the frequency will not thwart our attacks; even frequency as low as 1Hz would allow the same type of attack, with only factor-of-two slowdown.
This "vulnerability" is extremely hypothetical and they have not given proof that it can be exploited in the field. Just conjecture and a demo in a totally unrealistic environment.
It's not hypothetical at all. Watch the demos; they clearly demonstrate data being exfiltrated. Additionally, the article mentions several times that yes, the bits/sec is quite low due to several factors. I don't think the author is exaggerating the situation at all.
Would you rather wait for the API to go live and then be abused to steal real data? I would much rather researchers discover and report on possible attack vectors long before they are enabled by default. "Trust by default" long ago proved foolish.
> Although in our proof of concept demonstrations we rely on the assumption that the light conditions do not change during the exfiltration phase, extending the demos to handle these situations shouldn’t be a problem
They say themselves that their demo is not real world and wont work in the real work and then say it "shouldn't be a problem" to make it work.
Not to mention that it takes 20 seconds of flashing the users screen to do the thing (how is that supposed to work without setting off alarm bells).
As I said, they have no proof of a real world vulnerability, only proof it a staged environment, and they readily admit it.
> they have no proof of a real world vulnerability
So what. This "default allow" attitude is easily more damaging than any other source of security problems. You (or anyone else) cannot know all of the ways exposing new data could be exploited, or might already be exploited in ways that we are not lucky enough to know about.
Caring about security - which includes the future unknown unknowns you don't yet know to even look for - means minimizing what is exposed to the public attack surface to what is both needed (which does not include anything merely "wanted") and demonstrated/proven to have trivial risk with known limits.
Actually extracting data this way sounds like the kind of hack that would gain someone an impressive reputation as a hacker, instead of triggering serious privacy risks.
Compare it to the iPodLinux project, when nilss extracted a bootloader using a piezo buzzer. Yes, this type of hack can be done, but something tells me it's not going to be a frequent worry.
https://web.archive.org/web/20050301010451/http://ipodlinux....