Privacybadger: Move `*.cloudinary.com` to yellow list

[terrorist96]

Move *.cloudinary.com to yellow list. Blocks images: https://www.apartmentlist.com/cycle?category=E1&category_rank=0&index=0&pane=listing&rids%5B%5D=p68898&rids%5B%5D=p17422&rids%5B%5D=p26341&rids%5B%5D=p23136&rids%5B%5D=u42822807&rids%5B%5D=u42861803

[maxvonhippel]

I'm looking at the site example you gave with the latest build of privacy badger on the latest Google Chrome Canary and I don't see any issue. All the images show up, and Privacy Badger reports "no tracking" for res-4 and res-5.cloudinary.com. What am I not seeing? (New to the project so it's quite possible I'm missing something obvious, in which case I apologize)

[terrorist96]

PB learns over time what is tracking you. In your case, you most likely haven't browsed enough sites for PB to detect and block the aforementioned site.

[maxvonhippel]

Gotcha, thanks for the explanation. I'll start using canary as my default browser so I can accurately test stuff.

[phinze]

Just found this issue after getting broken images on grubhub.com from res.cloudinary.com. I'm a little confused about what the earlier conversation implies, but happy to submit a PR to yellowlist it if that makes sense!

[maxvonhippel]

@phinze do you get the same behavior? If so, I think you can go ahead and add to the list. (Previous conversation was because I did not get the same behavior).

[leggomuhgreggo]

Also seeing this behavior

[leggomuhgreggo]

I guess they collect fingerprinting info: http://cloudinary.com/privacy
Here's their policy on sharing info: http://cloudinary.com/privacy#section5

While the language seems to imply they aren't sharing for marketing purposes, there does appear to be some heavy nuance. Im not well enough versed in EULA language to say for sure that they're obfuscating, but it seems like a legit flag from PB.

[terrorist96]

https://www.crunchbase.com/organization/synapdx#/entity

crunchbase-production-res.cloudinary.com breaks images

[terrorist96]

https://www.valuepenguin.com/american-express-blue-cash-card

res.cloudinary.com blocks images.

[terrorist96]

http://www.voxelcloud.io/
res.cloudinary.com

[terrorist96]

https://www.bwpawards.org/winners2015

res.cloudinary.com

[terrorist96]

https://www.indiegogo.com/projects/liberland-settlement-association#/

[erikhuizinga]

http://www.made.com/

All their product images are delivered by Cloudinary.

[terrorist96]

@ghostwords should I make a PR adding cloudinary.com to the yellowlist?

[ghostwords]

I can't figure out how to get Privacy Badger to start seeing cloudinary.com domains as tracking.

@erikhuizinga Would you mind running debugging code as per instructions here for "cloudinary", and sharing what gets printed out?

[terrorist96]

Here's mine:

[terrorist96]

That's interesting that my output says the heuristic action for res and thefader-res subdomains are "allow" but they're clearly not:

[terrorist96]

@ghostwords if you can't reproduce, then it is probably another one of those sites that got blocked incorrectly in the past and needs to be migrated.

[terrorist96]

https://www.xfinity.com/mobile/
blocks images and fucks with the font.

[ghostwords]

Yeah, we should make everyone's Badger forget about this one. Unable to reproduce but still getting lots of error reports.

[terrorist96]

I suggest when you test for reproducibility, try on an old/experienced profile as well, cuz testing on a fresh profile is not representative of real-world situations.
You should probably create a new label for all these sites (suggest changing the unable to reproduce tags to needs migration or whatever)

[erikhuizinga]

My result for cloudinary.com:

**** ACTION_MAP for cloudinary.com
VM123:5 cloudinary.com {
  "dnt": false,
  "heuristicAction": "block",
  "nextUpdateTime": 0,
  "userAction": ""
}
VM123:5 res.cloudinary.com {
  "dnt": false,
  "heuristicAction": "block",
  "nextUpdateTime": 1504207187514,
  "userAction": "user_cookieblock"
}
VM123:5 res-1.cloudinary.com {
  "userAction": "user_cookieblock",
  "dnt": false,
  "heuristicAction": "",
  "nextUpdateTime": 1504093869687
}
VM123:5 res-2.cloudinary.com {
  "userAction": "user_cookieblock",
  "dnt": false,
  "heuristicAction": "",
  "nextUpdateTime": 1504221387657
}
VM123:5 res-3.cloudinary.com {
  "userAction": "user_cookieblock",
  "dnt": false,
  "heuristicAction": "",
  "nextUpdateTime": 1504367130750
}
VM123:5 res-4.cloudinary.com {
  "userAction": "user_cookieblock",
  "dnt": false,
  "heuristicAction": "",
  "nextUpdateTime": 1503953614019
}
VM123:5 res-5.cloudinary.com {
  "userAction": "user_cookieblock",
  "dnt": false,
  "heuristicAction": "",
  "nextUpdateTime": 1504191615302
}
VM123:7 **** SNITCH_MAP for cloudinary.com
VM123:9 cloudinary.com [
  "nedap-omnom.herokuapp.com",
  "lush.com",
  "urbandictionary.com"
]

[cowlicks]

What do you see when you run this in the extension console:

chrome.cookies.getAll({domain: "cloudinary.com"}, console.log)

Please don't post the "value" field of the cookie here, it may contain private sensitive data.

[terrorist96]

I get nothing. Length is 0.

[terrorist96]

https://health.usnews.com/doctors/albert-osbahr-382042
Profile image blocked. Two others blocked on right column.

[terrorist96]

https://www.rsk.co/

[terrorist96]

https://www.cloudbet.com/en/

[terrorist96]

https://d.tube/#!/v/haejin/xolanri5

[terrorist96]

http://culverlabs.co/

[ranrub]

@ghostwords Hi, I work at Cloudinary. This issue can be reproduced by visiting https://cloudinary.com and then visiting any of the sites mentioned. The problem is that google analytics on https://cloudinary.com sets a global domain cookie which is detected by PB as a tracking cookie.
Cloudinary is essentially a CDN similar to other domains on the yellow list. Our privacy policy specifically restrict tracking and we do not do it - it's not part of our business model in any way.

Can we add *.cloudinary.com to the yellowlist after all?

Thanks! I'm open to any questions about this.

[ghostwords]

Although I see Google Analytics on the Cloudinary homepage, I haven't been able to reproduce this way. For some reason I don't get the tracking cookie (in a new all-defaults Chrome profile with fresh Privacy Badger installed).

I have been able to reproduce, however, by first visiting http://culverlabs.co/ (an example page mentioned earlier in this issue), which seems to set a _mkto_trk (Marketo?) cookie on the .cloudinary.com domain. I think several more cookies get set there too, but one is enough for Privacy Badger. Visiting two more cloudinary.com-powered pages results in Privacy Badger learning to block Cloudinary domains.

As Cloudinary is a CDN that uses the same base domain across multiple customer accounts, this seems similar to https://github.com/EFForg/privacybadger/pull/1881#issue-170551628.

[ghostwords]

The cloudinary.com yellowlist update should be live. Privacy Badgers can take up to a day to get the latest yellowlist. To force an update, you could restart your browser (or just the Privacy Badger extension).

[terrorist96]

Are you saying yellowlist additions can now be pushed without having to release a new version of the extension?

[ghostwords]

It's been this case for a while ... since 2016.5.16 I think (c4024ea6ab37a3dc5d4f16757b47dde673e0b3cd). Edit: Before then too, as a "subscription", part of the original Adblock Plus infrastructure.