Clippings are stored on disk in plain text. Please add a checkbox that I don't want persistence

[kkovacs]

First of all, thanks for doing this great software - I've been a satisfied user for many many years!

The reason I've been so satisfied that – unlike every other clipboard software – JumpCut was the only one that did NOT write all the clippings to disk (in plaintext).

This changed 8 days ago in commit 1eb519db095f1934fcba96a0343268aad2f83300, with the big rewrite. Now everything is in ~/Library/Application Support/Jumpcut/JCEngine.save:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>displayNum</key>
        <integer>10</integer>
        <key>jcList</key>
        <array>
                <dict>
                        <key>Contents</key>
                        <string>Second clip, also stored in plaintext</string>
                        <key>Position</key>
                        <integer>0</integer>
                        <key>Type</key>
                        <string>NSStringPboardType</string>
                </dict>
                <dict>
                        <key>Contents</key>
                        <string>First clip</string>
                        <key>Position</key>
                        <integer>1</integer>
                        <key>Type</key>
                        <string>NSStringPboardType</string>
                </dict>
        </array>
        <key>rememberNum</key>
        <integer>10</integer>
        <key>version</key>
        <string>0.80</string>
</dict>

This is kind of a dealbreaker for me (and I guess lots of other people too).

Would it be possible to add a checkbox in the settings to prevent writing a history to disk? That would make JumpCut the one secure clipboard history once again. :)

As a WORKAROUND, for now it's possible to do the following, but it's an ugly hack (and not guaranteed to work if the file will ever be opened for writing in a different way):

cd ~/Library/Application\ Support/Jumpcut; rm JCEngine.save; ln -s /dev/null JCEngine.save

P.s.1: I DO see that there is a comment in the code that in the future this will be in SQLITE, but that will not be a solution, that will still be pretty plaintext.)

P.s.2: I do understand that there is a protection against "sensitive" copies, but not every copy that IS sensitive is marked as such.

Keep up the good work!

[snark]

Another feature that I didn't think anyone used! This probably will require more time to re-implement than is available for the forthcoming bugfix release, but I'll get restoring an option to not save clippings to disk on the roadmap.

[kkovacs]

Thank you, Steve!

Yeah, that's the problem with features – they say that everyone just uses 20% of them, but everyone uses a different 20% :)

[snark]

@kkovacs Quick question - do you not want the clippings to hit the drive ever, or would deleting on quit suffice? (Probably not an issue for now, just wondering--this isn't a feature I've used since the day of slow spinning metal hard drives.)

[kkovacs]

Thanks for asking, Steve! I would prefer if the data would never touch the drive. (Actually, I'd prefer it never to leave the process's memory.)

My worry is malware, many of which has hard-coded paths to files to grab first. I'm not an expert, but if I would be working on something like Pegasus, the files of various clipboard history programs that almost definitely have passwords/tokens in plaintext would certainly among my targets.

Unfortunately, in day-to-day work, we are often forced to copy passwords/tokens/etc from:

• Slack, Teams and other chats,
• web-based password storages,
• even Mantis etc tickets.

In these cases the passwords/tokens are NOT marked "sensitive".

Hope this helps! :)

P.s.: And I want to reiterate: when I evaluated Mac clipboard history apps (last time about 2 years ago), Jumpcut was the ONLY ONE that didn't do the storage-to-disk-in-plaintext. It could be a real distinguishing feature for Jumpcut, worth mentioning among its advantages.

P.s.2: I'm happy with my workaround for now, it keeps ME safe, so no rush, if there are more important features – but it would be nice to keep others safe too. :)

[monkeyhybrid]

Storing to disk is a concern of mine too. Even if it's only temporarily saved to disk before being deleted, sensitive data is still likely to be recoverable, making this a security concern.

[snark]

This is in 0.81, which is now available for download; I'll add documentation for it when the Sparkle update goes up this weekend, but it is not exposed in the preferences window, because I didn't like the flow of turning it off and on. If I can get the warnings about behavior settled in my mind, I'll expose it. As it is, this is an advanced feature that needs to be activated using the defaults command-line tool; from a Terminal (or iTerm, Kitty, etc.) window:

defaults write net.sf.Jumpcut skipSave -bool true

Then restart Jumpcut; your previous clippings will not be loaded, and Jumpcut will not save any new clippings to disk.

To return to saving the clippings to disk:

defaults delete net.sf.Jumpcut skipSave

Then restart Jumpcut.

[snark]

Thanks to the four of you (if I've counted correctly) in this issue, btw; this is a usage consideration I never really thought about [1], and while it's not something I personally find particularly compelling, I really appreciate it being brought up as a distinguishing characteristic.

[1] It was originally motivated by the dog-slow speed of my circa-2005 MacBook's hard drive; there was a noticeable chirp every time it saved.

[snark]

(I'm leaving this ticket open until I've got instructions up on the site.)

[Vadorequest]

My guess is, if storing to disk is a workaround due to old hardware that feels slow, then the best default would be to be secure by default, and only bring up the other option for the few people who feels the slow.

I'd much prefer having it safe by default. Everybody in my association uses Jumpcut, and nobody ever worried how the password are stored in the computer (not even myself). I'm glad to learn it was safe all those years 😂

[snark]

It was the opposite, really. Storing to disk was my preferred result, in that it means the clippings stack persisted between restarts. When I initially wrote Jumpcut back in 2004 or whenever it was, I had a very slow hard drive, so I gave the option to skip saving (or save only when quitting) because there could be a slight but notable lag if you were cutting-and-pasting whole documents.

I'm perfectly happy to accommodate this use case, but I think the happy path is enabling persistence.

(For what it's worth, if your concern is passwords, Jumpcut currently supports ignoring password managers that comply with the NSPasteboard.org standards, including MacPass and 1Password. There is an open issue for optionally ignoring high-entropy strings, e.g. "33;Uz8dbtT$7vv", and I have on my roadmap future features that would enable briefly disable recording and ignoring particular applications.)

[kkovacs]

Thank you Steve - the skipSave setting works perfectly!

[kschmid]

First of all thanks for this great nice tool!
I came here for the same reason, I noticed the change in behavior that all copy paste was still their after repeat and was looking for the option, which I thought I remembered to be there.
As for the others, security is for me an important feature. All passwords I copy out of KeepassXC make it to jumpcut (although "ignore confidential clipping types" is checked) and are then stored in plaintext by jumpcut on disk. Like kkovacs, this bothers me a lot. So, it was great to find here the workaround implemented.
For what it is worth, I would always prefer a simple preference selection for ignoring the store (i.e., keep only in memory) over any magic including or dropping specific strings (like high-entropy).
Actually having the passwords in jumpcut memory is not bad as it helps when juggling with multiple passwords repeatedly, e.g., while debugging various configurations of the system.

[Vadorequest]

Agreed, I want "my" JumpCut to save passwords (I'd be a mess for me if it stopped doing that, I rely on this a lot for newly auto-generated passwords), I just want to avoid them being stored on disk for security reasons.

[snark]

@kschmid The KeePassXC thing should work, depending on your cut-and-paste method: keepassxreboot/keepassxc#6518 -- that's a KeePassXC issue, independent of Jumpcut's behavior. (I just tested it using MacPass, a Mac KeePass client, and the behavior is as expected.)

I'm willing to make this an ordinary configuration method; I just haven't figured out a UX for it that I'm satisfied with.

For what it is worth, I would always prefer a simple preference selection for ignoring the store (i.e., keep only in memory) over any magic including or dropping specific strings (like high-entropy).

The high-entropy string suggestion would be entirely separate from this (e.g. if you're using a site like random.org to generate high-entropy strings). (And my personal password style runs towards diceware/"correct horse battery staple", which would not be affected.)

[snark]

Okay, I think I've worked out in my head how the UI flow should be for exposing this feature. Exposing it isn't a high priority for me, but I'll see what I can do.

[kschmid]

@snark: thanks for pointing this out. I was not aware of this. However, this is actually not the behavior I want: I want jumpcut to sweep up everything and just not store it on disk. So, I turned off now the item in the preferences to ignore confidential snippets and used the default setting method referenced above to ensure that things are never stored to disk.

Not sure, whether I am oversimplifying things, but I do not understand the issue with the UI flow. - I would have assumed to have in the same preferences (ever under general or under clippings a check box whether to write stuff to disk or not)...
which effectively does the same as default setting command.
(I am not experienced with programming Mac UIs)

[snark]

@kschmid Sure, let me try to explain the UI flow issue. If you switch to "skip save" in preferences, how should Jumpcut behave with any existing clippings? They'll scroll off the stack, eventually, only to reappear the next time Jumpcut is launched, unless we delete the file--but deleting the file may not be what the user actually intends! Do we prompt for deleting the file? Do we avoid loading, but return re-load when the skip save preference is disabled? What do we do with the clippings accumulated while skip save preference is disabled?

What I decided is that Jumpcut should just warn the user that enabling/disabling the preference requires a restart, and give them a chance to cancel do anything they need to do with the existing clippings or automatically restart the application (using a helper app). I think that'll be intuitive.

[kschmid]

Dear Steve,
thanks for the explanation and the update!
I see, why it is more complicated than I would have thought. The way you describe it, it is certainly understandable. I would have assumed a (perhaps) easier flow, that does not require a restart:

• if the preference is switched off, the file is deleted, but everything remains in memory.
• if the preference is switched on, the current state is written.
  If a restart happens with things switched off, the next restart leads to an empty in memory list.
  (I would have assumed this is also rather clear and would avoid a restart

[snark]

A checkbox is now available in 0.82, with a "do you really mean it?" warning when disabling save, and the requirement that the clippings stack be empty when switching back and forth. Thanks for using Jumpcut, and thanks for explaining your use cases!

[kkovacs]

Thank you, snark! Will test as soon as the build is available through update.

[kschmid]

Thank you snark! This is really great!

[kkovacs]

The update just came to me and I tested it: works perfectly! A big thank you, @snark! 🎉