how to hide who created the document

[Seung Chan Lim]

So I wanted to do the following

1. have users create documents

2. only allow the user that created the document to edit the document (i.e. in the sync function check the "owner" attribute to be the same as the authenticated user)

3. allow everyone see the document (i.e. put it in a "public" channel)

4. hide who created the document from people other than the creator

I don't know how to do #4

What would be a sync-gateway approach to doing that?

In its simplest form, I thought if I could just hide the "owner" attribute, that'd be the end of it...

slim

[Jens Alfke]

On Oct 16, 2015, at 7:14 AM, Seung Chan Lim <djs...@gmail.com> wrote:

1. have users create documents

2. only allow the user that created the document to edit the document (i.e. in the sync function check the "owner" attribute to be the same as the authenticated user)

3. allow everyone see the document (i.e. put it in a "public" channel)

4. hide who created the document from people other than the creator

This is tricky. By design, there isn’t any hidden information in documents. That’s because we support multi-master replication where docs might pass through multiple servers/peers, so there isn’t just one source of ‘truth’. I think the best you can do is to obscure the creator, so that it’s possible to tell that two revisions were written by the same creator without revealing who that creator is.

I came up with a clever solution that relies on encrypting the username. Unfortunately it would require the sync function to decrypt it, but it isn’t practical to do that because there are no encryption APIs available, and implementing them in JS in the sync fn would be too slow. :(

Then JChris came up with an even more clever solution, and I simplified it a little bit:

• For every user, pick a secret string as their ‘codename’. It needs to be unique, and it needs to be impossible to derive the username from the codename.
• Create a role named "codename-“+codename, and grant only that user that role.
• The client needs to know the user's codename somehow.
• When a client creates a new document, it adds a property “codename” whose value is the user’s codename.
• The sync function then calls requireRole("codename-"+doc.codename)

—Jens

[J. Chris Anderson]

You can also give the user multiple codenames. I'm not exactly sure how many it would take before it's too many. Probably thousands of roles per user would be ok but it'd be worth testing if you think you will have a ton of "codenames" per user. 

The hard limit is a few MB of role names but going there could slow down other document operations for that user, as the list of roles will be loaded and parsed as part of their database interactions.

Chris

 

[Seung Chan Lim]

Ah... roles... Yes, indeed.

It occurs to me that "codename-" prefix is unnecessary.

Am I right?

slim

[J. Chris Anderson]

I like to use a prefix so that if it have roles I'm using for this aliasing feature, they don't get mixed up with roles I'm using for something else. The prefix should be unique in your app, but maybe pick something shorter than "codename".

Chris

[Seung Chan Lim]

So the only reason you have the prefix is because you have a list of roles to manage for your app, and you want to visibly discern which of them belong to this "feature" and which don't?

[Jens Alfke]

On Oct 16, 2015, at 8:10 PM, Seung Chan Lim <djs...@gmail.com> wrote:

So the only reason you have the prefix is because you have a list of roles to manage for your app, and you want to visibly discern which of them belong to this "feature" and which don't?

It helps ensure uniqueness too, so that this feature only gets used with roles that were created as codenames. For example, if you have an unrelated role “novice” that lots of people belong to, then all of them could post docs under the codename “novice”. Probably not a security hole, but not what you intended either; and in stuff related to security you don’t want to allow that kind of wiggle room or it’s likely that someday somebody will figure out a way to use it in a way that breaks security.

—Jens