Copperhead uses Grsecurity, and I used to use Grsecurity, when it was widely available, now that it's not and the developer has decided to act in hostile ways to the Linux community(1), it's made me rethink using his work and/or supporting him. Plenty of consultants make do fine without resorting to closing off their source code, and decide to act better with the community and/or companies.

(1) https://www.theregister.co.uk/2017/12/22/grsecurity_defamati...

CopperheadOS doesn't use grsecurity anymore afaik. https://twitter.com/CopperheadOS/status/933684025624993792

Actually, copperhead itself is sort of loosely following grsec's model, which is rather unfortunate. Their licences, where required will be GPL or compatible with upstream, but otherwise copperheadOS itself is not FOSS. I kind of get that it's hard to make money in such projects, but I really don't see how this strategy works for them, unless the goal is just to be bought out by someone.

Thanks for the link. Happy to hear they're maintaining Linux-hardened themselves.

Copperhead maintains the -hardened patchset, which is essentially a fork of Grsecurity, largely because of those concerns. (I don't use CopperheadOS on my phone, but I do use their work in the form of linux-hardened on my desktop!)

We've reverted the title above to the article title, since that's what the guidelines call for anyhow, unless it's misleading or linkbait. The submitted title was "Copperhead OS – De-Google Your Phone".

https://news.ycombinator.com/newsguidelines.html

A brief summary of what something is can be helpful. I probably wouldn't have noticed this story if it wasn't explicitly mentioned as being about phones; I like hearing about a new OS but since I don't have the time/urge for kernel hacking I've generally stopped reading such stories.

Your otherwise good comment probably should include two things that are critical to Google's stance on Android security:

1. They're a surveillance company that has more actual and potential earnings the more they know about their customers. They get good margins when their customers lack privacy with devices locked into Google by default.

2. They don't care about users' safety since make billions off Android platform but wont even patch vulnerabilities quickly. They have enough money to design a server UNIX from scratch plus a full-custom CPU plus mitigations from code injection at CPU level with all that leaving them with a few billion in revenue left out of Android alone. They just don't care since they're a public company about squeezing out every ounce of profit.

So, their incentives ensure they will leave the devices insecure. Someone will have to make their own versions that are secure like Copperhead and separation kernels before them (eg OK Labs) did. Alternatively, convince Google to offer a paid, secure option for their own internal use if nothing else with them recovering costs by eating up the cryptophone market's revenues.

I'm not sure i follow, you can upstream any security feature to AOSP, CopperheadOS dev has upstreamed lots of stuff to improve security overall which is good. Google can do whatever they want but most of it is happening in house sadly, they could probably pay grsecurity devs to implement security features for Android & ChromeOS if they wanted to.

That last part is exactly my point. They're making billions on Android but will barely patch it. They just dont care at all since the money will go into their pockets anyway. Instead, all these small players have to show up working nearly for free swimming upstream with their enhancements making almost nothing.

Well it's already pretty hard to exploit Android, the kernel is the weak point at the moment. I've studied the grsecurity code a lot and if you can exploit that stuff you can get high paying jobs for either red team or blue ;) Making it harder and driving up the cost to use/write exploits and ofcourse making everyone more secure is the end goal for the sec team :D

Can you explain how 2.) follows from 1.) ? Or at least how exactly has Google incentive to keep Android insecure (especially in terms of all the security research/hardening being done by internal teams, both for Android and iOS)?

They're seperate. Bad security follows from both. For one, too little privacy is profitable for a company selling or matching against profiles obtained from surveilling their users' activities. On 2, redoing Android security or just handling it better would cost more for Google even though the problems are externalities: they cost the users, not Google. For-profit, public comoanies ignore externalities as much as possible to maximize profit.

So, Google securing Android would cost them a lot of money for fixing the customers' problems that dont affect Google. Then, it might cost them piles of money later in lost ad revenue when now-private services make customers black boxes of sorts.

I think there's a lot of middle ground to explore but surveillance or public companies don't usually go for it. Offering a paid, surveillance-off version of each ad service is one of those. You will rarely see that as simple as it is to do.

You're deliberately ignoring the constant security updates and patches Google is pushing, both monthly (https://source.android.com/security/bulletin/) and as part of OS updates: (https://android-developers.googleblog.com/2017/12/double-stu...).

That's helpful insight. Thank you.