this post was submitted on 18 Oct 2023
134 points (96.5% liked)
Open Source
31190 readers
274 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
- !libre_culture@lemmy.ml
- !libre_software@lemmy.ml
- !libre_hardware@lemmy.ml
- !linux@lemmy.ml
- !technology@lemmy.ml
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
One red flag from that podcast:
When asked how they might deal with abuse of the service to distribute illegal files, he suggested that you could compare uploaded files to hashes of known files. This doesn't make sense in a system where the server has no knowledge of the unencrypted file, since the same file encrypted with two different passwords will result in two different hashes.
Can’t you hash it before uploading and upload just the hash? Or download the banned hash list locally.
Sure, but then you're trusting the client. I can always encrypt
x
and send along the hash fory
.In the end you can always just encrypt the illegal stuff externally before giving it to them...
The only way I could see them flagging potentially illegal files on the server-side if they don't have access to the cleartext file would be through the filesize, and that would lead to too many false-positives. On the client-side it could be done through a local checksum against a denylist (compared locally for privacy reason) before uploading, but that could be easily defeated.