MVP: Cookie policy

One thing to decide on the MVP is a cookie policy.

My suggestion would be:

  • Generally, set as few cookies as possible. In particular, when only browsing, no cookies should be set at all. Obviously some things, like logins, will require cookies.

  • In any case, the site should be usable as far as possible even with cookies disabled (note that while the first bullet point implies this one, they are not equivalent; if e.g. a decision is made to use session cookies even for non-logged-in users, users with disabled cookies should neither end up in an endless reload loop, nor be redirected onto a “please enable cookies” page; both are site misfeatures that normally make me turn away from a site on first sight, and never come back).

  • Where cookies are used, session cookies should be preferred to permanent cookies where possible.

  • The cookie policy should be documented (this may even be a legal requirement for the site). Since the cookie policy is completely determined by the software, I think it makes sense that also the policy documentation is part of the software (so anyone installing it gets it automatically); of course it should be overridable e.g. for localization, or to adapt to changing legal requirements. Maybe have an admin-editable document with default content.

  • And of course we should have no tracking cookies (but then, I guess that one is uncontroversial),


As a counterpoint: we might have features available to non-logged-in users that may be nice to persist across sessions; for example, that let them set certain viewing preferences.

I agree that the site should be functionally browsable without cookies, however.

We need to properly investigate that. Every site seems to have a cookie policy/banner these days, but I’ve heard contradictory things on whether they are needed for purely functional cookies.

Do you have a good definition of a ‘tracking cookie’ ? In my head they apply to large sites (like FB, Amazon, ad networks) that want to uniquely identify users on third-party sites; this doesn’t seem applicable to us. I may have misunderstood your intent though :slight_smile:


That would already go beyond only browsing. Those cookies would be set when the user selects that feature, for example, explicitly sets viewing preferences. Ideally the site interface would then make it clear that it requires a (non-identifying) cookie.

For example, I don’t want us to do the same as the infamous Google preferences cookie, which formally was only to save your search preferences, but actually contained an unique ID that was not necessary for the supposed functionality. That was never sent to anywhere but Google, and only when using Google, but it was still a tracking cookie, as it allowed Google to identify when the same person came back for another search.

And of course, our site could in principle cause tracking cookies from third parties being set, e.g. by using Google Analytics. I hope we won’t do that one either. Note that also certain forms of social media integration may cause third-party tracking cookies to be set.


Thanks for clarifying! To me, browsing is equivalent to non-logged in read-only access, which might still include features like filters, thresholds, appearance and the like. In any case, it sounds like we’re pretty much in agreement even if we call it different things? :slight_smile:

Thank you for the example, I wasn’t aware of that one. I agree that it seems unnecessary for us.

Sounds like a good thing to avoid if we can. I’m not sure if it has implications for OAuth; I’m equivocal on the use of Google Analytics, if we can do reasonably-featured analytics ourselves (definitely not MVP!) we shouldn’t need to involve Google.

I think the cookie rules I have in mind could be summarized as follows:

  • If cookies are not needed to provide a certain functionality (and think hard about alternatives!), don’t use them.

  • If a feature does need cookies, then think about if it really serves the users of the site (note that moderators are users, too). If not, think again if it is really needed.

  • If cookies are needed, use session cookies, unless the functionality demands a permanent cookie.

  • Cookies should never contain any personal IDs other than the session ID of the login cookie.

Do we need analytics at all? What would that give us that the server log plus the history data we collect anyway through the site’s normal operation wouldn’t? That’s a honest question; I have no experience of analytics other than blocking it.

1 Like

What alternatives do you have in mind, specifically?

Do you have a particular set of circumstances in mind that would have a feature implemented that doesn’t serve the users of the site? If you remove cookies from that statement, would it change much? Perhaps I’ve missed the point of what you’re getting it.

My own inclination would be a general statement along the lines of: "be conservative and mindful of cookies and other data which could be repurposed to track users without their consent"

By analytics, I am referring to human-interpretable information on how people use the site/network. It’s a broad definition as that would cover everything from a simple count of page loads to a heat map of mouse movements on a page. I don’t propose either extreme end of the spectrum!

There are benefits to analytics. They could give us aggregate and quantitative insights; as opposed to individual and qualitative insights from users saying what they do and how they use the site. Both are potentially helpful.

That being said, analytics i) wouldn’t be MVP in my view ii) merit their own discussion.

1 Like

Cookies can be a wonderful thing, especially chocolate chip :cookie:

But seriously, a site should generally be able to run very well in read-only mode (not logged in) without cookies. If logged in then generally you end up with some sort of cookie to help keep you logged in (I get confused about all the details and end up looking it up every time I work on a new site) and the rest of the details get stored server-side (e.g., this user likes dark theme and newest answer first, etc.).

Third-party/tracking/etc. cookies are definitely out. Plenty of systems block them, plenty of software (e.g., MBAM) removes them. They do no good for the end-user.

Some what related: 3rd-party Javscript on every page - e.g., Google Analytics, various social media buttons/widgets/etc.:

  • Analytics - may be worth it, maybe not, see Discussion: Analytics for a full discussion
  • Social media buttons/widgets and other “more than just a simple link” to elsewhere. We are in, IMHO, the very good situation of not really caring what other people think. Is it nice if someone posts a link to Codidact on Facebook? Sure, it can help get us some traffic. But do we really care? Not in the typical sense of “more traffic will generate more $”, which is the rationale I hear from commercial web sites. We should only include Javascript that notifies another site of any user action (including page load) if there is an actual documented and agreed-upon useful-to-our-own-system reason to do so. And at the moment, I can’t think of any such reason. Links to the outside world are fine. Loading JS or other content from other servers (e.g., CDN for JS libraries, image servers, etc.) is fine. But not anything in the “track/notify” genre.

That obviously depends on the feature in question. Since we’ve not yet decided on the concrete implementation of any feature, I cannot say anything concrete here.

I’m talking about general guidelines to follow here, not about specific cases. In every specific case the application of the guidelines should be obvious.

Basically, I’d like to have a culture where everyone who introduces a new cookie should be required to justify it, as opposed to a climate where introduction of new cookies is taken lightly.

I want to be conservative and mindful of any cookies, including those that most likely cannot be used for tracking. Of course, those which could be repurposed that way require extra care.

1 Like

I think we have consensus, that we’ll be restrictive with cookies and that we won’t use them to do nasty things.

Any objections? Otherwise this topic will close in 24h.


This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.