Write-only permission

[raucao]

I'm hitting more and more use cases, where it would be beneficial to have an additional write-only permission for directories. My main use case for this is server-side agents automatically syncing/writing things from other places to my storage.

This would already be useful when running your own server to enhance security, but especially if you want to give out a token to someone else writing to your storage, and you don't want them to be able to read the contents.

The background is that I'm thinking about creating a kind of data liberation service, where people can just OAuth-connect centralized silos and have the agent write structured data to their RS account for them. For example, you star something on GitHub and it would automatically create a bookmark for you in RS. In that case you'd want to give out a write-only token for the bookmarks category and nothing else.

WDYT?

[silverbucket]

I am probably missing something, but as I understand it - you want to give server-processes (that act on your behalf) write-only access to your RS? If I understand it correctly, I actually had this idea for Sockethub many years ago, where you would have a butler service subscribe to your various feeds and post that data to your RS for you, but didn't think about permissions. Essentially you're thinking of specialized bots that grab data from your various social media APIs and store it?

So the danger is that someone could compromise the server process and get a token to your RS?

[raucao]

The danger is not just someone compromising the server, but that if the account holder is not the server operator, right now they would be required to give the server operator read access to their data. So it's both about security and privacy.

[galfert]

I think that makes sense.

But the write-only token would only allow to create new files, not update or overwrite existing ones, correct?

[raucao]

But the write-only token would only allow to create new files, not update or overwrite existing ones, correct?

That's an excellent question! I haven't really thought about it, but I think I'd prefer a dropbox approach over being able to update/overwrite. There's no perfect privacy, of course, because you'd be able to know which documents already exist, but it would at least be much better than any random bot on the Web having unfettered read access to someone's files.

[raucao]

I just stumbled upon another use case:

In order to make bookmarking in Webmarks even quicker and more streamlined, I'd like to have the bookmarklet contain the code not to redirect to the app, but to write directly to one's storage and then show a notification overlay (similar to e.g. Instapaper). This would have to include the token, of course, but I wouldn't want full-access tokens being accessible in a browser bookmark object. Write-only tokens on the other hand would be fine imo.

[raucao]

And another one: considering an app like https://doodle.com, with this permission we could enable some social apps like this, where people can for example upload their vote in a poll, but not manipulate other people's entries (by way of only being able to create, not overwrite).

[michielbdejong]

only being able to create, not overwrite

then I would call it 'append' or 'create' permissions, and the term 'write' would still mean everything that :rw has but :r doesn't, i.e. create+update+delete.

A limitation is that we probably don't want to remember which app created which document, so if you get create permissions, you cannot update or delete the files you created. so it's only useful for processes that accumulate, or one-off imports. what if someone wants to edit their doodle vote before the deadline, or if I re-import my Facebook photo albums? Maybe it would make more sense to give such processes read-write access to a subfolder?

[raucao]

Excellent points. Hadn't thought about appending much, because I thought overwriting was OK at first (and still think it is in most cases).

Maybe it would make more sense to give such processes read-write access to a subfolder?

Good idea. Would you tend to allow arbitrary folder depths for the scope in this case?

[michielbdejong]

Would you tend to allow arbitrary folder depths for the scope in this case?

Hm, we restricted it to zero or one levels in https://tools.ietf.org/html/draft-dejong-remotestorage-12#section-9 so then you would have to do a twitter-import module and an smtp-import module, etc.
For doodles you would need one "module" per doodle, e.g. giving an app read-write access to the hackerbeach-2020-doodle module. There, it would maybe be nicer to be able to call it doodle/hackerbeach/2020, so that you can give different levels of access to different apps and processes. But we would need to justify if that niceness is worth the spec change.

[raucao]

Revisiting this, I think the social use case should probably be handled via other, existing communication channels, while having a simple create/append token for a whole category is much simpler and less prone to unexpected behavior. It also fits squarely within the personal storage use case, as opposed to collaborative storage.