Like many other people focused on their privacy, I run Pi-hole at home to block advertising domains, among other annoyances, and personally make extensive use of Privacy Badger and NoScript. The Pi-hole alone has the effect whenever anyone of the household is out of the building and not connected to our home's wifi, they get the jarring experience of seeing a completely different version of the web, plastered with ads, most of which are animated and attention-grabbing. This is especially true in mobile apps.

There's been a lot of lip service given to the way the “old web” used to appear versus how things are now, so I'm not going to do more of that here. I think what a lot of us “web old-timers” maybe don't realize is that how the web looks now is actually pretty common and has its origins in the way newspapers and magazines were laid out in the past.

If you've never had cause to go back and look at old newspaper archives, you might not have experienced this, so I'm going to show you some examples. You'll see the bones of modern web advertising buried in newspapers a century old, and then I'll explain what I think is critically different about how the web is these days. Spoiler: it's not better.

ref: https://archive.org/details/NYTimes_feb1_15_1921/page/mode/2up

You can see there's a few modern innovations in papers missing here — no “above the fold” style of breaking up the layout. Another trick newspapers did initially was to never put the ads on the front page — they were selling you the news after all.

Now onto page two:

ref: https://archive.org/details/NYTimes_feb1_15_1921/page/n1/mode/2up

This layout is common amongst the meatier news-focused sections of the paper. The first 5.5 columns are dedicated to news stories and then the rest is devoted to ads. Three are larger double-column spaced ads, while two are smaller and occupy the space in an ad. The rest of the Times' early layouts in the news sections were like this, with sometimes more space dedicated to ads on the lighter topics.

For example, here's the sports section: ref: https://archive.org/details/NYTimes_feb1_15_1921/page/n11/mode/2up

Here ads are placed in a very familiar format for the modern web; The ads effectively bookend either side of the center columns which house the articles themselves.

However, it's worth noting this layout was not universal. Here's an example of the Victoria Daily Times, from Victoria, British Columbia: ref: https://archive.org/details/victoriadailytimes19210722/page/n1/mode/2up

I can only imagine its print runs were much smaller than the New York Times. The paper lives on to this day as the Victoria Times Colonist, having merged with another local paper in the 1980s. Attempting to read this layout now, I understand why the format the Times is using won out over other layouts. The ads being so close to the article is visually distracting.

Now let's compare those older examples to modern web news media. Let's start with a relatively tame example: Yahoo! News:

ref: https://us.yahoo.com/news/sister-andr-worlds-oldest-person-183029182.html

Here you can see the remnants of the earlier newspaper design. The page is divided into roughly fifths, and a fifth is allocated to the side ads. All in all this doesn't look too unreasonable, but let's now look to what modern newspapers' sites look like. Here's the front page of the New York times:

ref: https://nytimes.com/

Because of the nature of the web and the drive to obtain impressions versus what works in print there's a huge functional difference: Each article is given its own webpage, so what is displayed on the main page landing page actually looks more like older newspapers, where a single viewing space — in that time period, paper, in ours, screen real estate — is subdivided into several articles. I don't have any insider knowledge or analytics but I believe that in today's social media dominated world, most users do not visit the front pages of newspaper sites, yet the philosophy persists of the relatively “clean” first page.

Now let's look at what happens when we load an article:

ref: https://www.nytimes.com/2023/01/19/us/politics/supreme-court-leak-roe.html

Here we can see probably the worst feature of modern advertising: the pop up modal dialog requesting subscription or registration. This is commonplace among all newspapers websites at this point in time and that's not news to any of you. On what should be an article page the title is not even visible! There are two separate subscribe buttons visible, plus our lovely “create an account” modal dialog.

Not that I'm unsympathetic, the trials of various news organizations are well documented so I don't need to go into them here. What I would like to highlight is simply that some philosophies and design elements in use a hundred years ago persist. For example, we still have the behavior of keeping the first point of arrival largely ad free. Not completely of course, because the tombstone of the 2015+ web will be engraved with “Subscribe, Click that like button, and share it with your friends”, but the front page is relatively ad-free compared to the hilarious experience of trying to view an article.

On that note though, the viewing an article experience is very reminiscent of the Victoria Daily Times' layout. Maybe they were right all along.

The problem this creates is that whenever I visit friends or family who aren't tech-savvy, I realize just how bombarded they get with advertising.

It also really drives home Google's impetus for working on DNS-over-HTTPS and Manifest V3: It will help them take back control over ad visibility in the era of every user using an ad blocker in their browser and things like Pi-hole becoming cheaper and simpler for people to run at home.

For today's rant I want to talk about libraries, their developers, and when not applying the Unix philosophy goes terribly wrong.

I'm going to talk about Log4J but I'm also going to talk about things like XXE and in general design choices that lead to headaches.

When you're designing a library that is intended to be used to tackle some important but common function, it's incredibly important that you keep the library as task focused as possible especially the core library and its defaults. If you need to extend functionality, use a pluggable architecture and make those plugins opt-in. The amount of headache that Log4J (the “log4shell” vulnerability really) caused the world is outsized to what everyone expected the library to do.

It's important to understand that users' expectations of what the library is doing are important. Log4J is not alone in this though. The log4shell vulnerability is very reminiscent to me of XXE. It's a feature that was enabled as a default to do some additional parsing that most of its users didn't want or need and that they didn't necessarily have visibility to.

Along those lines, if you're not familiar with XXE, AKA XML External Entity parsing attacks, the basics of the attack are this: – Attacker submits XML to server – Server parses XML – Server does a bunch of stupid shit like opening remote connections and sending files – Attacker laughs, possibly even a good cackle

When XML as a document standard was being ratified importance was placed on this idea of being able to validate the document against an arbitrary schema in order to make it flexible. It was important that schema specifications not just be able to be loaded from local files but could be loaded from central locations using a variety of different protocols. Examples of these are Gopher, FTP, or later HTTP. XML is very old.

Secondly, in XML there is this concept of entities — a shorthand within the document so that you can refer to some special character or a predefined standard blurb. You have likely seen these; the © that you would use to insert a copyright symbol in an older HTML doc is an entity (HTML having its roots in XML). When you combine these two things what it meant is that you could have remotely loadable entities that would get parsed and loaded on the machine that was processing the document.

Now because you might have some rather large entity, perhaps some boilerplate legalese that needs to be attached to each document, you might want to load that out of a local text file. You might make &legalese; into an entity that reads its data from /usr/lib/standard_disclaimer.txt.

This idea of document processor went from simple to unfocused, and because of these features you can probably see how with XXE you could often steal contents of files, reveal remote server locations, SSRF, cause a denial of service, etc., purely because this specification became overly complicated.

It was then made worse by the fact that as the web was evolving, nobody had a better answer than XML for a long time to do online document exchange. Since it was already a standard in business, it meant that it had the inertia and so there was no reason to change this. Ultimately you end up with major websites being vulnerable to all manner of XXE attacks purely because some support for some long forgotten feature was thrown in there. Even today this happens.

Enter the developer using it: It's not clear that this needs to be turned off, I just wanted to parse an XML document! They don't make any mention of this sort of thing anywhere in the documentation, so why would I think it's by nature unsafe?!

This is horse shit. We should expect better from our library authors. We should expect better from commonly used components. Importantly all the billion dollar corporations that make much of their billions leveraging this kind of software need to pony up, fund some pentests for these things, fund developer education, dedicate some resources to it.