Here's my theory as to how it works:

The CPU generates a session key, encrypts it using the video site's public key (which comes from a certificate signed by Intel which is verified by the CPU) and sends this encrypted session key to the video site.

The video site then decrypts the encrypted session key using their private key, and then uses the session key to encrypt the video stream.

The CPU then takes the encrypted video stream, decrypts it with the session key, then produces an HDCP stream[1] which is sent out over the video ports.

All you need for this is instructions for:
- init_session(certificate_signed_by_intel) -> (context, session_key_encrypted_by_cert_public_key)
- convert_stream_block_to_hdcp(context, encrypted_stream_block) -> hdcp_stream_block

and since the session key never leaves the CPU unencrypted, and the stream is never emitted unencrypted there's nothing to tap.

[1]: yes HDCP is broken, but Intel barely admits that.

Here's my three favourite language flaws, which make the language nearly unusable for non-trivial projects:

• Variables are global by default, leading to accidental memory leaks, conflicts and various other fun things.
• A lack of namespaces.
• Lack of block scope (despite the fact the language has blocks), i.e:

  function a() {
  var b = 1;
  {
  var b = 2;
  }
  alert(b);
  }

  will alert 2.

Not really, no.

For the NTP pool you send and recieve time data; funnily enough the time is public information.

Switching your DNS servers to OpenDNS means you end up sending them every domain you visit, and apparently every Google search too.
Most people would probably want their search terms and domains they visit to stay private, so your analogy between the NTP pool and commercial DNS providers breaks down here.

(note: I'm not implying sending your DNS data to OpenDNS means it's made public!)