J
jackFang

  • 6 days ago
  • Joined 15 Jan
  • GrapheneOS fully supports the Private Space feature in Android 15, which is essentially a separate user nested inside of the Owner user.

    We strongly recommend it as a replacement for a work profile managed by a local profile admin app. It has better OS integration and isolation.

    Private Space is an isolated workspace (profile) for apps and data similar to both user profiles and work profiles. All 3 forms of profiles also have entirely separate VPN configuration which is very useful even if you connected to the same VPN, since exit IPs can be separate.

    All forms of profiles have separate encryption keys. You can keep a Private Space at rest while the Owner user is logged in just as you can with a secondary user.

    Private Space makes it easier to share data than users. The clipboard is shared, but we could add a setting for it.

    GrapheneOS users choose to use the OS in different ways. A lot of people largely use open source apps and not sandboxed Google Play. Others use sandboxed Google Play in their main profile. Many use sandboxed Google Play in a dedicated profile to choose which apps use it.

    Regardless of how people choose to use sandboxed Google Play, they're regular sandboxed apps without special access. Private Space makes it easier to use a dedicated profile for sandboxed Google Play though.

    It's also worth noting you can still use a work profile alongside it.

    All of our features including Contact Scopes, Storage Scopes and sandboxed Google Play have full support for Private Space. We added support for it significantly before the release of Android 15, even before the initial early release of the source code was published in September.


    Social media threads:

    Mastodon: https://grapheneos.social/@GrapheneOS/113351721569189227
    Bluesky: https://bsky.app/profile/grapheneos.org/post/3l74cuxsgee2x
    X :https://x.com/GrapheneOS/status/1848744438568263956

    • jackFang A device can have Auditor pairings with multiple devices rather than only one. You could also set it up with our https://attestation.app/ service. The Auditor-side pairings also get backed up as part of regular app backups including cloud backups. We haven't fully worked out how it should integrate with backups though.

    • Glad to hear you're enjoying GrapheneOS.

      Xarcell Issues that I've had is I cannot get my banking apps to work. Although, not that big of a deal to me, as I can just login through the browser.

      You might be able to get them to work depending on why they're not working. Some apps can stop working due to not playing well with the project's hardening, but there are toggles to use for that, namely the exploit protection compatibility mode toggle.

      Xarcell I feel the furture is uncertain though. I'm being told by others that GrapheneOs is a honeypot.

      There will always be people trying to spread FUD about projects that work. We see it constantly with projects like GrapheneOS, Signal etc. I'm not going to waste everybody's time by reiterating "GrapheneOS is not a honeypot" because if it were and I was in on it, I wouldn't tell you. I will say that it's ridiculous for people to make claims like that without any kind of evidence, though, especially when existing documents prove that GrapheneOS is robust against exploitation in the real world.

      Xarcell Also, that Google is cracking down legally and making it harder to NOT use their products. I can't go into details about this because I don't understand it.

      Not quite the case. What you may have heard is abut the Play Integrity API which Google is pushing developers towards using. Apps that use the Play Integrity API won't work on alternative OSes. It's an issue that requires regulatory action, ideally, and we're working on it.

    • We've upgraded discuss.grapheneos.org to use an in-memory database (valkey) for caches and sessions instead of disk storage along with using it as a queue for running more jobs in the background. The background job queue greatly improves performance for posting in threads where people are subscribed to notifications since submitting the emails to mail.grapheneos.org is now handled by a background worker. Sending emails is also now more robust because we've configured it to retry if submitting emails to mail.grapheneos.org fails for any reason. You can see the changes here:

      https://github.com/GrapheneOS/discuss.grapheneos.org/compare/a53ae3b14ac5435530f07c3a6c95f8239eecdf6f...71365875383608c0f0a7b636d85965d0ef227bf7

      Since sending emails is now being handled in a much better way, we can consider adding the Follow Tags extension to allow users to receive notifications when new threads are posted with a tag:

      https://discuss.flarum.org/d/20525-friendsofflarum-follow-tags

      Among other things, this would allow receiving notifications including optionally an email when official posts are made with the Announcements tag.

    • StellarSecurity-martin Judging from the screenshots on your website for the "Stellar Phone", you're also selling devices with a fork of GrapheneOS for large sums of money.

      While that is fine, and permitted by the license, we would appreciate it if you didn't come here to promote your products. This is a community forum for the GrapheneOS community, and not an advertising board.

      This is not the first time that people from your company have ended up on the forum (which makes sense, since it seems like you're basing at least one of your products on GrapheneOS' work) to try and stir up interest in your product.

      This approach to marketing is not allowed in this community, and we would prefer it if it stopped.

      • Every single time there's a Vanadium or OS update, I think to myself: I can't believe how they manage to implement so much with such a small team of developers. And that in a FOSS project.

        Thank you for your tireless work!

        https://grapheneos.org/donate

        AFK - an update to 2024090400 is waiting for me :-)

        • So just to provide an update - this issue has been a nightmare. Multiple calls with Google about this issue (since the original blacklist came from Google FI), trying to escalate it. They give me NO EXPLANATION whatsoever about how it could possibly been stolen or somehow involved in fraud if I've used it successfully for 5 months. They won't tell me anything other than since I'm not the original owner, they can't do anything.

          Bottom line - they won't unblock it. So I can't use it anymore. I'm so pissed.

          Also, just so everyone knows - google (or any carrier, I guess) can blacklist your phone at any time. They don't have to and probably won't provide any explanation or excuse. You have no recourse.

          • It was discussed when the new setup wizard was being developed.
            Its something we considered but would require us to test for any cell network leaks that may occur as devices boot. There is some chance there may be a cell leak before the OS is fully booted, particularly when a device may not have had airplane mode activated on the previous boot (eg. before being flashed with GrapheneOS). The cellular baseband may start functioning before the OS is ready to tell it to switch off.

            This testing would be required for all supported devices. Should probably be a retest if there are any changes to the broadband firmware. We do not want to falsely suggest that transmissions are blocked.

            There is interest in doing this but we do not currently have the equipment or the time to do it.

            Also another thing worth considering - for many people what value is added with this?

            In most cases the device will be on stock before flashing GrapheneOS. After acquiring the stock device it has to be booted and in most cases it will not have airplane mode active. Also in most cases need to connect to network to enable OEM Unlocking. If you want to be super private/anonymous there are a lot of awkward maneuvers required to acquire the device and flash GrapheneOS. Having airplane on by default in GrapheneOS only provides a small assistance.

            If they acquire a device with GrapheneOS already flashed there could be benefits for people who intend to operate mainly, or always, with airplane mode on.

            Also for anyone who operates in airplane mode who wants to do a factory reset.

            In the mean time there is also the option to find a basement or somewhere out in nature where there is no cellular network coverage.

            • Experimental releases of GrapheneOS for the Pixel 9, Pixel 9 Pro and Pixel 9 Pro XL can already be installed with the web installer on our staging site:

              https://staging.grapheneos.org/install/web

              Can also use the CLI install guide with the releases listed on the staging site releases page.

              Our USB-C port control feature with both hardware-level and software-level enforcement hasn't been ported to them yet. They temporarily have our old USB peripherals toggle not depending on changes to device-specific USB HAL and USB-C kernel driver. We aim to get this done soon.

              These are production builds signed with the official keys with our standard update system. They'll get updated to future releases without needing to reinstall the OS.

              For now, please report issues to our testing chat room rather than our issue tracker: https://grapheneos.org/contact#community-chat.

              • Making any modification from AOSP takes time and effort. Can easily be unexpected consequences. Can often be far harder to make the changes to robustly achieve the desired outcome than initially apparent. Then have to maintain all changes going forward as AOSP itself changes. This last point is of critical importance as porting changes forward to new AOSP releases can delay security updates. What may be considered easy, reasonable and nice to have can easily have major unexpected negative impacts.

                • The purpose of Android's Phone permission is to give apps the ability to make and manage carrier-based calls. It also provides access to related information on the phone number and carrier. This information can also be obtained through the ability to place a call providing by the permission. This permission also isn't required by apps implementing their own calling system. Signal/Molly is a very widely used example of an app implementing non-carrier-based calls and doesn't require this. It's not required to properly avoid conflicts between calls and other apps playing audio. Android has a solid audio focus system and nearly every app integrates well into it. No permissions are required to properly implement this kind of user experience. Phone permission is for apps making/managing carrier-based calls, not VoIP calls. Some apps request it simply to autofill the user's phone number if they use it as their account identifier such as Signal and WhatsApp, but those apps almost always work without it particularly since they want to support using a different phone number than one assigned by a carrier to the device.

                  GrapheneOS provides Contact Scopes and Storage Scopes for working around privacy invasive apps unnecessarily insisting on access to the contacts and storage/media permissions. It would still be better if these apps simply used the standard Android contact picker, file picker and photo picker on their own, and that's something users already should have been expecting from apps. These scope features are a way of working around many apps insisting on having access they don't require. This is far less common with other permissions, so it hasn't been prioritized to the same extent. However, we plan to provide similar features for other permissions including the Phone and SMS permissions along with Camera, Microphone and others.

                  We have limited development resources and a lot of them need to be spent on maintaining what we already provide and porting to new Android releases. Since we continue to add more features and raise the bar for quality, we have increasingly reduced time for adding new features. We have to carefully choose what to prioritize and can only gradually implement a small fraction of the features we want to add. Adding alternatives to granting the Phone and SMS permissions for apps insisting on having them is not at the top of our priorities. One of our top priorities for privacy is providing control over which apps can read clipboard contents set by other apps when they focused, etc. Providing a per-app replacement for the standard mock location feature is also likely a higher priority than the Phone and SMS permissions.

                  If you don't want apps having access to this, then simply reject their request for it. If an app insists on having it and won't work without it, use a different app. There are lots of VoIP options without the unreasonable expectation that you share your carrier-based numbers with them. Apps insisting on having access to this permission are doing it for data mining and you don't have to tolerate it. You do not have to use those apps. Permission requests do not have to be granted. The whole point of having a permission system is the option to reject it. You do not need features like Storage Scopes and Contact Scopes to benefit from the permission model. Those features are nice to have to work around invasive apps and use them despite their intention to coerce you into giving access to your data. However, you already had the option to say no and avoid using apps insisting on saying yes before we provided these features. You currently have that option for permissions like Microphone and Phone prior to us adding similar features offering an alternative to granting them. It's up to you if you want to use a privacy invasive app demanding access it shouldn't need.

                  MySudo unnecessarily demands access to this permission, has an unnecessary hard dependency on Google Play and bans using an alternate OS for registering an account. Leave a 1 star review for their app on the Play Store explaining this is why and use a better option like jmp.chat. Send app developers a link to https://grapheneos.org/articles/attestation-compatibility-guide if they're banning using alternate operating systems to show them how they can permit GrapheneOS without losing any of what they're trying to do.

                  Storage Scopes and Contact Scopes didn't exist for most of the lifetime of GrapheneOS. No one should feel entitled to having more features like this from us covering more permissions. We implement what we can based on our available resources and our priorities. No one should be attacking the project and our team based on this. We're aware everyone has their own ideas on what should be prioritized, but most of the community seems quite happy with how we choose our priorities. We're currently working on 2-factor fingerprint unlock, per-app clipboard control, preventing other kinds of leaks with third party VPN apps, control over communication between apps and other features. Some people would prefer if we'd prioritize other things, but it's up to us and it's not open to negotiation. Contacting developers trying to influence our prioritization or publicly attacking our project members based on it is highly inappropriate and isn't going to be tolerated. We aren't going to provide a platform for it and it's not going to influence our priorities. It's taking resources away from development and is in fact delaying the implementation of features.