keybase / client

Keybase Go Library, Client, Service, OS X, iOS, Android, Electron
BSD 3-Clause "New" or "Revised" License
8.83k stars 1.22k forks source link

Suggestion for change to KBFS #10527

Open VictorKroese opened 6 years ago

VictorKroese commented 6 years ago

Hi, I would like to suggest a change that may be a bit deeper in the KBFS. I am in a group where we deal with files that can contain sensitive information (especially video's) that we would like to protect from distributing freely. We can set a person to be a reader and they will have access only to read the files, that is great. However they are also able to copy the file to other locations, also outside of the file system. We would like to see an option where we can prevent files from leaving the folder to other destinations other then a sandbox where they can temporary be stored for viewing (not relocated). It would be sufficient if this can be set alone for readers for a whole folder or even if that would make it easier for readers for a whole team. With sub-teams that could be organized for the the kind of information that we are dealing with. For others it might even better if the owner of file (for writers) or admin could copy the file but not other writers. I guess also in here on folder level would be sufficient.

strib commented 6 years ago

Hi @VictorKroese, that's a good idea in theory, but in practice it is impossible for us to distinguish the reading of a file from the copying of a file. I believe that would have to be done in the operating system itself; Keybase wouldn't have access to enforce those kinds of constraints.

If you (or anyone else) knows of operating system hooks that would allow for this, please let me know!

VictorKroese commented 6 years ago

Thanks @strib. So it is not the Keybase Filesystem that would be handling that. That also means that this hook you are talking about would need to be available for every OS (Windows, MacOS, Linux) that the KBFS integrates with. I will see if I can get more information, great if anyone that is knowledgeable in these areas could add suggestions.

strib commented 6 years ago

Correct. I think it's unlikely we'll find hooks like that for all platforms, but you never know.

zanderz commented 6 years ago

Unfortunately, there is always the analog hole

eli-schwartz commented 6 years ago

Any security model that relies on preventing users from using their own operating system however they wish, would by definition require you to act as the administrator of the system in question (and deny that right to the user, who may disagree with what you're doing to hardware that they own).

But that still wouldn't help as the user could simply login to KBFS from another device, and read the files. Or use the cat command to "read" the file, and totally coincidentally write a totally unrelated file containing the same content... If keybase was designed to only offer access to devices that somehow prove the administrator account and OS security policies are locked down by the owner of the file, I guess you could stop every method... except of course for the aforementioned analog hole, which will never be defeated.

It is impossible and an oxymoron to both give someone a file and the ability to use it, and use technological restrictions to prevent them from using it the way they want to. The whole Digital Rights Management ~farce~ industry has repeatedly proven this for starters (and somehow I doubt the Keybase people want to be known as a DRM provider).

If you do not trust people to refrain from redistributing said content, you should maybe reconsider trusting them at all. :stuck_out_tongue: Either way, maybe try reinventing the entire computing industry before expecting the Keybase software itself to do something like this.

VictorKroese commented 6 years ago

Thank you @eli-schwartz for your view. A lot of people fortunately can be trusted, reality has unfortunately proven this is not the case for everyone. It has happened that people have stolen video files and tried to sell them on to others. If 0.1% cannot be trusted it is not a reason to distrust the 99.9% as well. You do not know in advance in which group someone belongs though. So it is not about what device they access it from. They can look at it from any device as much as they want, as long as they are in the team. There are other ways probably that we can look into like branding the video's. If people would be buying those at least they would know they buy stolen material. I guess the branding would also help for the analog hole 😄 My thought was that a program would be requesting a file from the KBFS and that based on the program or type of program the KBFS would be able to grand access or not. It looks like that was a misconception on my part.