hpr-knowledge-base/hpr_transcripts/hpr3085.txt

Episode: 3085
Title: HPR3085: Architectures of Robust Openness
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3085/hpr3085.mp3
Transcribed: 2025-10-24 16:28:34

---

This is Hacker Public Radio episode 3,085 for Friday 29 May 2020.
Today's show is entitled, Architecture of Robust Openness
and is part of the series' social media. It is the 180th anniversary show of Ahuka
and is about 19 minutes long
and carries a clean flag. The summer is
a look at how to secure social networks against attack while still being open to strangers.
This episode of HPR is brought to you by archive.org.
Support universal access to all knowledge by heading over to archive.org forward slash donate.
Music
Hello, this is Ahuka.
Welcome to Hacker Public Radio and another exciting episode
and we are going to conclude our look at the activity pub 2019 conference
by taking a look at the keynote talk from day two of the conference.
Following this talk, there were basically birds of a feather sessions
that you would find at an unconference
and there is no videos of that for me to take a look at.
So this will be the last of the shows that we do on this particular conference.
And this talk by Mark Miller is Architecture of Robust Openness, which was very interesting.
And again, the link to the video is in the show notes along with a whole bunch of other links.
Mark Miller is an interesting fellow.
Been around for a while.
Wikipedia says he is known for his work as one of the participants in the 1979 hypertext project known as Project Xanadu
for inventing Miller columns, co-creator of the Agorac paradigm of market-based distributed secure computing,
and the open source coordinator of the e-programming language.
He also designed the, we are going to say Kaja, C-A-J-A, programming language,
and he is a senior research fellow at the Forsite Institute.
So obviously, someone with a lot of credentials, also with a lot of interesting ideas.
So his talk is about social networks that are robust against attacks but open to strangers.
So he begins with a historical overview that mentions how cooperation has spread as a dominant form of interaction.
That sometimes surprises people, particularly as a recovering economist.
It surprises a lot of economists who somehow feel that competition has dominated everything throughout the history of the human race, and it's not true.
Now, cooperation has been dominant. It's not always what happens, but it is the most common.
And our world today, for instance, is extraordinarily less violent than it used to be.
And again, you'll look at stuff like Syria, and think, well, what are you talking about?
But you have to be able to look at what's happening globally, and what you find is that it's a much better place than it used to be.
Now, what about the online world? Well, he says it started out as a place where you could reasonably assume pleasant and cooperative interactions, but something happened.
And the online world is not like that now. Now, he gives the example of junk mail. No one likes it, but we can manage it by throwing out the junk.
But in the online world, we got spam. It is not feasible to manually sort through and discard the junk in email.
And in looking at security, there is no perfect wall in the physical world since enough force will breach any wall.
But in the online world, we can have impenetrable walls through things like cryptography, which is close enough to perfect for our purposes.
But in the physical world, the attack takes some scarce resources of the attacker, and yet in the online world, the attacker can multiply the attack very cheaply.
So, there are differences that matter between the physical world and the online world, and it's good to keep that in mind.
Now, Mark says that he sees a trade-off between safety and cooperation, and worries that we will give up cooperation to retreat into a closed realm of safety.
Now, he wants to change the terms of the trade-off, because you can't get rid of the trade-off, it's inherent.
But by changing the terms of the trade-off, he wants to allow for more cooperation for any given level of safety.
Now, in order to cooperate in a decentralized environment, you have to address the problem of identity.
You don't want an attacker to impersonate you online, but at the same time, you don't want a centralized naming authority that can take your name away. That's censorship.
Now, Bitcoin has solved an analogous problem, since your key pair cannot be impersonated, and no one can stop you from spending your Bitcoin.
So, there are two fundamental safety problems we need to solve. One is proactive, the other reactive.
Proactive safety lets us act online in ways that do not create safety issues, but occasionally people will make mistakes.
So, we also need reactive safety as a kind of damage control when those mistakes happen.
There are two ways to provide safety, either through authorizations or through identities.
Authorizations get us to something called object capabilities, a very important concept that I will be talking more about in this series on social media continues, because I think it's a very important concept.
Now, object capabilities, which is the decentralized way of giving you authorizations.
Identity relies on centralized systems such as access control lists.
You must have an account to post here, you must register all these kinds of things.
Now, object capabilities is very good at proactive safety, while identity-based systems are best for reactive safety.
Now, he gave an example that I think helps illustrate this, and that is a car key.
The car key is the right that goes to the bearer of the car key to operate the vehicle.
Now, you can transfer that right, for instance, to the valet at the restaurant by handing that person the key.
You build proactive safety by who gets the key.
My wife, for example, has a copy of my car key, and I have a copy of hers, and that lets us cooperate in safety.
I don't need to tell my car that my wife is an authorized driver.
But what happens if I make a mistake and give a key to the wrong person?
I now need reactive system of some kind to fix my problem.
Now, how do we build a system that combines the strengths of both proactive and reactive?
If we start with a fundamentally access control system, we can add some authorizations features.
An example of that would be Polaris, Plash, and BitFrost.
All of these links in the show notes if you want to follow up on that.
Now, in the 1980s, a number of systems were built that were hybrids, like SCAP and CIS 38.
Now, Mark claims that neither of these approaches really worked very well.
And what we need to do is start with a pure object capabilities base and add ingredients to it that improve reactive safety.
The problem here is that an object capability system has some inherent tendencies to anonymity.
Think about trying to know who used the car when all you know is that, well, it was someone with a key.
So, in an object capabilities framework, if you decide a message was abusive in some way looking back,
you may not be able to determine where it came from.
Now, if you're not at all clear what we're talking about with these object capabilities,
I would say go back and take a look at the Serge Riklowski presentation that we talked about on keeping unwanted messages off the Fediverse that I think is going to illustrate some of this stuff a little bit better.
So, but think about object capabilities and permissions as I give you the permission to send me email and it'll come right to my inbox,
whereas someone I haven't given that permission to is going to have to maybe jump through a hoop or something.
That's what we're talking about with object capabilities.
So, let's say you get a message in an object capabilities framework and it's not signed, it's abusive.
So, someone got a hold of a right to send you something, but you may not be sure who it was.
Now, you could try into a hybrid of object capabilities with an identity list, but then you went into the problem that identities are designed to come and go.
And, you know, one of the things I think about is email address. I have quite a few of them.
I've had many more that don't even exist anymore, and it's a perennial issue of people move from one provider to another.
Okay, forget that old email, now I'm going to tell you my new email and everyone who knows me has to change their address book and, you know, it's a mess.
So, Mark suggests something, and he goes through several levels.
The first one he talks about is two-party intermediation.
We're in the party sending the message, logs the message, and who it was sent to, and the receiving party logs the message and who it was from.
Now, Hewlett-Packard had a system like this called scoopFS, simple cooperative file system, and I'm not sure I'm pronouncing that.
It might be scoops or something, but whatever.
And this will work only as long as you can prevent impersonation and censorship.
Now, impersonation is someone else impersonating you, and censorship is your name is no longer recognized.
So, in this system, you have to be able to prevent that, the names have to be meaningful to humans, and they have to be globally meaningful.
Now, no single naming system can do all three of those, but several systems together could accomplish all three.
Now, the next level is what Mark calls three-party intermediation. Consider this example. You call Uber to get a ride.
Sometime later, someone you have never met drives up. In a car you have never seen, and you get in it.
Similarly, the person who drove up is letting a complete stranger get into her car, and she drives off with that stranger.
Now, why would any of us do this?
Oh, the answer is that Uber is a third party that is essentially vouching for both of us to the other.
But, can either of the other parties know for sure that the person they are introduced to is independent of the third party?
So, suppose someone who works for Uber and wants to do something nefarious can use the Uber system to create a false identity and get into a car.
And, you know, commit robbery or some other horrible crime. You know, they're obviously, it's not a perfect system.
So, then Mark says that what he advocates is something called four-party intermediation systems.
We're only joint introductions, cooperate independence, corroborate independence, and that solves this problem.
Secure scuttlebutt is such a system where multiple people may attest to the identity of a participant.
So, that would be like someone who is known to both of us introduces me to you and someone else who is known to both of us introduces you to me.
And so, there's two other parties vouching that, you know, this person is who they say they are and as far as I know is not some kind of weirdo or criminal.
So, in secure scuttlebutt, multiple people may attest to the identity of a participant.
With this, you can then build a decentralized federated social network with naming integrity.
In other words, the names are not subject to impersonation or censorship that is also a network of consent.
But is it welcoming to strangers? Not quite.
The example I gave, there had to be these introductions going on.
If you don't have a way for someone not known to anyone to join the group, basically the group has completely walled off.
And instead of a network of cooperation, what you have are isolated subgroups.
And no one has any way to knock on the door.
Now, that would require a publicly open inbox of some kind to which people could send messages asking for admission.
If it's open, we still have the spam problem. Now, to get around that, you need to impose a cost of some kind on the sender.
Capture was an example of that. It's becoming less useful as people figure out ways to automate responses.
The whole idea of capture was that it was something that was going to require some effort on the part of the person sending the message to prove that they're human and not a robot.
And I, you know, the idea, as I mentioned in a previous thing about requiring, in fact, I think it was Sergei Riklowski's one where I commented on the idea of stamps being a really good way to at least cut down on some of the abusive messaging issues.
Now, the system that Miller proposes would hold people responsible for requests, responses, and introductions, which is more than an identity-based system can do.
And we have robust openness because there is no global naming authority. It's a skeptical aggregation strategy and a corroboration driven disaggregation strategy, and it is still open to strangers.
This was an interesting but difficult talk for me. I may not have done a really good job of grasping everything going on here.
A lot of the concepts in the language used come from object-oriented programming. And as I've said, I am not a developer, so some of that stuff is a little harder for me to get my mind around, but I did get a lot out of this.
You know, the fundamental problem that he's trying to deal with here, I think, is a very good one. How do we have good cooperative, safe communities that still allow others to join?
And I think that's an important consideration. So I thought it was a valuable talk to listen to. I'm glad I did. This will conclude our look at the activity pub 2019 conference.
It's quite possible. There will be another one in 2020. And if so, it's quite possible. I'll be reporting on that. But for now, I think I'm going to get back to taking a look at some of the applications and other concepts I want to dig into object capabilities more.
There's other applications like pixel-fed and peer-tube that I want to talk about. So there's plenty more to discuss here. But for now, this is Ahuka signing off for Hacker Public Radio and reminding you to support Free Software. Bye-bye.
You've been listening to Hacker Public Radio at Hacker Public Radio.org. We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself. If you ever thought of recording a podcast, then click on our contribute link to find out how easy it really is.
Hacker Public Radio was founded by the Digital Dove Pound and the Infonomicon Computer Club and is part of the binary revolution at binrev.com. If you have comments on today's show, please email the host directly, leave a comment on the website or record a follow-up episode yourself.
On this otherwise stated, today's show is released under Creative Commons, Attribution, Share a Life, 3.0 license.