hlandau

I haven't laughed this hard in a long time.

I'm honestly having difficulty telling whether this is real or an extraordinary piece of performance art.

I'm a bit confused.

This is described as being related to 'NitroTPM', which is described as a 'virtual device [...] which conforms to the TPM 2.0 specification'.

Ordinarily, the way you do attestation with a TPM is to perform a TPM quote operation, which provides a TPM-signed attestation of a set of PCRs.

This is... not that. This appears (judging by looking at the source code for some of the provided tools) to be invoking an undocumented(?) vendor-specific command on the TPM device which appears related to the previous Nitro Secure Enclaves support. When AWS introduced Nitro Secure Enclaves, they came up with their own signed attestation document format rather than reusing the TPM standard, then added support for that format to KMS.

The documentation also states: "An Attestation Document is generated by the NitroTPM and it is signed by the Nitro Hypervisor."

This seems to suggest that different entities are responsible for generating AWS's Attestation Document and for signing it, which seems rather odd. What's going on here?

If AWS's claims that NitroTPM is TPM 2.0 compliant are true, it seems like there are now basically two completely different APIs for remote attestation exposed via the TPM virtual device: TPM 2.0 Quote operations and AWS Attestation Documents via an undocumented(?) vendor-specific API.

I can understand wanting to take this approach for consistency with their previous Nitro Secure Enclaves API but it's at the expense of consistency with the existing TPM 2.0 standard. Presumably if you want to use KMS with this you have to use their Attestation Document format rather than a TPM 2.0 Quote, forcing you to use a vendor specific API with it.

Just some thoughts, and this is just my quick impression. I could be mistaken. In any case, having this functionality with a viable KMS tie-in is certainly valuable, so it's nice to see in the sense that you no longer have to create a Nitro Secure Enclave to get this kind of functionality if you don't need the dual compartments separated via a vsock.

Most webapps would be dramatically improved if the developers were banned from using any JavaScript on the client side in the first version, and allowed only to apply progressive enhancements from there.

This seems overcomplicated. Maybe I'm missing something, but is there some reason not just to define a psuedoelement on the current option?

  option::picker-current { ... }

With every new PostgreSQL release we see yet more features and sugar added to the frontend, yet seemingly no meaningful improvement to the backend/storage layer which suffers these fundamental problems.

I wish the PostgreSQL community would stop chasing more frontend features and spend a concerted few years completely renovating their storage layer. The effort in each release seems massively and disproportionately skewed towards frontend improvements without the will to address these fundamental issues.

It's absurd that in 2024, "the world's most advanced open source database" doesn't have a method of doing upgrades between major versions that doesn't involve taking the database down.

Yes, logical replication exists, but it still doesn't do DDL, so it has big caveats attached.

The underlying lesson here should be that centralised package registries are unnecessary, yet new language ecosystems keep making the same mistake.

There's really no reason for NPM or crates.io to exist.

Go got this right.

This is lovely.

This feels like a new genre of hardware hacking to me, where someone is motivated to make a device out of compassion for their family or others. It reminds me of this instance where someone designed their own peristaltic pump to ensure their grandfather can eat:

https://hackaday.com/2015/11/10/3d-printed-peristalic-pump-h...

I seem to recall another similar device to this posted on HN also, but with audiobooks.

On an unrelated note, the modern digital age does deprive me of my longtime love of removable media, whether analogue or digital. There's a mechanical satisfaction in having a physical token which is decisively inserted into something. USB drives just don't have the kinetic enjoyment of a floppy disk or tape. (Clearly the next iteration of the OP's design needs a motorised NFC card loader, ATM-style. ;))

Very nice!

Not free, but the "Technic", "Simplex" and "ISOCP" fonts included with AutoCAD are also of this aesthetic, if people want an exhaustive list of candidates.

Personally I've always considered it bad hygiene to commit generated outputs, but this article notes that this takes on a new significance in the light of supply chain security concerns. Good changes from PostgreSQL here.

Generated output, vendored source trees, etc. aren't, or can't be, meaningfully audited as part of a code review process, so they're basically merged without real audit or verification.

My personal preference is never to include generated output in a repository or tarball, including e.g. autoconf/automake scripts. This is directly contrary to the advice of the autotools documentation, which wants people to ship these unauditably gargantuan and obtuse generated scripts as part of tarballs... an approach which created an ideal space for things like the XZ backdoor.

The problem (at least for me) is input format support.

Assorted foobar2000 plugins support every obscure tracker format, every obscure video game music format (.vgz, etc.), and then foo_midi lets you render MIDIs not just with Soundfonts but with whatever VSTi DLLs you like. Also support for music files in ZIP files as well as music files in ZIP files in ZIP files (don't ask). That's hard to compete with.

foobar2000 is so good, and so unmatched, especially with its plugins ecosystem, I use it for my music playback needs under wine on Linux.

Interesting.

Are there better MCUs on the market for these applications (other than massively expensive actual 'rad-hardened' space chips)? You can get MCUs with lockstep dual CPUs, for example (TMS570 etc., and I assume the automotive sector has loads of stuff).

The context of this discussion is my claim that "the adoption of electric, centrally controlled doors was naturally motivated in major part by timeliness."

You're claiming that this is refuted by the Wikipedia article, but I don't see any evidence for that. To be clear, I'm open to evidence that this isn't the case, there just isn't any there, because it discusses motives for adopting centrally controlled doors in the 1990s when the technology for centrally controlled doors was already widely available. It doesn't tell us anything about the initial motives for developing the technology for centrally controlled train doors many decades earlier, just that later on an additional motive showed up which drove some additional (late) adoption.

I would absolutely consider prisons a technology, most obviously because we can see human societies where prisons are not a viable technology. If a member of a more primitive tribe starts killing people, the pragmatic solution is to kill them, not incarcerate them. Incarceration imposes technological (e.g. can you build buildings strong enough to hold people involuntarily?) prerequisites and high or extremely high logistical costs (see the cost of housing a prisoner for a year in the UK). You ultimately also need guards and the spare labour in society to be able to allocate to that task instead of potentially more important tasks, like obtaining food. Whether that is feasible will in turn be determined by human productivity in the various fields of production, in the case of food which is determined by the availability of agricultural technology (50% of the UK workforce used to be working on agriculture, now only about 2% to my recollection). Incarceration on the scale we see today is a relatively recent phenomenon.

Obviously such technology can be good or bad.

In my view the IT community falls into the trap of a narrow definition of the term, which now has been supplanted by an even narrower definition where technology just means "IT".

See the other thread above for my thoughts on the latter part. The adoption of a technology is done by the decision of a human. Nobody's claiming that computers have imposed themselves on society...

The first quote is simply a statement that central locking is safer. I don't think that's really disputed, but it's not the same as saying that it was the defining motivation, especially in the 1920s.

The second quote relates to the greater adoption in the 1990s. But this is far after the initial adoption by the London Underground in the 1920s, and presumably these safety issues during the period 1920-1990 weren't so great as to be a showstopper, even if a safer design is preferable. This suggests to me that there was some other, much stronger motivating factor behind the development of the technology in the 1920s on the London Underground, with safety being a trailing motivator.

The third relates to a design issue entirely orthogonal to the design of the doors.

Prisons are a technology as I define it, as is writing, agriculture, etc.

Author here.

In a word: yes. The universe is cold, ruthless, and does not care about us. I make no claims otherwise.

Society isn't that, though. Not least because nobody is particularly happy about the above fact and most people are trying to get away from it, not embrace it. And so, society is made up of people who have the capacity for empathy and adaptation to the nuances of others. So the relevant comparison here is not the timeframe before human civilization came to exist, but the society which existed prior to computerisation.

The adoption of computers within a society largely replaces human-to-human interactions with human-to-computer interactions, or interactions between humans which are now modulated and controlled by a computer (human-computer-human). That adoption trend inherently converts relationships between humans which are adaptable and contain a component of empathy, to interactions controlled by non-adaptive machinery with no capacity for empathy.

The adoption of computers as a technology within the context of a society seems, to me, to make society inherently more oppressive and less humane for this reason. (The main exception I would grant is computers only used by the people who have freely chosen to own them (as per comment above), and to which other people aren't subject to non-consensually.)

Author here.

This misses the point that computers are a technology. Like any technology, the choice to adopt a technology is always made by a human actor with some knowledge of the relevant tradeoffs. Ergo, wilful adoption of a technology which (necessarily) possesses the attributes I describe can be taken as tacit consent to those attributes and the collateral damage they cause. There is a human actor hiding behind every life ruined by "computer says no".

Saying that no technology is inherently oppressive is strange to me. Are prisons not by design an intentionally oppressive technology?

The human perception of agency in inanimate objects is curiously variable. To my understanding, this is a factor in why some people are more religious and some people are less so. Since my article is intrinsically written from the capacity to perceive agency as present in an inanimate object, it's perhaps less compelling to people who aren't wired this way, is my guess. This is not a criticism of anyone, just an observation of an interesting human neurological variability. Other constructions of the same argument are of course possible.

In any case, the point here is that a human actor decides to adopt computers as a technology; and that that act generally replaces a human interaction which was previously social, human-to-human, and therefore on some level adaptive and modulated by empathy, whereas a human-computer interaction is inherently uncaring. The adoption of computer technology in society has led to a generalised trend of replacing human-human (social) interactions with human-computer or human-computer-human interactions, which generally remove all opportunities for adaptation or empathic variation.

This leads to my view that computers as a technology in society are inherently oppressive.

Though I suppose one possible qualification would be that this possibly is only the case when applied as a technology by a different party to the party which will be subject to it. A computer in someone's home by their free choice, which is purely controlled by them (which is therefore not any modern computer, I should note) seems like an exception.

Author here.

Can you elaborate? I don't see anything to support this claim from the link you provide.

You are correct that the completion of the phase-out of slam-door rolling stock in the UK will relate to modern safety (and accessibility) regulations, amongst other factors. But that is different to what motivated the initial introduction of remotely controlled doors, which as that article states, dates back to the London Underground in the 1920s.

While it might be the case that centrally controlled doors are mostly more safe (with some exceptions), that mere fact doesn't imply that it is the primary motivating factor behind the historical adoption trend. So it's an interesting claim, but unless I'm missing something in the link I don't see it as supporting this claim?

Indeed, double-free, not UAF; I should know better than to write comments while sleep-deprived...

I suppose a cookie could be used in a "trust, but verify" approach if the free function takes both a pointer and a cookie. You would have the usual sidecar data next to the allocated region, but verify that the cookie matches. This would avoid the lookup issues you discuss.

My own view on this is that a hardened allocator API should separate the functions of an allocation identifier/cookie and the actual pointer to the allocated memory:

    func alloc(numBytes: usize) -> (ptr: void *, cookie: uword) | Error
    func free(cookie: uword, numBytes: usize) -> void

A design like this encourages segregation of allocator metadata and the allocated memory, though it is possible to achieve such a design with the classic C malloc/free API.

However, a design like this is even more helpful against use-after-free because cookies can be unique for the lifetime of a program, whereas pointers naturally get reused when a block of memory is reallocated. So the traditional API can never be fully resilient against UAF, whereas an API like this can.

The underlying observation here is that malloc/free couples two different things (access to memory and identifying a previously made allocation) in a way that creates an API which is far less able to mitigate misuse in a safe way. IMO, these functions should be separated in new designs.

See comment below.

More generally what I'm seeking is something in the card form factor which is suitable to store cryptographic secrets (i.e., a smartcard).

Separate IC is a disadvantage here since it creates a vulnerable security boundary and makes it infeasible to integrate the chip into a thin card.

This is interesting but clearly not intended for security/cryptographic applications... no security hardening, no hardware cryptography, and it's also not available in a card form factor according to the datasheet.

The NFC chip I want still doesn't exist: a CPU and flash I can write a program for, directly, no VMs, no Java, without an NDA'd datasheet.

These exist, but they're all behind NDAs and you're not allowed to have them. They're used for e.g. EMV.

The Great Wave is fantastic art and I'm getting a bit tired of seeing it overused everywhere. This is going to make that even worse.

It's good to celebrate outstanding artwork but having it in everyone's face all the time is antithetical to that.

From my perspective, TF2 was ruined the moment microtransactions became involved.

The point of a game, from my perspective, is that it allows people to compete in a game of skill or chance (or some mixture of both) in a way that is independent of a wider socioeconomic context. For example, it doesn't matter if you're broke or a billionaire when playing chess. That's the point.

As soon as a "game" starts involving microtransactions where your real world finances determine the probability of you winning, it's not a game anymore, it's a casino. It defeats the object of a "game"; it is unfair.

If items are purely cosmetic it's one thing but we're talking about items with different gameplay attributes here.

Imagine if chess was invented today and the IP owned by a company. The entire world playing chess and then suddenly, the owner of the IP would announce that from now on, you can pay $20 and restore a piece to the board. This would of course be insane and defeat the object of the game. I also feel like it would quickly become socially unacceptable for people to invoke this option when playing chess face-to-face. Behind a screen, though, people are moderated from one another and it's an option.

Of course this is a wider comment on "F2P" games in general and why they're not valid as games in my view.

The fact that Valve doesn't allow mods of TF2 when they allowed mods of their other Source games is very telling.

Yeah, the low quality and informal "tutorial" presentation of the RISC-V "specification" has always been very jarring to me given the popularity of RISC-V.

The authoritative description should be machine readable, but the PDF also needs to be authoritative. That means the PDF needs to be generated from the machine readable spec automatically.

I think the highest quality ISA spec in the industry at this point is ARM's ARMv8/9 ISA manual - it's a readable PDF with psuedocode in a well defined language. Every ISA rule is even given a unique identifier. But even better, it's all generated from XML source files which ARM releases, so you can parse the psuedocode out of those and run that code directly if you write an interpreter for it.

I was hoping to see ARM also release this XML for ARMv8-M but last I checked they haven't done so, sadly.

It's highly worthwhile to examine different ISA manuals to compare their relative approaches (e.g. Power, SPARC, ARMv8, Hexagon, s390x, Itanium, etc.). But I think ARMv8 is the best.

CGNAT should be illegal.

Or at least it should be illegal to advertise a CGNAT service as an "Internet connection". It's not an Internet connection, you can't use it to send or receive arbitrary IP packets, only TCP/UDP.

My mail server has been known to deliver mail to Gmail using IPv6 if I don't tell it not to. Not sure if Gmail will use IPv6 for incoming mail though.

I've never tried to use passkeys, but determined a while ago my hard, non-negotiable, a priori requirements which would have to be met for me to be willing to use them:

1. I can, if I choose, have a passkey in software (no hardware enclave, no captive key, no TPM) even if the security of that sucks:

  => Implication: I can backup and copy a passkey without restriction, e.g.
     putting the key material in an airgapped password safe, and without that
     being visible to a website.

  => Implication: Websites can't discriminate by whether I have a passkey in
     software or have any part in deciding whether I get to backup, copy or
     transfer a passkey.

I haven't looked into this yet, so: do, or can, passkeys, or the contemporary WebAuthn implementations in Firefox or Chrome on Linux, meet my requirements?