Are you sure? I would be more surprised if it did not come from there, if the field was present at all. You're already processing the PostScript... Might as well use the metadata.
Because everyone [in the specific field of technical professional operating systems like this] is using AI and not everyone is smart about how they use AI?
System worked mostly fine for decades, then in the middle of integrating a new AI system it completely goes down.
It doesn't take a genius to see the problem is the new AI system. Whether or it's the "AI" part of the system isn't really relevant system this new system was vibe-coded by AI and built around the "AI" features.
There is zero evidence of this at all. The stuff going around on social media has zero correlation to the system in question. Unless you have other evidence others are not privy to?
Doesn't seem to me like it is telling the printer what day of the week it is because the printer needs to know so much as it is generating a PostScript file for the printer to use and is adding the creation date as either a convention or requirement of the format, and not the printer.
Not a requirement, but indeed more of a convention or at least a possibility. Postscript files can be postprocessed or read by humans, and then this kind of metadata can be useful.
this seems like a post-rationalization. when an app generates a file to send to another service, it's usually a good practice to timestamp that. unless you're severely bandwidth-constrained, putting a timestamp in your protocol almost always solves more problems than it creates. "we shouldn't include a timestamp because it might at some point trigger a date-math bug" is just not how software gets built.
if this bug was caused by a lack of a datestamp instead of the inclusion of one, you'd be here leaving comments about how silly it was they didn't include something as standard and widely useful as a datestamp, and that of course that was necessary.
A datestamp is a privacy risk. If it's optional, don't include it. If it's not optional, it's a spec bug! It should be optional. Or even better, removed entirely.
Exactly, it was using the file utility to determine what it was so it could print it correctly (by processing it if needed to a format the printer understood) and there was a bug in that.
This is one of those "VLC is slow to start because of a bug in Windows" things. It's VLC's responsibility to ensure their program runs properly on the OS people actually have. It's LibreOffice's responsibility to ensure that their files print on Tuesday irrespective of bugs in CUPS (which ships with the Mac).
So, Windows gets a pass for being sloppy coded? Give me a break. Every software must fulfill their contract with every consumer rather than consumer have to work around producers quirks. "All means are fair except solving the problem"[0]
I think people on HN argue way too much about this. It's not like they're named iPhone 18 Pro XL Max. It's meant to evoke a feeling of wonder or awe, not really that hard of a logical leap to make, and it's only one minor quibble. Jeesh.
So we either expose the key material for inspection (very obviously bad) or we try and brute force how many possible "weak" private keys from the public key to see if they check out?
Note that this is on the order of trillions of useless computations at least per year since almost everyone just uses a CSPRNG or HWRNG available in all modern computers to generate their keys sanely.
Now, for CAs, sure because that is a very small number of certificates. But that's a completely different discussion and also however eMudhra managed to lop off all of the entropy except for the final byte was wildly incompetent and not something a layman would even consider doing.
It's also not the job of the CA to detect you being an idiot. You can go post your private key online after getting your certificate if you so wish, the CA may revoke it if they find out but they're just in the business of helping you secure your communications with others. If you wish for them to actually be insecure... You are silly, but that was always allowed.
FWIW, at at least some of the ACME CAs still willing to sign RSA certificates will make a cursory attempt at brute forcing your private key to make sure you don’t have one very tiny prime and one big one. Tom7 encountered this when he tried to implement the least secure website he could without being flagged by the browser. He ended up using a public modulus with four prime factors instead of 2.
The “4” affair did make me wonder… as a non-expert, I’d always kind of assumed that—with all the ceremony around key ceremonies and all—there might be some way to provably assert the set of techniques used to arrive at the key in the first place. XYZ hardware-signed source of entropy was sampled at DEF time and input into ABC signed chunk of algorithm to arrive at the private key…
In fact I assumed that’s why somebody might explicitly choose “4” as their key: to make it as easily detected as “TK” in a copy edit, or a prefix-designated API key in a repo, or an “@example.com” that slides by into a serious environment.
We really go on a pinky swear across the public CA ecosystem?
You could certainly use zero knowledge proofs to prove some statements about the secret key, like requiring it to be roughly a 1:1 ratio of 0s and 1s and the longest run of the same bit is not significantly larger than log2(n). I think if I were trying to enforce a minimum level of security then I might take that route, requiring that the key passes zero-knowledge proofs of various statistical tests of randomness.
By pigeonhole principle, nearly all numbers have to have a Kolmogrov complexity within some constant of their own length, meaning they are algorithmically random and will by definition pass every statistical test of randomness, so you lose surprisingly few bits entropy per assertion this way.
I am not sure how trillions of computations will occur, simply attempting 0-255 would have found ... all? ... of the eMudhra fuckups. Maybe a few million instructions burnt on a CPU.
And again, you have to actively work to get a "private key" of 0000 ... 0-255. If you want to be stupid it's not really the CA's job to tell you not to be. It's their job to verify your identity. And, again, a CA itself is a totally separate beast where this thinking does not apply. If you want to be secure it's easy to be secure and if you don't want to be... Why should anyone else care? You are only hurting yourself.
This is just flatly false. You're comparing a worst case SSD with maybe 10% of its writes left to an extremely lucky floppy disk that hasn't died to binder hydrolysis, mold and fungal growth, warping or demagnetization. And you also completely made up that you couldn't generate a strong enough magnetic field at home to corrupt one - you absolutely could especially since rare earth magnets are not that uncommon and are more than enough to kill a floppy.
> Cloudflare is no better, maybe worse. They forward your complaint & PI on to the offending site's registered owner and to whichever (gray or black hat) host it's served from.
This is literally false. They are one of the few hosts I have dealt with that actually does NOT do this. Their abuse reporting form even has check boxes that are optional to forward it to the underlying host and the owner. If you leave them unchecked they don't forward anything.
I don't know where you got your information from but it's quite literally the opposite of reality.
Now, whether or not they actually act on it depends on whether they are proxying the site or merely providing authoritative DNS. If they are just providing DNS they will continue to provide it and deny your report and I think that's stupid and frustrating. If they are proxying it they will put up a block page in front of it which is meh.
reply