This is a terrible use case for cookies. Any browser reset or change, new computer, your phone, etc, and you need to redo the whole experience every time. I'd rather login and customize once.
Cookies get sent with most requests as headers so you're unnecessarily bogging down requests with data unrelated to the session.
It can be worked around. For example, you can use those cookies just to initialize the client web browser. Once it's done, the data can be cached inside the localStorage, and the cookie itself can be deleted (Or changed to a marker that tells the server that the client has been customized).
Of course this may require some heavy changes on the client-side code, as the client now must have the ability to apply user's customization locally, but there are benefit: After you done that, then you don't have to read user's customization data from any of your infrastructure every time user reloads your page.
I don't think a gzipped header with some hundreds of bytes of JSON (or BSON) for preferences is that much bigger than one with a session id string in a cookie.
100% exactly. Cookies are device and moment specific. Whereas a user account can easily save and transport the saved experience/setting anywhere the user wants to access them.
Thanks for the suggestion. That wiki page brought me to https://mozilla-services.readthedocs.io/en/latest/howtos/run... which I intend to try out. I want to migrate my a Firefox profile from Windows to Linux and synching seems to be the easiest way to transfer bookmarks and saved passwords.
Cookies get sent with most requests as headers so you're unnecessarily bogging down requests with data unrelated to the session.