❌ Software Removal | Keka #2126
Labels
No Label
🔍🤖 Search Engines
approved
dependencies
duplicate
feedback wanted
high priority
I2P
iOS
low priority
OS
Self-contained networks
Social media
stale
streaming
todo
Tor
WIP
wontfix
XMPP
[m]
₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
💻 hardware
🌐 hosting
🏠 housekeeping
🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
🌐 website issue
🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
🗨️ instant messaging (im)
🇦🇶 translations
No Milestone
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: privacyguides/privacytools.io#2126
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
I suggest removing Keka.
Why I am making the suggestion
Keka was once open source.
But now it's closed source.
Transparency and mass surveillance are important for cryptographic software.
I suggest removal.
My connection with the software
I have nothing to do with the Keka developers.
I agree that it makes sense to remove Keka if you want to clean up the Worth Mentioning section as mentioned here. However, I'm biased since my application is on this page.
I was already looking into removing Keka. On the research of the program's history, and trying to come up with a decent conclusion whether or not the pogram should be trusted;
I determined that the author of the pogram closed it because somebody else had taken his code and submitted to the AppStore for the MacOS (if I recall correctly, it's been a few months and I didn't keep notes).
Which isn't really a good reason for close-sourcing your program, I believe. And I don't think an archiving tool with "meh" encryption built-in really fits as a cryptographic tool with security in mind.
For Keka having encryption support seems to be more about having it as an additional feature, rather than incorporating security as a process.
I can do additional research, but Keka should probably be removed on the basis of not fitting into this section, and being closed source (and for silly reasons).
Even if it is a "good" program, it needs moved to a different section.
7Zip also does not belong in this section, so I will probably get both of these removed.
And it isn't really a privacy tool. Just a simple archiving tool.
7-Zip does make it easy to password protect a ZIP, but I agree that perhaps it doesn't belong in this section or maybe it should be moved to Worth Mentioning. @lynn-stephenson Where would you move it to?
I think I'd replace 7-Zip's spot with Cryptomator for the file encryption recommendation. Is LUKS only in Worth Mentioning because of how difficult it is to use the tool compared to VeraCrypt? LUKS should be recommended for disk encryption on Linux really since it's built into loads of distros and VeraCrypt doesn't support system drive encryption on Linux.