Re: Ambient Light Sensor API

[Andrew Overholt]

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 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/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Anne van Kesteren]

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'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/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Eric Rescorla]

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:
> > 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/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Frederik Braun]

la-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 
>>>>>> 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
>>>>>>>
>>>>>>> On Mon, Apr 24, 2017 at 2:38 PM, Frederik Braun 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 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?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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 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/nsDev
>>>>>>>> iceSensors.cpp
>>>>>>>> ___
>>>>>>>> dev-platform mailing list
>>>>>>>> dev-platform@lists.mozilla.org
>>>>>>>> https://lists.mozilla.org/listinfo/dev-platform
>>>>>>>>
>>>>>> ___
>>>>>> dev-platform mailing list
>>>>>> dev-platform@lists.mozilla.org
>>>>>> https://lists.mozilla.org/listinfo/dev-platform
>>>>> ___
>>>>> dev-platform mailing list
>>>>> dev-platform@lists.mozilla.org
>>>>> https://lists.mozilla.org/listinfo/dev-platform
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Martin Thomson]

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 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...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Ehsan Akhgari]

 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,

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/nsDev

iceSensors.cpp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Anne van Kesteren]

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 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/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Frederik Braun]

gh.
>>>>>
>>>>> 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
>>>>>
>>>>> On Mon, Apr 24, 2017 at 2:38 PM, Frederik Braun 
>>>>> wrote:
>>>>>
>>>>>> 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?
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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 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/nsDev
>>>>>> iceSensors.cpp
>>>>>> ___
>>>>>> dev-platform mailing list
>>>>>> dev-platform@lists.mozilla.org
>>>>>> https://lists.mozilla.org/listinfo/dev-platform
>>>>>>
>>>>>
>>>> ___
>>>> dev-platform mailing list
>>>> dev-platform@lists.mozilla.org
>>>> https://lists.mozilla.org/listinfo/dev-platform
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[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. )


  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.


On Tue, Apr 25, 2017 at 12:06 AM, Jonathan Kingston  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  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

On Mon, Apr 24, 2017 at 2:38 PM, Frederik Braun 
wrote:


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?



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

Re: Ambient Light Sensor API

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

> 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 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 > > 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  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 >  > >> wrote:
>>
>>
>>
>> On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente
>> mailto: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 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
>> mailto:j...@mozilla.com>
>> >> wrote:
>>
>> > Auth related images are the attack vector, that and
>> history
>> attacks on
>> > same domain.
>> >
>>

Re: Ambient Light Sensor API

[Ehsan Akhgari]

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



On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente
mailto: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 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
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 <
> 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 have the
ability to
embed the
>> image
>> in step 1, why to not simply send this to evil.com

 for further
>> processing?
 

Re: Ambient Light Sensor API

[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 
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 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>> wrote:
>>
>>
>>
>> On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente
>> mailto: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 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
>> 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 <
>> > 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 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
>> mailto:ehsan.akhg...@gmail.com>>
>> >> wrote:
>> >>
>> >> > On 04/25/2017 10:25 AM, Andrew Overholt wrote:
>> >> >
>> >> >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla
>> 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
>> 
>> >> >> 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-platform@lists.mozilla.org
>> 
>> >> >> https://lists.mozilla.org/listinfo/dev-platform
>> 
>> >> >>
>> >> >
>> >> > ___
>> >> > dev-platform mailing list
>> >> > dev-platform@lists.mozilla.org
>> 
>> >> > https://lists.mozilla.org/listinfo/dev-platform
>> 

Re: Ambient Light Sensor API

[Salvador de la Puente]

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 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 
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 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>> wrote:
>>
>>
>>
>> On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente
>> mailto: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 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
>> 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 <
>> > 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 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
>> mailto:ehsan.akhg...@gmail.com>>
>> >> wrote:
>> >>
>> >> > On 04/25/2017 10:25 AM, Andrew Overholt wrote:
>> >> >
>> >> >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla
>> 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
>> 
>> >> >> 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-platform@lists.mozilla.org
>> 
>> >> >> https://lists.mozilla.org/listinfo/dev-platform
>> 
>> >> >>
>> >> >
>> >> > ___
>> >> > dev-platform mailing list
>> >> > dev-platform@lis

Re: Ambient Light Sensor API

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




On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente
mailto: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 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
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 <
> 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 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
mailto:ehsan.akhg...@gmail.com>>
>> wrote:
>>
>> > On 04/25/2017 10:25 AM, Andrew Overholt wrote:
>> >
>> >> On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla
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

>> >> 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-platform@lists.mozilla.org

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

>> >>
>> >
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org

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

>> >
>>
>>
>>
>> --
>> 
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org

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

>>
>
>


--

___
dev-platform mailing list
dev-platform@lists.mo

Re: Ambient Light Sensor API

[Martin Thomson]

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, 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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[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 <
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 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 
> wrote:
>
> > 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/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-platform@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
>
>
>
> --
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Eric Rescorla]

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 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
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[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

On Monday, April 24, 2017 at 3:25:05 PM UTC+2, 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 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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Kurt Roeckx]

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


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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Eric Rescorla]

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 pretty seriously.

-Ekr



> 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:
>>
>>> 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 
>>> 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 <
>>> > 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 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.akhg...@gmail.com>
>>> >> wrote:
>>> >>
>>> >> > 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/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-platform@lists.mozilla.org
>>> >> >> https://lists.mozilla.org/listinfo/dev-platform
>>> >> >>
>>> >> >
>>> >> > ___
>>> >> > dev-platform mailing list
>>> >> > dev-platform@lists.mozilla.org
>>> >> > https://lists.mozilla.org/listinfo/dev-platform
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> 
>>> >> ___
>>> >> dev-platform mailing list
>>> >> dev-platform@lists.mozilla.org
>>> >> https://lists.mozilla.org/listinfo/dev-platform
>>> >>
>>> >
>>> >
>>>
>>>
>>> --
>>> 
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
>
>
> --
> 
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

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

>
>
> 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 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 
>> 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 <
>> > 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 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.akhg...@gmail.com>
>> >> wrote:
>> >>
>> >> > 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/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-platform@lists.mozilla.org
>> >> >> https://lists.mozilla.org/listinfo/dev-platform
>> >> >>
>> >> >
>> >> > ___
>> >> > dev-platform mailing list
>> >> > dev-platform@lists.mozilla.org
>> >> > https://lists.mozilla.org/listinfo/dev-platform
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> 
>> >> ___
>> >> dev-platform mailing list
>> >> dev-platform@lists.mozilla.org
>> >> https://lists.mozilla.org/listinfo/dev-platform
>> >>
>> >
>> >
>>
>>
>> --
>> 
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>


-- 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Eric Rescorla]

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 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 
> 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 <
> > 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 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  >
> >> wrote:
> >>
> >> > 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/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-platform@lists.mozilla.org
> >> >> https://lists.mozilla.org/listinfo/dev-platform
> >> >>
> >> >
> >> > ___
> >> > dev-platform mailing list
> >> > dev-platform@lists.mozilla.org
> >> > https://lists.mozilla.org/listinfo/dev-platform
> >> >
> >>
> >>
> >>
> >> --
> >> 
> >> ___
> >> dev-platform mailing list
> >> dev-platform@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
> >
> >
>
>
> --
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[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  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 <
> 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 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 
>> wrote:
>>
>> > 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/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-platform@lists.mozilla.org
>> >> https://lists.mozilla.org/listinfo/dev-platform
>> >>
>> >
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> >
>>
>>
>>
>> --
>> 
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>


-- 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

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

> 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/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-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Ehsan Akhgari]

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/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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[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  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  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, 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
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

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

> 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 <= 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.
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Eric Rescorla]

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 <= 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.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[Andrew Overholt]

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 going to collect telemetry in
https://bugzilla.mozilla.org/show_bug.cgi?id=1359124.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

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


On Tue, Apr 25, 2017 at 12:06 AM, Jonathan Kingston  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  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

On Mon, Apr 24, 2017 at 2:38 PM, Frederik Braun 
wrote:


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?



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 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/nsDev

iceSensors.cpp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform




__

Re: Ambient Light Sensor API

[Eric Rescorla]

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, 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
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[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  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  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
>>
>> On Mon, Apr 24, 2017 at 2:38 PM, Frederik Braun 
>> wrote:
>>
>>> 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?
>>>
>>>
>>>
>>> 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 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/nsDev
>>> iceSensors.cpp
>>> >
>>>
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[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  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
>
> On Mon, Apr 24, 2017 at 2:38 PM, Frederik Braun 
> wrote:
>
>> 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?
>>
>>
>>
>> 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 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/nsDev
>> iceSensors.cpp
>> >
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[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
restriction in our codebase though?

This looks like a specification violation here.

Thanks
Jonathan

On Mon, Apr 24, 2017 at 2:38 PM, Frederik Braun  wrote:

> 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?
>
>
>
> 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 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
> >
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

[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?



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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ambient Light Sensor API

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

On Mon, Apr 24, 2017 at 9:24 AM, 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 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
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform