Live data from Hacker News

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

grapheneos.org

101–110 of 186 posts

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

#101
post #62

Security focused and Android in the same sentence? All I can say is good luck with various firmware, custom services and drivers.

Found the Apple zealot! Seriously though, I hear Apple is super great on privacy now as long as you take their word for it and not their track record of being a member of PRISM https://en.wikipedia.org/wiki/PRISM_%28surveillance_program%... , etc

Every US company has to comply with lawful US government orders if they're going to continue operating. I highly recommend reading carefully through the details on the page you linked. It doesn't only apply to a few companies. It's very difficult to fight the government even in cases where it's arguably unconstitutional, etc. You have to assume that all US companies are going to comply with US warrants to obtain information, including when those warrants come from a secret court with a gag order.

There were consequences to the US passing draconian surveillance laws like the Patriot Act and the updates to it. Companies / organizations and individuals based in the US are subject to those laws. Many other countries have similar or even more oppressive laws when it comes to these things.

A company being based in for example France doesn't mean that the same kind of things don't apply.

If you don't want data to be subject to warrants requesting the information from companies, you need to either avoid having your data there or make sure it's encrypted with a key that the company doesn't have. End-to-end encryption is important. The companies could also have the data exposed by a malicious insider or a data breach. Many countries will happily demand the key from you and then treat you as a criminal for not turning it over but that doesn't work for mass surveillance.

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

#102
post #30
post #3

A very condensed version of the messy CopperheadOS implosion is: https://en.wikipedia.org/wiki/CopperheadOS#History It's good that the tech person is moving on, but Android doesn't seem a great starting point if privacy&security are the top priorities (as opposed to remaining captive in the Android camp, with some belief that you're a bit more secure than default).

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…

That's what OK Labs did before GD bought them:

https://web.archive.org/web/20111130031013/http://www.ok-lab...

CompSci folks have been doing it, too. Here's a paper describing the design style:

https://os.inf.tu-dresden.de/papers_ps/nizza.pdf

Genode OS Framework is only one I know building something like this in FOSS. The rest, esp used in phones, were commercial. One might port Android to something like it or seL4 with dynamic, resource management. Rewrite drivers or anything that's moved to kernel mode for performance in safe language or lots of verification tooling thrown at it.

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

#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.

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

#104
post #59

Would this be something Huawei might get into?

Huawei could probably do something similar, however they still can't access the Google Play Store and such, therefore leaving them in a problematic area. For instance, though somewhat substantial, the Amazon store is quite pitiful in comparison to Google Play. Huawei could attempt to make a store but it won't have the world of apps that already exist on the Play Store.

This would work in China though, since they don't have the Play Store in the first place.

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

#105

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.

> 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 can do about it.

What's the relevance?

It's also quite important to note that the Android patch level includes firmware. Purism doesn'tship firmware updates in PureOS as part of it being 'pure', so you would be stuck with the equivalent of an ancient patch level at least with the stock OS. You're also no less dependent on the companies releasing firmware updates.

You're also bringing up hardware as an alternative to an OS that would run on the hardware that you're talking about. It's hard to understand the point. The Librem 5 will be a hardware target for GrapheneOS to consider. It will be missing many of the core hardware security and robustness features, so it couldn't be a tier 1 target, but it could still be unofficially or even officially supported.

If it doesn't depend on any out-of-tree kernel drivers, that will apply to Android and GrapheneOS too. I'm not sure why you're bringing it up as something distinct.

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

#106
post #92
post #61

What does it matter if you are still running proprietary software with direct memory and CPU access on your network, camera, ... Android can give you privacy and enough security for most people. This can't add much more as long as its running on the same devices. This is a great effort and I support it, but let's not imagine this will make our phones that much more secure.

Open source is a development model and doesn't have magical privacy and security properties. An iPhone is going to remain the best overall option for privacy and security for the near future, especially for users that aren't very technical. That's not really in spite of it being almost entirely proprietary but rather that's something quite orthogonal to it. GrapheneOS aims to provide a much more private and secure op…

"They're on the same die as the CPU and come with it. That doesn't mean they can freely access all memory... but it does mean that supply chain attacks targeting them would generally be able to target the CPU instead."

I don't disagree with your overall post. I do want to add that there's a good reason to not put the backdoor in the CPU: it's main place they'll look with plenty of people capable of spotting it. The guy that taught me about hardware subversion years ago preferred hiding stuff in analog parts of mixed-signal ASIC's. He said digital people neither saw it nor understood it. He and others taught me about how the two can interact in invisible ways where analog or RF portions might pick up leaks. So, deniability is maximum if it's some kind of analog or RF part of a chip. He claimed to have never found backdoors but that he and others used this for I.P. obfuscation a lot.

I do like the IOMMU and firmware work. There's a lot of custom I.P. to build before being competitive with one of high-end SOC's. One thing I considered about trying to make an open phone is whether a company with money could just pay for Snapdragon to be integrated with the RISC-V cores. Modify RISC-V core to use microcode for security updates and product enhancements. Put security barriers in key places so Snapdragon I.P. is a little less dangerous or can even be powered off component by component. Then, if the agreement gets more data on hardware, use that with secure, development practices to make robust drivers. Include method for secure boot and update that still allows user to put their own stuff on the phone if they choose.

What you think?

EDIT: In case it wasn't clear, I know there's stuff like IOMMU's in Snapdragon. I'd just prefer an independent, security-focused company to be making those components. Sort of a check against incompetence or malice on Snapdragon's end.

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

#107
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…

PureOS seems to have these exact same problems except way worse.

Yes, a significant fraction of Android apps do not work on AOSP without Play Services. And 100% of Android apps do not work on PureOS. F-Droid alone has ~1800 apps. I do not see PureOS or PostmarketOS catching up to that level anytime soon.

FOSS projects that are built out of passion, but recieve little funding or corporate support? Exact same situation on PureOS.

Are the Snapchats and Instagrams of the world going to port their apps over to this entirely new platform when they can't even be bothered to make versions of their Android apps that work without Google's services?

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

#108

Earlier quoted context omitted.

> There is security, and then there is freedom. You can have the most secure system in the world -- but if there are state sponsored, or company back back doors it means nothing. Okay, so you're saying: "If a backdoor is present than your security prioritization doesn't matter, the result is bad." I understand, but: 1. If there is a back door in open source code that goes unnoticed (and it certainly does) because of…

I feel google is really turning into Microsoft. These are the same anti open source talking points / FUD you’d see in the early 2000s.

Who exactly is talking about anti-openness here? We're talking about which open source piece of code to reuse. Someone gave a bad argument against one company's offering.

Microsoft of the 90s, which no one emulates these days and it's a wrongheaded comparison anyways, would have said that all the open options are bad to begin with.

If you meant to say "anti-free software" then maybe we could have a conversation, but that's hardly the problem Microsoft faced in the 90s and 2ks.

Seriously, what does your post mean? Could you maybe be specific? And while we're at it, what's your connection if any with the company that sells Purism phones.

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

#109

Creator of CopperheadOS [0] and now GrapheneOS, Daniel Micay, was a prolific contributor to rustlang-core [1] but did rub off the rustlang community the wrong way? If I'm not mistaken he has a history of contributing to Arch Linux, as well. What happened with CopperheadOS was unfortunate [2]. I hope Daniel [3] is able to work on GrapheneOS on his own terms [4]. The work that was done had garnered a lot of following a…

> but did rub off the rustlang community the wrong way?

I find it interesting that people bring up my time contributing to Rust as a negative thing, largely due to my former business partner misrepresenting it and falsely claiming I was kicked out of the project. To be clear, I don't think you're doing it maliciously, but it's quite weird that contributing so much of my time to an open source project and then having that used against me as if working on a set of open source projects nearly full time for a year as a volunteer was a terrible thing to do. It's a large part of why I now avoid doing work without compensation. If people are going to value my work so little, then I'm at least going to get paid for it.

I left Rust on my own accord because I wasn't enjoying it anymore and I'd determined that it was extremely unlikely that it would turn into a career which is part of why I'd persisted long past the point that I was enjoying it. It became harder and harder to accomplish anything of substantial value as it moved towards stability. I had strong opinions on many of the topics and to get anything done as an outsider I had to make strong arguments and be incredibly persistent, which rubbed some people the wrong way. It was also very rough at that time being an outsider and trying to have a significant influence on it, especially when I disagreed in many areas with the core developers. The way things were done drastically changed later on for the better. I left the project for the same reason a few people didn't like my involvement in it. I was getting burned out dealing with them and they were getting burned out dealing with me. It certainly went both ways and the vast majority of the people involved in the project didn't have issues with me. Out of thousands of people, there were only a couple that I truly didn't get along with and literally only one person where that persists today (and believe me, I'm not the only person who doesn't click with them).

I've certainly evolved how I communicate with people online since then. I still take serious issue with people bending the truth and being dishonest / misleading, which can make arguments very heated if people aren't trying to debate based on the facts. There's a tiny minority of people that I absolutely don't get along with because they'll keep bending the truth and I'll keep pointing out that they're doing it, which they can interpret as an insult. In the context of a debate over the design of a project where the stakes are high, I'll choose not to be very diplomatic when the alternative is letting someone walk all over me with false claims. It's too tiring refuting things over and over and having facts treated as subjective things rather than being able to agree upon a set of facts and argue things based on their merits. I think the world would be a better place if people didn't tolerate this so much. I was no good at playing politics and choosing my battles carefully which played a big part in it too.

The objective truth is that I decided to leave the Rust project and community, and I removed myself as a contributor from the repository. If I recall correctly, I think someone misinterpreted what happened and posted a thread on /r/rust incredibly angry because they thought I was kicked out of the project. The people who saw the thread but weren't aware of the details assumed that it actually happened and then had a massive fight with each other about whether something that didn't happen was justified or not. The reality is that it didn't happen in the first place.

I also seriously doubt that I would be kicked out of any project for occasionally being a bit abrasive in arguments. It would be a bit ridiculous for a project to ban people from contributing for having that kind of personality or not being neurotypical. It's possible that they would have asked me to start being less abrasive in debates, sure, but they hadn't. I definitely don't think I was always fun to work with, particularly once things had soured with Mozilla, but I don't think it's entirely fair to put all the blame on me for that. I was upset about what had happened overall and that definitely influenced how I participated.

My experiences with Rust and other projects are what led to me making sure that I'd own and control the projects that I'd be heavily working on in the future so I wouldn't need to spend so much of my time debating and playing politics. When I co-founded Copperhead, I made sure that it was explicitly agreed that my open source work would remain under my control despite the company sponsoring it. It was explicit that I would own and control the OS development project. It's worth noting that there were 3 co-founders, and 2 of us believed in open source and the company building value around it rather than by selling it. Unfortunately, the 3rd co-founder left early on before shares were even divided up, and I ended up owning the company 50/50 with a narcissistic sociopath who ended up totally screwing me over. Internally, there was conflict and dysfunction long before it became public. I wanted to be free of that company for a long time, but I couldn't leave because I couldn't just abandon the people using the project and it had become too tied to the company. Eventually, my business partner decided to throw away all the agreements and just try to take over the project with threats / ultimatums. I don't think it was at all rational for him to do that. It wasn't at all in his best interest even from an entirely selfish point of view. There's absolutely no way I was going to turn over ownership / control of my project to someone that by then I considered highly untrustworthy and downright dangerous. Unfortunately, they had set up everything to be able to completely screw with over by tricking me at various points and being very strategic about how the domain, infrastructure, etc. was set up. It ended up not mattering at all that I owned 50% of the shares because they just ignored my rights as a shareholder and banked on me not wanting to spend a huge amount of money fighting them in court.

GrapheneOS is the direct continuation of my work on this, which began before Copperhead became involved in it. It had existed before it was CopperheadOS. I've learned a lot of lessons from the experience there. One of the biggest mistakes was being tricked into not being a director early on, but that was also before the stakes had become so high. It also really shouldn't have mattered to the extent that it did if the Copperhead lawyer had been at all competent and truly looked after the interest of the company instead of acting solely on behalf of my business partner. Anyway, I'd rather not be directly involved in businesses at all. I've had almost nothing but bad experiences with governments, businesses, etc. including things far worse than the stuff with Copperhead.

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

#110

Earlier quoted context omitted.

There is security, and then there is freedom. You can have the most secure system in the world -- but if there are state sponsored, or company back back doors it means nothing. In FOSS initiatives spent ages building fee and and open software, combating proprietary systems and software that they had no control over. All that would be loss just to give it up now that we have moved from PCs to phones.... I for one want…

> There is security, and then there is freedom. You can have the most secure system in the world -- but if there are state sponsored, or company back back doors it means nothing. Okay, so you're saying: "If a backdoor is present than your security prioritization doesn't matter, the result is bad." I understand, but: 1. If there is a back door in open source code that goes unnoticed (and it certainly does) because of…

> persistent but bad practices in the open source community (e.g., a stubborn refusal to stop using C-like memory management semantics and primitives when dealing with untrusted inputs)

This applies to the entire industry. It's not something specific to the open source community. It's also extreme to call the use of C as "bad practice," as any language has its own strengths and weaknesses.

Post reply on HN