Re: [briar-devel] How does Briar know where to send a message to reach a given user?

[James M. <ja...@jm...>]

Thanks Greg, this is very helpful!

Correction-- when I said "onion server", I meant a hidden service.

Responses inline:

[Sent from my phone.]

On Mon, Jul 22, 2019, 4:02 AM Greg Troxel <gd...@le...> wrote:

> James Marshall <ja...@jm...> writes:
>
>
> Two thought from that:
>
>   Briar is essentially what you want, perhaps missing some features.
>   Consider extending Briar instead.
>

I've thought about that, and still may.  Another possibility is to use
Briar's transport to send data as messages, which my tool could then format
as needed, e.g. as JSON.

I think there are features I want that may not fit in the full Briar model,
though.  I want to use HTML templates with CSS and potentially JS, so that
any UX designer who knows HTML can create their own UI for the tool; these
could be shareable.  This would a) allow clean separation of design from
code, b) leverage creativity of the user community, and c) let users choose
the UI they prefer.

I and others know HTML/CSS/JS already, which is a benefit.  I've never
written a mobile app and I don't know how complicated the layout mechanism
is... maybe it's easy!  But most people already know HTML etc.

I also want cross-platform development.

For both of these reasons, I'm looking at using Meteor to develop this, as
it seems to have all I need and its users seem happy with it.  I've never
used it, so all thoughts and concerns are welcome!


>   Briar is heading in the direction of federated personal servers (but
>   with the big point of a server for each person), so that they can be
>   always reachable.  Understand Briar's issues with power usage, then
>   design, and then post it for review.
>

I'm considering that too, a personal server acting as a message relay, but
for saving power when encrypting e.g. media files for your 500 friends.
This server would need to see the message in order to encrypt it for
everyone, so it would need to be secured and trusted.

The other, main kind of server for this tool would *not* see message
content; it would only pass encrypted messages among other servers and
users, queueing as needed.  The user wouldn't need to trust this kind of
server, and each server could be used by many users.  (It *could* learn
things like "this user knows someone on that server.")

But maybe I can just run a hidden service on each device, thus requiring
tor (I was thinking of making tor usage optional).



> > As I understand it, a Briar user's identity is basically just their
> public
> > key (?).  If each user isn't associated with a server, like the
> > use...@se... that some federated tools use, then how does user A
> > know where to send a message to get to user B?
>
> There's identity, and there's address.  Briar shares a tor hidden
> service address with peers and one communication method is to contact
> the other briar node over tor.  The others are local only, so tor is the
> only method for people not near you, more or less.
>

Interesting, so each Briar installation includes its own hidden service.
And then presumably re-registers with the tor network whenever its IP
address changes.



> > Unless I'm missing something, I don't see how to do that without a
> > centralized lookup server, which I thought Briar is trying to avoid.
> > Maybe server info is stored with each contact?
>
> Yes, the hidden service.  But you don't need a centralised server, you
> need a worldwide service which can be distributed.  tor HS are such a
> distributed service.
>

Right, that's what I meant, a service.



> > I would love for my tool not to require a server name in user IDs; it
> would
> > be easier to use onion servers, for example, and easier to transparently
> > migrate to a different server.
>
> I don't follow your concern.  Briar keeps the HS name in the db and
> doesn't show it to the user, so it isn't hard.  If you mean "just type
> in the name", then you need centralized registration, or to bootstrap on
> centralized registration like DNS.
>

My concern may be unfounded-- I'm new to hidden services and need to
consider how this tool should best use them.



> > Thanks a lot!  Links to docs, discussions, or relevant source code are
> most
> > welcome.
>
> A huge issue in Briar was and still is power usage.  For reasons that
> aren't fundamental, tor uses huge amounts of power when offering a
> hidden service (on a phone; regular computers call this same usage very
> little power!).  So enabling the HS on your phone -- which is necessary
> to receive messages from people who aren't on the same wifi or in BT
> range -- runs the battery down, unacceptably for most.  Surely
> acceptable to some if their actual threat model is as bad as Briar's.
>

Interesting, thanks for the info that hidden services on mobile drain
power.  I was mostly concerned about all the end-to-end encryption draining
power, so this is good to know too.



> There are two paths forward, and as I understand it both are happening:
>
>   fix tor to not need a wake lock for a HS.  then it will just be sort
>   of heavy usage, but probably good enough
>
>   allow personal relay boxes that speak the protocol, but can't decrypt,
>   that are someplace with power, with a different HS, that the user
>   polls when they want to get mail (or when they are plugged in, etc.)
>
>
> Also, see the literature on Disruption Tolerant Networking, which for a
> time in the 2000s was very successful at extracting funding from
> research sponsors :-)   But seriously, there is the notion of
> transferring messages over a network with occasional connectivity and
> node movement.   The problems are:
>
>   figuring out routing is very hard,  You can't flood, because that
>   doesn't scale.  You don't know who is going where.
>
>   if you want to trust no one, do you trust strangers?
>

My goal is to not trust strangers with anything but encrypted data.
Specifically, users should not have to trust any servers.  Right now, the
federated tools I know of require each user to trust not only their server,
but the servers of all their friends too.


> briar avoids this by not doing routing, just direct delivery, via wifi,
> bt, or tor HS.  It is headed to 1-hop routing, where the intermediate is
> specified by the peer, avoiding both of the above issues.
>


Thanks so much for all the great info!  And for your interest.  This helps
me a lot.

Best,
James