Hosts: Remove Sentry (sentry.io)

[dcramer]

(Copying this over from the pi-hole project)

Sentry (sentry.io) is included in the following list:

https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts

It seems the author of this list is misinformed, as they include it under

# Block ads on Hotstar streaming app by @anudeepND

Sentry is not an advertising or analytics service. Hotstar simply uses Sentry to log client-side issues.

This is problematic for software developers due to the sheer nature of JavaScript used these days. If you can't log errors in your client-side applications, you best case lose context for debugging issues and worst case any visibility that errors are even happening (and end up relying on twitter-ragefests).

I also see that New Relic is in here listed as an "adserver" which is also incorrect, and similar to Sentry. I see in @anudeepND's original "adservers" it also lists our previous domain (getsentry.com).

References:

• https://sentry.io
• https://github.com/getsentry/sentry
• https://github.com/getsentry/raven-js

Nit: not sure how we've gotten to the point where everyone assumes any javascript hosted on a third-party domain is advertising

[welcome[bot]]

Hello! Thank you for opening your first issue in this repo. It’s people like you who make these host files better!

[dcramer]

So per the convo on the other ticket:

@dcramer @PromoFaux sentry.io is like crashlytics, which we also block. A pretty massive leak of workstation-specific information and other things.

I agree that from a privacy standpoint, blocking Sentry achieves a goal of "dont let anyone know anything about me". That said, there's a few important things:

1. @pi-hole is "Network-wide ad blocking via your own Linux hardware"
2. "No third party scripts" is very different from "protect my data"

Now the last one, "workstation specific information". I can already get that without JavaScript. I can embed an image, I can scrape my logs, I can set and track cookies, etc etc.

I cant fully introspect the browser (thus I can't do any signature tracing), but I do have access to nearly all of the same critical information with or without an embedded JavaScript widget.

I don't disagree that Sentry isn't all that dissimilar to Crashlytics (though we dont capture as much), but I will disagree that it is an actual concern to users.

Last note: on our "Sensitive Data" (https://docs.sentry.io/learn/sensitive-data/) nearly none of that is available in the browser. Sentry does both client and server-side collection, and almost all of those kinds of datapoints only come from POST'd data.

Ok that's my spiel. Assuming it won't be removed, but fwiw other lists have removed it because of the same kinds of arguments as above.

[sadsfae]

Thank you for your time and dedication in maintaining the domain block lists for Pi-hole. I'd like to see sentry.io removed as well from list.0.raw.githubusercontent.com.domains

[xetorixik]

@dcramer it seems that you are an employee from Sentry, so perhaps biased.
This is not PI, so point 1 is perhaps important for PI, ask them I would say.
But does that also apply here? I would say no.

I agree that from a privacy standpoint

You give an equal answer to your own question 2.

If it's all so innocent. Why does Sentry need a privacy policy of the size of a book?

[dcramer]

@xetorixik I am the founder and CEO of Sentry (as well as the original author, 10 years ago). Yes I'm biased, but that doesn't make me wrong.

Why does Sentry need a giant privacy policy? Regulation and compliance, and the fact that we're a business.

See also:

• https://www.eugdpr.org/
• https://en.wikipedia.org/wiki/International_Safe_Harbor_Privacy_Principles
• https://www.privacyshield.gov/welcome
• https://www.ssae-16.com/soc-2/

The alternative to privacy policies is that you trust us blindly. Instead we have a giant legal terms of service that you can hold us accountable on (legally even).

Anyways, agree this is a concern with PI, but someone has to decide who's actual problem it is. PI wants to use this list, but says its the fault of this list, and @StevenBlack says PI is ultimately responsible for what they include (which is where I agree with things). Ideally PI would either not include the entirety of this list, or there'd be separate lists/configuration so people who wish to block tracking/ads can, but aren't required to harm development teams.

[PromoFaux]

PI wants to use this list

To clear it up, and as has been stated many times over, Pi-hole includes several lists by default which have always been "suggestions". These are lists that have been found to work well for the _majority_ of our users, and are there to serve as a starting point only.

Something else I would suggest. If a list-maintainer believes a domain you control should be on his list, and you do not, then that is something you have to fight out among yourselves.

The onus is on the user to ultimately decide what they do and do not want blocked. Pi-hole (and I'm sure other similar solutions) put the user in control of what they want blocked. If they find a list to be overzealous they have the tools to be able to tailor it to their own experience. Be that by whitelisting domains (thus ignoring the fact that it is on an otherwise fine list), or by removing the list entirely.

And it is for this that Pi-hole is exploring ways of making it much more abundantly clear that we are not choosing for them what is and what isn't blocked.

These community sourced lists are a great resource for everyone, be they novice or pro. Not everybody has the time to go through their network's DNS lookups and look into what is and isn't a good domain to block, and that's where these lists come into play. Block many first, tailor to your own needs by whitelisting domains that are causing issues with your browsing habits/applications.

You can argue back and forth on whether or not a domain should or should not be included in a list all day, or you can just whitelist the domain, stop using the list all together, or create your own blocking list.

As mentioned elsewhere, we're looking into a way to make it so that any list that is enabled on a Pi-hole install is one that a user has explicitly enabled themselves, firstly via a list of lists that we have found to work well (again, remember, for the _majority_ of users, and the developers themselves, _suggestions_ if you will...), and secondly via their ability to add lists of their own choosing, sourced from wherever the hell they like on the internet, by using the web admin page we provide:

@StevenBlack Sorry to Hijack this thread after directing the OP here, but I need to make it clear that what is and isn't blocked is ultimately down to the user. I'm sure _you_ (and members of your community) know that, of course, but some others just don't seem to get it!

[xetorixik]

Ok going back to the specific Sentry topic.
@dcramer

but aren't required to harm development teams.

With all due respect but could you write that again?
Harm development teams while the Sentry service has the possibility to telemetrically collect the user::

1. password
2. secret
3. passwd
4. api_key
5. apikey
6. access_token
7. auth_token
8. credentials
9. mysql_pwd
10. stripetoken
11. card[number]

It is not about ads, it is the point that almost everything
with an internet connection, nowadays is logged with both telemetry and trackers.
Something that just beginning users have no idea of.

Banning telemetry and trackers is exactly what you need to accomplish for beginners.
Not specifically only Sentry, Not specifically Windows telemetry.

This is opt-in. Wide open to abuse. I would say, anyone using our hosts file seeks protection against exactly this sort of thing.

That is why I fully agree with @StevenBlack
I think: Sentry should not be whitelisted.

[StevenBlack]

Here's my perspective David @dcramer.

The proportion of internet users who use hosts-based blocking is minuscule. Almost negligible, I'd say.

Of that negligible number, a very small proportion use a hosts file that blocks sentry.io.

Therefore a minuscule slice from a minuscule slice equals a very minuscule effect, overall.

Is the math good so far?

Maybe we could transparent about what's really at stake here?

I'm being asked to open all the users of this hosts file to sentry.io so the developers of sentry.io can use this hosts file at work or at home.

If this is true, I'm a size Large t-shirt, and I'll take two, long-sleeves if you have 'em. One for me, and one to give to a repo contributor, though I suspect some of those are borderline XL-sized people :-)

If what I say is not true, then what's the problem? You'll be getting crash reports from 99.9% of your installed base anyway.

[dcramer]

@stevenblack for clarity it’s not just developers of Sentry.io. It’s developers from 20,000+ companies that use our hosted service. I’m fine if people block Sentry, but people shouldn’t treat it as the same thing as advertising. Adblock became super common after a period of time, and depending on your audience it could be a much higher % of users running it. I just dont want to see the same dilemma we had with Adblock happen here (incorrectly marking Sentry as ads).

[StevenBlack]

I understand David @dcramer. Thanks for clarifying.

[anudeepND]

@dcramer Thanks for the detailed info, what do you think @StevenBlack are going to remove the domain, I can make PR if you want to...

[StevenBlack]

Shhhh... @anudeepND! I'm holding out for some swag! Summer might come to Eastern Canada and, if it ever does, I'll need a tee.

Gah! Alright. @anudeepND I'm happy to entertain the PR.

[StevenBlack]

Closing!

[dcramer]

We can make swag happen :)

[StevenBlack]

[DPTJKKVH]

Will you create a blocklist specific for trackers like this?

I know @dcramer talks all nice but from a technical and legal standpoint thier porduct collects way more details than e.g. Google Analytics does. In EU you must close a data processing agreement with Google before using Google Analytics, a data protection contract that Sentry to my knowledge refuses to sign because they collect more data than can be reasonably expected from the user (passwords and such).

I'd say @dcramer should put his money where his mouth is and either sign European GDPR data protection agreements with their customers or block collection of such sensitive information entirely.

Until then we really need them on a block list. I know I can (and I will) block them and others to my best abilities with the custom black list but it would be a shame if everybody else had to do that as well.

[dcramer]

@DPTJKKVH We already do, for every customer, in every country. https://blog.sentry.io/2018/03/14/gdpr-sentry-and-you

Again, what Sentry collects you can get almost the entirety of from web server access logs or web server processes. It's not the same as a large analytics providers which can track you across multiple properties that are unrelated (e.g. Google).

[arikfr]

@DPTJKKVH,

In EU you must close a data processing agreement with Google before using Google Analytics, a data protection contract that Sentry to my knowledge refuses to sign because they collect more data than can be reasonably expected from the user (passwords and such).

There is a very simple process to sign a DPA with Sentry. It's practically two clicks in the UI:

[DPTJKKVH]

@dcramer Well you got me there since it wasn't as easy when we tried last year (where such contracts where already required but under the now soon obsolete General Data Protection Directive which has now become a Regulation). Or at least your email support had a hard time dealing with this.

Anyways thanks for the heads! Still one thing to consider since you use this argument a lot: It's a big difference if a first party collects certain data or if a third party does mostly unnoticed in the background. It has a lot do with user expectations and most users aren't very tech savvy.

Still @StevenBlack I think we fail to meet the expectations of many users if we arbitrarily unblock certain third party trackers because they collect data "for a good cause". I think most users just want to block as much ads and trackers as possible without breaking functionality on their own side. I would keep sentry in the main block list but if not I'd highly recommend we start a "debugging" list or something. You already said it's kinda dumb because it would be a small list that we couldn't even properly differentiate by name since in the end those trackers do the same as all trackers (they collect data and track user behaviour). However it'd still be better than just unblocking it without giving the average user a chance to easily block those without everyone maintaining their own custom black list. Heck if you want I could try maintaining this extra list here since it's really not that many services out there so it should be doable without too much effort.

[StevenBlack]

Thanks @DPTJKKVH, I'll take that under advisement. I appreciate your input.

Edge-cases like this are always interesting. I'm tempted to add a page, or create a gist, to list and summarize boundary issues like this one.

In the end I just have to make a decision.

I can tell you, I am swayed because David @dcramer came forward, made a clear coherent case, solid and smart, and I understand where he's coming from. I'm happy to presume Sentry is a good player.

[anudeepND]

You know what @StevenBlack I personally don't like to whitelist these domains because when it comes to data collection there is no difference between "good telemetry" and "bad telemetry". Blocking data collection/harvesting about user was the main purpose of using hosts file like this.

And if these type of domain causing problems with work or anything like that, there's always an option to whitelist.

Coming to this Hotstar streaming app, it crashes awful lot of times like 7-10 times an hour and it's been happening from the beginning. I don't know what the hell are devs doing from error logs collected by your so called Sentry. I would like to include it in the blacklist. Again this is my personal opinion, what do you think @StevenBlack ?

[DPTJKKVH]

Thanks @StevenBlack for considering this. I don't want to force a conversation in a closed bug report so please allow me a final response to what you said:

I never said they are a "bad" player. I know first hand how complicated it can be to deal with user created bug reports without any easy way to reproduce the issue. So in my very personal opinion they are indeed "better" than most "analytics" service provider. However this all ties back to the question if we are the ones to decide if the good end justifies the means.

One very well could argue that Google is a good player as well since they do create ad revenue for independent journalism and valuable insights for salesmen around the world.

One could even argue that Sentry is more dangerous than Google Analytics since a misconfigured blacklist results in passwords being logged in plain text and sent to a third party.

Ultimately the means in both cases are the same and as such we should treat them equally.

[dcramer]

If y’all really want to block Sentry and everything else on the internet why don’t you just disable third party scripts in you’re browser?

Alternatively as suggested in the original post the main issue is most users are unknowingly blocking Sentry which isnt an adserver. It doesn’t mean you can’t block it just when people blindly do it because of easy defaults (and as tools gain popularity) it can actively cause ecosystem harm.

I think this is an internet-wide problem these days and I personally don’t believe blocking all services is the right answer. There are certainly good players and we all know there are a large amount of bad players.

Again if PI were to implement categorical selection I’d be ok with this, just as is I have technical colleagues who had unknowingly blocked Sentry and didn’t intend to. Give users the choice and educate them on what their actions mean.

[dcramer]

Also sorry for all the noise this is causing.

One last point and I’ll leave you all to your own vices: Sentry does not collect passwords, and cannot accidentally collect things like that using its JavaScript component. The areas where sensitive data live are fully on servers so blocking the host on the client side wouldn’t prevent that kind of concern anyways.

[DPTJKKVH]

If y’all really want to block Sentry and everything else on the internet why don’t you just disable third party scripts in you’re browser?

Because we don't want to blindly break functionality of the website or service that the user is consciously visiting.

What you describe is a business issue on your side that you should educate your own paying customers about if it's really a significant problem to you.

There is no reason why we should cater to your business model because then Google, Facebook and others will be the next asking us why we are not considering their business.

[StevenBlack]

I'm sorry guys, maybe I wasn't clear.

Decision made.