Cookie-based access to capabilities

[elima]

From the Security document, I understand that since no user accounts exist, the way a legitimate owner of a set of photos obtain access to his/her capabilities is by storing a client-side cookie persistently.

This has some important implications:

• Photos uploaded by one user from one device (one browser in one device, actually) are not accessible to the same user in other devices he/she might regularly use.
• If a browser wipes out its cookies, the resources linked to those cookies are lost forever, and will probably stay orphaned in a server, without ever been possible for anyone to "claim" them.
  • Removing cookies in a browser is not uncommon. Some browsers do that automatically (i.e, on memory restricted devices or under "incognito" mode), and a user could also remove personal data accidentally.
• This scheme will not work at all if cookies are disable in a particular browser, something that is incresingly common after recent scandals. The user mindset right now seems to be that cookies are dangerous.

These issues would be mitigated if the photos are considered partially volatile (and the UI is clear about it), meaning there is no guarantee for permanent storage beyond a browsing session, or after a given period of time. But I suppose Omafano's goal is to be a permanent storage for photos, right?

[wingo]

I feel like we should recast this in terms of use cases. So what I hear you saying is:

1. a user should be able to access photos from multiple devices
2. a user should be able to have some way to recover their capabilities if they lose their browser cache (via device theft, incognito mode, accident, changing browsers, etc)

We solve this with share links. When you have a capability, you can share it with others, and those shares go via links, and you can email the link to yourself, or omafano can send you the link. Optionally we could associate caps with email addresses, and then that would allow omafano to re-send share links in case of loss. It's possible also to see how many times a share link was visited, resulting in caps installation, so it has some degree of tamper-proofness -- you could see if the backup shares you sent yourself were ever used.

Finally you mention that this strategy wouldn't work if a user disables cookies. I'm not sure what the use case is there TBH. But I guess I would frame it as twofold:

1. User with cookies off wants to see public photos
2. User with cookies off wants to see photos that were shared with them (private photos) or manage photos, etc

Case (1) works. Case (2) would cause the share link that installs the cookie to notice that in fact the cookie wasn't set, so thereby should give the user a message to allow cookies for that site. Anyway due to the eurocookie law we'd have to explain in the share link that we're installing a cookie when the user clicks OK, so that's fine. Does that satisfy you?