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

Michael Rogers michael at briarproject.org
Fri May 26 07:30:14 EDT 2017


On 10/05/17 19:57, Greg Troxel wrote:
> 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?

As far as I can see, there are three directions we could take here:

1) Wake the device once per minute to keep the Tor circuits alive. I've
exhausted most of the possibilities for doing this in doze mode - the
only one I haven't tried yet is setAlarmClock(), which may be able to
get around the alarm restrictions in doze mode. However, this call is
meant for user-visible alarms, not background processing, so it's really
an abuse of the API, and the loophole (if it exists) could be closed at
any time. We also don't know whether letting the Tor process sleep most
of the time would harm anonymity, for example by making circuits
linkable to each other through their bursts of activity. In short, this
approach is a hack.

2) Work with the Tor developers to make the protocol more
mobile-friendly. One possibility would be to allow a client to put its
bridge or guard connection into some kind of "sleep mode" for 15 minutes
at a time without tearing down its circuits. The open questions here
include whether extra resources would be needed on the guard (do cells
need to be buffered, or could they just be dropped?), and whether there
would be an impact on anonymity due to correlated bursts of activity.
Tor seems to have some funding for mobile support at the moment, so this
approach might be feasible if the changes required aren't too large.

3) Shut down the hidden service during long periods of sleep and rely on
push notifications to wake the device. Push notifications obviously leak
metadata, but we can take some steps to limit the leakage. First,
encrypt the notification in a format designed to reveal minimal
information about the sender's identity, the app being used, and the
content of the notification. Second, send the notification to the push
server via Tor, so the server sees the identity of the recipient but not
the sender. Third, replace GCM/Firebase with a federated notification
service, so not all metadata is exposed to a single server, and
recipients can choose servers they trust.

If I understand right, Signal now allows a direct (websocket?)
connection to the Signal server to be used instead of GCM/Firebase for
receiving push notifications, which suggests a federated notification
service is technically possible. This would be a big project in its own
right, but I can imagine funders supporting it if enough apps would benefit.

I did a quick thought experiment to see how much metadata would be
leaked to a notification server (or an adversary watching it) in two use
cases: an IM conversation and a message to a publish-subscribe group.

The leakage for the IM conversation isn't too bad. If both parties are
awake at the start of the conversation, the initiator connects to the
responder's hidden service, the whole conversation happens over Tor and
the server sees nothing. If the responder is asleep, the server sees an
anonymous notification addressed to the responder, so the server knows
(1) the responder was asleep, and therefore didn't send any recent
notifications, and (2) the anonymous initiator was awake, and therefore
didn't receive any recent notifications.

In the publish-subscribe scenario the leakage is much worse. Each device
in the pub-sub group sends the message to its peers, so for each device,
the server sees a set of anonymous notifications addressed to whichever
of the device's peers are asleep. The sets of notifications ripple out
from the originator of the message until all devices in the group are
awake. This gives the server a partial view of the membership and
structure of the group, excluding the originator and any other devices
that were already awake. The partial views can be combined over time
using graph matching techniques to deanonymise the members who were
excluded from each view. As with the IM scenario, there's also leakage
across groups: the server knows that any device that receives a
notification was asleep, and therefore wasn't one of the anonymous
devices excluded from any recent partial views.

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

I've been thinking along similar lines. There are two ways we could do this:

1) To send a message, the sender connects to the recipient's inbox
server's hidden service. To collect messages, the recipient connects to
her own inbox server's hidden service. When the recipient is asleep or
offline, she doesn't collect any messages (and therefore doesn't forward
any messages in pub-sub groups). This is essentially Pond.

2) To send a message, the sender connects to the recipient's inbox
server's hidden service. The recipient connects to her own inbox server
via some non-anonymous, sleep-friendly protocol. When the recipient's
asleep, the server wakes her for incoming messages. When the recipient's
offline, the server stores incoming messages. This is essentially
Loopix, or the Loopix-like system the PANORAMIX project is working on.

In both cases, the recipient can optionally run her own hidden service
when she's awake, bypassing her inbox. The privacy properties of the
second approach are similar to those of the federated push notification
service. The first approach has better privacy properties but doesn't
wake the device for incoming messages, which is a non-starter for a
messaging app these days.

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 4660 bytes
Desc: not available
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20170526/91545ee4/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20170526/91545ee4/attachment.sig>


More information about the guardian-dev mailing list