Picard’s Uneasy Fandom

Captain Picard is back.

You’d think this would be cause for universal celebration. But not all the fans engaging with Michael Chabon’s instagram are thrilled with the new series. Their discontent reveals a science experiment being enacted upon tens of millions of people.

What happens to a piece of culture when its formative economics undergo a seismic shift?

Will its fans still recognize it?

Television economics

We have to start with how money shaped storytelling in the days of broadcast television. Here’s the quick, late 20th century version.


TV was expensive. The more credible your show, the more money you needed. You were shooting with film, editing wasn’t initially digital. This took work.

But! If you succeeded in making something that people fell in love with, you could sell it to them over and over and over again. So that initial, expensive investment? It gets paid back, many, many times over. If a new piece of IP really worked, it could pay you back for decades.

So how do you sell it to people? Back then, there’s no streaming platform to work this out for you. All you’ve got is broadcast television television stations. They’ll sell ads against your content to make money, they’ll use the money to pay you for rights to the content.

The golden ticket for your television IP was simple: reach 100 episodes. If you hit 100 episodes, you can sell the show for stations to air every afternoon. With 100 episodes, you can be on every weekday for five weeks without repeating. This was seen as the threshold for viable re-run revenue.

So that was the entire game.

Make 25 episodes every year. Stay on the air at least four years. Whatever your annual budget, you need to spread it out over a lot of shows.

These fucking people. 236 episodes of this playing multiple times a day in every single US market must have been a cash cow.

Not only that, every episode had to be self-contained. This model evolved at a time without streaming, and where recording shows was cumbersome. It wasn’t a guarantee that any given audience member had seen the episode played a week before. And if they felt lost, they’d tune out, along with your ad revenue.

So the economics conspired to make the average television series highly uniform, episodically self-contained and copious in volume.

Except where it didn’t.


Over at HBO, economics worked differently. As cable and satellite penetration increased, HBO found a niche selling access to content. Pay cable was the original streaming service. Tack a few extra dollars onto your monthly cable bill, you get access to premium movies without leaving your house.

HBO’s The Larry Sanders Show. They said “fuck” a lot.

But you can get movies anywhere. So HBO added something unique: original TV shows. For HBO, money was coming directly from subscribers, rather than ads. They didn’t want to re-distribute to anyone else, either. It was their differentiator. No need to rush to 100 episodes.

So instead, seasons were short. 8-13 episodes. Quality over quantity.

But this was anomalous. An exception to the rule.

Until AMC was on the brink.

The Prestige Explosion

If you’re my age and grew up with cable, you remember flipping past the bizarre edifice of American Movie Classics. They were continually playing black and white movies in weird aspect ratios, completely irrelevant to our cultural frame of reference.

This was a problem because eventually people my age developed favorable advertising demographics. Cable operators didn’t want to continue paying fees to include AMC in the basic cable lineup if a big proportion of their viewers were skipping it. The loss of revenue for AMC in this case would have been lethal. They needed to create immediate relevance.

So they started funding shows on the HBO model. Quality over quantity. Compelling enough that you needed to see what happened next season.

The result: an army of loyal consumers who would arrive at their cable operator’s office with pitchforks if they didn’t get resolution on Don Draper or Walter White. At the same time, the penetration of DVD players made it possible to buy or rent entire seasons of a TV show. You no longer needed to sell 100 episodes to a TV station. You could sell 30 episodes to individuals.

Picard’s transformation

Today, a lot of TV gets made according to this model. Streaming services have proliferated and they have the same sticky subscriber goals of AMC or HBO. Give you something unique, keep you coming back.

While Jean-Luc Picard has changed in the 20 years since we last saw him, television has changed even more. Here is the science experiment:

What happens when a shared narrative framework born to the old economics of television is reanimated, with full continuity, into the modern style of TV production? The change has unnerved some folks who were used to the old way of making these stories.

People can say fuck sometimes

Shit you not, people are complaining that there’s cursing in this series. Star Trek: The Next Generation had to be sold into re-runs to play in the afternoons and evenings when kids were at home. If they’d tried to slip anything racy into the dialogue, the advertising prospects get complicated. Better to keep things clean and presentable for all hours. To say nothing about the prudish FCC.

Of course, when distributed through the internet, anything goes. You need to opt into a specific stream and it’s assumed that parents have some basic control over the situation.

So on Picard, there’s language sometimes. The medium permits it and it’s hard to believe we lost interest in cursing between now and the 24th century. Besides: thousands of gifs don’t lie. The body language of these characters always implied cursing.

Mood, production design and pacing are different

An episode of TNG races through a story. It has to be self-contained. Things happen, characters do things and resolutions are provided.

Picard has no such rush. It’s a single story, told with the understanding that you are fully capable of watching it in order.

With over 20 episodes to get through each season, it saved time and complexity to keep everyone’s clothing consistent. Same goes for lighting.

Meanwhile, because quantity of episodes isn’t paramount, episodes don’t need to be made on an assembly line of identical sets and costumes. The Next Generation often felt like a televised stage play. Compact scenes in familiar settings featuring a handful of actors, as they hashed through an ethical or philosophical conflict.

By contrast, Picard shows tremendous range of mood and setting. We have everything from action scenes to tender conversations to philosophical arguments. We’ve been to France, to Starfleet Headquarters, to space, to the borderlands, to a Borg cube. We see a variety of clothes on our characters. Uniforms exist at the periphery, in a professional world that’s no longer our focus.

Elite crisis

But perhaps most striking, Picard arrives in a cultural context that is exhausted and disappointed.

Star Trek was always a political animal. Gene Roddenberry discovered that science fiction gave him a cloak for discussing political issues that would be too controversial to broadcast in the late 1960’s. TNG continued this tradition, tackling subjects including civil rights, environmental crises, the nature of war, even technology ethics.

Picard knows it is walking into a messy moment in human history. A moment where many of us have lost faith in our leaders and institutions. A moment where we see millions of people fleeing their homes just to stay alive, while those who are safe look the other way. A moment where it feels our technology is out of our control, and perhaps betraying us to shadowy figures we don’t fully see.

So the story reflects this. To meet its duties in the tradition it’s continuing, Picard has no other option.

Star Trek was always an idea about our best selves

There’s plenty you can critique about Star Trek. Its heteronormativity hasn’t aged well. It’s hard to imagine a future that straight in a present that’s so cheerfully queer.

Its erasure of religion ends up an erasure of many cultures, so we lose some richness in the humans it can represent.

And I could go on. But even if it didn’t always meet its own high standards for creativity and diversity, the intention of Star Trek was clear: help us imagine a better version of ourselves. I would argue it was successful in this.

“There’s a black lady on TV and she ain’t no maid!” — A very young Whoopi Goldberg

If Star Trek is to return in a modern form, many things are subject to change in its style and presentation. But its core responsibility is immutable: show us how our best selves respond to difficult situations.

In this, Picard is meeting its obligations to us head-on. We’re only four episodes in. The quality of its final execution is an open question and certainly subject to critique. It is a truth accepted since the first season of TNG that we are not guaranteed good Star Trek.

What is clear is that Picard wants to address the most pressing issues facing us right now. It wants to fulfill its role as a social imagination stimulant. It wants to support us by showing our best selves dusting themselves off and responding to a crisis of confidence in our leadership and institutions. It wants to show us what it’s like to try again after failing to make a better world.

We could certainly use the help.

Read more

Thread: How “The Measure of a Man” offers modern lessons in technology ethics.


Protect your digital identity from Google for $70 per year

I’ve never trusted Gmail. Google does too much creepy stuff, and they have zero customer accountability.

While there’s no escaping Google for some services, I think it’s reasonable to draw the line at email. It’s deeply personal content and the gateway to all of the rest of your internet accounts. If you used a Gmail account for your other account signups, and one day Google decided to take your account away, you could find yourself locked out of your entire digital identity.

Best of all, it’s entirely possible to assemble your own email service—if you can part with a few dollars each year.

Start with a domain

This part is essential. As long as you control your own domain, you can always decide where your email is routed.

If you do nothing else, register a domain. You can at least set up free mail forwarding from your domain to a Gmail address. If one day you need to leave Google in the middle of the night, you can redirect your mail forwarding to a new service.

I like Namecheap. Every registration comes with free whois masking, so no one can look up your address through your domain. Here’s a bit on how to set up email forwarding through Namecheap, but most registrars offer this option. Just search the web for [registrar name] email forwarding.

Once you’re using a custom domain for email, you have a lot more control over how you receive email. But there are limits to the free forwarding service that comes with your registration. It can be finicky to successfully send mail using your new address. For a fully-integrated experience where your address always works consistently for sending and receiving, you have to go further.

Add an email host

You can actually pay Google to be your email host. This is called Gsuite and it costs $5 per month. But the whole point of this is to get away from Google.

This is the beauty of holding your own domain, though: you can decide. If Google happens to be convenient for you, you can point your address there. If you’d rather keep your email private from a company like Google, you can use someone else. While it’s entirely possible to stand up your own server for email, dedicated entirely to you, with no other users, I’m not going to get into those details. Instead, there’s a nice middle ground between complete DIY and revealing all your data to a massive advertising company.

You can use a service like Fastmail, whose only ambition is to provide secure, reliable email for a reasonable price. Also for $5 a month, they’ll host your email and, if you want, completely configure your domain for you. Here are the details.

But Fastmail isn’t the only option. If you’re especially worried about privacy and security, you can use ProtonMail, which is headquartered and hosted in Switzerland. Mmm, Swiss privacy laws.

What’s important here is that, at any moment, you can point your domain to new service if the host you’re using doesn’t work out. Your emails won’t be trapped with one service.

Backing up your email

Web-based email is convenient but it means giving up a lot of power. When you use an email application on your local computer, you can be assured that all of your messages are stored to your hard drive. If you do automatic backups, your email will be safely backed up as well. If you host with Fastmail, they have complete documentation for setting this up on macOS, Windows and Linux. ProtonMail offers something similar, again with a privacy emphasis.

Coexisting with Google

After all of this is set up, you’ll probably still need Google for some things. You can sign up for a Google Account with your email address and not get Gmail. This is convenient for Google Calendar especially—most people seem to use Google/Gsuite for calendaring, so having your invitations automatically caught by Google Calendar is helpful.

Of course, for all non-email services provided by Google, you’re again at their mercy. But your email is safe.

Explainer Technical

ECDSA signatures with node.js and Swift

In the process of de-risking some business model questions for Digamo, I went looking for an open source project that would allow us to generate and verify license keys. We’re not sure what our business model will be there, but understanding the technical costs of licensing is important to making decisions.

While this is a problem that has been solved, I didn’t find anything especially modern, well-maintained, or documented—and nothing in Swift or Node, which I’m using for everything right now.

Some research did suggest that asymmetric cryptography was the way to go, using a private key to sign a registration string, and a public key distributed with the app to verify the signature. This was also the approach used in the older projects that tried to solve this problem for Mac apps.

Still, I found precious little documentation or tutorials to walk me through the implementation. All the signing examples took place within the same context, rather than between client and server. Here’s an approach that appears to be working, using Node and a Swift Mac app.

Try the demo

Generate a signed message file here:

Download, build and run the macOS verification app here:

Once the app is running, you can double-click the signed message files from the Glitch app to automatically load them. File free to tamper with the content of the plaintext field by opening a file in your favorite text editor, then try to verify again. Tampering should cause the verification step to fail.

The public and private keys are included for your inspection and experimentation, as a “known-good” configuration. In your own projects you should use care to ensure your private key is not distributed.

Generate encryption keys

Per the instructions from IBM’s BlueECC project, here’s how you get started:

On macOS you can install OpenSSL using brew:

brew install openssl

Once you have installed OpenSSL, create your private key:

openssl ecparam -name prime256v1 -genkey -noout -out ec256priv.pem

Using the private key, create your public key:

openssl ec -in ec256priv.pem -pubout -out ec256pub.pem

It seems you want to use the prime256v1 curve—other algorithms have some cross-platform issues.

This will leave you with a private and public key. The private key goes on your server to generate signatures. The public key can be distributed with your app to verify those signatures.

Signing with Node.js

The npm module EC-Key will make it easy to load your key:

let ECKey = require("ec-key");

let pem = fs.readFileSync("./privatekey.pem");
let eccPrivateKey = new ECKey(pem, "pem")

Here my implementation gets a little clunky—there may be better ways to do this, but at least it seems pretty flexible. Create a JavaScript object with whatever keys and content you want:

var objectToSign = {}
objectToSign.message = message
let date = new Date().toJSON() = date

Convert that into a JSON string:

let outputString = JSON.stringify(objectToSign)

Then, create a signature from that string:

let signature = eccPrivateKey.createSign("SHA256").update(outputString).sign("base64")

And pack the plaintext string and signature into a second object:

let outputObject = {}
outputObject.plaintext = outputString
outputObject.signatureBase64 = signature

You can then convert the output to JSON and have the user download the file.

See the whole thing in action with this Glitch project.

Verification in Swift

Add the BlueECC package to your project. Install manually, or use the Swift Package Manager. In Xcode, choose File > Swift Packages > Add Package Dependency…

Search for “CryptorECC,” and pick “BlueECC.”

Add your public key file to your project, and import CryptorECC
to the file where you’re working. Then you can grab the public key like this:

let filepath = Bundle.main.path(forResource: "ec256pub", ofType: "pem")!

let keyString = try? String(contentsOfFile: filepath)

let publicKey = try ECPublicKey(key: keyString)

With the public key loaded from your bundle into memory, you can now verify a signature with it:

let signature = try ECSignature(asn1: Data(base64Encoded: signatureBase64)!)

(signatureBase64 is the output from createSign() above)

let verified = signature.verify(plaintext: plaintext, using: publicKey)

The constant verified will tell you if the plaintext and signature match.

Here’s a Mac app you can build and run to see this in action.


Is this a good approach? See anywhere it could work better? Drop me a line: