By Nathan L. Walls

  • Sunset, Jan. 2, 2021/Williams Township
  • On Bougher Hill/Williams Township
  • Sunrise, Dec. 19, 2020/Williams Township
  • Sunset, Dec. 27, 2020

The Web has become an awful place to read

Somewhere in the past 10 years or so, the Web has become terrible for reading and readers. We don’t suffer from lack of writing quality, or quantity. Enough lands in my feed reader, via email newsletter, or on Twitter daily such that I will never want for something new to read. My queue of Instapaper articles or saved browser tabs will tell you this has been the case for some time.

No, I mean, the act of reading itself on the Web, in general terms, has gotten worse over time with outright hostility toward readers. The design of news sites, particularly regional and local newspapers that aren’t making the sort of nationwide play for subscribers that The New York Times or The Washington Post are have gotten worse.

I mean the slow accumulation of weight that modern sites have taken on. The sliding interruptions. Paragraphs that shift as you’re reading them because the surrounding ad positions have reloaded and the page text has reflowed. Autoplaying video, with sound, that “helpfully” moves itself to a bottom corner of your browser window as you scroll down the page. The newsletter modal after you’ve scrolled to read the second paragraph. It will offer a “Maybe not right now” passive aggressive dismissal.

It’s the alert message that tells you the site would like to send you notifications when they post new content. “Yes” or “Maybe later”. Never, “No, thank you, do not ask me again.” I’ve already breezed past the persistent cookie banner with several questions. I’ll come back to that.

The newsletter thing bugs me, because I see it so often on sites. Do I want, right now, to interrupt what I was in the middle of doing, to subscribe to a newsletter. Friends, I was in the middle of reading. I have seen it, too, where I go to site, having clicked on a link, from the newsletter, and see the admonishment to subscribe to the newsletter. I think because sites and their advertisers view newsletters as higher quality and thus more valuable than Web traffic. That feels right, but, also seems like punishing a reader instead of rewarded them with fewer obstacles and interruptions for doing exactly what the newsletter asked of them.

What a site could do, should do even, is shift the reader analytics tracking they’re doing for ad placements to smoothing the reader’s path. Skip showing that newsletter reader your subscription call to action.

The cookie banner bugs me severely. Ostensibly, this is a site telling you they’re saving your customizations and want to tailor recommendations to you. I think a lot of that, specifically, is bullshit. Being able to track what you read between different properties, that an ad provider can show you retargeted ads, from site-to-site. That it will do. It will also help feed Google Analytics and whatever profile Facebook has for you and whichever other ad tech vendors a site makes use of.

The analytics practice is a lot. Google gets to know tons about you as a reader. Sites get free analytics tools, but, that’s essentially a side-business for Google in exchange for acquiring more information. I think, too, site managers and owners don’t know how to treat or read the analytic data they have because they keep pivoting to video.

The other regrettable practice that comes out of this is click-chasing by lots of “news” sites rewriting stories from somewhere else. This is completely different in spirit from the early 2000s weblog practice of linking and adding some context or explanation for wonderful things. Jason Kottke still does this, and bless him for it. No, this practice leads to the Rolling Stone rewrite of an incomplete local news story, and then everyone riffing off of that. Rolling Stone and other sites do rewrites like this to attract traffic for ad positions.

Meanwhile, browsers like Firefox, Brave, and Safari have taken to reporting on what invasive techniques they’re blocking from sites. By comparison, Google’s Chrome is still advertiser friendly. It certainly helps Google’s business. Chrome, Firefox and Safari had lots of available ad-blocking plugins. Site ads become more intrusive and annoying. For a time, a lot of sites carried straight-up malware in their ads, because websites outsourced everything about the online advertising side of the. Malware ads carried readers away from the site reading to some tar pit with even worse practices trying to get victimes to install something nefarious or part with banking information.

It got worse. Advertising networks bought the ad blocking browser plugins and turned them into ads. Websites added plugin detectors to block readers from reading if they wouldn’t let the site’s advertising try to grift them.

Reams of first and third party JavaScript power these websites. Generally speaking, the HTML, and text of a website are overly complex, and simultaneously, aren’t all that much. But, ads, and these reams of JavaScript, sometimes video, cost readers in concrete device resources, device memory, CPU, and (potentially capped or otherwise limited) networking bandwidth.

Another contemptible practice is not even loading the whole article at once. Instead, a few paragraphs, separated by ad positions and then some manner of “Click to read more” button. I haven’t figured out the why here. The expensive page-retrieval and load has already occurred. Maybe it’s a manner of protecting against reader modes or other weird robot mitigation. It seems related to a largely disappeared trend to split web articles across multiple pages.

Now, let’s say a reader makes it well into an article, perhaps to the end. I hope that reader is expecting chumboxes, because that’s what’s there. In the past, a news article would have three or six terrible ads for get rich quick or lose weight fast schemes. Now, those lousy and deceptive visual ads will darn near infinitely scroll on some websites. Famous crypto surgeon knows the 30 second routine to clear out your offline wallet. Do this once everyday, and throw away this vegetable.

What I find frustrating is news sites have made putting any sort of news article in context much harder than it ought to be. Stories typically aren’t updated to point at newer, more complete information. It’s rarely possible to know if a particular article contains the most recent information a news organization has. But, somehow, simultaneously, looking through archives in a systematic fashion or even just browsing to past-days news is nigh impossible.

Substantial responsibility for the reading experience decline I’m describing lays at the feet of the news industry through a combination of the collapse of advertising revenue and a disinclination to maintain in-house expertise.

In 1999, at the beginning of my brief reporting and editing career, the newspaper I worked at, the Press-Tribune of Roseville, Calif., did not have an internal library. The company that bought it joined it with several other local newspapers in the foothills and suburbs east of Sacramento and cut staff, including the librarian. They sold off the presses, sublet the now empty half of the offices formerly occupied by the press, and printed the papers from a central facility in Auburn. Our work computers has small hard drives, even for the time. We could only keep two or three editions of the paper’s QuarkXPress files around before our managing editor came around and removed anything but established templates. After the paper went to press, a week or so later, we had no company-maintained record of what we’d printed. This working arrangement was pretty informative for where the rest of the news industry ended up by 2021.

The way this plays out online is archives start off terribly, and get worse over time. Newpapers change online publishing systems and URLs change, and it’s rare for a paper or news site to either redirect old urls or migrate the articles at the old address to a new system. The New York Times_ does it well, as does The Atlantic magazine. Lots of local news sites, however, do not, and our communities, local and online, are poorer for it. The attention sites pay to their site design has declined, apart from finding more opportunities to interrupt readers.

Collectively, reading any manner of long-form content online, particularly news, has gotten worse. The Web could be and should be so much more than it is. Faster pages, easy to find credible content, credible information that’s updated as circumstances warrant and doesn’t mysteriously vanish when a content management system changes. Reading online should not require megabytes of third-party JavaScript, should not require trading privacy and device security, substantial portions of device and networking resources, to read.

Readers deserve better.

2020 books

One of the things I like at the end of each year are seeing folks list of books.

My list for the year is here. My easy favorite was Ta-Nehisi Coates’ Between the World and Me. By subject matter, the book has been timely from publication, I was just late to pulling it off the shelf. As prose, it is one of the most astonishing written works I’ve ever read. The lines filled with spirit, not one wasted. It is a book I expect to return to often.

Group f.64, by Mary Street Alinder has also been out for a bit, but was another favorite. Alinder is Ansel Adams’ former assistant and biographer. Here, she turns her attention to the photographic community and broader spirit Adams helped found. It is deeply researched, taking the better part of two decades of work to get to publication. The endnotes and references are about one third as long as the book itself. Worthwhile.

Elsewhere, here are some end of the year book posts I appreciated:

I’ve started my 2021 books page. I have two books in flight presently, and I’ll add them to the page once I finish the books.

🔗 Links for Dec. 30, 2020

Cryptocurrency Start-Up Underpaid Women and Black Employees, Data Shows

Nathaniel Popper reporting for The New York Times:

The fast-growing cryptocurrency start-up Coinbase has been rattled in recent months by tensions between executives and employees who said they were being treated unfairly because of their race or gender.

While management at the company has argued that the complaints were limited to a handful of employees, Coinbase’s own compensation data suggests that inequitable treatment of women and Black workers went far beyond a few disgruntled workers.

The Coinbase figures arrived at by Ms. Marr took account of the job level of all employees, as well as their status as an engineer and manager. It is possible that if the analysis took account of more factors, the pay disparity would shrink.

In the 14 job categories at Coinbase with at least three women, the average woman earned less than the average man in all but two job categories.

Black employees earned less, on average, than white employees in all but one of the eight job categories that had any Black staff members, the analysis by Ms. Marr shows.

The wage disparities are compounded by the fact that women and Black employees were concentrated in the lower-paying jobs at the company.

It does not surprise me in any way to read this about a company whose CEO made loud noises about staff being “mission-focused” and apolitical at work.

It’s Peak Season for Tamales in Los Angeles

Tejal Rao, reporting for The New York Times:

The Mesoamerican dumpling, made with nixtamalized corn dough and a variety of fillings, has been around for thousands of years. Called tamalli in Nahuatl, a language spoken by Indigenous peoples in Mexico and Central America, it’s still referred to in its singular as a tamal, or tamale.

It can be a source of deliciousness, comfort, cultural connection or income, but the tamal is not a monolith, and there’s no single, correct way to make it.

Dr. Jeremy Littau: “I miss Christmas tamale season in California.”

Maybe You Don’t Need Kubernetes

Matthias Endler:

Kubernetes is the 800-pound gorilla of container orchestration.

It powers some of the biggest deployments worldwide, but it comes with a price tag.

Especially for smaller teams, it can be time-consuming to maintain and has a steep learning curve. For what our team of four wanted to achieve at trivago, it added too much overhead. So we looked into alternatives — and fell in love with Nomad.

We use Kubernetes at work. We’re a decently-sized engineering organization with several teams each supporting two or more applications. The complexities are worthwhile for us since our infrastructure team has a common framework for supporting applications deployed with Kubernetes.

For side projects, or a small shop, I would not start with Kubernetes.

The Frightening State of Security Around NPM Package Management

David Bryant Copeland:

I take GitHub’s new security vulnerability notifications seriously, and try to patch my apps whenever something comes up. I recently had trouble doing so for a JavaScript dependency, and uncovered just how utterly complex management of NPM modules is, and how difficult it must be to manage vulnerable packages. And I’m left wanting. I’m also left more concerned than ever that the excessive use of the NPM ecosystem is risky and dangerous.

The problem stems from three issues, each compounding the other:

  • NPM’s management of transitive dependencies that allows many versions of the same module to be active in one app.
  • Core tooling lacking support to identify and remediate the inclusion if insecure modules.
  • Common use of the same package.json for client and server side bundles.

This is an article from 2019, focused on NPM and JavaScript. More broadly, it’s a reminder to truly own your software dependencies. GitHub’s Dependabot is really helpful for getting automated updates, where they’re possible. It is insufficient to rely on it alone and so, the responsibility remains with project maintainers to stay aware and on top of security updates. Choose the your dependencies conservatively and wisely.

Russia’s SolarWinds Attack

Bruce Schneier:

The US prioritizes and spends many times more on offense than on defensive cybersecurity. In recent years, the NSA has adopted a strategy of “persistent engagement,” sometimes called “defending forward.” The idea is that instead of passively waiting for the enemy to attack our networks and infrastructure, we go on the offensive and disrupt attacks before they get to us. This strategy was credited with foiling a plot by the Russian Internet Research Agency to disrupt the 2018 elections.

But if persistent engagement is so effective, how could it have missed this massive SVR operation? It seems that pretty much the entire US government was unknowingly sending information back to Moscow. If we had been watching everything the Russians were doing, we would have seen some evidence of this. The Russians’ success under the watchful eye of the NSA and US Cyber Command shows that this is a failed approach.

And how did US defensive capability miss this? The only reason we know about this breach is because, earlier this month, the security company FireEye discovered that it had been hacked. During its own audit of its network, it uncovered the Orion vulnerability and alerted the US government. Why don’t organizations like the Departments of State, Treasury and Homeland Wecurity regularly conduct that level of audit on their own systems? The government’s intrusion detection system, Einstein 3, failed here because it doesn’t detect new sophisticated attacks — a deficiency pointed out in 2018 but never fixed. We shouldn’t have to rely on a private cybersecurity company to alert us of a major nation-state attack.

Schneier has the most level-headed, thorough, and considered write-up of the SolarWinds incident that I’ve seen so far.

Using Drafts

I was turned on to Drafts listing to the Back to Work podcast with Merlin Mann and Dan Benjamin, back when Drafts 4 was current and before there was a Mac client. If I recall correctly, Merlin was talking on the fact that Drafts was a good dumping ground for random bits of text that he could then decide what to do with.

It took me a bit to really grasp the promise.

Ordinarily, I work with BBEdit and Vim when I’m at my computer. Both are great for handling established lists, text manipulation, editing and so forth. But now, most things I write on the iPad, iPhone, and a fair amount of what I write on my desktop starts in Drafts.

BBEdit has some provision for temporary text in the form of its Scratchpad, something I use frequently. There’s a global Scratchpad and one available for each BBEdit project. I set-up a different BBEdit project for each codebase I use. Actively, I have snippets of text in two or three different scratchpads.

What’s harder, though, is starting a new document in one of these programs, because, pretty quickly, in wanting to save this text to disk, there’s a decision about what to call the thing I’m writing. Surprisingly, there’s some friction there, because besides giving the piece of writing a name, there’s the aspect of where it goes.

For ephemera, I don’t need the text I write to end up in a permanent file. I do need the text to appear across my devices and be easy to locate. Drafts does just that.

If and when I am ready to save an entry to a file, Drafts gives me that option. It’s plain-text. It supports Markdown. It syncs nearly instantly and it gets out of the way. Drafts also has Workspaces functionality, and wow, is it nice.

The iPad, an external keyboard, and Drafts, is a pretty idealized writing environment. It’s full-screen, (mostly) distraction free, when I let it be.

Here are the tasks I use Drafts for:

  • Building up shopping lists
  • Creating workout plans
    • This was more of a thing before gestures broadly all of this
  • Drafting tweets
  • Saving URLs for link posts
  • Writing blog entry drafts
  • Taking notes for work meetings
  • Writing most anything I haven’t figured out any particular structure to just yet
  • Composing emails, Slack messages, or anything i might paste into a web-based textarea
    • I find dedicated text editors drop words, letters, punctuation or flat out lose everything much less often than webforms textareas do
    • As with drafting tweets, there’s an added benefit in that composing offline means fewer opportunities for a hasty autocorrect or dropped error
    • On Slack, I avoid “Nathan is typing…” for minutes while I gather my thoughts, I’ve already done it once I send something

Once I’m done with the above, Drafts gives me several options of how to act on what I’ve just written:

  • Preview Markdown text as lightly-styled HTML
  • Save an entry as a text file
  • Send a tweet directly from Drafts, which is nice when I don’t want to open the hellsite directly
  • Send a tweet thread
    • The hack here is by writing in terms of a tweet thread, I will veer into just writing. At that point, I’m working on a blog entry and, as a goal, I would strongly prefer to publish more here than on Twitter.
  • Archive or delete the entry once I’m done with it, particularly ephemeral lists

It’s a valuable tool.

By any other name: What to call similar things

On a recent code review, one of my teammates was adding a new branch of code behind a feature flag to adjust how our site search weights potential results.

The existing code had a constant I’ll call RESPONSE_WEIGHT. The new branch added RESPONSE_WEIGHT_NEW. Both would co-exist while the feature flag was present.

Given this is a temporary feature flag that should be retired once the code is determined to be steady-state in production, going back through the code and taking out the feature flag and the old branch will leave RESPONSE_WEIGHT_NEW.

In a few weeks or months, I or another teammate are going to look at RESPONSE_WEIGHT_NEW and wonder what new means. If, we decide to further adjust search result weighting, RESPONSE_WEIGHT_NEW is an outright misleading name.

Appending a name with _new or _old is tempting because it doesn’t require a lot of creativity. It isn’t a great idea, because the new or oldness of it quickly loses context.

If there’s a need to separate functionality or naming by a feature flag, use a suffix like: _2020_Q1, which ties the name to a point in time.

This will also likely leave an earlier name around, and, context dependent, those can also change with a suffix _PRE_2020_Q1, if there’s not already a data quantifier on something.

Then, if and when it comes time to remove the feature flag, the code isn’t populated with now contextless _new entries. Similarly, the code won’t be looking at _new2 or _new_new.

In this case, the pull request feedback resulted in RESPONSE_WEIGHT_2020_Q1, which is more likely to remain an accurate name as long as it lives on in the codebase.

← Previous