This particular line in the developer's response[1] leads me to believe they don't - or at least don't properly - validate third party dependency changes, which is even more worrying if I'm honest:
> I will look into why Sentry.io is being contacted so often! This is strange as unless they changed their SDK/framework, is only supposed to happen on a crash report.
That's a poor characterisation, I'm not convinced any developer can say with 100% certainty they've never missed anything in the release notes of their dependencies or had any unexpected behaviour in changes that made it to production. Mistakes happen.
I agree with sibling: I think you're giving it an uncharitable interpretation. There is an open issue and they are investigating to improve the situation.
You’d think, if they wanted telemetry so badly they are prepared to deal with the fallout, they’d be on top of the information collected by that telemetry.
Crash dumps can contain highly sensitive info. I have blocked Crashlytics[0] and Sentry with my pi-hole so nothing gets sent. I'm starting to believe these tools are abused and not even used to improve services. They're basically a MITM so people can violate other's privacy.
You can block the root, but usually the domain contains random (unique) strings as a subdomain, so you need to wildcard block it, which pi-hole supports.
Thanks. Bummer, I figured they probably didn't use the root domain but some amalgamation of letters/number/sub-domains. I have a pi-hole at home which has been working great for 3+ years now, but I mostly run objective-see stuff on my work machine.
You can block Lulu with Lulu. I think by now we should all have learnt to block internet access for every app, and only enable it if it really needs it - that's exactly what an application firewall like Lulu is for.
Potentially relevant that the Sentry client is configured in debug mode there. Not sure what the actual impact of that is but maybe it causes additional network traffic to Sentry (outside of crash reports)?
you can actually use lulu itself to block sentry for all of their tools (this is what i do). i found that the only other connections they'll make is for updates--both software and rulesets (if you have that configured).
lulu is not nearly as polished as hands off! (may it rest in peace) or little snitch, but it gets the job done. i also have some rules in pf (via murus gui) to block things like google and facebook on a system-wide level.
It's troublesome that an app designed for blocking telemetry (among other things) is sending telemetry without consent. :(
Software that exfiltrates your usage, crashes, or other data from your own machine without advance, opt-in, informed consent is unethical and disrespectful.
I sent a message to slack the other day recommending Shortcat (https://shortcat.app/). I edited the message to mention that I use LuLu and it's worth noting that Shortcat is closed source and does send info out to sentry.
Now I have to edit that same message and mention that LuLu also phones home to sentry. Can't blame people for wanting stack traces but wow it's a tricky subject in terms of privacy.
I've been using Shortcat for years, and I thought it was long since abandoned. I was even more surprised to see a new version was released last month. I seriously stopped checking on this project years ago, and just kept a backup .dmg.
I am sad to read about sending out info to Sentry, but I guess that is something I am going to have to think about some more.
Personally I'm not comfortable with this due to the level of access they require and thought it worth to mention.