Time Intent: Data Disclaimer

Disclaimer: It's your data, your responsibility

In Time Intent the bulk of user data is stored in the user's web browser (IndexedDB).

Users of Time Intent are responsible for their data.

Your data is stored on the device. This practically means the following.

• If your device crashes, blows up, gets lost in the depths of the ocean, etc. Your data is gone.
  • Unless synced with another client peer to peer.
• Your device proves its id with a private key in its database. This is why no password is needed.
• Sharing your physical device with, trusted, authorized or unauthorized actors potentially puts this data in their hands.
  • Including its ability to assert its identity.
• Data shared to Deabute's cloud service is encrypted on the client with pre-shared keys between your peer connected clients.
  • Deabute can not recover those packets of data for users or know what data to give users back.
  • The above is only authorized to be done by a client with premium service credentials with information that only that client knows or shares with the other client it intends to share with.

Recovering paid access after a complete loss on all clients.

• We are not sure how this works yet, but it will probably involve the following.
  • An empty/touch transaction with the original payment method.
  • One-time key user keeps offline or in their password manager.

Whether "hidden" or "deleted" data might exist on a storage device

Something more folks should generally understand about computer systems is that the erasure of data is expensive. Could be for many reasons, processing efficiency, data integrity (a part of one thing depends on what's up for erasure), energy efficiency, and typically storage longevity. Most systems elect to simply remove the reference address to the data instead of clearing the data from the storage device. Ultimately waiting for something else to come and write over it. It's like kicking down the mailbox and scraping away the street number instead of going through the work of demoing a house. Might be good enough depending on what is expected. Client-side data in Time Intent will likely only be dereferenced from its local database when that data is elderly or unnecessary.

For instance, keep these things in mind when using the delete or hide features

• deleting a task is an expected behavior up until timestamps have nothing reference to know what they were for.
• In syncing removals, it is hard to tell another client something was deleted without at least revealing the id of the deleted item.

Deletion is included and worded that way to be an expected convenience as commonly understood but it likely doesn't do as expected in the background. Don't be surprised to see it in IndexedDb still if you're inclined to inspect into the browser more carefully.

Data is stored in plain text on rest. If there is enough request for it we would consider opt-in at rest encryption for those that don't mind using a password.

How data is stored at rest is an important issue for those worried about

• Shared OS login
• remote access actors
• Potential cross-origin browser vulnerability sharing access to IndexedDB

Drawbacks of providing encryption at rest (on the client)

• If a malicious remote actor is there's the user is hosed anyhow.
• What stops them from planting a key logger and getting the user's key?
• Longer page loads
• Passwords