- This depends what you mean by 'issues with NFC'. My understanding is that Google require an OS that is blessed by them for contactless payments in Google Wallet to work. That restriction applies to all alternative operating systems that aren't Google certified stock Android.
The OEM partnership would not change that.
In non-NA regions there may be more options for mobile contactless payments using apps that are not Google Wallet/Pay. So it also depends where in the world you are.
- Reducing waste is very important, but I think this is something you need to take up with the Android OEMs. GrapheneOS can't really do anything about the fact that Android OEMs stop supporting the device and allow vulnerabilities to go unaddressed. For context in this situation, GrapheneOS is also trying to provide a best-in-class privacy/security experience for people. There were other projects that are/were dedicated to supporting abandoned hardware.
A connected world full of devices with excessively vulnerable hardware & software is also something GrapheneOS are desperate to avoid.
- I don't think that is a consideration for the project. Their OEM partnership also includes supporting a current generation Snapdragon SoC which seems to feature an integrated modem.
>A component being on a separate chip is orthogonal to whether it's isolated. In order to be isolated, the drivers need to treat it as untrusted. If it has DMA access, that needs to be contained via IOMMU and the driver needs to treat the shared memory as untrusted, as it would do with data received another way.
- >Think mesh networking, resilient ad-hoc application clustering, non-Internet P2P, like Freifunk but everywhere.
(if dumbed down) What's are the gaps in features and functionality between what you're describing and what might be achievable today (given enough software glue) with an SDR transceiver and something like Reticulum [1] on an Android?
- On bundling apps in general: https://grapheneos.org/faq#bundled-apps. For the calendar app particularly I think they assessed that the AOSP Calendar app was beyond saving (left to rot by AOSP/Google). I cannot remember if they still have plans to develop a calendar app.
I believe you're right that the idea is for people to download the apps they want (from wherever they choose). GrapheneOS has a complicated history with F-Droid though. Unfortunately, unless their approach was different in a lot of significant ways, it is unlikely GrapheneOS will include F-Droid in their Apps app repository.
- Because the technicalities of accomplishing something like that are quite complicated from what I understand. If an app has the necessary permissions and network access, almost anything you try to stop it from transmitting data about the platform and data about its usage is futile.
You're firing a starting pistol for a race to the bottom where app developers just end up sending all that information to their own first-party servers instead to be shared with whoever they wanted to anyway.
GrapheneOS absolutely tries to deal with the root of the issue, by giving the user control over sensors and network permissions that return fake/simulated data to keep the app running while denying access to data in the first place. Or contact scopes and storage scopes which restrict access to contact information or storage locations in the first place. As you can imagine, more are planned like location scopes, app communication scopes etc.
- They are already stretched a bit in terms of doing what they are comfortable and best at which is implementing privacy and security enhancements in AOSP and maintaining them across AOSP changes and upgrades (or getting them upstreamed if palatable to Google/AOSP).
They have made major usability improvements like eSIM support and network-based location. They have also been forced to work on things due to unrelenting popular demand like Android Auto support, sandboxed-google-play and the compatibility layer and Google Messages & RCS support.. to the cost of working on other security/privacy enhancements. At the end of the day, this is more a question of resources available.
I think the task of usability, features and overall experience is better delegated to another group of developers who might then contribute those improvements to GrapheneOS as well in an ideal world.
- GrapheneOS have mentioned in the past that the Qualcomm baseband processors compare well to competition in terms of security and isolation support on their respective SoCs. There may be other aspects they need to catch up to Pixels on regarding security though (like the secure element, open-source TEE etc.).
- As far as I'm aware, their flagship Xperia phones do support bootloader re-locking [1]. The problem is they haven't fulfilled GrapheneOS's other requirements: https://grapheneos.org/faq#future-devices
[1] https://github.com/chenxiaolong/avbroot/issues/299#issue-232...
- The base operating system is quite far behind on app compatibility, privacy and "deGoogling" in comparison to GrapheneOS https://eylenburg.github.io/android_comparison.htm.
- It's hopeful news. GrapheneOS have had access to security patches as part of their agreement with an OEM partner already, so I assume these discussions/plans have been with the same partner. They are also hopeful of getting full access to AOSP releases which would greatly alleviate the pain Google have put custom OS developers through recently.
I am still very surprised that any OEM is willing to commit to monthly security updates and OS upgrades for a minimum of possibly five years. I think it would be a good thing for GrapheneOS to have more than one partnership in future for the Android ecosystem as a whole.
- All mobile computing and connectivity hardware is unverifiable in reality and by design. It's not some property exclusive to Google Pixels.
Their business model also does not involve selling data afaik, it's selling access to their adspaces [1] all over the internet including the ability to target people (based on information Google jealously hoard). They stand to lose just as much as most other OEMs if they did suspicious things in hardware just like Apple, Samsung etc.
If you're serious about security you will avoid using OEMs that have unfortunate patch gaps which leave device owners at the mercy to *known vulnerabilities* [1][2][3][4] as well as unknown threats which is fortunately one of GrapheneOS's many reasonable device support requirements.
[1] https://blog.google/products/ads-commerce/more-effective-med...
[2] https://srlabs.de/blog/android-patch-gap
[3] https://srlabs.de/blog/android-patch-gap-2020
[4] https://www.android-device-security.org/talks/
[5] https://techcommunity.microsoft.com/blog/vulnerability-manag...
- >It would be "more secure" to have a per-application firewall that blocks particular apps from outbound traffic over certain networks or to certain destinations. This prevents a malicious app from consuming roaming data.
LineageOS can have that, at the owner's preference. Graphene explicitly forbids it.
Not sure what is meant by forbidding it? GrapheneOS provides per-app network access control via a user-controllable Network permission which is not implemented in AOSP or LineageOS afaik. They do not forbid using local firewall/filtering apps like RethinkDNS (to enforce mobile data only or Wi-Fi only iirc) and InviZible. They only warn that 'blocks particular apps from outbound traffic ..to certain destinations' cannot be enforced once an app has network access which makes sense to me.
>It would be "more secure" to allow backing up apps and all their data. This would mitigate the damage of ransomware. Graphene, again, forbids it (following google guidelines prioritizing the wishes of an app's developer over the device owner).
Contact scopes, storage scopes, the sensors permission and the network permission are examples that show precisely the opposite (GrapheneOS prioritises the device owner over the application developers). To my understanding, the backup app built-in to GrapheneOS even 'simulates' a device-to-device transfer mode to get around apps not being comfortable with data being exfiltrated to Google Drive. That being said, I understand they have plans to completely revamp the backup experience once they have the resources to do so.
- There is Destiny https://leastauthority.com/community-matters/destiny/. Although there hasn't been much activity lately.
- Can anyone comment on where this puts Signal now in relation to iMessage with PQ3[1]? As an aside, can anyone comment on earlier (fast/rushed/sound?) attempts at quantum-resistant encrypted messaging in Cyph[2] and Simplex[3] in comparison?
[1] https://security.apple.com/blog/imessage-pq3/ [2] https://www.cyph.com/castle [3] https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum...
- You're confusing the founding of the Signal Foundation with the release of Signal. Textsecure/Redphone which Signal came from existed in some part around 2010 or thereafter. Their merging and re-release as an all-in-one IP-based encryption app also came before WhatsApp was sold to Facebook.
- Using multiple profiles is completely optional.
It is completely the user's choice to put sandboxed google play in a private space or secondary user profile. It is completely the user's choice to put sandboxed google play services in the owner profile and not use multiple profiles at all. It is completely the user's choice to source apps from outside Google Play.
- >Nevertheless GOS on Librem 5 or Pinephone would be a nice idea, except the GOS developers are against that: https://www.hackerneue.com/item?id=45101400
GrapheneOS are against using their development resources on a platform that is drastically, significantly worse than the hardware platform they already have, which is quite fair. It is not about Pine64 or Purism's products specifically. They would not be against them if they met 95% of the requirements detailed in https://grapheneos.org/faq#future-devices. It would more sense to explain which of those requirements you think are unreasonable.
- >I just wanted to get a statement from them concerning what's a reasonable goal and what isn't
Please contact the OEMs/manufacturers and ask them why they cannot support reasonable requirements like: minimum five years of full (OS, firmwared, security patches etc.) device support code, hardware accelerated virtualisation, isolated radios (Wi-Fi/Cellular/Bluetooth etc.), a decent secure element implementation and support for throttling, proper Wi-Fi privacy support etc. (https://grapheneos.org/faq#future-devices)
You are clearly passionate about this, and you are not alone. But I have never understood why people expect GrapheneOS to compromise their goals and values, rather than wanting others to improve to meet them. GrapheneOS is completely free.
>to break from their life-threatening dependence on Google?
They have had talks with at least one OEM in the years past before the recent round of communications, trying to secure support for GrapheneOS on non-Pixel hardware. They have had builds in the past for Samsung hardware and development boards to explore alternative platforms and interest in minimal blob platforms which they had to abandon because those were not suitable for the project long term.
They have always been completely willing to support non-Pixel devices that meet their requirements, but none have been available or validated so far.
It's not appropriate at all to say they have no interest in breaking their dependence on Google Pixels. Personally, I think it's bizarre that numerous companies like Fairphone, Punkt and OSOM can come and go without ever seriously attempting to meet the reasonable requirements set by GrapheneOS and offer alternative options.
>to allow more people benefit from a better security, not just those who can afford a Pixel?
GrapheneOS is not a hardware manufacturer with the benefits of economies of scale. If they could magically create an affordable device that met their standards they would do it...
As you already understand, GrapheneOS is a project with limited resources. They put those resources to use in significantly improving the privacy/security for an operating system (OS) that guards regular people's most personal data and device. Any device they support that lowers that standard means much much more time spent on device support and much less time on important work that improves on what you can have now (GrapheneOS + Pixel 8 and above).
GrapheneOS is also open source, so nothing stops you or I from adapting parts of it for a less suitable platform and releasing that for others to use. DivestOS for example used code and ideas from GrapheneOS in their own project, and GrapheneOS were always supportive of the project and even offered the founding developer a role in the development team after they stopped working on DivestOS.
>Where did you find that?
As I've said above, it is something they experimented with in the past. But the reality is that they are intimately familiar with some past and present projects around that area including Raptor Engineering stuff, SiFive, Betrusted, coreboot, OpenTitan, Tropic Square etc. GrapheneOS has always been deeply interested in quality open source software and open hardware, unfortunately they just never had opportunities to support those things while improving on the progress they have already made.
>I'm not sure what you're talking about but not GrapheneOS, which depends on a bunch of proprietary drivers and firmware.
I did not say Pixels are a blob-free platform. I said GrapheneOS have expressed interest in open source kernel and OS projects even outside of GrapheneOS itself.
>Like those on Librem 5? Or do you mean some other device? I'm not aware of any other device with usable kill switches.
No, I don't mean usability, I mean physical privacy switches with a proper threat model. GrapheneOS have stated they would be 100% interested in usable privacy switches for specific goals like stopping audio recording or location detection but it is a lower priority than other ideas they have to improve privacy/security on the device as a whole.
- Sorry, but it is very difficult to understand what you mean and what you want from GrapheneOS. GrapheneOS is a FOSS project and they have committed to that being the case for the forseeable future.
They have expressed interest in open hardware, well-designed open source secure elements, open source blob-free firmware with proper signature verification, open source greenfield kernel and OS projects, hardware kill switches with a proper threat model etc.
Why should anyone expect them to throw away everything they have accomplished to start several steps backward on platforms that don't achieve any of these things?
- > Sure it's cool you can turn off google play
Google Play and associated services are not bundled with GrapheneOS, they are completely optional.
> I found the profile feature to be only slightly more convenient than having two physical devices.
User Profiles is a feature inherited from AOSP. This is what AOSP says about the feature: "Android supports multiple users on a single Android device by separating user accounts and app data. For instance, parents might allow their children to use the family tablet, a family can share an automobile, or a critical response team might share a mobile device for on-call duty."
In the community it is popular to use multiple profiles to compartmentalise personas or group apps with hard google service dependencies together, but this is all completely optional. GrapheneOS as a project gently suggest keeping everything in the same initial owner profile and then moving things around to suit your comfort level.
> It's my device, not google's, and certainly not Graphene's.
You've clearly endured a lot of frustration when using the OS. Are there any specific things you remember trying to do that were blocked or prevented by GrapheneOS? It's not a project with unlimited resources, but actionable information about limitations and bugs can potentially be addressed if known.
What team are you talking about? JMP/Cheogram? This is the first I've heard of this.