If I do this on my mac, I wonder if am technically violating the HEIC patent license. I suppose it depends on the details in the patent license, plus perhaps rights Apple has acquired for its users. I definitely don't know, but maybe someone on HN does?

I would assume not because you can do the same thing using a CLI apple installs on all macs, sips

    sips -s format jpeg in.heic --out out.jpeg

also, a heic is just a container around an h265 image frame

i doubt anyone needs to be concerned with licences if they are not producing a paid product.

I gather from the HN discussion that it's not simple to disable scripting in an SVG, in retrospect a tragically missing feature.

I guess the next step is to propose a simple "noscripting" attribute, which if present in the root of the SVG doc inhibits all scripting by conforming renderers. Then the renderer layer at runtime could also take a noscripting option, so the rendering context could force it if appropriate. Surely someone at HN is on this committee, so see what you can do!

Edit: thinking about it a little more - maybe it's best to just require noscripting as a parameter to the rendering function. Then the browsers can have a corresponding checkbox to control SVG scripting and that's it.

Disabling script execution in svgs is very easy, it's just also easy to not realize you're about to embed an svg. `<img src="evil.svg">` will not execute scripts, a bit like your "noscripting" attribute except it's already around and works. Content Security Policy will prevent execution as well, you should be setting one for image endpoints that blocks scripts.

Sanitizing is hard to get right by comparison (svgs can reference other svgs) but it's still a good idea.

I had the impression from elsewhere in this thread that loading the svg in some other way, then you are not protected. This makes a no-brainer "don't run these ever" option in the browser seem appealing.

> This makes a no-brainer "don't run these ever" option in the browser seem appealing.

Firefox has this: svg.disabled in about:config. It doesn't seem to be properly documented, and might cause other problems for the developer (I found it accidentally, and a more deliberate search turns up mainly bug tracker entries.)

its common to santize html string to parse it and remove/error on script tags (and other possible vulnerabilities)

i wonder do people not do this with svgs?

I would surprised to see performance as good as V8, although that would be great. As I recall the v8 team performed exceptionally well in a corporate environment that badly wanted js performance to improve, and maybe inherited some Hotspot people at the right time.

I'd be quite delighted to see, say, 2x Python performance vs. 3.12. The JIT work has potential, but thus far little has come of it, but in fairness it's still the early days for the JIT. The funding is tiny compared to V8. I'm surprised someone at Google, OpenAI et al isn't sending a little more money that way. Talk about shared infrastructure!

Don't underestimate the nicotine withdrawal for making you feel crabby - I've heard that anecdote many times. The nice thing is ... that one gets better with time.

I'm super curious how this hack worked, but I feel like the story is just about the last step. What did the attacker have such that this last step did it?

My guess is that the attacker had the google password, and also the login for Coinbase was somehow stored in Google, so the attacker getting into google also exposed Coinbase. I just looked at Coinbase, and it does have a "Sign In With Google" feature.

If you want to live the stripped-down TOTP lifestyle, you have to love this 20 line Python solution. Does not depend on weird libs, and the last edit is 4 years ago. Write the seed on a Post-It and you're all set. Not so convenient, but sound sleeping! https://github.com/susam/mintotp