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

[Greg T. <gd...@le...>]

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.

If you mean an API to briar for another program, makes sense.

> 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.

JS evil in anything secure.  See previous rant.

> I also want cross-platform development.

Beware that "Cross-platform" often means "both platforms", vs "actually
portable".

Besides android and ios, there is "system conforming to POSIX" (which
with a bit of fuzz covers, BSD, Linux, macOS, illumos), and then
windows.

> 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!

Hard to follow what that means; it seems to use the network, but maybe
you mean that locally.  And it seems to run JS, maybe in the browser.
Also it uses mongodb which is no longer open source.

You have to keep in mind what can and can't happen in the background on
mobile OS.  As I understand it, Briar is android only and I see that as
a real problem.

> 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.

It would be good to understand (may require experimenting) what actually
takes power.  Your assumption that it's crypto does not seem right to me.

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

Then you need a plan for how the devices communicate, without the
adversary seeing them, and without the service you don't want to locate
them.

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

Yes.

>> > 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.

So now I do not understand you about this.

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

I would suggest that you attempt to thoroughly understand

  tor
  briar
  diaspora
  ipfs
  DTN literature on routing
  freifunk
  
>> 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.

I didn't mean trusting them with plaintext.  If you want to route to
another user multi-hop, you have to either flood or know how it's going
to go, or end up with low delivery probabilities.  So handing encrypted
messages to others is still trusting they will deliver.  And it exposes
information helpful for traffic analysis.