creatonez

Both workloads being malicious and trying to establish a hidden data channel between them probably makes this attack a lot easier than conventional spectre/meltdown where it's trying to target ordinary processes.

The refusal string feature was implemented at an API level, but for whatever reason Anthropic doesn't want the feature to exist anymore. It's gone now, the refusals you get now are just the model's natural behavior, perhaps after being trained on internet posts that mentioned the feature.

Meh. This is the only part that should be boring, because boring prevents mistakes that result in data loss, which ends the fun of gaming faster than any other problem.

Not anymore, because the CT logs only accept entries for currently active certificates. But during the period before it was revoked, yes.

The intent isn't public shaming, it's to have enough information about what the hell happened, so that the failure mode can be squashed as thoroughly as possible in the future. Other CAs and interested parties should be terrified about the possibility that they have the same cockroach infestation as a result of using the same software or similar procedures, rather than sneer about how bad the so-called "human error" was this time.

> At the time of posting, I didn't know about any embargo. My contact had told me there was no embargo, and her contact had told her the same thing.

If you're not a party to an embargo, and no one told you an embargo even exists... you should not follow the embargo. In fact, you should maybe even consider leaking basic details or challenging the embargo if you are in this situation. In your situation, they had lost information asymmetry before the news got to you. I don't know where people got the idea that unrelated third parties have to follow embargos.

Embargos are not about keeping secrets, they are about the game theory of coordinated disclosure.

On second look, I guess I'm wrong about Node.js... shockingly, they follow in Java's idiotic footsteps and do use a builtin root store by default.

Is certifi used widely in the Python ecosystem?

> It appears to me they do, and that is why everybody is saying to patch your python, go, and node infrastructure separately from /etc/ssl.

No it is not. As I said, the revoked key IDs is a supplementary list. It is not a root store. They do not add new root keys or transmit any public key material via this path. It may not contain data that is applicable to the root store being used, but it is perfectly permissible to relay a revocation 'out of band' as long as it represents a truly revoked certificate (CRLs and OCSP are out of band in the same sense)

Only in Java is the practice you're describing (full root store bundled with the runtime) widespread. (Edit: Node.js too, apparently)

> * It's absurd that Python, Go, or Node need their own certificate stores that need separate updates.

They don't. They use the OS certificate store, which on all platforms has already had this certificate revoked from it.

These runtimes are just doing this as a secondary precaution to deliver the revocations to anyone paying attention to version numbers for their runtime but not their OS. It's a bit of an odd approach, and for most of these projects it's their first time ever doing such a thing, but there's no big issue with it as long as it doesn't encourage complacency and is only applied to truly revoked certificates.

You are thinking of Java, which does actually have its own certificate store. Java users are familiar with how wacky this is, so there have been 3rd party attempts at a cleaner solution, such as the way RHEL keeps the Java certificates in sync with the system certificates.

Huh? Smaller numbers are a smaller part of the space.

> 2. Name constraints. It’s long past time for the CAs of the world to have name constraints enforced. A CA that is not appropriate to use for .com should not work for .com. A CA that is not appropriate to use for .ae should not work for .ae. And the CA/B Forum should should requiring that all newly approved roots and all newly signed intermediates have appropriate name constraints.

This suggestion seems to be a symptom of thinking different TLDs represent different levels of trustworthiness... which hasn't been the case in ages

This problem is being addressed: https://en.wikipedia.org/wiki/Certificate_Transparency

The certificates are not trusted, they have a certificate revocation from the issuer associated with them. Your OS trusting these certs is a symptom of it not getting an up to date CRL.

I find it baffling that anyone still cares. RSS nerds like RSS because it can be consumed by software that displays it however the user wants. XSLT pages just function as normal webpages, there is no consuming it programatically because XSLT is the view language. The underlying XML/RSS is what you wanted, not the hodgepodged together crap on top of it.

Right, we have the capability to update timezone definitions in a standardized automatable way right now, but 14 hours is the furthest timezone offset a political timezone has ever had. The distant future will require the offset to drift by multiple earth rotations, which puts a wrench in the flexibility of existing systems even if the tzdata database compiles properly. For example, this would break Java's ZonedDateTime as it only supports offsets up to 18 hours.

Sure, but political timezones shifted by more than 12 hours 65,000 years in the future seems like the sort of thing that would really screw up our existing code. (I wonder what happens if you put such an entry in tzdata right now? Maybe we should put Null Island at +37:00 or something crazy like +1000:00 to start hardening now)

And maybe we should stop touching political timezones by then anyways.

Any prospect for a leap hour is toast by the time we need it. Over a thousand years of ossification will mean our only option is to not care about aligning clock time to the sun. So it's kinda a joke to even talk about leap hours. I'm shocked they're even mentioning such an idea, they should have declared it as a non-solution.

HTTP/2 without encryption is still standards compliant if you initiate the connection with prior knowledge that the protocol is supported. It's upgrading from HTTP/1.1 that isn't supposed to be supported.

But of course, the only scenarios where you have prior knowledge are things like reverse proxies or custom made clients.

> When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.

This is grade A horseshit. The end goal is for enterprise passkey managers to not boot up at all and not unlock their encrypted stores if hardware attestation isn't available. There's no use in attesting a certain password manager vendor if the platform isn't helping to avoid impersonation.

The projects I'm referring to are ones that have a complete prohibition on "slop". Any serious project would, which is why you should check whether it's a serious project instead of worrying about the specifics of their AI policy.

> But Apple doesn't give me a legal way to freely run an iOS simulator nor even a macOS VM on my linux machine, I have to pay money, to buy their hardware to see if my site will work on Safari.

Try GNOME Web (Epiphany). It's webkit based, keeps up with Safari, doesn't disable access to the Safari devtools, and it sends the exact same user agent string. Should be essentially bug-for-bug compatible. It's otherwise an anemic browser, but you don't need much for testing.

Haiku OS is similarly hard-line about this, and is also starting from the point of an extremely clean codebase.

Neat stuff, though I can't say AI policy is the biggest priority when I choose projects to use, plenty of projects are using it in a measured and sane way without needing a complete prohibition.

Indeed, I was just giving some perspective on the number (and how it was a 2100 target and not a 2030 target), which is thought of as the "quite bad but the overall order of civilization keeps going" scenario

Note that the original Paris 1.5°C target referred to keeping under 1.5°C for the entire period from 2015 to 2100, requiring sustained action between 2020 and 2030 to have any hope of setting that trajectory. We are so, so far away from that goal. The maximum by 2100 is going to be at least 2.2°C for sure, but 2.5°C and beyond are more likely.

Vi Hart's claim to fame is extremely verbose and meandering math explanations... hope she keeps doing that, because it's awesome

The Polymarket account on twitter is a satire account where half the posts are made up news headlines... maybe switch this link to something else

Tried doing this with Proton Drive one time. It broke in several different ways simultaneously. Doesn't seem to be ready yet, but maybe some day it will be good for this.

I mean sure, you could still win if almost no requests are opening the database in write mode

Is the CGI process opening up the SQLite database for every request...? That would have the most insane contention ever.

Why exactly the fuck did Tor partner with a VPN company? Of course something bad was going to happen. The incentives at play could not be more at odds.