Live data from Hacker News

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

grapheneos.org

171–180 of 186 posts

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

#171
post #30

Earlier quoted context omitted.

The Android Open Source Project is the only viable starting point. I don't know what else you would suggest. It has solid privacy and security as a baseline already, unlike other mobile or desktop Linux-based operating systems. There's also a huge amount of public security research targeting it for both offensive and defensive work. Moving to the desktop Linux stack would drastically set back both privacy and securit…

> Linux ultimately isn't a viable choice for creating a system with decent security. Stop spreading FUD. In this conversation we are talking about phones filled with bloatware that spies on the user in every instant and you nitpick about memory safety in the kernel.

I'm not spreading FUD, and the conversation isn't about what you claim. Talking about the lack of basic security on existing operating systems based on monolithic kernels written in memory unsafe languages is hardly nitpicking. It's the kind of stuff that GrapheneOS is all about... which is what this entire is about.

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

#172
post #39
post #37

Earlier quoted context omitted.

The open source project was started before Copperhead existed and long before it was incorporated. The project was never directly owned or controlled by the company, as that was an explicit condition of the collaboration with the company. GrapheneOS is the continuation of that original project, but a lot has been learned and it will never become associated with another company or organization to the same extent. The…

I don't think he's representing or misrepresenting much at all. Most of his comment (like mine) talks about what we don't know and asks questions, and like mine admits it would be hard to know anything even if we were told what "really" happened. >It was a problematic relationship long before you heard about it Probably day 1 as it sounds like there was a fundamental conflict with the business and non business entiti…

The business wasn't supposed to be entirely based around my open source project. It was a security consulting company.

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

#173

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.

There are more devices supporting this than there used to be though. https://grapheneos.org/#device-support explains that it's going to support other devices. It doesn't support the Pixel 3a and Pixel 3a XL yet either. Supporting each device is a lot of work, and other devices will need to be carefully chosen. It would be harmful to make bad choices about device support and encourage people to buy insecure devices with too many issues that can't be fixed with another OS.

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

#174
post #103

"Android compatibility" implies that it's something entirely new. It appears to be an Android fork that simply hasn't done away with compatibility. There are neat ideas and all, but the title implies that it's something that it isn't. Lastly, I wonder how this will do over time considering Fuschia.

It's not implied that it's something completely new, although a dozen of the sub-projects are new projects rather than forks of existing ones. The overall project is not simply a fork of the Android Open Source Project with hardening. That's a subset of the work, and a big part of it. I also added a paragraph to the placeholder index page clarifying the longer-term plans with virtualization: https://grapheneos.org/#roadmap.

GrapheneOS includes sub-projects including standalone projects like https://github.com/GrapheneOS/Auditor and https://github.com/GrapheneOS/hardened_malloc that are portable to other operating systems. This also applies to a lot of work that's under active development and not yet published as part of the stable releases.

It intentionally doesn't stick to the Compatibility Definition Document / Compatibility Test Suite requirements required to be Android, so it can't be referred to as Android, but rather it's an OS with Android app compatibility. It preserves what's actually needed for compatibility in practice, while not being strictly bound by those requirements. The intentional deviations from these are documented, and there are a bunch of them.

> Lastly, I wonder how this will do over time considering Fuschia.

If it ends up shipping as a replacement for the core OS, with Android running in a virtual machine or on top of a compatibility layer like gVisor, that would just mean that there's a better base to build on than before. All of the work done by the project would still be relevant in a future like that. I'm not so sure that's truly going to happen though.

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

#176
post #130
post #105

Earlier quoted context omitted.

> with completely Open pieces AOSP is completely open source. Hardware and firmware is a much different story, but that applies to the device you're promoting just as much... > 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…

> AOSP is completely open source. This is only true in the most technical way possible. Yes, AOSP is open source -- but none of the standard applications on any stock version of Android use AOSP anymore. The calendar and other applications are all proprietary. The AOSP versions feel like they stopped being developed in 2010 -- which coincidentally is when Google started developing proprietary replacements. I use Line…

>This is only true in the most technical way possible. Yes, AOSP is open source -- but none of the standard applications on any stock version of Android use AOSP anymore. The calendar and other applications are all proprietary. The AOSP versions feel like they stopped being developed in 2010 -- which coincidentally is when Google started developing proprietary replacements.

AOSP sample applications like Calendar are exactly that: samples. I'm not sure why those are at all relevant. There's a very healthy and active open source app ecosystem, along with many other apps that work on AOSP. Those AOSP apps are included as samples, and they're being removed from the project as at this point there's no real need to have these samples.

It's also not true what you claim about the stock applications shipped on a phone like a Pixel. Apps like Dialer, Contacts, DeskClock, etc. are still actively developed and maintained in AOSP with the Google variants being extended versions of those apps. It's true that some apps like the keyboard forked away from the AOSP version, but it doesn't make AOSP any less viable of a basis for an OS. It's not a bad thing for AOSP to not ship a bunch of user-facing apps when there are a bunch of good alternatives outside of it. Apps do better without a release cycle tied to the slower pace of the OS releases.

> The Librem 5 hardware was specifically chosen so that it contains no firmware blobs and all the firmware is free software and upstream in Linux. There is a caveat for the baseband, but that's because it's not legal in most countries to sell or use baseband hardware that is free software (unless the user is licensed and even then it's non-trivial).

This is completely untrue and absolutely a false claim. The SoC is entirely proprietary with proprietary hardware, firmware and microcode along with the other components like Wi-Fi, the baseband, etc. being the same. The cellular baseband is not an exception. It applies to all of the hardware components in general. Librem 5 is not open hardware and does not have open firmware or microcode. It's simply untrue, and you're falsely representing it. I can see why you would be under that misunderstanding based on their incredibly misleading marketing but they never actually claim what you are claiming.

Not providing firmware updates for these things is a security disaster. The firmware that's upstream in Linux is rarely open source. It's a subset of the necessary firmware for most devices and is still proprietary. Projects like linux-libre / PureOS do not ship these upstream Linux firmware updates. They strip all of this out of the kernel. They also don't provide all the additional firmware updates beyond what is upstream.

The hardware and firmware is just as proprietary. The boot chain has open source components near the end before the OS (coreboot), just as many mainstream devices do (https://source.codeaurora.org/quic/la/abl/tianocore/edk2).

There's a huge difference between choosing hardware that has built-in firmware and can work without the OS supplying it each boot and hardware with open firmware... what they are doing is shipping a device that can work without the OS providing firmware updates, since they don't do that to keep it 'pure' of proprietary code. The firmware is still present and running, except it's out-of-date and vulnerable to many patched security vulnerabilities. You're completely misrepresenting the reality and falsely portraying it as having open hardware and firmware when it absolutely does not.

https://twitter.com/mjg59/status/1129124275464441856

What you claim about not being allowed to have open cellular baseband firmware is also nonsense. It's also not particularly different from how Wi-Fi works. Wi-Fi firmware is a comparable secondary OS, and the same applies to a lot of other components. These hardware and firmware components on the Librem 5 are not any more open. What you're doing is spreading misinformation and false claims to promote it as something that it's not.

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

#178
post #94

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?

> It supports the Google Pixel range of phones only so far. See https://grapheneos.org/#early-stage-of-development and https://grapheneos.org/#device-support . There's barely any content on the site, since it's so new, but this is covered pretty well. It does support other devices already. There's a difference between that and deciding to do all the work to provide official releases with seamless over-the-air updates…

How good is the Dual-SIM support ? Seeing the P20 Pro on that list is very promising.

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

#179
post #153

Earlier quoted context omitted.

I think if you dont have a strong opinion about it, this is exactly what they are trying to achive with Zircon/Fuchsia kernel. A micro-kernel, with a linux virtualization layer, being abble to run Linux executables as if they were native. My hunch is that in the long term, Google will probably use Zircon as the 'first-level' kernel, and run the android apps using some emulation layer. Maybe it could be the answer for…

Google has already kind of achieved that with ChromeOS, each Linux executable runs in a sandbox, specially tailored for it. It can only see hardware, files and processes that the user allows to as well. It was written in Rust. Check the ChromeOS support for Linux talk at Google IO.

I have checked this earlier. Its pretty cool stuff, but its more in the direction of userspace emulation like what GVisor do.

The OP expressed he wanted to use (or create idk) a micro-kernel based OS, and that in the end he would like to scrap the Linux kernel.

Of course the solution you are pointing out will deliver in one of those axis, but the solution im pointing out would deliver in both, Linux emulation/sandboxing and a micro-kernel based OS controlling all of this.

I just think that the direction Fuchsia is going, has a little bit more to do, to what he is trying to achieve.

But he can totally mix the 'syscall proxy' solution of ChromeOS and a micro-kernel, even if this would still be Zinc or something else. And depending on the goal, maybe having this in userspace level would make more sense. He just need a good and flexible IPC communication (like the one in Chrome, or something on the kernel level).

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

#180

Earlier quoted context omitted.

GPS doesn't make your location known at all, it's receiving only. It sends information about your location to nobody, it triangulates your position from publicly broadcast signals. And, I would much rather "make my location known" to about fifty other companies before I would want Google to have it.

I did not know that and even looked it up to confirm. Thanks for mentioning it https://www.maptoaster.com/maptoaster-topo-nz/articles/how-g...

Yeah, GPS is actually insanely cool technology, and the US making it available to everyone was a real public service. Now of course, other nations are, partially for defense purposes of course, deploying similar networks as well.

And it's just out there. Usable with no subscription, no account, nothing. It's just free data.

Post reply on HN