search

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

kbfs: support unlisted public folders #2419

Open rajeevn1 opened 8 years ago

rajeevn1 commented 8 years ago

similar to unix directories with execution bit unset.

cjb commented 8 years ago

Do you mean unlisted on keybase.pub?

That won't be very secure, because the list of Keybase users is discoverable and someone could spider them to see if a user has anything on KBFS -- that's kind of what keybase.pub does

But if you just want keybase.pub to avoid indexing your site, seems like we could consider supporting some hidden file that does that.

I don't see how this is much like having the executable bit unset, since in that case you can't enter the directory.

taruti commented 8 years ago

@rajeevn1: Are you asking for directories where readdir would return no files (or only the files the user has explicitely requested)?

I.e. lacking r instead of lacking x?

rajeevn1 commented 8 years ago

I am looking for 'public' but 'unlisted/ undiscoverable' directories so I can share links with people in email, or a group and only the people who have the link can view the public folder. This means such public folders won't be indexed/ searchable either.

cjb commented 8 years ago

@rajeevn1 Are you talking about keybase.pub, or /keybase on the command line, or both?

@strib How do you feel about touch /keybase/public/foo/bar/.undiscoverable etc?

rajeevn1 commented 8 years ago

I prefer the command line, but the person receiving the link in an email should be able to just click it.

strib commented 8 years ago

@rajeevn1 @cjb: It would be possible for KBFS to allow paths via some pseudo-subdirectory like .kbfs_undiscoverable/ anywhere within a given folder, and not show that through regular command line operations like ls -l. However, note that a determined adversary could still discover these paths, either with a modified KBFS client, or by requesting the public change records of the folder (used to invalidate kernel caches, etc). For those reasons I'm not sure it would be very useful, but if those drawbacks don't bother you we can open an internal ticket (though I can't promise we'd get to it in the near future).

cjb commented 8 years ago

Cool. CC'ing @malgorithms to consider this too.

Thanks for the suggestion, @rajeevn1!

edgimar commented 5 years ago

This issue is a bit old, but I still think it could be a worthwhile feature, in particular for sharing to specific individuals via a 'public' link that isn't published on keybase.pub. It would be convenient to be able to simply touch myfolder/.hidden in order to hide myfolder and its contents from being seen via the keybase.pub interface.

@strib So there is no way to prevent such a hidden folder from being discovered? How would one go about requesting public change records in such a way that the folder could be seen? And is it not possible or advisable to hide such folders from the public change records?

oscarfroberg commented 5 years ago

This would be cool for example for prototyping web apps, which wouldn't necessarily contain sensitive information, but would make very little sense to have them browsable through keybase.pub.

sugoidesune commented 4 years ago

I was also looking for this feature. Having files accessible without the need for authentication, while not making them publicly browsable. Also just for the ease of use it would be great to have this in also available in the app interface. Maybe a fourth folder, private, public, team, unlisted.

RogueScholar commented 4 years ago

Sorry to clutter the thread just to essentially say "+1" but the impression I get from following this repo is that it hews much more closely to the issue tracker model than the traditional developer mailing list one. That being the case (and please correct me if I'm in error about that) it seemed more productive to comment within it rather than simply add a reaction to the original post.

Specifically responding to @cjb's comments, having folders in my personal public tree that are unlisted on keybase.pub but still accessible over HTTP/S and KBFS with the correct URI is exactly what I'd love to see. Your suggestion of using an .undiscoverable file (I might lean towards .unseen for brevity's sake) as the trigger is exactly what I had in mind, even. @strib mentioned some realistic limitations but I don't find them to be impediments to my use case.

You're probably sick of hearing it, but you guys still amaze me with the constant innovations and community focus for this endeavour even after almost 5 years since I registered. You make open source really fun, and that's not an easy task. Thanks for all of it, I mean that.