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


 * MS: Goal of this meeting - We are collecting concerns:
 * Talking about problems and how we will reach a resolution, not technical solutions.
 * What concerns do we need to incorporate
 * When we think about long-term, we need to know who will be in the room
 * We will stay away from actual implementations
 * Goal is to determine: what around this question should we be aware of?


 * Miro Board
 * Requirements:
 * Needs to prevent Flash Of Unstyled Content (FOUC) as well as content shifts
 * If we were to apply a class on page load after the page had painted, it would introduce a massive layout shift to make the content expand
 * Other features we may use this for:
 * Dark mode - this would have a FOUC
 * Font-size - would have a layout shift if we did not render block
 * Concerns:
 * If we open this up, and in a year’s time, because of volunteers and extensions, we’ve got 10,000 features that use this, is this ok?
 * AS: there are many ways to poison the cache
 * If you mess with stored HTML you will poison the cache
 * For now, Which class on the body will change :
 * AS - Suggestion: Startup module - tell it to load another set of modules if the cookie is set there
 * You have different solutions here - the constraint is very very important - you may end up with different solutions that aren’t the way that have been envisioned
 * “Bloat” of size and features are concerns
 * Concern: Sending large amounts of CSS to everyone
 * Question: What is bloat, what is acceptable?
 * MS: Ownership: who owns this, who says what should and shouldn’t come in? We shouldn’t find ourselves in 2 years’ time with 10k of these
 * MS: Just booleans?
 * Need to consider what kind of data can / should be stored
 * Font-size will not be a boolean
 * >2 but not a lot of values?
 * A requirement could be: no arbitrary/string value. Only bool or set of options
 * JF: Are there existing settings we might want to migrate?
 * JF: Thumbnail size - currently hard-coded, only available to logged-in users, splits parser cache
 * JF: Will e.g. thumbnail size be migrated to client side preference?
 * https://phabricator.wikimedia.org/T66214
 * JF: A way to balance performance cost and performance benefit
 * RK: this would also require changing how the preference is handled for logged in users!
 * JF: and providing an API for thumb sizes, which has been open for 10 years now
 * AS: If you change the image size, it will be part of HTML, unless you load a large size and make it smaller. It gets nasty, and quickly
 * MS: Logged in vs. not-logged-in users, what are the implications here?
 * Cookies have expirations. Will we ever consider, especially if we’re moving between non- and logged-in users,
 * IP Masking - non-logged in users are kind of logged in!
 * NR: The way we currently handle limited width, we use an inline script that handles cookies for anonymous users; logged in users don’t get this script at all
 * This was probably a mistake. After speaking with the team
 * Ideally everything that works for anons also works for logged in
 * This is a device preference, it doesn't matter if you’re logged in or anonymous
 * We always want this for our features: Limited width, font-size, dark mode
 * VG: treating anons and logged in users the same will be beneficial
 * This could trigger inconsistencies, may not look good
 * VG: also worried about a per-device setting - this could enable tracking of devices
 * MS: Per-Device?
 * esp. Re: a11y, I’m not sure all settings make sense to be per-device - font-size would be expected to persist across devices
 * Would logged-in users want their font-size (or other accessibility features) to stick regardless of the device they are on
 * If this is true, then this is a concern you will need to look into
 * Do we just move it to preferences, in this case?
 * AS: when you log in, many cookies are flashed. Not necessarily all?
 * Users have a different UX than non-logged out: gadgets, different views, etc.
 * MS: If I am logged in and set my preference to be bigger, I would not expect them to persist when anonymous.
 * But if I set this device, I would expect it to remain
 * Up to you all to define this - we should see how users will react
 * It’s complicated, but is it worth solving?
 * Anything that would be bad to store client side?:
 * AS: Anything that needs to persist for legal reasons
 * RK: things with many values, many arbitrary values, large impacts on the page
 * One thing you could do is have a separate UX and hide it behind a CSS class - 5KB of HTML and have “display: none” set . As an intuition, everything we’ve talked about so far has been style changes - changing the appearance of things that don’t exist. Show/hide smaller things, but not showing/hiding entire UX - things that take a lot of space to store
 * JF: skin preference; desktop vs. mobile; which languages to display - 500 versions of the doc in DOM; anything with a large ratio  of performance impact!
 * This is hard to enforce technically, better to enforce socially!
 * Historically, we haven’t been successful at enforcing things socially - “let’s make an exception in this case”
 * MS: How can we be defensive? what is created here is an enablement of something - a cookie that you can add features into. There is no good way to create a pipeline for it. It’s easy to keep track of how many things add cookies. Could a gadget do this, because it’s a FE cookie? We need a way to shine a light on what is impacting the cookie. Otherwise we can lose control over this. How can we be defensive?
 * JF: "I'll just re-implement MonoBook as a Gadget".
 * NR: this is definitely a concern I have as well. Maybe an allow-list, either in the inline script, or, in the script, we don’t allow it to add what is in the cookie
 * Current implementation is here: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/883243/18/includes/ResourceLoader/ClientHtml.php . Looks at the cookie, and for each value, replaces this feature - disabled or enabled, on the HTML element. It will only change the behavior if that class is already on the HTML element. This way you limit how many of these are added
 * Some sort of allow list could be helpful
 * MS: We could also trim what is in the cookie
 * NR: performance will always trump other preferences - perf is always first
 * MS: if we limit it to 5, should we create a pipeline?
 * AS: saying “performance comes first” is a misnomer - if you change perf drastically, everything will become complicated. This is more about scale. It doesn’t matter how many preference, but rather people should understand how the caching pipeline and mediawiki works. There are complex use cases that touch sensitive areas of MW.
 * NH: ways to future-proof this from a naming POV?
 * JF: all of our naming conventions have changed over time


 * NH: migration implications?
 * JF: We could handle this the standard way. Once you’ve got a stable name, you can make changed rapidly


 * NR: Internal-only restriction? MS brought up the question of whether gadgets could use this. One idea I had : when launching this, we restrict it to internal-only usage. The concern is releasing it, opening the floodgates, people use it in ways we didn’t anticipate. Being conservative: this is internal use only, seems easier. Does anyone see a problem with this strategy?
 * AS: I don’t and I think it’s a good idea!
 * RK: I think this is fine, but even something for internal use needs to be well-documented! We don’t all know each other. Not super-discoverable, not announced, etc., but this doesn’t free us from having to think about use cases and documentation. Explaining that this is not something you should use lightly / should not use without approval from team X, will be an important part of this communication. Even if it’s internal use, we still need to document it well (how do we use it, you need to get approval from x team, etc)
 * MS: having this as restricted is a good idea. But we need to take into account what happens when it is not restricted. But - the definition of “internal” is tricky - does this include WMDE? “Only staff” gets complicated. I’m in favor of restricting, but how do we do this? Just by numbers?
 * AS: One way to look at it is to not put it as a gadget / allow users to use it as a gadget.
 * JF: There are ~400 people who can merge code into MW, about ~50 of them are from WMDE, and about ~50 of them aren't on Slack. Roughly.
 * MS: a combination of defensive coding but also policy
 * JF: we do this with beta features! The beta-feature allow list uses this - if you don’t list a feature in SiteConfig, you can’t use it. You must email James F if you want to use it. It won’t go live to production unless you go through this gate.
 * NR: This is for the beta features extension?
 * JF: we could use this for Core - if in array, then quick check
 * AS: We need to make sure this is clear: This is touching core of caching in mediawiki, do not touch it unless you're sure it's not going to bring down everything
 * MS: the next step, a group of people who are interested in a solution will brainstorm. Please alert Moriel if you’re interested in participating in this. Also - if there are other people who should be here


 * AS: please invite me there!

Action items

 * Second phase discussion around implementations / solutions
 * Reach out to Moriel if you’d like to be in the next phase of discussions around implementations / would recommend that another party be there