here's the bug. star it.

> See, I use foxit. I like foxit.

you may be interested to know that Chrome seems to be using Foxit for their plugin:
http://googlesystem.blogspot.com/2010/08/google-chromes-pdf-plugin-uses-foxit.html

plus additional sandboxing, for extra security.

Here's how it works: when Chrome 8 is branched to beta, trunk becomes Chrome 9. At first the difference is purely cosmetic.
But yes, Chrome N+1 is born at the same instant Chrome N goes to beta. From the next canary or dev release on you will see Chrome N+1 versions, though differences between them and Chrome N (already in beta) may be very small.

It appears that Chrome is using Foxit library.
Can't verify it because the codereview link they provide doesn't work anymore.

> These are issues that don't exist in IE or Chrome. Just Chrome Frame.

have you considered reporting them?

java is in heavy use at google but in other places - there is no java involved in serving a search query. with search, it's c++ all the way down.

> root certificates for Google's HTTPS site

there is no such thing as a "root certificate for site". there is a "certificate", issued to a certain "subject" for a certain "canonical [site] name".

> 1024-bit RSA keys.

this is true.

> Google's HTTPS site use MD2

this is not. you can test it yourself:

$ openssl s_client -connect www.google.com:443 /dev/null | openssl x509 -text ...
                        Public Key Algorithm: rsaEncryption
                        RSA Public Key: (1024 bit) ...
        Signature Algorithm: sha1WithRSAEncryption

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

RFC2616, 15.1.3

all browsers follow this.

actually, your browser will do this for you anyway:

RFC 2616, 15.1.3:
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

> Maybe that cert has been compromised by a Chinese insider.

i don't see mail.google.com's cert on any revocation lists, so it's probably ok.
given the approach google has taken in other aspects of the unfolding drama,
i think it's a fairly safe bet that it would've been revoked by now if there was any doubt that it may have been compromised.

having intercepted a single request containing cookies, you gain full access to the account, potentially forever (depends on server's expiration policy and your ability to keep the sessions alive). so yes, for all intents and purposes it is just as bad.

> As usual, Google leads the pack in creating groundbreaking technology, and comes in dead last in dealing with the boring stuff, like dealing with security issues

and now you show me another free mail service of any significance that has IMAPS, POP3S, SMTPS and now HTTPS (yes, all with *S, because Gmail requires you to use SSL for SMTP, POP3 and IMAP, and has been doing so since the very beginning, HTTPS was available for use for a while, though not required or offered by default).
if google is dead last, the internet must be swarming with secure mail services, right? ...right?

starting at certain bitrates, there's simply not enough processing power to apply compression.
modern general purpose CPU can gzip at just tens of megabytes per second, simpler and less effective algorithms may give you couple hundred MBytes/sec, which is still just a couple Gb/s.

now imagine you have couple dozen 10 gig ports, in and out. and that's just the beginning, some high-end gear has 100+ 10G ports, all lit.
specialized ASICs can help, but they're not free either and ultimately don't take you very far, especially after throwing in all that memory required for processing.
all in all, none of the high-end routing or switching gear does compression nowadays, it's simply not worth it, in dollars and milliseconds of added latency.