yore

  • Joined Sep 3, 2023
  • An anonymous GrapheneOS user who wants to help out others in need.

  • GmsCompatConfig version 151 released:

    https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/releases/tag/config-151

    See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.

    GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims and sets the maximum supported versions for Play services and the Play Store.

  • qp5235 Can someone provide a link to a survey result which confirms the statement above?

    If there is none, then it's likely inaccurate. Because multiple users on this forum already expressed the same view.

    There are no survey results for either side of the debate that I know of. I remember when the boot animation was updated and many people said they liked it. I don't think a large chunk of GrapheneOS users want the boot animation to be changed. It's brought up very rarely. I can think of other changes people want way, way more.

    qp5235 It only clearly displays that the device is running an alternative OS.

    qp5235 The above assumes that the level of attention would be the same, regardless of which alternative OS is being used.

    Which is not necessarily accurate though.

    Because not all alternative operating systems are the same and the level of attention might be higher for a device that is using GOS (which is known for security) compared to what it might be for other alternative Android operating systems (which are not necessarily known for security).

    But if someone who is interested in these things notices that an alternate OS is installed by seeing the very obvious triangle during boot, they would know enough to make an educated guess which OS is installed. I just searched for videos of other OSes' boot animations and it looks like they have their logos in theirs. So, since other popular Android OSes have their own unique boot animations, anyone who knows enough about GrapheneOS would know which boot animation GrapheneOS uses and can suspect GrapheneOS is installed on a phone just by seeing the boot animation regardless of whether it's the current one or the AOSP one.

    So removing the GrapheneOS logo in the boot animation wouldn't really achieve anything, except maybe fooling certain people.

    qp5235 It doesn't. Because it exposes more information about the device (in a locked state) than necessary.

    That information is already available in BFU as multiple people have already pointed out.

    qp5235 it exposes more information about the device (in a locked state) than necessary.

    qp5235 It is not easy (without physical access and from just looking at the verified boot hash in tiny font on a smallish display). And it also would not necessarily be easy even with (short) physical access.

    I'm not sure what you're trying to protect yourself from. If someone can see "GrapheneOS" in recovery, they have physical access to the device. If they have physical access to the device, they can see and even write down or search the internet for the boot hash. A shoulder-surfer who sees the triangle and boot animation will know an alternate OS is installed and can get a good idea as to which OS is installed based on which animation they saw.

    Enough people know about GrapheneOS that feeble attempts to hide which OS is on a phone won't make a big difference.

    qp5235 Why would they dislike (or "hate") it?

    People can have very strong opinions about different UI/UX things. Not sure how long you've been around in our community, but people complain almost any time there are upstream changes and they ask for GrapheneOS to revert things. One example is when the lockscreen clock font was changed upstream. People were very unhappy.

    There are many people who are proud to have GrapheneOS on their phones. I'd imagine they'd be unhappy if the boot animation were changed. I think some who really dislike Google would be very unhappy if the boot animation was changed to look more like the stock OS's.

    qp5235 Adding a custom (GOS branded) boot animation does not add security and might decrease security.

    How? Like what specific situations are you thinking about here?

    I'm personally not convinced there's a security issue here, and if someone finding out GrapheneOS is on a phone is a security issue for people, then I'd be very curious as to why that is.

    qp5235 Which "pro"? Which benefit does a custom (GOS branded) boot animation provide?

    The way I see it, pros would be:

    • Less confusion for new or inexperienced users (same goes for having "GrapheneOS" in recovery)
    • Logo for people who like the OS and don't want to hide that they have it installed on their phones
    • Good for the project to have the logo on phones and I've even seen pictures of phones with the boot animation running on external websites when they talk about GrapheneOS.
    • Some people actually like the animation and are happy to have it show up on their phones.

    I, personally, still can't think of any good and compelling reasons for changing the boot animation back, except maybe fooling some people or hiding something from shoulder surfers.

    So, again, I think the pros outweigh the cons.

    • I like to brag and show im using GrapheneOS. I care about security. Whoever I speak about it and convert user into it thank me later always.

      • Hey

        improve zoom gesture by scrolling during zooming to keep focus in the same place instead of the top left corner

        thanks :)

      • Thanks a lot for your explanations. It's always nice to have some insights and backgrounds on current developments.

      • 01123581321 disable interface animations

        Theres currently a bug with widgets thats hitting some people who have animations disabled.

        https://github.com/GrapheneOS/os-issue-tracker/issues/4275

        Regarding the bottom pill - the development team have always got a long list of high priority issues and features that are being worked upon. Making any modification to the OS can often take considerably more time than may initially be expected. We implement features properly rather than as fragile hacks. Any changes need maintaining as AOSP and other upstream code changes. This can take a lot of work. Every change has to be carefully considered. What is the priority. Is it worth the work. What is the potential for the change to cause us problems later.

      • 01123581321 To my eyes the GrapheneOS team is not at all "conservative" when it comes to making changes that improve security and privacy (storage scopes, contact scopes, duress PIN, PIN scrambling, and many others). But they appear to be actively disinterested in UI tweaks unrelated to security and privacy.

        Every GrapheneOS change must be re-merged against each monthly Google release. This takes some time (at least computer time) for every GrapheneOS change, so fewer is better.

        Other Android variants work the opposite way: they prioritize their local changes, including UI tweaks, even if that limits their ability to merge security fixes promptly.

        In a sense the GrapheneOS project was founded to work on the opposite of the kind of feature you are requesting, and in a sense shipping that kind of feature opposes the project's core goals. So it might not happen.

        Please note that I do not speak for the GrapheneOS project.

        • Android 15 QPR2 is moving 6th/7th/8th generation Pixels to the Linux kernel's 6.1 LTS branch already used for 9th generation Pixels. This will reduce the kernel branches we need to support down to 6.1 and 6.6. There will likely need to be a yearly migration for all the devices.

          Linux kernel increased official support time for the Long Term Support (LTS) branches from 2 years to 6 years, mainly for Android devices using Generic Kernel Image (GKI) releases. However, it was recently reduced back to 2 years. Pixels will need to start migrating every year.

          It will likely take around 6 months for a new branch to be considered stable enough with most regressions resolved and another 6 months to successfully integrate and ship it. Therefore, 2 years of support implies yearly migrations to keep up rather than doing it every 2 years.

          Upstream LTS releases are closely connected to Android. Moving to 6 years of support was likely closely connected to the Pixel 6 moving to 5 years of support. GKI made the drivers far more standalone and easy to migrate, and Linux moving back to 2 year support is likely related.

          Google has been testing newer kernels with the Pixel 6 and later for years. They have 6.6 and newer mainline kernels working fine already, it just takes a long time until the kernels are stable enough to consider shipping them. It's great that it's finally going to be happening.

          Newer kernels bring many new features and increasingly complexity which means they bring lots of new security bugs. Older kernels get an increasingly small subset of bug fixes including security fixes backported in the LTS releases. Newer kernels also bring new security features.

          Using a year old kernel for around a year and then upgrading to a new year old kernel is likely the best balance that's available. With 2 year support time, they can focus on backporting more patches and providing more testing/stability since there will be far fewer LTS branches.

          It's not commonly understood that Android itself only has a single LTS branch, which is current Android 15. It receives monthly and quarterly updates. It moves to a new LTS with a yearly update after it has gone through many months of public testing via Developer Preview / Beta.

          Many people including journalists covering it in tech news media wrongly believe Android's monthly security patch releases are the monthly releases. No, the monthly security patches are backports of a subset of the privacy/security patches to older releases. They're incomplete.

          Android's monthly releases have many changes beyond privacy/security patches even when it's not a quarterly or yearly release. They also have a lot more privacy/security patches than the Android Security Bulletin backports. They backport High/Critical severity patches, not all.

          These updates are a major factor in why Pixels are the only Android devices with competitive security with iPhones. Pixels also have a lot of hardware security features not implemented on other Android devices. They also have higher quality of implementation across the board.

          Google will likely require other OEMs start upgrading kernel branches. However, standards for other OEMs are always far lower than the standards met by Pixels. For example, many important hardware security features are recommended in the CDD, not mandatory, or not even listed.

          We aren't aware of any OEM trying to keep up with the monthly releases, only OEMs skipping all the monthly/quarterly releases but trying to ship the yearly release around the official launch. Only Samsung tries to keep up with the new security features, but lags quite behind.

          Other Android OEMs do the bare minimum required by Google unless their SoC vendor (generally Qualcomm) hands the feature to them on a silver platter with no additional cost. They largely ship the monthly security backports now, but with significant delays or skipping some months.

          The reduction of support time for Linux kernel LTS releases from 6 years to 2 years is likely going to become a major problem for non-Pixel Android devices. Google will likely require them to upgrade but probably at a very delayed schedule where they fall out of support first.

          Our official hardware requirements are listed here:

          https://grapheneos.org/faq#future-devices

          You can see support for Linux 6.1 or 6.6 is already a requirement for new devices. We'll be adding a requirement to upgrade the kernel branch because it will be essential with 2 year Linux LTS support.


          Social media threads:

          X: https://x.com/GrapheneOS/status/1860365266921603389
          Bluesky: https://bsky.app/profile/grapheneos.org/post/3lbmyp4jfi22b
          Mastodon: https://grapheneos.social/@GrapheneOS/113533415116755738

        • 01123581321 Input points on hiding bottom pill so the conservative GrapheneOS team will finally add this setting.

          The GrapheneOS team generally does not make tweaks to the UI, instead shipping the UI Google ships in AOSP. So lobbying Google for their UI team to add the option to AOSP may well be more productive than lobbying the GrapheneOS team. Google makes UI changes frequently.

          • yore

            That makes sense! I'm sure whoever writes the announcements for the forum, social media, etc... would be able to come up with a more elegant phrasing than what I threw together up there in 10 seconds :)

          • ErnestThornhill

            Wouldn't it be amazing if they just made a tiny tweak to the announcement message to be more user friendly (particularly for new users) so we didn't have to answer this question countless times? Literally, just a tiny change to the existing template:

            GrapheneOS version 2024111700 released to alpha channel for testing. This may be released to the Stable channel in the near future if no issues are discovered during testing.

            https://grapheneos.org/releases#2024111700

            See the linked release notes for a summary of the improvements over the previous release.

            • We've added the new official Flarum GDPR extension providing support for account anonymization and data export. These are available in your user account's settings at the bottom as Erase Account and Export Data.

              Erase Account takes 30 days to happen automatically but a subset of the mods can manually approve the requests earlier. We'll wait a few days to give people time to cancel. This will delete all the account data and reassign the public data including posts to an automatically created deleted user account to replace your account. We can choose to trigger full erasure for an account where all posts are deleted but will not do that in practice. Posts are public and crawled/archived elsewhere so it wouldn't accomplish much and would ruin a bunch of discussions, so we're using the anonymization method as the default.

            • Sounds like it's just auto reboot, you can turn it off or make the timer longer in settings > security & privacy > exploit protection

            • bigtechhater I was not using a VPN and am on my home IP. (Did the website send Facebook my ip maybe?)

              That would be easy enough, especially since the IP address is probably in a netblock for residences, i.e., it is an IP address that likely maps to a small number of people, unlike a library or corporate address.