troet.cafe ist Teil eines dezentralisierten sozialen Netzwerks, angetrieben von Mastodon.
Hallo im troet.cafe! Dies ist die derzeit größte deutschsprachige Mastodon Instanz zum tröten, neue Leute kennenlernen, sich auszutauschen und Spaß zu haben.

Verwaltet von:

Serverstatistik:

7,2 Tsd.
aktive Profile

Mehr erfahren

Vorsicht mit dem neuen @accrescent App-Store:

Das ist ein neuer alternativer Android-App-Store, der von sich behauptet, auf Privacy und Security fokussiert zu sein. Er wird auch über den @GrapheneOS Appstore angeboten.

Bei genauerem Hinsehen finden sich allerdings Apps, die Werbe- und Analysetracking enthalten, wie ich nach kurzer Prüfung feststellte.

Der Entwickler sieht darin kein Problem …
1/2

@rufposten @accrescent @GrapheneOS
Ich denke der Hintergrund ist ein grundsätzlich unterschiedliches Verständnis von Datenschutz in verschiedenen Bubbles der Privacy-Community.

Auf der einen Seite ist es mehr absolut: Was eine App kann, das müssen wir auch annehmen, dass sie das auch tut. Ob es faktisch Tracking gibt oder nicht, ist dabei fast egal, genauso wer die Daten bekommt (weil er ja weitergeben könnte). Der einzige wirksame Schutz ist, die zugreifbaren Daten zu reduzieren.

@pixelschubsi @rufposten @accrescent That is how GrapheneOS approaches privacy as an OS but it is not how we approach privacy in terms of recommending apps and services. They're different things. Technical measures in the OS can't be based on enumerating badness and implementing easily bypassed barriers which don't work if adversaries are aware of them. Privacy/security features need to hold up to an adversary aware of it and which can actively adapt to it in order to be a serious approach.

@GrapheneOS @rufposten @accrescent
> Privacy/security features need to hold up to an adversary aware of it and which can actively adapt to it in order to be a serious approach.

See, this is what I mean. I totally agree with you on the one hand, but on the other hand, I understand people consider, for example, an ad blocker a useful tool, because it works reasonably well in practice even if technically, it can be bypassed easily.

@pixelschubsi @rufposten @accrescent

Content filtering based on enumerating things that are only used for ads, tracking, etc. and not for anything useful is inherently incapable of fundamentally protecting privacy. It can only provide an opportunistic reduction in exposure to privacy invasive practices. In practice, adblockers cannot and do not block services which are used for both useful functionality and ads/tracking. It is not simply that they are easy to bypass due to enumerating badness.

@pixelschubsi @rufposten @accrescent There's a big difference between fundamental privacy improvements and increasingly weak approaches for opportunistically improving privacy. The opportunistic privacy improvements get increasingly less useful as development practices change to integrate the privacy invasive code without having an easy way to block it. The more coarsely the filtering is done, the easier it is to render it useless as an approach. Sharing with 3rd parties can be done server side.

pixelschubsi

@GrapheneOS @rufposten @accrescent
I know all this. But again: In practice ad blockers work reasonably well. Yes, some ads manage to pass through, but most get blocked. It effectively improves the user's experience.

The absolute stance would be to say that either you have to accept the websites render ton of ads, because there is no guaranteed way of blocking them, or you stop using the web. But some people prefer the non-absolutist way, that is to use an ad blocker.

@pixelschubsi @rufposten @accrescent GrapheneOS has a Vanadium browser project which includes an adblocker. We do not present it as an important privacy feature. It uses EasyList + EasyPrivacy and enables language specific lists based on which languages the user has enabled to avoid it being additional fingerprinting attack surface. The content filters are shipped in a signed APK via our App Store. It is not a fundamental improvement to privacy. It only opportunistically eliminates some stuff.

@GrapheneOS @rufposten @accrescent
Please realize how I was talking about ad blocking and ad blocking only here, not that some ad blocker lists also include tracking blocking.

I use the ad blocker example because it's a perfect analogy that is much easier to grasp. The effect of privacy blocking is almost impossible to quantify, because you don't know how much less data about you is collected due to using them. With ad blockers you can easily see yourself how effective they are.

@GrapheneOS @rufposten @accrescent
If ad blockers work reasonably well in practice, it is likely that privacy blockers do so as well. They're not perfect, they will let some data slip through, so any absolute approach is to be preferred when available and applicable. But they likely are a good addition to provide opportunistic improvements for what absolute approaches can't do (yet).
Opportunistic improvements are still better than no improvements.

@GrapheneOS @rufposten @accrescent
And in case that wasn't obvious, this isn't meant as an attack towards GrapheneOS. You do amazing work and your results are astonishing. But that shouldn't keep you from realizing that the work of others, even if only opportunistic, also improves people's life in the wild.

Greetings from a user of a custom-built GrapheneOS modified to support microG in regular user sandbox.

@pixelschubsi @rufposten @accrescent Doing something is not always better than doing nothing when it gives people a false sense of privacy/security, takes away from other efforts, etc. There is a limited amount that can be done and it matters where those resources are expended. Users can also tolerate a limited amount of complexity, sites breaking, etc.

@pixelschubsi @rufposten @accrescent No, that is not a reasonable thing to infer because privacy works fundamentally differently from displaying ads and can't be seen and corrected when they slip through. Invasion of privacy including sharing data with third parties after it's obtained does not require any direct contact to third parties from the client side, which is what those are focused on filtering, but only when it doesn't break functionality of sites. They can't block dual use tracking.

@GrapheneOS @rufposten @accrescent
You're right in theory, but not how things work in practice. The large majority of apps send tracking data to Google exclusively directly through their tracking library. They don't send tracking data to their own servers so they couldn't silently forward it. A future version could send tracking data to their server, just as a future version could serve ads through their server. Thus, with every new version you'd need to verify again what they send where.

@GrapheneOS @rufposten @accrescent
We know that in reality, most websites don't try to bypass adblockers. Some try to detect them and block using their websites if you don't disable them. The same holds true for tracking, where the ROI to build a bypass for the blocker is even lower (because the tracking data really isn't worth as much). This is of course what we know from the web, but there's no reason why this should be any different on android apps.

@pixelschubsi @rufposten @accrescent Content filters have barely any impact on the website itself performing tracking of what users are doing. That is where they largely succeed rather than with ads, which are visible to users and get reported and fixed. They also aren't fundamentally tied into the site working in the way that tracking users often is. No need for entirely separate stuff to track users, it can be baked into everything.

@pixelschubsi @rufposten @accrescent Sites do often put effort into bypassing adblockers but users see it and report it, then it gets addressed. They can keep doing it again and again but don't generally bother since it won't last. Lower traffic sites have much more success with this. There hasn't been much serious effort into breaking adblockers for web sites yet but it's gradually happening.

@GrapheneOS @rufposten @accrescent
Also, there's privacy laws (at least here in the EU). Forwarding the user's IP address from your server to Google for Analytics would be illegal without good reason, but connecting to Google servers for Analytics and there for effectively sharing the user's IP address as well is considered legal because it's technically required.

@GrapheneOS @rufposten @accrescent And lastly, Google doesn't even provide proper APIs to pass data into Google Analytics without using their tracking library. So using a tracking blocked which blocks their tracking library in fact does effectively block the app from sending tracking data to Google. Yes, a win against Google is just a small win, but it's a win that can be reached.

@pixelschubsi @rufposten @accrescent Sites use plenty of APIs which are genuinely useful to users and therefore don't get blocked by a content filter. Third party tracking does not have to be a service called analytics. It can be a bunch of useful functionality such as maps, push, etc. they include in the site which is not going to be blocked by any normal adblocker since it would break sites. Look into how the adblocker lists work. They permit tracking if sites break without it.

@pixelschubsi @rufposten @accrescent One of the most simple and successful ways to do it is where requests are sent through a third party service for click tracking which involves a redirect to the service and then to the site where it has to be followed to get the destination. Adblockers have exceptions for these in the privacy filters since blocking them would break sites. These also bypass cookie isolation used by Firefox, Brave, etc. to restrict cross-site cookies by matching heuristics.

@GrapheneOS @rufposten @accrescent
All you write is correct and still it is totally missing the point.

Try the following: Install a popular ad blocker into your web browser and configure ad and privacy filters. Now open the developer tools to monitor all requests done. Navigate to a few popular websites and check how many invasive cookies are set and how many tracking endpoints data is sent to. Now reset and repeat the same with the ad blocker disabled.

You'll see the blocker blocked a lot.

@GrapheneOS @rufposten @accrescent
If those resources and cookies blocked had not been of purpose to the tracking/ads/... industry, they would not have been requested. Thus, while certainly not perfect, it reduces how much tracking happens and/or how much data is shared and/or how many receive it.

It might not be perfect, but it did some good. And that's better than doing nothing just because you can't be perfect.

@pixelschubsi @rufposten @accrescent We never said to do nothing and after all our Vanadium browser includes content filtering with a privacy list in addition to an ads list. It doesn't mean we think it's a strong privacy feature or a fundamental privacy improvement. It's an opportunistic privacy improvement with rapidly dwindling value.

@GrapheneOS @rufposten @accrescent
Not everytime people talk with you it's also about GrapheneOS. This is about Accrescent not caring about and not willing to tag apps with known tracking. This is the kind of tracking you also block in Vanadium. And I understand Accrescent can't block the tracking, but at least tagging it if it's known (opportunistically) would be possible. Not doing so is thus similar as it would be to not have an ad blocker in Vanadium.

@pixelschubsi @GrapheneOS @rufposten @accrescent even that is doubtful at hest and one needs to acquire proper consent.

  • Otherwise my current employers' main product would not exist and I'd be without a job!