On Thu, Apr 27, 2017 at 11:02 PM, Frederik Braun <fbr...@mozilla.com> wrote:
> On 28.04.2017 05:56, Ehsan Akhgari wrote: > > On 04/27/2017 08:09 AM, Frederik Braun wrote: > >> 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. > > Why is that an advantage? Any attacker can use a secure context. The > > word "secure" here relates to the security of the transport layer, but > > if the origin itself is untrusted (which it is) exposing an unsafe > > functionality to a "secure" context is just as unsafe. > > > > (And on the practical side of things, any attacker can use a free or > > paid CA service to deliver their attack code through a secure channel.) > > > > Yes, yes and yes. This is not about the attack at all. > This is about powerful features using secure contexts. > I realize that a number of people like this "powerful features" concept, but I don't really think it's that useful a frame, for precisely the reasons on display here, nor is it really the consensus inside Mozilla. Rather, the policy is that we will move to requiring all new features to have HTTPS [0]. I agree that the specification specifically says that this feature must only be exposed in a secure context, and so we should conform to that (or just remove the feature) but I don't think the "powerful features" argument is particularly persuasive in that decision. -Ekr [0] https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
