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

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: > I think that 60Hz is too high a rate for this. > > I sugge

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

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: I think that 60Hz is too high a rate for this. I suggest that we restrict this to top-level, foreground, and secure contex

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

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: >>> 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

Re: Ambient Light Sensor API

On 04/25/2017 04:38 PM, Ehsan Akhgari wrote: On 04/24/2017 06:04 PM, 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 rest

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

Hi all, I understand that the privacy of users is paramount, but please let's try to find a solution to mitigate the effect instead of "just switching it off". Switching an API off that previously worked is bad for the Web as a whole, not just for the (small) percentage of sites using that API.

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

On 04/24/2017 06:04 PM, 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. Critically,

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

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. Critically, rate limit access much more than the 60Hz recom

Re: Ambient Light Sensor API

As a follow up, it looks like the device motion events defined in the device sensors: http://searchfox.org/mozilla-central/source/dom/system/nsDeviceSensors.cp should also be restricting based on isSecureContext. The spec mentions "should take into consideration the following suggestions" : https:

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 secure context. Granted this doesn't fix the exploit mentioned here though. Freddy highlighted that the spec itself suggests the Generic Sensor API

Re: Ambient Light Sensor API

The Ambient Light spec defers its security and privacy considerations to the generic sensors specification, which states > all interfaces defined by this specification or extension specifications must only be available within a secure context. Would we require telemetry before we restricted this

Re: Ambient Light Sensor API

The post suggests that limiting precision would mitigate the issue. We could do that immediately while we wait for telemetry to roll in. The post says reducing the frequency of the readings would not be very effective, but maybe we should reduce the frequency anyway? Possibly firing an event eve