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