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 <e...@rtfm.com> 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 <k...@roeckx.be> 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
