Reading/Web/Preference Persistence For Anonymous Users/Notes/TDF Feedback/20230517 Notes
Appearance
We need a way to provide anonymous users different configurable experiences such as font size, limited width, dark mode, etc (preferences that change how the page is displayed to the user) without causing a layout shift or flash of unstyled content during page load
Notes
[edit]- SG: need to be aware of fingerprinting; we should look to either reduce what information we request, enforcing a short lifespan of these cookies
- AS: Font-size and dark mode may have different solutions / implementation details may vary
- MS:
- There are a few solutions we know are not quite valid:
- Re: localstorage, we heard this might not be viable due to performance concerns. See https://phabricator.wikimedia.org/T321498#8550182
- We should create something generalized, but let’s focus first on what we want to ship for now. We can see what we need for other use cases further down the line
- Amir: enum or bool is not that important perf-wise, the amount of css we ship is important
- There are a few solutions we know are not quite valid:
- PM: are these preferences site-specific ? Does this mean just wikipedia? What about sister projects? This will change the direction we go in
- NR: there are constraints via the client-side storage requirement. These are specific to the specific domain. Not a requirement for this to also be set on Spanish if we set on English
- JF: We could theoretically use login.wikimedia.org for the siteprefs cookie? But eww.
- MS: If they want global preferences -- they... can... log in....?
- NR: there are constraints via the client-side storage requirement. These are specific to the specific domain. Not a requirement for this to also be set on Spanish if we set on English
- TC: From a user POV - I would be happy to have a mechanism I can use without thinking about it too much. Whether it uses localStorage or cookies, I don’t care. Maybe responsible devs could switch this around? As an extension user I shouldn’t have to care
- What all solutions have in common is that we have a small piece of JS that needs to be executed as early as possible
- We need to heavily limit it. Don’t think too much ahead - just think about these other use cases - its easier to open something up later than to go in the opposite direction
- Ensure: no modules are loaded. Block ResourceLoader, limit the number of bytes, everything that increases the # of bytes flags a CI job - this should be good enough!
- Make sure this is only used for exceptional circumstances. People open the page and get the default font-size – a cookie should not be created with a default value, only when people make an exceptional decision, e.g “I want dark mode”. This also means this only applies to a fraction of users, e.g 5-10% (dark mode maybe more?)
- MS: can we forever tell what the default will be?
- It could be that a given wiki wants to make a different default
- We have something working now for width that is already running.
- Maybe we keep it but add a few things? This will save us some work.
- Maybe we talk about this in the next meeting?
- NR: this is limited to one preference only for now, we’d need to expand it
- MA: there is workarounds for localstorage and cookies to assign to a domain that is not the one opened
- NH: This is partially about the solution itself, but we need a decision record around this as well, to document when and how we would and would not use this.
- MA: we need ideas about the naming convention also - we need to refine this to a starting point
- NR: what I’m hearing is: whether we use localStorage or cookie doesn’t matter as much to people – we did get a perf recommendation to use cookies – but most concerns are around how we implement that solution
- PM: it would matter for SRE probably - as cookie is sent with every request
- NR: there may be two solutions here:
- One for those that don’t require CSS, another which would allow us to conditionally load CSS
- AS: For the second, you ship a different module, or an extra module from the startup module. This adds one more module to be loaded to the queue of modules
- MS: won't that impact caching, Amir?
- AS: Nope, I thought hard about it
- MS: won't that impact caching, Amir?
- NR: for now we’re only considering solutions that have limited CSS Impact.
- NR: TC mentioned we should start simple and small. From this POV, we should consider limited CSS features to begin with. We don’t need the conditional loading strategy?
- TC: Still design the cookie format so it's expandable.
- MS: re: dark mode, I’ve spent 4 months in a rabbit hole around this! Many fixes will not be done in CSS but on wiki.
- Re: checks, we already have CI integration right?
- TC: Let's finally fix https://www.mediawiki.org/wiki/Developers/Maintainers? ;))
- MA: we want to avoid excessive cookie usage, to get to the point that it becomes a security problem? Something in localstorage but that is sent via API parameters, maybe this is an option?
- JF: I’ve numbered all solutions – there are 7 of them. Includes Edge Side Includes (which we will almost assuredly not going to use)
- We should include ESIs, even though they’ve said we can’t use these
- 1. Currently in prod
- 4. Amir’s solution
- 2, 3, 5, 6 - clear we don’t want to do these
- NH: Existing conventions that we can reference?
- https://www.mediawiki.org/wiki/Manual:Coding_conventions
- https://www.mediawiki.org/wiki/Manual:Coding_conventions/JavaScript#Keys
- https://foundation.wikimedia.org/wiki/Policy:Cookie_statement
- In case it's helpful, the security did an inventory/audit of cookies last year, which includes a somewhat list of existing wiki cookies : https://docs.google.com/document/d/1N0WrFB01JzgmjqfaeKig17AMjzShZcJ5-Oo86sNEbPA/edit#heading=h.jwmlwo5k3dt1
- TK: This is just one cookie, right?
- NR: yes this is a single cookie, but it is pipe-delimited
- MA: we should minimize the number of cookies
- TC: we are used to the pipe - it works!
- MA: All caps, or not? Starts with a given prefix?
- TC: Suggestion: Use the abbreviated product names as they are on Phabricator. E.g. VisualEditor is https://phabricator.wikimedia.org/diffusion/EVED/ there.
- PM: once we start using cookies, we should make sure we don’t impact GDPR. These shouldn’t be used for tracking, but people are creative! We need to maybe then potentially consider
- TK: we should not encrypt the cookie