ability to turn remote history off and on

[chaserene]

(posting this here, as the functionality first needs to exist on the server-side before clients can make use of it.)

current behavior

Remote History is a Extended feature that creates periodic backups of each note on the server after a note is edited. these revisions go back to the time the account gained Extended status (the home page says it's up to 100 years, but that's probably a figurative expression). the maximum resolution in my experience is about 30 minutes. revisions are accessible to whoever has access to the given note.

the feature is built into the app (it's not a separate extension) and automatically turned on for Extended users. it can't be paused or disabled in any manner.

all revisions are stored on the server and stay accessible until the parent note is moved to the Trash and then deleted from the Trash as well. currently this is the only way revisions can be deleted. (it's possible that revisions are removed from an account once it loses its Extended status, but I don't know for how long that data is actually retained after the loss of status.)

proposal

I suggest letting the user turn Remote History off and on both on a per-note basis and globally (for all notes).

when turning off, remote revisions of the affected notes would be permanently removed from the server, and no further revisions would be created until Remote History is turned on again. turning it back on would start revision capturing for the affected notes.

both the per-note and the global switch could reside in the History -> Remote -> Options menu, and would necessarily come with a warning modal that details the implications of each change. when turning off, the warning would describe that the current version of the note remains untouched, but any past versions will be lost and only the Session History (local history) remains for undoing changes. when turning it on, the warning would describe that this will start storing past versions of the affected notes on the server and so deleted data will still be present on the server indefinitely, which is worse for privacy.

rationale

Remote History is a huge UX improvement because it makes it nearly impossible to lose data by accidentally deleting text in a note. however, there's a big downside: data is retained even when the user doesn't want it or when they don't know about it. this is a problem due to two things:

1. contents of the note may be sensitive. since Standard Notes is an encrypted note-taking app, this is quite probable.
2. most users probably think that when they delete text from the note, it's gone forever. most users are not technical and probably don't use note history. they won't be completely conscious of the fact that the deleted data is still there and accessible, only through a different menu. (this expectation is reinforced by the fact that the app focuses on security, so even Remote History users will unconsciously expect that they are kept safe in all situations -- even when that goes against other goals of the app, like data persistence.)

this means sensitive data that the user thinks is long gone can be available to attackers. that can happen in many ways. an attacker can access the user's device while the app is unlocked. they can compromise the passcode. or, more dangerous, if the user's account password becomes compromised at any time in the future, those with the password -- sync server owners, authorities, hackers, etc. -- can access not only the current notes of the user, but also everything the user ever typed into Standard Notes. another scenario is if the cryptography used by Standard Notes becomes breakable by an attacker, either due to vulnerabilities in the primitives, in their implementation, and/or because technological advances create access to sufficient computational power to do that.

as an app that champions security and control over your own data, Standard Notes should offer a practical way to mitigate this attack vector. the only currently available way (described previously in "current behavior") is insufficient because it is:

1. unintuitive (people won't figure it out until they find the Github issue I linked),
2. way too complicated (you need copy the current contents into a new note, delete the old note, then delete it again from Trash), and
3. doesn't offer a way to do it for all notes at once.

what makes this attack vector more severe is that it's very hard to educate yourself about Remote History. apart from the bullet point on the home page and the short section on the Extended features page, there is nearly no information about it. there is no Knowledge Base article. the documentation mentions it shortly but it seems incorrect because it conflates the built-in Remote History with the CloudLink extension. understanding is made more difficult by the fact that there are two other modules in the application that are similar in function (Session History and the CloudLink extension). this proposal is potentially the most detailed write-up about it. (I couldn't check the blog because it's currently unreachable on both the .org and .com domains.)

this proposal is just the requisite minimum to mitigate this attack vector. it doesn't deal with the problems that Remote History is turned on by default for all Extended users and that this isn't accompanied by an explanation about its potential dangers. whether it should be on or off by default and the ways the app should educate users won't be tackled here but deserve their own separate discussions. due to this, I argue the turn off/on function is sorely needed so at least those who do understand this attack vector can make a decision.

Remote History is a very sharp double-edged sword. this proposal is not yet a scabbard, but first let's put a cross-guard on so at least swordsmen won't cut themselves.

[JaspalSuri]

Hi @chaserene, I've noted your suggestion from when you first suggested it, but have expanded it (in our internal report) to include session history as well as there are users who want to use the app without an account.

[chaserene]

thank you @JaspalSuri! I agree with the inclusion, I didn't realize that as far as this issue relates to end-point security, Session History introduces similar risks. although I did notice that Session History is more limited in how far it goes back. what are the parameters it operates by (time resolution, maximum revision count, maximum time span covered by revisions, etc.)?

[JaspalSuri]

Currently it saves minor changes quite frequently, compared to the remote version history option that saves different versions of a note made at least 5 minutes apart. The session history is cleared when a user signs out or if they click on either history clearing option provided under History > Session > Options (in the menu that appears above the note's editor).