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: Future of out-of-tree spell checkers?

[Ehsan Akhgari]

On 04/26/2017 07:02 AM, Henri Sivonen wrote:

On Tue, Apr 25, 2017 at 9:02 PM, Bill McCloskey  wrote:

On Tue, Apr 25, 2017 at 5:41 AM, Henri Sivonen  wrote:

What problem did you mean to address by code signing?

The reason I suggested code signing is because loading libvoikko would
provide an easy way for people to inject code into Firefox.


Yes, this is precisely what I'm worried about as well.

For a while
we've been trying to make it difficult for semi-legit-but-not-quite-malware
parties to load crappy code into Firefox (I'm thinking of crappy antivirus
software, adware, etc.). Removing binary XPCOM components and NPAPI support,
and requiring add-on signing, are all facets of this. If we simply load and
run code from any file named voikko.dll on the user's computer, then we've
opened up another door. It's a less powerful door since we probably (I hope)
wouldn't give them access to XPCOM. But they could still open windows that
look like they came from Firefox and I imagine there's other bad stuff I
haven't thought of.

People often object to this argument by saying that, without libvoikko,
these bad actors could just replace libxul or something. But I think in
practice it would be harder for them to pull that off, both technically and
socially. From a technical perspective, it's harder to replace core parts of
Firefox while still leaving it in a working state, especially if the updater
is still allowed to run. And socially, I think it makes their software look
a lot more like malware if they replace parts of Firefox rather than simply
install a new DLL that we then load.

This concern applies to Windows but not to Linux, right? What about Mac?
FTR my main concern is about Windows here.  But that being said I think 
we can probably do something similar for Linux and Mac (but if we don't 
have the time or resources to address those first/now, that's probably 
fine.)

To address that concern, the local system itself would have to be
treated as semi-hostile and the signature would have to be checked at
library load time as opposed to the usual library install time. Do we
have pre-existing code for that?
We should treat the local system as *hostile*.  Because that's what it 
is in the real world at least for our Windows users.


I was hoping that we can use the code that we use to sign and verify our 
mar files for the updater here, see for example this header which we use 
for signature verification 
. 
I'm suggesting to use this code as a *basis* for this work, so there 
will be some new code to be written for sure.


The advantage of this code is that it's pretty self-contained, so for 
example we can use it to create a small command line utility to give the 
voikko folks to use for signing, etc.

AFAIK, in the case of OpenH264 we check a hash at library install
time, but when we subsequently load the library, we don't check a hash
or signature. In the case of OpenH264, the library gets loaded into a
sandbox, which probably addresses the concern of a replacement
OpenH264 with dodgy additional code being able to open windows that
look like they came from Firefox.

Assuming that we don't already have code for validating library
provenance at library load time, wouldn't it make more sense to put
effort into reusing the facilities for spawning a GMP process to spawn
a low-privilege spell checking process than to try validate the
provenance of already-installed code in a way that still doesn't
address the crash impact concern in the case of the code being
legitimate?


Overall, though, I agree with Ehsan that this discussion isn't very
worthwhile unless we what the voikko people want to do.

It seems to me that this thread raises enough concerns on our side
that it doesn't make sense to ask a third party what they want to do
before we have an idea what we'd be OK with.

Suppose they'd say they'd want to include libvoikko in Firefox like Hunspell?
We'd have binary size and crash impact concerns.
To make the concerns here more concrete, the core of the issue is that 
our non-English builds are merely a repack of the en-US builds, so 
currently it's not possible to ship extra code to those users. That 
being said, it _may_ be an option to use the locale repackaging step as 
a vehicle for delivering the library binary that the voikko project 
provides us if we end up going that option.  We should check with the 
l10n team how easy/possible packaging this would be inside the locale as 
a resource...

Suppose they'd say they'd want to make libvoikko download on-demand
using Mozilla infra like OpenH264?
We'd have concerns of finding release engineers and front end
engineers with time to set it up, the crash impact concern and the
concern of another party dropping malware in libvoikko's place.
FTR, it may actually be useful to look into this...  I sort of assumed 
this isn't an option because I don't know how reusable the infra that we 
ha

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: A reminder about commit messages: they should be useful

[Selena Deckelmann]

Hi!

On Wed, Apr 26, 2017 at 7:05 AM Boris Zbarsky  wrote:

> On 4/25/17 4:27 PM, Alexander Surkov wrote:
> > Maybe we should have a style guide, explaining what makes a good commit
> message and what makes a good and descriptive bug, with number of (good and
> bad) examples.
>
> Yes, we should.
>
> Maybe we should have a discussion at the all hands about this...
>

I'll take that as my cue to organize this.

I'll reach out off-list to the folks involved in this conversation and set
a time and an agenda.

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

Re: A reminder about commit messages: they should be useful

[Boris Zbarsky]

On 4/25/17 4:27 PM, Alexander Surkov wrote:

Maybe we should have a style guide, explaining what makes a good commit message 
and what makes a good and descriptive bug, with number of (good and bad) 
examples.


Yes, we should.

Maybe we should have a discussion at the all hands about this...

-Boris

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

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: Future of out-of-tree spell checkers?

[Henri Sivonen]

On Tue, Apr 25, 2017 at 9:02 PM, Bill McCloskey  wrote:
> On Tue, Apr 25, 2017 at 5:41 AM, Henri Sivonen  wrote:
>>
>> What problem did you mean to address by code signing?
>
> The reason I suggested code signing is because loading libvoikko would
> provide an easy way for people to inject code into Firefox. For a while
> we've been trying to make it difficult for semi-legit-but-not-quite-malware
> parties to load crappy code into Firefox (I'm thinking of crappy antivirus
> software, adware, etc.). Removing binary XPCOM components and NPAPI support,
> and requiring add-on signing, are all facets of this. If we simply load and
> run code from any file named voikko.dll on the user's computer, then we've
> opened up another door. It's a less powerful door since we probably (I hope)
> wouldn't give them access to XPCOM. But they could still open windows that
> look like they came from Firefox and I imagine there's other bad stuff I
> haven't thought of.
>
> People often object to this argument by saying that, without libvoikko,
> these bad actors could just replace libxul or something. But I think in
> practice it would be harder for them to pull that off, both technically and
> socially. From a technical perspective, it's harder to replace core parts of
> Firefox while still leaving it in a working state, especially if the updater
> is still allowed to run. And socially, I think it makes their software look
> a lot more like malware if they replace parts of Firefox rather than simply
> install a new DLL that we then load.

This concern applies to Windows but not to Linux, right? What about Mac?

To address that concern, the local system itself would have to be
treated as semi-hostile and the signature would have to be checked at
library load time as opposed to the usual library install time. Do we
have pre-existing code for that?

AFAIK, in the case of OpenH264 we check a hash at library install
time, but when we subsequently load the library, we don't check a hash
or signature. In the case of OpenH264, the library gets loaded into a
sandbox, which probably addresses the concern of a replacement
OpenH264 with dodgy additional code being able to open windows that
look like they came from Firefox.

Assuming that we don't already have code for validating library
provenance at library load time, wouldn't it make more sense to put
effort into reusing the facilities for spawning a GMP process to spawn
a low-privilege spell checking process than to try validate the
provenance of already-installed code in a way that still doesn't
address the crash impact concern in the case of the code being
legitimate?

> Overall, though, I agree with Ehsan that this discussion isn't very
> worthwhile unless we what the voikko people want to do.

It seems to me that this thread raises enough concerns on our side
that it doesn't make sense to ask a third party what they want to do
before we have an idea what we'd be OK with.

Suppose they'd say they'd want to include libvoikko in Firefox like Hunspell?
We'd have binary size and crash impact concerns.

Suppose they'd say they'd want to make libvoikko download on-demand
using Mozilla infra like OpenH264?
We'd have concerns of finding release engineers and front end
engineers with time to set it up, the crash impact concern and the
concern of another party dropping malware in libvoikko's place.

Suppose they'd say they'd want to install libvoikko somewhere on the
user's library path and have us dlopen() it?
We'd have concerns about crash impact, being able to remedy crashes,
directing people to install non-Mozilla software (though @firefox on
Twitter regularly does) and other parties dropping malware in
libvoikko's place.

Suppose they'd say they'd want to ship a back end for system spell
checking frameworks and have us use the system spell checking API[1]?
We'd have concerns of Windows 7 not being covered, directing people to
install non-Mozilla software and crash impact at least in the Linux
case (AFAICT, Enchant doesn't provide process isolation from the back
end; I *think* Apple's solution does; not sure about Windows 8+) and
having to write 3 system-specific spell checking integrations.

Suppose they'd say they'd want to ship it as Web Assembly in a Web Extension?
We'd have concern about allocating engineering time to enable a Web
Extension to act as a spell checking provider, when there's only one
extension that'd foreseeably use it.

- -

[1] Enchant on Linux (currently hard-codes the assumption that Voikko
is Finnish only, so at least for the time being (until a potential
future version of Enchant without that hard-coding makes its way
through the distros) would throw Greenlandic, Sami and hope of other
languages under the bus).
https://bugzilla.mozilla.org/show_bug.cgi?id=422399

ISpellChecker on Windows 8+. The Windows built-in Finnish spell
checker is competent, so there'd be no functional need for Voikko for
Finnish. Would still need a non-Microsoft (i.e. libvoikko +
hfst-os

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: PBlob refactoring landed

[Jan Varga]

Thanks for this refactoring!

Especially given that this code is quite complex and I remember the 
times when there's was only one guy who understood it (bent)


Jan


On 26/04/17 09:13, Andrea Marchesini wrote:

Hi all,

In the last month I have worked on the refactoring of PBlob code and today
I'm very excited to announce that the first block of patches (20~) is
finally in nightly.
Everywhere in gecko, PBlob has been converted to IPCBlob, except for 2
components: FileHandle and IndexedDb. The former has patches in review, the
latter, patches are in testing.

The reason why I started this refactoring are mainly 3:

1. PBlob code has/had sync IPC calls for retrieving remote inputStreams
(bug 1350644) PBlob has also other sync IPC calls, and all of them have
been removed in the refactoring:
https://dxr.mozilla.org/mozilla-central/source/ipc/ipdl/sync-messages.ini#810-817

2. A consequence of point one is not just a performance issue, but we have
bugs where those IPC calls cause deadlocks when those are executed on the
main-thread, during a sync event loop of a workers, on a PBlob generated in
workers (super racy but still possible).

3. PBlob code is hard to maintain, it doesn't have enough comments and it
has some open issues such as: bug 1304056 and bug 1272078

4. We have crashs in the use of remoteInputStream in PBlob: bug 1349685

The new source code gets rid of PBlob completely. A good description of how
it works can be found here:

https://dxr.mozilla.org/mozilla-central/source/dom/file/ipc/IPCBlobUtils.h#12

If you need to pass Blobs via IPC, please, use IPCBlob. There are useful
methods in mozilla/dom/IPCBlobUtils.h for serializing and deserializing
blobs into/from IPCBlob.

Cheers,
b
___
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: PBlob refactoring landed

[Andrea Marchesini]

I forgot to say that there is a meta bug for this PBlob refactoring: bug
1353629.

On Wed, Apr 26, 2017 at 9:13 AM, Andrea Marchesini 
wrote:

> Hi all,
>
> In the last month I have worked on the refactoring of PBlob code and today
> I'm very excited to announce that the first block of patches (20~) is
> finally in nightly.
> Everywhere in gecko, PBlob has been converted to IPCBlob, except for 2
> components: FileHandle and IndexedDb. The former has patches in review, the
> latter, patches are in testing.
>
> The reason why I started this refactoring are mainly 3:
>
> 1. PBlob code has/had sync IPC calls for retrieving remote inputStreams
> (bug 1350644) PBlob has also other sync IPC calls, and all of them have
> been removed in the refactoring: https://dxr.mozilla.org/
> mozilla-central/source/ipc/ipdl/sync-messages.ini#810-817
>
> 2. A consequence of point one is not just a performance issue, but we have
> bugs where those IPC calls cause deadlocks when those are executed on the
> main-thread, during a sync event loop of a workers, on a PBlob generated in
> workers (super racy but still possible).
>
> 3. PBlob code is hard to maintain, it doesn't have enough comments and it
> has some open issues such as: bug 1304056 and bug 1272078
>
> 4. We have crashs in the use of remoteInputStream in PBlob: bug 1349685
>
> The new source code gets rid of PBlob completely. A good description of
> how it works can be found here:
>
> https://dxr.mozilla.org/mozilla-central/source/dom/
> file/ipc/IPCBlobUtils.h#12
>
> If you need to pass Blobs via IPC, please, use IPCBlob. There are useful
> methods in mozilla/dom/IPCBlobUtils.h for serializing and deserializing
> blobs into/from IPCBlob.
>
> Cheers,
> b
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PBlob refactoring landed

[Andrea Marchesini]

Hi all,

In the last month I have worked on the refactoring of PBlob code and today
I'm very excited to announce that the first block of patches (20~) is
finally in nightly.
Everywhere in gecko, PBlob has been converted to IPCBlob, except for 2
components: FileHandle and IndexedDb. The former has patches in review, the
latter, patches are in testing.

The reason why I started this refactoring are mainly 3:

1. PBlob code has/had sync IPC calls for retrieving remote inputStreams
(bug 1350644) PBlob has also other sync IPC calls, and all of them have
been removed in the refactoring:
https://dxr.mozilla.org/mozilla-central/source/ipc/ipdl/sync-messages.ini#810-817

2. A consequence of point one is not just a performance issue, but we have
bugs where those IPC calls cause deadlocks when those are executed on the
main-thread, during a sync event loop of a workers, on a PBlob generated in
workers (super racy but still possible).

3. PBlob code is hard to maintain, it doesn't have enough comments and it
has some open issues such as: bug 1304056 and bug 1272078

4. We have crashs in the use of remoteInputStream in PBlob: bug 1349685

The new source code gets rid of PBlob completely. A good description of how
it works can be found here:

https://dxr.mozilla.org/mozilla-central/source/dom/file/ipc/IPCBlobUtils.h#12

If you need to pass Blobs via IPC, please, use IPCBlob. There are useful
methods in mozilla/dom/IPCBlobUtils.h for serializing and deserializing
blobs into/from IPCBlob.

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