ysnp

Can Android OEMs, bundling Google Mobile Services for Android certification, choose different trust roots for verification?

The correct thing to complain about is requiring developer mode for unverified installs, which doesn't seem necessary

I had assumed the friction was to dissuade developers from not going through ADV. Isn't it partly for making malware distribution more traceable and campaigns easier to halt on GMS/certified Android systems?

Can you add CopperheadOS data 2014-2018 and AndroidHardening Project from 2018-2019?

For what it's worth, strcat is the GrapheneOS founder so they will have a keen insight into current plans.

Any promising mesh networks, radio networks or routing protocols worth looking into?

It may be worth noting that GrapheneOS in most cases to date are not the initiators for conversations around extra device support. They do not control which mobile divisions and engineering teams can come to them and back genuine interest with the resources needed to reach an acceptable privacy/security standard for support.

The question is really why are Motorola the only ones that have gone that extra mile so far and what does it say about the rest of the Android OEMs (including Fairphone, which unlike most is actually a younger project than GrapheneOS).

The details of the partnership are mostly disclosed in the joint announcements but GrapheneOS has no say or influence on Motorola's stock Android image and policy.

The main objective of the partnership is to do what you described in the former case, get Motorola up to a standard where GraphenOS could support the phone. They could not previously take a Motorola phone and build GrapheneOS for it because of numerous basic requirements they did not yet meet. I can guess that GrapheneOS only really condone the efforts Motorola will put in to meet their support requirements as a platform.

Motorola also gets to incorporate a subset of GrapheneOS's features and improvements as enterprise targeted Motorola features. GrapheneOS do not have any direct influence over the apps and policies for the stock GMS Android image Motorola ship with their phones. Motorola have no significant say in what GrapheneOS does with their OS. GrapheneOS can assist Motorola in hardening efforts at the OS and firmware layer etc.

I've not seen someone refer to a portion of GrapheneOS's mitigations as superficial and meaningless before. What might an OS with significant improvements to usable attack surface reduction and exploit mitigations look like to you? What sort of things (given a team of less than a dozen contending with OS updates, upgrades and device support) would you have liked to see implemented?

They have commented elsewhere that any inclusion/exclusion criteria (if at all) should be transparent and collaboratively decided rather than arbitrary, monopolised or ineffectual/deceptive. They mention several times that people should not be excluded from web services for browser/OS choice.

The requirements are not particularly stringent. It is more an embarrassing show from the rest of the Android OEMs that they don't meet basic standards like timely security updates and a decent support period.

From what I've read I understand it is more like:

/e/OS (recipient of EU funding) and iodéOS are European projects that have not been singled out by the French government in smearing despite them having the similar self-professed goals to GrapheneOS. That they had any influence at all on the French government directly is speculated but not asserted.

CalyxOS/Techlore are blamed for being complicit in escalating the animosity and furore around what were initially low-key fallouts/disagreements. This led to GrapheneOS/Micay escalating to defend themselves which unchecked fuelled a spiral of influencer content, vile spamming of CSAM in GrapheneOS rooms (I can personally attest these were some of the biggest on Matrix at the time and led to the team giving up on Matrix moderation and self-protection capabilities), intense public speculation/accusations about Micay's character/mental health etc. which eventually resulted in the swatting attempts.

F-Droid project members have publicly aired their dislike of Daniel as a result of direct or indirect disagreements and did have a software quirk that caused an issue for GrapheneOS/possibly other custom OSes' users due to their added permission (which the two parties again disagreed on). Conspires is loaded wording.

But I do not think it is productive for me to dredge up posts and potentially cause more misunderstandings as a complete outsider for something that is directly affecting someone's life like this. They (Micay/GrapheneOS) have posted detailed contextual snippets and information about what has happened so please contact them directly for reference to the original posts and discuss if you really wish to find out more.

There are a lot of judgemental comments here criticising Daniel's character, responses and handling of what was likely a very trying and stressful period in their life.

Barely any comments about the linked thread which is about Wired publishing an article that was extremely poorly researched after having misled GrapheneOS about the intention and content of what would be published. This seems like the sort of thing that should earn a disclaimer on future Wired articles as worthless and get them removed from RSS feeds/have subscriptions cancelled. Complete lack of integrity and respect for standards. Why did they not interview anyone else involved in the project or around at the time?

Phantom Secure is directly named as one of the parties Donaldson was dealing with, with others being suspected:

Donaldson tried to make a deal with Phantom Secure, which ultimately didnt work out. Micay suspected other counterparties were linked to organized crime, but we cannot confirm those identities or ties on short notice. Donaldson began pursuing such deals before Micay left and continued afterward.

https://discuss.grapheneos.org/d/34369-original-grapheneos-r...

It may be worth checking Motorola's OLED models in person (for example the Razr Fold, Razr Ultra and Signature) so see if their Flicker Prevention mode helps. I don't think any IPS models are likely to be supported in the first wave/generation of supported devices in 2027.

Having GrapheneOS preinstalled is an option they may discuss with Motorola. It is not the current plan. The current plan is that Motorola release their devices as normal, but some of the flagship devices in 2027 will support manual installation of GrapheneOS.

GrapheneOS will support future Morotola phones that meet a subset of their requirements, rather than existing phones. Less likely to be budget lines for now.

DNSSEC is one of very few topics where voices I respect on security seem completely opposed (WebPKI depends on DNS vs. DNS security does not matter). Is there any literature that demonstrates deep understanding of both arguments? Why are they (DNSSEC + WebPKI) never considered complimentary?

Is the case that captures all RF still planned for the productised Baochip?

Can anyone from Motorola confirm that the form submission and time delay requirements will be removed?

Hi daneel, what would you like GrapheneOS to do while you develop your own formally verified, open hardware, open source firmware/OS baseband processor they can use? Sit on their hands doing nothing or making the best of the least worst options currently available?

Since ~2023 all Motorola phones with Snapdragon SoCs (the ones most likely to support MTE as needed by GrapheneOS first) have been larger or equal to 6.5" screens.

The Google Pixel has first-class support for alternate OSes (not custom firmware like a Chromebook). The OEM has to go out of their way to support avb_custom_key as mentioned in https://android.googlesource.com/platform/external/avb/+/mas... and I believe the GrapheneOS founder strcat was heavily involved in helping Google design this feature and flow for Android Verified Boot.

are by incompetent/lazy/pressured devs who just throw in some library and don't even care that it leaks data to Google

Even if I agreed with this statement, I don't understand why it is better to put limited/precious resources something the app developers can easily circumvent, praying they never stop being incompetent/lazy/pressured and tell device owners it is an important privacy feature? Instead of waiting for the apps to become actively hostile why not just feed them fake data in the first place? Like the scoped access permissions do?

If you really want to do this, you (and any GrapheneOS user) can do it today with mitmproxy and RethinkDNS but I think it is perfectly OK users choose their (privacy-invasive) apps and choose how to mitigate annoyances like that themselves. Otherwise they need to complain to the app developers and app stores.

That's why I said that the main focus of GOS is security, not privacy. If they cared about privacy primarily, they would actively support microG and NetGuard, or at least similar solutions.

That feels more like you are framing your opinion as a fact. To me it is not so obvious.

When I think of privacy, I think of Privacy Enhancing Technologies (https://petsymposium.org/). I also think of things like:

* separate network namespaces for profiles (https://github.com/GrapheneOS/os-issue-tracker/issues/5225#i...) and/or a GrapheneOS-Gateway equivalent to https://www.whonix.org/wiki/Whonix-Gateway, * built-in OS support for chaining VPNs together or splitting different traffic over different privacy-enhanced networks like in RethinkDNS, * adversarial pressure wave + ultrasonic noise to thwart smart listening devices https://youtu.be/xMYm2d9bmEA?t=1305, * virtualisation as a sandboxing and anti-fingerprinting primitive (https://discuss.grapheneos.org/d/5775-device-fingerprinting-...), * control over what apps can communicate with each other https://github.com/GrapheneOS/os-issue-tracker/issues/2197 * location scopes/phone state scopes etc that are already planned.

etc.

The partnership is for future devices, rather than existing devices.

They said they have access to security previews/patches but I have missed that they have full AOSP access now? Do you have a link?

I am not a project member so I cannot speak for GrapheneOS, but maybe I can help clear up some misunderstandings.

insistence on not supporting MicroG leads to poor UX,

The problem they are trying to solve is apps not working without the presence of Google Mobile Services or Google Play. They don't want to compromise by having a component with high privileges integrated in their image that involves security issues like signature spoofing.

MicroG will send less data to Google partly because it is simply an incomplete implementation of the features offered by GMS (sanboxed-google-play appp compatibility is quite a bit higher), partly because the access is more granular or there are choices offered for services like location (GrapheneOS provides non-Google location services and community support on only installing and enabling the parts you need for specific app features to work). UX is not adversely affected, but if you want to use a privileged app bypassing security checks and sending data to Google anyway then you have the freedom to compile microG with it integrated if you would like.

They also seem to be very opinionated about (not) using a firewall for privacy, like NetGuard, instead recommending some weird alternatives like DNS firewalls

GrapheneOS tries to implement or end encourage sustainable approaches to privacy and security, and this partially means approaches that don't break if the adversary knows what you are doing.

Egress/outbound traffic filtering is fundamentally unworkable. Apps do not have to connect to known privacy a invasive third party domains to violate your privacy or expose your data to extra parties, they can simply send anything they want to their own servers and do anything they like with the data. From my understanding this is why GrapheneOS do not want to encourage the approach of blocking apps from connecting to certain domains/addresses.

Instead they tackle the problem at its source by providing a direct AND indirect network access toggle which cuts off an apps access to the outernet without letting the app know (pretends the network is down). This makes it non trivial for apps to exfiltrate data and as a side effect can provide benefits like data conservation (for capped plans).

instead recommending some weird alternatives like DNS firewalls.

DNS based solutions are offered (not promoted) if you want more control over your DNS query resolvers or you want to improve your quality of experience by blocking advertisements and malvertising domains.

they (heavily) prioritize security over privacy.

Can you point out another OS project with real privacy features like a network permission, sensors data access permission, contact access scopes, storage access scopes, per connection MAC randomisation and so on? https://eylenburg.github.io/android_comparison.htm They have even more plans for privacy like location scopes, anti-fingerprinting for Vanadium browser and maybe AnonymisedDNSCrypt/Oblivious DNS and probably more they haven't mentioned. If you suggest some more on their issue tracker they may get back to it when they have the resources.

It took a while but congrats to Daniel Micay and GrapheneOS. Hopefully it is the first of a few (looking at you HMD, Sony, Samsung, Nothing).

Will Motorola allowlist/whitelist GrapheneOS's avb key for green boot state? Does that have any implications for Play Integrity?

Do GrapheneOS finally get AOSP full partner access as a result of this? Will the Motorola device have USB port control, OS virtualisation and GPU virtualisation? Will it have a better secure face unlock story than Pixel 5 - 10?

Will the gushing fans and secret admirers finally stop flocking to me because I switched from Pixel-GrapheneOS to Motorola-GrapheneOS?

some odd ideas about trust and PKIs.

Can you explain what you mean?

I've had people tell me that nobody should use anything but GrapheneOS and stop supporting alternatives to throw all support into that because the others are "less secure"

Without having an kind of authoritative knowledge or experience on the topic, those people are wrong and please ignore them. The argument has generally been that if you are specifically after privacy and security in your personal device then GrapheneOS or post-MIE iOS will be your most sensible choices. You CAN choose devices for other reasons, as has always been your prerogative.

The question of whether to support 'alternatives' is fraught. It used to be that there were two other OS projects that happened to be collaborating and adopting features from GrapheneOS and that would have been reasonable. The main argument (from GrapheneOS) in that case has been for people to please invest in alternatives with approaches to privacy and security that stand up to threat-model driven design and real world attacker/defender experience.

GrapheneOS was never meant to be alone in pushing for things like hardened secure element-based protection of secrets and side-channel resistant rate-limiting of unlock attempts, memory tagging/hardened memory allocators/secure application spawning/dynamic code loading control, anti-persistence hardening, prompt security patching, network/sensor permissions, contact/storage scopes, PIN scrambling, auto reboot etc. Unfortunately very few other projects that I am aware of are looking into doing things like this to give the device owner control and mastery over their data.

and now that GrapheneOS isn't for everyone and anyone -- the majority of people -- without a specific narrow selection of hardware should get lost.

GrapheneOS tries to make most of their hardening transparent and non-intrusive by default. They also spend a lot of time and resources working on usability (sandboxed-Google-play and the web installer) and now accessibility (upcoming text-to-speech implementation?). The idea is that if you have a Pixel and choose to use GrapheneOS then it should be as easy to use as they can manage without compromising their efforts improving privacy/security. In that sense, GrapheneOS is for anyone and not just security nerds or tinfoil hats.

The exclusivity to Pixels is an unfortunate consequence of being the only platform equipped to provide what they need to achieve their goals. If multiple devices supported what they needed from the beginning, they would have probably supported three or four models from different brands as targets (for example you could imagine a couple Pixel lines + one Samsung line (Europe/North America/Oceania), one Xiaomi line (East Asia/South East Asia/South Asia/South America), one Tecno line (Africa). This is speculation on my part, but the main point is that the Android OEMs have been seriously slacking on basic privacy/security leading to this kind of situation.

We need the people who buy $100 phones to have the ability to put a better OS on them than the burning mudslide that comes with them, is all I'm saying.

No disagreement here. This relies on AOSP adopting improvements and also on Google tightening their certification (for Play Store) requirements to include stronger privacy and security guarantees.

The point of GrapheneOS isn't improving a generic device's security, it's about setting an example for a highly private and secure OS. It's a FOSS project, so nothing stops a committed individual or community from using other device targets, but the main project chooses specifically to use their smaller resources to pursue excellence rather than mediocrity.

Not everyone needs kernel hardening, or always E2EE (as with signal).

If application processors and hardware crypto accelerators are good enough to make this invisible to the end user, then why not? Why not have everyone be on hardened kernels by default and let them opt-in to insecure ones instead of the other way around?