Brice Person 🇺🇦 @[email protected]

Le chant "Maréchal nous voilà" à la gloire de Philippe Pétain a été diffusé à Carpentras le jour du 8-Mai. Le maire RN de la ville renvoie la faute sur un prestataire extérieur et a annoncé vouloir porter plainte. #JT13h

The ICE agent who fatally shot Renee Nicole Good has been quietly relocated to a different state and allowed to resume work. thedailybeast.com/ice-agent-jona…

The @EU_Commission has released an update to patch out the issues I raised last week, v2026.04-2 (#release-notes_1" target="_blank" rel="nofollow noopener">ageverification.dev/releases/#rele…) Honestly, I don't know if I should laugh or cry. Let's review each one: 1. On-device data: database and settings encrypted at rest, with keys protected by the device’s hardware-backed key store. Sounds great, until you look closer. They introduced androidx.security:security-crypto, deprecated in 2025. Also androidx.security.crypto.EncryptedSharedPreferences, deprecated in 2025. Finally, androidx.security.crypto.MasterKeys, which were deprecated in 2020. 3 deprecated dependencies introduced following criticism over weak security. These weren't left over and missed during an update... they've added them now to "harden security". Remember, this isn't an isolated app. It's intended to lay the foundation for many production applications; all using deprecated security libraries from the outset. Worse, they already correctly use KeystoreController in their codebase. The correct answer already existed and they still got it wrong. 2. Runtime: the app checks device integrity on startup and refuses to run on rooted or jailbroken devices. Production deployments should complement it with stronger device-attestation mechanisms appropriate to their infrastructure and compliance requirements. They check for su, check package manager for root apps, run "which su" and checks if it's a custom ROM. Paths: /system/bin/su /system/xbin/su /sbin/su /system/su /data/local/su /data/local/bin/su /data/local/xbin/su /system/app/Superuser.apk /system/app/SuperSU.apk Great... in 2015. These are all trivially bypassed in 2026. 3. Passport onboarding: more stable scanning; the passport photo is stored privately and deleted as soon as it’s no longer needed. They're still not encrypted, so I'm not sure what "privately" means - but they are deleted correctly now. 4. PIN: stricter rules block easy-to-guess PINs; PINs are salted and hashed, never stored in plain form. They salt correctly (a true CSPRNG), then use PBKDF2-SHA256 - which is outdated and only recommended where FIPS compliance is required, which doesn't apply here. To make matters worse, they use just 210,000 iterations. For those of a NISTy disposition, you're likely already shaking your head. 210,000 seems oddly specific. It is. It's the @owasp minimum for PBKDF2-SHA512, not SHA256. Right number, wrong algorithm. In reality, OWASP recommended 600,000 iterations as a minimum in 2023. Worse still, 600,000 is the baseline minimum for passwords, not PINs with 1 million permutations. You could use 1B iterations, you're not measurably increasing security when there are so few attempts required to break it. At the very least, use a modern hash with reasonable brute-force resistance against a 2026 threat model. All this... cited as a "first hardening step". Again, utter security theatre. None of this negates my fundamental point. This isn't fixable through code - it's fundamentally ill-conceived and poorly implemented.

.@vonderleyen "The European #AgeVerification app is technically ready. It respects the highest privacy standards in the world. It's open-source, so anyone can check the code..." I did. It didn't take long to find what looks like a serious #privacy issue. The app goes to great lengths to protect the AV data AFTER collection (is_over_18: true is AES-GCM'd); it does so pretty well. But, the source image used to collect that data is written to disk without encryption and not deleted correctly. For NFC biometric data: It pulls DG2 and writes a lossless PNG to the filesystem. It's only deleted on success. If it fails for any reason (user clicks back, scan fails & retries, app crashes etc), the full biometric image remains on the device in cache. This is protected with CE keys at the Android level, but the app makes no attempt to encrypt/protect them. For selfie pictures: Different scenario. These images are written to external storage in lossless PNG format, but they're never deleted. Not a cache... long-term storage. These are protected with DE keys at the Android level, but again, the app makes no attempt to encrypt/protect them. This is akin to taking a picture of your passport/government ID using the camera app and keeping it just in case. You can encrypt data taken from it until you're blue in the face... leaving the original image on disk is crazy & unnecessary. From a #GDPR standpoint: Biometric data collected is special category data. If there's no lawful basis to retain it after processing, that's potentially a material breach. youtube.com/watch?v=4VRRri…