- From: Chris Palmer <palmer@google.com>
- Date: Thu, 18 Dec 2014 13:46:12 -0800
- To: Monica Chew <mmc@mozilla.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, blink-dev <blink-dev@chromium.org>, security-dev <security-dev@chromium.org>, "dev-security@lists.mozilla.org" <dev-security@lists.mozilla.org>
Sigh. Re-posting this, because the Mozilla list doesn't like large attachments. To see the equivalent, go to https://www.google.com and click on the green lock in the Omnibox. On Thu, Dec 18, 2014 at 1:41 PM, Chris Palmer <palmer@google.com> wrote: > On Thu, Dec 18, 2014 at 1:18 PM, Monica Chew <mmc@mozilla.com> wrote: > >> Thanks for the numbers. That's a significant gap (58% vs 33%). Do you have >> any idea why this might be the case? > > I don't, unfortunately. > > I think we (Chrome) are going to try measuring HTTPS vs. HTTP > deployment in other ways too, and then we might see discrepancies. > >> I understand the desire here, but a passive indicator is not going to change >> the status quo if it's shown 42% of the time (or 67% of the time, in >> Firefox's case). > > That's part of why we plan to gate the change on increasing HTTPS > adoption. Gervase liked that idea, too. > >> Other passive indicators (e.g., Prop 65 warnings if you >> live in California, or compiler warnings that aren't failures) haven't >> succeeded in changing the status quo. > > Citation needed...? > > (If you're arguing that we should all compile with -Werror, I'll > surely agree with you. Chrome does. But I assume you did not mean to > suggest we should do the equivalent for HTTP navigation, at least not > yet...) > >> Again, what's the action that typical >> users are going to take when they see a passive indicator? > > First, keep in mind that you can't argue that showing the passive > indicator will be both ignored and crying wolf. It's one or the other. > Which argument are you making? > > That said, > > * Those few users who do look at it will at least be able to discern > the truth. Currently, they cannot. > > * Site operators are likely to discern the truth, and may be motivated > to deploy HTTPS, if they feel that their user base might demand it. > (Complementarily, as site operators seek to use more powerful, > app-like features like Service Workers, they will increasingly deploy > HTTPS because they have to.) > > * As we make the web more powerful and more app-like, we (Chrome) seek > to join the "what powerful permissions does this origin have?" views > and controls with the "by the way, how authentic is this origin?" > view. (See attached Chrome screenshot, showing that they are already > significantly merged. In my other window I am working on a patch to > make this easier to use.) As users become increasingly aware of these > controls, they may become increasingly aware of the authenticity > marking. And then they may make decisions about granting permissions > differently, or at least with more information. Basically, "how real > and how powerful is this origin" is gradually becoming a first-class > UX piece. > > But, fundamentally, we owe it to users to tell the truth. I don't see > that the status quo is defensible.
Received on Thursday, 18 December 2014 21:46:44 UTC