Hans-Christoph Steiner @eighthave@librem.one

@jz YES! I'm already a practioner! I highly recommend it

@Billie For apps that don't have features broken by #targetSdkVersion, you might as well up it. If your app is in a memory safe language e.g. Java, Kotlin then the targetSdkVersion does not help you much while restricting features. If the app uses C/native code and you don't want to think too much about security vulns, then upping it could help you. My understanding is that #Google thinks of it as a way to protect private data from unknown apps, so they don't have to review uploads to Play.

Sandboxes have often been represented as a security feature, but it seems there are always ways out, e.g. there are always jailbreaks available for iOS. Sandboxes still make sense for restricting non-malware apps from accessing private info. For security, its more important to avoid targeted exploits, e.g. reducing identifiability, to force the use 0days into broader targets, which is then more likely to burn that 0day. Users of 0day exploits are rarely willing to burn one to target one person

@rogermcnamee on top of that, each affected Facebook user has been allocated about $2.25. Yup, two dollars and change. A classic example of the problems of class action lawsuits. The firm gets to cash out with $181 million, but the actual settlement for the affected parties is not worth the time to do the paperwork.

@filippo Cloudflare will tell you about it: https://blog.cloudflare.com/icloud-private-relay/ It is based on the #IETF #MASQUE standard for proxying over UDP/QUIC.

@mozilla here's the link, I think https://blog.mozilla.org/en/mozilla/mozilla-launch-fediverse-instance-social-media-alternative/

@somegirlprivacy@mstdn.asprivacy.com I'm not saying it should not be updated, we welcome contributions there. I would love to see F-Droid working well everywhere, I can't do it all, and the dev team for #FDroid is small. We can make it work well for a lot more people if there are more contributors.

We welcome help for bumping the #targetSdkVersionfor #FDroid and have mapped out what needs to be done:
* https://gitlab.com/fdroid/fdroidclient/-/issues/2037
* https://gitlab.com/fdroid/fdroidclient/-/issues/1440

Given our limited resources, I have chosen to focus my time on concrete improvements for #FreeSoftware. The only thing I'm opposed to in all this is removing functionality in order to bump targetSdkVersion. Google's recent changes there have removed functionality that many rely on.

When #FDroid is built into a #FreeSoftware ROM, like #CalyxOS, #lineageos for #microg, etc there is no popup warning with fdroidclient. That comes from "Play Protect", which is #Google proprietary software that flags things based on automated rules, it does not point to real world security concerns for apps like #FDroid. I have nothing against the #targetSdkVersion sandbox, I just think it is important to note what it is good for, and what it cannot do well 2/2

As lead maintainer of the official #FDroid client, I hear a lot of criticism that #targetSdkVersion is still at 25. fdroidclient is #FreeSoftware, publicly audited, with #ReproducibleBuilds, written in memory safe languages, with a proven record of respecting #privacy and delivering #security. The source and binaries also receive human and machine review. #targetSdkVersion is designed around untrusted proprietary software with non-memory safe code where the binary only gets machine review. 1/2

@guardianproject @lauren And of course #ReproducibleBuilds is a key part of this whole picture, allowing anyone to confirm that the exact binary that is running on their device matches the source code as published and audited.