some of us voluntarily mitm ourselves via cloudflare ;)
214 karma · joined December 11, 2013
The way I understand it is more like tls certs, with each country managing their own root cert.
So there's demo app in the eu-digital-identity-wallet/av-app-android-wallet-ui github repo, I believe this is what's being tested. This is obviously not an app for an end user, it looks more like a template, to be implemented / integrated on the national level.
There's also this controversial requirement for attestation / google play integrity / tpm on the device. That's not implemented in the demo app, in fact the twitter video linked in the article clearly shows security researcher launching a total commander android app with super user privileges.
IMO selling this as an "EU age verification app" by the commission is dishonest.
edit: so in the linked twitter thread, the security researcher is aware that this is demo app. So not only commission here is being dishonest...
Just curious, is it about different tools / workflow / the new thing to learn (and those are valid reasons!) or are there some technical issues with for example Winboat?
I would expect better spam detection system from GitHub. This is hardly acceptable.
They can! Singing requires either PIN or finger on the fingerprint, and signed "proof" is valid for like 60 seconds. This whole end-to-end attestation with play integrity is supposed to make setting up token-as-a-service things impractical.
> What's going to stop the government from keeping all the salts they're issuing and then mandating that site operators add the salts to their existing logs?
> How does the math say no
BBS+ signatures. Hashes you receive from the government and hashes you send to the site operator are different and not correlated.
Where I think we are not in agreement the question of "who to trust" and "for what purposes".
Are you going to trust me when I tell you that I'm over 18 if I provide you with the document signed by my cousin, Honest Ahmed?
Are you going to trust me when I show you the document signed by my government?
(this is the trick question, you don't have a choice, law says you must; there's a list of who you need to trust and for what purposes; like a certificate root store in your browser)
If I choose to share that salt, and provide my name, someone could hash all that information and compare it to the government-issued document to verify if my name really is john smith (or if my claim "I'm over 18" is valid).
If I don't, they have no way of knowing.
> no "routing through the government"
> government is the one providing the documents
I'm also lost. I mean, this is the government issued ID we are talking about, right? How are you expected to get it if not from the government? "Are you over 18" claim is part of that government issued ID.
They don't have to know which sites or when you are visiting, but they do have to issue you the document.
(To be clear, there are also other options, it doesn't have strictly to be government; for example banks around here can provide ID documents - for their clients. There's a list of who is trusted for what https://eidas.ec.europa.eu/efda/trust-services/browse/eidas/...).
> However there's obviously a reason that those are only valid for 30 days instead of indefinitely.
It's the same reason why we prefer tls certificates with short lifespans.
In theory you cannot export your private key from the device (from the secure element), so for each $2 someone would have to quickly unlock their phone, scan code via the app and so on.
You get your document with fields like "can drive", "is over 18" and so on. It's valid for some time; physical ID is valid for like 10 years and then you have to get a new document, this digital one is valid for lets say 30 days and if it expires you get a new one.
Then you present only those fields you want, when you want, without anyone talking to the government at all. All the other party needs to check is "is the document valid" and "do presented fields match the document". Like checking a tls certificate for a given domain name or purpose.
Strictly speaking there is no "routing through the government" of any information. The government just "issues a certificate" valid for X days without knowledge with whom, how or when you are using it.
you get your sd-jwt document signed once and you reuse it for like 30 days or so.
I mean, you can. It's like with TLS certificates. The standard is there. The code is there. You can issue your own.
The question is, who will trust you?
That is not true and "true zero knowledge ID check" + "age verification" with blind signatures is what's being implemented by the EU ID project.
So someone's id leaks. It happens. In EUDI there are things called "cryptographic accumulators of non-revocation proofs". If your ID leaks it goes into the accumulator. Similar to the certificate revocation lists. During check, you include claims "im over 18" and "my id is not in the accumulator".
This is included in the standard.
This is also (I can only assume) one of the reasons why EUDI wallets require play integrity / attestation / secure element on the device. So your private key won't be easily leaked and no one can steal your ID.
EUDI wallets are connected to your government issued ID. There is no "highly invasive age verification".
We are literally sending a request to our government's server to sign, with their private key, message "this john smith born on 1970-01-01 is aged over 18" + jwt iat. There are 3 claims in there. They are hashed with different salts. This all is signed by the government.
You get it with the salts. When you want to prove you are 18+ you include salt for the "is aged over 18" claim, and the signed document with all the salts and the other side can validate if the document is signed and if your claim matches the document.
No face scanning, no driver license uploading to god-knows-where, no anything.
> to obtain 30 single use, easily trackable tokens that expire after 3 months
This is the fallback mechanism. You are supposed to use bbs+ signatures that are zero knowledge, are computed on the device and so on. It is supposed to provide the "unlinkability". I don't feel competent enough to explain how those work.
> jailbreaking / "prevent tampering"
This is true. The eidas directive requires that secret material lives in a dedicated hardware / secure element. It's really not much different than what a banking app would require.
> You have to blindly trust that the tokens will not be tracked
This is not true, the law requires core apps to be opensource. Polish EUDI wallet has been even decompiled by a youtuber to compare it with sources and check if the rumors about spying are true. So you can check yourself if the app tracks you.
Also we can't have a meaningful discussion without expanding on definition of "tracking".
Can the site owner track you when you verify if you are 18+? Not really, each token is unique, there should be no correlation here.
Can the government track you? No, not alone.
Can the site owner and the government collude to track you? Yes they can! Government can track all salts for your tokens, site can collect all salts, they can compare notes. There are so called policy mitigations currently: audits and requirements for governments to remove salts from memory the moment stuff is issued.
Can they lie? Sure.
Can the site owner and the government collude to track you if you are using bbs+? No. Math says no.
Can they lie if you are using bbs+? Math says no.
There's probably a /usr/share/dbus-1/services/org.freedesktop.IBus.service file in your system and if dbus sees something that tries to talk to IBus, and IBus is not running yet, dbus will launch it for you as directed in that file. In it's own namespace unless directed otherwise.
There's an optional integration between dbus and systemd, look for SystemdService in man dbus-daemon. IBus does not set it. Perhaps it should. I don't know.
> I ran into this problem because ibus runs later than setxkbmap and undoes the keyboard settings.
that must've been pain to debug :). I can see on my system that there's a systemd user service that I could launch with `systemctl --user start org.freedesktop.IBus.session.generic.service`, maybe that would work better than on-demand via dbus in your case.
Cgroups in Linux kernel, and systemd-cgls tool should let you trace every process to a source
Different cultures, different languages, it's obvious to the locals.
https://www.php.net/manual/en/language.types.numeric-strings...
Of course, this is only my experience and codex is still very young. I really hope it becomes as capable as Claude.
There were many such cases. There is now a policy in place: https://terms.archlinux.org/docs/code-of-conduct/#arch-linux....
That's not all! Some Manjaro users learned to withhold information that they were using Manjaro and insisted that "it's archlinux", even when their own logs clearly said Manjaro.
Also, people behind Manjaro let their ssl cert expire 4 times. At one time they told their users to change their system clocks: https://archive.is/JeOLo.
Manjaro people have literally DDOSed AUR. https://gitlab.manjaro.org/applications/pamac/-/issues/1017
Would you like me to continue? I think that's enough of examples but believe me, there's more. Have you heard story about manjaro-system 20180716-1?
In both scenarios, yes. This is what dpkg database is for, it keeps info about state of each package: whatever is it installed, unpacked, configured and so on. It is required to handle interrupted update scenario, no matter if it was interrupted during package unpacking or in the configuration stage.
So far you are just describing --force-unsafe-io from dpkg. It is called unsafe because you can end up with zeroed or 0-length files long after the package has been marked as installed.
> This is what a filesystem journal does anyways.
This is incorrect. And also filesystem journal is irrelevant.
Filesystem journal protects you from interrupted writes on the disk layer. You set some flag, you write to some temporary space called journal, you set another flag, then you copy that data to your primary space, then you remove both flags. If something happens during that process you'll know and you'll be able to recover because you know in which step you were interrupted.
Without filesystem journal every power outage could result in not being able to mount the filesystem. Journal prevents that scenario. This has nothing to do with package managers, page cache or fsync.
Under Linux you do the whole write() + fsync() + rename() dance, for every file, because this is the only way you don't end up in the scenario where you've written the new file, renamed it, marked package as installed and fsynced the package manager database but the actual new file contents never left the page cache and now you have bunch of zeroes on the disk. You have to fsync(). This is semantic of the layer you are working with. No fsync(), no guarantee that data is on the disk. Even if you wrote it and closed the file hours ago. And fsynced package manager database.
> There are different requirements among different systems which is the whole point of this post.
Sorry, I was under assumption that this thread is about dpkg and fsync and your idea of "solving the problem". I just wanted to point out that, no, package managers are not "trying to be clever" and are not "stuck in the 1990s". You can't throw fsync() out of the equation, reorder bunch of steps and call this "a solution".
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_is_dpkg_so_slo...
Not the same problem, it's half-written file vs half of the files in older version.
> Which actually solves both problems.
it does not and you would have to guarantee that multiple rename operations are executed in a transaction. Which you can't. Unless you have really fancy filesystem.
> Stop trying to be clever.
It's called being correct and reliable.
and about kernel-level crashes: yes, but you see, dpkg creates a new file on the disk, makes sure it is written correctly with fsync() and then calls rename() (or something like that) to atomically replace old file with new one.
So there is never a possibility of given file being corrupt during update.
Basically, from autistic perspective, it's the non autistic people who have deficiencies in communication. There's been a whole lot of research about that in the last 10-15 years or so. And a lot of memes in the community.