PrivateCommunities.md2.6KB

Private Communities

With the current model, each Share is public and is sharing all of its files
with anyone who might be interested in them. A Share announces itself to one or
more Hubs, but those Hubs are not necessarily the only ones indexing that
particular Share. In fact, it would be relatively trivial for a Hub to fully
clone another Hub: Just grab a list of all Shares from the Hub and index those.
A Share has no way to restrict which Hubs are allowed to index it and/or who
is allowed to download from it.

Reasons for wanting to restrict access to Hubs and Shares could be:

A Share only has limited bandwidth and wants that bandwidth to be used by
people that they know or people who benefit the most from the shared files.

The shared files may contain sensitive information that should not leak
outside of a small community. E.g. security research, whistleblowers.

I consider this out of scope for the early stages of ChiFS, but support for
private communities can be considered if there’s demand for it. Here’s a rough
idea of how this could work.

Architecture

Precondition: Users have a way to register and authenticate to a Hub. Plain old
user/password authentication would suffice for this model, but stronger schemes
could also be supported.

The Hub generates a public/private key pair and makes sure that the public key
is available to all Shares indexed by the Hub. Users that wish to download a
file from a Share first obtain a token signed by the Hub’s private key, which
they can then use to authenticate themselves to a Share. The Share can verify
the validity of the User’s token by checking it against the public key of the
Hub.

A User’s token should be short-lived, anywhere between 5 minutes and 24 hours
should suffice, depending on the Hub’s policies. A short expiration time
ensures that Users will have to regularly re-authenticate themselves to the Hub
and limits the amount of time that a user can access Shares after their
authorization has been revoked. Short-lived tokens also avoid the need to
implement systems like CRL or OCSP.

Tokens could be restricted in various ways:

A general token to allow a user to download anything from any Share. This is
just a verification that the user is registered with the Hub and is
authorized to download things.

A token to only download from a particular Share; This way the Hub can
restrict users to only access particular Shares.

A token to only download a single file. For extra fine-grained access
control.