Ambient Light Sensor API

[Frederik Braun]

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 context and making it HTTPS-only wouldn't
address the attack.

The API as implemented is using the 'devicelight' event on window.
I suppose one might also be able to implement a prompt for this, but
that doesn't sound very appealing (prompt fatigue, etc., etc.).


What do people think we should do about this?



Cheers,
Freddy





[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/source/dom/system/nsDeviceSensors.cpp

[Ben Kelly]

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 every 100ms to 200ms to report on light conditions seems
rather bad for perf/battery.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Frederik Braun]

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 to secure contexts?

[Jonathan Kingston]

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://www.w3.org/TR/orientation-event/#security-and-privacy

We don't do those measures from what I can see.

Can we make the webIDL represent this requirement for requiring secure
context instead?

Thanks
Jonathan

On Mon, Apr 24, 2017 at 2:41 PM, Jonathan Kingston <j...@mozilla.com> wrote:

> 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 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?
>
> This looks like a specification violation here.
>
> Thanks
> Jonathan

[Jonathan Kingston]

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 is
the security model which requires:

https://www.w3.org/TR/generic-sensor/#secure-context I can't see that as a

[Martin Thomson]

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 recommended for the
accelerometer. 5Hz might be sufficient here, maybe even lower.

Since the amount of information that can be extracted is a function of
the number of times the API is called and the accuracy of the reading,
we should consider also reducing the accuracy of the reading. The
attack reduced its information extraction to 1 bit per reading, but
you can't assume that this is the actual limit. Fuzzing is much
harder than it seems if your intent is to deal with an attack. I can
walk through some strategies if someone is interested in doing this.

That all assumes that you aren't willing to add a dialog for this,
which seems like the right answer. That said, if the mitigation
strategies - rate limiting in particular - can't be implemented in a
reasonable time-frame, I would consider preffing this off (though the
pref name suggests that there would be collateral).

On Tue, Apr 25, 2017 at 12:06 AM, Jonathan Kingston <j...@mozilla.com> wrote:
> 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://www.w3.org/TR/orientation-event/#security-and-privacy
>
> We don't do those measures from what I can see.
>
> Can we make the webIDL represent this requirement for requiring secure
> context instead?
>

> Thanks
> Jonathan
>

> On Mon, Apr 24, 2017 at 2:41 PM, Jonathan Kingston <j...@mozilla.com> wrote:
>

[Kurt Roeckx]

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. Critically,
> rate limit access much more than the 60Hz recommended for the
> accelerometer. 5Hz might be sufficient here, maybe even lower.

Note that they already talk about 2Hz being the rate they think is
realistic to do their attack, and that 5Hz is probably an upper bound of
their attack, so reducing it from 60 to 5 doesn't actually change
anything and you would need to go even lower. You could for instance do
something like only allowing it 1 time per minute, and require user
approval for higher frequencies.

The other suggestion they have in their paper is to reduce the number of
values you return, say 4 different values.


Kurt

[Eric Rescorla]

Going back to Jonathan's (I think) question. Does anyone use this at all in
the field?

-Ekr

[Ehsan Akhgari]

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,
> rate limit access much more than the 60Hz recommended for the
> accelerometer. 5Hz might be sufficient here, maybe even lower.

How does restricting this to secure contexts help? If I understand
correctly the attacks being discussed in the article referenced here are
stealing cross origin data and user's history. These aren't things that
we can expose to secure contexts any more than we can expose to insecure
contexts.

> Since the amount of information that can be extracted is a function of
> the number of times the API is called and the accuracy of the reading,
> we should consider also reducing the accuracy of the reading. The
> attack reduced its information extraction to 1 bit per reading, but
> you can't assume that this is the actual limit. Fuzzing is much
> harder than it seems if your intent is to deal with an attack. I can
> walk through some strategies if someone is interested in doing this.
>
> That all assumes that you aren't willing to add a dialog for this,
> which seems like the right answer. That said, if the mitigation
> strategies - rate limiting in particular - can't be implemented in a
> reasonable time-frame, I would consider preffing this off (though the
> pref name suggests that there would be collateral).

It seems hard to explain the risks of granting this permission to a site
to a user correctly. :-/ A permission prompt that doesn't allow us do
that isn't very useful. Also given that the API is an event handler, it
doesn't really lend itself to a permission prompt anyway.

But also given the event handler nature of the API, not dispatching the
event makes it very unlikely to break pages, unless if the page's
functionality explicitly depends on the ambient light, I think, which
works in our favor if we decide in that direction. I think I'm leaning
in that way personally rather than coming up with a complicated
heuristic here and potentially getting it wrong.

[Andrew Overholt]

On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla <e...@rtfm.com> 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 going to collect telemetry in
https://bugzilla.mozilla.org/show_bug.cgi?id=1359124.

[Eric Rescorla]

This suggests that maybe we could just turn it off

On Tue, Apr 25, 2017 at 7:25 AM, Andrew Overholt <over...@mozilla.com>
wrote:

[Jonathan Kingston]

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 all usages of the Generic Sensors from the
light sensors to orientation:
https://bugzilla.mozilla.org/show_bug.cgi?id=1359124

I would suggest we should check how often these are moved, but also move to
remove them when it makes sense to over insecure context.
If our implementations don't match what Google is pushing in it's origin
trial it may make sense to remove them anyway assuming there won't be much
breakage.

Thanks
Jonathan

On Tue, Apr 25, 2017 at 2:35 PM, Eric Rescorla <e...@rtfm.com> wrote:

> 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 <ku...@roeckx.be> wrote:
>

[Jonathan Kingston]

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 <e...@rtfm.com> wrote:

> This suggests that maybe we could just turn it off
>
> On Tue, Apr 25, 2017 at 7:25 AM, Andrew Overholt <over...@mozilla.com>
> wrote:
>

> > On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla <e...@rtfm.com> 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 going to collect telemetry in
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1359124.
> >

[Ehsan Akhgari]

On 04/25/2017 10:25 AM, Andrew Overholt wrote:
> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla <e...@rtfm.com> 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.

This is the new version of the spec which we don't ship.

> We are going to collect telemetry in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1359124.

[Salvador de la Puente]

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?

On Tue, Apr 25, 2017 at 8:04 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

> On 04/25/2017 10:25 AM, Andrew Overholt wrote:
>
>> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla <e...@rtfm.com> 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#Ambi
>> entLightSensorConstructor.
>>
>
> This is the new version of the spec which we don't ship.
>
>
> We are going to collect telemetry in
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1359124.

>> _______________________________________________
>> dev-platform mailing list
>> dev-pl...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

--
<salva />

[Salvador de la Puente]

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 I can embed that image, it is because I know the URL for
it and the proper auth tokens if it is protected. In that case, why to not
simply steal the image?

On Wed, Apr 26, 2017 at 12:23 AM, Jonathan Kingston <j...@mozilla.com> wrote:

> 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 <
> sdela...@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 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?
>>
>> On Tue, Apr 25, 2017 at 8:04 PM, Ehsan Akhgari <ehsan....@gmail.com>
>> wrote:
>>
>> > On 04/25/2017 10:25 AM, Andrew Overholt wrote:
>> >
>> >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla <e...@rtfm.com> 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#Ambi
>> >> entLightSensorConstructor.
>> >>
>> >
>> > This is the new version of the spec which we don't ship.
>> >
>> >
>> > We are going to collect telemetry in
>> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1359124.

>> >> _______________________________________________
>> >> dev-platform mailing list
>> >> dev-pl...@lists.mozilla.org
>> >> https://lists.mozilla.org/listinfo/dev-platform
>> >>
>> >
>> > _______________________________________________
>> > dev-platform mailing list
>> > dev-pl...@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> >
>>
>>
>>

>> --
>> <salva />

>> _______________________________________________
>> dev-platform mailing list
>> dev-pl...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>

--
<salva />

[Eric Rescorla]

On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente <
sdela...@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 code.
> >
>
> And then refers all the steps to this image (binarizing, expand and measure
> per pixel) but, If I can embed that image, it is because I know the URL for
> it and the proper auth tokens if it is protected. In that case, why to not
> simply steal the image?
>

The simple version of this is that the image is cookie protected.

-Ekr

> >> >> _______________________________________________
> >> >> dev-platform mailing list
> >> >> dev-pl...@lists.mozilla.org
> >> >> https://lists.mozilla.org/listinfo/dev-platform
> >> >>
> >> >
> >> > _______________________________________________
> >> > dev-platform mailing list
> >> > dev-pl...@lists.mozilla.org
> >> > https://lists.mozilla.org/listinfo/dev-platform
> >> >
> >>
> >>
> >>

> >> --
> >> <salva />

> >> _______________________________________________
> >> dev-platform mailing list
> >> dev-pl...@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
> >
> >
>
>

> --
> <salva />

[Salvador de la Puente]

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 <e...@rtfm.com> wrote:

>
>
> On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente <
> sdela...@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 code.
>> >
>>
>> And then refers all the steps to this image (binarizing, expand and
>> measure
>> per pixel) but, If I can embed that image, it is because I know the URL
>> for
>> it and the proper auth tokens if it is protected. In that case, why to not
>> simply steal the image?
>>
>
> The simple version of this is that the image is cookie protected.
>
> -Ekr
>
>

>> >> >> _______________________________________________
>> >> >> dev-platform mailing list
>> >> >> dev-pl...@lists.mozilla.org
>> >> >> https://lists.mozilla.org/listinfo/dev-platform
>> >> >>
>> >> >
>> >> > _______________________________________________
>> >> > dev-platform mailing list
>> >> > dev-pl...@lists.mozilla.org
>> >> > https://lists.mozilla.org/listinfo/dev-platform
>> >> >
>> >>
>> >>
>> >>

>> >> --
>> >> <salva />

>> >> _______________________________________________
>> >> dev-platform mailing list
>> >> dev-pl...@lists.mozilla.org
>> >> https://lists.mozilla.org/listinfo/dev-platform
>> >>
>> >
>> >
>>
>>

>> --
>> <salva />

>> _______________________________________________
>> dev-platform mailing list
>> dev-pl...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>

--
<salva />

[Eric Rescorla]

On Tue, Apr 25, 2017 at 5:26 PM, Salvador de la Puente <
sdela...@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 pretty seriously.

-Ekr

> On Wed, Apr 26, 2017 at 1:30 AM, Eric Rescorla <e...@rtfm.com> wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente <
>> sdela...@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 code.
>>> >
>>>
>>> And then refers all the steps to this image (binarizing, expand and
>>> measure
>>> per pixel) but, If I can embed that image, it is because I know the URL
>>> for
>>> it and the proper auth tokens if it is protected. In that case, why to
>>> not
>>> simply steal the image?
>>>
>>
>> The simple version of this is that the image is cookie protected.
>>
>> -Ekr
>>
>>

>>> >> >> _______________________________________________
>>> >> >> dev-platform mailing list
>>> >> >> dev-pl...@lists.mozilla.org
>>> >> >> https://lists.mozilla.org/listinfo/dev-platform
>>> >> >>
>>> >> >
>>> >> > _______________________________________________
>>> >> > dev-platform mailing list
>>> >> > dev-pl...@lists.mozilla.org
>>> >> > https://lists.mozilla.org/listinfo/dev-platform
>>> >> >
>>> >>
>>> >>
>>> >>

>>> >> --
>>> >> <salva />

>>> >> _______________________________________________
>>> >> dev-platform mailing list
>>> >> dev-pl...@lists.mozilla.org
>>> >> https://lists.mozilla.org/listinfo/dev-platform
>>> >>
>>> >
>>> >
>>>
>>>

>>> --
>>> <salva />

>>> _______________________________________________
>>> dev-platform mailing list
>>> dev-pl...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
>
>

> --
> <salva />
>

[Gervase Markham]

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
person has the phone up against their face, right? If so, reducing to a
small number of quantized levels would do the trick.

Gerv

[Kurt Roeckx]

As far as I know that's a different sensor which actually measures the
proximity, not the light level, and usually just has 2 values.

I have no idea what the light sensor would all be used for. One of the
few things I can think about is that you change the color theme like a
GPS does for day and night settings, which does not require a lot of
different levels.


Kurt

[Belén Albeza]

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.

One of the big pillars of the Web is that is resilient. There's an implicit promise that something that you develop today will continue to work in two decades. This is a huge advantage over native apps, this is what a web developer expects, and breaking this promise could be dangerous and should be the last option.

If there is a way to mitigate the risks of the attack IMO we should try that instead of removing the API.

Cheers,
Belén

[Eric Rescorla]

On Wed, Apr 26, 2017 at 2:01 AM, Gervase Markham <ge...@mozilla.org> 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 almost nobody uses it.

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.

-Ekr

> Is it right that one key use of this sensor is to see if the
> person has the phone up against their face, right? If so, reducing to a
> small number of quantized levels would do the trick.
>
> Gerv

[Jonathan Kingston]

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 <
sdela...@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 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?
>
> On Tue, Apr 25, 2017 at 8:04 PM, Ehsan Akhgari <ehsan....@gmail.com>
> wrote:
>
> > On 04/25/2017 10:25 AM, Andrew Overholt wrote:
> >
> >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla <e...@rtfm.com> 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#Ambi
> >> entLightSensorConstructor.
> >>
> >
> > This is the new version of the spec which we don't ship.
> >
> >
> > We are going to collect telemetry in
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1359124.

> >> _______________________________________________
> >> dev-platform mailing list
> >> dev-pl...@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
> >
> > _______________________________________________
> > dev-platform mailing list
> > dev-pl...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
>
>
>

> --
> <salva />

[Martin Thomson]

On Wed, Apr 26, 2017 at 10:26 PM, Eric Rescorla <e...@rtfm.com> 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, after looking at the papers here, this doesn't look salvagable.
Other ways of accessing cross-origin data are all gated behind
permissions. Given that this is in effect a camera with low
resolution and framerate, and also a screen capture device, that's the
bar the API has to meet.

Combined with low usage rates, (lower than battery status?), this
seems pretty clear-cut to me.

[Ehsan Akhgari]

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 scanned copies
of their cheques (including secret financial information) as cookie
protected images. Browsers already have protections in place that
prevent cross-origin pages from reading the pixel values of these images
by tainting such images and remembering that an image is coming from
such a source and preventing the contents of such a tainted image to be
read out through an API that gives you access to raw pixel values.
Merely uploading the URL of such an image to the evil.com server doesn't
help the attacker since they won't have access to the user's credentials
on the server side. The attack vector being discussed here introduces a
new vulnerability vector for websites to try to steal sensitive
information like this in ways that currently isn't possible.

>
> On Wed, Apr 26, 2017 at 1:30 AM, Eric Rescorla <e...@rtfm.com

> <mailto:e...@rtfm.com>> wrote:

>
>
>
> On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente
> <sdela...@mozilla.com <mailto:sdela...@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 code.
> >
>
> And then refers all the steps to this image (binarizing,
> expand and measure
> per pixel) but, If I can embed that image, it is because I
> know the URL for
> it and the proper auth tokens if it is protected. In that
> case, why to not
> simply steal the image?
>
>
> The simple version of this is that the image is cookie protected.
>
> -Ekr
>
>
> On Wed, Apr 26, 2017 at 12:23 AM, Jonathan Kingston

> <j...@mozilla.com <mailto:j...@mozilla.com>> wrote:
>
> > 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 <
> > sdela...@mozilla.com <mailto:sdela...@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 have the ability to
> embed the
> >> image
> >> in step 1, why to not simply send this to evil.com

> <http://evil.com> for further
> >> processing?
> >> How it is possible for evil.com <http://evil.com> to get

> access to protected resources?
> >>
> >> On Tue, Apr 25, 2017 at 8:04 PM, Ehsan Akhgari

> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>>

> >> wrote:
> >>
> >> > On 04/25/2017 10:25 AM, Andrew Overholt wrote:
> >> >
> >> >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla
> <e...@rtfm.com <mailto:e...@rtfm.com>> 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#Ambi
> <https://www.chromestatus.com/metrics/feature/popularity#Ambi>
> >> >> entLightSensorConstructor.
> >> >>
> >> >
> >> > This is the new version of the spec which we don't ship.
> >> >
> >> >
> >> > We are going to collect telemetry in
> >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1359124

> <https://bugzilla.mozilla.org/show_bug.cgi?id=1359124>.

> >> >> _______________________________________________
> >> >> dev-platform mailing list
> >> >> dev-pl...@lists.mozilla.org

> <mailto:dev-pl...@lists.mozilla.org>
> >> >> https://lists.mozilla.org/listinfo/dev-platform

> <https://lists.mozilla.org/listinfo/dev-platform>
> >> >>
> >> >
> >> > _______________________________________________
> >> > dev-platform mailing list
> >> > dev-pl...@lists.mozilla.org

> <mailto:dev-pl...@lists.mozilla.org>
> >> > https://lists.mozilla.org/listinfo/dev-platform

> <https://lists.mozilla.org/listinfo/dev-platform>
> >> >
> >>
> >>
> >>
> >> --
> >> <salva />

> >> _______________________________________________
> >> dev-platform mailing list
> >> dev-pl...@lists.mozilla.org

> <mailto:dev-pl...@lists.mozilla.org>
> >> https://lists.mozilla.org/listinfo/dev-platform

> <https://lists.mozilla.org/listinfo/dev-platform>
> >>
> >
> >
>
>
> --
> <salva />

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org

> <mailto:dev-pl...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-platform

[Salvador de la Puente]

Right, I did not remember that request to victim.com originated in <img>
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 be harmful? Do we have any way to measure
the traffic of the web properties using this API?

On Wed, Apr 26, 2017 at 5:28 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

>> >> >> _______________________________________________
>> >> >> dev-platform mailing list
>> >> >> dev-pl...@lists.mozilla.org

>> <mailto:dev-pl...@lists.mozilla.org>
>> >> >> https://lists.mozilla.org/listinfo/dev-platform

>> <https://lists.mozilla.org/listinfo/dev-platform>
>> >> >>
>> >> >
>> >> > _______________________________________________
>> >> > dev-platform mailing list
>> >> > dev-pl...@lists.mozilla.org

>> <mailto:dev-pl...@lists.mozilla.org>
>> >> > https://lists.mozilla.org/listinfo/dev-platform
>> <https://lists.mozilla.org/listinfo/dev-platform>
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> <salva />

>> >> _______________________________________________
>> >> dev-platform mailing list
>> >> dev-pl...@lists.mozilla.org

>> <mailto:dev-pl...@lists.mozilla.org>
>> >> https://lists.mozilla.org/listinfo/dev-platform
>> <https://lists.mozilla.org/listinfo/dev-platform>
>> >>
>> >
>> >
>>
>>
>> --
>> <salva />

>> _______________________________________________
>> dev-platform mailing list
>> dev-pl...@lists.mozilla.org

>> <mailto:dev-pl...@lists.mozilla.org>
>> https://lists.mozilla.org/listinfo/dev-platform
>> <https://lists.mozilla.org/listinfo/dev-platform>
>>
>>
>>
>>
>>
>> --
>> <salva />
>>
>
>

--
<salva />

[Haik Aftandilian]

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 <ehsan....@gmail.com>

>> >> >> _______________________________________________
>> >> >> dev-platform mailing list
>> >> >> dev-pl...@lists.mozilla.org

>> <mailto:dev-pl...@lists.mozilla.org>
>> >> >> https://lists.mozilla.org/listinfo/dev-platform

>> <https://lists.mozilla.org/listinfo/dev-platform>
>> >> >>
>> >> >
>> >> > _______________________________________________
>> >> > dev-platform mailing list
>> >> > dev-pl...@lists.mozilla.org

>> <mailto:dev-pl...@lists.mozilla.org>
>> >> > https://lists.mozilla.org/listinfo/dev-platform
>> <https://lists.mozilla.org/listinfo/dev-platform>
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> <salva />

>> >> _______________________________________________
>> >> dev-platform mailing list
>> >> dev-pl...@lists.mozilla.org

>> <mailto:dev-pl...@lists.mozilla.org>
>> >> https://lists.mozilla.org/listinfo/dev-platform
>> <https://lists.mozilla.org/listinfo/dev-platform>
>> >>
>> >
>> >
>>
>>
>> --
>> <salva />

>> _______________________________________________
>> dev-platform mailing list
>> dev-pl...@lists.mozilla.org

>> <mailto:dev-pl...@lists.mozilla.org>
>> https://lists.mozilla.org/listinfo/dev-platform
>> <https://lists.mozilla.org/listinfo/dev-platform>
>>
>>
>>
>>
>>
>> --
>> <salva />
>>
>

[Ehsan Akhgari]

On 04/26/2017 11:36 AM, Salvador de la Puente wrote:
> Right, I did not remember that request to victim.com

> <http://victim.com> originated in <img> tags inside evil.com
> <http://evil.com> went to the network with victim.com
> <http://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 be harmful?

Nobody is saying that every usage of the API is harmful. But the
browser engine doesn't have a way to read the mind of the author of the
page to figure out why a certain API is being used. When APIs expose
risks like this we need some kind of mitigation. Rate limits are one
approach, but it's hard to get right and it's hard to demonstrate its
effectiveness given the existence of wakelock APIs as described in the
article.

Also please note that typically Web APIs aren't designed based on the
assumption that most of the consumers use them in a non-malicious way,
quite the contrary -- we usually assume an untrusted caller because we
can't know much about the intentions of the caller, and our users can't
be expected to make security decisions before visiting a website.

> Do we have any way to measure the traffic of the web properties using
> this API?

That has no bearing on the security aspect of this. And no, we don't.
At best we can add some telemetry for the number of sessions that have
an event handler for this or some such which bug 1359124 was filed for.

>
> On Wed, Apr 26, 2017 at 5:28 PM, Ehsan Akhgari
> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>> wrote:
>
> 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 scanned
> copies of their cheques (including secret financial information)
> as cookie protected images. Browsers already have protections in
> place that prevent cross-origin pages from reading the pixel
> values of these images by tainting such images and remembering
> that an image is coming from such a source and preventing the
> contents of such a tainted image to be read out through an API
> that gives you access to raw pixel values. Merely uploading the

> URL of such an image to the evil.com <http://evil.com> server

> doesn't help the attacker since they won't have access to the
> user's credentials on the server side. The attack vector being
> discussed here introduces a new vulnerability vector for websites
> to try to steal sensitive information like this in ways that
> currently isn't possible.
>
>
> On Wed, Apr 26, 2017 at 1:30 AM, Eric Rescorla <e...@rtfm.com

> <mailto:e...@rtfm.com> <mailto:e...@rtfm.com

> <mailto:e...@rtfm.com>>> wrote:
>
>
>
> On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente
> <sdela...@mozilla.com <mailto:sdela...@mozilla.com>

> <mailto:sdela...@mozilla.com

> <mailto:sdela...@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 code.
> >
>
> And then refers all the steps to this image (binarizing,
> expand and measure
> per pixel) but, If I can embed that image, it is because I
> know the URL for
> it and the proper auth tokens if it is protected. In that
> case, why to not
> simply steal the image?
>
>
> The simple version of this is that the image is cookie
> protected.
>
> -Ekr
>
>
> On Wed, Apr 26, 2017 at 12:23 AM, Jonathan Kingston
> <j...@mozilla.com <mailto:j...@mozilla.com>

> <mailto:j...@mozilla.com <mailto:j...@mozilla.com>>> wrote:
>
> > 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 <
> > sdela...@mozilla.com
> <mailto:sdela...@mozilla.com>

> <mailto:sdela...@mozilla.com

> <mailto:sdela...@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 have the
> ability to
> embed the
> >> image
> >> in step 1, why to not simply send this to evil.com
> <http://evil.com>
> <http://evil.com> for further
> >> processing?
> >> How it is possible for evil.com <http://evil.com>
> <http://evil.com> to get
> access to protected resources?
> >>
> >> On Tue, Apr 25, 2017 at 8:04 PM, Ehsan Akhgari
> <ehsan....@gmail.com
> <mailto:ehsan....@gmail.com>

> <mailto:ehsan....@gmail.com <mailto:ehsan....@gmail.com>>>

> >> wrote:
> >>
> >> > On 04/25/2017 10:25 AM, Andrew Overholt wrote:
> >> >
> >> >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla
> <e...@rtfm.com <mailto:e...@rtfm.com>

> <mailto:e...@rtfm.com <mailto:e...@rtfm.com>>> 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#Ambi
> <https://www.chromestatus.com/metrics/feature/popularity#Ambi>
>
> <https://www.chromestatus.com/metrics/feature/popularity#Ambi
> <https://www.chromestatus.com/metrics/feature/popularity#Ambi>>
> >> >> entLightSensorConstructor.
> >> >>
> >> >
> >> > This is the new version of the spec which we
> don't ship.
> >> >
> >> >
> >> > We are going to collect telemetry in
> >> >>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1359124
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1359124>
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1359124
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1359124>>.

> >> >> _______________________________________________
> >> >> dev-platform mailing list
> >> >> dev-pl...@lists.mozilla.org

> <mailto:dev-pl...@lists.mozilla.org>
> <mailto:dev-pl...@lists.mozilla.org

> <mailto:dev-pl...@lists.mozilla.org>>
> >> >> https://lists.mozilla.org/listinfo/dev-platform
> <https://lists.mozilla.org/listinfo/dev-platform>

> <https://lists.mozilla.org/listinfo/dev-platform

> <https://lists.mozilla.org/listinfo/dev-platform>>
> >> >>
> >> >
> >> > _______________________________________________
> >> > dev-platform mailing list
> >> > dev-pl...@lists.mozilla.org

> <mailto:dev-pl...@lists.mozilla.org>
> <mailto:dev-pl...@lists.mozilla.org

> <mailto:dev-pl...@lists.mozilla.org>>
> >> > https://lists.mozilla.org/listinfo/dev-platform
> <https://lists.mozilla.org/listinfo/dev-platform>

> <https://lists.mozilla.org/listinfo/dev-platform
> <https://lists.mozilla.org/listinfo/dev-platform>>
> >> >
> >>
> >>
> >>
> >> --
> >> <salva />

> >> _______________________________________________
> >> dev-platform mailing list
> >> dev-pl...@lists.mozilla.org

> <mailto:dev-pl...@lists.mozilla.org>
> <mailto:dev-pl...@lists.mozilla.org

> <mailto:dev-pl...@lists.mozilla.org>>
> >> https://lists.mozilla.org/listinfo/dev-platform
> <https://lists.mozilla.org/listinfo/dev-platform>

> <https://lists.mozilla.org/listinfo/dev-platform
> <https://lists.mozilla.org/listinfo/dev-platform>>
> >>
> >
> >
>
>
> --
> <salva />

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org

> <mailto:dev-pl...@lists.mozilla.org>
> <mailto:dev-pl...@lists.mozilla.org

> <mailto:dev-pl...@lists.mozilla.org>>
> https://lists.mozilla.org/listinfo/dev-platform
> <https://lists.mozilla.org/listinfo/dev-platform>

> <https://lists.mozilla.org/listinfo/dev-platform
> <https://lists.mozilla.org/listinfo/dev-platform>>
>
>
>
>
>
> --
> <salva />
>
>
>
>
>

> --
> <salva />

[Salvador de la Puente]

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 it off, but neither I thought of reading an image
pixel by pixel with the ambient light sensor, to be honest.

On Wed, Apr 26, 2017 at 8:27 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

>> >> >> _______________________________________________
>> >> >> dev-platform mailing list
>> >> >> dev-pl...@lists.mozilla.org

>> <mailto:dev-pl...@lists.mozilla.org>
>> <mailto:dev-pl...@lists.mozilla.org
>> <mailto:dev-pl...@lists.mozilla.org>>
>> >> >> https://lists.mozilla.org/listinfo/dev-platform
>> <https://lists.mozilla.org/listinfo/dev-platform>
>> <https://lists.mozilla.org/listinfo/dev-platform

>> <https://lists.mozilla.org/listinfo/dev-platform>>
>> >> >>
>> >> >
>> >> > _______________________________________________
>> >> > dev-platform mailing list
>> >> > dev-pl...@lists.mozilla.org

>> <mailto:dev-pl...@lists.mozilla.org>
>> <mailto:dev-pl...@lists.mozilla.org
>> <mailto:dev-pl...@lists.mozilla.org>>
>> >> > https://lists.mozilla.org/listinfo/dev-platform
>> <https://lists.mozilla.org/listinfo/dev-platform>
>> <https://lists.mozilla.org/listinfo/dev-platform
>> <https://lists.mozilla.org/listinfo/dev-platform>>
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> <salva />

>> >> _______________________________________________
>> >> dev-platform mailing list
>> >> dev-pl...@lists.mozilla.org

>> <mailto:dev-pl...@lists.mozilla.org>
>> <mailto:dev-pl...@lists.mozilla.org
>> <mailto:dev-pl...@lists.mozilla.org>>
>> >> https://lists.mozilla.org/listinfo/dev-platform
>> <https://lists.mozilla.org/listinfo/dev-platform>
>> <https://lists.mozilla.org/listinfo/dev-platform
>> <https://lists.mozilla.org/listinfo/dev-platform>>
>> >>
>> >
>> >
>>
>>
>> --
>> <salva />

>> _______________________________________________
>> dev-platform mailing list
>> dev-pl...@lists.mozilla.org

>> <mailto:dev-pl...@lists.mozilla.org>
>> <mailto:dev-pl...@lists.mozilla.org
>> <mailto:dev-pl...@lists.mozilla.org>>
>> https://lists.mozilla.org/listinfo/dev-platform
>> <https://lists.mozilla.org/listinfo/dev-platform>
>> <https://lists.mozilla.org/listinfo/dev-platform
>> <https://lists.mozilla.org/listinfo/dev-platform>>
>>
>>
>>
>>
>>
>> -- <salva />
>>
>>
>>
>>
>>
>> --
>> <salva />
>>
>
>

--
<salva />

[smaug]

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 restriction doesn't really help here. Critically,
>> rate limit access much more than the 60Hz recommended for the
>> accelerometer. 5Hz might be sufficient here, maybe even lower.
>
> How does restricting this to secure contexts help?

This is a good point to remember in this kinds of attacks. So often has use of secure context suggested as the way to
fix issues, when it often doesn't really help at all with the core issue.

And the initial email did have

"Unshipping for non-secure context and making it HTTPS-only wouldn't address the attack."

(Also, secure context itself is in its current design rather broken, IMO, yet hinting in its name that it is somehow secure.
BroadcastChannel or localStorage etc are easy ways to transfer data from secure context to non-secure. )

[Frederik Braun]

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 necessary precondition for the
>>> attack, so that restriction doesn't really help here. Critically,
>>> rate limit access much more than the 60Hz recommended for the
>>> accelerometer. 5Hz might be sufficient here, maybe even lower.
>>
>> How does restricting this to secure contexts help?
> This is a good point to remember in this kinds of attacks. So often has
> use of secure context suggested as the way to
> fix issues, when it often doesn't really help at all with the core issue.
>
> And the initial email did have
> "Unshipping for non-secure context and making it HTTPS-only wouldn't
> address the attack."
>

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.

[Anne van Kesteren]

On Thu, Apr 27, 2017 at 8:42 AM, Salvador de la Puente
<sdela...@mozilla.com> 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 platform in an insecure state undermines
confidence more than removing features that are barely used and cause
security problems.

And even if you'd reduce the amount of detail it exposes, it seems
that would still leak some bits, which is more than we leak today (so
I'm not sure why the CSS solution with less values is acceptable for
instance). At which point you're left with asking the user and that
leads to dialog fatigue, figuring out how to even ask the question,
etc. This may be a worthwhile problem to solve, but any acceptable
solution likely leads to a different API shape anyway. In the interim
we should not dispatch this event.


--
https://annevankesteren.nl/

[Ehsan Akhgari]

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
>>>> 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 recommended for the
>>>> accelerometer. 5Hz might be sufficient here, maybe even lower.
>>> How does restricting this to secure contexts help?
>> This is a good point to remember in this kinds of attacks. So often has
>> use of secure context suggested as the way to
>> fix issues, when it often doesn't really help at all with the core issue.
>>
>> And the initial email did have
>> "Unshipping for non-secure context and making it HTTPS-only wouldn't
>> address the attack."
>>

> 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 security of the transport layer, but
if the origin itself is untrusted (which it is) exposing an unsafe
functionality to a "secure" context is just as unsafe.

(And on the practical side of things, any attacker can use a free or
paid CA service to deliver their attack code through a secure channel.)

[Martin Thomson]

On Fri, Apr 28, 2017 at 1:56 PM, Ehsan Akhgari <ehsan....@gmail.com> 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 security of the transport layer, but if the
> origin itself is untrusted (which it is) exposing an unsafe functionality to
> a "secure" context is just as unsafe.
>
> (And on the practical side of things, any attacker can use a free or paid CA
> service to deliver their attack code through a secure channel.)

While this is all true, a secure origin at least gives us the ability
to disable the feature on a per-origin basis if we decided to do that.

I feel like I've had this conversation before...

[Frederik Braun]

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 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 recommended for the
>>>>> accelerometer. 5Hz might be sufficient here, maybe even lower.
>>>> How does restricting this to secure contexts help?
>>> This is a good point to remember in this kinds of attacks. So often has
>>> use of secure context suggested as the way to
>>> fix issues, when it often doesn't really help at all with the core
>>> issue.
>>>
>>> And the initial email did have
>>> "Unshipping for non-secure context and making it HTTPS-only wouldn't
>>> address the attack."
>>>

>> 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 security of the transport layer, but
> if the origin itself is untrusted (which it is) exposing an unsafe
> functionality to a "secure" context is just as unsafe.
>
> (And on the practical side of things, any attacker can use a free or
> paid CA service to deliver their attack code through a secure channel.)
>

Yes, yes and yes. This is not about the attack at all.
This is about powerful features using secure contexts.

[Eric Rescorla]

On Thu, Apr 27, 2017 at 11:02 PM, Frederik Braun <fbr...@mozilla.com> 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:
> >>>>> 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 recommended for the
> >>>>> accelerometer. 5Hz might be sufficient here, maybe even lower.
> >>>> How does restricting this to secure contexts help?
> >>> This is a good point to remember in this kinds of attacks. So often has
> >>> use of secure context suggested as the way to
> >>> fix issues, when it often doesn't really help at all with the core
> >>> issue.
> >>>
> >>> And the initial email did have
> >>> "Unshipping for non-secure context and making it HTTPS-only wouldn't
> >>> address the attack."
> >>>

> >> 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 security of the transport layer, but
> > if the origin itself is untrusted (which it is) exposing an unsafe
> > functionality to a "secure" context is just as unsafe.
> >
> > (And on the practical side of things, any attacker can use a free or
> > paid CA service to deliver their attack code through a secure channel.)
> >
>
> Yes, yes and yes. This is not about the attack at all.
> This is about powerful features using secure contexts.
>

I realize that a number of people like this "powerful features" concept,
but I
don't really think it's that useful a frame, for precisely the reasons on
display
here, nor is it really the consensus inside Mozilla. Rather, the policy is
that we will move to requiring all new features to have HTTPS [0].

I agree that the specification specifically says that this feature must only
be exposed in a secure context, and so we should conform to that (or
just remove the feature) but I don't think the "powerful features" argument
is particularly persuasive in that decision.

-Ekr

[0]
https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/

[Anne van Kesteren]

On Fri, Apr 28, 2017 at 7:10 PM, Eric Rescorla <e...@rtfm.com> 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's also very much unclear what the scope of it is,
whether a new CSS property should get that treatment, a new method on
Node, etc.


> [0]
> https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/


--
https://annevankesteren.nl/

[Andrew Overholt]

Did we make a decision here? If not, what are we missing to make one?