Comments (18)
Also remember that these domains are only blocked on Ultimate as it stands (which IMO is the way to go), and I feel that this follows the current precedent for that list. If these domains are removed from Ultimate, you could also make the case to remove lots of other telemetry/crash reporting/etc domains. Where is the line drawn?
I don't think it's fair to characterize the concern here as solely irresponsibility, there are other factors to consider as well. For instance, in the past, There was a bug that automatically sent tab crash reports to Mozilla without user knowledge. In general, a lot of things could happen, and those using Ultimate would likely expect to be protected from data collection in instances like this.
I don't think it's fair to decide what kind of data collection is or isn't acceptable for everyone with an aggressive list like Ultimate, it's too personal & subjective.
I don't think Ultimate should make opinionated decisions like this on what kinds of data collection are and aren't okay.
Honestly, you make some good points. I hadn't realized that this is only about Ultimate, which makes me a lot more inclined to agree. Ultimate as the name implies is a much more absolutist list and in that sense I agree with your comments regarding subjectivity. It isn't ambiguous what Ultimate does, in the description or in the name, and in that sense I can understand how blocking this crash reporting could mean giving back control to those that use it, since they would be more likely to expect it and be ready for it, and it would also remove edge cases where their choices wouldn't have been respected anyway.
At least as I see it, this being blocked in Ultimate is ok, but Multi PRO++ would be too much.
So in the end this discussion simply reinforces that Ultimate isn't for me. Sorry for my rant and thanks for bearing with me! :)
from dns-blocklists.
The domains are currently only blocked in Ultimate.
from dns-blocklists.
Sorry for my rant and thanks for bearing with me! :)
No worries, you made some fair points yourself and it was nice to chat about it & hear your perspective :)
from dns-blocklists.
https://github.com/hagezi/dns-blocklists/blob/main/wildcard/pro.txt
from dns-blocklists.
I may move the domains to the aggressive lists. I think they are also used for the automatic sending of crash reports, which counts as bug tracking and is blocked from Pro onwards.
from dns-blocklists.
crash reports are never sent automatically.
from dns-blocklists.
from dns-blocklists.
This does not make sense to be blocked this crash reports are sent by the user does not sent automatically (like posting a picture in Instagram) and blocking this means blocking the internet itself.
This should not be in pro or pro+ not even ultimate.
This is my opinion.
from dns-blocklists.
If that's the case, I agree with you.
from dns-blocklists.
Blocked (crash related):
crash-analysis.mozilla.com
crash-reports-xpsp2.mozilla.com
crash-reports-xpsp2s.mozilla.com
crash-reports.allizom.org
crash-reports.build.mozilla.org
crash-reports.maven.mozilla.org
crash-reports.mozilla.com
crash-reports.nightly.mozilla.org
crash-reports.security.mozilla.org
crash-reports.stage.mozilla.com
crash-stacks.mozilla.com
crash-stats-dev.allizom.org
crash-stats-django.allizom.org
crash-stats-django.mozilla.org
crash-stats-new-dev.allizom.org
crash-stats.allizom.org
crash-stats.mozilla.com
crash-stats.mozilla.org
crash-stats.stage.mozilla.com
crash.addons.mozilla.org
crash.mozilla.com
crash.planet.mozilla.org
crash.reporting.build.mozilla.org
crash.reporting.mozilla.org
crash.reporting.planet.mozilla.org
crash.reporting.svn.mozilla.org
crash.services.mozilla.com
crash.svn.mozilla.org
crash.vpn.mozilla.org
crashplan.addons.mozilla.org
crashplan.planet.mozilla.org
crashplan.svn.mozilla.org
crashplan.vpn.mozilla.org
crashstats.mozilla.com
CNAMES:
antenna-stage.socorro.nonprod.webservices.mozgcp.net
socorro-stage.socorro.nonprod.webservices.mozgcp.net
antenna-prod.socorro.prod.webservices.mozgcp.net
socorro-prod.socorro.prod.webservices.mozgcp.net
from dns-blocklists.
The following blocked domains are on the Umbrella Top 1M list:
crash-reports.mozilla.com
antenna-prod.socorro.prod.webservices.mozgcp.net
Either there are a lot of users reporting crashes and the domain therefore ends up on the Top 1M list or it is triggered without user action.
from dns-blocklists.
crash reports are never sent automatically.
@bbhtt This is incorrect, but I understand why you would come to that conclusion... Mozilla has not well documented this at all.
According to a Mozilla employee:
Having looked at the code again this does two things when checked:
If you've got some old unsent crashes it sends them automatically w/o user interaction
If a tab crashes it sends the crash report automatically w/o user interaction
(The pref being referred to here is enabled by default).
Therefore IMO these domains should be kept, and Mozilla really needs to make this clearer.
from dns-blocklists.
This also explains why the domain appears in the top lists. Since it is a mix of, I am moving it to the aggressive area.
from dns-blocklists.
(The pref being referred to here is enabled by default).
How did you confirm this? This toggle was never enabled by default on any Firefox installation I've done in the past as far as I recall, and I just tested it by reinstalling Firefox; it's off by default.
This support page also states that crash reporting prompts the user for their consent by default: https://www.mozilla.org/en-US/privacy/firefox/#crash-reporter
By default, on desktop versions of Firefox, we will ask you to share a report with more detailed information about crashes with Mozilla, but you always have the choice to decline.
To me it seems quite clear that crash reporting requires user consent in one way or another. The default behavior is to prompt the user for their consent before reporting a crash, while the optional behavior is to do that automatically after the user enables it. I'm not sure it makes sense to block crash reporting if it is explicitly opt-in rather than opt-out.
from dns-blocklists.
https://bugzilla.mozilla.org/show_bug.cgi?id=1593523 ... when checked ...
from dns-blocklists.
How did you confirm this? This toggle was never enabled by default on any Firefox installation I've done in the past as far as I recall, and I just tested it by reinstalling Firefox; it's off by default.
Well... I stand corrected, apologies. I just tested myself and you're right, it doesn't appear to be enabled by default. I guess I just assumed it was since the other telemetry options are always automatically enabled...
To me it seems quite clear that crash reporting requires user consent in one way or another. The default behavior is to prompt the user for their consent before reporting a crash, while the optional behavior is to do that automatically after the user enables it. I'm not sure it makes sense to block crash reporting if it is explicitly opt-in rather than opt-out.
IMO it's still worth blocking these domains (at least on the aggressive lists). It looks like even though automatic crash reporting is not enabled by default, Mozilla still promotes it & tries pushing users to enable it.
Example on mobile:
(In this case it actually does look toggled by default)
& An example on desktop:
I could see unsuspecting users enabling it without paying attention, which would add up with @hagezi seeing the domain on the top lists.
I feel like these domains would be best fit for the aggressive lists, since I would wager most people on the aggressive lists would never want this data to be sent.
from dns-blocklists.
IMO it's still worth blocking these domains (at least on the aggressive lists). It looks like even though automatic crash reporting is not enabled by default, Mozilla still promotes it & tries pushing users to enable it.
I think I disagree, respectfully.
As it stands, a user which makes a conscious and informed decision to either send a crash report once or allow the automatic sending of crash reports is completely blocked from doing so, probably even without them being even aware of it (this is doubly problematic to me).
Meanwhile, a distracted/uninformed user which chooses to report a crash without being aware of what it means, whether it is by ticking the box to allow automatic sending or agreeing to report an individual crash, would be shielded from the potentially negative consequences of their choice to their privacy. At the same time, that user was never forced to make that choice.
If I understand correctly, the reasoning for blocking these domains is that irresponsible users should be protected from their own irresponsibility. I question whether this is what this blocklist aspires to do. Privacy violations on the web are usually invisible or severely deceptive, and therefore I think it is perfectly fair to try and shield end users from that. I don't believe this applies here.
I think the most problematic part is the fact that informed, responsible users are also removed the ability to choose, in the name of shielding irresponsible users from their own choices (something that is questionable to begin with in my opinion).
Blocking these domains basically means making decisions for the users, which I don't agree with philosophically.
Although I agree that the consent dialogs are sometimes designed to encourage a specific action, it is still clear to an attentive user what it is they are being asked, and if they don't quite understand it, they can simply take the time to do a little bit of research or they can simply disagree as a precautionary measure.
Example on mobile:
If that is the current situation on mobile, I think that's not ideal. In this case I think Mozilla should provide a link or at least a short explanation of what crash reporting entails. It doesn't change my overall position, though.
(In this case it actually does look toggled by default)
I think that this is a different situation from the question of whether automated crash reporting is enabled by default or not; in this case, the user is still asked for their consent. The original claim about desktop Firefox was that the user isn't asked for their consent at any point.
& An example on desktop:
I don't understand as well what you're saying the problem is in this screenshot. Is it the banner at the bottom that asks to send an unsent crash report? I can see how it might be designed in a way to encourage sending the crash report, however it isn't very intrusive or pressurizing and there is a 'view' button that's reasonably prominent which can help the user understand, and an 'X' to get rid of it.
I would wager most people on the aggressive lists would never want this data to be sent.
That's a bold assumption in my view. For one, I use the aggressive lists and I would want this data to be sent. But even if it is true, I think the benefits are not worth the downsides, for the reasons I already layed out.
from dns-blocklists.
As it stands, a user which makes a conscious and informed decision to either send a crash report once or allow the automatic sending of crash reports is completely blocked from doing so
I disagree - I think blocking it actually forces the user to make a conscious and informed decision whether they want to send these reports or not. If the user wishes to send these reports, rather than it being enabled for them (through dark patterns, by accident, or otherwise), they can make the active decision to whitelist the domains.
Also remember that these domains are only blocked on Ultimate as it stands (which IMO is the way to go), and I feel that this follows the current precedent for that list. If these domains are removed from Ultimate, you could also make the case to remove lots of other telemetry/crash reporting/etc domains. Where is the line drawn? That's where it gets very difficult. I feel like leaving them on Ultimate is the best course of action, and those who are fine with this type of data collection can either: 1. Make the conscious decision to send it through whitelisting the domains or 2. use a list less aggressive than Ultimate (Which they probably already are if they're fine sending this type of data).
probably even without them being even aware of it (this is doubly problematic to me).
Since we're talking about Ultimate here, this would really only apply to those using the public DNS servers, but again: This type of data collection being blocked IMO is expected from Ultimate, so if someone is fine sending this type of data, they should just use a less aggressive list.
If I understand correctly, the reasoning for blocking these domains is that irresponsible users should be protected from their own irresponsibility.
I don't think it's fair to characterize the concern here as solely irresponsibility, there are other factors to consider as well. For instance, in the past, There was a bug that automatically sent tab crash reports to Mozilla without user knowledge. In general, a lot of things could happen, and those using Ultimate would likely expect to be protected from data collection in instances like this.
I question whether this is what this blocklist aspires to do
I'm not Hagezi so I won't speak on his behalf, but my understanding is that Ultimate does aspire to block all data collection like this.
Privacy violations on the web are usually invisible or severely deceptive, and therefore I think it is perfectly fair to try and shield end users from that. I don't believe this applies here.
I think I already touched on this above, but again, this is just far too subjective IMO. Under your criteria, I could already think of several domains off the top of my head that would also have to be removed. I don't think it's fair to decide what kind of data collection is or isn't acceptable for everyone with an aggressive list like Ultimate, it's too personal & subjective. It should be left to the user to decide & whitelist as they see fit.
Blocking these domains basically means making decisions for the users, which I don't agree with philosophically.
I just see this as the complete opposite honestly - I feel like this is actually giving the decision back to the users vs. Mozilla or whoever else making it for them. I also think that again it fits the philosophy of Ultimate to block all forms of data collection of like this.
I think that this is a different situation from the question of whether automated crash reporting is enabled by default or not; in this case, the user is still asked for their consent.
The box is checked by default... - again, I hate to keep coming back to this, but I can think of several domains that would also have to be reconsidered if they showed some kind of prompt but were still toggled by default.
That's a bold assumption in my view. For one, I use the aggressive lists and I would want this data to be sent.
I don't think it's a bold assumption to make at all, and if you're fine with this type of data being sent, I'd recommend either just whitelisting these domains or not using Ultimate, and instead stepping down to ex. Normal which doesn't block crash reporting like this.
But even if it is true, I think the benefits are not worth the downsides, for the reasons I already layed out.
What exactly are the downsides of blocking these domains? Unless you're Mozilla, the only downside I can think of is it being slightly annoying to whitelist them if you actually want to send these reports (In which case you shouldn't be using Ultimate IMO).
Overall, I think your criteria is far too subjective for Ultimate. If we were talking about less aggressive lists, then I would be inclined to agree with you, but I don't think Ultimate should make opinionated decisions like this on what kinds of data collection are and aren't okay.
from dns-blocklists.
Related Issues (20)
- Possible tracker HOT 1
- YouTube Thumbnails not loading on iOS app HOT 1
- Site names in other languages? HOT 2
- Pro++ not blocking domains on Spiegel HOT 6
- Show Azure Functions invocations fails HOT 2
- popular websites are not working HOT 12
- Add New Gambling Sites HOT 1
- Add to HageZi's Gambling Blocklist HOT 1
- Please add rules. HOT 2
- Block analytics HOT 1
- Block error tracker HOT 1
- Can this be blocked permanently? HOT 1
- Unblock URL shortener HOT 1
- Shazam Telemetry HOT 1
- Add New Gambling Sites HOT 1
- Allow privacy.sexy HOT 1
- Block - ipatronus.idata.shopeemobile.com HOT 1
- Block Steam phishing HOT 1
- Allow Pipedrive chat HOT 1
- Allow affiliate link HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dns-blocklists.