If Google Play services is listed as a requirement, that implies that a "certified Android" device capable of Play Integrity attestation is required, since that's the only officially supported way to obtain Google Play services. On consumer-facing support articles like this, they don't tend to get into the nitty gritty details like what APIs are being used. If MEETS_DEVICE_INTEGRITY is required, that would probably not be explicitly listed here.
(Yes, if you go deep into the FAQ at the end it eventually states that if you rooted your phone, you can't use tap to pay, but that requirement is implied by the certification requirement [1].)
In Google's eyes, and in the eyes of the law due to trademarks filed by Google, Android == Google Android.
This feature would make little sense if it's not using device attestation because otherwise it would be easy to spoof. I expect that it will initially not use it, and they will start A/B testing device attestation in the coming years.
it's boiling the frog method. Moving too fast means backlash, but a slow, step by step transition where each step seems reasonable, but ultimately end up with a locked down device, is how they aim to achieve it. And people would be too lazy to complain until the last few steps, by which time it would be too late.
Good metaphor. On the one hand, Google increasingly cooperates and makes deals with militaries and governments. On the other hand, it increasingly locks down its customers and eliminates their privacy and freedoms.
Google has just about got the pot boiling. They win, we lose.
Not really - i would prefer that any policy change that _could_ be utilized in the future to enable future draconian changes be killed before it takes root.
I want a system, like type safety, to guarantee that XYZ cannot be possible, rather than rely on civil jurisprudence and active opposition to prevent it. We don't have that today, but i like to have it.
>that implies that a "certified Android" device capable of Play Integrity attestation is required
No, it doesn't. It implies that the app for handling the deeplink lives within GMS as opposed to needing to manually install a separate app like you do on iOS. GMS does not have a hard dependency on device integrity APIs being supported.
They said "capable of Play Integrity attestation". It's a weasel statement. If you have GMS, you're capable of performing PIA attestation, you just might fail. So it's strictly true, but doesn't tell us anything about whether it requires PIA.
No, they were correct in their understanding of what I meant. I should've said "capable of passing Play Integrity's device attestation checks". I replied to them with more context.
It indeed runs on modified versions of Android, but this is not supported by Google and never has been.
When Apple says "Apple Pay is supported on iOS >= $VERSION" they don't explicitly mention that it won't work on jailbroken iPhones, because they don't expect you to make modifications to your device and then try and use their services as normal. This is unsupported and discouraged, just like trying to manually install Google Play services on an OS that didn't ship with it.
The only way to get Google Mobile Services officially is to buy an Android device with it pre-installed while leaving the stock OS untouched. And the only way for an OEM to ship GMS with their device is to certify it with Google. And one of the requirements for certification is to use device attestation keys signed by the Google Hardware Attestation Root certificate [1], thus Play Integrity will pass on all such devices.
Legacy is pre-bedrock and it’s NOT decompiled; some consider it to be the “last good” version of Minecraft that wasn’t Java - and perhaps could be used to do something interesting on non-jvm platforms.
Decompiled code is great, but having access to the “real” code gives you more insight into design decisions and directions.
Sure, my wording isn't perfect. I don't have a watertight definition ready to go. To my mind the spirit of the thing is that (for example) if a site has an http endpoint that accepts arbitrary sql queries and blindly runs them then sending your own custom query doesn't qualify as an exploit any more than scraping publicly accessible pages does. Whereas if you have to cleverly craft an sql query in a way that exploits string escapes in order to work around the restrictions that the backend has in place then that's technically an exploit (although it's an incredibly minor one against a piece of software whose developer has put on a display of utter incompetence).
The point isn't my precise wording but the underlying concept that making use of freely provided information isn't exploiting anything even if both the user and the developer are unhappy about the end result. Security boundaries are not defined post hoc by regret.
Most tech businesses exist because problems exist. Tailscale delivers a solution that's available today. The only alternative is to sit and wait for IPv6. I don't imagine Tailscale is against IPv6 any more than security professionals are against memory-safe programming languages.
Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.
There are not "exceptions"; there is one exception, and that's educational apps. But it's unclear why Pythonista is educational while the apps mentioned in the article are not. In fact, Pythonista is even listed in the "Productivity" section in the App Store.
Apple's own Swift Playground app does the exact thing that supposedly violates the rules, abusing an inconsistently-applied exception for "educational" apps [1].
Recent regulation doesn't help here, by the way. iOS apps submitted for "notarization" to be distributed in alternative app stores in the EU, Japan, etc. still must comply with a subset of the guidelines, including 2.5.2. EU is probably not interested in strengthening the DMA so that Apple doesn't have to approve everything because then it makes other EU regulations easier to bypass (e.g. Chat Control).
The "educational" exception is definitely a convenient loophole, but it raises questions about consistency and fairness in how these rules are enforced across the board
But do they do it whether you're logged in or not?
I noticed the ChatGPT app also checks Play Integrity on Android (because GrapheneOS snitches on apps when they do this), probably for the same reason. Claude's app doesn't, by the way, but it also requires a login.
You don't need a phone number to create a google account. (Though the account creation flow is inconsistent in this, in sone situations it will require a phone number, in some it won't.)
Proceeds to explain why your opinion is not "fine" but rather invalid, because Apple boiled you like a frog...
Every time someone mentions here that they're concerned macOS is becoming more like iOS, Apple apologists show up to explain how that's not actually happening. I guess now you guys have just accepted it.
> While sadly, it doesn’t look like there will be any ADB command you can send to your phone to make it immediately jump to the end of that 24-hour delay
There's also no evidence that adb-sideloaded app stores will be able to skip PackageInstaller's developer verification enforcement, so no, you will have to wait 24 hours to install F-Droid and actually use it.
Wasn't most of the hype surrounding the Motorola partnership based on the idea that you'd be able to get a device with GrapheneOS pre-installed, boosting the legitimacy of GrapheneOS as a competitor to Google Android? Sure, "GrapheneOS adds several more supported devices" is cool and all, but it's not nearly as exciting...
No. The bare minimum is that Motorola provides the needed baseline hardware security requirements to their future devices. Everything else is just a bonus. There could be green-boot support and/or preinstalled devices, but thats not a necessity. GOS benefits with an official hardware platform, potentially early partner access to AOSP source code, input on hardware and firmware decisions, and Motorola benefits by potentially having GOS features, better hardware security, and making tons of money from alternate OS users, GOS or otherwise.
If Google Play services is listed as a requirement, that implies that a "certified Android" device capable of Play Integrity attestation is required, since that's the only officially supported way to obtain Google Play services. On consumer-facing support articles like this, they don't tend to get into the nitty gritty details like what APIs are being used. If MEETS_DEVICE_INTEGRITY is required, that would probably not be explicitly listed here.
E.g. the consumer documentation for Google Pay just says you need a "certified" Android device and a screen lock set up: https://support.google.com/wallet/answer/12200245
(Yes, if you go deep into the FAQ at the end it eventually states that if you rooted your phone, you can't use tap to pay, but that requirement is implied by the certification requirement [1].)
In Google's eyes, and in the eyes of the law due to trademarks filed by Google, Android == Google Android.
This feature would make little sense if it's not using device attestation because otherwise it would be easy to spoof. I expect that it will initially not use it, and they will start A/B testing device attestation in the coming years.
[1] Expand "What to do if you see device is not certified" -> "Reset device to fix issue" https://support.google.com/android/answer/7165974
reply