hlandau

To add, thinking a bit more about it: Designing formats to be understandable by future civilizations actually reduces to a surprising degree to the same set of problems which METI has to face. As in, sending signals designed to be intelligible to extraterrestrials - Carl Sagan's Contact, etc.

Even if you write an ASCII message directly to a tape, that data is obviously going to be encoded before being written to the tape, and you have no idea if anyone will be able to figure out that encoding in future. Trouble.

What makes this particularly pernicious is the fact that LTO nowadays is a proprietary format(!!). I believe the spec for the first generation or two of LTO might be available, but last I checked, it's been proprietary for some time. The spec is only available to the (very small) consortium of companies which make the drives and media. And the number of companies which make the drives is now... two, I think? (They're often rebadged.) Wouldn't surprise me to see it drop to one in the future.

This seems to make LTO a very untrustworthy format for archiving, which is deeply unfortunate.

Absolutely amazing story. Fantastic!

I've actually long been stunned by the propensity of proprietary backup software to use undocumented, proprietary formats. I've always found this quite stunning, in fact. It seems to me like the first thing one should make sure to solve when designing a backup format is to ensure it can be read in the future even if all copies of the backup software are lost.

I may be wrong but I think some open source tape backup software (Amanda, I think?) does the right thing and actually starts its backup format with emergency restoration instructions in ASCII. I really like this kind of "Dear future civilization, if you are reading this..." approach.

Frankly nobody should agree to use a backup system which generates output in a proprietary and undocumented format, but also I want a pony...

It's interesting to note that the suitability of file formats for archiving is also a specialised field of consideration. I recall some article by someone investigating this very issue who argued formats like .xz or similar weren't very suited to archiving. Relevant concerns include, how screwed you are if the archive is partly corrupted, for example. The more sophisticated your compression algorithm (and thus the more state it records from longer before a given block), the more a single bit flip can result in massive amounts of run-on data corruption, so better compression essentially makes things worse if you assume some amount of data might be damaged. You also have the option of adding parity data to allow for some recovery from damage, of course. Though as this article shows, it seems like all of this is nothing compared to the challenge of ensuring you'll even be able to read the media at all in the future.

At some point the design lifespan of the proprietary ASICs in these tape drives will presumably just expire(?). I don't know what will happen then. Maybe people will start using advanced FPGAs to reverse engineer the tape format and read the signals off, but the amount of effort to do that would be astronomical, far more even than the amazing effort the author here went to.

This is a very common way to handle multiplayer for RTS-style games. The inputs of the computation are the same, and the computation to update the game state is deterministic, so only the inputs are needed by every client. The disadvantage is if the logic deviates even slightly due to a bug you get a desync. If using floats I could also imagine there being issues with IEEE 754 architectures versus non-IEEE 754 architectures.

I had to find a copy of 'IE6 Full' on archive.org in the process of making this blog post. Most copies of IE6 are web installers.

I have to say I'm really quite irritated by Microsoft's habit of deleting old software from their download site, forcing people to get it from potentially untrustworthy third parties. I'm fairly sure there's some downloads on there that are just gone for good.

And, ah, wow. I was not expecting someone to mention IE HTAs here. Welcome to the club. ;) Another thing for the blog queue in the future, though frankly the number of IE-specific technologies is so large I should probably break it out into a separate series.

The claim that SMM is measured by (Intel) DRTM is interesting. Do you have any details on that? To my knowledge Intel was trying to solve this issue using the concept of an 'SMM Transfer Monitor (STM)' not simply by measuring the SMM environment [1]. But it's been 8 years since [1] was written so if you have links to more current information, it'd be welcome.

[1] https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf...

Except that it can't actually do that, because x86 DRTM doesn't remove SMM handlers installed by the system firmware, ACPI tables also remain resident and could be changed to contain malicious code, etc.

Can you explain how Intel Bootguard usefully guards against evil maids?

Looks like an URL reorg, it's now here: https://www.gnu.org/licenses/old-licenses/gpl-1.0.html

Breaking URLs isn't good; I hope gnu.org fixes this anyway.

Why would they even need to remove it from the UK appstore?

The logical course of action would be for Whatsapp to remove all assets they have in the UK from the UK (so there is nothing the UK government can hold hostage to extract compliance) and then disregard UK law entirely. If the UK wants to block Whatsapp or order Google/Apple to make it unavailable in the UK they could do so, but they could then educate people on how to sideload it on Android devices (and support continued antitrust action against Apple for the appstore, etc.). If the UK government tries to block Whatsapp at the network level, Whatsapp could enhance their application to automatically work around this using Tor-style, Tor Bridge-style/obfsproxy/etc. or similar techniques.

I believe the actual reason old IBM mainframe OSes is that computer programs originally weren't copyrightable. When the law was changed to make them copyrightable, this wasn't retroactive.

The AS/400 is, indeed, a truly weird system. Nowadays it runs as a VM guest on an IBM POWER system. Interestingly, it makes use of hardware tagged memory functionality in the IBM POWER CPUs. You can tinker with this stuff yourself if you have a Talos/Blackbird (or other POWER9) system, as I wrote about previously [1] [2].

[1] https://www.devever.net/~hl/power9tags

[1] https://www.devever.net/~hl/ppcas

This cannot come soon enough.

I like Postgres. I've used it in production in the past as a default choice. I want to like Postgres. But I find my enthusiasm for using Postgres again in the future severely dampened by just how bad Postgres's replication story is.

Currently, Postgres has two options for replication:

- Physical replication, which is not binary-compatible between major versions, meaning that upgrading your database requires downtime

- Logical replication, which doesn't replicate DDL (let alone atomic DDL)

This is frankly silly. It seems like PostgreSQL's storage layer hasn't been improved much over the years and is now becoming quite an issue. It's actually surprising to me, since the binary compatibility break with every major version you would think would give them exactly the opportunity they need to make improvements here.

This isn't even to go into other issues like the XID wraparound issue, etc. It's time the world's most advanced open source database had a decent storage layer.

I'll email you when I publish it. Until then you may enjoy: https://www.devever.net/~hl/auth

This assumes that a compromise of confidentiality is equally as undesirable as the ability to forge requests which change state. As I see it it's going to be fairly common to have applications where one of these things is much less desirable than the other. If confidentiality is less important than ensuring requests can't be forged, client certificates may be a bad option. If confidentiality is far more important (including against enterprise MitM) is more important than ensuring requests can't be forged, it may well be a better option. So it's a question of tradeoffs.

Of course there's also always the option to combine both and require both a client certificate and some sort of application-layer signature, for the best of both worlds at the cost of greater complexity.

I agree that the Cloudflare trend is a disaster though (as I wrote in my article about Cloudflare), people literally opting into having their traffic MitM'd.

Yeah. Of course, nowadays I believe you could replace <frameset> almost entirely with iframes and CSS layout. But it does occur to me that there was exactly one feature of frameset which you maybe can't replicate: the ability of the user to resize frames with the mouse without relying on JavaScript.

...Although, come to think of it, the CSS `resize:` property exists now, and it seems it can be used to make arbitrary elements resizeable. Might actually work for it, though the UI might differ a bit.

With a non-client-cert based authentication system, one can devise a common authentication scheme (AWS's v4 signatures being a good example), but then delegate implementation of that scheme to a centralised service (or a standardised library), rather than being reimplemented in every application service. But that service needn't be a public, user-visible service.

I think there's a distinction here to be made about whether an application should roll its own authentication (answer: no), whether an organisation should roll its own authentication (answer: probably not), and whether, when we are comparing unified authentication systems which do or could exist, including client certificates, whether client certificates are particularly good (my view: probably not). The question of who designed an authentication scheme, and when and where that scheme is actually enforced (on what machine, in what codebase), are, except in the case of client certificates, largely orthogonal.

(I just wrote up my thoughts on this in more detail and will publish that blog post sometime.)

Author here. There needn't be any cost for client certificates, since client certificates are frequently issued by custom in-house CAs for free. A more pertinent example of what you're talking about would be the use of S/MIME email encryption - I believe you could pay to get a proper certificate from a trusted CA for your email address to use S/MIME - I have no idea if any CA still does this or how many people do so. It's not something I've ever encountered personally, at least.

Author here. "Secrets in the perimeter instead of the core" is an interesting point. To my mind it can just as equally be a disadvantage - I'd usually consider the core more trusted and less exposed.

When deploying client certificate auth with HTTP load balancers, etc. you basically have to have the LB add a X-Client-Certificate: ... header and then trust that it's telling the truth. This means a LB compromise basically compromises everything, since it can just lie, whereas something like (for example) AWS's HMAC-based signature system (where the substance of a request is signed using a shared secret unknown to LBs) for its APIs wouldn't be.

So I actually find this a compelling argument against client certificates in practice. It's actually a curious example of how the security of client certificates might be worse in practice, even though theoretically superior on the client-to-server leg, because of the backend implications it creates.

Author here - yes, ISINDEX is on my radar. ;) Taking other suggestions also - I'm sure my memory isn't exhaustive. At some point I may venture into the weird proprietary extensions IE had also.

I don't believe it is known to have any firmware.

They won't be leaked, though. With a large western coompany like NXP, especially being that it's one with crypto-related business units, it's basically guaranteed that the keys will be in an HSM. There's always a slight chance they're inept and the private key is sitting in someone's home directory and they could decide to leak it, but in this case the chances seem very low.

Might have better luck with the Taiwanese hardware vendors - as I recall a major Taiwanese PC motherboard maker got hacked recently and UEFI secure boot keys were taken, so they probably weren't storing them in an HSM and don't have proper security practices in place for cryptographic material.

Both HDMI and DisplayPort can use HDCP. The authors of the DisplayPort standard also invented their own clone of HDCP called DPCP, but you can also use HDCP over DP, and it seems like HDCP is a lot more popular(?). In any case the DRM implications (in terms of lockdown and code signing) are the same. Though not explicitly mentioned in the screenshots of the i.MX8M reference manual shown in the article, reading the rest of the manual it's clear DP is affected too. (Which, again, is why the MNT Reform forewent the use of the DP interface to attach their eDP internal display in favour of a MIPI DSI to eDP bridge.)

I certainly agree that restrictive code signing practices like these are completely unacceptable. In my view, the 'right to repair' movement should encompass a right to any keys needed to fix bugs, though I am not optimistic about 'right to repair' being interpreted in this way.

Worth noting that while we usually think of DRM as a (patently ineffective) way to prevent piracy, in reality it seems to be much more about controlling end devices and the manufacturers of end devices. I explain more about this here: https://news.ycombinator.com/item?id=17588610

I've updated the article to clarify this. Thanks for the feedback!

Not sure what you're referring to. As I state in the article:

>Therefore, it is impossible to ever replace the HDMI blob used by this device. The device could be used without this blob, but you then forego use of the HDMI (or DisplayPort) functionality.

If you use the MNT Reform without the blob you can never use certain features of the device, namely the external HDMI port, so it's not as though the MNT Reform is without flaws. In any case the article is about the i.MX8M, not any specific device.

Author here. Yes - the obvious way to wire up the internal display of the MNT Reform would have been to use eDP directly, but since that would require use of the blob, they used the i.MX8M's MIPI DSI interface instead and used a DSI to eDP converter.

Author here. MNT actually went out of their way to make sure you could use the device without this blob: rather than do the obvious thing and wire up HDMI or DP to the laptop's internal display (both of which require the blob), they used the MIPI DSI interface and a DSI to eDP converter chip.

But yeah, if you want to use the external HDMI port on the laptop, you need the blob.

Author here. As the comment above notes, it's a leak of the signing keys which would be needed to free this. The actual blob itself can be reversed and replaced with enough of someone's time. The only other prospect is a flaw in the code which verifies the signature. The PS3 ECDSA break was an amusing example of this (though technically in that case, actually a flaw in the signing code, not the verifying code).

Author here. Not all HDMI/HDCP implementations work like this. Basically, the designer of the SoC (NXP) will have licenced an HDMI/HDCP IP block from some company selling such IP. It looks like NXP licenced their HDMI/HDCP IP from Cadence in this case, a major provider of silicon IP.

So this particular HDMI/HDCP implementation is designed to require this signed blob in order for it to function. Could Cadence have designed it so you can use it without HDCP without this blob, or use an unsigned blob and forego HDCP support, probably. But they didn't, so that's the situation.

It's completely broken if you don't have JavaScript enabled, for starters.

There is a variant of Opus called Opus Custom which is intended to support ultra low latency applications. Might be worth looking into.

There is also this product by the Nullsoft guys, no idea if it's any good though: http://cockos.com/ninjam/