They Made Me Write a Privacy Policy for This Newsletter (Trust is Rivalrous)

So, hopefully you are reading this and it's not stuck in your spam filter. Because it kinda took me a bit of work to even get this to your spam filter.

See, I came back to the newsletter after a bit away, fired it up, tried to send out a post and... it failed. After about an hour fishing around in the logs of my this Independently Hosted Newsletter I finally figured out it was failing because the mail service, Mailgun, that I use to deliver messages to you fine people was rejecting my attempts to send.

Why I need a mail service, and I can't just use an SMTP server, in just a minute.

So I fired Mailgun off a support request ticket and got back a (probably automated) response informing me my account had been flagged as "suspicious" and that to get unflagged I needed to answer some questions:

Please briefly describe how your business uses email.

What types of emails will you be sending: transactional, marketing, or both?

How do you source your email lists/contacts, and what are the URLs of these sources?

Could you please provide the URLs to your Terms of Service and Privacy Policy for our review?

What is your expected monthly volume of messages?

In an attempt to get unflagged I replied with answers like "This is a private newsletter" and "I don't have a terms of service or a privacy policy. I'm just trying to send a newsletter to a few friends."

That second one was deemed unacceptable. I was informed "In order to complete the business verification process and have the sending limitation removed, please note that we require you have a website with a privacy policy."

So I wrote them one.

I don't know whether that response met the requirement, or if it was tongue-in-check enough to prove I was a human with a tongue and cheeks. Either way, the next response from Mailgun support was from a different user support person (I suspect this one was an actual person) and informed me I was off double secret probation and could send newsletters again.

This isn't really a criticism of Mailgun though. In their defense, I am only using the free tier of their service, so given I paid nothing that wasn't bad customer support.

No, my larger observation is that trust is rivalrous. Back in the early days of The Internet, it was common to observe that Information Was A Public Good, especially given Digital Reproduction. Once made public, information is non-exclusive and non-rivalrous. You can't stop someone from using public information and someone using public information doesn't stop others from also making use of it.

This lead to a broad discussion about how to incentivize information production that I will not recreate here right now. What it tended to miss was the way in which other things, surrounding information, were in fact not public goods. They were rivalrous. Figuring out how to provision those and manage the power associated with provisioning them is an under-examined problem, and that's why I had to write a privacy policy for this newsletter.

Trust is a good. Knowing who to trust in an information packed environment is incredibly valuable. You really can't "do your own research."

And, in any kind of push medium, like email, consumers can't even possibly do the work to sort trustworthy from untrustworthy information fast enough to prevent the untrustworthy information from overwhelming their ability to use the channel.

All of this highlights how trust is trading on the scarce resource of attention. If you trust one source, another must be excluded. We must decide who to trust. We can't trust everyone.

Hence, the humble Spam Filter takes on ever more significance. But as the means for automatically generating text become ever more sophisticated, figuring our who to trust based on text alone becomes impossible. More signals are needed.

This is where Mailgun comes in. If I sent these emails from my own SMTP (email) server, the spam filters would eat them. Mailgun basically is a trust signal that lets my message get through.

So I have to work with them. Decentralized networks struggle with this! There may be no single point of control to allow someone to create or send information, but if they are going to have that information be received, they will have to pay for trust signals.

What's interesting about this case is that, because trust is happening on the back end, provider-side, it goes unnoticed. We know there are gatekeepers when we subscribe to a trusted information service. When a spam filter sorts for trustworthiness in the background, we might not notice it.

The power relationships embedded in these trust issuing bodies need to be examined because, as the AI moment progresses, they will only become more significant. For example, camera manufacturers are trying to signal which images can be trusted with a technology called C2PA (Coalition for Content Provenance and Authenticity) which will embed encrypted certificates in images at the time of capture to signify them as genuine.

It's striking to me that this technology, which I think might have alarmed people for its potential for control and surveillance five years ago, is now welcomed (I, for one, welcome it) as a method for dealing with fraudulent images created by generative AI.

But all this will need to be thought through and examined. Who gets access? How is it paid for? Who are we trusting and why?

Lots to consider.