Hacker News Reader

Comment by ffpip | Hacker News Reader

FYI Google fonts are also loaded from the google.com domain. They can associate your login cookies with every page you visit.

As you can see, it is very sneaky by using CNAME Cloaking - https://i.imgur.com/VB2DB75.png

The request is to fonts.gstatic.com, but it resolves to gstaticadssl.l.google.com

Tracking using CNAME cloacking - https://medium.com/nextdns/cname-cloaking-the-dangerous-disg...

View on HN

Correct me if I'm wrong, but a CNAME "redirect" on the DNS level does not change the page origin. `fonts.gstatic.com` will only get the cookies set for `fonts.gstatic.com`, even if it is CNAMEd to a different domain.

I am not sure that’s true. Where is your proof... and Can’t they just ask you to set an A record btw?

Well, you can easily verify this by looking at your browser‘s request header. If the cookie is sent, you’ll see it in there for requests to the font cdn subdomain. (Hint: It‘s not.)

You are correct.

Wait, are you saying that if foo.example.com and bar.example.com are each CNAME records pointing at example.com (and the server has regular name based vhosts to isolate what is served for each), then browsers use a single cookie jar for foo and bar? So if the admin of the foo site and the admin of the bar site are adversarial, they can steal each other's cookies?

That doesn't seem right at all... I hope I am misunderstanding.

Now, if the admin of foo overrides the cookie scope to be *.example.com instead of the default foo.example.com, then yes it's expected that the admin of bar can steal foo's cookies. This is mentioned in the NextDNS Medium article you linked to, toward the end. This is definitely a "gotcha" situation but at least the default is safe, as far as I can tell.

Its false. CNAMEs are dealt with on the DNS level and are transparent to HTTP. It will use the origin the client connects with which is fonts.gstatic.com

I maintain a small hosts file project for blocking ads and tracking. I get so many complaints about blocking google fonts that I had to add a section to my README specifically for it [0]. I don't block google fonts, but I do block gstaticadssl.l.google.com and most blockers will block based on CNAME values now. Oh well.

[0] https://github.com/lightswitch05/hosts#google-fonts

Cookies gstatic.com wouldn't share to the resolved name would they? The cookie site is requested name not the resolved cname - or am I missing something?

> They can associate your login cookies with every page you visit.

This is why 3rd party cookies should always be disabled.

I'm glad pihole now blocks CNAMEs as well for known hosts :)

So they can also do it with A records and IP addresses. I guess the CNAME resolved to an IP address at the end anyway.

Reply on news.ycombinator.com