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

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

Thanks again.  Responses inline:


On Mon, Jul 22, 2019, 2:07 PM 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.
>
> If you mean an API to briar for another program, makes sense.
>

Yes, that or something similar.



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

Indeed.  Web-based JS is more secure than it used to be, with things like
Content Security Policy, but CSP is still a moving target last I checked.

If we support any JS in the HTML templates (and I think we will), it will
be very restricted, on a whitelist-only basis.



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

Thanks for your experience here, as I have none.

I'm planning to start with the mobile apps only, since that's what most
people use.  If/when that gets done, we can write apps for the various
desktop OSes.  I'm not as worried about those, since most scripting
languages these days are pretty cross-platform (and I have experience
writing cross-platform server applications).



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

Meteor has some features I don't intend to use.  My app will only access
the DB locally, not over a network.  I may not use the reactive features
either.  Mostly, I like its use of templates, its apparently satisfied user
base, and its good community support that's not corporate-based.

As I understand the MongoDB open source issue, it's just to prevent
commercial use without a license, which is OK with me.  I don't think it
would interfere with using it in an open source app that uses it, would
it?  As I recall, they mostly just care about SaaS situations.

I don't know exactly which license I want to use for my tool, but it will
be free and 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.
>

OK.  Yeah, worth experimenting.

The trusted personal server would also save a lot of mobile bandwidth.


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

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

Sorry, didn't mean to confuse it.  The answer to my original question is
"yes, a lookup service is needed, and Briar uses Tor's existing lookup
service for HS."



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

Excellent, thanks for the leads!  Some I know, some I don't.  I'll check
them all out.

Freifunk is interesting, reminiscent of the Neighborhood Area Networks
(NAN) we used to hope for.  I guess mesh networking has come a long way
since I last knew about it.



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

Ah, right.  Trusting a server to deliver is an important kind of trust.
Yes about traffic analysis too.


Cheers,
James