Re: isolating history with buffer-local variables

[Nick Helm]

> On 16/05/2015, at 11:32 am, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> I think there are other use-cases though. For instance, I use Emacs to
>> edit confidential files that I don't want leaking into incremental
>> backups or off-site syncing of ~/.emacs.d/ (all the usual financial,
>> medical, legal stuff).
> 
> Could you give details of those use-cases, to see how much of it is very
> specific to your particular setup, and how much of it could apply to
> a wider audience?
> 
> I'm specifically wondering why copying "foo" to "foo~" or to "#foo#"
> would be a problem (assuming "foo" itself is modified) w.r.t
> incremental backups or off-site syncing.  Or are your worries more
> specifically about leaking data from those files via history variables
> saved in ~/.emacs.d ?
> [ Another way to attack this problem is to try and avoid
>  syncing/backing-up the saved-history data in ~/.emacs.d.
>  Maybe this history data should never be saved to ~/.emacs.d but to
>  another place instead?  ]

My primary concern is losing control of copies or fragments of confidential 
files. 

If I edit a confidential file foo.txt, which is stored in plain text on my 
file-server, Emacs potentially creates at least three additional copies or 
fragments of foo.txt created on the local machine - foo.txt~x~, #foo.txt# and 
.emacs-history. 

My file-server does encrypted backups to keep the originals secure, but I also 
I do hourly incremental rsync backups of $HOME on each client machine, so 
another three copies and fragments of foo.txt find their way to that machine as 
well. These backups are rotated off-site.

I also sync ~/.emacs.d to Dropbox for continuity and so I can access my Emacs 
setup, backups, auto-saves and histories from any machine, but that means 
another three copies and fragments of foo.txt now exist up on Dropbox.

So, all up, for a single edit, I could end up with nine or more uncontrolled 
copies or fragments of foo.txt floating around. For normal files, this is a 
good thing, but not for private data (to my mind at least). Where the edit 
takes place on a shared machine or a portable device, there is also an 
additional risk of theft.

Similarly, if I use Tramp to remote into a client's machine and edit foo.conf 
for admin purposes, Emacs creates foo.conf~x~ #foo.conf# and saves file 
fragments in .emacs-history on the local machine. The remote sysadmin can add 
file variables:

;; backup-inhibited: t
;; eval: (auto-save-mode 0)

to foo.conf to prevent the copies being created, but has no simple control over 
saved rings and histories.

Out of interest, I ran a series of little tests to see what Emacs saves in 
different situations. This table shows the data that was committed to the local 
disk when editing plain text and encrypted files (via EPA) in different 
locations. 

                    +-------------------------------+
                    |File content                   |
                    +---------------+---------------+
                    |plain-text     |encrypted      |
+---------+---------+---------------+---------------+
|File     |Local FS |Fp Ap Bp Hp Rp |Fe -  Be Hp Rp |
|loc      +---------+---------------+---------------+
|         |LAN      |Fp Ap Bp Hp Rp |Fe -  Be Hp Rp |
|         +---------+---------------+---------------+
|         |Remote   |Fp Ap Bp Hp Rp |Fe Ap Be Hp Rp |
+---------+---------+---------------+---------------+

Where:
F = visited file (on user save)
A = auto-saves (to ~/.emacs.d/auto-saves)
B = backups (to ~/.emacs.d/backups)
H = minibuffer history (et al) (to ~/.emacs.d/.emacs_history via savehist)
R = kill-ring (et al) (also to ~/.emacs.d/.emacs_history via savehist)

And:
p = data was saved to disk in plain text
e = data was saved to disk encrypted

The results are largely as expected, with the exception of the handling of 
auto-saves on remote machines (the remote encrypted gpg was saved in plain text 
on the local machine). Perhaps this is a bug.

That issue aside, I hope private-mode will enable something like the following. 
That is, make it easier to control what private data is committed to disk 
without an explicit user save.

               +---------------------------------------------------------------+
               |File content                                                   |
               
+---------------+-------------------------------+---------------+ 
                               |            PRIVATE            |       
               +---------------+---------------+---------------+---------------+
               |plain-text     |plain-text     |encrypted      |encrypted      |
+----+---------+---------------+---------------+---------------+---------------+
|File|Local FS |Fp Ap Bp Hp Rp |Fp -  -  -  -  |Fe -  -  -  -  |Fe -  Be Hp Rp |
|loc +---------+---------------+---------------+---------------+---------------+
|    |LAN      |Fp Ap Bp Hp Rp |Fp -  -  -  -  |Fe -  -  -  -  |Fe -  Be Hp Rp |
|    +---------+---------------+---------------+---------------+---------------+
|    |Remote   |Fp Ap Bp Hp Rp |Fp -  -  -  -  |Fe -  -  -  -  |Fe -  Be Hp Rp |
+----+---------+---------------+---------------+---------------+---------------+


Nick