Add description for use cases

[pozdnyakov]

The ALS specification is missing use cases description.

[pozdnyakov]

Tagging @anssiko @tobie @dougt

[tobie]

Adding my comment here made directly in the Chrome's design doc:

One of the key points of the generic sensor API is to expose low-level primitives so that (1) the Web platform can compete with native, and (2) developers have the tools to explore new use cases without requiring implementors to implement and deploy specific APIs for each new use case (as per the Extensible Web Manifesto).

Of course, low-level primitives have added security and privacy concerns compared to higher-level APIs, which is why it makes sense to beef-up their permissions. If/when specific use cases emerge that could benefit from higher-level APIs and which could lessen the security concerns, it makes sense to add such APIs and entice developers to use them by making them available with "lighter" permissions.

For example, the Youtube use case mentioned above could be handled by a dedicated LightLevel API, with two to three enum values (e.g. the lightlevel mediaquery inspired "dim", "normal", and "washed" values), with a frequency below 1Hz, whose permission would be granted by default, whereas ALS would require a prompt of some kind.

Similarly, motion-sensors have high security/privacy issues, while a "device shaked" sensors (that would literally emit a new event everytime the device is shaked, similar to undo on iPhones) has much lower security concerns and could probably be offered with super low permissions.

So to answer the larger question, we need to consider these sensors as tools for bleeding-edge use cases, and know that spec-editors and implementors will be paving the cowpath as common use-cases emerge. Such low-level access comes with a cost for developers: higher scrutiny (from both UA and users). For example, they could be limited to bookmarked/installed apps, origins with EV certs, or other, vendor-specific heuristics. So imho, don't worry about making these high-security risk sensors harder to access. That's part of the deal.

[anssiko]

@tobie, thanks! I'd be happy if you'd add a concise version of what you just wrote into the spec proper.

[tobie]

@anssiko I'm struggling where to put all of this info. In the generic sensor spec? In the privacy and security section? In the extensibility part? In an explainer doc? Arggg!!!!

[anssiko]

Just put it somewhere and we can move it around if people are not happy where it lands initially :-)

[reillyeon]

I don't know about YouTube but there is a proposal to use the ambient light sensor for reader mode in Chrome for the same purpose.

[anssiko]

@reillyeon, that's a good one, thanks!

@tobie, could you integrate @reillyeon's use case too? I'm happy to review your PR, and add more content when we have a starting point somewhere :-)

[noncombatant]

If we design powerful APIs first, without use-cases, we will achieve parity with native: privacy- and security-vulnerability parity. That is how legacy platforms were designed, and that's what we need to get away from (especially in this world where drive-by, ephemeral mobile code is a key feature).

A key security and privacy question has been, how much precision and frequency do we need in these samples? And we can't answer those questions without use-cases. For ALS, the YouTube and Reader use-cases (which are essentially the same) are already served by the CSS Light Level API. If we want to go beyond that, we need use cases that go beyond that.

[tobie]

If we design powerful APIs first, without use-cases, we will achieve parity with native: privacy- and security-vulnerability parity. That is how legacy platforms were designed, and that's what we need to get away from (especially in this world where drive-by, ephemeral mobile code is a key feature).

A key security and privacy question has been, how much precision and frequency do we need in these samples? And we can't answer those questions without use-cases. For ALS, the YouTube and Reader use-cases (which are essentially the same) are already served by the CSS Light Level API. If we want to go beyond that, we need use cases that go beyond that.

You have a point.

For ALS, I agree we don't seem to have use cases that require anything beyond the granularity of the CSS Light Level API (which, btw, has been deferred to level 5 of the media query spec for now). I've only looked at ALS as a testbed for the generic sensor API, so maybe @dougt or @anssiko have more info wrt to use-cases. Cursory search in the group's archive didn't yield much in terms of use cases that would require higher granularity.

That said, we have such use cases for sensors beyond ALS, notably motion sensors. The use cases for motion sensors require high precision and high frequency (120Hz and beyond). Furthermore, as the data is often integrated, mitigating privacy concerns by adding noise to the data samples (or even to their timestamps) isn't really an option as its effect would be exponential.

Hence we have to solve this issue for motion sensors. Once we do, we might find this solution applies just as well to ALS, or instead ditch ALS altogether for now in favor of a mediaquery-inspired LightLevelSensor.

As a sidenote, your comment about drive-by seems particularly intriguing wrt low-level and/or high-frequency sensors. Has limiting access based on PWA installed status been considered for sensors? Iirc that's been done for push notifications, no?

[owencm]

Friendly reminder that Chrome security and privacy teams would like to see use cases linked to from the spec somewhere before doing a final review.

[anssiko]

We now have a bunch of high value use cases documented in https://w3c.github.io/ambient-light/#usecases-requirements

All these use cases seem to require ALS, so I suggest we look into rounding the illuminance readings (and capping the frequency) to the extent that mitigates the known attacks while still being able to address the said use cases, update our current implementation accordingly, and then let @lknik et al. to try to reproduce the attack on the updated implementation, to confirm whether we've succeeded or failed.

If the attack cannot be mitigated this way, only then look into dropping ALS in favour of LLS.

[anssiko]

(I reopened this issue to signal we're still interested in hearing further use cases, even if the current set is a great start.)

[tobie]

Would be great to see the comments I made in my review of #26 addressed. Mainly:

1. that these use cases sound very theoretical and it would good to have them confirmed by their existence in natives apps,
2. that I'm also not sure ALS sensors shipped on devices actually have the physical capabilities for some of these use cases,
3. that the document styling really is a CSS issue, and that the CSS WG was happy providing just 3 discreet values, and
4. that these use cases have very different requirements in terms of accuracy, latency, and frequency, and it would be good to have those spelled out.

Overall, I'm concerned we're increasing the attack surface area for little gain at this point. As mentioned earlier, I think we should focus on finding solutions for motion sensors where the use cases are much clearer and the requirements much higher. Once we find a solution for those, extending it to ALS should be trivial.

[anssiko]

Folks who may not be following the PR comments, please note there's an active discussion going on in #26 with regard to the ALS use cases.

Edit: the PR #26 was merged, further discussion in this issue.

[alexshalamov]

There was concern related to whether ALS can be used to support following use-case:

• A Web application calculates settings for a camera with manual controls (apperture, shutter speed, ISO).

I did few tests with (Sony Xperia Z5 compact, Z1 compact, PixelXL, Nexus 5 and Mi Pad2), some devices have better sensors than the others, yet, the mentioned use-case can be implemented. There are few native apps as well.

Example of "good" sensor, 0.1 EV difference with Sekonic L-358.

[anssiko]

Use cases have been documented in https://w3c.github.io/ambient-light/#usecases-requirements and recently we also added https://w3c.github.io/ambient-light/#security-and-privacy that specify how to mitigate the known attacks while still be able to address the said use cases.

[tobie]

I don't think #23 (comment) has been addressed.

[anssiko]

I revisited PR #26 and discussion therein seemed to address all of your concerns. Please clarify which part requires further discussion?

[tobie]

Specifically point (3) and (4) in #23 (comment) weren't addressed.

[anssiko]

@tobie, my expectation is #34 addresses your concerns. I will merge it if I don't hear any further objections from you in a reasonable time.

[tobie]

"In a reasonable time" should be a little over 1 hour and 40 minutes, no?

Overall, it seems you want to move away from catering to the common use case of designing to the ambient-light level, which I think is fine.

In this case, I suggest moving the note you just added (along with the one in the introduction) to a dedicated "scope" section (or similar), earlier in the document (perhaps in the intro or right after), where you explicitly mention that the ambient-light-adaptive-design use case is not in scope and needs to be handled by the light-level media query (which is now level 5, btw, and no longer level 4) combined with the matchMedia operation spec'ed in CSSOM.

[alexshalamov]

@tobie can you make new issue related to moving note to the scope section and fixing MQ versioning? This issue has nothing to do with the reason used for reopening.

[tobie]

Those are suggested editorial details for the overarching issue which is to be upfront about the scope of use cases the API is designed to enable. Seems a good fit for an issue which is precisely about listing use cases and in which the scope of the API was clarified.

[anssiko]

@tobie, #36 should address your concerns. Please let us know if you have further tweaks or suggestions in mind.