Live data from Hacker News

Devices with GrapheneOS support should be available in 2027

grapheneos.social

281–290 of 444 posts

Re: Devices with GrapheneOS support should be available in 2027

#281

[flagged]

There has been successful honeypots like EncroChat. What's the evidence that GrapheneOS is not yet another one?

For one, GrapheneOS is open source, unlike EncroChat which was a shady proprietary app distributed on shady modified smartphones.

GrapheneOS also doesn't have any custom messengers or other services which could potentially be monitored. It's very easy to check where your phone is sending requests, and if Graphene was secretly MITMing all of your traffic it would be discovered within days.

Re: Devices with GrapheneOS support should be available in 2027

#282

I've never really understood why we chase Android-alikes on mobile platforms instead of trying to build on mainstream Linux. I know some folks in the nix community (nix-on-droid and other projects) have tried to bring us closer to this, but projects like Graphene seem to have a lot of traction.

One word: ecosystem. Phones are useless bricks without an ecosystem. This is why we only have 2 operating systems for portable devices when we used to have more than twice the amount.

Re: Devices with GrapheneOS support should be available in 2027

#283

[flagged]

Person A: Did you know Google removed access to Pixel code repo.

Person B: Well, it didn't go away, they just changed the access method to Google Drive.

Saved us that conversation here, Thanks. No matter what mental gymnastics we may do, it is pretty clear where this is heading.

On a different note, the source download form requires you to accept Google's privacy policy for the information you submit.

Is it ok to tack on accepting additional policies as requirements to access what is allowed under OSS licenses.

Re: Devices with GrapheneOS support should be available in 2027

#284

Earlier quoted context omitted.

How about for clients with no smartphones?

You're basically out of luck. This is happening all over the world these days with various government services . It's not just for clients with no smart phones. It's also clients who activate developer mode on their smartphone etc... clients who use VPN. Clients who run AdBlocker. Clients who use Firefox. There needs to be a severe push back against this. Things have gotten so crazy that the homeless here are walking…

I am so grateful for the large religious population in my country who eschew the smartphone. I suppose because of them every back and government service is available to all citizens.

Re: Devices with GrapheneOS support should be available in 2027

#285

Earlier quoted context omitted.

My broker has a much more fully featured web app then it does on iOS or Android. You can do things in a browser that the phone apps will send you to a browser to do. BofA is just as good of a web app. Maybe people are just used to using their phones?

Can you deposit checks from the webapp? That is the feature most often missing in banking webapps. It isn't something I need often, fortunately.

Asking for a cheque deposit is like asking for a car with a hand crank. People outside USA are going to look at you like on a member of a Sentinel tribe.

Re: Devices with GrapheneOS support should be available in 2027

#286

I've never really understood why we chase Android-alikes on mobile platforms instead of trying to build on mainstream Linux. I know some folks in the nix community (nix-on-droid and other projects) have tried to bring us closer to this, but projects like Graphene seem to have a lot of traction.

Everyone else mentioned the app support which is true, but for graphene specifically, they do not like desktop Linux at all because they don't like its security. They would much rather build on AOSP than desktop linux.

[flagged]

Re: Devices with GrapheneOS support should be available in 2027

#287
post #269

Earlier quoted context omitted.

What is the point of apps for these things in particular? I understand that some banks require an app for 2FA, but I don't see why anyone would want some invasive healthcare app on their phone.

It's not invasive generally speaking. My healthcare provider allows me to access e-perscriptions via the app. But for that there are certain security requirements which this particular Healthcare provider equated to "Android good, GOS bad"

> My healthcare provider allows me to access e-perscriptions via the app.

Why can't the prescription be sent to email or collected on a website? I don't see why an "app," especially one signed by Google is necessary for something like this. It wouldn't surprise me if the app requested location or sensor access in order to provide a "personalized experience."

Re: Devices with GrapheneOS support should be available in 2027

#288
post #271

Earlier quoted context omitted.

> Google, this small tech company (correct me if I'm wrong), is peddling source code via tarballs on google drive. What is the context for this? It's not clear from the linked social media post. The Android kernel source code is in git: https://android.googlesource.com/kernel/common/ Plus there's a lot of other Android source hosted on Google's git servers: https://android.googlesource.com/

It's mentioned in the same thread, just scroll up a few pages in the linked social post.

Yes I read the whole thread, but it wasn't clear which bits of source code required requesting a tarball.

Re: Devices with GrapheneOS support should be available in 2027

#289
post #36

Earlier quoted context omitted.

All the existing apps are on Android and iOS. Graphene lets you run them. You can't have a bank account on a Linux phone* because they won't let you, but you can on Android including on Graphene. * before replying snarkily that Android is Linux, please take a long walk off a short pier, thanks

> All the existing apps are on Android and iOS. Graphene lets you run them. We have waydroid for that. > You can't have a bank account on a Linux phone* because they won't let you, but you can on Android including on Graphene. Unless of course it uses those stupid integrity apis to block anything that isn't stock.

GrapheneOS primarily exists to greatly improve privacy and security compared to the Android Open Source Project (AOSP). AOSP provides far better privacy and security than a traditional desktop Linux distribution. It has a strong mandatory app sandbox, an increasingly good permission model moving more and more towards case-by-case consent, broad use of memory safe languages throughout the OS and app ecosystem, strong MAC/MLS policies developed as part of the whole OS, modern exploit protections, verified boot with downgrade protection for the whole OS and far more. GrapheneOS starts from the already good privacy and security of AOSP and greatly improves upon it. We greatly improve the permission model, exploit protections and much more but we depend on starting from a foundation that's already decent.

Moving to a far less private and secure desktop software stack is going in the opposite direction from GrapheneOS. GrapheneOS doesn't exist to simply provide an alternative to mainstream operating systems but rather to offer much better privacy and security. We wouldn't be doing that if we were forking a desktop Linux environment and doing similar work for it. It would be nowhere close to the privacy and security of simply using an iPhone. That's a major part of why GrapheneOS is based on AOSP rather than it solely being about compatibility.

Desktop distributions are incredibly far behind on privacy/security and lack any clear path to achieving the same things. Every year, Android makes backwards incompatible privacy and security improvements as part of a new target SDK version. Android retains compatibility with legacy apps, but apps distributed through the Play Store (and other app stores to an extent) are required to move to the new target API level within around a year. This results in apps being forced to conform to a gradually improving privacy and security model. There's no such thing for desktop Linux apps but rather apps choose how much they want to participate in nascent sandboxing efforts.

GrapheneOS has near perfect compatibility apps from the Play Store via our sandboxed Google Play compatibility layer with the exception of banking and government apps. 90% of banking apps currently work on GrapheneOS because it greatly succeeds all of their security requirements and is only wrongly banned by a subset of those apps. These apps are gradually adding more anti-tampering and attestation checks for the hardware and OS, so maintaining compatibility has required us to gradually add more functionality working around it. We've also had to actively convince apps to stop banning non-Google-certified operating systems or to permit GrapheneOS and other secure options alongside doing it. A growing number of apps are choosing to stop banning using GrapheneOS due to pressure from our expanding userbase.

Waydroid uses namespaces and a compatibility layer to run an outdated fork of LineageOS. It's far from providing full functionality and compatibility with apps and nowhere close to the compatibility provided by GrapheneOS. More importantly from our perspective, Waydroid disables most of Android's standard privacy and security model through not supporting SELinux and other core parts of the security model. Android doesn't simply use SELinux as an additional layer of security with targeted policies but rather it's deeply integrated into the OS. It uses very strong whole system policies to implement the app sandbox, drastically reduced kernel attack surface and a lot more. Namespaces for the overall userspace environment are not a replacement for the app sandbox, kernel protections, verified boot and the rest of the security model.

Post reply on HN