I like this idea though, indeed I like the idea of the web being https by default.
Where I find it funny in relation to email is that email passes over the internet in plain text and without Google adding PGP or something to Gmail the benefits for this aren't great.
Considering the current incident with China, and the hacking in December. https for gmail will prevent snooping of gmail, but wouldn't prevent the email being intercepted if sent to or CC'd anyone on any other domain where the traffic crossed China (ot it could offer low-hanging fruit in other countries as relays may not be as secure).
It does help increase intra-Gmail security (as using the web to author would author it being visible before being sent) but it wouldn't wholly secure the entire transaction end to end which surely should be the goal.
I'd love to see Google take steps to offer a public key encryption system for Gmail that could secure the email even as it passed over other systems and to recipients in potential hot-zones.
Actually, not all email passes in plain text - a decent chunk (although doubtless a minority) uses SMTP over TLS.
Many servers have it configured, and if it's available on the destination almost all MTAs will use it to send mail to other servers, even if they don't support receipt of mail in this way.
Ignoring the technical issues, Google doesn't want your free Gmail encrypted end-to-end because they rely on searching your email to serve you targeted ads (and deal with spam).
Intercepting email between SMTP servers is a much harder problem than intercepting email to and from the mail client, even if both are unencrypted. The latter requires only that the ISP or the LAN of the user to be compromised. If you ever connect through an insufficiently secured WAP then all of your email could be compromised.
However, using a secure link from the client to the mail server cuts down on the area of vulnerability significantly. Now your personal system needs to be compromised, or the backbone internet links between mail servers used by people who contact you need to be compromised. This is a significantly higher bar. Granted, if you want to maximize email security then public/private key encryption is the way to go, but the simple step of using https between the client and the server is a very significant improvement.
> I like the idea of the web being https by default.
So that proxies become useless, the connection gets slower, data traffic increases, firefox users are plagued with warnings because people don't have proper certificats etc.
At least 95% of the web-pages people are viewing are pointless bullshit anyway. It's not as if the casual internet user were using the potential freedom of the internet for anything good.
Messaging and similar services should be private of course.
It could be completely coincidental. Their China blog post suggests that unauthorized access to Gmail account was gained through phishing and malware - something https, sadly, does not protect against.
This is old news for people who know (or care) about https. But it is new news in terms of the Goog vs. China cyber war. The winners in all this will most certainly be Google customers outside of China because Google will continue hardening their defenses which will make computing with Google safer for the end user. Will it help users in China? Time will tell...
Good that it's still possible to turn it off. In Iran 2-3days before and after each political event government restricts access to only :80. No IMAP no POP3, and no :443.
I guess they put this off mainly because of the performance hit. I found the following quote regarding HTTP vs HTTPS performance on SO:
One point that has been brought up by several others is that SSL handshaking is the major cost of HTTPS. That is correct, which is why "typical session length" and "caching behavior of clients" are important.
Many, very short sessions means that handshaking time will overwhelm any other performance factors. Longer sessions will mean the handshaking cost will be incurred at the start of the session, but subsequent requests will have relatively low overhead.
I'd be surprised if the answer wasn't latency - this kind of server load would be easy to scale with their engineering resources and they're big on the competitive advantage of user-perceived performance.