In T233489#5513837, @Krenair wrote:

So it looks like we're not properly changing the CSP header to beta.wmflabs.org addresses. That would be bad, except they're listed as Report Only?

To answer my own question, i did a quick test - Currently its 26751 bytes compressed. Super aggressive gzip (zopfli) could in theory bring that down to 25532 bytes for a saving of 1219 bytes. More sane would be brotli, which could bring down to 23763 bytes for a saving of 2988 bytes.

Interesting. Thanks for sharing this. I wonder if this is an area that would benefit from more aggressive compression. The data is cached from what i understand so it doesnt have to be compressed on the fly, and getting as much as possible in that initial window seems important

In T233386#5508470, @Bawolff wrote:

As an additional check, is the included google analytics also intentional in light of T201022?
[I'm assuming it actually loads, I couldn't figure out how to disable DoNotTrack in my browser to test it]

As an additional check, is the included google analytics also intentional in light of T201022?

Is it intentional that wikimediafoundation.org is loading resources from wikimediafoundation-org-preprod.go-vip.net ?

I think a more fruitful starting place for this sort of thing would be doc.wikimedia.org - its probably simpler as a semi static thing, and i think at these early stages it has more relavent info than discourse does at present (although ideally search would search all the things)

In T231758#5490195, @Zoranzoki21 wrote:

Done all requested.

Im sorry, i dont mean to be harsh, but you are very far away from the expected level of familarity with mw code and quite frankly skill, expected of someone with +2 rights

In any case, critical errors thrown in DeferredUpdates should not be invisible per default on 3rd party installations. This ticket should stay open until that problem is resolved.

This is kind of an obscure aspect of CORS, and i certainly haven't tested it, so i might be wrong, but: https://fetch.spec.whatwg.org/#credentials says "Credentials are HTTP cookies, TLS client certificates, and authentication entries (for HTTP authentication). [COOKIES] [TLS] [HTTP-AUTH] ". My reading of that, combined with "A CORS non-wildcard request-header name is a byte-case-insensitive match for Authorization. would be that allow-credential just affect browser managed credentials, and if you explicitly put Authorization in the allowed headers (must be explicit, it is not included with a wildcard), then you can override the value of the Authorization header. But I haven't tested it, and CORS is complex, so I may be misunderstanding.

But if your authentication is coming from an Authorization header, and no cookies are involved, the Access-Control-Allow-credentials would have no effect, as that only controls browser level credentials (cookies, TLS certs, http basic auth, etc)

In T232176#5488306, @dbarratt wrote:

In T232176#5488296, @Bawolff wrote:

I'm confused. Are you talking about setting Access-Control-Allow-Credentials: true when Access-Control-Allow-Origin: *. My reading of https://fetch.spec.whatwg.org/#cors-protocol-and-credentials is that that is banned in the spec.

We would only add Access-Control-Allow-Credentials: true if the request included an Authorization header (which bypasses the cache), if it did it would reply back with Access-Control-Allow-Origin: <the request Origin>. (Again, this assumes we wouldn't be using Cookies, if we are then we would still need the whitelist like the Action API).

Credentials
If the API allows for authorization with the authorization code grant (or some other authorization mechanism that is stateless and does not force the client app to expose it's own secrets), then it is safe to add Access-Control-Allow-Credentials. >However, if the user adds the credentials the Access-Control-Allow-Origin will need to be specific to the Origin requested. Since credentialed requests are not cached anyways, this shouldn't be a problem.

the server is not aware of the logged-in state

the clients authorization token is not transferred to the server in an automated way

Storing session state on server side (whether in memcached or whatever) instead of as an encrypted blob on the client has lots of upsides

Whether Lua or JavaScript, there are some significant complications to this sort of thing when you're dealing with something that's fundamentally a text file, which is probably why the three examples are all programmed using a custom editor oriented around dragging and dropping "blocks" instead, so the human-readable names really are arbitrary labels and the editor always knows exactly which code-object everything refers to.

In T180860#5459714, @Neil_P._Quinn_WMF wrote:

@Isarra, @Bawolff is right that this needs special access to run. In addition, it's not possible to simply re-run the code I wrote in 2016; since then, the Analytics MediaWiki replica databases have been split across multiple hosts, so it's no longer possible for an analyst to create a new table in the staging database (as I created a new table of active users) and join it with the user_properties table of each wiki.
However, it seems like a lot of people are interested; in addition to all the comments here, @Jdlrobson recently asked me for this to help see the impact of T223824. So, I will raise this with my manager @kzimmerman and see if we can make time for this.
Since I'm thinking about it, let me ask some questions I was wondering about:

• As I understand it, the only valid skin preferences are currently vector, monobook, modern, cologneblue, minerva, and timeless. Any other preferences should be normalized to the default (currently vector). Is that right?

In T6845#5457634, @Guy_Macon wrote:

I am having a bit of a quandary here.
I see "I'll try to get more educated on the topic, and hopefully give more information in the coming weeks" at [ https://phabricator.wikimedia.org/T6845 ] but nothing since.
I am seeing the same thing at [ https://en.wikipedia.org/wiki/User_talk:Doc_James#13_years ]: "working on it" then nothing.
The cynic in me says that if I keep patently waiting nothing will happen and after a while I will be posting a "14 years" complaint, but if I start making noise about hearing nothing I will be embarrassed to discover that someone has been furiously working on this and watch as they change the Wikimedia software in a way that solves everything -- 15 minutes after I hit send on my complaint.
I am left with these known facts:

• For 13 years the WMF has failed to assign an employee or contractor the task of fixing this problem.
• For 13 years the WMF has failed to budget a single dollar towards fixing this.
• For 13 years the WMF has failed to provide an estimate of how long it is expected to take to fix this.
• For 13 years the WMF has failed to write any requirements for fixing this. ("Requirements" is geek talk for "please define what 'done' is and how we will recognize that whoever is working on this is done".)
• For 13 years the WMF has failed to make a plan for an independent third party (which in this case means "someone with a visual impairment accessing Wikipedia with a screen reader") to look at the results and verify whether the requirements were met.

So I ask the community: how long is a reasonable time for me to patently wait without any updates before going back to complaining about WMF inaction?

So roughly what needs to be done here:

In T200703#5456947, @gerritbot wrote:

Change 533728 had a related patch set uploaded (by Brian Wolff; owner: Brian Wolff):
[mediawiki/core@master] Better randomness for Special:RandomInCat and no more subcats
https://gerrit.wikimedia.org/r/533728

In T180860#5453204, @Isarra wrote:

So what exactly does one need to actually run these queries? Are you guys doing this on labs or quarry or what? Could someone rerun this or tell me exactly how I would do it myself?

https://www.mediawiki.org/wiki/Special:Code/MediaWiki/r80434 in the old numbering scheme = 3b84269eb2612e in the new numbering scheme

Thank you!

In T155029#5424117, @DannyS712 wrote:

Assuming that https://www.mediawiki.org/wiki/Module:ExtensionJson is kept updated by bot, I can update the template to extract data from there. At https://www.mediawiki.org/wiki/Module:Extension/sandbox I'm rewriting the current template display in lua, which eventually will control the entire infobox rather than just providing specific pieces of data.

In T230234#5414310, @gerritbot wrote:

Change 530009 merged by jenkins-bot:
[mediawiki/core@master] Set @return-taint of Sanitizer::stripAllTags to tainted
https://gerrit.wikimedia.org/r/530009

In T200703#5422151, @Marostegui wrote:

It would be helpful if you guys can come with some specific example queries we could run on production, check their query plan etc. That would help to understand if they are viable or not :-)

Hmm, this is the second issue with revdel & Special:Redirect :( [The other one being T187638]. Guess we need to be careful with this page

@Bawolff How about using the existing approach for large categories, and one based on page_random for smaller categories? Determining category size has to be efficient, as we are doing it every time a category page is shown (for pagination purposes

Yes, i was speaking a bit informally. I meant a constant number of queries which read one-ish rows which would technically be O(log n) due to the logrithmic time of looking up an arbitrary item in a B-tree

P.s. for historical background see T27931 where the suggestion to use the search backend also came up (probably more practical now that we movedfrom lucene to cirrus)

In T200703#5420630, @Huji wrote:

Is there a reason we are using cl_timestamp and not page_random here? The code has been using cl_timestamp since 2013 at least. In comparison, Randompage and Randomrootpage both use page_random.

Note. Only happening on my talk page not happening on other pages. Maybe related to having a new msg on my talk

In T230124#5402604, @sbassett wrote:

Are gadgets expected to fall under the standard Wikimedia privacy policy? I'm not seeing any specific privacy policy just for them, nor am I seeing any exceptional language for them within the standard privacy policy. Though gadgets are fairly similar to user scripts, which often call external resources, and which will indeed break once CSP is set to enforce (whenever that may be.)

One of the commonly proposed schemes if you only need equality comparison is to use deterministic encryption (Abbreviated as DTE-encryption in the paper). If you don't have the private key, deterministic encryption basically has the same properties as the HMAC construction you proposed. The linked paper discusses some attacks on encrypted db's, using medical information as an example. It mostly concerns itself with systems that allow range queries, but section 5 talks about deterministic encryption. It describes 2 attacks, the first one (frequency) is pretty straight forward. Applied to this bug, it would be something along the lines of: Take all the IP edits from the last month before switching to the hashed IP scheme. The IP that edited the most is probably the same as the hashed IP in the next month that edited the most. Then take the second most common IP, and so on.

I do not believe there is a perfect solution, only less-terrible ones. If we are searching for a perfect solution, I think we will be searching forever.

If you extend RedirectSpecialPage it happens automatically. Otherwise override isListed() method

I kind of disagree. I don't think subsequent pages of results should start at 1. If we knew how many results came before on previous pages, then I would think this is a good idea, but since we don't, i think unordered lists are less confusing.

Just as an aside, the ideal way to demonstrate fb surveliance is taking place, would be to attach a HAR file that shows what network connections are made, although doing this does require some technical knowledge it would be pretty unambigious.

I think this is fine. Logging when it matches an abusive pattern isn't a privacy issue, because it's not correlating reader behavior, since the url isn't a page being read - it's abuse.

The form seems a little underfilled out... There was basically one production error which arguably was intentional behaviour (albeit maybe a poor design choice not to suppress it)

In T32674#5106469, @TheDJ wrote:

@Dvorapa that makes use of MySQL logic to do the actually implementation of that a setting. We cannot make use of that in Javascript (well localeCompare in theory does, but most browsers haven't really implemented it and just fallback to a standard collection for most languages)

Related to this, is potentially the old feature request for translatable category names, which at one point commons really wanted, although i havent heard much about it recently (one suggested solution was to basically switch up the display title based on user language to the various redirects to the category, although i think there were some concerns that that is hacky, but the discussikn was a long time ago and i dont entirely remember)

Partial read restrictions are rather poorly implemented in mediawiki. They prevent direct page views but there are lots of indirect ways to leak page contents. There has been little interest in fixing this in the past as its not something that wikimedia uses. There has been mixed interest from (corporate) third parties with some really wanting it but a minority viewing lack of functional read restrictions to be a killer feature (due to perverse incentives in the corporate environments those users use mediawiki in).

In T202625#5344737, @Vogone wrote:

In T202625#5344657, @Legoktm wrote:

Per bawolff, this isn't really suitable for a user preference, sorry. Plus with UrlShortener, it would defeat the point of the whitelist since people could just shorten https://en.wikipedia.org/wiki/google:foo

Please read the comment right above yours.
Links like
https://en.wikipedia.org/wiki/google:foo
https://en.wikipedia.org/wiki/luxo:foo
and whatnot are not possible, anyway, so this cannot be a concern.

Lastly, AbuseFilter should implement the userCanhook to control access to the filters (i.e. if a filter is marked as Private, it should prevent read for all unprivileged users of both the content and the discussion page). The private filters will also need to be filtered out of the database replicas (that are available on Toolforge and as dumps).

Does maybe ci have less memory available? (When i used to test on my old laptop with low ram when ram ran out things slowed to a crawl (presumably lot of swapping)

Looking at the code, what you're describing can't really happen. Are you sure you didn't just set $wgSpamRegex to something else in LocalSettings.php, and the problem went away when you added $wgSpamRegex = false; at the end of LocalSettings.php because it overrided the previous code in LocalSettings.php?

Note, the default has been an array since 2008 - 06e3d0e3777

Where SESSION_ID is the users session id. This would create a new mask every time the user's session was generated (i.e. each new device and browser, etc.). This would, of course, break the social contract of what the mask represents, but would be technically trivial to implement as the masks would function identically to the IP masks.

From a Wikipedia anti-vandal perspective, I suspect the hardest sell would be not being able to see patterns related to ranges/ip-distance, at a glance.

In T216682#5298861, @MaxSem wrote:

Unfortunately, Argon2 will most likely be broken in a backwards-incompatible way in PHP 7.4: https://wiki.php.net/rfc/sodium.argon.hash
Can't trust it right now.

So yeah, I guess this counts as passes security review as none of those issues were security related. May need additional security review if the extension changes significantly. Should still get approval from Rel engineering before deploy.

Main reason its restricted is it used to be autoconfirm but enwiki got mad (if i recall)

In T101631#5171643, @Bstorm wrote:

If I can get a thumbs up from @Bawolff, perhaps?
The current logic expressly filters rev_len on deleted revisions: if(rev_deleted&1,null,rev_len) as rev_len. I don't know if that's just for consistency or if someone thinks that really should be kept out of the replicas. As stated above, it does seem to be available online, though I'm not sure if that's all versions of the deleted field, since that's an integer, I think.

So I guess this isn't quite ready for a security review given previous comment, but some thoughts

This is old enough now to no longer be relevant.

Ah, that's confusing. Thanks.

The threat model here is kind of debatable. Its unclear what security goals we are trying to accomplish with the displaytitle restrictions, and thus I'm unsure (unsure in the sense of actually do not know, not unsure in the sense of disagreeing) if further restrictions on it are justified.

wikititle:/// is supposed to prevent query paramters from being used, however it could probably be bypassed if they are percent encoded due to T96274 (e.g. https://en.wikipedia.org/wiki/Main_Page%3faction=history%26curid=2120 is interpreted by our servers incorrectly )

In T207246#5160385, @sbassett wrote:

Re: privacy, the sites reference the standard Wikimedia PP. And while most resources seem to come from internal Wikimedia sites, some definitely do not (e.g. images within the Shocking tales from ornithology post on en.planet.wikimedia.org and a few others.)