Privacybadger: emoji.tapatalk-cdn.com

[terrorist96]

https://forum.xda-developers.com/chef-central/android/tool-universal-htc-ruu-rom-decryption-t3382928/post73028480#post73028480

emoji.tapatalk-cdn.com blocks two emojis

[cowlicks]

It looks like emoji.tapatalk-cdn.com is not blocked in the code you have posted here. Is it blocked in the popup?

[terrorist96]

Yep.

[terrorist96]

[terrorist96]

[cowlicks]

Ah, I think we need the results for "tapatalk-cd.com".

On a related note, this is an example where #1430 would be helpful since it would have handled that for you.

[terrorist96]

[cowlicks]

We are not actually prepared to fix this from our end. From my comment in #1531

We are currently only blindly able to fix some site bugs, for examlpe in #1493

there is a blocked fqdn that is not tracking on the reported 1st party origin
the blocked domains' fqdn is different from its base domain
none of the basedomains in the snitch_map have the tracking basedomain. I don't even know if the snitch maps are derived from FQDN's.

So there is no obvious way to find where the original tracking actually happend
and reproduce it.

Once we are doing a better job tracking these trackers, we'll be better able to fix this. However, for now, I think the best thing you can do is set the slider to yellow for this domain.

[ghostwords]

@terrorist96 Just checking, are you using the latest Privacy Badger, version 2017.7.24?

[ghostwords]

@cowlicks, I don't understand what you mean by "none of the basedomains in the snitch_map have the tracking basedomain. I don't even know if the snitch maps are derived from FQDN's".

The base domain of emoji.tapatalk-cdn.com is tapatalk-cdn.com. It is indeed in snitch_map three times. It looks like uploads.tapatalk-cdn.com was seen "tracking" on those three sites and was then set to be "cookieblocked" since uploads.tapatalk-cdn.com is on the yellowlist. emoji.tapatalk-cdn.com is being blocked because its base domain, tapatalk-cdn.com, is still set to be blocked and the "emoji" subdomain is inheriting that.

To me the mystery is why the base domain is still set to blocked. Shouldn't it have been set to "cookieblock" by setupSubdomainsForCookieblock?

This might be a bug with the way we handle adding new items to the yellowlist. The "uploads" subdomain was added in https://github.com/EFForg/privacybadger/issues/865, but that didn't update its base domain to cookieblock, right? Whereas going through blacklistOrigin to block uploads.tapatalk-cdn.com after it was already on the yellowlist would have updated its base domain to cookieblock.

[ghostwords]

If that's what's going on, this bug is related to #1474, which concerns removing items from the yellowlist.

[terrorist96]

@terrorist96 Just checking, are you using the latest Privacy Badger, version 2017.7.24?

Yeah

[ghostwords]

Ah, setupSubdomainsForCookieblock doesn't set the base domain to cookieblock, it sets the domain to cookieblock. So while we probably have discrepancies between adding to the yellowlist after related domains have gotten blocked and blocking domains after related domains have been yellowlisted, this doesn't seem to be one of them.

[ghostwords]

I too would like to know why Privacy Badger decided to block uploads.tapatalk-cdn.com. @terrorist96 Do you have any cookies or localStorage set for the "uploads" subdomain?

It seems like we should add tapatalk-cdn.com to the yellowlist (instead of just "uploads", but removing anything from the list is inadvisable, for a while anyway, until few people use versions earlier than 2017.7.24).

[terrorist96]

No cookies for the upload subdomain, but one cookie for tapatalk-cdn.com itself (named __cfduid). Not sure how to check for localStorage items. Searching for that in Chrome's settings menu returns no results.

[ghostwords]

OK, thank you! localStorage would be displayed in the same place as cookies on chrome://settings/content/cookies.

That's the Cloudflare cookie that we started ignoring to fix #1237, the fix released as part of 2017.5.9. That tells me Badgers that haven't previously learned to block tapatalk-cdn.com will never learn to block tapatalk-cdn.com, and that the proper fix to #865 would have been to ignore Cloudflare cookies.

So I am not sure there is anything to do here then.

[terrorist96]

But what about those that did learn to block it (like mine)? I'm sure I'm not alone.

[terrorist96]

Also, I should note that I have 3rd party cookies disabled via Chrome's settings, so that could also be why I don't have any tapatalk cookies.

[ghostwords]

We've got five error reports in total for tapatalk-cdn.com, the most recent from July 4th this year. So yes, this does happen occasionally still, my guess is only to people who ran into the base domain getting blocked before we started ignoring Cloudflare. We never migrated Cloudflare-blocked domains, I wonder if we still should. We could also fix this particular case of overblocking by adding the base domain to the yellowlist.

Being able to explain why a domain was blocked would help with debugging in the future: #963. It would resolve any uncertainty about the source of blocking as well (maybe it wasn't Cloudflare cookies, although probably was).

[terrorist96]

I think adding it to the yellow list would be the simplest and most immediate solution.

[cowlicks]

Re: https://github.com/EFForg/privacybadger/issues/1493#issuecomment-318681126

@cowlicks, I don't understand what you mean by "none of the basedomains in the snitch_map have the tracking basedomain. I don't even know if the snitch maps are derived from FQDN's".

Sorry I'll try to explain. When I visit the domains listed in the snitch_map for "tapatalk-cdn.com" I don't see "tapatalk-cdn.com" or any of its subdomains. It is possible that the domains in the snitch_map, could be derived from some FQDN. So I don't know if I'm visiting the correct domain.

[ghostwords]

@cowlicks @terrorist96 Ah, agreed, we don't know if the snitch map entries came from emoji.tapatalk-cdn.com or some other tapatalk-cdn.com subdomain. This is why we should make sure to run our debugging queries for the base domain (or even just a snippet of it). const STR = "tapatalk-cdn"; or const STR = "tapatalk-cdn.com"; are more useful than const STR = "emoji.tapatalk-cdn.com";.

We also don't know where within the sites in snitch map the tracking occurred, or what the tracking consisted of, but this usually just means more work for us in figuring out what happened exactly; not knowing exact details shouldn't stop us outright.

I have run into broken site issues I've absolutely been unable to reproduce in the past, until realizing the issues all pointed at a localStorage detection-related bug (#1403), for example.

[cowlicks]

@ghostwords we also do not know if the domains in the snitchmap are derived from an FQDN, so we don't even know what site the tracking actually happened on. For example, tapatalk-cdn.com might have been seen on some.suddomain.xda-developers.com, but we wouldn't know this. Likewise for the other snitchmap entries.

[terrorist96]

In this case, it more than likely occurred on forum.xda-developers.com :smiley: