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