On Tue, Oct 25, 2016 at 8:12 PM, Anne van Kesteren <ann...@annevk.nl> wrote: > The basic problem is prompting the user at all for non-HTTPS since > that leads them to think they can make an informed decision whereas > that's very much unclear. So prompting more would just make the > problem worse. > > We want to get to a place where when we prompt the user on behalf of a > website we have some certainty who is asking the question (i.e., > HTTPS).
By that logic, we should not permit users to submit forms to non-HTTPS either. I agree that if we were designing the web from scratch we would absolutely require HTTPS for everything, but in reality we have to make a cost-benefit analysis in each case. That means analyzing the threats to our users' privacy or security and deciding whether it outweighs the user annoyance. If the prospect of a privacy leak is implausible or not a big privacy compromise, it doesn't necessarily outweigh the cost of aggravating users. I don't think that privacy or security issues are exempt from cost-benefit analysis like any other feature or bug fix -- they're unusually important, but still do not have infinite value. In this specific case, it seems that the usual candidates for MITMing (compromised Wi-Fi, malicious ISP) will already know the user's approximate location, because they're the ones who set up the Internet connection, and Wi-Fi has limited range. What exactly is the scenario we're worried about here? _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
