Remote alternative to local storage for low security user data?

Question

Suppose you are developing an independent small subpage for a large and well-visited web portal.

The subpage displays entries from the publicly available event calendar and allows users to highlight those that are of particular interest to them. Highlighted events should be highlighted (and possibly shown in a separate list) for each subsequent visit to this user.

However, creating a classic user registration system or any other way of storing user-selected events on the server is not an option: the submodule should be as autonomous and need as little maintenance as possible. This is one of the conditions of the project.

The only way to do this without creating any kind of login system (as far as I can see) is to use cookies or other local storage (Flash / HTML 5 ....), which has an obvious and big drawback that it is tied to a computer and not to the user.

Is there a way to store several kilobytes of data for each person, but without the need to use the login or openID that I skip? Perhaps a reliable web service?

A "key / value" storage service, to which I transmit a unique key (the one specified by the user) and receive the stored value in response, will be sufficient. There is no need for real security - the data is not confidential.

OpenID is not an option: it is not well known among the audience of the site.

Facebook would be an option, but I don't think they provide storage options like this.

As a workaround, I am considering offering the user their choice of events in the form of a download of a text file, which can also be downloaded and converted into cookies on another computer. But it is quite difficult for the user and, therefore, not perfect.

Answer 1

We have a similar system on our website where users can add bookmarks to the scheduler / wish list function. Saved items are sent through the web service and stored on our server, and there is a corresponding get.service web service.

We have a lazy register system. The first time a user saves an item, they are offered their email (but not a password, since nothing is confidential). This is hashed and stored locally using a cookie, and then used to set / retrieve stored items. When a user uses another computer, they are again offered an email address.

The key is that the register and login are the same operation, so there is no need for password reminders or any reset functions.

Answer 2

The Google Docs API provides programmatic access to Google Docs , where you can create and store documents and spreadsheets. Your application may have its own Google login, which it uses to create one or more documents for each user. These documents can be used to store user preferences.

If you can get a unique identifier from each user (for example, an email address or something more secure), this should be pretty simple. You can even organize files into folders - one for each user.

Alternatively, you can combine Google Docs with the Google Spreadsheets API , where I just noticed this pretty handy feature:

Tables and Records
Interaction with spreadsheets as if they were a database using tables and records.