Using telemetry Mozilla was able to precisely measure how many connections are actually established with TLS 1.0 and 1.1. Without numbers, they'd have been flying blind, making decisions with no rational basis. That's why I personally choose to leave telemetry on in applications that I trust. It helps the dev makes sensible, data-driven decisions.
Some unrelated advice: what would you do if business brings up Google analytics data showing Google Chrome, IE, and Safari are three main browsers people use and the usage share of Mozilla Firefox is under 5% for a particular website? I tried to show my own use case with uBlock Origin which means when I go to the website it doesn't show up on Google Analytics.
How do we make decisions based on self-reported data?
You'd think institutions funded by public monies would be more sensitive on issues like this but my pleas fall on deaf ears.
EDIT: I'm mostly suggesting this because it sounds like all you need is proof that your Google Analytics data might be incorrect.
I really didn't expect my adblocker to do that when I installed it.
I've had so many things break because someone somewhere didn't think a request was valid enough and blocked it and it was put into a common blocklist. WebRTC, several fonts, first party analytics, even whole services like Google shopping were blocked entirely because "they are ads" or they were "trackers". We even had to modify an app which was using css modules one time because class names were compiled down to a hex encoded hash of the css properties, and any class names beginning with `ad` were blocked by EasyList at one point...
It is giving an uncomfortable amount of power to a very small amount of developers. And it ends up ruining efforts to avoid 3rd party analytics because not only are first party harder to implement and maintain in many cases, but they get blocked just the same for very innocuous reasons, and give worse insights in some ways.
Just look at the list of what EasyList considers "unacceptable data to gather" in first party analytics [0]. Things like the useragent, timezone, IP address, and language are considered "personal information" and should be blocked even in first party scripts with EasyList! IP address or useragent alone literally makes all first party tracking impossible...
[0] https://easylist.to/2011/08/31/what-is-acceptable-first-part...
I will say this is why people install content blockers, to avoid giving control to random developers behind countless websites, which have shown that there is no limit in the amount of data they will try to gather without a hint of informed consent.
On the other hand, content blockers are opt-in and people are free to install or not after reading the description/documentation and further researching them.
But it's the lack of choice in terms of what is blocked, and the limited ability to understand that it's the content blocker that is potentially breaking the application which is what i'm lamenting here.
I can't overstate how much I want to respect the user if they don't want some aspects, or some features, or anything which they just don't like, or which they feel can impact their privacy. (I'll argue with you about the ethics of blocking ads but still using a service, but that's another point entirely!)
My issue is that there is a group of people that are deciding what things are allowed and which aren't, and they are going to necessarily have to make tradeoffs (I don't think that all of amazon.com should be blocked because they can track your purchase history by virtue of handling your purchase!). But for the most part the trade offs made are opaque to the user and site owner, and the UX is lacking in showing the user that the content blocker can be the cause of the problem, not to mention that by default these lists are very powerful tools able to pretty quickly harm good actors (and this isn't something i'm single-ing out content blockers for, antivirus vendors, ISPs (AKA net neutrality), and even social networks all have this issue to some extent).
There might not be a good answer, and I sure as hell don't pretend to have it, but I'm just wishing for a way that users can make informed decisions on what they want to block, rather than have someone decide for them. Without some kind of give and take here, the arms race is just going to continue, and as it escalates, good actors (of which I'd like to think i'm one of) will get increasingly pushed away as they are blocked just the same as bad actors, leaving them with the options of "play dirty and survive" or "die peacefully".
I'm sad to say that I ended up taking a page out of the "play dirty" book and got a new domain name for the app in question to get around the content blockers, but I'd do it again in a heartbeat since I'm not abusing that information or power, but I'm blocked as if I am. And while I feel dirty that I'm forcing my wants onto others, the ratio of "unwilling participants" to "those who actually wanted to use my app, but not one it's core features" is so unbalanced that I ended up ignoring the latter to save the former. And while I wish I could respect the wants of the latter group, if I engage there the former will have the content blocked for them as well again, and I'll be right back to square 1.
Sometimes people really mean it when they say they don't want to be tracked: they want to leave no footprint at all. Sometimes people just want the website to load as fast as possible by discarding as much Javascript and as many requests as they can get away with.
But don't forget the good old HTTP access logs, which give you all this information anyway without having to load extra scripts.
But that's my point, whole domains have been added to EasyList under these rules that break the entire application because the person who added it assumed it was tracking related and not part of the application. People see xhr requests which save the current timezone so the server can update calendar notifications at the right time as "tracking" and break the application entirely because of it. They see a request they don't understand and block it because "it includes the useragent".
Take Google shopping for instance, an entire service shut off because "it's tracking", while Amazon or eBay or any other online shopping service isn't blocked.
If you really want that blocked, I'm more than happy to not serve you! I don't want to track you if you feel that using your timezone is over the line! But when your feelings toward that are pushed to who knows how many computers and now my site is broken for a large number of users, who are now contacting me to fix it, it becomes a problem.
To use an analogy, I don't have any issue with people that are allergic to peanuts. I don't want to try and force feed you peanuts, I want to make sure everyone knows I serve peanuts, and I want to give you the option of not eating at my establishment if you are allergic or simply don't like peanuts.
But if you start removing my establishment from maps, and start putting road blocks in front of my building preventing others from getting in, now it's overstepped a boundary.
I don't pretend to have a good answer, this isn't an easy problem to solve, but giving a handful of devs a "break this website for all adblocker users" button seems like a lot of power, and it especially hurts those who are trying to accommodate you.
If I didn't care, I'd just work around it, use server logs and send them to 3rd parties, lie and actively route around your attempts to block. And I'd not only make more money, but have to deal with less issues from users...
My hope is that the devs that believe these things can give more options to the user to decide for themselves and make informed decisions about the tradeoffs, rather than saying "this is bad, I blocked it for you".
In the instance I'm talking about, the app was about reminders for taking medications. Having those go off at 3am local time because you flew to Hawaii for a week doesn't do you any good. Not to mention that the app tracked and helped tune dosages and timing, and needed information like when you woke up, time of day for you, the kind if medication, and a lot more.
Again, you are free to not give it, but that was a core point of the application, and trying to disable or break the application in the name of privacy is like cementing your door shut to prevent breakins.
Users aren't "tricked" into having timezone information used to track them, they aren't frusturated with the timezone tracking feature, and the app was paid and had a privacy policy in place that prevented me from selling or using any of the information for advertising. And if users become frusturated with the feature, I can as the developer fix it for them. You cannot, and blocking requests that you don't understand in an app you don't use is exactly what caused all the headache in the first place. And when I went to try and get it unlocked I was met with similar hostility, and told in so many words "too bad".
You don't always know better than the user, and you don't always know better than the developer.
In the end, I switched domains, and since then have managed to fly under the adblocker radar. I'm no longer involved with it, so I don't know if they managed another solution without me.
However. I don't think that content blockers are third parties. They are part of the user agent. The choice to use a blacklist is up to the user. It is not a third party breaking your app. It is the user themselves.
To use a more controversial phrase, the "blocklist" groups are now a cartel which gets to decide which apps work and which don't, and you have no way of appealing or even reasoning with them in a lot of cases. They get to decide that the Amazon cookie is okay, but a Google font is not, that login-with-facebook isn't allowed, but login-with-twitter is okay. That my app which uses timezone information was crossing a line, but my competitor wasn't.
I'm more than happy to help work with those who want to protect their privacy. I genuinely agree with a lot of viewpoints and I work to protect my own privacy as well, but at some point things go too far and I feel a lot of these tools are throwing the baby out with the bathwater here, and are even causing a false sense of security as people think they are protected from everything when really they are hurting the good actors the worst while the bad actors continue to operate just fine.
As I’m one of these people who aggressively controls what I let my web browser load maybe I can answer some of your questions.
Facebook, Twitter, Google Analytics and tag manager are blocked outright, all the time.
If your site needs several different CDN’s to load it’s assets, for seemingly no reason then I generally leave; unless I need something from that particular page, in which case I give it about 2 or 3 goes of playing “which CDN serves the information I actually care about?”.
Any domain you use that isn’t obviously yours or a CDN or obviously related to what’s on the page (web stores get to load shoplift for example) is blocked because assume it’s just another advertising/analytics company.
Sites that load the DOM and contents into memory, but display a blank page until I unblock a bunch of JS are my pet peeve, and I make a note to never return to them.
> I feel a lot of these tools are throwing the baby out with the bathwater here
The carté Blanche approache is used because it’s faster and easier for me to find the minimal set of domains and resources to load than it is to get every website out there to not stuff their site full of trackers and unnecessary JS.
>Any domain you use that isn’t obviously yours or a CDN or obviously related to what’s on the page (web stores get to load shoplift for example) is blocked because assume it’s just another advertising/analytics company.
I'll generally agree with you (for the most part). With the exception of using a CDN to serve static assets that I control (like amazon s3 for instance), I have no issues with you or anyone else blocking all requests that they don't like! (and hell, i'm fine with you even blocking first party requests, but since you are the one doing it you'll know that it is the reason the site breaks).
> Sites that load the DOM and contents into memory, but display a blank page until I unblock a bunch of JS are my pet peeve, and I make a note to never return to them.
But I'm talking about applications, not static web pages or documents. Complaining that an application needs a programming language is like refusing to turn on any computer that runs any code at all. The code is the application, and if you don't want to run JS, then you don't want to use the program. (outside of viewing some static assets like images, or possibly the minimal DOM put into the HTML for bootstrapping, there's literally nothing else).
>The carté Blanche approache is used because it’s faster and easier for me to find the minimal set of domains and resources to load than it is to get every website out there to not stuff their site full of trackers and unnecessary JS.
Again, I'm more than happy to let you block what you want, i'll even help support your use case if you want and it's possible.
But when you take your approach, and you start making a large percentage of the web use it, and you auto-update their browser plugins to use your approach so that things that were once working yesterday are now broken, and users don't have any real reason or understanding why. Or even worse, you begin making wild assumptions about why I need data backed by nothing but scaremongering (displaying warnings like "this site is trying to track you" when I give the option of offering the app in multiple languages...), then we have a problem.
In these case, I'm more than happy to break their stuff as it's seemingly the only way to get them to pay attention.
This isn't a blog that loads 50 trackers and tons of superfluous animations and video, this is an application which is designed to do things for the user. It's stuff like a music making app, or a medication reminder and tracker application that takes a lot of your personal information to help you find accurate dosages. It's stuff like games or offline-caching documentation browsers with IDE integration and powerful client-side search, or self-hosted home automation controller systems, or chat applications, or a barcode scanner app that checks for coupons for things that you scan in a web browser, etc...
And again, i'm fine if you don't want to run one aspect of it, you are the client and I can't technically control what you do, but complaining that the car won't work when you ripped the spark plugs out is dumb, and a mechanic that goes around taking out spark plugs every chance he/she gets so that people won't speed isn't helping.
> start putting road blocks in front of my building preventing others from getting in
It's more like you've erected a billboard, and the Campaign Against Ugly Billboards have given some people AR glasses which edit out the billboard .. and a bit more of your storefront. It's not really in the same category as fraudulent Yelp reviews.
> If you really want that blocked, I'm more than happy to not serve you!
I think you'd be better off just accepting this. The user and their user-agent has a "right" to display a website how they want, including in ways that the developer didn't think of - and including ways that are broken. The user can break your site if they want. I appreciate that this causes problems when they've not realised that it's their choices that break it, or put in annoying requests ("why doesn't this site work in Lynx"). But fundamentally they're customers, customers are always annoying. Given your context of a paid app it sounds like it's worth asking them to disable the adblocker pre-emptively, but presumably you've tried that already and they haven't.
> Take Google shopping for instance, an entire service shut off because "it's tracking", while Amazon or eBay or any other online shopping service isn't blocked
ublock Origin blocks bits of Amazon within the website - the internal sponsored advertising. I only noticed when some of it flashed up and then vanished.
It’s something at least akin to unethical to deliberately break something I’ve built and then come complain to me that it’s broken.
And sure, they might be would-be customers, but not all would-be customers are worth serving.
Just as customers have the right to buy from whoever they like so to do seller have the right to sell to whoever they like (barring certain narrow exceptions like racial discrimination.)
It’s always the negative value customers that throw the biggest tantrums when they are told a business would rather not serve them. Or in the case of ad block users, not even customers just people that want something for nothing.
But your analogy misses a key aspect which is that the adblocker breaks the app entirely. It's not like just hiding my storefront, it's preventing users from entering the store at all unless they completely disable the device. Often those same users don't realize that these blocklist update silently in the background and it's their adblocker that is breaking the application that they have been using every day for years.
> I think you'd be better off just accepting this.
I think I worded that poorly. I do accept this. If you don't want to use an aspect, or want to render something your own way, I'm happy to let you! But I'm not happy when you start imposing those restrictions on others who don't know it's happening and don't know why core aspects of the app aren't working.
Informed decisions are good, blanket disabling or breaking applications because a developer "knows better" isn't.
Useragent issues I can work around, bugs can be fixed, and those who don't want that part of the app to work are happy. But I can't work around an adblocker blocking things for users that don't want then blocked. If I work around it I'm then "tracking" those who are attempting to block it (and IMO should be called out for it), and if I do nothing I lose users and paying customers who will move to competitors which for some reason are not blocked. (And I don't blame them, my app doesn't work, so why would you stick with it?)
> ublock Origin blocks bits of Amazon within the website
But back a year or so ago, it blocked the entire google.com/shopping URL, and the shopping.google.com subdomain (I haven't checked if it still does).
The entire service blocked because someone somewhere decided it wasn't worth it, but Amazon and eBay and AliExpress all only have some elements blocked because it's somehow different.
And while you can go in and re-enable those parts, it takes a long time and a good amount of technical know how of things like globbing and regex to whitelist it correctly. And then must be repeated on every device you use.
What I am hating most is that sites where I am willing to send money to (web shops) do these things and send data to ad net works too, no less.
You have no guarantees at all, but that information is always sent across, and in many cases must be sent to even make a request. You literally can't prevent an IP address from being "sent" because it's needed to route the information back to you. Sending an "Accept-Language" header lets a website be translated into multiple languages. And virtually 100% of my users want times and dates in their local time, not UTC.
Just because it's potentially identifying information doesn't mean you can block it and pat yourself on the back as "stopping tracking". When you don't allow an IP address to be sent, you have just created a system where you can arbitrarily choose literally any request and block it under that rule. It's like making a law against breathing oxygen, then arresting anyone that you don't like for any reason because they are breaking at least that law.
> That's why I personally choose to leave telemetry on in applications that I trust
The problem is that when I have to "leave it on" rather than explicitly enable it then it's no longer an application I trust.
On first launch or after a set period, show a non-dismissable dialog asking users to choose between the two, with no default option selected, so you can't just click through.
This strikes me as the best compromise between respect for user privacy and acknowledging that data collection can be useful, with the trade-off that some users will choose not to use the software/website rather than decide on an option (thus, 'no default' must be used sparingly).
In that context opt-in has a bit of an issue with people even knowing it exists, not to mention caring enough to go find the option to opt-in, and then doing so. This route will, for better or worse, produce a very self-selected group. The proposal above is a way to maintain the benefits of opt-in (namely, consent) while trying to improve the quality of the group.