6 ms·
The title is misleading. App attestation does not require an Apple account nor a google account. For Android, it does limit the ROMs to Google certified ones a
by AppAttestationz 6mo ago
The title is misleading.
App attestation does not require an Apple account nor a google account. For Android, it does limit the ROMs to Google certified ones and requires GMS to be installed if Play Integrity is used. An alternative option, would be to use the Hardware Attestation API directly, GrapheneOS would be thanking you.
I've spent a good amount of time implementing exactly this type of system for a backup service.
his document specifies a way to cryptographically attest the integrity of a HTTP request hitting a server.
The attestation proves the request came from a device and attest the legitimacy of the bootloader, OS and app.
Google and Apple are in a privileged position to be able to bypass the app attestation though, so depending on the threat model, it's not bulletproof.
edit: Play Integrity could the worst offender here, as it can be leveraged to force a user to have installed the app through the Play Store. Indirectly, requiring a Google account.
- bossyTeacher 6mo ago> App attestation does not require an Apple account nor a google account. For Android, it does limit the ROMs to Google certified ones and requires GMS to be installed. To me, there is no difference between your sentences. You require the blessing of an American company to be able use eIDAS. Google has the power to disable eIDAS at a national scale by making the attestation services treat all devices as not certified. There should be NO reliance whatsoever on a private company not under the control (direct or indirect) of the government let alone a foreign private company. Edit: I just noticed your username and the fact that your account is very new. Are you astroturfing?
- AppAttestationz 6mo agoI agree, there is still a reliance on the tech giants that produce the phones, who are the o'es embedding the cryptographic keys, to make this end to end attestation work. But in pure technical & UX terms, you don't need to be logged in.
- bossyTeacher 6mo ago[flagged]
- AppAttestationz 6mo agoYour whole point is orthogonal to what I said too. I said the title is misleading, which it is. Your argument that app attestation should be avoided because big tech company can withhold it is garbage. It holds no water. They can cut off access to the app in general by removing it from the app stores and the devices that have it installed. American big tech has Europe in a stranglehold, I agree with your sentiment there. eIDAS can be used with the ID reader on Linux even, there's no lock out. They want to offer a convenient alternative for the normies, in a secure manner, I don't mind. Edit: my 70 y/o mother even eIDAS authenticates (not germany, other EU country) on Linux Mint. There's no argument for lockout in my anecdotal perspective.
- lucb1e 6mo agoHow are you expecting someone here to complete a captcha in the comments?
- deleted 6mo ago[deleted]
- AppAttestationz 6mo agoI made an account because I'm qualified to talk about this topic :-) I've spent a considerable time testing every corner case of UX, and DX of an app attested service. App attestation can fail on simulators, Graphene OS, dev builds, I've seen it all. There is one check you can do to see if an app was side loaded, so indirectly, can require Google account. Title is still misleading though, as it explicitly mentions accounts.
- whatsupdog 6mo agoCome September, there will be no side loaded apps on Android.
- gnabgib 6mo agoYou're behind on your news! Google details new 24-hour process to sideload unverified Android apps (1196 points, 16 days ago, 1262 comments) https://news.ycombinator.com/item?id=47442690 https://news.ycombinator.com/item?id=47442690
- dugite-code 6mo agoFunctionaly it's dubious if this will not cause further issues. Developer tools cause some security checks to fail. It's not yet known if the unknown apps setting will do the same
- whatsupdog 6mo agoStop shilling Google. It's not the same thing. It will stop 99% users from jumping through all the hoops, exactly what Google wants.
- seba_dos1 6mo agoThere's no such thing as "legitimacy of the bootloader, OS" that can be verified by someone who isn't the device's user. The bootloader that booted the phone I type this on is patched by me, which makes it more "legitimate" than any other bootloader that could be placed there.
- AppAttestationz 6mo agoYou can bicker about the words all day long. Legitimacy, or perhaps better: authenticity, in this context, would be a bootloader or OS that doesn't allow tampering with the execution of an app.
- seba_dos1 6mo agoAny bootloader or OS that doesn't allow the user to tamper with it or the other tools they're using on it is obviously illegitimate malware.
- AppAttestationz 6mo agoIt's a funny comment, because actual malware, very much loves to tamper with the bootloader and OS. Which was the motivation for cryptographically attesting the boot process and OS, and in part paved the way for app attestation. There are alternatives though: The Android Hardware Attestation API enables attestation on custom ROMs, but the attestation verifier needs a list of hashes for all "acceptable" ROMs. GrapheneOS publishes these but there's nobody, to my knowledge, maintaining a community list.
- seba_dos1 6mo agoNothing funny in it, I'm afraid. Socially accepted malware is still malware. Caffeine is a stimulant, alcohol is a drug, a piece of software that works against the user is a malware. Cryptographic attestation is not a problem in itself, the problem is exactly what you already somewhat hinted at: it's who and how decides who to trust and who gets to make (or delegate) the choices. You can make a secure system that lets the user be in charge, but these systems we're discussing here don't (and that's by design; they're made to protect "apps", not users).