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 <j...@mozilla.com> wrote:
As a follow up, it looks like the device motion events defined in the
device sensors:
http://searchfox.org/mozilla-central/source/dom/system/nsDeviceSensors.cp
should also be restricting based on isSecureContext.
The spec mentions "should take into consideration the following suggestions"
:
https://www.w3.org/TR/orientation-event/#security-and-privacy
We don't do those measures from what I can see.
Can we make the webIDL represent this requirement for requiring secure
context instead?
Thanks
Jonathan
On Mon, Apr 24, 2017 at 2:41 PM, Jonathan Kingston <j...@mozilla.com> wrote:
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 <fbr...@mozilla.com>
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
