chocmake
Joined 2 years ago
Karma
266
Submissions
12
Member since
Sep 27
Recent submissions
Comment · 6 months ago
Comment · 7 months ago
EUDI has had various criticism with its approach for not supporting unlinkability (with the same attestation used across verifiers they can be traced to the same user).
There are some long Github threads in the official repo along with a PDF[1] of cryptographer's feedback about the privacy issues. Also covered in this[2] article.
This is unlike BBS+ which supports unlinkability and which was even recommended by GSMA Europe to such address downsides. In the Github discussions there seems to be pushback by those officially involved that claim BBS+ isn't compatible with EUDI[3] and there seems to be some plateauing of any progress advancing it.
[1] https://github.com/eu-digital-identity-wallet/eudi-doc-archi...
[2] https://news.dyne.org/the-problems-of-european-digital-ident...
[3] https://github.com/eu-digital-identity-wallet/eudi-doc-archi...
Comment · 8 months ago
See eg. BBS+[1]. Proofs that preserve anonymity are generated locally and neither the verifier nor issuer can determine the user based on these (in scenarios of non PII signals like age thresholds), while still allowing the verifier to validate it's issuer approved.
Comment · 8 months ago
If it is the case that German IDs supporting selective disclosure aren't seeing adoption for services then it needs to looked at what the friction is or even just because it's optional. It doesn't necessarily have to be an ulterior motive. It'd be easy to be called out as conspiratorial otherwise.
Right now with age assurance laws and online services there has been no singular approach beside falling back to use of government ID that any country has required. Each country has just said 'here are the minimum criteria, choose what you want' and left it up to services to comply.
So what have services chosen? The least friction and cheapest existing solution to be compliant. For most services that's been using readily available facial scanning services and government IDs as fallback. Not all of them of course but it's so scattered that it makes it difficult for a person to know what they'll need for one service vs another (and perhaps even avoid use of a service if their approach doesn't align with the person's values).
Without mandating better minimum privacy criteria governments can just point to the fact they're not preventing such tech from being used and leave it at that. But solutions also need to be affordable to adopt for a wide range of sites/services and have good support (interfaces, etc) around them to catch on so it's not just entirely whether tech exists per se.
Comment · 8 months ago
There's a good explainer and Q&A of BBS+[1], which is one such zero-knowledge anonymous credentials standard, in a joint talk by cryptographer Brent Zundel. It covers the history of getting it into the W3C verified crentials spec and how various competing verified credential standards aren't privacy-preserving or as performant. It seems very promising and has considered various pitfalls.
From what I understand the issuer signs a credential and then the user on their local device generates unique proofs based on the signature each time, preventing verifiers from colluding/tracking the original signature across services. It also seems to be designed with safeguards against the issuer.
Info based on credentials can be selectively disclosed like whether you're over 18 or whether you have above a certain threshold in an account without disclosing the underlying data.
Obviously if the type of services you use need literal PII then they can still tie activity to a real-world identity but for services only requiring age assurance being able to prove you're over 18 without providing the actual age or other identifiers is better than solutions being actively used.
Comment · 1 year ago
CSS animations still lack a semantic way to sequence animations based on the beginning/end of some other animation, which SMIL offers. With SMIL you can say 'when this animation ID begins/ends only then trigger this other animation', including time offsets from that point.
Which is miles better than having to having to use calcs for CSS animation timing which requires a kludge of CSS variables/etc to keep track of when something begins/ends time-wise, if wanting to avoid requiring Javascript. And some years ago Firefox IIRC didn't even support time-based calcs.
When Chromium announced the intent to deprecate SMIL a decade back (before relenting) it was far too early to consider that given CSS at that time lacked much of what SMIL allowed for (including motion along a path and SVG attribute value animations, which saw CSS support later). It also set off a chain of articles and never-again updated notes warning about SMIL, which just added to confusion. I remember even an LLM mistakenly believing SMIL was still deprecated in Chromium.
Comment · 1 year ago
This is disappointing. I was using XSLT for transforming SVGs, having discovered it early last year via a chat. Even despite browsers only shipping with v1.0 it still allowed a quite compact way to manipulate them without adding some extra parser dependency.
Comment · 1 year ago
From what I gather Epic delisted various of their Unreal Tournament games across all stores a couple years ago due to them not supporting their modern online services (including chat). This was within days of being fined $500m for, among other things, allowing on-by-default text chat in one of their other games that is available for children/teens to play, so some believe they'd rather delist than update some of their older games.
Comment · 2 years ago
> Also Blender does not have support for variable fonts; this add-on adds support for those, along with support for keyframing variable font axes.
This was a nice unexpected feature from the list.
Sanitization-wise it's already possible to strip scripting from SVGs and anything else you want, it's just that a library like DOMPurify to avoid ballooning in size doesn't include say a preset to handle the extra parsing necessary to make them behave like browsers treat IMG embeds, so it's up to devs to add their own.
But yeah, a world where a simple attribute to achieve the same effect as an IMG embed but for inlined SVGs would be nice.