You don't think that the digital ID provider is keeping logs of which sites requested to verify which users? Even government websites are not exactly known for their high security.
The digital ID provider is only involved in issuing the ID to you. When you use that ID to verify age to a site the only communication is between your phone and the site. The ID provider has no idea when you use the ID, how often you use the ID, or where you use the ID.
Briefly, when the ID provider issues the ID it gets cryptographically bound to your phone. When you use the ID to prove something to a site (age, citizenship, etc) the is done by using a zero-knowledge proof based protocol that allows your phone to prove to the site (1) that you have an ID issued by your ID provider, (2) that ID is bound to your phone, (3) the phone is unlocked, and (4) the thing you are claiming (age, citizenship, etc) matches what the ID says. This protocol does not convey any other information from or about your ID to the site.
This doesn't work because you can't prove the origin of a single bit of data without the associated identity and the origin of the data can only be verified by matching the biometric image on the ID against your real face with a camera.
Otherwise a single person could donate their ID card and let everyone else authenticate with it.
Now you might counter and say it would be enough to give each card a sequential number independent of the person's identity, but then you run into another problem. Each service might accept each card only once, but there are many services out there, so having a few thousand donations could be enough to cover exactly the niche sites that you don't want kids to see.
There is no way to implement this without a complete authoritarian lockdown of everything. There will always be people slipping past the cracks. This means all this will ever amount to is harm reduction, but nobody is selling it on that platform. Nobody is saying that they are okay with imperfect compromises.
The difference is meaningful. It's mostly prisoners dilemma. If only one persons porn habit is available thats bad for them. If everyones (legal) porn habits are available, then it gets normalized.
this seems to run parallel to the "i have nothing to hide" / "well they have everyone's data, so who cares about mine" arguments.
this is too narrow a view on the issue. the problem isn't that a colleague, acquaintance, neighbor, or government employee is going to snoop through your data. the problem is that once any government has everyone's data, they will feed it to PRISM-esque systems and use it to accurately model the population, granting the power to predict and shape future events.
Normalized or not, the risk is you get something akin US drug enforcement: ignored for certain demographics, enforced for others. The ability to see someone's porn history is irrelevant until a government (or employer perhaps) wants to weaponize it.
The problem isn't my peers, it's the people in power and how many of them lack any scruples.
If you don't like youtubers with sponsors, don't watch those videos. Not all do.
Personally I pay for youtube and I don't mind the sponsor sections. They're easy to fast forward through and income goes directly to the creator. Youtube doesn't take a cut. These are the only kinds of ads that work on me - in the rare case that the product is something I'm interested in, I go out of my way to make sure I use the creator's link.
The long story short is that there are creators I like and I want them to devote all their time to making more content. I'm glad some of them get sponsors. For many I just straight up give them money on Patreon.
This is only repeated by people who have never used it.
XSLT is still a great way of easily transforming xml-like documents. It's orders of magnitude more concise than transforming using Javascript or other general programming languages. And people are actively re-inventing XSLT for JSON (see `jq`).
I used to use XSLT a lot, though it was a while ago.
You can use Javascript to get the same effect and, indeed, write your transforms in much the same style as XSLT. Javascript has xpath (still). You have a choice of template language but JSX is common and convenient. A function for applying XSLT-style matching rules for an XSLT push style of transform is only a few lines of code.
Do you have a particular example where you think Javascript might be more verbose than XSLT?
Who is transforming XML documents on the web? Most people produce HTML to begin with, so XSLT is a solution seeking a problem. If you really insist, you could just use XSLT via server side rendering.
I actually do have to work with raw XML and XSLTs every once in a while for a java-based CMS and holy hell, it's nasty.
Java in general... Maven, trying to implement extremely simple things in Gradle (e.g. only execute a specific Thing as part of the pipeline when certain conditions are met) is an utter headache to do in the pom.xml because XML is not a programming language!
It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams...
I agree though, "XML is not a programming language" and attempts to use it that way have produced poor results. You should have seen the `ant` era! But this is broader than XML - look at pretty much every popular CI system for "YAML is not a programming language".
That doesn't mean that XML isn't useful. Just not as a programming language.
But, that's what XSL is! XSL is a Turing-complete programming language in XML for processing XML documents. Being in XML is a big part of what makes XSL so awful to write.
XSL may be Turing-complete but it's not a programming language and wasn't intended to be one. It's a declarative way to transform XML. When used as such I never found it awful to write... it's certainly much easier than doing the equivalent in general purpose programming languages.
Maybe by analogy: There are type systems that are Turing complete. People sometimes abuse them to humorous effect to write whole programs (famously, C++ templates). That doesn't mean that type systems are bad.
XSL is a functional programming language, not a declarative language. When you xsl:apply-template, you're calling a function.
Functional programming languages can often feel declarative. When XSL is doing trivial, functional transformations, when you keep your hands off of xsl:for-each, XSL feels declarative, and doesn't feel that bad.
The problem is: no clean API is perfectly shaped for UI, so you always wind up having to do arbitrary, non-trivial transformations with tricky uses of for-each to make the output HTML satisfy user requirements.
XSL's "escape hatch" is to allow arbitrary Turing-complete transformations. This was always intended to exist, to make easy transformations easy and hard transformations possible.
You basically never need to write Turing-complete code in a type system, but in any meaningful XSL project you will absolutely need to write Turing-complete XSL.
XSL's escape hatch is always needed, but it's absolutely terrible, especially compared to JS, especially compared to modern frameworks. This is why JS remained popular, but XSL dwindled.
> It is an unfortunate fact about our industry that all build tools suck. Tell me what your favorite build tool is and I can point at hundreds of HN threads ripping it to shreds. Maybe it's NPM? Cue the screams...
npm isn't even a build tool, it's a package manager and at that it's actually gotten quite decent - the fact that the JS ecosystem at large doesn't give a fuck about respecting semantic versioning or keeps reinventing the wheel or that NodeJS / JavaScript itself lacks a decent standard library aren't faults of npm ;)
Maven and Gradle in contrast are one-stop-shops, both build orchestrators and dependency managers. As for ant, oh hell yes I'm aware of that. The most horrid build system I encountered in my decade worth of tenure as "the guy who can figure out pretty much any nuclear submarine project (aka, only surfaces every few years after everyone working on it departed)" involved Gradle, which then orchestrated Maven and Ant, oh and the project was built on a Jenkins that was half DSL, half clicked together in the web UI, and the runner that executed the builds was a manually set up, "organically grown" server. That one was a holy damn mess to understand, unwind, clean up and migrate to Gitlab.
> look at pretty much every popular CI system for "YAML is not a programming language".
Oh yes... I only had the misfortune of having to code for Github Actions once in my life time, it's utter fucking madness compared to GitLab.
This is the problem with the dialogue around Musk. He's not 99% vaporware, he's 80-90% vaporware. That's problem enough.
In some cases, like Tesla, the vaporware is propping up the company (pivoting to robots!) even though sales are crashing because of the self-inflicted immolation of his personal brand. This is not going to end well.
IMO none of the current crop of LLMs truly pass the Turing Test. If you limit the conversation to an hour or two, sure - but if you let a conversation run months or years I think it will be pretty easy to pick the machine. The lack of continuous learning and the quality dropoff as the context window fills up will be the giveaways.
There are places where $3-$4 USD per hour is significantly higher than the prevailing wage. This is not a great fact about global wealth disparity, but that money goes towards improving the situation not making it worse.
To math it out: 8 hours a day at $3 USD per hour with 2 weeks vacation is about $15,000 per year.
That's not a lot of money to someone who lives in the United States. But here in 2025 it gets you out of the bottom quintile of earners in China, India, Brazil, Russia, Turkey, Japan, Central America, South America, Africa, South Asia, Southeast Asia, most of Eastern Europe...
For a job that's on demand, and requires, as far as I can tell, decent English skills and an Internet connection, but no real barriers to entry otherwise. It would have been a much stronger deal back in 2012, of course.
I'd be interested to know if the introduction of MTurk as a market competitor pushed entry level clerical wages up in some of these areas. Probably not, because English proficiency in a non English speaking country is a very rare skill not usually borne by people in the bottom 20% of income. But that's probably less true today given the dominant of English language YouTube.
Some of their work benefits us all. Unfortunately, some of their work is also rooting out homesexuals, making sure you can't buy sex toys, putting people in jail for smoking weed, and making sure everyone votes for the guys in charge.
reply