HN user

Avamander

5,093 karma

[ my public key: https://keybase.io/avamander; my proof: https://keybase.io/avamander/sigs/vV2ZbzCWZFslfcFmlrQ0-BCnkpzWbYuekYqzAPnjdTM ]

Posts5
Comments3,221
View on HN

If you find those few instances that have those few uploaders that interest you, the content can be good.

However it does certainly suffer from the fact that all federated instances can't pull in videos from other platforms in some reproducible way (so that all instances would be able to serve the same content).

I'm sure some YouTubers would allow mirrors if they didn't have to pick an instance and keep it running.

Servers can communicate their preference in terms of CAs they want. But the UX in browsers is unbelievably horrible for no good reason.

Not only is it difficult for an user to make a proper selection, it's also hard to fix a wrong one. The error pages are also terrible. There's no way for the site owner to request that when the navigation to the (auth) page fails, redirect back. Nope, no way to do error handling without some really clever iframe stuff and even then it's way too opaque.

God forbid you have to deal with CORS + mTLS.

Appreciating Exif 1 month ago

Yup. Looking back I wish I had location data on some of the photos I took. Can't share them but can't also remember where I took them. Unfortunate.

Wacom does the same CRC-32 BS in their updater.

I blocked HTTP connections from my local network years ago and you wouldn't believe how many driver installers and auto-updaters break. One should never trust a HW vendor's (auto-)update implementation.

[...] it seems likely they also have enough to maliciously chug the hardware sufficiently to degrade capacity over time and otherwise impact system integrity. I hate the thought of some random website writing and overwriting random bytes in a tight loop in the background while I'm browsing elsewhere to find the cause of my slow disk subsystem.

Absolutely. Things like IndexedDB get fsynced super frequently. There's no way to tell Chrome that some web apps do not need to make it do the physical disk this often.

It's really difficult to reliably separate temporary and persistent browser storage. I tried at some point to reduce HDD noise. But given how neither Firefox or Chrome properly follow the XDG spec, it did not yield the results I wanted without a lot of handcrafted mounts.

In the end I'd guess you can also use some aspects of persistent storage to achieve similar results, even if the rest is actually tmpfs/RAM.

LLMs managing the "coloring book" equivalent of something is not bullish for the "art" version of something.

The intent for most CTFs is to provide a meaningful challenge that concerns a single topic without introducing noise that wastes time. Of course a training exercise is easier to complete for an LLM.

The more you obfuscate a topic against LLMs the lower the educational value of a challenge.

The only things that works is novelty and obscurity. LLMs still suck with things mentioned in the footnotes of datasheets and manuals, things that deviate in subtle ways, unique constructions that alter something very very common. It's hard for LLMs to avoid common pitfalls in terms of making assumptions, while staying on track.

No, the search space is much more vast and the feedback loop almost nonexistent.

The reason LLMs can do CTFs so well is partially because the challenges are usually designed to avoid wasting time and to introduce a single concept without noise.

Or maybe an employee has compromised the new key that is going to be rotated in, while the old key is securely rooted in an HSM?

Also possible, but that'd be an active threat that has some probability of being caught.

Never replacing keys allows permanent compromise that can only be caught if someone directly observes misuse.

Though nobody monitors DNSSEC like that, nor uses it, so it's fine from that aspect I guess.

It is not fine. Keeping key material safe is not a boolean between "permanently safe" and "leaks immediately".

Keeping key material secure for more than a decade while it's in active use is vastly more complex than keeping it secure for a month, until it rotates.

For all we know, some ex-employee might be walking around with that KSK, theoretically being able to use it for god knows what for an another decade.

ASN.1 is not used because of just bitpacking. There are other benefits to ASN.1 and it's probably one of the least problematic parts there.

People who have thought they can do better have made things like PGP. It's one of the worst cryptographic solutions out there. You're free to try as well though.

Kind-of. But there are worse things than outages when it's PKIs we're talking about. DNSSEC is also extremely opaque and unmonitored. Any compromise will not be noticed. Nor will anyone have any recourse against misbehaving roots.

Fun fact, CloudFlare has used the same KSK for zones it serves more than a decade now.

Dav2d 3 months ago

The "can't" comes from the fact that VLC is not going to rewrite their forum software or software forge.

Software written in PHP is in most cases frankly still abysmally slow and inefficient. Wordpress runs like 70% of the web and you can really feel it from the 1500ms+ TFFB most sites have. PhpBB is not much better. Pathetic throughput at best and it has not gotten better in decades now.

I don't know how GitLab became so disgustingly slow. But yeah, I'm not surprised bots can easily bring it to its knees.

This is the effect of "every vulnerability is a bug" and "we can't rate the severity of any vulnerabilities".

Which very clearly results in "bugfixes" (security patches) not making it everywhere in time because it's just simply ridiculous to ask for each downstream consumer to rate the severity of everything on their own. It's easy to shit on CVEs, some even put out shit CVEs, but at the same time contribute absolutely nothing towards providing a better alternative.

It's quite certain that both the Linux project and the Linux CNA needs to take some responsibility and put in some effort at communication and making it easier to triage.