Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add description for use cases #23

Closed
pozdnyakov opened this issue Mar 28, 2017 · 24 comments

Comments

Projects
None yet
7 participants
@pozdnyakov
Copy link

commented Mar 28, 2017

The ALS specification is missing use cases description.

@pozdnyakov

This comment has been minimized.

Copy link
Author

commented Mar 28, 2017

@tobie

This comment has been minimized.

Copy link
Member

commented Apr 13, 2017

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

This comment has been minimized.

Copy link
Member

commented Apr 13, 2017

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

@tobie

This comment has been minimized.

Copy link
Member

commented Apr 13, 2017

@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

This comment has been minimized.

Copy link
Member

commented Apr 13, 2017

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

@reillyeon

This comment has been minimized.

Copy link

commented Apr 17, 2017

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

This comment has been minimized.

Copy link
Member

commented Apr 19, 2017

@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

This comment has been minimized.

Copy link

commented Apr 19, 2017

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

This comment has been minimized.

Copy link
Member

commented Apr 20, 2017

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

This comment has been minimized.

Copy link

commented Apr 25, 2017

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.

pozdnyakov pushed a commit to pozdnyakov/ambient-light that referenced this issue Apr 28, 2017

Mikhail Pozdnyakov
Provide "Use Cases and Requirements" section
Fixes w3c#23.

Authors:
Alexander Sahalamov <alexander.shalamov@intel.com>
Mikhail Pozdnyakov <mikhail.pozdnyakov@intel.com>

pozdnyakov pushed a commit to pozdnyakov/ambient-light that referenced this issue Apr 28, 2017

Mikhail Pozdnyakov
Provide "Use Cases and Requirements" section
Fixes w3c#23.

Authors:
Alexander Sahalamov <alexander.shalamov@intel.com>
Mikhail Pozdnyakov <mikhail.pozdnyakov@intel.com>

@anssiko anssiko closed this in #26 Apr 28, 2017

anssiko added a commit that referenced this issue Apr 28, 2017

Provide "Use Cases and Requirements" section
Fixes #23.

Authors:
Alexander Sahalamov <alexander.shalamov@intel.com>
Mikhail Pozdnyakov <mikhail.pozdnyakov@intel.com>
@anssiko

This comment has been minimized.

Copy link
Member

commented Apr 28, 2017

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

This comment has been minimized.

Copy link
Member

commented Apr 28, 2017

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

@anssiko anssiko reopened this Apr 28, 2017

@tobie

This comment has been minimized.

Copy link
Member

commented Apr 28, 2017

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

This comment has been minimized.

Copy link
Member

commented Apr 28, 2017

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

This comment has been minimized.

Copy link

commented May 12, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 18, 2017

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.

@anssiko anssiko closed this Aug 18, 2017

@tobie tobie reopened this Aug 18, 2017

@tobie

This comment has been minimized.

Copy link
Member

commented Aug 18, 2017

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

@anssiko

This comment has been minimized.

Copy link
Member

commented Aug 18, 2017

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

@tobie

This comment has been minimized.

Copy link
Member

commented Aug 18, 2017

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

anssiko added a commit that referenced this issue Aug 18, 2017

Fix #23: Clarify use cases further
Note light-level media feature
@anssiko

This comment has been minimized.

Copy link
Member

commented Aug 18, 2017

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

@anssiko anssiko closed this in 90d4e3c Aug 18, 2017

anssiko added a commit that referenced this issue Aug 18, 2017

Merge pull request #34 from w3c/use-cases
Fix #23: Clarify use cases further
@tobie

This comment has been minimized.

Copy link
Member

commented Aug 18, 2017

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

@tobie tobie reopened this Aug 18, 2017

@alexshalamov

This comment has been minimized.

Copy link

commented Aug 18, 2017

@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

This comment has been minimized.

Copy link
Member

commented Aug 18, 2017

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

This comment has been minimized.

Copy link
Member

commented Aug 21, 2017

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

@anssiko anssiko closed this in 8f9b5fc Aug 21, 2017

anssiko added a commit that referenced this issue Aug 21, 2017

Merge pull request #36 from w3c/use-cases
Fix #23: Move content from Use Cases to Scope
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.