741–750 of 907 posts
Earlier quoted context omitted.
https://grapheneos.org/features#anti-persistence GrapheneOS has apex modules disabled and never had the need for that.
ART updates are distributed via APEX since Android 12. So is it stuck in Java 12?
Earlier quoted context omitted.
AOSP is open source so it could be forked.
Except many key features are nowadays delivered via APEX modules, distributed via PlayStore. https://source.android.com/docs/core/ota/apex
Google began shipping Google builds of the APEX modules via the Play Store to work around non-Pixel devices not shipping the latest monthly, quarterly and yearly OS releases. For Google Mobile Services devices, many of the APEX modules are required to be the official Google builds from the Play Store. The changes to APEX modules are released as part of the quarterly and yearly AOSP releases.
Earlier quoted context omitted.
[flagged]
Yeah, this is pretty much the rationale behind the Paradox of Tolerance, which you alluded to. Just as a tolerant society cannot tolerate intolerance without eventually just becoming intolerant, this clearly demonstrates that the same is true for Free Software. If we tolerate the use of Free Software for the use of the non-free software, eventually one loses the freedom in Free Software. It's of course not a perfect…
I’ve always thought this was hand wavy nonsense. Tolerance and tolerating is so ill defined in these discussions that they end up pointless.
I’m also not sure game theory supports that intolerance wins out if you view it as repeated instances of the prisoner’s dilemma.
Earlier quoted context omitted.
ART updates are distributed via APEX since Android 12. So is it stuck in Java 12?
I believe it's similar to kernel modules in that they can either be compiled into the kernel or distributed separately. Graphene probably just distributes it as part of the system images. This just means rollouts are coupled. Apex doesn't imply closed source, only that there is a stable surface that allows more modular updates.
Earlier quoted context omitted.
https://madaidans-insecurities.github.io/linux.html
It's a different approach to security. There are no malicious apps in GNU/Linux repositories. (And yes, Linux security should be improved; I run Qubes on desktop) https://source.puri.sm/Librem5/docs/community-wiki/-/wikis/F...
That's definitely not the case. There have been repeated cases of developers shipping malicious code which ended up in distribution package repositories. Defining malicious is difficult and incredibly privacy invasive behavior is often not considered to be malicious. That software is also generally being used without a mandatory app sandbox with a proper permission model, so it can access whatever it wants for the most part beyond self-imposed restrictions.
There are similarly maintained package repositories for Android such as F-Droid. It adds the people doing packaging as trusted parties. Contrary to common misconceptions, Linux distributions and F-Droid are not meaningfully auditing/reviewing the upstream code and therefore not actually significantly reducing trust in the upstream projects. There substantial delays for updates with how most are maintained, so that gives time for external parties to find issues but doesn't mean it won't be packaged and shipped anyway.
Earlier quoted context omitted.
GrapheneOS is in some ways not an open OS. The official builds don't provide root access. So for example apps are able to hold your data hostage from you. I get that this is in the name of security hardening. And you can make a build that has limited root access and is officially supported. But GrapheneOS isn't the end-all solution to computing freedom. Although hopefully on those devices you will be able to install…
GrapheneOS is all about security, not privacy or freedom. You coincidentally get privacy and freedom benefits, but only where they don't conflict with security.
Earlier quoted context omitted.
Looks like GrapheneOS will be available on another "major Android OEM” soon [1]. Regulation should prevent Google from subsidising manufacturers to use Android. Arguably the recent antitrust legislation [2] applies in this case because they're effectively paying manufacturers to place that horrendous and impossible to remove search bar on the home screen. [1] https://www.androidauthority.com/graphene-os-major-android…
GrapheneOS is in some ways not an open OS. The official builds don't provide root access. So for example apps are able to hold your data hostage from you. I get that this is in the name of security hardening. And you can make a build that has limited root access and is officially supported. But GrapheneOS isn't the end-all solution to computing freedom. Although hopefully on those devices you will be able to install…
Devices built to officially support GrapheneOS MUST include first class support for using an alternate OS that's not the official GrapheneOS, which is part of our requirements at https://grapheneos.org/faq#future-devices. These requirements apply to official GrapheneOS devices in the same way as devices using a Google Mobile Services stock OS. Combined with the OS being open source, that's what gives people the freedom to legally and practically use/make forks of it with arbitrary changes.
Userdebug builds of GrapheneOS are officially supported, although we don't recommend using them on a production device. Setting ro.adb.secure=1 for a userdebug build does preserve most of the security as long as ADB isn't used, but not all of it. It still downgrades security when ADB isn't used since the changes to accommodate having root access and other debug features via ADB have an impact beyond when it's actually used. It doesn't destroy the overall security model in the way people typically integrate root access where a huge portion of the OS has it and it's accessible to apps in a persistent way.
Earlier quoted context omitted.
Root access isn't available by default, but it takes about 120 seconds (including waiting for it to reboot) to add it.
Last I checked the situation was similar to what it is in Calyx, which is that it's not officially supported and you have to keep manually reapplying the root after every update.
Modifying the official builds by replacing part of the core OS with Magisk and then using that to modify the rest of the OS dynamically is what's not officially supported and strongly discouraged. That doesn't mean there isn't official support for root, which is available in userdebug builds without the same massive negative impact to the security model of the OS.