rslashuser

Just as a PSA, I found that "nginx -v" was not detailed about the version sufficient to check, but "apt list nginx" gave the full version number that was checkable, and indeed the 24.04 version of this morning (1.24.0-2ubuntu7.8) is patched.

The test is the hardcore engineering tell here. The test is dialed in on the key area, and when the graph wasn't coming out the right shape, they kept at it. Plus one from me!

What jumps out to me is that this is a success story of using a non-trivial test to illuminate an important but hard to observe bit of algorithm. I appreciate the engineering grit to put in a complex test like this, and follow it up when the graph does not have the expected shape.

Imagine your team does not want to write a test because it's too much work or hard to model - this is a great example to bring up.

Exactly. It's not a good solution where you have to read a bunch of steps to do to make SVG safe, where you're worried you forgot one. Instead there should be a straightforward <svg exec="false"> or whatever that simply and comprehensively disables the unsafe features.

Think of prior technologies like display postscript and .doc, where a data format ended up a with big problems from its embedded "exec" type features.

I'm curious is the JIT developers could mention any Python features that prevent promising JIT features. An earlier Ken Jin blog [1], mentions how __del__ complicates reference counting optimization.

There is a story that Python is harder to optimize than, say, Typescript, with Python flexibility and the C API getting mentioned. Maybe, if the list of troublesome Python features was out there, programmers could know to avoid those features with the promise of activating the JIT when it can prove the feature is not in use. This could provide a way out of the current Python hard-to-JIT trap. It's just a gist of an idea, but certainly an interesting first step would be to hear from the JIT people which Python features they find troublesome.

[1] https://fidget-spinner.github.io/posts/faster-jit-plan.html

Nice HN explanation! One hopes we will not be living with 4kb pages forever, and perhaps L1 performance will be one more reason.

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 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.

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.

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