[kevindong]

Keep in mind that a substantial portion of users now use ad blockers such that a lot of URLs used for analytics like this are blocked.

Consequently, you can't actually expect to capture 100% of these analytics events nor even expect the percentage captured to stay the same over time since the filter lists are very regularly updated and users enable/disable different ad blockers over time.

More broadly speaking, once you have sent a webpage to the user, you should not expect anything from the user's browser. They may or may not allow whatever arbitrary JS you have on the page. They may even intentionally give you bad data (e.g. hijack the payload to give you intentionally malformed data).

edit: even more broadly speaking, there's additional reasons why you can't expect to receive these kinds of callbacks: consider what happens if a user loses connectivity between loading the page and them navigating away (e.g. their phone loses service because they went into an elevator before navigating away)

[capableweb]

> Keep in mind that a substantial portion of users now use ad blockers such that a lot of URLs used for analytics like this are blocked.

How sure are we about this? I'm pretty sure it depends on which market specifically you're in, and the data I'm about to show is of course not perfect, but it seems that not so many users actually do use adblockers today. Although I don't know a single developer who doesn't, and in some web applications I'm running, the majority of users do use adblockers as they are focused on developers.

Chrome is assumed to be the most popular browser (by a large margin last time I checked, so I won't bother to check again) and a quick search puts the user base around 2-3 billion users. Searching for "adblock" in the Chrome Web Store (https://chrome.google.com/webstore/search/adblock?hl=en&_cat...) shows that the most popular adblocker has a user base of ~300,000 users.

That makes 0.015% to 0.01% of Chrome users having the "AdBlock" extension installed. Not that substantial.

If someone has some more accurate numbers than my slightly-educated guess, I'd be happy to be proven wrong.

Edit: The above user base of the adblock extension is wrong. As Jabbles pointed out, I was seeing the number of reviews, not number of users.

So instead, the page lists "10,000,000+ users" so we can assume the true number to be above that, but below "100,000,000+ users" users.

That would put the amount of Chrome users using the "AdBlock" extension between 0.3% and 5% more of less. Closer to "substantial", but not sure if it would impact businesses choice regarding ads/tracking or not.

[zamadatix]

> So instead, the page lists "10,000,000+ users" so we can assume the true number to be above that, but below "100,000,000+ users" users

Can we? I can't seem to find anything that indicates if/when the next number jump is, just a lot of big name extensions at "10,000,000+". Back in 2016 ABP had a post about their extension alone having 100+ million active users https://blog.adblockplus.org/blog/100-million-users-100-mill... and that's ignoring the >50% of Chrome users on mobile which requires non-extension based blocking.

Going for someone else's numbers instead of trying to build my own I'm finding anything from 10% to near 50% with most estimates being in the range of ~25%.

[capableweb]

I just assumed that Google has brackets of 10 - 100 - 1000 - 10000 and so on, which led me to the "but below 100,000,000+ users" part. Not sure why they are hiding the true count (maybe they don't have exact numbers themselves), but if there truly is that many users, not sure why they wouldn't show it.

> and that's ignoring the >50% of Chrome users on mobile which requires non-extension based blocking.

That might be true for Chrome users on Android, but Chrome users on iOS (which aren't as many as Android users although), there isn't a choice of any extension nor non-extension based blocking. Firefox on iOS doesn't even allow extensions, and only Safari seems to have ad-blocking. At least last time I checked, might have changed lately.

[devmor]

You are in fact wrong. iOS users use DNS-based blocking through VPN apps.

[capableweb]

You're saying that a significant portion of Chrome + iOS users are A) constantly connected to a VPN and B) that VPN has DNS-based ad-blocking?

I'm not doubting you that some are, but to say that a significant portion of them are, would need some sort of evidence/source to back you up.

[zamadatix]

> You're saying that a significant portion of Chrome + iOS users are A) constantly connected to a VPN and B) that VPN has DNS-based ad-blocking?

No, they simply said this statement:

> but Chrome users on iOS (which aren't as many as Android users although), there isn't a choice of any extension nor non-extension based blocking.

Is factually wrong as there is a choice; namely ad blocking VPN based apps.

Also these apps probably work differently than you're thinking. The "VPN" isn't a VPN in a traditional sense where your traffic goes to a remote server somewhere on the internet. Using VPN transport is just the method of convincing iOS/non-rooted Android to send the traffic to the app, which itself acts as the VPN server. Of course traditional true VPNs with ad filtering are also a thing but less common and more catered towards those already interested in true VPN service in the first place.

All that said iOS is hard to provide numbers showing usage scale being one way or the other as Apple doesn't publish them like other stores. If I had to guess iOS users would probably be the user group with the lowest ad blocking penetration though I wouldn't go as far as to say it's not worth noting. All of these smaller alternatives probably add up to more than the largest "normal" ad blocking method in the long run and ignoring them on an individual basis can significantly skew your overall result.

[varenc]

I use an adblocker, and lots of filtering lists, but most of the `navigator.sendBeacon` requests I was seeing weren't being blocked. Sometimes they were when the URL matched a pattern, but often they weren't. Which makes sense since they aren't ads and by design have nearly zero effect on the user experience.

I still wanted to block them though... so I started killing all `navigator.sendBeacon` requests by replacing it with a no-op function on page load. [0]

I have the no-op function log the results to console and it's fascinating seeing all the sites attempting to use it.Some pages on Amazon will fire a sendBeacon request every second or so.

[0] With this uBlock Origin user script: https://gist.github.com/varenc/7c0c17eea480a03d7c8844d81e608...

[capableweb]

That's interesting, I wasn't aware of "navigator.sendBeacon" before.

Question about the user script. Blocking WebSockets I can understand as they can be used for exfiltrating data you don't want them to get a hold of. But why disable WASM? It can't be used for exfiltrating, and disabling it probably gives them a stronger data-point than just leaving it on, for when they are able to exfiltrate data (via CSS HTTP requests for example).

[varenc]

Oh I don't actually disable WASM. Those are just different scripts that can apply to pages when a filter matches. I disable sendBeacon everywhere with `*##+js(disable-sendBeacon.js)` but the others I don't use or only use on a specific site. I believe I added the WASM removal just to test how a particular site's fallback would work when it wasn't present. That said, disabling WASM probably reduces your browser fingerprinting bits. I bet fingerprintjs[0] uses it.

UBO already has a built-in set of powerful scripts[1], but I just wrote my own for fun. I think I could have done this by just using the built-in ones.

edit: This filter does the same thing just using the built in `set` script, but won't log to console:

   *##+js(set, navigator.sendBeacon, trueFunc)   

[0] - https://fingerprintjs.com/demo/

[1] - https://github.com/gorhill/uBlock/wiki/Resources-Library

[kbelder]

From tests I've ran, about 8-12% of our visitors have some sort of tracking, analytics, or javascript disabling or blocking. This is in an ecommerce site focused toward non-technical users. I'd expect a tech savy browsing audience to be composed of 20% or more visitors with blocking.

[Jabbles]

You're looking at number of reviews, the number of downloads is significantly higher.

[capableweb]

Doh, you're right! I blame it on poor UX in the Chrome Web Store :) Will update my comment...

[dfas23]

Not always - more sophisticated analytics will proxy these requests through the websites own domain.

[ForHackernews]

> they may even intentionally give you bad data (e.g. hijack the payload to give you intentionally malformed data).

Interesting. Are there tools we can install to send malicious payloads to surveillance companies?

[HWR_14]

There are plugins that do this, but I think trying to choke off the signal is more effective than just adding noise.