Per T41877, this was needed for https://en.wikipedia.org/wiki/Wikipedia:File_Upload_Wizard to work. Is it still? @Rillke, do you know if that tool has been updated to use something saner since 2012?

https://en.wikipedia.org/wiki/MediaWiki:FileUploadWizard.js

// However, since api.php sends back a response page that humans won't want to read,
// we'll have to channel that response away and discard it. We'll use a hidden iframe
// for that purpose.
// Unfortunately, it doesn't seem possible to submit file upload content through an 
// Xmlhtml object via Ajax.

Last update was 11:26, 24. Jun. 2015‎ and at this time, MediaWiki still supported IE8 so iframe upload was still required.

Brought up the issue at the script's talk page.

Hmm. Do *you* really want to support IE 8/9 with that tool, though? It
would probably be fine to just point these users to the plain
Special:Upload form.

(MediaWiki doesn't support IE 8 anymore, but IE 9 can't upload files
through XMLHTTPRequest either. IE 10 can.)

Do *you* really

I, the community or Future Perfect at Sunrise? I don't want.

would probably be fine to just point these users to the plain Special:Upload form.

I think the issue they've been trying to solve with that script was something with the workflow, mainly getting fair use material upload to WP and sending the free stuff to Commons.

In T131183#2158664, @Rillke wrote:

https://en.wikipedia.org/wiki/MediaWiki:FileUploadWizard.js

// However, since api.php sends back a response page that humans won't want to read,
// we'll have to channel that response away and discard it. We'll use a hidden iframe
// for that purpose.
// Unfortunately, it doesn't seem possible to submit file upload content through an 
// Xmlhtml object via Ajax.

Last update was 11:26, 24. Jun. 2015‎ and at this time, MediaWiki still supported IE8 so iframe upload was still required.

Brought up the issue at the script's talk page.

(just so it while reviewing the configuration) Do we really need it these days?

It appears still necessary to support FileUploadWizard.js, until that tool is updated to use more modern APIs (it is now definitely possible to "submit file upload content through an Xmlhtml object via Ajax").

As recent as last year in 2021, it was (re)requested on the enwiki script's talk page to port the script away from the iframe approach so that it can be used on other wikis since we do (correctly) enforce FrameOptions=DENY outside of enwiki.

I note that this request was not responded to in any way.

https://en.wikipedia.org/wiki/Wikipedia_talk:File_Upload_Wizard/Archive_7#X-Frame-Options

In T131183#8086641, @Krinkle wrote:

As recent as last year in 2021, it was (re)requested on the enwiki script's talk page to port the script away from the iframe approach so that it can be used on other wikis since we do (correctly) enforce FrameOptions=DENY outside of enwiki.

Outside of enwiki and zhwiki actually (T41877: X-Frame-Options: DENY in API responses breaks UploadWizard in IE8, consider using SAMEORIGIN instead, T173631: File Upload Wizard doesn't work well with X-Frame-Options set to be DENY on zhwiki).

It's a bit confusing that both of those tasks mention UploadWizard, but UploadWizard is not actually enabled on either wiki. I guess what happened was that FrameOptions=DENY broke UW, then frame breaking was temporarily relaxed via rOMWC22ceabed668b: (bug 39877) Set X-Frame-Options: SAMEORIGIN if UploadWizard enabled, and then UW switched to more modern technology so that was reverted, but same-origin framing was allowed on enwiki/zhwiki because of their custom upload script?

It should be possible to just replace the iframe with mw.Upload, right?

T41877 also says

The fix for bug 39180 ( https://gerrit.wikimedia.org/r/20472 ) broke UploadWizard in IE, because it uses an iframe to submit a form that includes a file upload input. This has to be done with a form submission rather than AJAX because it involves a file upload, and it has to be done in an iframe to prevent the browser from navigating away from the page. In modern browsers, it uses a combination of FileAPI and binary XHR so an iframe isn't needed, but in IE these features aren't available so it falls back to using an iframe.

FWIW, we haven't supported IE8/9 for a long time, and now don't support IE at all. File API (caniuse) and XHR 2 (caniuse) now have wide browser support.

In T131183#9148649, @Tgr wrote:

It should be possible to just replace the iframe with mw.Upload, right?

Yes, it's "just" a matter of rewriting the code.

Wikipedia is called out as being vulnerable to the GPU.zip attack because of this configuration. https://www.hertzbleed.com/gpu.zip/

Most sensitive websites already deny being embedded by cross-origin websites. As a result, they are not vulnerable to the pixel stealing attack we mounted using GPU.zip. However, some websites remain vulnerable. For example, if a user who is logged into Wikipedia visits a malicious webpage, that webpage can exploit GPU.zip to learn the user’s Wikipedia username (as we demonstrate in Section 5.4 of the paper).

5.4. Wikipedia username stealing example

As a proof-of-concept for a realistic attack, we demonstrate stealing a username. In this scenario the target iframe is Wikipedia, which shows the user’s username in the top corner. We run this PoC with multiple browser windows open, with one playing a YouTube video during the attack. Figure 17 shows the results of our attack on an Intel i7-8700 and an AMD Ryzen 7 4800U. We calculate the accuracy based on the ground truth after color binarization. Our attack is unoptimized, but completes in 30 minutes on the Ryzen with 97.0% accuracy. The Intel attack is significantly slower, at 215 minutes with 98.3% accuracy. Unlike previous works that are sensitive to noise in DVFS oscillation [24], [25], our PoC succeeds even in the presence of system noise, showcasing robustness.

That sounds pretty bad. But Wikipedia does deny cross-origin embedding, so I don't understand how the attack is supposed to work.

Also:

However, from JavaScript we can only access coarse-grained timers. For the feasibility experiments in Section 5.2, we build Chrome with debug symbols (v8_symbol_level = 2), and use uprobe to expose the CPU time-stamp counter to Chrome. The time-stamp counter allows us to synchronize the rendering process and the sampling process and pinpoint the block of sampled data that belongs to the same frame.

which I think requires a fairly generous interpretation of "realistic attack".

The attack is not about the API (although in theory you could pull off a similar attack against the API if it were cross-origin embeddable), so I guess the relevant task is {T112428}.

I was bored today and wrote the patch for the file upload wizard. https://en.wikipedia.org/wiki/Wikipedia_talk:File_upload_wizard#Use_AJAX_instead_of_<iframe>_in_the_script

My enwiki changes were accepted.

zhwiki has the same config override for the same reason. I prepared the patch for their version of the file upload wizard too: https://zh.wikipedia.org/wiki/MediaWiki_talk:FileUploadWizard.js#Use_AJAX_instead_of_<iframe>

By the way, there are many more localized copies of the script: https://global-search.toolforge.org/?q="document.createElement('iframe')"&namespaces=2%2C4%2C8&title=.*pload.*\.js

…but none of the other wikis have the config override, so I guess they're all somewhat broken. I won't bother with them all.

My zhwiki changes were accepted as well.

We can presumably remove the config overrides now, I want to do that next week.

Change 966919 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[operations/mediawiki-config@master] Remove $wgApiFrameOptions override for enwiki and zhwiki

https://gerrit.wikimedia.org/r/966919

Change 966919 merged by jenkins-bot:

[operations/mediawiki-config@master] Remove $wgApiFrameOptions override for enwiki and zhwiki

https://gerrit.wikimedia.org/r/966919

Mentioned in SAL (#wikimedia-operations) [2023-10-23T13:17:12Z] <urbanecm@deploy2002> Started scap: Backport for [[gerrit:967195|Remove 'currentProto'/'finalProto'/'proto' business (T348852)]], [[gerrit:966915|Remove unused $wgIncludeLegacyJavaScript]], [[gerrit:966919|Remove $wgApiFrameOptions override for enwiki and zhwiki (T131183)]]

Mentioned in SAL (#wikimedia-operations) [2023-10-23T13:18:26Z] <urbanecm@deploy2002> matmarex and urbanecm: Backport for [[gerrit:967195|Remove 'currentProto'/'finalProto'/'proto' business (T348852)]], [[gerrit:966915|Remove unused $wgIncludeLegacyJavaScript]], [[gerrit:966919|Remove $wgApiFrameOptions override for enwiki and zhwiki (T131183)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2023-10-23T13:29:09Z] <urbanecm@deploy2002> Finished scap: Backport for [[gerrit:967195|Remove 'currentProto'/'finalProto'/'proto' business (T348852)]], [[gerrit:966915|Remove unused $wgIncludeLegacyJavaScript]], [[gerrit:966919|Remove $wgApiFrameOptions override for enwiki and zhwiki (T131183)]] (duration: 11m 56s)