On Mon, Apr 13, 2015 at 5:57 PM, Richard Barnes <rbar...@mozilla.com> wrote: > There's pretty broad agreement that HTTPS is the way forward for the web. > In recent months, there have been statements from IETF [1], IAB [2], W3C > [3], and even the US Government [4] calling for universal use of > encryption, which in the case of the web means HTTPS.
I agree that we should get the Web onto https and I'me very happy to see this proposal. > https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit?usp=sharing > > Some earlier threads on this list [5] and elsewhere [6] have discussed > deprecating insecure HTTP for "powerful features". We think it would be a > simpler and clearer statement to avoid the discussion of which features are > "powerful" and focus on moving all features to HTTPS, powerful or not. I understand that especially in debates about crypto, there's a strong desire to avoid ratholing and bikeshedding. However, I think avoiding the discussion on which features are "powerful" is the wrong way to get from the current situation to where we want to be. Specifically: 1) I expect the non-availability on http origins of e.g. new CSS effects that are equally non-privacy-sensitive as existing CSS effects just as a way to force sites onto https to create resentment among Web devs that would be better avoided in order to have Web devs support the cause of encrypting the Web and that could be avoided by withholding features from http on grounds that tie clearly to the downsides of http relative to https. 2) I expect withholding certain *existing* privacy-sensitive features from http to have a greater leverage to push sites to https than withholding privacy-neutral *new* features. Specifically, on point #2, I think we should start by, by default, forgetting all cookies that don't have the "secure" flag set at the end of the Firefox session. Persistent cookies have two main use cases: * On login-requiring sites, not requiring the user to have to re-enter credentials in every browser session. * Behavioral profiling. The first has a clear user-facing benefit. The second is something that users typically don't want and breaking it has no obvious user-visible effect of breaking Web compat of the browser. Fortunately, the most-used login-requiring sites use https already, so forgetting insecure cookies at the end of the session would have no adverse effect on the most-user-visible use of persistent cookies. Also, if a login-requiring site is not already using https, it's pretty non-controversial that they are Doing It Wrong and should migrate to https. One big reason why mostly content-oriented sites, such as news sites, haven't migrated to https is that they are ad-funded and the advertising networks are lagging behind in https deployment. Removing persistence from insecure cookies would give a reason for the ad networks to accelerate https deployment and do so in a way that doesn't break the Web in user-visible ways during the transition. That is, if ad networks want to track users, at least they shouldn't enable collateral tracking by network eavesdroppers while doing so. So I think withholding cookie persistence from insecure cookies could well be way more effective per unit of disruption of user-perceived Web compat than anything in your proposal. In addition to persistent cookies, I think we should seek to be more aggressive in making other features that allow sites to store persistent state on the client https-only than in making new features in general https-only. (I realize that applying this consistently to the HTTP cache could be infeasible on performance grounds in the near future at least.) Furthermore, I think this program should have a UI aspect to it: Currently, the UI designation for http is neutral while the UI designation for mixed content is undesirable. I think we should make the UI designation of plain http undesirable once x% the sites that users encounter on a daily basis are https. Since users don't interact with the whole Web equally, this means that the UI for http would be made undesirable much earlier than the time when x% of Web sites migrates to https. x should be chosen to be high enough as to avoid warning fatigue that'd desensitize users to the undesirable UI designation. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
