Live data from Hacker News

Android Developer Verification: Threat masquerading as protection

f-droid.org

591–600 of 793 posts

Re: Android Developer Verification: Threat masquerading as protection

#591

Earlier quoted context omitted.

The irony is none of this is a problem in the US. We still have a ton of banks that you can use without a smartphone. Even my bank's app works fine on a rooted Android or GrapheneOS. Europeans are doing this to themselves.

> Europeans are doing this to themselves. I mean, tbf the situation was fine until the US transitioned to an autocracy, and the companies went full surveillance state evil, completely supporting the autocracy. Which is a relatively recent development. But sure. Most places here are working as fast as possible to decouple from any reliance on the US, and I would expect Norway to switch to the new EU digital ID system…

> US transitioned to an autocracy

this is too funny coming from a continent constantly at war with itself

Re: Android Developer Verification: Threat masquerading as protection

#592
post #546
post #344

Earlier quoted context omitted.

I see. I looked at https://play.google.com/store/apps/details?id=eu.faircode.em... and saw nothing. I can see why your address is shown if you offer something for sale. Ads, that puzzles me.

> I see. I looked at https://play.google.com/store/apps/details?id=eu.faircode.em ... and saw nothing. I can see? FairCode B.V. marcel+play@faircode.eu Anyway, ads are just a sidechannel for purchase. There is a product advertised, someone buys it and developer gets the cut from the seller of the product. This is how ads work.

Just in case they're looking in the wrong place (looks like they moved where this information was since I last looked), you have to expand it in the sidebar on the right.

Re: Android Developer Verification: Threat masquerading as protection

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

I agree that the usability is behind, as we would expect. For me mainly is about missing apps and some hardware support. But in terms of UX for example I liked using SailfishOS, although I'll admit the UI needs some getting used to.

But I prefer this to the feeling that I'm being limited on what I can do on Android/Apple, and the worry of being in a duopoly that allows the companies to worsen their products without ever fearing competition(as far as they do it in small chunks).

Re: Android Developer Verification: Threat masquerading as protection

#594

Earlier quoted context omitted.

> Also why do you need bank app on your phone? Many banks gate features like mobile check deposit behind the native app. The nearest ATM is 20 minutes away from my house, so unfortunately I consider this feature essential.

How often are you still receiving physical cheques that mobile deposit is an essential feature? I could probably count on one hand the number of cheques I've deposited or written in the past ~15 years, nor can I say I've been so desperate to access said money that I feel the need to deposit the cheque within moments of receiving it.

At least 3 times a month. I have a rental property and my tenant prefers to mail a check instead of paying extra to pay electronically. My spouse gets paid by check for dumb reasons I won't get into. I sometimes get dividends from my insurance company via check. And then several family members still prefer to use checks to pay each other back instead of Venmo or other electronic services.

I blame it on the fact that the US doesn't have a free electronic bank transfer system like the rest of the developed world.

Re: Android Developer Verification: Threat masquerading as protection

#595

Earlier quoted context omitted.

GrapheneOS is currently the blessed child. Like CyanogenMod previously. They are "permitted" to access to Google Play Services because their work hardening Android currently benefits Google. Once Google feels like there is sufficient stability and compatibility with hardened memory allocator and tagged memory (and when they can get Qualcomm to support it across their range), they will make harder, until impossible, f…

Your claims about this don't make sense. Google does not provide compatibility with GrapheneOS for Google Play services. They do not provide support for using it or fix the issues introduced in new releases. GrapheneOS doesn't license Google Mobile Services (GMS), doesn't include it in the OS and doesn't have Google certification. It isn't permitted by the Google Play Integrity API device and strong integrity levels…

Thanks for your hard work!

Re: Android Developer Verification: Threat masquerading as protection

#597

Earlier quoted context omitted.

GrapheneOS does not run anything through google services. Nowhere in the "terms" is this stated. GrapheneOS uses first party servers for all default OS connections.

[flagged]

> Graphene proxies all the Google services connection. They take over the connections that would go to Google. They then, supposedly, only forward the ones you wish.

GrapheneOS doesn't include Google Play services. Unlike LineageOS, GrapheneOS replaces all of the standard Android Open Source Project (AOSP) connections with our own servers. Also unlike LineageOS, GrapheneOS adds toggles for these connections providing a way to disable the ones which didn't already have a way to do it. See https://eylenburg.github.io/android_comparison.htm for a comparison across AOSP-based operating systems covering what's done with most of the standard AOSP connections. It doesn't cover everything such as the Certificate Transparency (CT) log list downloads added in Android 16 which are now used by default for enforcing CT for apps targeting Android 17.

> Graphene proxies what would go to Google on regular Android.

GrapheneOS doesn't include Google Play services. It has a compatibility layer enabling running Google Mobile Services apps including Google Play services and Google Play Store as regular sandboxed apps, but it doesn't come with those. Users can choose to install those in specific profiles.

> I am getting downvotes on this, but that is how their Google Play sandbox works. It is proxied on their server, not your phone. > > A non-Google copy of your Google pointed traffic is made. That is a fact. It is identifiable to you or they could not individually forward this or that. That is a fact.

GrapheneOS doesn't include sandboxed Google Play. It does not come with it. It's possible to install those apps on GrapheneOS and it provides a compatibility layer to make it work. The compatibility layer doesn't involve proxying anything to our servers.

> Extricating from Google is the answer. Not relating your RCS chats et al through a third party then to Google then to that third party and back to you.

No such thing exists in GrapheneOS. It doesn't include any Google apps and doesn't proxy any of the connections made by Google apps elsewhere if people install them.

GrapheneOS has low-level support for RCS but doesn't have an RCS app yet since the only one for Android which exists in practice anymore is Google Messages and Google apps aren't included in GrapheneOS. Google Messages can be installed by users on GrapheneOS and set as the SMS/MMS/RCS app instead of using our fork of AOSP Messaging but that's definitely not a default. We'll have our own RCS implementation in the future in our fork of AOSP MEssaging.

> They wrote an article on it a while back.

No, and it's definitely not how sandboxed Google Play works for people who choose to install it.

It sounds like you're misunderstanding what our sandboxed Google Play compatibility layer handles location requests made to Play services. For users who install sandboxed Google Play on GrapheneOS, our compatibility layer redirects apps requesting location from Play services to request it from the OS instead. This doesn't involve making any connections, it happens locally on the default. By default, only GNSS (satellite-based location) with A-GNSS (SUPL and PSDS) is used. GNSS is a receive-only system. We add toggles for configuring SUPL and PSDS with choices between GrapheneOS, Google or Off. PSDS are static database downloads covering the whole world so that's just another form of update download. We also add a toggle for opting into our network-based location implementation which uses Apple's service either directly or via a proxy. You seem to be confusing our location request redirection with intercepting connections and running those through our services which isn't what it involves at all. Our location request redirection avoids needing to grant Location access to Play services by making it use the standard Android OS location service instead as many apps already do. There's a toggle for this in case someone actually wants to use Google's location service with their network-based location instead of Apple such as if the Apple data for their area is awful.

> Graphene with Google Services is like calling up an Intel Agency and signing up to use them as your VPN.

GrapheneOS doesn't include Google Mobile Services, and our sandboxed Google Play compatibility layer doesn't work that way at all.

> Without Google Services, it is a way to degoogle a phone with an SD card slot and 3.5mm phone jack if Motorola continues on track, but I would prefer regular Lineage support than Graphene for that purpose in case the middle man aspect expands to non-Google Services apps later.

There's no such man-in-the-middle system in GrapheneOS as you claim. LineageOS does not replace the Google servers for all of the standard AOSP services as we do and doesn't provide similar settings to control all of those. GrapheneOS does not intercept/redirect Google services used by Google apps as you claim. It doesn't come with Google apps as you're describing either.

> I want straight no-google android with the chipset drivers so that calls and sms/mms messages work without Google getting a copy of every message sent and received, and I want it on phones with sd card slots and 3.5mm headphone ports.

GrapheneOS only includes support for using SMS/MMS via the carrier. There's no involvement from Google unless Google is your carrier or your carrier is using GCP to host their servers or something similar. Using Google's RCS services would require that you go out of the way to install Google Messages after first going out of the way to install sandboxed Google Play followed by setting Google Messages as your carrier-based messaging app and granting the required permissions to use RCS (Phone permission for Google Messages and Play services along with the ICC authentication toggle in the sandboxed Google Play settings).

You're talking about it as if us supporting installing these apps as regular sandboxed apps somehow makes that the default approach. That's not how any of this is supported at all. You have to go out of your way to install sandboxed Google Play or especially Google Messages. Those don't come with GrapheneOS.

GrapheneOS does not include Google Mobile Services or Google Messages. It does not intercept or proxy connections made by Google apps installed by users. None of that is part of how it works.

Re: Android Developer Verification: Threat masquerading as protection

#598

Earlier quoted context omitted.

> Google phones are surprisingly open and work well. Google takes a pro-user stance here that is extremely rare in the ecosystem, so why not support this product? Because they will pull the rug here one day too. Why on earth should we trust them to keep this approach to their hardware?

The vast majority of smartphones don't allow installing another OS. Multiple Android OEMs have been restricting or fully phasing out supporting it. Among devices which do permit it, none have provided the hardware-based security features or driver/firmware update support needed by GrapheneOS beyond Pixels. Our hardware requirements are listed here: https://grapheneos.org/faq#future-devices GrapheneOS has an official…

[flagged]

Re: Android Developer Verification: Threat masquerading as protection

#599
post #356

Earlier quoted context omitted.

I would strongly advise using your personal account to access the developer-side of the Play Store. No, these services shouldn’t all be bundled under a single account…

Missing: [not]

Indeed. I should get more sleep. Thank you!

Re: Android Developer Verification: Threat masquerading as protection

#600

All talk, no solutions from F-droid. What are they actually doing to solve it? Why not stand up their own vetting system? I'd love some technical solutions, instead this is just childish.

At this point, the only "solution" is anti-compete legislation.
Post reply on HN