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.