Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

grapheneos.org

Post reply on HN
Print view View original

71–80 of 186 posts

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#71

Post by neilv »

Dunedan wrote: post #55
neilv wrote: post #36

Earlier quoted context omitted.

PostmarketOS seems the most promising effort for a truly open and affordable handheld OS with mainline kernel and other good practices. And there's also a useful incremental path for evolution, that starts with a familiar GNU/Linux and moves gradually towards handheld tweaks (UI, power, devices, apps). It's important to be upfront that PostmarketOS is not yet viable as a daily driver, or people will feel they wasted…

PostmarketOS reminds me a lot about the approach Openmoko ( https://en.wikipedia.org/wiki/Openmoko ) took way back over a decade ago, except that they did have to build the hardware as well.

There've been several such prominent open source handheld projects in the last 20 years. PostmarketOS seems the most viable, IMHO, because it emphasizes the old Linux (and GNU) principles of getting working on lots of available hardware, with true open source, mainlined. (Separately, it also potentially builds on a wealth of GNU/Linux stuff that there's no good reason shouldn't have a lot of commonality between desktop and handheld.)

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#72

Post by bubblethink »

ThinkBeat wrote: post #38

It supports the Google Pixel range of phones only so far. So in order to get that is more secure and more independent from Google I have to buy a Google phone?

>So in order to get that is more secure and more independent from Google I have to buy a Google phone?

Yes, people find it ironic, but that's how it is. Google's hardware is always better than competition for security: not just in phones, but also look at chromebooks. However, not running proprietary google software is left as an exercise for the reader.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#73

Post by groovybits »

KirinDave wrote: post #70
groovybits wrote: post #67

Earlier quoted context omitted.

I believe there is a general lack of awareness of what AOSP is without Google services and add-ons on top of it. In some facets, AOSP is not a complete and working OS as is. In particular, I have personally had many issues with GPS location for the past fews years. Out-of-the-box, GPS simply does not work without additional non-free software to help it out. Additionally, many (that is, 95%) of all Android apps that y…

In general, until we have open source handset hardware to work with, all fine-tuned sensors and clock hardware support will be bad. This is a problem Linux had for a long time, and it took a ton of effort to partially solve the problem. It seems a bit unfair to blame AOSP for not having drivers for specific hardware, that's not it's function. The big contribution of Purism phones is that more open hardware. After tha…

I agree, hardware is a primary concern.

I am not meaning to paint those who work on AOSP or third-party ROMs in a bad light. The work they do is terrific and great for the community. I also do not mean to dismiss any of the fantastic work that Graphene brings to the Android community.

I am simply stating that the biggest difference between Librem and Android is that there are more hurdles to jump through to provide a completely usable and free AOSP phone to an end-user in 2019. Android has been made to host a Google ecosystem, where the Librem 5 is being created to host an open ecosystem.

It sounds like the Purism team identified this issue ahead of time and decided to provide that open hardeware platform for us.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#74

Post by andrepd »

groovybits wrote: post #67
opencl wrote: post #52

Earlier quoted context omitted.

What freedom does PureOS offer that AOSP without Google services lacks?

I believe there is a general lack of awareness of what AOSP is without Google services and add-ons on top of it. In some facets, AOSP is not a complete and working OS as is. In particular, I have personally had many issues with GPS location for the past fews years. Out-of-the-box, GPS simply does not work without additional non-free software to help it out. Additionally, many (that is, 95%) of all Android apps that y…

How does microg help with that?

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#75

Post by vasili111 »

letstrynvm wrote: post #10

Librem seems to have the correct way forward, reject the big mess of Android and catch up to it with completely Open pieces. https://puri.sm/products/librem-5/ They're making good progress and I can't wait to be able to update my handheld device with mainline pieces for as long as anyone who still uses one cares to update it. Currently my Samsung Android device is at Dec 2018 patchlevel and nothing I can do about it.

The big problem is the price which too high.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#76

Post by strcat »

groovybits wrote: post #73
KirinDave wrote: post #70

Earlier quoted context omitted.

In general, until we have open source handset hardware to work with, all fine-tuned sensors and clock hardware support will be bad. This is a problem Linux had for a long time, and it took a ton of effort to partially solve the problem. It seems a bit unfair to blame AOSP for not having drivers for specific hardware, that's not it's function. The big contribution of Purism phones is that more open hardware. After tha…

I agree, hardware is a primary concern. I am not meaning to paint those who work on AOSP or third-party ROMs in a bad light. The work they do is terrific and great for the community. I also do not mean to dismiss any of the fantastic work that Graphene brings to the Android community. I am simply stating that the biggest difference between Librem and Android is that there are more hurdles to jump through to provide a…

Librem 5 is not open hardware. I also don't understand why you're comparing hardware to an operating system that's perfectly capable of running on top of it with the strengths and weaknesses of the hardware underneath it. You make it sound like AOSP or GrapheneOS wouldn't run on it. I don't think it would make a very good hardware target due to having so many security regressions from the status quo but it could certainly be one of the official targets. Whether or not it's an official hardware target, people will be able to use GrapheneOS on it.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#77

Post by strcat »

groovybits wrote: post #67
opencl wrote: post #52

Earlier quoted context omitted.

What freedom does PureOS offer that AOSP without Google services lacks?

I believe there is a general lack of awareness of what AOSP is without Google services and add-ons on top of it. In some facets, AOSP is not a complete and working OS as is. In particular, I have personally had many issues with GPS location for the past fews years. Out-of-the-box, GPS simply does not work without additional non-free software to help it out. Additionally, many (that is, 95%) of all Android apps that y…

> I believe there is a general lack of awareness of what AOSP is without Google services and add-ons on top of it.

That lack of awareness seems to be your own.

> In particular, I have personally had many issues with GPS location for the past fews years. Out-of-the-box, GPS simply does not work without additional non-free software to help it out.

GPS doesn't require Play Services, etc. Play Services provides supplementary network-based location services for providing a coarse, inaccurate location estimate without waiting for a while for a GPS lock. The infrastructure for this is open source and part of AOSP. It has generic, provider-agnostic support for services like supplementary location providers, text-to-speech, speech-to-text, geocoding, etc. Play Services is what provides these on phones with Google Play, but there are alternative implementations used by Amazon and in China.

> Applications that are built to run on stock AOSP are not the 'Snapchats' or 'Instagrams' of the world.

Yet apps like WhatsApp, Facebook's apps, Microsoft's apps, etc. do work without Play Services... despite what you claim. A lot of these mainstream apps do work fine, and there's a large ecosystem of open source apps that are mostly designed to run without Play Services. Providing the Play Services APIs with an alternate implementation and is also certainly possible, although I would prefer a different approach than microG.

How is any of this resolved by moving to a completely different OS with far less privacy and security, none of these mainstream applications you talk about and barely any open source application ecosystem by comparison? I don't get it.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#78

Post by strcat »

letstrynvm wrote: post #26
rst wrote: post #16

Earlier quoted context omitted.

Chain of trust won't reduce the attack surface, but adopting memory corruption mitigations and replacing C code with something with stronger memory-protection guarantees would -- and while some kinds of memory protection can be bolted on later with minimal disruption, minimizing C is best done from the start.

That sounds reasonable, but here we are with Android's endless security disaster and all their apps written in not-Java from the beginning. The most cancerous aspects of Android are by design, that you cannot control network exfiltration from apps, you cannot update or modify the OS pieces at will, and the apps are monetizing everything you do and everything they can find against you. Librem will answer these.

> that you cannot control network exfiltration from apps

GrapheneOS has a Network permission toggle, which is one of the features already restored from the past work on the project. There are many other privacy and security features that still need to be ported to the latest release, although a lot of them have become standard features especially in Android Q. https://gist.github.com/thestinger/e4bb344dcc545d2ee00dcc22f... is an overview of the Android Q privacy improvements(not security improvements, just privacy) in the context of GrapheneOS. To conserve development resources, the past features that are becoming standard aren't going to be ported over rather than just waiting for the standard implementations being released around August. Some of them will need to be adjusted to make them a bit more aggressive when it comes to apps targeting the legacy API level, but that's a lot less work than maintaining downstream implementations of all of this.

> you cannot update or modify the OS pieces at will

Having a well-defined base OS with verified boot and proper atomic updates with automatic rollback on failure is a strength, not a weakness. It's the same update system (update_engine) as ChromeOS. The update system is not the problem with the broader Android ecosystem with lack of updates to vendor forks. The migration towards everything being apk components that can be separated updated rather than moving more towards the ChromeOS design is a negative thing in terms of GrapheneOS and it's one of the things that has to be changed downstream to improve verified boot.

> Librem will answer these.

That's nonsense. First of all, that's hardware, and also moving to a far less secure software stack with non-existent privacy and security, an inferior update system and no verified boot is not a solution to these problems. The solution to privacy and security problems is not completely throwing away privacy and security...

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#79

Post by mlinksva »

https://grapheneos.org/#roadmap is pretty interesting:

> Details on the roadmap of the project will be posted on the site in the near future. In the long term, it aims to move beyond a hardened fork of the Android Open Source Project. Achieving the goals requires moving away from relying the Linux kernel as the core of the OS and foundation of the security model. It needs to move towards a microkernel-based model with a Linux compatibility layer, with many stepping stones leading towards that goal including adopting virtualization-based isolation.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#80

Post by djsumdog »

yegortimoshenko wrote: post #42
ThinkBeat wrote: post #38

It supports the Google Pixel range of phones only so far. So in order to get that is more secure and more independent from Google I have to buy a Google phone?

There are not that many phone manufacturers that even allow you to change the trust anchor (which makes any of this even remotely possible). For example, Samsung uses e-fuses to burn in their signing key, rewriting recovery will permanently trip their attestation (Knox); other manufacturers use similar practices. Pixels are one of the only currently available phones with user-controlled trusted boot in mind.

Yea. It's bullshit. You can't install something like Magick and then relock the bootloader with a new signature.

A PC with UEFI (except for a few of those which Microsoft locked down) lets you turnoff secure boot, and install your own keys, and turn it back on. So you actively delete the stock keys that boot stock Microsoft/Ubuntu/Redhat, and then custom sign your Grub bootloader or UEFI-Stub Kernel, add that cert to SecureBoot and turn it back on.

You can argue device security all day long, but if manufactures can't update Android security patch sets as they come out, then you have gaps in your device security anyway.

Google controls ASOP. They could literally force manufactures to be compliant, have UEFI or devicetree as a standard, demand every device allow a stock reinstall just like Windows and even create shims to fix the broken Linux driver ABI. But there is more money in planned obsolescence. Gotta throw out that phone after two years and just buy a new one.

Post reply on HN