Closed terrorist96 closed 7 years ago
https://theintercept.com/2017/01/18/trump-education-nominee-betsy-devos-lied-to-the-senate/
content.jwplatform.com
videos-f.jwpsrv.com
and assets-jpcust.jwpsrv.com
breaks the video thumbnail
I can't get Privacy Badger to learn to block content.jwplatform.com
even after opening every one of these links, both with development and production versions of Privacy Badger in Chrome.
Could you share your snitch_map
for jwplatform.com
? Also, does a new install of Privacy Badger learn to block content.jwplatform.com
for you with these links (in a new browser profile)?
"medicaldaily.com", "digitaltrends.com", "thekitchn.com"
No, I can't get content.jwplatform.com
to get blocked in a new profile. So the issue is with my Chrome profile? I thought PB is supposed to get better over time, not worse. o_O
Ha yeah theoretically ... well, hopefully we'll get to the bottom of this.
Might another extension (you use Chrome, right?) be interfering with Badger's learning process?
Yeah I use Chrome. My other extensions are ABP, HTTPS Everywhere, Ghostery, Referer Control, and some other non-content related extensions. I could see some of these maybe blocking something before PB has a chance to, but I don't see why that should interfere with its learning process (since this is an issue where it is overblocking, not underblocking).
You could try finding the conflict (if there is one) by picking half your extensions to install alongside Privacy Badger in a new profile to try to replicate content.jwplatform.com
getting auto-blocked. If that doesn't do it, try the other half. If you can reproduce, halve the extension list again to try in yet another new profile.
I have a separate test profile with the same content blocking extensions on my main profile, and I can't reproduce the issue there either, so no need in narrowing down my extensions. It doesn't seem to be a conflict issue. It seems to me that PB somehow blocked it by accident at one point (maybe in a previous version that caused it) and is being stubborn about unlearning that in the current version. Or maybe due to an old version of a rule in HTTPS Everywhere (since I know that has a JW rule) caused interference? I remember I had a similar issue with player.brightcove.net at one point. It was being blocked on some profiles but not others, despite it being added to the cookieblock list. But eventually, it learned to unblock it on all profiles.
We may need to add an option to have Badger collect extra information about why exactly a domain gets auto-blocked (request URL, cookie contents (if cookie), etc.).
Good idea. The snitch map as it currently stands isn't as helpful as it probably could be.
While working on revealing Badger's reasoning, I found what is probably the bug responsible for this and lots of other site breakages.
Badger performs tab and frame data bookkeeping in one place, while checking which requests are responsible for tracking activity in a different place. The problem is that these two places can get out of sync; the tracking checks can happen after tab and frame data for the request got cleaned up.
One way to trigger this is by reloading a page while it is still in the middle of loading. Let's say the page has a YouTube video in a nested frame, and the video writes data to localStorage. When Badger can't find frame data for the actual frame it is looking for, it defaults to getting data for frame 0 (the main document for the tab). Since Badger was trying to get frame data to mark that frame as having "supercookie" (localStorage) tracking (such as from the embedded YouTube video), it marks the main document instead, which leads to all subsequent third-party frame 0 resources in that page load getting marked as trackers.
The fixes (#1403, #1428) went out with Privacy Badger 2017.6.13.1, but I didn't add jwplatform.com
/ jwpsrv.com
to the list of domains to forget because I ran into at least one instance of cookies being set. I think the misattribution bug contributed to these domains getting blocked, but it probably wasn't the whole story.
If cookies were detected, adding it to the cookie block list should be sufficient, no? Yellowlist fixes the issue.
Interestingly, some JW players are not blocked though.
Example: https://solarmoviez.to/movie/before-i-fall-20327/623089-7/watching.html
The video player is JW (you can tell by right clicking on it), but content.jwplatform.com
isn't detected by PB.
The player on solarmoviez.to
is served by cdn.solarcdn.ru
.
When I said I ran into an instance of cookies being sent, I meant to say localStorage being written.
I just rechecked all the URLs above, and the only place I see any tracking is on The Intercept page, where a "jwplayerLocalId" localStorage key is set by content.jwplatform.com
.
http://mashable.com/2016/11/07/reborning-babies/#EIhpNz8Wiaqp
content.jwplatform.com
breaks the video. Move to yellowlist.