Client: Abuse vector: My chat and KBFS can be initiated by any user

Created on 29 Mar 2018  Â·  9Comments  Â·  Source: keybase/client

I searched Keybase.io for a contact page, and then I raised this topic to @malgorithms who suggested I take my questions to GitHub, so I'm starting this thread.

I'm concerned about the open nature (and no option to close) access to both my chat and KBFS. There is no request and approve/deny flow.

Problem

Right now any Keybase user can create a shared folder with me, without asking first. This will send me a notification, and if I navigate to that folder on my machine, the files will automatically download.

(Update: As noted in a comment below simply lsing the directory won't download all the files in the folder. It would require an actual _read_ of the file to do so.)

According to the documentation:

“Filesystem” means that there is no sync model -- files stream in and out on demand.

This is probably a fine process for people I know and trust. But the way Keybase is currently designed, any user can initiate this. This is a problem if a user wants to be malicious. What happens if a user wishes to fill a folder with malicious or abusive or illegal files?

Best case scenario: I resist the temptation to navigate to that directory on my machine. But there's now a folder with both my username and my access rights full of these hypothetical malicious or abusive or illegal files. I can use the UI to ignore the folder only as a reactionary action. I'm not convinced that's an adequate solution under a potential abusive situation, especially if there are multiple abusers (this is a problem Twitter has spent years trying to address, and is still working on).

Worst case scenario: I navigate to the folder and now these hypothetical malicious or abusive or illegal files are downloaded to my machine. I can then use the UI to ignore the folder, but as mentioned above, this solution seems problematic.

A similar issue arrises with chat: Anyone can initiate a chat with me. They can be abusive, spammy, or even send me illegal/offensive content. My only option is to ignore the user after the fact.

Furthermore, I'm concerned about Keybase's ability to help in an abusive situation. Since everything is encrypted end-to-end, how would Keybase step in?

Solution?

This is likely not a trivial solution to implement technically, but I think it's worth considering a "Friend" model. Keybase already has the concept of "following." As a user, I would like to be able to have a request and allow/deny flow when someone wishes to "follow" me. Or, perhaps a situation where we must be mutual followers in order to do certain types of communication.

Something like that would create an explicit _social network of trust_. Eg: "Since we both follow each other, it's reasonable to say we agree to receive files or message from each another."

Since my Keybase profile is public, (unlike email or other social networks) and since end-to-end encryption would prevent Keybase from implementing content filters for spam or abuse (again, unlike email or other social networks) it seems like giving users at least the option to gate access to their chats and files would be positive if not necessary.

Most helpful comment

Where should Keybase intervene, without completely destroying the usefulness of keybase as a whole?

Someone could email you illegal files encrypted with your pgp public key, and your mail client would download the encrypted file, so you are in more trouble than with Keybase

As mentioned in my original comment, I think Keybase should implement controls on the receiving-user's side to create a layer of approval.

You're right that anyone _can_ email you anything, and you can't stop it. The difference here is that Gmail doesn't have a searchable directory of everyone's email address that is also tied to their Twitter/HN/Reddit/Whatever identifications. I think people would be irate if Google did that, but that's exactly what Keybase is.

I agree, for Keybase to remain useful, public proofs of identity are important. But defaulting all forms of communication to "accept" seems problematic when coupled with that public directory.

Keybase is already doing this at the team level:

If you know of a team, you can ask for access. Actually, I just made a team called keybasefriends so if you want to talk to other testers, ask for access:

 keybase team request-access keybasefriends

As an outsider, you can't tell who's on a team, so Keybase will ping the admins for you. They can then add you or ignore the request.

That ability to ignore a request seems like it'd be valuable at the individual level.

All 9 comments

if I navigate to that folder on my machine, the files will automatically download

This isn't true. As you quoted above, files stream in and out _on demand_ -- navigating to the folder isn't enough to download all the files in the folder. For the most part, you actually have to actually instruct your machine to start reading the files to fully download them. Before you do that, you'll get a popup describing who the user is, and you can choose to proceed from there if you want.

(There is some limited "pre-fetching" done of a folder that you ls, but it only reads at most one block of data from each entry in that directory, so it won't recurse into subdirs or download big files. And even if so, the downloaded data will remain _encrypted_ on the disk.)

I'm not dismissing your concerns, just clarifying a technical point.

@strib Thanks for that important clarification. I had assumed lsing would pull down the files. I've updated my initial comment.

KBFS issue: When it boils down to it, when mra creates a private folder with mrb without mrb's permission, this is what happens:

  1. mra generates a key for the encryption of the folder contents.
  2. mra encrypts the key using mrb's public key
  3. mra uploads the key encrypted with mrb's public key
  4. If mrb tries to look at the folder, he decrypts the key and downloads the folder directory list (and apparently one block of each file just to make sure it's not a folder etc.)
  5. If mrb tries to read a file, it will be downloaded to disk as an encrypted file.

Where should Keybase intervene, without completely destroying the usefulness of keybase as a whole?

Someone could email you illegal files encrypted with your pgp public key, and your mail client would download the encrypted file, so you are in more trouble than with Keybase.

Summary: KBFS issue is a non-issue in my opinion.

Chat issue: Similarly to email, anyone can send you email... the way email has compromised with it is they have "spam filters" that try to guess whether mail is spam or not... This wouldn't work on keybase.

However, there is a problem with my analogies.

The only difference in the KBFS / Chat to email comparison, is that Email (SMTP) is an open protocol, so many people over the years have developed tools that stand between your inbox client and your mailserver that try to filter spam / delete attachments / restrict incoming mail to specific domains, etc.

Keybase, however, is still very new, and all the hosting is done by Keybase, so the only way to implement a "roll-your-own" solution would be if Keybase allowed self-hosting... which they don't... and they probably won't implement filters and things like that when their entire chat feature could change completely tomorrow (still very beta) requiring a full rewrite of the filter logic as well.

I'd say this is a wishlist feature, but not a necessity.

No one will arrest you because some bad guy sent a million emails with illegal files on it to your public email address.

They will arrest you if you keep them.

Where should Keybase intervene, without completely destroying the usefulness of keybase as a whole?

Someone could email you illegal files encrypted with your pgp public key, and your mail client would download the encrypted file, so you are in more trouble than with Keybase

As mentioned in my original comment, I think Keybase should implement controls on the receiving-user's side to create a layer of approval.

You're right that anyone _can_ email you anything, and you can't stop it. The difference here is that Gmail doesn't have a searchable directory of everyone's email address that is also tied to their Twitter/HN/Reddit/Whatever identifications. I think people would be irate if Google did that, but that's exactly what Keybase is.

I agree, for Keybase to remain useful, public proofs of identity are important. But defaulting all forms of communication to "accept" seems problematic when coupled with that public directory.

Keybase is already doing this at the team level:

If you know of a team, you can ask for access. Actually, I just made a team called keybasefriends so if you want to talk to other testers, ask for access:

 keybase team request-access keybasefriends

As an outsider, you can't tell who's on a team, so Keybase will ping the admins for you. They can then add you or ignore the request.

That ability to ignore a request seems like it'd be valuable at the individual level.

please do this before the platform becomes entirely unusable.

I have recently started getting keybase chat spam, 3 spam messages in the last few days, from accounts flyinger, kareengreen and maizeplomino. One thing I noticed is that these 3 accounts only have associated stellar / BTC accounts, nothing else linked.

This tweet and its replies illustrate that the lack of controls is a big problem for many women users. https://twitter.com/aredridel/status/1201338814859501569?s=21. Speaking as an employer, I can’t expose women employees to this kind of harassment.

Another spam message from another account. I've disabled notifications and emails for chat, which is a shame because I do use it with a couple people.

Perhaps the motive is to create fake accounts to receive the airdrop, and have activity that makes them harder to distinguish from real people?

It looks like there are new privacy controls available in the client:

Screen Shot 2020-04-18 at 9 36 59 AM

Was this page helpful?
0 / 5 - 0 ratings

Related issues

heartwithyou picture heartwithyou  Â·  3Comments

pipermerriam picture pipermerriam  Â·  4Comments

daothanhphap picture daothanhphap  Â·  3Comments

hkjels picture hkjels  Â·  4Comments

martindevans picture martindevans  Â·  4Comments