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

[Greg Troxel]

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.


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.

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.

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20170510/0cded6e7/attachment.sig>