jumpcut: Clippings are stored on disk in plain text. Please add a checkbox that I don't want persistence
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!
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 5
- Comments: 22 (10 by maintainers)
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.
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
defaultscommand-line tool; from a Terminal (or iTerm, Kitty, etc.) window: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:
Then restart Jumpcut.
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:
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. 😃
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!
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 😂
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.
@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)
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.
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:
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.
Thank you Steve - the
skipSavesetting works perfectly!