Privacy beyond data concerns

[violetadev]

Is your feature request related to a problem? Please describe.

It would be nice to have some kind of protection on the app itself.
What do I mean? Anyone can go through your phone and access the app. For example, I'm thinking how customs have the right to go through your phone without a warrant in an airport, or if you are in an abusive relationship they can do the same. Are there any proposals for this?

Describe the solution you'd like

Some ideas that come to mind: pin protected app, easy to access wipe functionality

[novonimo]

@artnerdnet I'm not sure but #21 would talk about these important aspects of security for the data.

[getify]

This kind of protection was the very first thing I built here, it's feature number 1, and it's already solid and tested.

The app requires a passphrase to "login"... and it uses this passphrase to derive (via argon2) a strong hash used as the encryption key, so the data is always encypted "at rest". And alongside the encypted data, only a challenge hash (different from the derived-key hash) of the password is stored on disk to verify each login.

The derived-hash encryption/decryption key is stored in sessionStorage while you are "logged in", for convenience, so that a page nav or refresh doesn't log you out. The health data itself is only unecypted while in the memory/DOM of the running app, never on disk.

Technically, some browsers store sessionStorage itself on disk temporarily (in case of a browser crash so they can offer "restore session?" prompts to the user).

Unfortunately, that means it might be possible if you are currently logged into the app, and haven't closed the app or tab, that the decryption key is in plaintext on the device disk, available to a government/police device scan (though unlikely).

Web apps do not have "secure enclave" access the way some native apps on some OSs do, so there's really nothing we can do about that particular vulnerability (as small as it is). I spent many days intensely researching options. I think what we have is the best/safest we can get in a local-only web app.

But hopefully someone could close/logout before having to hand their phone over, in which case there's near-zero. vulnerability and essentially perfect protection, because the only data on the device is strongly encrypted.

Unless they force you to give the passphrase (or you entered it into your device's autocomplete or password manager), they cannot access your data.

Assuming you have picked a good passphrase (app currently requires at least 12 letters, and will eventually enforce more constraints Iike multiple words, etc), the encryption (256 bit AES-GCM, a universally accepted standard, considered "military strength") is strong enough that your encypted data is safe from brute force cracking, as it's estimated to take months or years of CPU time to do so.

That's the best symmetric encryption we can get in a user device.

[getify]

FWIW, there's a web API we might decide to use: https://developer.mozilla.org/en-US/docs/Web/API/Credential_Management_API

This allows an app to manually put credentials into the browser's credential store. Unfortunately, I think I've heard that some browsers (like Chrome?) keep stored credentials in plain-text on disk. We should do some research to validate if that's true, and under what circumstances. And we should particularly validate if that's true when using this API (which is a shame if so).

But if we validated that the credential storage was indeed secure "at rest" (on disk), this would be an upgrade to the app's current security specifically as it relates to storing the encryption/decryption key in sessionStorage.

[birant]

@getify What do you think of a kill-switch pass phrase that is different than your normal pass phrase? If this kill-switch pass phrase is entered it deletes/corrupts/randomizes/sets a predefined state. I think this might be useful if user is forced to give the password.

[getify]

@birant Sounds like a great feature idea!

[violetadev]

thanks for the explanation @getify
@birant my thoughts exactly!! it would be nice to wipe and access the app to find it empty as nothing was ever logged

[Gynko]

Oh well, this came out today:
https://edition.cnn.com/2022/07/08/tech/period-tracking-apps-data-privacy/index.html

[getify]

Doesn't change any of the need or plan for what we're building. In fact, I've reached out to that reporter to ask them to keep an eye on our project and to, either now or in the future, highlight it as another (and better!) option than commercial/business-driven apps.