MediaWiki

Reading/Web/Preference Persistence For Anonymous Users/Notes/TDF Feedback/20230517 Notes

< Reading | Web | Preference Persistence For Anonymous Users

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:
    • 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
  • 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....?
  • 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
      • 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?
  • 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
Retrieved from "https://www.mediawiki.org/w/index.php?title=Reading/Web/Preference_Persistence_For_Anonymous_Users/Notes/TDF_Feedback/20230517_Notes&oldid=6065113"