Platy’s Web Excursions

Share this post
Web Excursions 2022-08-01
platylinks.substack.com

Web Excursions 2022-08-01

Platy Hsu
Aug 2
Share this post
Web Excursions 2022-08-01
platylinks.substack.com

Why the Windows Registry Sucks … Technically

  1. It’s a half-arsed implementation of a filesystem

  • 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.

  1. 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

  2. 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.

  1. Types are not well specified

  • 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.

  1. Interchange formats are not well specified

  • 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.

  1. The Registry arrangement is a mess

  • 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.

  1. The Registry is a filesystem

  • 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.

  1. Security, ha ha, let’s pretend

  • 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.

  1. 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.

I Miss The Programmable Web

Date: D.2022-08-02

  • 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

Browser Support for HTTP/3 QUIC | myByways

  • 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...

Share this post
Web Excursions 2022-08-01
platylinks.substack.com
Comments

Create your profile

0 subscriptions will be displayed on your profile (edit)

Skip for now

Only paid subscribers can comment on this post

Already a paid subscriber? Sign in

Check your email

For your security, we need to re-authenticate you.

Click the link we sent to , or click here to sign in.

TopNewCommunity

No posts

Ready for more?

© 2022 Platy Hsu
Privacy ∙ Terms ∙ Collection notice
Publish on Substack Get the app
Substack is the home for great writing