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
0x9FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
