I think that 60Hz is too high a rate for this. I suggest that we restrict this to top-level, foreground, and secure contexts. Note that foreground is a necessary precondition for the attack, so that restriction doesn't really help here. Critically, rate limit access much more than the 60Hz recommended for the accelerometer. 5Hz might be sufficient here, maybe even lower.
Since the amount of information that can be extracted is a function of the number of times the API is called and the accuracy of the reading, we should consider also reducing the accuracy of the reading. The attack reduced its information extraction to 1 bit per reading, but you can't assume that this is the actual limit. Fuzzing is much harder than it seems if your intent is to deal with an attack. I can walk through some strategies if someone is interested in doing this. That all assumes that you aren't willing to add a dialog for this, which seems like the right answer. That said, if the mitigation strategies - rate limiting in particular - can't be implemented in a reasonable time-frame, I would consider preffing this off (though the pref name suggests that there would be collateral). On Tue, Apr 25, 2017 at 12:06 AM, Jonathan Kingston <j...@mozilla.com> wrote: > As a follow up, it looks like the device motion events defined in the > device sensors: > http://searchfox.org/mozilla-central/source/dom/system/nsDeviceSensors.cp > should also be restricting based on isSecureContext. > > The spec mentions "should take into consideration the following suggestions" > : > https://www.w3.org/TR/orientation-event/#security-and-privacy > > We don't do those measures from what I can see. > > Can we make the webIDL represent this requirement for requiring secure > context instead? > > Thanks > Jonathan > > On Mon, Apr 24, 2017 at 2:41 PM, Jonathan Kingston <j...@mozilla.com> wrote: > >> 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
