It looks like Android 16 will be quite the promising update.
If I had to guess, once 16 rolls around to Graphene, Graphene’s gonna use some of these added protections by default. I also heard that Advanced Protection will disable sideloading by default, which on stock, could unfortunately restrict people from installing apps like Tubular or FlorisBoard.
Disabling sideloading by default isnt inherently a bad thing. This is a broader approach to improving security mostly for those who might unknowingly side load malicious applications. I think providing an option to override this for power users or installing these prior to toggling on advanced protection procedures would be great.
Graphene will take full advantage and maybe be able to implement it better.
You realize that there is no such thing as sideloading? Why is downloading from the Play Store considered safe, while downloading from Acrescent isn’t?
Now if this has options to enable install from trusted app stores outside Google Play, then it’s good.
Disabling sideloading is disappointing, I hope they let you disable that. Otherwise looks awesome.
I don’t see anything new to GOS besides disable sideloading and Google stuff. But for other phones cool.
you mean you hope they let you enable that?
Well I’m hoping GOS will take what’s in the android advanced protection and put everything and letting the sideloading be opt-in opt-out
From the article:
These settings cannot be adjusted, helping ensure a consistent security level.
Honestly the only thing here that I think might be useful for GrapheneOS users is if apps choose to support the API. Then again it’s very possible they’ll just use it to force enable already existing settings which could be more annoying than useful. This seems to be the approach Google is taking with their first party apps.
Is it from AOSP or part of Google Services?
Maybe the web protections? There is already Vanadium, but perhaps here we see some iOS-like Safari lockdown?
But from the wording it might just be disabling JIT, which would be disappointing.
Regulators really need to crack down on Google and Apple using “security” as an excuse to evade their anti-monopoly court judgements.
If this works the same as Advanced Protection Program though, you’ll be able to sideload APKs for initial app installs via ADB, and then any alternative app stores you sideload with ADB will be able to update themselves and those apps on-device from there on out. Still annoying, but not the end of the world.
The irony is that this workaround introduces more risk than just using trusted App Stores (F-Droid, Acrescent, etc.)for app download, because at least those have verification in place.
It’s a shame that you cannot enable trusted app stores, or that Google doesn’t have a “Trusted app stores” program. At the very least there is no reason Acrescent shoudln’t be allowed, it is more secure and private than Google Play.
The rest of ADP is very good, the fact that it automatically enables secure settings across Google apps, and third-parties app (if/when they choose to integrate) is also very neat.
Yes. However, once you install an update from a trusted app store (or reinstall the currently installed version? I don’t remember if you can do this) that will serve as a verification that the app matches the app store’s trusted version of it, since otherwise Android would fail to install the update due to a signature mismatch.
There is definitely more risk though, yeah, and it is an absurd restriction overall.
By default, on new devices? Will the user be able to turn it off without messing around with adb? From the news it looks like it’s something the user has to enable themselves (I hope it’s the case).
One benefit ADP could have would be allowing non-Pixel android users some peace of mind against targeted attacks. HEAVY emphasis on peace of mind. I don’t know how these additional features can protect users without the added benefits of frequent security updates or longer support duration.
You may want to read this part of the blog. Seems to be an opt-in feature.
- Defense-in-depth: Once a user turns on Advanced Protection, the system prevents accidental or malicious disablement of the individual security features under the Advanced Protection umbrella. This reflects a “defense-in-depth” strategy, where multiple security layers work together.
I see. Glad to know that. Although in some cases the F-Droid version is different signature than the Github release version, in which case you are cooked (I remember Mull had this problem, so when Firefox had a critical vulnerability, SkewedZepelin put an emergency update on Github, but I couldn’t update because the signature was =/ than the F-droid version)
Yep. Big problem with some (most?) F-Droid apps and most Google Play/Aurora apps. Luckily Accrescent doesn’t have this issue, and obviously Obtainium wouldn’t either.
Google Play obtained apps will get worse at this over time (which is why it’s best to discourage Aurora/Play as much as possible now), and F-Droid apps will get better over time. Ideally F-Droid will add some indicator showing which apps have reproducible builds with developer-provided keys.
Does reproducible builds mean the problem with the signature will not be a problem anymore ?
Also, F-Droid biggest problem isn’t the lack of enough reproducible builds, but that even security updates can take >48 hours to be shipped.
Apps which support F-Droid’s reproducible builds can be distributed on F-Droid with the developer’s signing key instead of F-Droid’s.