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

Michael Rogers michael at briarproject.org
Thu Mar 23 10:00:22 EDT 2017


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.

Another issue to consider is that apps have been removed from the Play
Store for requesting the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
permission, if Google decides that the permission isn't needed for "the
core function of the app" (see
https://commonsware.com/blog/2015/11/11/google-anti-trust-issues.html).
If a client app needs a hidden service and Orbot provides one, which of
them would Google consider to have a legitimate case for requesting the
permission? I have no idea, and frankly it's stupid that we even have to
worry about it, but such is the platform.

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/20170323/08ac1827/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/20170323/08ac1827/attachment.sig>


More information about the guardian-dev mailing list