On Thu, Apr 14, 2016 at 10:54 PM, Chris Peterson <cpeter...@mozilla.com> wrote: > Thanks for all the feedbck. I anticipated this proposal might not be > practical with real world sites, so it's better to halt it here. :) I should > have framed this email as an RFC instead of an intent to ship. >
Thanks Chris for bringing up this "modest proposal". I for one definitely had the feeling of "I would flip this on and try it immediately for myself." However, As EKR pointed out, Kyle Huey's > Why should we be the ones to take the web compat hit on this? is the fundamentally biggest issue. There were numerous other issues brought up as well about what makes the user more/less secure, typing in / sending their password more times etc. that are potentially more debatable. I'd like to see (a) revised/refined proposal(s) that ask(s): What steps can we take in this direction WITHOUT breaking web compat? E.g. since one of the issues raised is that *every* time a user enters/submits a password over HTTP (not secure), it opens them to being sniffed etc., thus it's good to discourage the frequency. Some STRAW PROPOSALS that I expect others here (and UX folks) to easily improve on: 1. Warning (perhaps similar to the invalid red glow) on password inputs in forms with HTTP "action" 2. Warning (similarly) on HTTP-auth password dialogs Both with wording making it clear that *the site* is requesting this "password in the clear", and perhaps a suggestion to especially use different passwords for any such sites. The intent being to educate users about the sites that are asking them to take more risks, and encouraging at least incrementally better password (creating/use) behaviors. Chris Peterson <cpeter...@mozilla.com> wrote: > > Focusing on third-party session cookies is an interesting idea. > "Sessionizing" non-HTTPS third-party cookies would encourage ad networks and > CDNs to use HTTPS, allowing content sites to use HTTPS without mixed content > problems. Much later, we could consider sessionizing even HTTPS third-party > cookies. This is an interesting refinement, and perhaps worthy of testing behind a flag to see how much "breaks". > I'll think about telemetry probes that could be added to better understand > these scenarios. I'm surprised we don't have much telemetry about cookie > usage. Monica Chew wrote [1] about a Mozilla study of cookies, but that was > only 573 users back in 2013. > > > chris > > [1] http://monica-at-mozilla.blogspot.com/2013/10/cookie-counting.html More telemetry on these scenarios would help inform both proposals and decisions regarding this. For that matter, how much telemetry do we have on frequency of user password submissions on HTML forms over HTTP, or insecure HTTP-auth? Thanks, Tantek _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
