[guardian-dev] Orbot 15.4.0-beta-1 (ARM ONLY)

[Nathan of Guardian]

Response inline below...

On Wed, May 10, 2017, at 02:57 PM, Greg Troxel wrote:
> 
> Michael Rogers <michael at briarproject.org> writes:
> 
> > On 06/03/17 14:34, Nathan of Guardian wrote:
> >> For now, Orbot does prompt you to disable the battery optimization
> >> features for Orbot when you enable a hidden service. Otherwise, I think
> >> it is up to the app server/process itself to handle their own wake lock
> >> needs, depending on what kind of availability they are expected to have.
> >> 
> >> ChatSecure/Zom already does quite a bit of wakelock management for
> >> instance, and so if we added a Ricochet, Briar or other protocol support
> >> into that stack, I wouldn't expect Orbot to directly handle it.
> >> 
> >> Does that make sense?
> >
> > The situation with doze mode and app standby is far from clear to me,
> > even after a lot of digging, but it seems to me that whichever app holds
> > the wake lock also needs to request whitelisting, otherwise the wake
> > lock won't be honoured in doze mode.
> >
> > So if you think the wake lock should be held by the client app rather
> > than by Orbot (which I would agree with, because it puts the battery
> > blame on the client), then the client app should also request
> > whitelisting. I don't understand the benefit of Orbot requesting
> > whitelisting without also holding a wake lock.
> 
> [long delayed response -- too many non-cypherpunk thinks to do :-(]
> 
> (I've said some of this on the briar list.)
> 
> I agree that doze is pesky, but I don't think we're really going to have
> a great outcome with wakelocks for more than very brief intervals.
> Sure, if someone wants to run a server on a device that happens to be
> Android, with power, that's one thing.  But for a device being carried
> on battery, having a general wake lock more or less all the time feels
> like it just don't work.  Certainly I gave up on code that wanted to do
> that.
> 
> So long term, I think we need to think about two things:
> 
>   Does a HS really require a wakelock?  Can we back off on the rapid
>   timer notion?  Can it work eventually, if the client is persistent?
>   Can we cope with the notion that the HS goes away in doze?  Is that
>   scary in terms of locating it?
> 
>   How do we build protocols that have the properties we want, without
>   having to have a persistent HS on the device itself.

I agree here strongly. We need to move HS way from being a socket,
real-time oriented interaction, to an async one. This is work that might
be done in Tor itself, or it could be a set of best practices that by
default expects a HS to be asleep, and supports some kind of pinging
back, wake notification between trusted HS nodes.

> For the second point, I wonder about having a device with power which is
> trusted to be an intermediary, not to read the data, but to see the
> routing data.  I could see running a machine someplace with a HS that
> would get my briar messages, perhaps pointed to by a pseudo-MX record
> which is a statement signed by by briar pubkey.  This box would be mine
> or a trusted friend's.  Once a peer has this mapping, it can continue to
> use it.  My client would then connect to this HS and be sent the
> messages, more or less like SMTP ETRN.

There is also something interesting with using Onion Balance / HS load
balancing as Facebook has done. Multiple nodes can share the same
private key, and if one is offline, another node will be available. You
could have a Rpi at home with the same private key that is on your
device. Between your personal devices, you could setup a sync method of
some sort, but to the public, it would essentially look like one device.

> I think this is a pretty obvious idea, just combining MX records and HS
> hosts.  It's not really that different from running SUBMISSION/IMAP over
> tor from your client to an IMAP/SMTP server on a HS, to get mail from
> other such people, except that it blends in with the local exchange and
> blog notion of briar.
> 
> This would let me get offline messages with low battery use (at the
> expense of latency, but that's ok I think) without exposing user traffic
> patterns and reliability to any kind of central infrastrutcure.

Agreed, this is an excellent goal and outcome.

> 
> To implement, we'd need to write code to generate, manage, distribute
> and use these HS-MX records.  And to have the proxy node (which could be
> a regular node itself) have some sort of notion to do queuing and
> deliver to some lower HS-MX server.  That doesn't seem that hard.
> 
> And perhaps blog/ec. sharing would be done to HS-MX destinations of
> peers we'd share to.

+n