OK, lets keep it to the bare technical facts since I won't convince you on anything else:
allowBackup is not disabled.
The element in AndroidManifest.xml does not set android:allowBackup="false" or define android:dataExtractionRules. Auditor's SharedPreferences containing all Auditor-role pairing data are included in Google cloud backup by default. This data includes pinned public keys, verified boot key hashes, device fingerprints, OS/patch versions, and verification timestamps for every paired Auditee.
This data could be backed up to an auditor's Google account, especially in the case of the Play Store variant on a stock Pixel. Even if you discount the other attack paths I defined.
Now let's look at practical risk.
There is data exposure at rest in Google's infrastructure. The pairing data uniquely identifies physical devices, their OS versions, patch levels, and verification history. This data now sits in Google's cloud backup infrastructure tied to the user's Google account. Anyone with access to that account (the user themselves may not even realize this data is there) has access to a structured inventory of every device the Auditor has verified.
The fix is one manifest attribute and an XML resource. This isn't a design change or a protocol modification. It's android:allowBackup="false" and a dataExtractionRules XML. Google's own https://developer.android.com/privacy-and-security/risks/backup-best-practices recommends exactly this for apps handling sensitive data.
You would reject a trivial fix because you think the data was AI written? If you take just the facts above - absent the theoretical risks outlined requiring 'hyberbolic' situations in the previous PR - isn't that enough to consider a tiny adjustment?
OK, lets keep it to the bare technical facts since I won't convince you on anything else:
allowBackup is not disabled.
The element in AndroidManifest.xml does not set android:allowBackup="false" or define android:dataExtractionRules. Auditor's SharedPreferences containing all Auditor-role pairing data are included in Google cloud backup by default. This data includes pinned public keys, verified boot key hashes, device fingerprints, OS/patch versions, and verification timestamps for every paired Auditee.
This data could be backed up to an auditor's Google account, especially in the case of the Play Store variant on a stock Pixel. Even if you discount the other attack paths I defined.
Now let's look at practical risk.
There is data exposure at rest in Google's infrastructure. The pairing data uniquely identifies physical devices, their OS versions, patch levels, and verification history. This data now sits in Google's cloud backup infrastructure tied to the user's Google account. Anyone with access to that account (the user themselves may not even realize this data is there) has access to a structured inventory of every device the Auditor has verified.
The fix is one manifest attribute and an XML resource. This isn't a design change or a protocol modification. It's android:allowBackup="false" and a dataExtractionRules XML. Google's own https://developer.android.com/privacy-and-security/risks/backup-best-practices recommends exactly this for apps handling sensitive data.
You would reject a trivial fix because you think the data was AI written? If you take just the facts above - absent the theoretical risks outlined requiring 'hyberbolic' situations in the previous PR - isn't that enough to consider a tiny adjustment?