Partial UI lock

[macspeaks]

I noticed while creating a task, a privacy option. Even after choosing confidential. The task still appears with other task on the list of created tasks.

Suggestions

My suggestion is to add security option to the confidential and private tasks.
A Password should be required to be able to view those tasks.

[dmfs]

Definitely an interesting idea. I'm just wondering if this makes much sense, considering the primary use cases we're targeting. The privacy options has its origin in the iCalendar spec. A server which follows the iCalendar model usually uses this setting to determine if/how other users on that server can see such a task (or event).
In case of OpenTasks, however, we assume that the task owner is the only person who has access to the device. This assumption may not hold true on shared devices though.
We've been considering encrypting the entire task database, but that creates other issues with synchronization.

[betsythefc]

Encrypting the DB would be a cool idea, but I would like at least a pin/fingerprint option for opening the app. There could be an option in the top right menu to "show private tasks" that requires the user to authenticate with the device, however their device is set, or their own passcode of they don't have one on their device.

andOTP is a 2fa app that has this feature, it just asks the device to authenticate the user.

For encrypting the DB, perhaps a notification comes up asking to unlock the DB for syncing, or it stays unlocked while open as a background task for syncing. I would make both of these optional.

[dmfs]

The main problem with DB encryption is, how to handle sync adapters. If the sync adapter tries to sync before the database has been unlocked it will run into an error.

At present I see two options:

• return an error to the sync adapter, this will most likely cause the sync app to crash.
• make all operations NoOps, i.e. return empty tables and ignore any updates, removals and inserts. This will cause the sync adapter to frequently re-sync the entire collection, causing plenty of traffic and battery consumption or, depending on how it's implemented, sync adapter crashes as well.

We could certainly introduce some sort of "pragma" table which allows a sync adapter to check if the database is locked or open before syncing. All sync apps would have to implement this before we could go live. Also, we'd have to make sure that sync adapters every now and then get a chance to sync. You don't want to enter your password every time an app is trying to sync.

Maybe we could add an option which allows to decrypt the database automatically when a sync app tries to sync. The idea would be to allow a user to enter a password "on behalf" of a sync app. OpenTasks would store that password in the Android keystore binding it to the package name and signing certificate of the sync app.
I've created #790 to track ideas and progress of this.

[dmfs]

I've renamed this issue to something more meaningful. As long as the database is still open this is not a security feature, because any app supporting the OpenTasks Contract and having the required permission can still access all tasks.
However, just like DB encryption we could make this a TaskProvider feature. This is how it could work:

• if a sync adapter accesses the provider it will always see all tasks (of its own account)
• if a non-sync adapter accesses the provider it checks whether private tasks have been unlocked, otherwise it will add a filter to exclude private tasks from all results (which will also mean you won't get any notifications for such a task though).
• to unlock private tasks you'd have to provide the password via a pragma table, this could be done on a per-app basis, so other apps still wouldn't see private tasks, even if OpenTasks itself is unlocked