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

131–140 of 186 posts

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

#131

Post by dingaling »

yorwba wrote: post #35
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.

> Currently my Samsung Android device is at Dec 2018 patchlevel and nothing I can do about it. Have you checked whether there's a LineageOS build for your device? https://wiki.lineageos.org/devices/#samsung (Darker links indicate a build is maintained and available.)

Lineage are quite aggressive in dropping older hardware since they pivoted towards 'experience'. My 2013 Galaxy S4 is no longer supported.

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

#132

Post by realusername »

pjmlp wrote: post #43
yegortimoshenko wrote: post #13

Earlier quoted context omitted.

Librem 5 isn't going to be particularly security-focused: no attestation, no trusted boot, most userspace programs are written in memory unsafe languages like C, with no extra effort memory corruption mitigations. Also, Flatpak offers a permission system that's very limited compared to Android.

While with each Android interaction, Google locks down the amount of C and C++ code that gets exposed to outside world. https://android-developers.googleblog.com/2019/05/queue-hard... As such I have a very hard time believing that Librem with be as secure as modern Android.

> As such I have a very hard time believing that Librem with be as secure as modern Android.

Android isn't secure, it's limited, that's the whole problem here. Any security you can't control isn't a security feature but just a limitation. It's "secure" because you can't do anything interesting with it.

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

#133

Post by jammygit »

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.

I don’t fully understand why it was not easier to build a fork of aosp, but it is exciting at least

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

#134

Post by jammygit »

strcat wrote: post #109
ignoramous wrote: post #5

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…

Just wanted to say: Thanks for all your work on these projects

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

#136

Post by jammygit »

ocdtrekkie wrote: post #129
beenBoutIT wrote: post #127

Earlier quoted context omitted.

If you're willing to make your location known in order to take advantage of location services why wouldn't you want the very best possible service? There are complicated workarounds that can be used in place of Google's location services but none of them are anywhere near as easy to implement for the app developer or as easy to use or as accurate for the end user.

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

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

#137

Post by pjmlp »

soraminazuki wrote: post #110
KirinDave wrote: post #69

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…

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

Not the entire industry, as many companies have thankfully moved on from plain old C, or at very least reduced its use quite considerably.

BSD/Linux derived FOSS is still the C stronghold.

The Morris worm was in 1988, since then C has collected enough CVEs due to memory corruption issues to consider its use bad practice.

Something that even Apple, Google and Microsoft security reports now advise against, and with Google actively engaging into taming C's usage in Linux kernel.

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

#138

Post by pjmlp »

realusername wrote: post #132
pjmlp wrote: post #43

Earlier quoted context omitted.

While with each Android interaction, Google locks down the amount of C and C++ code that gets exposed to outside world. https://android-developers.googleblog.com/2019/05/queue-hard... As such I have a very hard time believing that Librem with be as secure as modern Android.

> As such I have a very hard time believing that Librem with be as secure as modern Android. Android isn't secure, it's limited, that's the whole problem here. Any security you can't control isn't a security feature but just a limitation. It's "secure" because you can't do anything interesting with it.

Using Android with reluntance, since my favourite OSes were Symbian and Windows Phone, additionally I dislike Android J++ and the NDK is relatively constrained.

Still, I can do plenty of interesting things with my Android gadgets.

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

#139

Post by Nursie »

pjmlp wrote: post #137
soraminazuki wrote: post #110

Earlier quoted context omitted.

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

Not the entire industry, as many companies have thankfully moved on from plain old C, or at very least reduced its use quite considerably. BSD/Linux derived FOSS is still the C stronghold. The Morris worm was in 1988, since then C has collected enough CVEs due to memory corruption issues to consider its use bad practice. Something that even Apple, Google and Microsoft security reports now advise against, and with Goo…

> BSD/Linux derived FOSS is still the C stronghold.

Oh that's ok then, it's not like that accounts for most of the world's server and embedded infrastructure, open or otherwise...

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

#140

Post by orbifold »

Nursie wrote: post #139
pjmlp wrote: post #137

Earlier quoted context omitted.

Not the entire industry, as many companies have thankfully moved on from plain old C, or at very least reduced its use quite considerably. BSD/Linux derived FOSS is still the C stronghold. The Morris worm was in 1988, since then C has collected enough CVEs due to memory corruption issues to consider its use bad practice. Something that even Apple, Google and Microsoft security reports now advise against, and with Goo…

> BSD/Linux derived FOSS is still the C stronghold. Oh that's ok then, it's not like that accounts for most of the world's server and embedded infrastructure, open or otherwise...

The operating system is only a tiny fraction of commercial code out there most of which is either written in (more) memory safe languages like Java, C# or C++. SAPs code base alone is 1 billion lines of mostly C++ and their own proprietary scripting language.
Post reply on HN