Okay, so for the last talk of the day, we will hear Juliana that we'll talk about
consent-based secure collaboration with spurtly goblins object capabilities.
Yes.
So, hello, everyone, as was just explained, my name is Juliana, I work at the Spritly Network
Community Institute.
We are working on the next generation of the social web and my colleagues, Jessica Talon
and David Thompson, we'll have talks about our core technologies, goblins and hoot tomorrow.
There will be a QR code at the end of the talk, you can get the links to their talks.
But I'm talking about what I see as the biggest problem with collaborative and social
software systems today and how I think we can build better ones using, in fact, technologies
that we're working on.
So I didn't expect to have something in my hand and I'm messing up the talk.
So can you still hear me, okay?
So I feel that we build a lot of social and collaborative systems that are not based
on consent.
And I think that this is because historically, asynchronous communication didn't really
have the option of privacy, right?
We had mail and then later we had telegraph, telephone, radio, and you could have basic
encryption, but you couldn't have anything like we have now.
You didn't have centralized storage of messages, right, so that you could choose who
you wanted to see things.
And this sort of just became encoded in our society that we just assume that our communications
and our interactions will have to be public, they have to be out of our control, right?
And this hasn't been helped, let me make sure I don't mess this up again.
By the fact that big companies perpetuate this, right?
They sort of inherited these perceptions and they've just continued to run with them.
So we have Facebook and Twitter, which are big social platforms, right?
And they benefit from these systems of organization because, well, frankly, they profit
off of them because they turn user data into a commodity.
And so you have examples of post-serving, public by default, all of this.
And because it's profitable, they're disincentivized from protecting user agency, user data.
And even when they do have protections in place, these protections can be ignored and
they can be abused by the people working there.
So one example I find, particularly disconcerting, is Tesla.
Tesla records everything that happens inside their cars to train their self-driving.
And we've heard anecdotes of Tesla employees watching videos of Tesla drivers doing embarrassing
things, laughing at them, which, you know, kind of sucks.
And similarly, governments aren't really incentivized to protect user data either.
And user agency because they may have legitimate uses for this data, right?
As this information, that sort of thing, or they might be abusive governments.
We are standing in the EU, which has pretty good privacy and data protections, but I'm
from the US, but we don't have very good privacy and data protections.
And a few years ago, it was revealed that the NSA and US allies for that matter are collecting
a huge amount of information about humanity.
And again, even with protections in place, humans can violate those protections.
And we have Edward Snowden shared stories of his co-workers contracting for the NSA using
NSA surveillance data to stalk their access, which is, again, deeply disconcerting.
So what do we do?
And I think what we do is we build systems based first and foremost on consent.
And in order to understand what consent is, we have to understand what it's not.
It is not unclear communication.
If you sign up for Facebook, you're asked to agree to a term of, in terms of
service, which is a long document with legal jargon in it, it doesn't make sense.
Or, once you're on the platform, you might need to opt out of things, because you're
posted public by default, because Facebook can sell all this information about you by
default.
And this is stigmatized, right?
So to revert slightly to the political context, there's this saying, if you have
nothing to hide, you have nothing to fear, right?
And even if you feel that these conditions are too honest, and you don't want to use
these platforms, you might not actually have a meaningful choice not to, because of
network effects or social pressures.
Your friends are all in Facebook.
How are you going to stay in touch with them if you don't use Facebook, right?
If I'm sound like I'm picking on Facebook, it's probably because it's really bad.
But what is consent?
First and foremost, it's informed, right?
You're transparent about the context of the interactions.
You're transparent about potential consequences, and it's really granted.
It's actively chosen, right?
We assume in a truly consent-based system, we assume no by default, and then you choose
to give a yes.
And even when you do give that yes, it can be taken back.
You can say no at any time.
That's very important to consent.
And I think that the object capability paradigm encodes as much of a model of health
the consent as can be encoded in a technical system.
It's a relatively complex paradigm, where it seems to be at first at least.
So I'll try to summarize it quickly.
The basic idea is it provides both security and concurrency.
I'll be focusing on the security, but I'll mention concurrency a little bit at the end.
And it centers around capabilities.
Capabilities are actively granted, and they can be revoked as I'll show you.
And as I have there, it can model consent as far as consent can be modeled.
If you're a PL theory person, it is related to the actor model, which I find, I personally
find a useful analogy, and so I'll probably be talking about things in terms of actors
here.
So we have our objects, and they are actors, and that they can receive messages.
And in response to a message, they can create a new actor, and thereby obtain a reference
to that actor, where they can send a message, which can include a reference to another actor.
Or they can change their behavior in response to future messages.
And capabilities are just at the programming language level at least, which is the level
I'm most familiar with through Goblins.
They're just references, you know, pointers if you want to go down that level of a level.
And so here we see a user object with a reference, a capability on the object Gary, and
we see the user object sending the message Alice to which Gary responds, hello Alice, my name
is Gary.
These diagrams are from our heart of sprightly white paper, they're describing code.
They're not perfect for the things I'm going to be talking about, so I'll try to explain
as best as I can.
Capabilities can be limited, right?
So in the context of consent, you can consent to a specific thing and not, you know, all
of your posts being publicly available as another example.
And so here this demonstrates some code, it's a procedure that spawns two objects,
log in an admin, that have different capabilities on a collection of posts.
The blog can read them, but not write them, the admin can write them, but not read them.
And they can be revoked.
So this diagrams relatively complex, you can ignore most of it.
What's important is that we have the Robert object that has a reference to a, or a capability
on a proxy to the admin object.
And we have Lauren over here on the left hand side, who's paying attention to everything
Robert does, because the proxy is telling about it, and Lauren can choose to revoke Robert's
access to the admin object through the proxy, which in this diagram has happened, you see
the little, I don't know how to describe this very well, the little switch that's up, right?
And so in conclusion, I think that Ocaps models consent really well.
You have the necessity of explicitly granting a capability, because by default, you have
no capabilities, and you can choose exactly which aspects of an object's abilities.
You want to grant capabilities on, and so it's granular, just like consent in real life,
which allows you to build trust and empower collaboration, because you probably won't
meet a stranger and invite them to spend the night at your house.
You'd probably go out to coffee or something first.
You can invite them to your house if you want, nothing wrong with that.
I'm just very anxious person, so what do we actually do?
How do we build consent into our systems?
If you agree with my analysis and my proposed solutions, the first thing that I'm going
to advocate is using the Ocaps in protocol.
So it stands for the object capability network protocol, and it allows Ocaps systems to talk
to each other over arbitrary network boundaries.
And this goes back to the concurrency I was talking about earlier, so you can learn more
about this at Ocapsand.org or the GitHub page that I have linked there as well.
And the action items here are to join the standards group, get involved in talking about
what you want or need out of this sort of system, and the big one really is to implement
Ocaps and we especially need implementations in strongly typed languages, because in
spitely we use a Gile scheme, which is a dynamic language, and then the other big implementation
is in JavaScript, which is also dynamically typed.
You can also implement all of Ocaps if you want, so these links are kind of the literature
on Ocaps.
You write.org is preserving the knowledge of the e-programming language, which was the
first full modern Ocaps programming language.
And the longer link is to our Heart of Spritely White Paper.
You go to Spritely.institute press goblins, and then click Heart of Spritely, you can get
that as well, which is where the diagrams are from.
And you can also support us.
We're currently running a donor campaign, so I'm obligated to say, I'm not actually obligated
to say, but I do want to say, that's my boss.
You can go to Spritely.institute slash donate and give us money, and you can also write
software using goblins.
You can run it on the web with our boot compiler, which is a scheme to Web Assembly compiler,
and we really want this because we need to know what people actually want to build with
these tools, and what trouble they're having building those things, so that we can provide
the best tools possible.
And you can tell other people about this stuff, right?
In fact, your friends and loved ones as a book title puts it, and yeah, so that's that.
Thank you, everyone.
Thanks to the organizers of this Devroom.
If you want to see the rest of Spritely's talks tomorrow, you can scan that QR code to
get our blog.
Stop it.
Thank you.
So we have the last couple minutes of the day, if you have any questions.
Oh, no.
Everybody is tired.
I guess.
So, that's the hookup model of collaboration makes sense for managing access to, let's
say, branches on a Git repository, and maybe more fine-grained access than, and so things
like that.
So, I don't see why not.
You could, you'd have to design the sort of level above, because Git is not designed
from an Ocaps perspective, you would need to design an interface sort of on top of it
to manage access in an Ocaps friendly way.
But there's no reason you couldn't.
Yeah.
Thank you.
Yeah.
Hi.
I'm thinking about fatigue and giving consent in a very fine-grained way, do you have
any thoughts about that?
That's a good question that I should probably have foreseen a little bit.
Do you have any thoughts on this, Christine?
Well, I don't know.
I think one of the things that's important about Sprite Lee's goblins is that the consent
flow is actually fairly natural, and then it's a flows from the code and the interface
abstractions that you end up having.
So, there's two ways that you can think about this from a code perspective.
It doesn't end up being really honest to keep passing things around, because it's the same
way that you program every day is basically passing around arguments to functions.
That's exactly how the capability consent approach works.
The second one is that we're very interested in something called secure user interfaces.
There's a wonderful paper about this called Not One Click for Security by Ellen Carp
and some other of his colleagues, and he kind of shows how one of the big things that
they show with the capability based UI paradigm is that it kind of flows out of the natural
actions that the user is expressing that they intend to do.
And one of the big complaints that they ended up having at the end of it was that it uses
for, like, well, where's the security?
And the problem was that they expected to be inconvenienced, right?
They expected to be bothered for a whole bunch of things, whereas, you know, one great example
of this, which you're probably already familiar with today, is in your browser, you
can upload a file.
So in your browser, you can probably upload a file, right, to a web page.
But the web page can't download every file from your computer, it can't take anything
at once.
And that's because there's a consent-based flow there when you click browse, it has something
called a power box in capability literature.
The web, the file browser, has the ability to get a capability to that specific file.
So when the user selects that actually has a natural flow to be able to hand it to the
web page, and the web page didn't have that, and it just feels so natural users don't
really think about the fact that they're granting consent in that scenario, but it's very,
the very thing that they're doing.
And so it turns out that a lot of these consent flows, they're very similar to how people
interact with each other as human beings, where they consent actually flows out of the interactions.
Thank you.
So any last question we have about 20 seconds?
No.
Great.
Then thank you very much.
Thank you all.