As a preview of what's going to be possible in the upcoming release of #GrapheneOS, here's a screenshot from a Pixel Tablet running desktop Chrome in a virtual machine with basic GPU acceleration via ANGLE on the host. The infrastructure is a lot more robust than the Terminal app:

Our next release also enables running the Terminal app in secondary users. There's still the temporary limitation of only being able to use a single VM on the device at a time because the dedicated internal network interface it uses for the Terminal app isn't split up at all yet.

GUI VM support will have 2 main use cases:

1) Running a specific app or an entire profile via GrapheneOS virtual machines seamlessly integrated into the OS.

2) Running Windows or desktop Linux applications with desktop mode + USB-C DisplayPort alt mode on the Pixel 8 and later.

This virtual machine management app (Terminal) will be handling the 2nd case. It's essentially already available in a very primitive way. We expect this to become much more usable and robust entirely from the upstream Android work on the virtual machine and desktop mode features.

Reply to this note

Please Login to reply.

Discussion

Speaking of the termianl app. How do you type in it? When I type in it and hit enter nothing happens. Only a new line appears. It looks like there is something appearing over the terminal and I type in it but that doesn't send the prompt to the terminal

Are you using a different keyboard app? If so, which?

Does the standard OS keyboard work? Aware it might be a bug with Openboard itself.

Florisboard had a similar bug they fixed, see:

https://github.com/florisboard/florisboard/issues/2806

Is it possible for the operating system to provide IMEI spoofing for the mobile network? And at the system level, apart from MAC spoofing in the case of Wi-Fi, are other identifying signals hidden from applications?

No and yes. It can't be done directly through the OS and requires convoluted processes such as debug features and tampering with non-persistent state but it provides little overall value that avoids the solution of dealing with a hostile network like it which is not using that network at all. High risk users should just stick to WiFi and not use a SIM. Airplane mode prevents tracking from cellular by disabling the cellular radio. Such identifers usually aren't visible to apps in the OS unless they have READ_PRIVILEGED_PHONE_STATE, so system apps. The default SMS app is a special case that's given access to the IMEI, which is normally the GrapheneOS fork of the AOSP Messaging app unless users explicitly change it to another app at their own discretion.

We had been asked about it and clarified back when old Snapdragon Pixels could do it. Exynos Pixels could, but it's a no at this stage and had been for a long time It's nothing like WiFi MAC address randomisation.

Changing IMEI wouldn't prevent tracking via cellular since there are other identifiers specific to radios and also extensive fingerprinting possibilities. Choosing a random IMEI while everything else being the same as before would make you almost entirely unique as a starting point. It will only hide one commonly used ID rather than making the device not uniquely identifiable.

Carriers often detect device model via IMEI and multiple other ways as part of their standard operating procedure. They change how things work based on the detected capabilities but also hard-wired quirks for device models, etc. Devices send a lot of info on capabilities or features they support. The general type of radio/device is extremely obvious to the network since a bunch of capabilities, configuration, etc. vary and are directly reported to the network. We try to match stock Pixel OS configuration but it's clear it's a Pixel based on network behavior and not just an arbitrary number.

Identifying yourself to the network is what a SIM implements so you inherently get identified as a specific subscriber based on that too. You could change SIMs often but that's costly and doesn't solve the above problem. The radio is also supposed to send a unique identifier and will often send other identifiers, including but not limited to EID when using eSIM.

Since IMEI is typically configurable by OEMs building the phone and often has a debug feature for changing it, it can end up being possible to change it. It's a mistake and typically comes along with vulnerabilities. Reporting upstream could come with rewards but we're not looking into it. If upstream patches it, its no good for us then...

GrapheneOS only generally reports to Google if the vulnerability is major, exploited in the wild and/or their input to patch is required to protect the devices we support. Last major example of when we did this was for vulnerabilities exploited by a forensics firm selling a password brute force exclusively for the stock OS. While not affecting GrapheneOS the response and firmware changes helped us greatly in implementing duress password.

I also haven't counted RF fingerprinting (affects other radios too) or tracking miscellaneous artefacts like mobile data web traffic (conditional) or direct connection to the provider's IPsec tunnel for WiFi. RF fingerprinting two of the same mobile devices is a common academic project and you can check them out online.

Uninformed users would be fed false hope and act in ways they shouldn't with the feature which could endanger them. There is no legal restriction holding the project back, it's the above reasons.

We plan to provide more configuration for controlling Wi-Fi calling/texting where users can entirely toggle off the IPsec tunnel it uses while still using the SIM. It's not one of our top priorities since disabling the SIM is already available as a standard option and does that.

Which messaging apps do you recommend? Session, Matrix, Briar?

If you have the choice to use anything then SimpleX is gold standard. Signal is excellent if the phone number requirement isn't a problem for you. We heavily recommend https://molly.im/ for Signal users. Provides many privacy and security features Signal misses.

Session is good but disappointed with the lack of PFS. We disagree with their stance that it is not important. Exploiting someone's device gives access to their current encryption keys but if there is PFS then it doesn't imply recovering all past messages. It's great that they're honest though.

Thanks for the clarifications.

Using a messaging app linked to a phone number is never a good idea.

Yes. I see that another user also uses floris board and has issues that will allegedly be fixed in the nex update.

Before that comes I tried using the default keyboard. Everything works fine unless I try to go to edit an old prompt (up arrow and then backspace). It doesn't delete the old letters I have typed. It only allows me to type and delete new letters

Mobile is going towards desktop (with Andriod VMs) and desktop is headed towards mobile (with Phosh and Plasma).

nostr:nevent1qqsrl9npdmj50snnk8ue9m285n6rkjwnu269sasuw0pk4yashmafwtqpzdmhxue69uhhwmm59e6hg7r09ehkuef0qgstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgsrqsqqqqqpul8yz6

Awesome!!!

Android 16 QPR1 is a big deal for #GrapheneOS.

All of the major desktop mode features will be available in this version. A lot of it is available as developer options for an early preview on GrapheneOS but will be fully production ready by the time we have A16 QPR1.

This will allow a Desktop experience for users. Modern Pixels can then dock their device and use a mouse and keyboard to navigate the UI.

A functional desktop mode is huge, but it is a stepping stone towards a far greater feature target for us: A Desktop OS VM manager.

One OS feature (the Linux terminal app) already provides a Linux command line using a Debian virtual machine. Ideally, we would want to move away from a non-hardened desktop distribution like Debian, which the upstream uses, and have something an ARM build of secureblue, securecore or even a gold target for Windows 11 ARM for superior app compatibility.

Here you can see desktop operating system apps within a freeform window over the standard GrapheneOS applications. There are many unique setups and software choices if we can further develop this:

nostr:nevent1qqsxfr077j8sv4qgd3u43z0pqae52kxldseu3zzc4z5sy8f20ujq8pcppemhxue69uhkummn9ekx7mp0qgstnr0dfn4w5grepk7t8sc5qp5jqzwnf3lejf7zs6p44xdhfqd9cgsrqsqqqqqptkgq9j

nostr:nevent1qqsrl9npdmj50snnk8ue9m285n6rkjwnu269sasuw0pk4yashmafwtqpzpmhxue69uhkummnw3ezumt0d5hsyg9e3hk5e6h2ypusm09ncv2qq6fqp8f5clueylpgdq66nxm5sxjuygpsgqqqqqqst0wkpg

Gaining desktop functionality and including being able to run GUI Windows and desktop Linux applications via hardware accelerated virtualization will then lead to further innovative features, including:

1) Running a specific app or an entire profile via GrapheneOS virtual machines seamlessly integrated into the OS.

2) Running Windows or desktop Linux applications with desktop mode + USB-C DisplayPort alt mode on the Pixel 8 and later.

3) Create an amnesiac virtualized environment nested within the OS user that could be plausibly deniable.

There are also a few massive targets that would take a lot of work and wouldn't be seen yet, but worth considering. For example, Android provides Chromium's layer-1 sandbox as an OS feature available to be used by any app via isolatedProcess. It would be fantastic to move this to virtualization using microdroid. It'd be a large project, but have a very high impact for browsers, like per-site virtual machine instances. That would provide security above Tor Browser and comparable to Microsoft Edge's deprecated Application Guard feature that ran Edge in an isolated virtual machine but at a more seamless and useable scale.

Since isolatedProcess is an OS API, it'd benefit all Chromium-based browsers and other apps using it rather than being specific to Vanadium. That'd be a difficult project but we can consider it as a future large feature on the same scale as our sandboxed Google Play feature. This would make many apps get a large security boost.

This is incredible, I am so happy to read this