Hacker News new | ask | show | jobs
by tomudding 1642 days ago
I think this sounds more like some sort of fingerprinting attempt. It good to see that random access to these kind of resources fails due to new(er) browser controls. However, this does not mean that the fingerprinting actually failed.

There is probably some way to determine if the request was denied automatically by the browser or manually by the user (e.g., time to get "response"), which is definitely something which can be used for fingerprinting.

Which reminds me of fingerprinting by tiny differences in the audio API provided by browsers [0]. Super interesting, but also a bit depressing. Also works for things like canvases and WebGL.

EFF allows you to check how fingerprintable your browser is [1]. Do note that the results may not be very accurate.

[0]: https://fingerprintjs.com/blog/audio-fingerprinting/

[1]: https://coveryourtracks.eff.org

9 comments

As someone working on exactly this type of stuff, your'e absolutely right. \*.safeframe.googlesyndication.com is Google's implementation of the IAB's safeframe standard[0], which is basically a cross origin iframe with an API that's exposed to the embedded 3rd party code (the ad). This is how its HTML looks like (some attributes removed for readability):

  <iframe src="https://\*.safeframe.googlesyndication.com/safeframe/1-0-38/html/container.html" title="3rd party ad content" sandbox="allow-forms allow-popups allow-popups-to-escape-sandbox allow-same-origin allow-scripts allow-top-navigation-by-user-activation" allow="attribution-reporting"></iframe>
As you can see, it has both sandbox[1] and allow[2] attributes. The former restricts certain behaviors of the embedded code (most notably, navigating the top window without user activation), and the latter restricts it from accessing certain APIs - this why the author saw errors in the console.

The script at https://cdn.js7k.com/ix/talon-1.0.37.js is an ad verification library developed by Verizon Media (formerly Oath), and it does, among other things,, fingerprinting for bot detection purposes (because they want to prevent ad fraud). It was served together with the actual ad media (so called "creative") into the safeframe.

This a relativity begin case. Iv'e seen much more terrible stuff, from fingerprinting for user taking to straight out malware being served in ads. It's a wild west (or web).

[0]: https://www.iab.com/guidelines/safeframe/

[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...

[2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...

great post.

That verizon JS is surprisingly not very obfuscated so if anyone is interested or just curious to hack around this is a great one to look at!

It looks like they are checking notificationPermission for notifications. stores (this.permissionStatus = "") & (this.notificationPermission = "")

I don't see any requestPermission() in the verizon js. So it's probably not the culprit?

I also don't think that would make sense for them to do it. it's probably a bad faith advertiser.

I'm not sure if cross origin permissions requests can be blocked by the parent safe frame yet? It looks like Chrome is proposing but I can't find any info on if it has been implanted? [1] [2]

-------

I really enjoy fingerprinting. Just feels like 'hacking' in the basic sense of poking around with things. Since I don't know enough to make actual complicated real vulnerability hacking. I've built a pretty big js file for our own ads analytics & tracking.

The verizon js has most basic common things but one that sticks out as cool is cssSelectorCheck & cssRuleCheck checks a few like div:dir(ltr) probably for eastern languages, and stuff like -moz-osx-font-smoothing: grayscale.

I also like the idea of adding HONEYPOT_TAGS looks like they are adding a button to check for auto click publisher fraud. But man they should have obfuscated that name....

One interesting idea to expand on the css testing they have started to use a small amount.

I've played with is placing actual unique CSS features and @supports in styles and then measuring them. Maybe use variables pass to js. Also a couple @media sizes to see if it's lying about size. Can also measure if css/svg animation is paused for view ability.

There are a ton of new css features that are implemented in different browser versions so likely high entropy. Also would love to learn paintWorklet just to know it for design and also seems like a big surface area (svg too).

I'm kind of surprised they aren't doing a RTCPeerConnection to try and get any IPs and it doesn't look like they are doing actual webgl / audio prints.

seeing the mime type checks is validating to me. that's the latest check I added it's pretty fast to execute i have something like 150 different codes/mime types loop through lol. Verizon is more sensible in checking only a couple lmfao

[1] https://docs.google.com/document/d/1iaocsSuVrU11FFzZwy7EnJNO... [2] https://dev.chromium.org/Home/chromium-security/deprecating-...

In my experience, with tools like Cover Your Tracks (apparently this is the new name for Panopticlick), the more you try and thwart fingerprinting, the more unique you appear. Although I still do everything I can to block and filter everything conceivable, I've given up on trying to figure out how identifiable I am on the web because it seems useless. If you don't try then you're identifiable, and if you do then you are probably more identifiable. Whatever.
I think this can also be a good thing, as long as you also use software which makes sure you have a distinct 'unique' fingerprint for each session.

Not that I am a huge fan of Brave, but I think they have implemented something like this for certain (or all) APIs. You will still have a unique fingerprint, but it should not match to any previous fingerprints you had in the past.

Edit: see https://brave.com/privacy-updates/3-fingerprint-randomizatio...

Fingerprinting with any accuracy is hard. As a legitimate use case, I had a corporate client who wanted their management software only accessible to sub-management employees from certain on-site locations. And they wanted this without sending those employees through a VPN or having a static IP for each location. So what I allowed them to do was to let a manager clear a given device's browser fingerprint (e.g. on the computer at a certain desk, or the employee's laptop) and be able to manage or revoke access for a limited number of those at a time.

This was fairly secure because even the same employee was unlikely to get the same fingerprint twice - it was only occasionally more convenient than generating a random hash everytime they opened the browser. It became a huge pain for managers to be called constantly on the weekend to remotely reauthorize the devices they'd just authorized a few hours ago, or when chrome suddenly updated itself for half the employees, so eventually we switched to a looser hybrid of fingerprints and local storage.

But isn’t this exactly what client-side certificates are invented for?
Yeah. Maybe out of paranoia, there was concern that a rogue employee could snatch a client side key and reestablish a session from outside. The fingerprinting was aimed at making any attempt at that easily identifiable.
I attack if from a different direction. All these companies want to fingerprint your device and track you for really one reason at the very end: showing you a targeted ad. Now what happens if they can't deliver that ad (because you have an adblocker installed), well all that tracking and fingerprinting they just did is moot, because there's nothing actionable they can do with it.

That's my rather naive opinion, idk am I just being naive?

I care a lot less about whether or not I see an ad than I do about the shadow dossier being compiled about me based on my browsing habits. So no, I don't think all the fingerprinting is moot. I'd rather see untargeted advertising than have my personal profile bought and sold.
Do you have ads blocked on google.com then? Because all ads there are contextual, not personalized.
That is wrong. Not sure where you got that idea from.
Search 'hr platform' and you only get ads for HR platforms. At no point will you see totally unrelated ads for stuff you didn't search for, since those will do much worse than contextual ones in the search context.
The problem is all activity gets sold to data brokers who build up a profile on you for future targeting.
Mimic latest iPhone. They are very hard to fingerprint.
Those anti-fingerprinting tools should make you appear as the most common iPhone as much as possible.
What is the most common iPhone? Should the common iPhone browser experience be scaled up to a desktop resolution, or should the desktop browser limit itself to the common iPhone resolution? What about mobile Safari bugs or misfeatures, such as webRTC shortcomings, or CSS bugs, or viewport resizing/scaling/zoom bugs?

There are so many possible variations that it seems like preventing fingerprinting by pretending you're something you're not would be an impossible task and makes you even more unique, not less.

You could pretend to be something you are not but if you keep giving the same info everything will be grouped together.
the basicest of basic

live laugh love as the user-agent

> the more unique you appear

If your fingerprint is unique and doesn't change then yes, you stand out. But if your fingerprint changes on every page load, then you become indistinguishable from other users.

> the more you try and thwart fingerprinting, the more unique you appear.

This is presumably because most people don't attempt to thwart fingerprinting.

If a particular feature behaves differently between the three most common browsers, it can be used to distinguish them. If you disable it, now you don't look like any of the most common browsers, which puts you in a category with a smaller number of people in it.

Solution: Get more people in it by having more people install anti-fingerprinting extensions etc.

> the more you try and thwart fingerprinting, the more unique you appear.

Not if you use Tor Browser.

Then i just get put on another list :)
You get put on a different list each time. :)
Or you get put on the same list again. And again. And again. The list of users that have only visited once and never came back (because when you came back you were sometime else).
"In my experience, with tools like Cover Your Tracks (apparently this is the new name for Panopticlick), the more you try and thwart fingerprinting, the more unique you appear."

In the interest of fair balance, I have had the opposite experience.

"I've given up..."

That's probably what "tech" companies are hoping you will do. I see this response repeatedly on HN when the fingerprinting topic comes up. I am wondering if the persons submitting these replies want others to "give up".

Is there a difference between users wanting to appear "the same" and a desire by users to stop supplying maximum amounts of free data/information to "tech" companies and exacerbating the problem of online advertising and associated surveillance.

If a user sends no fingerprinting data/information, then she might be "unique" because most users are sending excessive amounts of fingerprinting data/information. However, IMO, that is hardly a sound argument for continuing to send excessive amounts of fingerprinting data/information. I subscribe to the general principle of sending the least amount of information possible to successfully retrieve a page. This might be "unique" user behaviour, but I am confident it is the correct approach. The big picture IMHO is that "tech" companies, generally, are trying to collect data/information about users to inform online advertising. Uniquely identifying users is only a part of what they are trying to do.

It is a bit like telling a user to use/not use an ad blocker based on what other users are doing, so as to avoid being "unique". This might help with avoiding "uniqueness" but clearly there are gains to be had from using an ad blocker that are greater than the value of trying to appear "the same" as every other user.

Imagine users are all trying to appear exactly the same, so they embark upon coordinating with each other to make the exact same choices. It stands to reason that the number of choices each user has to make is going to be a factor in whether this is successful.

If every user is choosing to send large amounts of data/information (e.g., using browser defaults), then every user has to coordinate their choices on every single data point or bit of information. The higher the number of "correct" choices each user has to make, the less likely that all users succeed in being uniform. There are more chances for error. Whereas if we reduce the number of data points and bits of information so that every user is only sending one or two headers, with no Javascript, CSS, etc.,^1 then that is far easier for users to coordinate.

1. This has been tested heavily by yours truly for decades. One does not need a graphics layer or graphical browser features to make successful HTTP requests. I am not interested in being "invisible", I am interested in reducing the amount of free data/information I give to "tech" companies. Perhaps there is a difference between wanting to "blend in" and wanting to stop "feeding the beast".

"We do not know anything about User A. It looks like she is using TOPS-20 to browse the internet."

Is User A less or more likely to be unique. Probably more. Is User A a more or less viable target for online advertising. To me, it is the second question that matters the most.

"I've given up... That's probably what "tech" companies are hoping you will do.

You don't have "googlesyndication.com" blocked?

I prefer to take an "allow list" approach rather than "blocking". That domain is certainly not one I have any use for and it is not on the allow list. Not much for me to read or download from "googlesyndication.com". The browser I use to read HTML does not auto-load iframes. Iframes are not a "feature" that I find myself needing.
One thing you can do is use different computers for different purposes.
Just the other day I created a vm on my proxmox server of the Tails .iso. Makes it much easier to fire up rather than reboot something with a USB.
> the more you try and thwart fingerprinting, the more unique you appear.

That phenomenon is called the Streissand effect

https://en.wikipedia.org/wiki/Streisand_effect

> https://fingerprintjs.com/blog/audio-fingerprinting/

> It is particularly useful to identify malicious visitors attempting to circumvent tracking

Ah yes, the visitor trying to not be tracked is the malicious one. Barf.

The nerve of some people protecting themselves against browser exploits.
Must be terrorists or communists.
As someone working on exactly this type of stuff, your'e absolutely right. *.safeframe.googlesyndication.com is Google's implementation of the IAB's safeframe standard[0], which is basically a cross origin iframe with an API that's exposed to the embedded 3rd party code (the ad). This is how its HTML looks like (some attributes removed for readability):

  <iframe src="https://*.safeframe.googlesyndication.com/safeframe/1-0-38/html/container.html" title="3rd party ad content" sandbox="allow-forms allow-popups allow-popups-to-escape-sandbox allow-same-origin allow-scripts allow-top-navigation-by-user-activation" allow="attribution-reporting"></iframe>
As you can see, it has both sandbox[1] and allow[2] attributes. The former restricts certain behaviors of the embedded code (most notably, navigating the top window without user activation), and the latter restricts it from accessing certain APIs - this why the author saw errors in the console.

The script at https://cdn.js7k.com/ix/talon-1.0.37.js is an ad verification library developed by Verizon Media (formerly Oath), and it does, among other things,, fingerprinting for bot detection purposes (because they want to prevent ad fraud). It was served together with the actual ad media (so called "creative") into the safeframe.

This a relativity begin case. Iv'e seen much more terrible stuff, from fingerprinting for user taking to straight out malware being served in ads. It's a wild west (or web).

[0]: https://www.iab.com/guidelines/safeframe/

[1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...

[2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...

>allow-popups-to-escape-sandbox

That setting is exactly the sort of reason I'm locked in a war to block ads from Google and others. What good is an escapable sandbox, other than for Google?

well, while I definitely block ads as well (when I don't reverse engineer them), this directive does have a good reason. It means:

"Allows a sandboxed document to open new windows without forcing the sandboxing flags upon them".

If it was absent, when user clicks the ad and it opens a new tab of the advertiser website, it would inherit the sandbox directives from the safeframe, which might break it. To be clear "sandbox" in this context refers to the iframe sandbox[0], not to be confused with the renderer process sandbox[1].

[0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...

[1]: https://chromium.googlesource.com/chromium/src/+/refs/heads/...

The iframe sandbox is not for you or google. It’s for sites that want to protect themselves from ads they embed on the page. You’ll also see this used on proxy websites that scrape your requested URL and embed the contents of that page in an iframe.
The result of [1] surprises me. I'm on a very standard Android device with a standard Browser and nevertheless I'm told that my USER AGENT and the HTTP_ACCEPT HEADERS are unique.

[1]: https://coveryourtracks.eff.org/

Very likelx true. I am more and more of the opinion that more users should attempt click fraud. I know that advertising does pay for infrastructure, but most advertisers are just interested in their competition not being able to do more.

But since there is absolutely no consideration for privacy from corporations like Google or Facebook, I don't see the need to support their perverse business model.

If enough users participated in such schemes, maybe these privacy invasions would stop.

IIRC FF puts the domain on the ‘blocklist’ after the first manual choice, at least if the user selects ‘block’ instead of one-time ‘deny’ (haven't seen the dialog in a while).

Hopefully The Browser doesn't pester the user each time, either.

Does anyone have first-hand experience with a company using fingerprinting in practice for the more standard marketing uses?

How does it work? What value does it provide? Who are the major players?

I work in marketing but feel like it’s a completely other world.

> this does not mean that the fingerprinting actually failed

When does fingerprinting ever fail? Maybe in Brave and/or Tor, but I wouldn’t bet on it.