Okay, can you hear me?
Okay, great.
I'm Morgan.
I've ever had presentation or introduction.
Good morning.
afternoon, whatever the hell it is.
I made this mistake in the past.
Let's kill this guy so we don't have that all overlay.
Perfect.
So, I'm Morgan.
I am the developer of Gosling and Refrersh working for an organization called Blueprint for Free Speech.
We are a nonprofit kind of focused on journalists and mobile protections.
And I'm not doing that.
I am also the browser team late at the Tor project where we are eye over the team of eight engineers developing
Tor browser, Tor browser for Android and mobile browser.
But today, I'm here talking about Gosling.
So, what is Gosling and what does it do?
Gosling is a rust library for developing peer-to-peer applications that has all of these
lovely properties.
And then encryption for secrecy, anonymity, whole-punching, financial circumvention, client
authentication, metadata resistance, and optional applications specific authorization extension.
So, I'm going to go over all that stuff.
So, it's built on Tor and unanswered services.
Jeremy talked about unanswered services a little bit beforehand.
This is a kind of a short talk.
So, I'm not going to go into the details of how Tor and unanswered services were
specifically.
I kind of assume this crowd probably knows it already.
But the main high-level idea that we need to understand is that the Tor network allows
you to connect it up to endpoints anonymously.
And then unanswered services are kind of the reverse of that where people can host services anonymously.
And they're only accessible for the Tor network.
So, how does Gosling work?
So, Gosling is a library is kind of like live P2P in the sense that you use it to build peer-to-peer applications.
Every user has an ID, an unanswered service ID, which turned it over earlier.
This ID serves two purposes within Gosling.
So, one, it's a destination.
And then point, it's an unanswered service that you connect to and you host.
And finally, it's also an identifier that's used for authenticating clients that connect to
an unanswered service.
So, in a Gosling peer-to-peer network application, every peer-to-peer hosted an unanswered service.
And if you want to connect the peers, you connect it to their unanswered service.
So, we get an encryption with forward secrecy by default because we're going through Tor.
You get anonymity for free because again, you're going through Tor.
There is no way to leak your actual IP address by using Gosling.
Presuming you don't do something silly, like as part of the optional application extension.
Say, hello, my IP addresses.
One, I just hear a point, whatever.
If you don't do that, then you can't leak your IP address.
But that's on you.
There's no central register, no signups, no need to associate.
You're earning a service ID or your peer ID or you want to call it with actual identifying information.
Again, because you're using Tor, you get a whole bunching for free.
You only need to make an outbound connection from your computer to the Tor network.
And you get, since it's your convention, again, with Tor.
So, there's, again, no authority or gatekeeping.
Nothing stops anybody from hosting an unanswered service.
If you can connect to the Tor network, you can create very easily a new unanswered society.
If you want to get rid of that and make start over, you can do that.
It is very straightforward, and there's no overhead and really doing this.
So, you might be thinking to yourself, okay, that's really cool.
So, you host unanswered services on Tor.
Good job.
This is where we actually get to value out of this.
Client authentication.
So, in the Tor network, unanswered services are self-authenticating.
If you can connect to an unanswered service, you, as a client, understand.
This is actually the endpoint that I am trying to get to you.
There is no possibility for a man, man, man.
Excuse me.
A machine in the middle of the hack.
There is no possibility of somebody else having like,
swap the entity or redirected the DNS request or whatever.
You can, as a client, have certainly that if you connect to an unanswered service and the connection exists and it succeeds,
you know you're going to the endpoint that you think you're going to.
The problem is this is supposed to be an authenticated peer-to-peer system.
So, how does an unanswered service verify that a client coming in is who they say they are?
So, clients using Gosling basically make a claim that they are the owner of some's unanswered society.
I mentioned earlier that unanswered service had these sort of two parts.
So, what you connect to and also who they are an identifier,
a unique identifier per client.
So, an unanswered service ID is actually a public key.
That's specifically it's an ED25519 public key.
Again, it's certainly mentioned in the previous talk.
If a user connects to your service and they claim that they are the owner of an unanswered society,
what they're actually claiming is that they own the private key that was used to generate that public key.
So, to verify that a Gosling client which connects to a peer connects to a peer's uninservice,
we basically ask them to sign a particularly crafted message proving that,
okay, you claim that you're, you know, ABC once you see that onion, prove it with photography.
So, that's the sort of client verification side of connecting to a verified host.
In addition, we also have optional application-specific extensions.
So, a lot of this is inspired from Ricochet Refresh, which I kind of mentioned earlier,
and part of that protocol involves, basically presenting a message saying, hey, you know,
I'm so, and so, I would like to add you as a contact.
And so, when designing Gosling, we were like, okay, but we kind of need that sort of idea,
we don't want, like, hard to code it to make it only work in the asymmetric context,
but also work in any kind of peer-to-peer application context.
So, there's a little part piece of the protocol that allows you to send arbitrary messages along with the protocol
that allow you to build these application-specific extensions.
So, you can add in functionality like peer block lists, or allow lists,
invite codes, proof of work, or state schemes, or whatever.
And finally, you get metadata resistance.
You get part of this, almost of this, just from uninservices.
So, all the communication contents are end-in-accripted,
and stay entirely in tour network.
Clientities are not exposed at all.
And there's no way to know which peers have connected to other peers,
because all this sort of information is only known to the peers involved.
So, it sounds great.
What's the problem here?
So, one problem with uninservices is that,
if you know the uninservicity, or the endpoint of an uninservist,
you can tell a bit's online.
So, you might think to yourself, well, that's true of any kind of thing.
You know, if I know CNN's URL, I can tell CNN's online,
if I've internet, I just connect to it.
So, the problem with that is that applications,
which use uninservices in this way, for instance,
because they refresh, are not servers on internet somewhere.
They are actual people who use actual computers and have actual lives
that correlate with their uptime of miscomputers.
So, one of the problems we wanted to solve was,
we didn't want arbitrary people who just happens to know your username
or your PDI in this context to be able to sell
if we're using your computer or not.
So, and then one other caveat here is,
an uninservist client authorization doesn't solve this problem.
So, this is a little tour feature that requires you to have a particular key
in order to, additional authentication information
needs to connect to an uninservist.
But the problem is that even if you don't have the key,
but you know the uninservist ID, you can still determine
if the uninservist was online over a certain window time.
So, it doesn't solve this problem,
but it does decrease the time resolution of kind of knowing
when people are online or offline.
So, we kind of call this problem a cyber stalking,
where, you know, if you know the service ID,
you can kind of simply figure out their online or offline.
At best, it's just a privacy violation.
If you are a malicious third party,
you can get a profile of somebody's online offline status.
In a quite malicious third party,
you can potentially discover your guard node.
So, for example, you can enumerate listed guard nodes.
If you have some sort of DDS botnetwork,
you can just verify if somebody's online,
DDS hardknock off a guard node,
see if the user goes offline,
it kind of steps through the guard nodes this way.
A very malicious third party could use legal interventions
or hacking or running malicious guard nodes to identify
the actual IP address of an uninservice using this online offline profile.
So, we wanted to avoid that in general case.
One other little thing here is that if you are using
one of these types of applications that use an uninservice
as your endpoint that other peers connect to,
but you don't broadcast your service ID,
then you're fine.
If you can trust the people you've shared it with,
to not try to dox to you or discover where you are,
or whatever, then you're fine.
Uninservices are not generally enumerable.
So, if you're running an uninservice,
and you never tell anybody what the idea is,
then nobody can tell that it's online or offline.
All right.
So, what we want.
We want authenticated peers to be able to connect to each other
and communicate.
We want authenticated peers to not be able to determine
people's online or offline status,
but you also want authenticated peers to have a pathway
to be coming authenticated.
So, obviously, you can't do all these things at the same time.
And a lot of these types of applications
kind of require you to share your service ID
for basic functionality.
Like, if I want to chat with a friend,
I have to tell them what my username is, right?
So, the solution and Gosling is to split the responsibility
across multiple uninservices.
So, you just have one identity service,
which is used as basically as an introduction point.
And so, again, insert the instant messaging context.
This is the ID that you would give people
to invite them to chat with you.
And so, they would connect to this uninservice
and then the Gosling protocol will one verify
if you'd actually want to be friends,
want to be peers or whatever.
And if they succeed this handshake,
then they are given their own,
especially unique uninservice.
They are allowed to connect to you.
And that's for the actual application logic happens.
So, basically what this means is that
to acquire new peers, they have to go through
your identity service,
but if you don't need any more peers,
then you can just turn that identity service off
and then all of your friends or contacts or peers
or if you want to call them,
each have different endpoints they connect to you.
And if you ever want to revoke their access,
then you can just stop running your uninservices.
Oh, that's what I talked about,
basically this now.
So, the basic plan here is you can't,
or basic ideas that you can't solve the problem
in a general case,
but you can give users control over their visibility
and what they share and what sort of metadata
they expose about themselves.
I think I feel like I've blazed through this,
but that's fine.
I have a whole bunch of links to documentation.
We have a design doc, a protocol spec.
A usage guide, along with both a rust
and a C++ sort of example,
toyed chat application, which kind of lets you
interact with and play with a protocol
and sort of the stepwise command line away,
and also create documentation because it's rust.
There's a little screenshot of the example application
you kind of see that where you kind of like
store your identity service,
stop it, start endpoints, end endpoint,
send messages, that type of thing.
List of peers I connect to you.
This rust version, which just uses the trade directly,
and a C++ version, which uses the CF5 version.
Okay, a couple of shout outs from the organization I work for.
Work for.
We have this no slot project, which is a sort of project,
which helps journalists and whistleblowers
and organizations defend themselves against
frivolous losses, which are kind of weaponized in Europe.
This underdevelopment sterves project, which aims to sort of support
whistleblowers.
And of course, my two little tools or some of my tools I work on,
Rick Shade refresh, which is kind of inspiration for this whole library
and the idea of peer-to-peer earnings service applications
and reducing this sort of exposed metadata.
That's currently under active development,
thanks to a grant from NL that.
And then something which people might find useful,
they don't find gosling useful, is a great call for interface.
We look it up on crates.io.
It basically encapsulates a lot of the nonsense
of integrating legacy toward Yemen,
as well as the new already implementation,
and kind of wraps all of that stuff in a relatively simple
and somewhat opinionated API service.
So if you want to integrate towards your service
into your application, or you want to programmatically
start or stop running services or kind of things over toer,
you should give this a great check out.
And that's that.
I have so much time for questions, I think.
Thank you.
There is indeed plenty of time for questions.
So let's, let's get going.
All right, Jeremy.
Let's see your hand.
Mmm, it's for a be a softball, Jeremy.
Okay.
So regarding the identity on your service that you described
to mitigate the risk of checking what your uptime is.
So there is an alternate way of gaining security with that.
One of my Ricochet contacts does this thing where
they only sign on once every like 24 hours
for like only a couple minutes of the time.
And they figure that if I want to send a message,
I'll just have it cute in Ricochet refresh
and they'll get it when they sign on.
And so I'm curious, does, does the approach you describe
of using a separate identity on your service?
Does that sort of improve or foggingly to what my contact does?
Like if you combine those two with that grant you additional
security and some threat models?
Potentially, I guess, if you don't
rust your contacts, then that sort of extreme approach
could be useful.
So what I would imagine instead of what you're,
so working on a new version, which includes this sort of
visibility controls and visibility features
around your online status in Ricochet refresh
for the run version three now.
What you would probably do is they would add you
and whoever else they want to talk to on Ricochet
and you would initially connect to their identity service.
And once everybody is all friends and everybody else is list,
they can just stop running their identity service.
Right?
And then the only person who would be able to
know their uptime in this case would be you
because you'd be able to connect to their one
on your service endpoint that only you know and they know.
And so at that point, presumably they trust you
not to do all the various things I was talking about,
then they can easily do that on.
Alternatively, if they don't trust you either,
they can also just turn off their endpoints and only
connect to you whenever they come online.
Or do the similar type of thing where
they just like only come on once they see
if they have a huge message for me for example.
Cool.
Is there any chance that Ricochet refresh might add
a GUI option to automate that particular threat model?
Maybe.
At the moment, the current plan is to have a sort of kind of
familiar setting to set your visibility.
So by default, you'll be able to set yourself
and totally online anybody can talk to me
or a hidden mode where only your friends can see you
or a completely sort of invisible mode where
only time you ever connect to a contact is if you explicitly
try to connect to them.
And then of course an offline mode where nothing is
online and you're not connecting anybody.
So kind of.
Okay.
Makes sense, thanks.
Well, wait for my question.
Hello, yeah, I just have a question.
Thanks for the talk.
And for the great work that looks really interesting.
I look forward to try the door interface.
I mean, I can see how you abstracted away all the stuff you did
before we could share.
And you made it like libraries.
But there's just, I think, one thing that is missing
to make it like a really a completely alternative
to like live peer-to-peer.
It's being able to do a DHD, DHT distributed
hash table.
So is it something that you think about adding at some point?
Or do you think it could be useful to have that in
Gosling?
What would you want the store and the distributed hash table?
Well, it could be many things.
I mean, usually when you build this decentralized peer-to-peer system,
right?
At some point, you want DHT, I guess, for a chat communication,
you don't need it because you exchange your contact.
But let's say you want the directory for something.
Can be contact, you can be anything else.
So at the moment, I have thought about this in the context
of the sharing refresh.
Where?
So in the sharing refresh, we kind of have this very hard
somewhat self-imposed constraint thing,
exclusively peer-to-peer and not needing to run
any extra infrastructure apart from the store network.
In the context of a registry refresh,
I have been thinking about, once this version is working,
as a peer-to-peer, how can we add additional useful
and useful functionality?
Like, discord-like servers, for example, or whatever.
I think that those types of things could be built on top,
or adjacent to the peer-to-peer-to-peer part,
but it's not really something I'm thinking about
too actively right now.
Okay, fix it up.
Thank you for the talk.
I guess my question, which may be you clarified,
and I missed, but Gosling, is it based solely on
already, or can I use it with C-tore?
And if I can use it with C-tore,
do you have, like, can I configure Gosling
to use to work with Hoonix, basically,
when the store binaries unlike some other box?
Short answer, yes, longer answer.
So Gosling is built, was originally built to work with C-tore.
There is an experimental feature in the create itself
that allows you to integrate the RD-client create,
so it's completely in-proc.
Outside of that, we recently received a patch
from somebody on the internet to add support
for configuring the C-tore demon using the
standard environment variables that everybody expects
and in terms of, like, the control port password
or control port control file, or whatever, all that kind of stuff.
So, if you go actually now and download
the Riccii refresh alpha, it's an alpha,
because I hold it whole new back ends.
It is using the Tore interface create, which uses C-tore
and it's kind of configuring this way.
So, longer answer is yes.
All right, we have time for one last question for me, move on.
Who wants to hold the spatula?
All right, well in that case, let's give it up one more time
for Morgan, everyone.
Thank you.