Hacker News .hnnew | past | comments | ask | show | jobs | submit | voxic11's commentslogin

To be held in contempt indefinitely you must "hold the keys to the jail cell" meaning you can leave at any time if you simply comply with the courts order.

Zero knowledge proofs are better than this "bearer token" proposal because all what is needed to unmask an account is for the shop to note down the name on the ID and the code that was given to them.

I already wrote "no record keeping" in my first comment.

Shop at stores that don't do that. If that doesn't work write it into the law that they aren't allowed to record your ID.

For alcohol and tobacco, stores don't even card people that obviously appear to be legal age. So most people won't ever show any ID to a clerk.

I've been buying alcohol since turning legal age, in multiple countries and jurisdictions. Never had my ID scanned or stored.


Minecraft is going this direction as well, at least for UK based users.

You know that none of those things actually protect children from predators which is the supposed reason for these changes. So when they inevitably don't work Discord will take the next step of requiring age verification from everyone.

Did regulating cigarettes kind of work? I ask just because I don't actually know. I always assumed that the regulations were a reflection of the growing society wide distaste of cigarettes and not a cause of it. If regulations were enough to change peoples attitudes towards something then why did alcohol prohibition fail so hard?

I mean, cigarette usage in the US is down massively since the US banned cigarette advertising to kids and actually started enforcing the ban on cigarette sales to kids.

Meanwhile, after cigarette companies spent some time thinking about how to solve the problem of falling sales, "vape" (which did not have the same regulations) sales surged first in kids, who have continued to use those products into adulthood (after they became addicted).

So, I would say "yes" regulating cigarettes not only worked, but was a massive public health success.


It's down massively because they're taxed to death making a smoking habit very expensive.

GDPR permits retention where necessary for compliance with a legal obligation (Article 6(1)(c)).

The AI Act qualifies as such a legal obligation.


No but if you defame them and that causes others to boycott then you could be legally responsible.

The idea is you wouldn't mix innerHTML and setHTML, you would eliminate all usage of innerHTML and use the new setHTMLUnsafe if you needed the old functionality.


I looked up setHTMLUnsafe on MDN, and it looks like its been in every notable browser since last year.

Good idea to ship that one first, when it's easier to implement and is going to be the unsafe fallback going forward.


I looked up setHTMLUnsafe on MDN, and it looks like its been in every notable browser since last year.

Oddly though, the Sanitizer API that it's built on doesn't appear to be in Safari. https://developer.mozilla.org/en-US/docs/Web/API/Sanitizer


If I need the old functionality why not stick to innerHTML?


because the "unsafe" suffix conveys information to the reader, whereas `innherHTML` does not?


Any potential reader should be familiar with innerHTML.


Right. Like how any potential reader is familiar with the risks of sql injection which is why nothing has ever been hacked that way.

Or how any potential driver is familiar with seat belts which is why everybody wears them and nobody’s been thrown from a car since they were invented.


yes, and bugs shouldn't exist because everyone should be familiar with everything.


But if some are marked unsafe and others are not it gives a false sense of security if something is not marked unsafe.


So we shouldn’t mark anything as unsafe then? And give no indication whatsoever?

The issue isn’t that the word “safe” doesn’t appear in safe variants, it’s that “unsafe” makes your intentions clear: “I know this is unsafe, but it’s fine because of X and Y”.


Maybe we should add the word safe and consider everything else as unsafe


Like life, things should default to being safe. Unsafe, unexpected behaviours should be exception and thus require an exceptional name.

Legacy and backwards compatibility hampers this, but going forward…


Because then your linter won't be able to tell you when you're done migrating the calls that can be migrated.


Because sooner or later it'll be removed.


No because the web has to remain backwards compatible with older sites. This has always been the case.


And break millions of sites?


You can't rename an existing method. It would break compatibility with existing websites.


> you would eliminate all usage of innerHTML

The mythical refactor where all deprecated code is replaced with modern code. I'm not sure it has ever happened.

I don't have an alternative of course, adding new methods while keeping the old ones is the only way to edit an append-only standard like the web.


If you want to adopt this in your project, you can add a linter that explicitly bans innerHTML (and then go fix the issues it finds). Obviously Mozilla cannot magically fix the code of every website on the web but the tools exist for _your_ website.


I kinda like the way JS evolved into a modern language, where essentially ~everyone uses a linter that e.g. prevents the use of `var`. Sure, it's technically still in the language, but it's almost never used anymore.

(Assuming transpilers have stopped outputting it, which I'm not confident about.)


Depending on the transpiler and mode of operation, `var` is sometimes emitted.

For example, esbuild will emit var when targeting ESM, for performance and minification reasons. Because ESM has its own inherent scope barrier, this is fine, but it won't apply the same optimizations when targeting (e.g.) IIFE, because it's not fine in that context.

https://github.com/evanw/esbuild/issues/1301



Ah yeah, I remember that. General point still stands: in terms of the lived experience of developers, `var` is essentially deprecated.


I touch JS that uses var heavily on a daily basis and I would be incredibly surprised to find out that I am alone in that.


That is indeed why I added qualifiers to "everyone" and "never".


for some values of "everyone" and "never".


It for sure happens for drop in replacements.


Nobody's talking about old code here.

Having an alternative to innerHTML means you can ban it from new code through linting.


Finally, a good use case for AI.


Yeah, using a kilowatt GPU for string replacement is going to be the killer feature. I probably shouldn't even be joking, people are using it like this already


This ship has sailed unfortunately, no later than yesterday I've seen coworkers redact a screenshot using chatGTP.


When the condition for when you want to replace is hard to properly specify, AI shines for such find and replaces.


This one is literally matching "innerHTML = X" and setting "setHTML(X)" instead. Not some complex data format transformation

But I can see what you mean, even if then it would still be better for it to print the code that does what you want (uses a few Wh) than doing the actual transformation itself (prone to mistakes, injection attacks, and uses however many tokens your input data is)


That can break the site if you do the find and replace blindly. The goal here is to do the refactor without breaking the site.


> When the condition for when you want to replace is hard to properly specify, AI shines for such find and replaces.

And, in your opinion, this is one of those cases?


It is because the new API purposefully blocks things the old API did not.


Wouldn't AI be trained on data using innerHTML?


My experience is that they somehow print quite modern code despite things like ES6 being too new to be standard knowledge even for me and I'm not even middle-aged yet

Maybe the last 10 years saw so much more modern code than the last cumulative 40+ years of coding and so modern code is statistically more likely to be output? Or maybe they assign higher weights to more recent commits/sources during training? Not sure but it seems to be good at picking this up. And you can always feed the info into its context window until then


This is not my experience. Claude has been happily generating code over the past week that is full of implicit any and using code that's been deprecated for at least 2 years.

>> Maybe the last 10 years saw so much more modern code than the last cumulative 40+ years of coding and so modern code is statistically more likely to be output?

The rate of change has made defining "modern" even more difficult and the timeframe brief, plus all that new code is based on old code, so it's more like a leaning tower than some sort of solid foundation.


ES6 is 11 years old. It's not that new.


Hence the example of how long it takes non-LLMs to pick that up, whereas LLMs seem to get it despite there being loads of old code out there

See also my reply to the sibling comment with the same remark https://hackernews.hn/item?id=47151211

My mistake for saying 10 instead of 11 years btw, but I don't think it changes the point


> "ES6 being too new to be standard knowledge"

Huh? It's been a decade.


Exactly, I learned coding JS before 2015 (it was my first language, picked up during what is probably called middle school in english). I haven't had to learn it again from scratch, so I need to go out of my way to find if there is maybe a better way to do the thing I can already do fine. It's not automatic knowledge, yet the LLM seems to have no trouble with it, so I'm pointing out that they seem to not have problems upgrading. The grandparent comment suggested it would need to be trained anew to use this new method instead. Given how much old (non-ES6) JS there is, apparently it gets it quite easily so any update that includes some amount of this new code will probably do it just fine


Which is why it can easily understand how innerHTML is being used so that it can replace it with the right thing.


Honest question: Is there a way to get an LLM to stop emitting deprecated code?


Theoretically, if you could train your own, and remove all references to the deprecated code in the training data, it wouldn't be able to emit deprecated code. Realistically that ability is out of reach at the hobbiest level so it will have to remain theoretical for at least a few more iterations of Moore's law.


You can use a custom domain that you own with gmail. But of course domains aren't that great either as they are only somewhat decentralized and it's still pretty easy to lose your domain.


When I've looked into these cases it often seems that there are additional issues at play like harassment/stalking of ex's. So the prosecutor is thinking they can get an easy plea deal on the "real" case by piling on additional charges.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: