Response inline below... On Wed, May 10, 2017, at 02:57 PM, Greg Troxel wrote: > > Michael Rogers <[email protected]> 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 _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
