> On 29 January 2016 at 13:09, <richard@leapbeyond.com> wrote: > > > There is little inherently "broken" about HTTP (without the "S"). It > has security limitations which it's audience accepts. Over the years > people have been trained to look for proactive signs of security (https, > green lock, etc) when they are doing activities that are sensitive (email, > banking transactions, etc). > Also, "email" only in the last several years hit the point where it was generally considered "sensitive" and encrypted by default. And it was Google then who led by enforcing HTTPS for Gmail in early 2010: http://www.eweek.com/c/a/Security/Google-Gmail-Switches-HTTPS-to-Always-on-by-Default-656394 Most other companies didn't move until the potential dangers were made more viscerally real to them with Firesheep, which came out in October 2010. And so now email is "sensitive" because of a combination of proactive and reactive leadership that changed the status quo. I don't remember feeling annoyed or worried about my webmail being served over plain HTTP in 2008. I didn't "accept" the security limitations -- I didn't understand them. Other people had to realize on my behalf that I was in danger, and I am glad that they did. You may personally accept HTTP's security limitations, but that doesn't mean anyone is obligated to serve you plain HTTP, and it doesn't mean anyone ethically has to refrain from strongly incentivizing websites to give users the security they deserve. -- Eric > > There is a ton of UI/UX research that people do not notice the absence > of positive indicators. One can train as much as they want, but the > training has not worked to date. > > > -- > Eitan Adler > > -- > You received this message because you are subscribed to the Google Groups > "Security-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to security-dev+unsubscribe@chromium.org. > > -- konklone.com | @konklone <https://twitter.com/konklone>
Received on Sunday, 31 January 2016 07:53:59 UTC