Yellowlist cdn.lib.newsvine.com

[eenblam]

Fixes #1293 by yellowlisting the cdn, as suggested.

Debug data from Privacy Badger:

**** ACTION_MAP for newsvine.com
VM378:5 cdn.lib.newsvine.com {
  "userAction": "",
  "dnt": false,
  "heuristicAction": "",
  "nextUpdateTime": 1502978092047
}
VM378:5 www.newsvine.com {
  "userAction": "",
  "dnt": false,
  "heuristicAction": "allow",
  "nextUpdateTime": 1502915615392
}
VM378:5 www.polls.newsvine.com {
  "userAction": "",
  "dnt": false,
  "heuristicAction": "",
  "nextUpdateTime": 1503070943545
}
VM378:5 newsvine.com {
  "userAction": "",
  "dnt": false,
  "heuristicAction": "allow",
  "nextUpdateTime": 0
}
VM378:7 **** SNITCH_MAP for newsvine.com
VM378:9 newsvine.com [
  "msnbc.com"
]

Cookie set by newsvine.com lasts for twenty years; obvious tracker.

Name: vid
Content: cba03db2435fb858ede5ee68277dcd9d
Domain: .newsvine.com
Path: /
Send for: Any kind of connection
Accessible to script: Yes
Created: Sunday, August 13, 2017 at 7:56:21 PM
Expires: Saturday, August 8, 2037 at 7:56:17 PM

[cowlicks]

As you recommended in the meeting today, these debug functions will be added to the background once #1430 is merged

[eenblam]

Cool. Happy to help with any finishing touches on #1430. Is any further action needed to address #1293?

[cowlicks]

It actually looks like newsvine and msnbc are owned by the same conglomerate link.

And the domain seems to only appear on msnbc.com link.

So it would probably be better to add this to the multidomainfirstparties. You should add an entry like this ['msnbc.com', 'newsvine.com'] (NB: we add etld+1 here). Then privacy badger will treat these domains as if they originate from they are first parties of each other. So PB won't block newsvine.com while on msnbc.com, and vice-versa.

[cowlicks]

@eenblam How'd you print that cookie info? I'm asking because the "Content" row could contain private information, like an authentication token. I want to make sure people don't accidentally post that by mistake.

It isn't private in this case, it is just a tracking token.

[eenblam]

I just included the same info from the example yellowlist PR.

The tracking that Privacy Badger sees comes from AWS "sticky sessions" load balancer cookies (the cookie info comes from Chrome's cookie details screen found under Settings > Advanced > Content settings > Cookies > Search cookies; here is the direct URL to the Cookies screen: chrome://settings/content/cookies)

Copypasta meant that I had to manually reformat it to get the style in the code block. So, people who do the same and know to be alarmed by sharing a token might notice it then, but it doesn't protect arbitrary users by any means.

An aside: to find this information, users have to do this:
Main repo >
Contributing >
Fixing broken sites >
...scroll all the way to the bottom... >
Example Yellowlist PR

And to get the rest of the debugging instructions, they have to follow an additional link out of the repo.

The last link is fixed by the PR that makes the function available in the background page by default, but overall the documentation structure makes it a bit hard to find.

[cowlicks]

@eenblam I agree. The intention of #1221 and #1430 is to streamline this process. Eventually the contributing.md or possibly an issue template will refer to these more explicitly. In the meantime, I'll add a link in the contributing document to the relevant gist. I super super want to avoid having a user accidentally post a cookie with an authentication token, so I'll probably remove that part until #1430 is merged, which avoids that problem.