It Wallet - [Graphene OS] - Criteri di sicurezza Documenti su IO #6327
Comments
|
Mi hai preceduto di poche ore, stavo per aprire la stessa issue. Pare che il Wallet di IO utilizzi Play Integrity API per validare la sicurezza del dispositivo: https://github.com/pagopa/io-react-native-wallet/blob/master/src/wallet-instance/README.md GrapheneOS non può passare l'attestazione anche se con bootloader bloccato e senza root in quanto non allowlisted da Google sebbene sia significativamente più sicuro dell'OS stock dei Pixel e praticamente di ogni altro telefono Android. Difatti l'app non valida realmente la sicurezza ma solo che il dispositivo passi l'attestazione hardware di Play Integrity, tuttavia questa la può passare un dispositivo Android con mesi addietro di patch di sicurezza (ad esempio privilege escalation and remote code execution regolarmente corrette nei bollettini di sicurezza). Non mi pare Play Integrity o IO facciano questa valutazione. IO dovrebbe lasciar passare GrapheneOS implementando attestazione hardware con cui è pienamente compatibile, non c'è motivo per rifiutarlo sulla base di un giudizio fuorviante di Play Integrity: https://grapheneos.org/articles/attestation-compatibility-guide |
|
Corretto, il motivo mi torna, è la stessa validazione hw usata per i tanto agognati pagamenti tramite nfc che su GOS non funzionano. L'attestazione dovrebbe avvenire in altro modo e non in subordine a metodi di un fornitore privato come google. |
Dovrebbe avvenire tramite attestazione standard di Android, possibilmente verificando anche il patch level in modo che non sia un security theater con il solo scopo reale di vietare sistemi operativi alternativi. Immagino alla luce del Digital Markets Act, l'UE non apprezzerebbe l'impiego di Play Integrity API. |
Sembrerebbe ancora più forte. Google Wallet funziona se l'esito di Play Integrity include Basic + Device integrity. Io sono nella situazione per cui ho Basic + Device (ma non Strong integrity), oltre al bootloader che risulta bloccato da Key Attestation Demo. Tuttavia, IT-Wallet non funziona, dando codice di errore KEY_IS_NOT_HARDWARE_BACKED. |
Google Pay occasionalmente oscilla tra
Sì, IT-Wallet senza dubbio richiede strong integrity, o per lo meno richiede chiave basata su hardware per la quale si basano comunque sul lasciapassare di Google per averne contezza, altrimenti funzionerebbe su GrapheneOS. |
@orazioedoardo IO dovrebbe lasciar passare qualsiasi android, non solo GrapheneOS. |
In base ai README di questo repository e altri di pagoPA è chiaro che si richieda un certo livello di sicurezza dai dispositivi su cui scaricare il digital ID. Non tutti gli OS di terze parti su Android sono allo stesso livello sotto questo punto di vista, ad esempio LineageOS anche senza root richiede bootloader sbloccato il che facilita accesso fisico alla partizione dati (basta cambiare recovery per fare bruteforce del PIN senza limiti). Inoltre non supporta Verified Boot, il che rende più facile a seguito di un attacco mantenere accesso persistente sul dispositivo dopo il riavvio. Si potrebbe aprire un'altra issue per discutere e giustificare i requisiti di sicurezza del digital ID in IO (IMHO LineageOS senza root potrebbe essere più che sufficiente considerato che per lo meno rispetto all'OS stock avresti le patch di Android più recenti sebbene non del firmware). È probabile che quanto implementato oggi in IO sia dovuto a una interpretazione di vari requisiti di sicurezza in vista del wallet europeo.
Dovrebbero effettuare una valutazione olistica del dispositivo sulla base dei meriti utilizzando API standard piuttosto che tramite un gatekeeper. |
Questo dipende dal bootloader e quindi dal modello del cellulare, in alcuni (come il mio) è possibile bloccare il bootloader in seguito all'installazione della ROM. Ma effettivamente sono casi rari. Dispositivi senza GMS o con microg sono invece più comuni. |
|
LineageOS does not preserve the security model. GrapheneOS not only preserves the security mode but substantially improves security. Unlike LineageOS, GrapheneOS supports verified boot and hardware attestation which enables verifying that it's genuine GrapheneOS. See https://grapheneos.org/articles/attestation-compatibility-guide. They should implement this rather than forbidding using GrapheneOS. It will not reduce their device security checks to implement this. |
|
Play integrity è inutile in quanto facilmente bypassabile con PIF + TS. |
|
Inoltre: Un altro problema è che si rende necessario contattare i server di Google. Perché devo chiedere il permesso a Google per avere i MIEI documenti italiani sul telefono? Cosa succede se i server di Google vanno giù? Cosa succede se decidono che il telefono di persona importante x non passa più l'integrity? |
|
IO sta creando un grave disservizio agli utenti che desiderano usare sistemi operativi più sicuri senza di fatto ostacolare aggressori che possono spoofare l'attestazione di Play Integrity tramite leaks di chiavi. È inverosimile che il team di sviluppo non abbia ancora letto questa issue e le altre due/tre dove si evidenzia questo approccio problematico alla sicurezza per cui a voler pensare bene la scelta non dipende da loro. La situazione non cambierà finché la discussione rimarrà confinata qui. È necessario un approccio concertato che generi più rumore su social network con coinvolgimento di media / siti di tecnologia come avvenne per la questione traccianti e allora forse prenderanno in considerazione. |
|
La FAQ sui documenti in IO a cui si viene indirizzati in caso di errore è fuorviante: https://io.italia.it/documenti-su-io/faq/#n1_12
Chiedo quanto possa valere l'attestazione di un dispositivo che nel migliore dei casi, ergo OEM benefattore, è indietro di 3 anni e 9 mesi nelle patch di sicurezza, il che si traduce in qualche centinaio di vulnerabilità con elevata severità oltre ovviamente a mancati miglioramenti strutturali alla sicurezza apportati nelle versioni più recenti di Android.
Un dispositivo sottoposto a jailbreak o root non implica sia compromesso. Inoltre sui Google Pixel lo sblocco del bootloader e il successivo blocco con un sistema operativo aftermarket è 100% supportata, non invalida neanche la garanzia, e permette di mantenere l'integrità e la sicurezza del sistema, come avviene con GrapheneOS. Il fatto che la stragrande maggioranza degli OEM azzoppi il telefono quando si cambi OS non rende la dicitura corretta.
Depistaggio, è IO che sceglie di utilizzare Play Integrity per vietare di fatto sistemi di terze parti, non Google. |
|
Quindi..., uno si prende un Pixel per installarci GrapheneOs e poi, per essere più realista del re e primo tra i primi, non appena il sistema da il via si sbatte e si arrovella nel tentativo di installare su quel telefono e su quel sistema operativo, uno di quelli che sarà tra i primi se non il primo strumento di controllo sociale? L'acqua bolle, ma la rana continua a credere che il caldo che sente sia per colpa del cambiamento climatico. Ambo, terno, quaterna, cinquina e tombola...., per il sistema! |
|
Stesso problema vostro, ho installato Lineage 21 sul mio Poco F2 Pro. Solo che anche con STRONG INTEGRITY mi dà che il mio dispositivo non e supportato. Probabilmente guarda se il bootloader e sbloccato |
|
@M4th12 Play Integrity API is supposed to be checked on the service, not in the app. Locally spoofing it for an app checking it won't bypass it for a proper implementation. Tricking the strong integrity check requires a leaked key which they can revoke once they detect it with their fingerprinting, although they probably won't for ones only used by a single person. |
|
True, but in the meantime I found a solution using a Module called Tricky Store, now I can use all the functions without an error. (I know is not the best for security, but I don't want to have a bad experience with the stock ROM) |
|
@M4th12 Are you using a leaked key? |
|
Caro team di IO, rispetto molto il vostro lavoro e vi sono grato per l'esempio virtuoso che date a tutta la PA per la gestione del progetto in maniera aperta. Mi sento però in questo momento di dover chiedere come mai, a due settimane dall'apertura dell'issue, non sia pervenuta ancora una risposta almeno ufficiosa. Andando avanti la discussione inevitabilmente si allargherà e sarà più difficile gestire il tutto. Già adesso il discorso si è esteso prendendo in considerazione la sicurezza di varie ROM e come bypassare il controllo da voi imposto, quando il problema è uno e molto semplice: l'API che usate è sbagliata in principio. Stiamo ricevendo anche il contributo del fondatore di quella che è probabilmente la ROM Android più sicura di sempre. Capisco che abbiate avuto le vostre gatte da pelare grazie ai tuttologi che su Twitter sono arrivati ad accusarvi di gestire male il progetto senza capirne niente, capisco anche che sia faticoso gestire un progetto open contribution, questo però non giustifica una totale negligenza nella comunicazione con il pubblico rispetto ad un problema che riguarda l'identità digitale del cittadino, un argomento che a poco a poco diventerà sempre più importante. |
|
Ho segnalato sul post dedicato a it wallet di IO su linkedin le due issues (questa e #6346 ). Un'altra soluzione è spingere google (aiutati da pagopa) ad ammettere GrapheneOS nella whitelist delle play untegrity api. |
|
L'issue su traffico in chiaro sembra avere una spiegazione semplice che ho appena aggiunto. Certo per GrapheneOS sarebbe ideale se Google lo aggiungesse in allowlist di Play Integrity in modo che funzioni con ogni app che ne fa uso, tuttavia la vedo dura e non affronterebbe il problema più grande, cioè l'uso stesso dell'API. |
|
@thestinger not leaked but given from a developer |
Gli sviluppatori non hanno accesso ai keybox. È una chiave leaked di certo se passi strong integrity. Detto ciò, io ora ho un problema ancora più grande perché il mio telefono è stato rilasciato con Android 7, aggiornato fino ad Android 10, ma non supporta neanche con sistema stock la STRONG INTEGRITY di Play Integrity. Di fatto non posso usare IT Wallet, se non appunto con trucchi vari, sul mio telefono stock con Android 10 (l'attestazione hardware non era un requisito con Android 7). Ovviamente usando custom rom con versioni più recenti di Android vale lo stesso, ma il fatto che io non possa usare una funzionalità come IT Wallet su un telefono stock mi pare alquanto assurdo. |
|
@roberto-sartori-gl Strong integrity depends on hardware key attestation which was required for devices launched with Android 8 and later so your device is too old. It's worth noting that only Android 12 or later has security support so devices with earlier versions lack security patches. It's ridiculous that a device with no patches for 8 years can pass Play Integrity device integrity but yet GrapheneOS is forbidden. GrapheneOS should pass both device and strong integrity, but unfortunately Google is taking a highly anti-competitive approach and apps like this are participating it. It's clearly illegal and we're not only considering legal action against Google but also app developers. |
|
My point is that the requirement for IT Wallet is 'Android 8', which is not true. The real requirement on Android is Play Integrity (with hardware attestation). Anyway, I don't think this is the thread to discuss GrapheneOS or not GrapheneOS. There are a lot of phones which don't have GraheneOS available so discussing GrapheneOS is not the point. Even Lineage may be considered more secure on old phones compared to the stock OEM OS. |
|
This thread was created about GrapheneOS, which not only preserves the standard security model (unlike LineageOS) but substantially improves security. A device without Android 12 or later with current security patches wouldn't pass their checks if they cared at all about security rather than doing performative security with a clearly illegal anti-competitive approach to pretend they care. They should either implement https://grapheneos.org/articles/attestation-compatibility-guide as a staritng point to permitting secure alternate operating systems or remove their checks. This thread was not created about LineageOS and LineageOS genuinely does not preserve the standard security model and features so convincing them to allow it is an entirely different topic from convincing them to allow a secure OS. Their lack of forbidding clearly insecure devices without security patches is simply strong evidence that they do not actually care about security but rather want to pretend they do, but they can prove that wrong by adding a check for a patch level from the past 4 months at a bare minimum. |
It still lacks most of the privacy/security patches, Nothing secure about that, and an app which wants to permit only secure devices would be checking for a current patch level and not allowing operating systems setting a fake patch level to mislead users like LineageOS does... LineageOS is a major part of the reason for why app developers are hostile towards alternate operating systems because they wrongly believe all of them have the same awful security as LineageOS, which is wrong. The person who filed this issue filed it about GrapheneOS and bringing up an insecure hobbyist OS is just weakening the attempt at getting them to follow https://grapheneos.org/articles/attestation-compatibility-guide. |
|
@thestinger the fact that the user who opened the issue is using GrapheneOS does not mean that we should discuss GrapheneOS only. We are in the io-app repository discussing IT Wallet. If you want to discuss GrapheneOS vs Lineage, you can discuss it on the Graphene OS repositories, I assume. Like I said, I have the same issue using the stock OS from the vendor of my phone. No Lineage or custom ROM. |
|
GrapheneOS supports hardware-based attestation which can be used to verify the device is running GrapheneOS as explained in https://grapheneos.org/articles/attestation-compatibility-guide. LineageOS doesn't support this so even if they wanted to allow it, there isn't a way for them to do it within their model of wanting to check the OS based on hardware attestation. This issue is about them implementing https://grapheneos.org/articles/attestation-compatibility-guide to verify the device is running either GrapheneOS or another alternate OS preserving the security model and supporting hardware attestation. We aren't aware of any others, but they could whitelist their keys very easily after they implement this. LineageOS doesn't provide current privacy/security patches, sets an inaccurate Android security patch level which misleads users, doesn't preserve the standard privacy/security model, doesn't leverage important hardware-based security features and introduces major issues. You're also talking about a phone running the stock OS which hasn't had security patches for years. Android 12 is the oldest Android OS version with ongoing security support and if this app cared about security instead of only performative security to pretend they're doing something for perception and legal reasons it would be the minimum OS version. You're bringing up LineageOS on an issue about permitting GrapheneOS so it's you who brought up this topic. LineageOS is indeed off topic for this issue, as is using a device with the stock OS that hasn't received security patches for years. It's not what the issue was filed about and all you're distracting from getting GrapheneOS permitted as it should be via our attestation compatibility guide. |
|
If they implement what's covered in our attestation compatibility guide by using the native Android hardware attestation API to verify the device is running either the stock OS or GrapheneOS, then they can easily add other operating systems. That is the starting point for adding other operating systems. |
All of this is just "talks", no one gonna stop Google monopoly, all this talk doesnt gonna solve anything, just saving your time |
|
@MethAddicted I would refrain from posting unproductive and useless comments, if you are not interested in the discussion you can simply unsubscribe from the conversation, we don't need the 60 years old italian boomer mentality. |
I get it, many users using Samsung S24 who never rooted, or never unlocked their bootloader, are having the same 409 error, you can check it here https://eu.community.samsung.com/t5/galaxy-s23-series/app-io/td-p/11100019 and here https://forum.italia.it/t/il-tuo-dispositivo-non-supporta-documenti-su-io/43170/80, imo not only Samsung users but also the Pixel users with A15 using december patch, so it's not the API causing the issue, it's some kind of bug in the code, and devs arent doing anything. |
|
@orazioedoardo If they're required to check for device authenticity / integrity by a regular, they can use the hardware key attestation API and check for any OS that's preserving the security model. Google Play Integrity API only checks for Google saying the device licensed Google Mobile Services. It's not a security certification. We can provide an actual security certification. They need to define what the security properties are that they need and we can have it verified every year by a third party auditor. At the moment, they have not defined any security requirements to use their app and permit using it on a device with no security patches for the past decade which is very clearly not a device with very basic security intact. It's genuinely ridiculous to permit such highly insecure devices while forbidding using the most secure Android devices available which objectively stand up to exploits far better than other devices. The end result is that users are required to support devices which can be exploited by companies like Cellebrite and NSO. Governments are effectively requiring users to use their apps from devices which can be compromised with off-the-shelf commercial tools. How is that about assuring security? Here's official Cellebrite documentation showing this: https://discuss.grapheneos.org/d/14344-cellebrite-premium-july-2024-documentation We care about security from real attackers and that is what we provide. Google putting their stamp of approval on an OS because it licensed Google Mobile Services clearly does not make the device secure, and it's easy for anyone to check that a device with many years without security patches can still pass their certification check. |
|
@MethAddicted That's unrelated to this, it's an app issue not directly connected to the Play Integrity API. |
Reason for me talking here is, we already had the thread opened for that issue, they closed it today for no reason #6525 |
The reason is specified on the comment posted just before the "issue closed" service message. It's a duplicate issue and they want to use this one for future communications. |
|
@MethAddicted They closed it but it's not locked and you can still post there rather than here to explain that it's not actually a duplicate of this issue but rather a technical issue unrelated to them needing to permit other operating systems. |
This was the initial goal, which has gradually evolved, it is not fair that we with devices left behind by manufacturers with very old security patches (who have opted for lineage os or similar, which provide patches instead) do not have access to our documents, we ourselves are aware of the risks we decide to take anyway. Still better recent android with recent security patches, but with unlocked bootloader and root, than android 11 with 2021 patches. Not to mention that we are free to have our driver's license in our pocket without security systems and not in a device that while vulnerable we are very careful not to put at risk (I would understand if it were other people's documents, but it's ours) |
This is a misconception. Using LineageOS on an end-of-life device does not provide you all of the high importance privacy/security patches. It only provides the subset of the patches available via the Android Open Source Project and a tiny subset of the kernel security patches i.e. only a couple instead of thousands. An end-of-life device running LineageOS is not receiving around half of Android's High/Critical severity privacy/security patches and those are also not the only patches devices need but rather just the ones from AOSP backported by them to older releases of Android.
You're still missing half of the High/Critical severity patches with LineageOS, regardless of the fact that LineageOS sets a fake Android security patch level in a way that misleads users and downplays the insecurity of the device. LineageOS also rolls back security in many ways. It is not a secure OS regardless of device. Even on a Pixel, it lacks proper privacy/security patches and rolls back security a lot. This issue was filed about permitting a secure OS on secure devices. There's no need for them to permit the legacy extended support GrapheneOS devices which are end-of-life and insecure regardless of the fact that we continue providing the AOSP security patches. We've removed the end-of-life devices from https://grapheneos.org/articles/attestation-compatibility-guide now. |
Not a problem if i know that, and i made it.
I'm not talking about graphene, I'm talking in general, it's not up to the lazy phone manufacturer to decide when the device (which at the hardware level is in line with android reqirements, {obviously I'm not talking about phones born with andorid 5 😅}) has reached its eol A device reaches eol in a certain area when it can no longer run something related to that area, not when the original manufacturer stops producing updates. To think otherwise is to think of throwing in the garbage phones at an average of 3 years old (when they can still do a lot, especially in the hands of someone aware of the dangers) Unfortunately, we don't have devs in the world capable of bringing your same level of security to all the devices that might.
but I repeat even having so many critical flaws is still better than having even more in an older version of android (and basic patch of aosp) ( {Random numbers just to communicate the concept} having the 50 or the 40% is better than have the 10% of security) |
It’s actually OEMs’ fault. |
|
unico problema qua é aver deciso che solo i telefono che hanno fatto un accordo commerciale con google possiano accedere a un servizio pubblico. non vedo come un telefono aggiornato ma senza accordi commerciali con google sia meno sicuro di un telefono non aggiornato da anni ma "approvato" |
Most people do not understand that half of the serious discovered issues aren't being patched just because they're using an alternate OS continuing to release updates which claims to provide the latest Android security patch level but does not actually provide it.
The devices we currently support have a 7 year minimum guarantee for OS updates including security patches. They receive the latest release of Android each month with the stock OS, so they always have proper support for it. We require at least 5 years of similar quality support as the minimum for phones rather than 7 because 7 is hard to provide and we don't want to rule out non-Pixel devices which actually try to provide good security. Non-Pixel Android devices currently lack basic security features and patches required to be competitive with iPhone security. If an app actually enforced having a high level of security, they'd support only iPhones and Pixels with either the stock OS, GrapheneOS or another AOSP-based OS preserving the security model... It is silly for them to pretend devices without proper security patches are secure simply because Google's stamp of approval is provided due to it licensing Google Mobile Services. It's fake security.
It's not how security works. Once the attacker has working exploits for firmware and driver vulnerabilities, those are going to keep working for them indefinitely against those devices and continuing to apply the partial backports of AOSP patches to older Android versions or even providing the current latest Android releases won't change that those holes are left open. |
Good for you but, not everyone is you
"Most people" don't even know the meaning of custom rom and similar concepts
Yes it is obvious 😅, But even if the improvement is minimal it is worth it
So? They are not nuclear codes, they are "my" documents that "I" decide to keep in a risky way, once it enters “the orbit” of my device, it is my responsibility, I am willing to take the risk for the reasons mentioned before. Also because (in the app itself) for pay and notification (even very private ones) an okay to an alert is enough, however for documents you have to go to all these levels of security |
They're operating systems, not ROM. The term custom ROM is incorrect.
It still won't meet even bare minimum security standards.
Having recent privacy and security patches is not advanced security. It's bare minimum basic security. The vast majority of Android devices have incredibly poor security and do not hold up against very unsophisticated attacks. We aren't talking about advanced security but rather patching serious known vulnerabilities... and you do not have that on an end-of-life device running LineageOS, or even a Pixel running LineageOS... |
Still not a problem if the alternative is even lower security standards. no buying other phones is not a viable option neither environmental (which however is subjective) nor economic. (Especially I repeat, if the lack of security is caused by the laziness of the manufacturer and not by the physical faults of the device)
For those who do it knowing the risks, it remains a nonissue (especially if any damage from the attack affects only the said person) |
We're suggesting they replace the Play Integrity API with basic security standards and permit any device or OS meeting those standards regardless of whether it's rubber stamped by Google for licensing Google Mobile Services. They can decide how much security they want to have compared to compatibility. Apps enforcing basic security standards would quickly impact the Android ecosystem and result in better security support since users would need to buy devices with proper long term security support to continue using their apps. In the long term, that would be a good thing. Play Integrity API only services to help Google's business interests through reinforcing their monopolies and preventing any viable competition with them through taking away app compatibility on a case-by-case basis as app developers make the misguided decision to enforce it.
It doesn't only impact them. They get the data on their contacts, group chats, and everything else. Compromised devices are also the main source of DDoS attacks on servers which result in centralization of the internet behind services like Cloudflare. Insecure IoT, mobile and desktop devices are a major part of that. |
This is not related to the app to which this issue is related. |
|
It is directly relevant to the app. Your posts about other operating systems without basic privacy/security patches in a thread specifically about GrapheneOS are not on-topic. This thread was explicitly not about supporting anything without the standard security model intact or the current Android privacy/security patches. |
The thread starts from the title but evolves, and does not talk about the importance of security of mobile devices, but about the level of security chosen by/imposed to "pagopa" for the "It wallet" function in the "io" app (that for every other function except that it only has a warning that says about "your phone might not be secure") No one doubts that security is important, but in a world where manufacturers decide to abandon devices (intended as family not single device) that are still perfectly functional, it becomes their fault. |
This is an issue tracker, not a discussion forum. The issue was filed about permitting GrapheneOS. It can also be considered to be about permitting other aftermarket operating systems preserving the standard security model, providing proper security patches and supporting hardware attestation for verifying them. Not aware of any of those. Play Integrity API is not currently any form of security check. Strong integrity level is going to be adding a check for having security patches from 1 year ago which is a very weak security check, but it will actually be doing something soon if they use the strong integrity level rather than only the device integrity level most apps use. There's going to be a lot of pushback from people on insecure end-of-life devices if apps keep using strong so our expectation is most will downgrade to the device integrity level with no actual security checks since their goal was only ever pretend security not real security, and the strong level still won't any more than an extremely basic check for extraordinarily bad security.
Users can choose to buy a device with 7 years of solid security support rather than 2-3 years of very poor support. Manufacturers aren't providing more support because users keep buying them and don't care. A device not receiving patches for serious known vulnerabilities in the Android Security Bulletins is not something that is even at the table for discussing the most basic security checks for devices. |
Many people do not have the opportunity, for some buying devices of this level means a big economic sacrifice |
|
Buying devices with proper long term support is much cheaper in the long run. Since the support period is so long, even buying them used after a year or two still provides drastically longer support than most new Android devices. It's also much better support not just longer. You're trying to justify people being ripped off. |
100% correct, but considering the nature of this app and the economic situation related to the country of this app, the idea that the common citizen can afford such a huge expense is not really feasible. But I'd say let's end it here, we're going very off topic. |
|
So, updated my phone on Android 15 and the issue of not meeting the security has returned, after having disappeared the last week. So, yeah. The current implementation is obviously not working. Phone:
Play Integrity Check:
|
|
@thestinger I understand your point, but first, we are talking about a government app that should be available to all citizens, without any discrimination. Second, you are right, the issue was born for GrapheneOS support, but IMHO I personally think it should be extended generically, because even adding GrapheneOS to the supported OS, the problem would be solved for (maybe) 5% of those who have problems now. Third, it is clear that the current implementation is extremely buggy, because there are tons of people with recent devices, without root and with bootloader never unlocked (therefore having all the security requirements) for whom the wallet does not work (source: app reviews on the play store). Fourth, the devices you support have 7 years of guaranteed updates, ok, but most manufacturers don't go beyond 2 years. I mean, what are we talking about?!? These security checks don't work and keeping them mandatory is harmful. |
|
@BoGnY Adding support for GrapheneOS is not the same as adding support for everything else. This issue was filed about allowing GrapheneOS as part of their existing checks rather than removing the checks. It makes sense to talk about other operating systems meeting basic security requirements including being possible to verify them via hardware attestation. Turning it into a generic complaint about their device integrity checks really isn't the purpose of this issue. |
|
@sirtao That's an unrelated technical issue not caused by them using the Play Integrity API. |
and others
Salve, come da titolo non passo i requisiti minimi di sicurezza con pixel 6a.
Non uso l'os stock, ma ho installato Graphene OS proprio per ragioni di privacy e sicurezza. Non ho infatti alcun root al telefono e ho il bootloader bloccato (come la FAQ relativa suggerisce).
Android 15
GraoheneOS: build 2024102100
Grazie!
The text was updated successfully, but these errors were encountered: