Live data from Hacker News

A big win for Android interoperability

openhomefoundation.org

101–110 of 194 posts

Re: A big win for Android interoperability

#101
post #50

Earlier quoted context omitted.

Why would anyone who cares enough about security/privacy to run a de-googled phone want to use a tap to pay app?

People use alternatives for many different reasons (or multiple at the same time): - They might want privacy from Google. Using Google Pay probably doesn't make much sense. - Security protection against Google. Google can remotely brick devices with unsandboxed Play Services. After blocking of ICC officials and all the Greenland threats, it's not odd that some European citizens would like to block this Google/US gove…

Minor note, you forgot battery life. Pinging your location every other minute for traffic and crowd denisty for Google Maps, even using AGPS, isn't cheap.

When you find battery life randomly tanks for a few days, despite not changing anything in your life, it's always Google Play Services that end up being the culprit

Re: A big win for Android interoperability

#102
post #39

Earlier quoted context omitted.

Indeed. This ruling seems to be targeted at AI specifically. It is a great ruling, because it allows proper competition of other assistants with Google's (and Bixby). However, IMO the bigger evil is all the anti-competitive stuff that make it impossible for competitors to Android/iOS to enter the market, including European products like SailfishOS, such as remote attestation and the things that flow from it (e.g. no…

I agree that attestation is the biggest deal. My current hope is that the upcoming GrapheneOS phones will be able to achieve that. It's really up to a manufacturer being able to strong-arm third-parties - banks and such - into accepting their chain of trust, and Motorola may be able to do that.

GrapheneOS doesn't solve the attestation problem though. If you compile it from source, the attestation still breaks (namely, you have to convince vendors that use attestation to trust your key). In practice, it does not allow you to run your code on your device anymore than stock Android with Google services does. At best, if GrapheneOS' build is reproducible, you can view the source code online and know that there isn't anything else in the blob you load onto your device

Source-available isn't quite the same as having the software freedoms (use, study, modify, share) where you can modify the code or inspect what the various third-party apps are doing on your device. I can currently look into /data/data/any_app and modify preferences, view what telemetry is queued up, remove gigabytes of cache files... all that goes away with a GrapheneOS installation that passes attestation. They want to appear legitimate to app vendors and so comply with Google's rules about what data is accessible to users; otherwise, they'd never convince anyone to add their attestation keys to the allowlist. You need to be on a closed device before those vendors put you on the allow list (and you probably need to sell at least a million devices before they bother to consider you). The concept of attesting your phone is fundamentally antithetical to open source

Re: A big win for Android interoperability

#103
post #50

Earlier quoted context omitted.

Why would anyone who cares enough about security/privacy to run a de-googled phone want to use a tap to pay app?

People use alternatives for many different reasons (or multiple at the same time): - They might want privacy from Google. Using Google Pay probably doesn't make much sense. - Security protection against Google. Google can remotely brick devices with unsandboxed Play Services. After blocking of ICC officials and all the Greenland threats, it's not odd that some European citizens would like to block this Google/US gove…

Is this an AI response? I get why people want a de-googled phone. What I don't get is why they would want to use tap to pay, one of the payment methods with increased attack vectors.

Re: A big win for Android interoperability

#104
post #45

Earlier quoted context omitted.

You have to negotiate directly with Visa to convince them why they should accept your system. How will you convince them?

so what you're saying is we should be looking at competitors of Visa

MasterCard has the exact same issue.

Re: A big win for Android interoperability

#105
post #64

Earlier quoted context omitted.

Because it’s convenient?

I agree, it's very convenient to have a phone full of corporate malware. But I thought the point of GrapheneOS was to escape that. My corporate malware only runs on my secure card processor which sits in a pocket glued to my phone.

But I thought the point of GrapheneOS was to escape that.

I think the point of GrapheneOS is being as secure as possible first and within those parameters give people the choice how much of Google they want. They have implemented sandboxed Google Play Services for a reason. Many people need Play Services for practical reasons (e.g. because they need to run apps that require it), so let's then run it in the most secure/private way possible - make it a sandboxed app, allowing users to decide whether to install it or not and if they choose to, that they can assign/revoke permissions like any other Android app.

Re: A big win for Android interoperability

#106

What a shame. How much time and €M spent just to deign allow you to do some very specific stuff on their devices (in 5 years at least once the trials and shenanigans settle) ? Obviously it doesn't include the "answering call screening" for example, which requires very privileged APIs accessible only by "system" apps, i.e. the ones preinstalled in the ROM. How about RCS ? Remember RCS the "open" standard replacing SMS…

RCS is partially open. The protocol is public, as are one or two authentication features. The biggest restriction for custom RCS implementations is that carriers often require access to SIM card functionality to authenticate a phone to their IMS. Only system software (your OS vendor, Google, maybe additional libraries like Facebook in some products) can access those. Unlike SMS, there is no simple "send this string to the modem and you've sent a message" communication method. The entire thing is SIP+RTP+a few other protocols, wrapped up in a brandable package. RCS is as open as SMS has been for a while, perhaps even more open as the SMS stack can only be reliably implemented in IP-only software stacks in LTE+ networks; 3G and below require integrations not even the Android system supports natively.

If you run a custom ROM, you can sign your own RCS app and have no such restrictions, of course. The same is true for devices with root access. There's nothing preventing anyone from writing a fully featured RCS client or library for custom ROMs, except maybe carriers filtering out unofficial ROMs, but those are a SIM card swap away. Nobody seems to have started working on an RCS app for those platforms yet. There are a few open source libraries out there, but they don't see much activity, and none of them implement the full RCS suite (which includes video calling and even exchanging money).

When people complain about RCS being closed off, most of them don't care about the RCS protocol. They want Google's libraries to handle all the hard work for them and provide an API to interact with without having to implement the carrier protocol side. RCS is already open, but they want Google Messages to be open, not RCS.

However, the EU's laws regarding gatekeepers require that a significant amount of people actually use the supposedly gatekept platform. Very few people within the EU use RCS. I don't think RCS is even close to being relevant for the EU's gatekeeper regulations. The only people talking about RCS on the European market are companies trying to peddle their RCS marketing spam delivery mechanism to other companies.

If the USA would adopt similar laws, the situation would probably be different. Don't expect the EU to care about gatekeepers in a market consumers aren't interested in.

Re: A big win for Android interoperability

#107
post #21

This is all smoke and mirrors. The core issue is not "Google not allowing a feature", it's that small businesses cannot buy phones, install a patched version of Android without a restriction and sell them to make money. Until this problem is solved, everything else is palliative.

Who wants a bootleg Android that sends all your call logs who knows where? xD

Everyone who buys an Android phone. This is about the opposite, an option to buy a phone that does not do that.

Re: A big win for Android interoperability

#108

Earlier quoted context omitted.

People use alternatives for many different reasons (or multiple at the same time): - They might want privacy from Google. Using Google Pay probably doesn't make much sense. - Security protection against Google. Google can remotely brick devices with unsandboxed Play Services. After blocking of ICC officials and all the Greenland threats, it's not odd that some European citizens would like to block this Google/US gove…

Is this an AI response? I get why people want a de-googled phone. What I don't get is why they would want to use tap to pay, one of the payment methods with increased attack vectors.

Is this an AI response?

No.

I hate AI writing, so I never use AI for writing. Randomly throwing in accusations in discussions sucks. I don't think my comment had any of the hallmarks of AI writing either, unless bulleted lists are also not-done these days.

I guess I should be happy that people don't recognize me as a non-native speaker anymore?

Re: A big win for Android interoperability

#109
post #101

Earlier quoted context omitted.

People use alternatives for many different reasons (or multiple at the same time): - They might want privacy from Google. Using Google Pay probably doesn't make much sense. - Security protection against Google. Google can remotely brick devices with unsandboxed Play Services. After blocking of ICC officials and all the Greenland threats, it's not odd that some European citizens would like to block this Google/US gove…

Minor note, you forgot battery life. Pinging your location every other minute for traffic and crowd denisty for Google Maps, even using AGPS, isn't cheap. When you find battery life randomly tanks for a few days, despite not changing anything in your life, it's always Google Play Services that end up being the culprit

Great point! For me that was not a reason to get a phone with GrapheneOS, but definitely a noticeable/welcome side-effect.

Re: A big win for Android interoperability

#110

Now if only these rulings also covered attestation.

Android has an accessible hardware attestation API already (https://developer.android.com/privacy-and-security/security-...). It's what powers the attestation API that GrapheneOS made as an alternative to Play Integrity and friends (demo app: https://github.com/GrapheneOS/Auditor)

It's up to third party app developers to choose what library to use, of course. A court case between the EU and Google isn't going to chance anything about the verification steps apps like Netflix or your bank might use, that will have to be a separate case.

Post reply on HN