Live data from Hacker News

Android Developer Verification: Threat masquerading as protection

f-droid.org

601–610 of 793 posts

Re: Android Developer Verification: Threat masquerading as protection

#601
post #143

Earlier quoted context omitted.

> Doesn't GrapheneOS supports only Google Pixel smartphones now? For good reasons. Most other devices arent secure enough to guarantee privacy. Especially not if loaded with a custom operating system (most devices don't allow to verify the boot chain with a custom OS) > And if we're talking about common people (especially not in US), it's not even everyone who can afford that. You can get a new Pixel 9a here in europ…

So to avoid google's android I buy google phone to not run android?

Yes, currently Pixels are the only phones with support for the hardware security features GrapheneOS requires.

In 2027, you will be able to use the Motorola flagships to run GrapheneOS.

Grapheneos is still based on Android.

Re: Android Developer Verification: Threat masquerading as protection

#602

Earlier quoted context omitted.

You seem to be greatly misunderstanding what is actually happening. You are conflating default OS domains with google play services. Google play services is not bundled or installed by default, and is not given any kind of privileged access when it is installed. It does not handle OS domains or functionality, and GrapheneOS does not proxy its connections in any way. As for the default domains of the OS, most are to G…

[flagged]

> every app installed is known to the proxy since each app has a unqiue key

GrapheneOSs proxies do not collect and send any "unique keys" from apps. That is made up.

> They mention no proxy of RCS data, but in theory, an RCS message requires location data. So, the proxy knows when a message is sent and received, at a minimum.

They dont mention a proxy of RCS data because there isnt one. RCS messages do not require location data. None of the GrapheneOS proxies are related to RCS and the proxies do not know if an RCS message is received or sent.

> So, based purely on the FAQ, if you use the sandboxed services and enable RCS, Graphene knows every app you install and has your location data, but they erase it after a couple of weeks.

You did not read the FAQ at all.

> There is some vagueness regarding the RCS implementation message content. People claim Google can't read it, yet they specify they can read it in the client terms, and offer a managed RCS archiving service that works regardless of messaging client or supposed encryption. Is the RCS query proxied? Graphene does not mention it, but the simultaneous location data to use it is.

RCS is end to end encrypted on Google messages. The RCS spec also includes end to end encryption. There is no RCS proxy and RCS is handled by google messages. No other client for it exists at this time. The location data provided by SUPL is not given to apps, it is used for OS location that can be reported to apps. An app must have the location permission to have location data provided by the OS.

Re: Android Developer Verification: Threat masquerading as protection

#603

Earlier quoted context omitted.

You seem to be greatly misunderstanding what is actually happening. You are conflating default OS domains with google play services. Google play services is not bundled or installed by default, and is not given any kind of privileged access when it is installed. It does not handle OS domains or functionality, and GrapheneOS does not proxy its connections in any way. As for the default domains of the OS, most are to G…

[flagged]

> every app installed is known to the proxy since each app has a unqiue key

No such proxy exists in GrapheneOS. GrapheneOS does not intercept or proxy connections made by Google apps or other apps.

GrapheneOS doesn't include Google Mobile Services. Sandboxed Google Play is not part of GrapheneOS. Users can choose to install Google Play services, Google Play Store and other Google apps on GrapheneOS. Unlike a standard GMS Android device, those are installed as regular sandboxed apps with no special access. The feature provided by GrapheneOS is a compatibility layer coercing those to run as regular sandboxed apps if installed by users. It doesn't involve intercepting or proxying any connections.

> location data is proxied

Location request rerouting is an entirely local feature of the sandboxed Google Play compatibility layer. By default, it replaces the Google Play location library used by many apps with another implementation using the local OS location service instead of the local Google Play location service. This isn't intercepting or proxying connections.

Google Play has an optional network-based location service that's opt-out for a GMS Android OS although it's opt-in for sandboxed Google Play and people would also need to grant the required permissions to Play services which aren't normally needed.

GrapheneOS has an opt-in network-based location using Apple's service either directly or via a proxy. We'll also eventually have our own service with offline database download support as another option. We have to build our own database to use for this first.

You're misunderstand what location request rerouting means. It reroutes apps which normally request location from Play services to ask the regular Android location API for it instead. This doesn't involve servers other than optional network-based location for apps which support using the network or fused providers. Network-based location is opt-in for GrapheneOS.

> They mention no proxy of RCS data, but in theory, an RCS message requires location data. So, the proxy knows when a message is sent and received, at a minimum.

GrapheneOS doesn't proxy things in the way you claim in the first place. It doesn't proxy any connections involving carriers and doesn't proxy any connections made by Google apps. It doesn't come with Google apps and those would need to be installed by users.

> So, based purely on the FAQ, if you use the sandboxed services and enable RCS, Graphene knows every app you install and has your location data, but they erase it after a couple of weeks.

This is all completely untrue. GrapheneOS doesn't include with sandboxed Google Play. Sandboxed Google Play compatibility doesn't make any connections to GrapheneOS servers. It doesn't proxy anything through our servers. RCS via Google Messages doesn't involve our servers either.

You're misunderstanding our approach to all of these things. Location request rerouting means replacing the local Play services location API for apps using it with the OS location API. That means asking the OS for location rather than Play services. That isn't a connection to a server. It means that by default, apps using the Play services location SDK will work without Play services needing to be granted Location access based on the OS satellite-based location. If users enable network-based location for the OS location service then it will work for apps normally using the Google Play network or fused location providers. It's an entirely local compatibility layer as with the whole rest of it. Sandboxed Google Play compatibility layer has 0 connections to our servers and there's no reason it would need to connect to our servers.

Re: Android Developer Verification: Threat masquerading as protection

#604

Earlier quoted context omitted.

Was this comment made by an LLM? i dont know anyone who drops "blast radius" in casual conversation besides claude.

People in security space use it all the time.

for CVE's, maybe.

Re: Android Developer Verification: Threat masquerading as protection

#605
post #566

It doesn't solve the current issue, but in case we don't manage to push back on this, some people might not know that there are various actual linux OSes for mobile: - SailfishOS: still linux based and seems fairly community inclusive, but the UI part of the stack is closed source. Is the only one officially allowed to run android apps, via emulation. Has existed for a very long time, it's lightweight and I think the…

Usability-wise, they are no match for Android and iOS—or even versions of them from five years ago. UI/UX is costly, and most FOSS projects cannot get it right without massive investments from enterprises (e.g., Red Hat's UX designers heavily contributed to GNOME) or startups (e.g., Zed, Element, Bluesky). Projects without that backing are mostly unusable, at least from a Gen Z perspective.

FWIW, I use my smartphone as an MP3 player, SMS messenger and TOTP auth. iOS and Android did that fine 5 years ago, I don't need Instagram or 8 Ball Pool to survive in life.

Re: Android Developer Verification: Threat masquerading as protection

#606

Earlier quoted context omitted.

Root access takes agency away from you and gives it to 3rd party software. It doesnt expand freedom at all, it just allows other software to abuse the user. With a proper security model and verified boot, you can be certain you, the user, are running exactly the OS you expect to run. You can also properly revoke permissions to software and gate access as you see fit. With root, you cannot guarantee you are running wh…

I just don't get why we need to argue about something — the right to general purpose computing — which has been answered decades ago? The user must be the administrator of their own device. Whether that's a laptop, desktop, PDA, mp3-player, smartphone, tablet, cyberdeck, netbook, or any other kind of computing device. The user must be able to overrule any and all decisions. That's the definition of ownership . Like,…

Being the administrator and being able to sidestep OS protections are not the same thing. Without root, the user is in control of what application does what and how. With root, the user is not. Root is not freedom or ownership, like many try to claim. Root is a hacky shortcut to proper functionality. You can build and sign the OS with your own keys, without undermining the security of your device, and adding whatever functionality you want with the principle of least privilege.

Its really funny because Tron, or at least Tron Legacy, is a great example of why godhood is dangerous and why a user and a program having root access is catastrophic.

Re: Android Developer Verification: Threat masquerading as protection

#607
post #437

Earlier quoted context omitted.

>> Google’s Android—and [Open Handset Alliance] members are contractually prohibited from building non-Google approved devices >So to compete you'd have to create a compatible Google Play Services as well as find a supporting manufacturer. Samsung managed their own competing apps and store [2] for a while along with Tizen, likely for leverage or theoretical pivot. But has since dropped that effort. What's wrong with…

It's a nice effort, but without preinstalls you aren't going to capture the market except for the tiny percentage of enthusiasts which are maybe a fraction of a percent of the market. Google needs to experience real competitive pressure, and you need preinstalls for that. Same story for year of the Linux desktop. It's doomed to 5% or less of market share without preinstalls (which Valve & the various other PCs now re…

> without preinstalls

GrapheneOS has an official partnership with Motorola Mobility which is improving their next generation devices to meet our requirements and helping us port GrapheneOS to those. GrapheneOS will be officially supported on those devices with Motorola Mobility providing us with the stripped down hardware support code we need to support their devices with proper firmware/driver/HAL updates.

A bunch of companies are already selling devices with GrapheneOS installed. Those companies can start buying the future Motorola devices supported by GrapheneOS and doing the same thing with those which they already do with Pixels. Motorola can also specifically sell devices to other companies to sell with GrapheneOS with official support from Motorola.

> prohibiting OEMs from making or partnering with "non Google approved" OSes

It has been challenged in court and ruled to be illegal in South Korea and elsewhere. Regardless, it's only an inconvenience and can be worked around. Even if Motorola can't sell devices with GrapheneOS in many countries themselves, those can still be sold by other companies and Motorola can sell devices to those companies at wholesale rates where they can match the price of the non-GrapheneOS devices. Other than Google, most OEMs aren't directly selling most of their devices anyway.

Re: Android Developer Verification: Threat masquerading as protection

#609

Earlier quoted context omitted.

[flagged]

> every app installed is known to the proxy since each app has a unqiue key GrapheneOSs proxies do not collect and send any "unique keys" from apps. That is made up. > They mention no proxy of RCS data, but in theory, an RCS message requires location data. So, the proxy knows when a message is sent and received, at a minimum. They dont mention a proxy of RCS data because there isnt one. RCS messages do not require lo…

[deleted]
Post reply on HN