On Mon, Apr 13, 2015 at 5:57 PM, Richard Barnes <rba...@mozilla.com
> There's pretty broad agreement that HTTPS is the way forward for the web.
> In recent months, there have been statements from IETF , IAB , W3C
> , and even the US Government  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.
> Some earlier threads on this list  and elsewhere  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.
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
* 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