Web Excursions 2022-08-01

Aug 2

Why the Windows Registry Sucks … Technically

the Registry is a filesystem.
- Sure it’s stored in a file, but so is ext3 if you choose to store it in a loopback mount.
The Registry binary format has all the aspects of a filesystem:
- things corresponding to directories, inodes, extended attributes etc.
The major difference is that this Registry filesystem format is half-arsed.
The format is badly constructed, fragile, endian-specific, underspecified and slow.

Hello Microsoft programmers, a memory dump is not a file format
- The format is essentially a dump of 32 bit C structures in a C memory heap.
- This was probably done originally for speed, but it opens the format to all sorts of issues
The implementation of reading/writing the Registry in Windows NT is poor

You might expect, given how critical the Registry is to Window’s integrity,
- that the people who wrote the code that loads it would have spent a bit of time thinking about checking the file for consistency,
- but apparently this is not done.
you can easily hide stuff in the Registry binary which is completely invisible to Windows,
- but will be apparent in other tools.
we have to write exactly the same bits that Windows would write, to be sure that Windows will be able to read it.

what counts as a “string” is not well-defined.
- A string might be encoded in 7 bit ASCII, or UTF-16-LE.
- The only way to know is to know what versions of Windows will use the registry.
Strings are also stored in REG_BINARY fields (in various encodings), but also raw binary data is stored in these fields.
some applications don’t confine themselves to the published types at all, and just use the type field for whatever they feel like.

the .REG format is not well-specified in terms of backslash escaping.
In addition the encoding of strings is again not specified.
- It seems to depend on the encoding of the actual .REG file, as far as anyone can tell.
- eg. If your .REG file itself is UTF-16-LE, then REGEDIT will encode all strings you define this way.

If you browse through the Registry some time you’ll see it’s a giant accreted mess of non-standardized, overlapping information stored in random places.
Some of it is configuration, much of it is runtime data.

Importantly, it’s not a database.
It should be a database! It could benefit from indices to allow quick lookups, but instead we have to manually and linearly traverse it.

you can create “unreadable” and “unwritable” keys.
These are “secure” from the point of view of Windows, unless you just modify the Registry binary file directly.
Windows also uses an unhealthy dose of security-through-obscurity.
- It hides password salts in the obscure “ClassName” field of the Registry key.
- The “security” here relies entirely on the fact that the default Windows REGEDIT program cannot view or edit the ClassName of a key.
- Anyone with a binary editor can get around this restriction trivially.

The Registry is obsolete, sorta
- Well the good news is the Registry is obsolete.
- The bad news is that Vista has introduced another, incompatible way to store application data, in AppData/Local and AppData/LocalLow directories,
  - but that Windows Vista and Windows 7 continue to rely on the Registry for all sorts of critical data, and
  - it doesn’t look like this mess is going to go away any time soon.

Brendan Eich, the author of JavaScript, thought that we'd use JavaScript bookmarklets to run arbitrary scripts against the DOM:
- They were a deliberate feature in this sense: I invented the javascript: URL along with JavaScript in 1995, and
- intended that javascript: URLs could be used as any other kind of URL,
  - including being bookmark-able.
- In particular, I made it possible to generate a new document by loading, e.g. javascript:'hello, world',
  - but also (key for bookmarklets) to run arbitrary script against the DOM of the current document, e.g. javascript:alert(document.links[0].href).
- The difference is that the latter kind of URL uses an expression that evaluates to the undefined type in JS.
- I added the void operator to JS before Netscape 2 shipped to make it easy to discard any non-undefined value in a javascript: URL.
Security policies have essentially killed the user script and bookmarklet ecosystem

the benefits of HTTP/3
- improves performance when switching networks,
- decreases effect of packet loss due to “head-of-line blocking” where packets are held up because the first packet is pending,
- faster connection establishment since QUIC allows TLS version negotiation to happen simultaneously during the first handshake round-trip,
- and in fact, zero round-trip time (0-RTT) skipping the handshake altogether for previously connected servers,
- more comprehensive encryption of transport-level headers and header compression.
At time of writing mid 2022, approximately 20-25% of web sites support HTTP/3.
Testing Browsers
- Cloudflare’s QUIC test page
- NGINX’s QUIC+HTTP/3 support page
On Firefox, about:networking will list the HTTP version detected for recently visited sites / hostnames.
Apple’s Safari remains the outlier, delaying the widespread adoption of HTTP/3 in all major browsers.
- Sometime in 2020, both macOS 11 Big Sur and iOS 14 introduced HTTP/3 as an experimental feature...
- which, alas, stubbornly remains ’til this day.
On macOS Monterey 12.5, performing the Cloudflare test above indicates Safari is now HTTP/3 enabled.
- And, strangely, on the Develop > Experimental Features > HTTP/3 remains off (unchecked)
- However, the NGINX test did not succeed unless the setting is turned on.
On iPadOS 15.5 / 15.6, this setting can be manually enabled under System Preferences > Safari > Advanced...