On Mon, May 4, 2015 at 10:52 AM, Florian Bösch <pya...@gmail.com> wrote:
> On Mon, May 4, 2015 at 7:43 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> This would be more useful if you explained what they considered the cost >> of converting to HTTPS so, so we could discuss ways to ameliorate that cost. >> > I agree. But I don't get to choose what answers I get. I can press the > point out of interest. But even if I get to some satisfactory outcome there > that way, it's still effort/money to expend, there's dozens of clients from > the past and more in the future that I'll have to have the same conversion > with. For the ones from the past, in many cases even in an ideal case (not > much effort and everybody knows what's to do), the budget for those > deployments is used up. There's no new budget coming. They're not going to > get fixed no matter the good intentions of everybody. End of the day, work > is not free. > I'm going to refer you at this point to the W3C HTML design principles of priority of constituencies (http://www.w3.org/TR/html-design-principles/#priority-of-constituencies). "In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once." Again, we're happy to look at ways to ease this transition, but right now you're not offering any. With that said, fullscreen is actually a good example of a feature which >> really benefits from being over HTTPS. Consider what happens if the user >> grants a persistent permission to site X to use fullscreen. At that point, >> any network attacker can take over the user's entire screen without their >> consent by pretending to be site X. Note that this is true *even if* the >> real version of site X doesn't do anything sensitive. So, I think it should >> be fairly easy to understand why we want to limit access to fullscreen over >> HTTP. >> > > I don't agree with that reasoning. But my agreeing to it or not doesn't > change the outcome I have tested in the real world. > I don't really understand what you're talking about here. I think this is a fairly straightforward security analysis here. I appreciate that it makes people sad that we don't want to let them do unsafe things, but that doesn't make them safe. If you have a security analysis to offer in this case about why fullscreen over HTTP is safe, I'd be happy to hear it. -Ekr _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
