varx @varx@infosec.exchange

Specifically, I'm wondering if a few celebrities getting killed by Teslas might be enough to spur some legislation against self-driving cars and quash the whole thing.

I wonder if self-driving cars are going to have a "nuclear safety effect", where the early models are actually dangerous and then by the time safe ones are developed, it's too late -- popular perception is already established.

The UN continues to push back against the UK's occupation of the Chagos Islands:

https://www.theguardian.com/world/2021/may/16/un-favours-mauritian-control-over-chagos-islands-by-rejecting-uk-stamps

I wonder if this will eventually cause disruption to the .io domain space.

...I kind of hope it does.

A decision!

If the ID has to be transformed for use, then IDs become implicitly bound to that transformation; if the protocol changes, old IDs might have to be stored differently from ones generated after the change.

That's enough to tip the balance in favor of simplicity.

Downsides:

- Less implementor freedom; maybe in their situation case-sensitivity is always available and they can actually make shorter IDs using base64.
- Chance of incompatible base32 implementations (there are at least two variants).

Upsides:

- Less data stored and copied around for most people.
- If someone needs to unexpectedly move their data from a case-sensitive to a case-insensitive environment, less chance of bugs on move.

Protocol design question!

There's an ID field that I *strongly encourage* implementors to generate by base32-encoding 8 random bytes, since that's 1) enough entropy and 2) broadly safe in URLs and filenames.

I could shrink some largish files by 4% if I instead specify that the 8 bytes are just stored as binary, and get base32'd before use.

Is it worth it?

The basic idea is that you prepend a zero byte to the data, then walk through the bytes (starting from the first one) and replace each zero byte with a byte indicating the distance to the next zero byte (or end of data, if you've reached it).

And then you stick a zero on the end to say "this is the end".

There's some additional detail, like chunking into 254 byte pieces when there aren't enough zeroes, and some optimizations, but that's the idea -- the zeroes turn into a linked list. 😁

It's a way of adding framing to a stream of byte data so that you end up with an unambiguous sentinel value to mark the end of the stream. You don't have to know how long the stream is in advance, although you do have to be able to look ahead 254 bytes.

What you end up with is a stream of non-zero bytes, ending in a zero byte that means "end of stream".