Intent to Implement: Ambient Light Events

[Bhaumik, Rijubrata]

Contact emails

rijubrat...@intel.com (eng)

anssi.ko...@intel.com (spec editor)

Spec

Candidate Recommendation:

http://www.w3.org/TR/ambient-light/ Editor's Draft:

https://dvcs.w3.org/hg/dap/raw-file/default/light/Overview.html

Summary

Implement Ambient Light Event API which is a handy way to make a web page or web app aware of any change in light intensity.

Motivation

The idea with this API is to detect light level from the surroundings and preferably adapt the user experience based on this information. Different user experiences can be created if say the user is outside in sunlight or if the user is under low light conditions like inside a car.

Compatibility Risk

This is a new API and Mozilla has already implemented and shipped it in Firefox 22.0 for Mac OS X and Firefox Mobile 15.0 for Android.

https://developer.mozilla.org/en-US/docs/WebAPI/Using_Light_Events#Browser_compatibility

Implementation details :

https://bugzilla.mozilla.org/show_bug.cgi?id=738465

I will be implementing it behind a runtime flag.

Ongoing technical constraints

None

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes. (Android and Mac implementations first)

OWP launch tracking bug?

https://code.google.com/p/chromium/issues/detail?id=336424

Link to entry on the feature dashboard

http://www.chromestatus.com/admin/features/edit/5298357018820608

Requesting approval to ship?

No.

[Dongseong Hwang]

The feature dashboard link is for edit purpose.

The right link is http://www.chromestatus.com/features/5298357018820608

If supporting Device API is Blink's direction, it's lgtm

- DS

[TAMURA, Kent]

Do you think large number of web pages will use this API?

Who wants this API?

What platforms can we support?  Does all of Android devices have ambient light sensors?

--
TAMURA Kent
Software Engineer, Google

[Kenneth Rohde Christiansen]

Car navigation systems (GPSs) etc have been using this for quite some
time for changing the UI color, so that inside of black on white you
would get white on black at night.

This is also quite useful for reading and could thus be quite useful
for web sites as well, though I suspect they want to have access to
this from CSS. I believe that is being tackled by CSS Media Queries
Level 4.

Most phones can adjust the screen brightness automatically so they
must have ambient light sensors - whether they are accessible from an
API point of view, I don't know, but they are on Mac, as I have seem
the feature demonstrated with Firefox on a MacBook Pro.

Cheers
Kenneth

> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.



--
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone +45 4294 9458 ﹆﹆﹆

[Kostiainen, Anssi]

Hi Tamura,

On 23 Jan 2014, at 09:04, TAMURA, Kent <tk...@chromium.org> wrote:

Thanks for your questions.

> Do you think large number of web pages will use this API?

With regard the high-level use cases and usage, the API may be used in a similar manner as the Device Orientation shipping in all major browsers (also IE). IOW sensory data can be used as input in various ways, for example to adapt the web content, control a game or an app.

More concretely, ambient light level could be used e.g. by a maps app (or any other app for which legibility of the web content is important) to gradually transition to the night mode when it gets darker. Or for controlling a game that reacts to the ambient light changes in the user’s surrounding and/or movement of the user. Here’s one of the creative uses of the API I stumbled upon recently (try it with Firefox on OS X or Android, or with your Firefox OS device):

http://www.francesco.iovine.name/mdn/xmas-tales/public_html/

> Who wants this API?

This capability makes the Web (and Blink) more competitive with native offerings in general. It is also aligned with the Blink’s goals to be more mobile-awesome.

The next time an app developer is about to create the Next-Awesome-App that uses a light sensor, s/he may be able to go the Web first instead of one of the native platforms.

> What platforms can we support? Does all of Android devices have ambient light sensors?

Android since API level 3 (Android 1.5), OS X 10.5+ IIRC, Windows 7+. All Android devices I’ve tried have shipped with a light sensor (if someone has accurate data on this, feel free to share).

All - let us know if you have any further questions or concerns.

Thanks,

-Anssi

[TAMURA, Kent]

Thank you for the reply.

pros:

  - This API matches our 2014 goal; 'Expose capabilities on the open-web competitive to “native” offerings'

  - The specification is a Candidate Recommendation.

  - Firefox already has it.

cons:

  - It might not help many web authors.

   I searched the web for "ambient light events," and didn't find a lot of enthusiastic desire.

  - To avoid privacy issues, we need to build some UI.

   Unfortunately, it's very hard for non-Google engineers to make new user-visible UI.

I'm slightly negative at this moment.

[Kenji Baheux]

Kent, can you explain your concerns for the privacy angle?

Thanks!

2014-01-28 TAMURA, Kent <tk...@chromium.org>

[Elliott Sprehn]

I think we should add this feature, it's already shipping in another browser and it's a capability that native apps have.

[TAMURA, Kent]

Kenji-san,

Please refer to http://www.w3.org/TR/ambient-light/#security-and-privacy-considerations

[Alex Russell]

I dislike the form of the API. It should be refactored to request a permission for this event. It's unclear why any random web page should be allowed access.q

[Philip Rogers]

Alex,

Are you worried about the privacy implications of the ambient light sensor? I'm having a hard time imagining a case where that would leak user information.

Philip

[Kostiainen, Anssi]

Hi Alex,

On 28 Jan 2014, at 02:25, Alex Russell <sligh...@google.com> wrote:

> I dislike the form of the API. It should be refactored to request a permission for this event. It's unclear why any random web page should be allowed access.q

Thanks for your feedback. The form of the API is similar to the Device Orientation shipping in all major browsers without a permission request. If the form is an issue, then I’d believe the Device Orientation should be addressed similarly for consistency.

Thanks,

-Anssi

[Kostiainen, Anssi]

Hi All,

On 28 Jan 2014, at 03:00, Philip Rogers <p...@chromium.org> wrote:

> Alex,
>
> Are you worried about the privacy implications of the ambient light sensor? I'm having a hard time imagining a case where that would leak user information.

Thank you for your comments.

I’d like to let you know the members of the W3C Privacy Interest Group have conducted an extensive review of the spec from a privacy perspective. IOW, the spec has been carefully scrutinized from that point of view.

Based on the review, the Security and privacy section in the spec was crafted as follows to inform implementers:

http://www.w3.org/TR/ambient-light/#security-and-privacy-considerations

For more details, here are the notes from the review:

http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0095.html

Thanks,

-Anssi

[Peter Beverloo]

I'm not convinced that duplicating the functionality of the ondevicelight event in a less accurate way, by means of the onlightlevel event, is the right way for mitigating the privacy concerns, especially given that the specification recommends mapping of lux ranges to the {dim, normal, bright} values.

What is the benefit of this over suggesting that UAs can decrease accuracy of the reported lux value using a logarithmic scale in a non-privileged browsing context?  The accuracy of sensors is going to deviate in either case.

Peter

[Kostiainen, Anssi]

Hi Peter,

On 28 Jan 2014, at 13:19, Peter Beverloo <pe...@chromium.org> wrote:

> I'm not convinced that duplicating the functionality of the ondevicelight event in a less accurate way, by means of the onlightlevel event, is the right way for mitigating the privacy concerns, especially given that the specification recommends mapping of lux ranges to the {dim, normal, bright} values.

Thanks for your feedback.

> What is the benefit of this over suggesting that UAs can decrease accuracy of the reported lux value using a logarithmic scale in a non-privileged browsing context? The accuracy of sensors is going to deviate in either case.

What you propose above is a very sound implementation strategy, conforming to the spec as per the following note:

[[

The definition of granularity i.e. how often the event is fired is left to the implementation.

]]

In the first phase we plan to implement the DeviceLightEvent and ondevicelight i.e. the lux value. Based on implementation experience and feedback (thanks!) we may consider not to proceed with the LightLevelEvent and onlightlevel part, i.e. the human-readable mapping to {dim, normal, bright}.

Does that address your concern?

I’m happy to take the feedback to the W3C group, and ensure that other implementers are informed.

Thanks,

-Anssi

[rijubrata bhaumik]

Hi All  + Peter,

Thanks for the responses. 

I have a CL for this feature now. 

Blink Side : 

https://codereview.chromium.org/143823004/

git diff --stat  origin/master Source/ public/platform/ 

16 files changed, 601 insertions(+), 2 deletions(-)

Chrome side + Android implementation https://codereview.chromium.org/152893002/

git diff --stat  origin/master 

39 files changed, 535 insertions(+), 30 deletions(-)

Technical debt for this feature : around 1100 LOC.

codereview shows a bit different result in the Stats column.

+Firefox already ships it.

+Makes chromium/Blink more "appy"

Demo purposes :

I used [1] and [2] with chromium_testshell on my Nexus 5.

[1] http://www.francesco.iovine.name/mdn/xmas-tales/public_html/

[2] http://www.freshtilledsoil.com/the-future-of-web/ambient-light/

Regards,

Riju.

Thanks,

-Anssi

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
- Riju

[Alex Russell]

Once again, delivery of ondevicelight events should be guarded by a request (even if we choose to enable it by default for now in Chrome). E.g.:

    navigator.requestDeviceLight().then(...);

[Kenneth Rohde Christiansen]

I am fine with this, though we might want to use allow or enable instead of request, as request seems to indicate action as it is currently used in for instance requestFullscreen.

I talked to Anssi and he seems OK with adding something like that in a Level 2 of the spec, but as this affects the whole platform, we should probably take this discussion now. Should we suggest something similar for DeviceOrientation/Motion and Geolocation - even if they would always succeed if enabled by default (like DeviceOrientation/Motion)?

Kenneth 

[Kostiainen, Anssi]

Hi,

I feel we could retrofit the request*() or similar into a Level 2 spec in this case. Implementations could then consider the operations noop and fire no events, if the request does not resolve successfully.

That said, am I hearing no concerns in enabling the feature by default now given we can retrofit?

Thanks,

-Anssi

[Adam Barth]

On Wed Mar 05 2014 at 2:28:05 AM, Kostiainen, Anssi <anssi.ko...@intel.com> wrote:

Hi,

I feel we could retrofit the request*() or similar into a Level 2 spec in this case. Implementations could then consider the operations noop and fire no events, if the request does not resolve successfully.

That said, am I hearing no concerns in enabling the feature by default now given we can retrofit?

This thread is an intent-to-implement, not an intent-to-ship.  There's a higher bar for enabling features by default than for implementing them in the first place.  We haven't discussed enabling this feature by default (shipping it) at all yet.

Adam

 

> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
>
>
>
> --
> - Riju
>
>
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Mounir Lamouri]

On Wed, 5 Mar 2014, at 10:19, Alex Russell wrote:
> Once again, delivery of ondevicelight events should be guarded by a
> request
> (even if we choose to enable it by default for now in Chrome). E.g.:
>
> navigator.requestDeviceLight().then(...);

My understanding is that listening to devicelight event would be an
implicit request. As far as the UA and the user are concerned, it will
be the same. The only difference is that the developer will not be able
to know if the request was actually granted. I think it would be
interesting to discuss a requestPermission/hasPermission pattern on the
Web and how we could make that simple and scalable. Actually, my TPAC
notes contain "Ask TAG about permissions". Should we discuss that
general issue there?

Cheers,
-- Mounir

[Alex Russell]

On Wed, Mar 5, 2014 at 1:16 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:

On Wed, 5 Mar 2014, at 10:19, Alex Russell wrote:
> Once again, delivery of ondevicelight events should be guarded by a
> request
> (even if we choose to enable it by default for now in Chrome). E.g.:
>
>     navigator.requestDeviceLight().then(...);

My understanding is that listening to devicelight event would be an
implicit request .

And I'm asking to explicitly decouple the two, for a set of reasons:

1. We want to be able to expose this sort of event to background contexts (e.g., Service Workers) where any potential permission UI might not have a corresponding foreground surface to make requests from (and would therefore fail).
2. We shouldn't be leaking fingerprintable data without consent, and while I won't fight the design point here, I want us to have a flexible enough API surface area to re-litigate it later. 

[Bhaumik, Rijubrata]

Hi Alex,

As Mounir pointed out the requestPermission/hasPermission should be applied to other related APIs also, e.g. device motion/ orientation which are status=stable now. 

How about we land this feature in this form (as per the spec) behind the experimental flag and get some feedback from web app developers. 

In the meantime, Anssi takes this permission discussion to W3C, and when there is some kind of consensus there, he changes the spec and we change the implementation. 

Does it sound like a plan ?

Cheers,

Riju.

[Eric Seidel]

Sounds like a plan. The point of Intent To Implement is to start
these discussions early. But all you need is an LGTM from any
reviewer on your patches to move forward. You don't need a stamp from
the API OWNERS until you're actually shipping. Feel encouraged to
implement behind a flag and iterate!

[Alex Russell]

Sounds good.

[Ilya Bogdanovich]

Hi all,

I’m just wondering, are you going to implement also CSS properties for ambient light levels with this intent? http://dev.w3.org/csswg/mediaqueries4/#light-level

We from Yandex, also would like to see this feature in Blink and could probably help you with implementation.

Ilya

[Kostiainen, Anssi]

Hi Ilya, All,

Riju is planning to do that, and will send a separate Intent to Implement for the light-level media feature. The feature is defined in the Media Queries Level 4, currently a First Public Working Draft [1]:

http://dev.w3.org/csswg/mediaqueries4/#light-level

Furthermore, we’re in process of changing the Ambient Light Events spec accordingly to ensure there’s no overlap with the light-level media feature:

http://lists.w3.org/Archives/Public/public-device-apis/2014May/0074.html

Thanks,

-Anssi

[1] First Public Working Draft was supposed to be published yesterday 2014-06-03, but the timestamped /TR link currently gives 404. I’ve asked the CSS WG to clarify the status: http://lists.w3.org/Archives/Public/www-style/2014Jun/0026.html