It's also possible to make the cookies non-exportable using a similar technique called channel binding[1], where the cookie is linked to the TLS channel it's minted over.
This is a lot more powerful than baking in the IP address when HMAC-ing the cookie but requires modification to the browser and server to get it up and running.
TLS client authentication allows the server to detect when an active MITM attempts to get into the connection[1]. This means that if you hold the theory that the NSA is acting as a MITM with Google's private keys, you also have to assume that they know they'll be detected the second anyone tries to use a client certificate to connect.
It bears repeating because this argument comes up in every PRISM thread...
The basics:
HTTPS is TLS/SSL transport level encryption of HTTP traffic (including HTTP headers).
The way it works is that client and server go through a handshake process where the server (and optionally client) present a public key and proof of ownership of a private key. The server public key is also normally signed by a certificate authority (e.g. Verisign), this is what is normally meant by a certificate.
Threat Models:
There are a number of different threat models that crop up when talking about TLS. I'll talk briefly about each below.
1. Compromised Certificate Authority (CA)
If the CA is compromised then the rogue CA can be used to create new certificates that claim to be for the intended target server (e.g. Google or Facebook)[1]. The fake certificate can then be used to launch a Man-in-the-Middle (MITM) attack where the attacker convinces a victim to connect to them, and creates two separate TLS connections VICTIM<-TLS1->MITM<-TLS2->SERVER. The MITM can see the unencrypted messages since the victim is encrypting to the key in the fake certificate.
Chrome's certificate pinning can be used to prevent this type of attack since the browser will check to see if the server has presented the _correct_ certificate for the intended server (by comparing public key fingerprints AFAIK). This attack can also be prevented if the connection is mutually authenticated by either a client certificate or an ephemeral ChannelID as discusses here[2].
2. Attacker has _correct_ private key for server
This threat model assumes the attacker has obtained the server's private key either via coercion / collusion. Certificate pinning doesn't prevent this type of attack.
2a. If the attacker is a passive attacker, meaning that they can only observe and record encrypted messages, then they can decrypt any messages that are sent over a cipher spec that doesn't have perfect forward secrecy (PFS). If the connection is setup using the Ephemeral Diffie-Hellman key exchange then the communication channel should be safe from a passive attacker. If the connection is mutually authenticated and the client certificate has not been compromised by the attacker, then the connection should also be safe from this attacker.
2b. If the attacker acts as a MITM then even PFS cipher specs can be compromised.
3. Attacker can break TLS encrypted channels and extract data without needing the keys
All bets are off if this can be done in a general way. There have been several attacks (BEAST, CRIME, Lucky13) that can extract small repeated bits of data (user authentication cookies), but no known attacks that can get at all of the data sent over a TLS encrypted channel.
AFAIK a strong key passphrase would be effective at protecting the private key while it's at rest (stolen laptop / hard drive). However as soon as the private key is pulled into memory for a signing or encryption operation the passphrase doesn't matter as the raw key is needed at that point.
As for your second question, there are techniques that perform static and dynamic analysis on javascript to try and detect illegal flows or taint propagation (without having to resort to monitoring the outbound network traffic). See [1] and [2] if you're interested in that topic.
If you're doing public key crypto on the client side in javascript, then the client side JS must necessarily have access to the private key (unless you have a TPM _and_ browser hooks to use it). This means that suddenly the private key is vulnerable to any XSS attacker that can inject itself into the same origin as your javascript crypto code.
That proposal is for an ephemeral, per gTLD client key and an example of mutual authentication that aims to defeat _active_ attackers (MITM).
Perfect forward secrecy in TLS is a bit different in that the ephemeral diffie-hellman key exchange sets up a shared key that is protected from a _passive_ attacker that observes the TLS encrypted communication and later gets a copy of the server's public key.
These are all things you should be doing anyway, even if you're pursuing a degree, and want to land a good software engineering job. So the "without a degree" caveat doesn't really matter.
The old compose _was_ broken (at least for me). I encounter the use case where I need to reference data from another email when composing a new message all the time. This used to mean opening up a new gmail tab, with the new compose I can draft an email while jumping around through archived messages. That's a big win.
This is a lot more powerful than baking in the IP address when HMAC-ing the cookie but requires modification to the browser and server to get it up and running.
[1] http://www.browserauth.net/channel-bound-cookies