Key-based cookie tracking

PrivacyBadger only checks the entropy of cookie values, but not the keys. I wrote a [PoC tracker](https://github.com/roguism/privacybender) that can exploit this bug by storing tracking ID's in the key.

To determine if this is being used in the wild, I wrote a chrome extension that scraped the Alexa top 1000 sites, logging each third-party cookie that that escaped notice at [this point](https://github.com/EFForg/privacybadgerchrome/blob/master/src/heuristicblocking.js#L548). I repeated this scraping three times (result sets [1](http://pastebin.com/TsKiRtHD), [2](http://pastebin.com/hXjdMsxb), [3](http://pastebin.com/V1JgdNPm)), each time starting with a clean browser with no cookies. If an ad-server assigns a new tracking-id to every clean client, then that should show as two different cookies. Sure enough, from sets two and three, we have:

```
"ctnsnet.com" : [
"opt=0",
" cid_dbc00370ddb64184b4f5f0719cbf9281=1"
]

"ctnsnet.com" : [
"opt=0",
" cid_f22a8562235a4abbbb32fb41638ec49d=1"
]
```

If the "id" prefix didn't give away it's purpose, 16 bytes is certainly enough entropy for a tracking cookie (ctnsnet.com is a Russian IP with DNS whois privacy, and visiting that url simply returns an error).

There may be other trackers, that this test didn't catch; perhaps they only appear once logged into many of these services. Or perhaps by different user-agent/IP fingerprint. Real-world data may show more.
## Solutions
1. Of course the simplest solution is to blacklist ctnsnet.com, however this doesn't cover future cases. Is there an algorithmic approach?
2. One could attempt to apply the current approach with values to the keys, however that seems infeasible. There there is large amount of variability across the web for key names, too large to enumerate. Although most benign websites will have fixed cookie keys, each website developer will pick their own. Browsing through the result sets demonstrates this.
3. Ultimately, the client must learn how much entropy is in the cookies from a given third party, in keys and values. Entropy has no meaning in isolation, but must be understood in the context of what other cookies that server is distributing to other clients. This implies sharing cookies with other clients, either through a trusted third party or in a decentralized manner. However, the former involves an unsettling amount of trust in the third party (capable of revealing the browsing patterns of every user), and the latter has similar issues. While I believe the decentralized solution could possibly be made secure with some hashing and crypto-magic, such a solution would be a massive and failure-prone undertaking for addressing what is currently only evidenced in one site.
4. The best solution may be to _become_ the second client you're comparing your cookies against. This clear-cache/re-request/compare method is what revealed the tracker anyway. Caution should be exercised in the timing of the re-request; a smart tracking server could reissue the same tracking cookie when requests from the same user-agent/IP in a short time frame. Because PB makes no assurances about tracking during the initial training window, we are free to send this comparison request at our leisure, preferably at some random interval.

Start with src/heuristicblocking.js at the referenced point where third-party cookies escape detection, then review the surrounding cookie-entropy logic. Compare the reported key-based examples with the current behavior and define a concrete algorithm and validation cases before implementation; the issue does not specify an accepted solution or completion test.

Written by the indexing model from the issue text.