Posted by Alma Whitten, Software Engineer, Security & Privacy Teams (Cross-posted from the Google Online Security Blog ) letter today urging Google to strengthen its leadership role in web application security, and we wanted to offer some of our thoughts on the subject.
We've long advocated for — and demonstrated — a focus on strong security in web applications. We run our own business on Google Apps, and we strive to provide a high level of security to our users. We currently let people access a number of our applications — including Gmail, Google Docs, and Google Calendar, among others — via HTTPS , a protocol that establishes a secure connection between your browser and our servers. choose to use HTTPS in Gmail, our systems are designed to maintain it throughout the email session — not just at login — so everything you do can be passed through a more secure connection. Last summer we made it even easier by letting Gmail users opt in to always use HTTPS every time they log in (no need to type or bookmark the "https").
Free, always-on HTTPS is pretty unusual in the email business, particularly for a free email service, but we see it as an another way to make the web safer and more useful. It's something we'd like to see all major webmail services provide.
In fact, we're currently looking into whether it would make sense to turn on HTTPS as the default for all Gmail users.
We know HTTPS is a good experience for many power users who've already turned it on as their default setting. And in this case, the additional cost of offering HTTPS isn't holding us back. But we want to more completely understand the impact on people's experience, analyze the data, and make sure there are no negative effects. Ideally we'd like this to be on by default for all connections, and we're investigating the trade-offs, since there are some downsides to HTTPS — in some cases it makes certain actions slower.
We're planning a trial in which we'll move small samples of different types of Gmail users to HTTPS to see what their experience is, and whether it affects the performance of their email. Does it load fast enough? Is it responsive enough? Are there particular regions, or networks, or computer setups that do particularly poorly on HTTPS?
Unless there are negative effects on the user experience or it's otherwise impractical, we intend to turn on HTTPS by default more broadly, hopefully for all Gmail users. We're also considering how to make this work best for other apps including Google Docs and Google Calendar (we offer free HTTPS for those apps as well).
Stay tuned, but we wanted to share our thinking on this, and to let you know we're always looking at ways to make the web more secure and more useful. Update @ 1:00pm : We've had some more time to go through the report. There's a factual inaccuracy we wanted to point out: a cookie from Docs or Calendar doesn't give access to a Gmail session. The master authentication cookie is always sent over HTTPS — whether or not the user specified HTTPS-only for their Gmail account. But we can all agree on the benefits of HTTPS, and we're glad that the report recognizes our leadership role in this area. As the report itself points out, "Users of Microsoft Hotmail, Yahoo Mail, Facebook and MySpace are also vulnerable to [data theft and account hijacking]. Worst of all — these firms do not offer their customers any form of protection. Google at least offers its tech savvy customers a strong degree of protection from snooping attacks." We take security very seriously, and we're proud of our record of providing security for free web apps.
iGoogle's gmail widget does not support viewing https accounts. Please consider fixing this before deploying large-scale.
ReplyDeletePersonally I opted remove the widget from my homepage and keep using https for my account.
I really enjoy reading your blog.The keyword sniping links are awesome.Keep it up.Thanks for sharing with us.Keep blogging.
ReplyDeleteIt's a very informative post. I totally agree with Hashbrown.iGoogle's gmail widget doesn't support the https account. So you should consider fixing this before deploying large- scale.Thanks for the information.
ReplyDelete