[chromium-dev] Re: Chromium security UI choices
Please do. :) Adam On Wed, Nov 4, 2009 at 6:27 PM, Alex Faaborg wrote: > Earlier today at Mozilla the UX team along with Mike Beltzner and Johnathan > Nightingale spent a good deal of time discussing how we want to evolve the > security UI in Firefox. We are planning on making a few changes to our > current approach based on what worked (and didn't work) in Firefox 3 and > 3.5. Once we have sketches and mockups ready I'll post a link over to the > relevant dev.apps.firefox thread in case you want to track the design > process on our side. > -Alex Faaborg > > > On Nov 2, 2009, at 11:40 AM, Peter Kasting wrote: > > +CC Ian Fette, our security PM. > None of the issues you raise are new; we've considered them for a couple of > years. > In general I agree that positive security indicators are designed around the > idea that users should be alarmed by something's _absence_, which doesn't > work well with how people process things. Unfortunately, the negative > security indicators suffer from the problem that they will appear > near-constantly and users will quickly tune them out. > My personal opinion is that much of the problem stems from the false > conflation of "SSL" and "secure" in past and present browser UIs. I don't > think SSL is either comprehensible or relevant enough to users that we > should do things like color address bars and display lock icons. Instead, > it should be one element in a larger equation of "is this site trustworthy". > Note that when you click on the Chrome lock icon we do show you a couple of > different pieces of information to help you decide, but this could be > better. > I applaud Mozilla for having tried to tackle this a bit in their UI. I > think it is superior to ours. > On Mon, Nov 2, 2009 at 12:23 PM, Mike Hearn wrote: >> >> 3) Use of colored address bars is easily confused with the aesthetic >> choices of the website designer. > > The fact that we color our address bar is a continual pet peeve of mine. I > have pushed for its removal since its inception. I will happily champion > patches to get rid of it. > Colored address bars overstate the importance of an HTTPS connection, reduce > readability, and confuse people. It's no accident that basically all other > vendors have steadily moved away from coloring the whole bar. >> >> 4) Visual complexity is used as a metric for "how hard it is to copy", >> eg favicons or animations in the web page make things look authentic > > This isn't really a point that's relevant to Chrome itself, but to web page > authors. >> >> 5) Many users don't look for security indicators at all and have a >> poor or non-existent understanding of what the elements of a URL mean. > > I do think our host-versus-everything-else coloring in the address bar helps > with phishing URLs even if users can't articulate what the different colored > sections are. >> >> - Showing some permanent status indicator of "insecurity" that visibly >> changes, eg with a very noticeable animation, when tab status changes. > > I believe this will just add visual noise people will tune out. >> >> - Replacing the entire contents of the URL bar with the organization >> name when an EV cert is present rather than displaying both. > > This suffers from a number of problems, especially with editing URLs (there > are fixes to make the real URL "magically" appear when you focus the address > bar, but they feel gross), as well as obscuring your location on a site. >> >> - Use of "cheap" negative trust indicators, for instance if a page >> matches the regex "Bank of America" and is not the well known site a >> small bar or bubble could appear that says "This website is not owned >> by Bank of America". This would obviously have a high false positive >> rate, but that's OK because it simply asserts a negative rather than a >> positive. > > In addition to the "false positives make users ignore the metric" obvious > problems, this implicitly has false negatives since we can't do this for > every site on the web and if users grow to trust it they are at higher risk > when on pages for which we don't provide this. > Sadly, good UI for security is extremely difficult. > PK > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium security UI choices
Earlier today at Mozilla the UX team along with Mike Beltzner and Johnathan Nightingale spent a good deal of time discussing how we want to evolve the security UI in Firefox. We are planning on making a few changes to our current approach based on what worked (and didn't work) in Firefox 3 and 3.5. Once we have sketches and mockups ready I'll post a link over to the relevant dev.apps.firefox thread in case you want to track the design process on our side. -Alex Faaborg On Nov 2, 2009, at 11:40 AM, Peter Kasting wrote: > +CC Ian Fette, our security PM. > > None of the issues you raise are new; we've considered them for a > couple of years. > > In general I agree that positive security indicators are designed > around the idea that users should be alarmed by something's > _absence_, which doesn't work well with how people process things. > Unfortunately, the negative security indicators suffer from the > problem that they will appear near-constantly and users will quickly > tune them out. > > My personal opinion is that much of the problem stems from the false > conflation of "SSL" and "secure" in past and present browser UIs. I > don't think SSL is either comprehensible or relevant enough to users > that we should do things like color address bars and display lock > icons. Instead, it should be one element in a larger equation of > "is this site trustworthy". Note that when you click on the Chrome > lock icon we do show you a couple of different pieces of information > to help you decide, but this could be better. > > I applaud Mozilla for having tried to tackle this a bit in their > UI. I think it is superior to ours. > > On Mon, Nov 2, 2009 at 12:23 PM, Mike Hearn > wrote: > 3) Use of colored address bars is easily confused with the aesthetic > choices of the website designer. > > The fact that we color our address bar is a continual pet peeve of > mine. I have pushed for its removal since its inception. I will > happily champion patches to get rid of it. > > Colored address bars overstate the importance of an HTTPS > connection, reduce readability, and confuse people. It's no > accident that basically all other vendors have steadily moved away > from coloring the whole bar. > > 4) Visual complexity is used as a metric for "how hard it is to copy", > eg favicons or animations in the web page make things look authentic > > This isn't really a point that's relevant to Chrome itself, but to > web page authors. > > 5) Many users don't look for security indicators at all and have a > poor or non-existent understanding of what the elements of a URL mean. > > I do think our host-versus-everything-else coloring in the address > bar helps with phishing URLs even if users can't articulate what the > different colored sections are. > > - Showing some permanent status indicator of "insecurity" that visibly > changes, eg with a very noticeable animation, when tab status changes. > > I believe this will just add visual noise people will tune out. > > - Replacing the entire contents of the URL bar with the organization > name when an EV cert is present rather than displaying both. > > This suffers from a number of problems, especially with editing URLs > (there are fixes to make the real URL "magically" appear when you > focus the address bar, but they feel gross), as well as obscuring > your location on a site. > > - Use of "cheap" negative trust indicators, for instance if a page > matches the regex "Bank of America" and is not the well known site a > small bar or bubble could appear that says "This website is not owned > by Bank of America". This would obviously have a high false positive > rate, but that's OK because it simply asserts a negative rather than a > positive. > > In addition to the "false positives make users ignore the metric" > obvious problems, this implicitly has false negatives since we can't > do this for every site on the web and if users grow to trust it they > are at higher risk when on pages for which we don't provide this. > > Sadly, good UI for security is extremely difficult. > > PK > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium security UI choices
On Tue, Nov 3, 2009 at 12:54 AM, Mike Hearn wrote: > Yeah, I understood :) I haven't seen much discussion of these issues > so figured I'd try and start some - perhaps a lurker would be > motivated to work on it. Or maybe the Chrome team in a later release. We had a lot of discussion on this topic before we released the first beta because we wanted to get security right out of the box. I'd certainly be happy to revisit this topic when we have new information. It's tempting to re-arrange the deck chairs, so to speak, but we'd like to have solid data showing that we're going in the right direction first. > The force-ssl stuff seems like good progress. Still, Chrome takes a > less aggressive stance than Firefox on things like click-through > warnings and that doesn't seem like needing academic study to resolve. You say what, but we have numbers on how often users click through the certificate errors, and they're commensurate with the data in this study: http://www.usenix.org/events/sec09/tech/full_papers/sunshine.pdf I'm not sure the extra clicks are buying Firefox users much, if any, security. That particular study is really interesting because the authors find that users learned how to get past their even-more-elaborate error dialogs during the course of the study. Now imagine if they were to use the browser for more than an afternoon... I'd encourage you to think about this issue, come up with great ideas, and get the data to convince us. If there's one thing I've learned working on this project, it's that data trumps opinion every time. Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium security UI choices
Yeah, I understood :) I haven't seen much discussion of these issues so figured I'd try and start some - perhaps a lurker would be motivated to work on it. Or maybe the Chrome team in a later release. The force-ssl stuff seems like good progress. Still, Chrome takes a less aggressive stance than Firefox on things like click-through warnings and that doesn't seem like needing academic study to resolve. On Nov 3, 4:56 am, Adam Barth wrote: > I'm sorry if my email came off as dismissive. I really would like to > see some serious study of user interfaces for certificate errors. I > think everyone agrees that the current designs can be improved. We > even know how to measure success > (e.g.,http://www.usenix.org/events/sec09/tech/full_papers/sunshine.pdf). > What we don't know is how to design something measurably better. > > Adam > > > > On Mon, Nov 2, 2009 at 6:19 PM, Evan Stade wrote: > > I now have a new response ready for the next "click to select all" thread: > > > "the best way to make your case is to write an academic paper and > > conduct a user study that shows how the new UI out-performs the > > current UI." > > > -- Evan Stade --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium security UI choices
I'm sorry if my email came off as dismissive. I really would like to see some serious study of user interfaces for certificate errors. I think everyone agrees that the current designs can be improved. We even know how to measure success (e.g., http://www.usenix.org/events/sec09/tech/full_papers/sunshine.pdf). What we don't know is how to design something measurably better. Adam On Mon, Nov 2, 2009 at 6:19 PM, Evan Stade wrote: > I now have a new response ready for the next "click to select all" thread: > > "the best way to make your case is to write an academic paper and > conduct a user study that shows how the new UI out-performs the > current UI." > > -- Evan Stade > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium security UI choices
I now have a new response ready for the next "click to select all" thread: "the best way to make your case is to write an academic paper and conduct a user study that shows how the new UI out-performs the current UI." -- Evan Stade --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium security UI choices
On Mon, Nov 2, 2009 at 11:23 AM, Mike Hearn wrote: > I'm concerned about the way Chromium displays SSL security indicators, > which this blog post reminded me about: > > http://chrome.blogspot.com/2009/10/are-you-seeing-red.html > > There have been a few studies of SSL usability and the conclusions are > that Chrome-style UI does not work. For example see Dhamija, Tygar and > Hearst: > > http://portal.acm.org/citation.cfm?id=1124861 I agree that our certificate error UI can be improved. If you have concrete suggestions, the best way to make your case is to write an academic paper and conduct a user study that shows how the new UI out-performs the current UI. Failing that, putting together a nice set of mocks and a coherent argument are good ways to make your case. One thing that we are doing in Chrome 4 is implementing Strict Transport Security, which is a security feature that lets high-security sites opt out of these error pages: http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium security UI choices
[repost with my actual signup address] > Ah, I see. Yeah, I agree, that would clutter Chrome a bit. > > I'm not sure what direction to look in then. Things like SafeBrowsing > suffer from the imperfect protection problem, but they are still worth > doing. Only showing indicators when the site identity is strongly > verified requires the user to pro-actively think about security, which > we know doesn't happen. > > I think replacing the contents of the URL bar does still have promise. > 99% of the time it's full of unreadable junk anyway, so it feels like > the lowest hanging fruit for both cleaning up browser UI and improving > security in one go. > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium security UI choices
On Mon, Nov 2, 2009 at 2:28 PM, Mike Hearn wrote: > I disagree that the padlock animation would be adding visual noise, > I wasn't commenting about the animation, rather the presence of an indicator on "normal" sites. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium security UI choices
> The malware and phishing system does a pretty good job of detecting > phishing sites like this, which we get notified of via SafeBrowsing SafeBrowsing is a great system, but it ultimately relies on savvy users telling us that a site is phishing. Some scams are sufficiently good that the majority of users don't notice. For instance the paper I linked found that some phishing attacks had a greater than 90% success rate. Anecdotally, I've manually reported two Facebook related phishing scam sites (by the same people) that didn't enter SafeBrowsing for multiple days, probably because they were very sophisticated and not enough users reported them as phishing. I agree that the biggest problem with negative indicators is false positives, though given that a good phish needs to be very close to the real website, I suspect a regex/phrase based approach could be pretty well tuned. Phishers would of course tweak their site until the warnings did not trigger, but they'd have to deviate significantly from the real site, which should lower their success rate with high profile targets like banks or facebook. I disagree that the padlock animation would be adding visual noise, the existing static padlock is already visual noise - people don't understand it, so replacing it with something more noticeable that is harder to forge can only increase its effectiveness. It also provides an opportunity to educate the user a bit - if the padlock animation includes the words "Secure" or "verified to be yourbank.com" or whatever, they don't have to remain on the screen permanently ... they could fade out after a few seconds in such a way that it's obvious where to click to learn more or get them back (eg a bubble). That way the meaning of the padlock becomes more obvious and it doesn't rely on people getting the (fairly ropey) analogy. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium security UI choices
On Mon, Nov 2, 2009 at 11:23 AM, Mike Hearn wrote: > - Use of "cheap" negative trust indicators, for instance if a page > matches the regex "Bank of America" and is not the well known site a > small bar or bubble could appear that says "This website is not owned > by Bank of America". This would obviously have a high false positive > rate, but that's OK because it simply asserts a negative rather than a > positive. Obviously the real regexs would be based on the contents of > the actual BoA website rather than a simple phrase. The malware and phishing system does a pretty good job of detecting phishing sites like this, which we get notified of via SafeBrowsing, which we then wind up putting a full red page road block in the way when the user tries to navigate to them, so I don't think there's much else we should be doing on this particular issue. Erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium security UI choices
On Mon, Nov 2, 2009 at 1:10 PM, John Munro wrote: > > I do think our host-versus-everything-else coloring in the address bar > helps > > with phishing URLs even if users can't articulate what the different > colored > > sections are. > > Would this be a good time to revisit this issue: > > http://code.google.com/p/chromium/issues/detail?id=1971 No, there really hasn't been anything new that would change the decision there. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium security UI choices
> I do think our host-versus-everything-else coloring in the address bar helps > with phishing URLs even if users can't articulate what the different colored > sections are. Would this be a good time to revisit this issue: http://code.google.com/p/chromium/issues/detail?id=1971 Both Firefox and IE highlight the domain and not the subdomain to help the user spot phishing like http://yourbank.com.badsite.com/ but Chrome does not. John --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium security UI choices
+CC Ian Fette, our security PM. None of the issues you raise are new; we've considered them for a couple of years. In general I agree that positive security indicators are designed around the idea that users should be alarmed by something's _absence_, which doesn't work well with how people process things. Unfortunately, the negative security indicators suffer from the problem that they will appear near-constantly and users will quickly tune them out. My personal opinion is that much of the problem stems from the false conflation of "SSL" and "secure" in past and present browser UIs. I don't think SSL is either comprehensible or relevant enough to users that we should do things like color address bars and display lock icons. Instead, it should be one element in a larger equation of "is this site trustworthy". Note that when you click on the Chrome lock icon we do show you a couple of different pieces of information to help you decide, but this could be better. I applaud Mozilla for having tried to tackle this a bit in their UI. I think it is superior to ours. On Mon, Nov 2, 2009 at 12:23 PM, Mike Hearn wrote: > 3) Use of colored address bars is easily confused with the aesthetic > choices of the website designer. > The fact that we color our address bar is a continual pet peeve of mine. I have pushed for its removal since its inception. I will happily champion patches to get rid of it. Colored address bars overstate the importance of an HTTPS connection, reduce readability, and confuse people. It's no accident that basically all other vendors have steadily moved away from coloring the whole bar. 4) Visual complexity is used as a metric for "how hard it is to copy", > eg favicons or animations in the web page make things look authentic > This isn't really a point that's relevant to Chrome itself, but to web page authors. 5) Many users don't look for security indicators at all and have a > poor or non-existent understanding of what the elements of a URL mean. > I do think our host-versus-everything-else coloring in the address bar helps with phishing URLs even if users can't articulate what the different colored sections are. - Showing some permanent status indicator of "insecurity" that visibly > changes, eg with a very noticeable animation, when tab status changes. > I believe this will just add visual noise people will tune out. - Replacing the entire contents of the URL bar with the organization > name when an EV cert is present rather than displaying both. > This suffers from a number of problems, especially with editing URLs (there are fixes to make the real URL "magically" appear when you focus the address bar, but they feel gross), as well as obscuring your location on a site. - Use of "cheap" negative trust indicators, for instance if a page > matches the regex "Bank of America" and is not the well known site a > small bar or bubble could appear that says "This website is not owned > by Bank of America". This would obviously have a high false positive > rate, but that's OK because it simply asserts a negative rather than a > positive. In addition to the "false positives make users ignore the metric" obvious problems, this implicitly has false negatives since we can't do this for every site on the web and if users grow to trust it they are at higher risk when on pages for which we don't provide this. Sadly, good UI for security is extremely difficult. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
