Re: Ambient Light Sensor API

Did we make a decision here? If not, what are we missing to make one? On Fri, Apr 28, 2017 at 1:55 PM, Anne van Kesteren wrote: > On Fri, Apr 28, 2017 at 7:10 PM, Eric Rescorla wrote: > > Rather, the policy is > > that we will move to requiring all new features to have HTTPS [0]. > > We should

Re: Ambient Light Sensor API

On Fri, Apr 28, 2017 at 7:10 PM, Eric Rescorla wrote: > Rather, the policy is > that we will move to requiring all new features to have HTTPS [0]. We should probably discuss that again at some point, since it's not meaningfully enforced and I don't think it has consensus within Mozilla either. It

Re: Ambient Light Sensor API

On Thu, Apr 27, 2017 at 11:02 PM, Frederik Braun wrote: > On 28.04.2017 05:56, Ehsan Akhgari wrote: > > On 04/27/2017 08:09 AM, Frederik Braun wrote: > >> On 27.04.2017 13:56, smaug wrote: > >>> On 04/25/2017 04:38 PM, Ehsan Akhgari wrote: > On 04/24/2017 06:04 PM, Martin Thomson wrote: > >>

Re: Ambient Light Sensor API

>>>> As mentioned a permission prompt isn't great. >>>>>>> >>>>>>> In it's current state it should probably be considered a "powerful >>>>>>> feature" that we can remove just for

Re: Ambient Light Sensor API

On Fri, Apr 28, 2017 at 1:56 PM, Ehsan Akhgari wrote: >> While it does not address the attack, it should be limited to secure >> context, if we keep the API. It's actually in the spec. > > Why is that an advantage? Any attacker can use a secure context. The word > "secure" here relates to the sec

Re: Ambient Light Sensor API

ts? On 24.04.2017 15:24, Frederik Braun wrote: Hi, there is a relatively recent blog post [1] by Lukasz Olejnik and Artur Janc that explains how one can steal sensitive data using the Ambient Light Sensor API [2]. We ship API and its enabled by default [3,4] and it seems we have no telemetry

Re: Ambient Light Sensor API

On Thu, Apr 27, 2017 at 8:42 AM, Salvador de la Puente wrote: > Well, I'm not saying "don't fix it" but if we switch the API off then > other-than-evil ways of using the API will never happen and, as Belen said > before, it undermines the confidence on the Web platform. I'd think that leaving the

Re: Ambient Light Sensor API

Sensor >>>>> API is >>>>> the security model which requires: https://www.w3.org/TR/generic- >>>>> sensor/#secure-context I can't see that as a restriction in our >>>>> codebase >>>>> though? >&

Re: Ambient Light Sensor API

Braun wrote: Hi, there is a relatively recent blog post [1] by Lukasz Olejnik and Artur Janc that explains how one can steal sensitive data using the Ambient Light Sensor API [2]. We ship API and its enabled by default [3,4] and it seems we have no telemetry for this feature. Unshipping for no

Re: Ambient Light Sensor API

Well, I'm not saying "don't fix it" but if we switch the API off then other-than-evil ways of using the API will never happen and, as Belen said before, it undermines the confidence on the Web platform. I can not foresee the canonical use of the API that would support the decision of not switching

Re: Ambient Light Sensor API

On 04/26/2017 11:36 AM, Salvador de la Puente wrote: Right, I did not remember that request to victim.com originated in tags inside evil.com went to the network with victim.com credentials so clients can reach more than servers. That's

Re: Ambient Light Sensor API

Which, from my perspective, is justification to disable reading the sensor until it can be implemented in a way that prevents the cross-origin stealing attack. Users shouldn't have to worry about this. Haik On Wed, Apr 26, 2017 at 8:28 AM, Ehsan Akhgari wrote: > On 04/25/2017 08:26 PM, Salvador

Re: Ambient Light Sensor API

Right, I did not remember that request to victim.com originated in tags inside evil.com went to the network with victim.com credentials so clients can reach more than servers. That's fine. Anyway, with only that use of the APIs, is it not a little bit early to say that every possible usage will b

Re: Ambient Light Sensor API

On 04/25/2017 08:26 PM, Salvador de la Puente wrote: So the risk is not that high since if the image is not protected I can get it and do evil things without requiring the Light Sensor API. Isn't it? No, the risk is extremely high. Here is a concrete example. Some banks give their users scan

Re: Ambient Light Sensor API

On Wed, Apr 26, 2017 at 10:26 PM, Eric Rescorla wrote: >> Surely we can avoid this problem without being so >> drastic? > > > Perhaps, but actually designing such security measures is expensive, so > absent some argument that this is in wide use, probably doesn't > pass a cost/benefit test. Yeah,

Re: Ambient Light Sensor API

Auth related images are the attack vector, that and history attacks on same domain. On Tue, Apr 25, 2017 at 11:17 PM, Salvador de la Puente < sdelapue...@mozilla.com> wrote: > Sorry for my ignorance but, in the case of Stealing cross-origin resources, > I don't get the point of the attack. If hav

Re: Ambient Light Sensor API

On Wed, Apr 26, 2017 at 2:01 AM, Gervase Markham wrote: > On 25/04/17 16:46, Eric Rescorla wrote: > > This suggests that maybe we could just turn it off > > It would be sad to remove a capability from the web platform which > native apps have. I'm not sure why it would be particularly sad if al

Re: Ambient Light Sensor API

] by Lukasz Olejnik and Artur > Janc that explains how one can steal sensitive data using the Ambient > Light Sensor API [2]. > > We ship API and its enabled by default [3,4] and it seems we have no > telemetry for this feature. > > > Unshipping for non-secure context a

Re: Ambient Light Sensor API

On 2017-04-26 11:01, Gervase Markham wrote: On 25/04/17 16:46, Eric Rescorla wrote: This suggests that maybe we could just turn it off It would be sad to remove a capability from the web platform which native apps have. Surely we can avoid this problem without being so drastic? Is it right tha

Re: Ambient Light Sensor API

On 25/04/17 16:46, Eric Rescorla wrote: > This suggests that maybe we could just turn it off It would be sad to remove a capability from the web platform which native apps have. Surely we can avoid this problem without being so drastic? Is it right that one key use of this sensor is to see if the

Re: Ambient Light Sensor API

On Tue, Apr 25, 2017 at 5:26 PM, Salvador de la Puente < sdelapue...@mozilla.com> wrote: > So the risk is not that high since if the image is not protected I can get > it and do evil things without requiring the Light Sensor API. Isn't it? > Generally, we take cross-origin information theft prett

Re: Ambient Light Sensor API

So the risk is not that high since if the image is not protected I can get it and do evil things without requiring the Light Sensor API. Isn't it? On Wed, Apr 26, 2017 at 1:30 AM, Eric Rescorla wrote: > > > On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente < > sdelapue...@mozilla.com> wrote

Re: Ambient Light Sensor API

On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente < sdelapue...@mozilla.com> wrote: > The article says: > > Embed an image from the attacked domain; generally this will be a resource > > which varies for different authenticated users such as the logged-in > user’s > > avatar or a security cod

Re: Ambient Light Sensor API

The article says: Embed an image from the attacked domain; generally this will be a resource > which varies for different authenticated users such as the logged-in user’s > avatar or a security code. > And then refers all the steps to this image (binarizing, expand and measure per pixel) but, If

Re: Ambient Light Sensor API

Sorry for my ignorance but, in the case of Stealing cross-origin resources, I don't get the point of the attack. If have the ability to embed the image in step 1, why to not simply send this to evil.com for further processing? How it is possible for evil.com to get access to protected resources? O

Re: Ambient Light Sensor API

On 04/25/2017 10:25 AM, Andrew Overholt wrote: On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote: Going back to Jonathan's (I think) question. Does anyone use this at all in the field? Chrome's usage metrics say <= 0.0001% of page loads: https://www.chromestatus.com/metrics/feature/popula

Re: Ambient Light Sensor API

CSS may implement a 3 state light level for most use cases of this metric, I would suggest that would be much better. According to the removal bug I raised, it looks like the spec has vastly changed anyway: https://bugzilla.mozilla.org/show_bug.cgi?id=1359076#c7 I have a patch ready to measure al

Re: Ambient Light Sensor API

Those stats aren't the old version of the spec, Google is pushing this constructor version however the old version as mentioned in the issues is event driven. We perhaps remove safely for insecure based on previous comments though. On Tue, Apr 25, 2017 at 4:46 PM, Eric Rescorla wrote: > This su

Re: Ambient Light Sensor API

This suggests that maybe we could just turn it off On Tue, Apr 25, 2017 at 7:25 AM, Andrew Overholt wrote: > On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote: > >> Going back to Jonathan's (I think) question. Does anyone use this at all >> in >> the field? >> > > Chrome's usage metrics say

Re: Ambient Light Sensor API

On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote: > Going back to Jonathan's (I think) question. Does anyone use this at all in > the field? > Chrome's usage metrics say <= 0.0001% of page loads: https://www.chromestatus.com/metrics/feature/popularity#AmbientLightSensorConstructor. We are go

Re: Ambient Light Sensor API

, there is a relatively recent blog post [1] by Lukasz Olejnik and Artur Janc that explains how one can steal sensitive data using the Ambient Light Sensor API [2]. We ship API and its enabled by default [3,4] and it seems we have no telemetry for this feature. Unshipping for non-secure context and

Re: Ambient Light Sensor API

Going back to Jonathan's (I think) question. Does anyone use this at all in the field? -Ekr On Tue, Apr 25, 2017 at 6:10 AM, Kurt Roeckx wrote: > On 2017-04-25 00:04, Martin Thomson wrote: > > I think that 60Hz is too high a rate for this. > > > > I suggest that we restrict this to top-level,

Re: Ambient Light Sensor API

On 2017-04-25 00:04, Martin Thomson wrote: > I think that 60Hz is too high a rate for this. > > I suggest that we restrict this to top-level, foreground, and secure > contexts. Note that foreground is a necessary precondition for the > attack, so that restriction doesn't really help here. Critic

Re: Ambient Light Sensor API

thin a secure context. >>> >>> >>> Would we require telemetry before we restricted this to secure contexts? >>> >>> >>> >>> On 24.04.2017 15:24, Frederik Braun wrote: >>> > Hi, >>> > >>> > there is a

Re: Ambient Light Sensor API

n >> specifications must only be available within a secure context. >> >> >> Would we require telemetry before we restricted this to secure contexts? >> >> >> >> On 24.04.2017 15:24, Frederik Braun wrote: >> > Hi, >> > >> >

Re: Ambient Light Sensor API

we require telemetry before we restricted this to secure contexts? > > > > On 24.04.2017 15:24, Frederik Braun wrote: > > Hi, > > > > there is a relatively recent blog post [1] by Lukasz Olejnik and Artur > > Janc that explains how one can steal sensitive data us

Re: Ambient Light Sensor API

ted this to secure contexts? On 24.04.2017 15:24, Frederik Braun wrote: > Hi, > > there is a relatively recent blog post [1] by Lukasz Olejnik and Artur > Janc that explains how one can steal sensitive data using the Ambient > Light Sensor API [2]. > > We ship API and its enab

Re: Ambient Light Sensor API

> > > > > [1] > https://blog.lukaszolejnik.com/stealing-sensitive- > browser-data-with-the-w3c-ambient-light-sensor-api/ > [2] https://www.w3.org/TR/ambient-light/ > [3] It is behind the dom.sensors.enabled (sic!) flag. > [4] > http://searchfox.org/mozilla-central/so

Ambient Light Sensor API

Hi, there is a relatively recent blog post [1] by Lukasz Olejnik and Artur Janc that explains how one can steal sensitive data using the Ambient Light Sensor API [2]. We ship API and its enabled by default [3,4] and it seems we have no telemetry for this feature. Unshipping for non-secure