@AndyRussG - I get an error that I'm not auth'd to preview banners when I try to view https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners/edit/scervantes_B1920_0701_enWW_dsk_p1_lg_template_share_inbanner. Not sure if that's critical to this privacy review or not...

I'm not the person doing the review, but I did notice there is an XSS in this banner: https://en.wikipedia.org/w/index.php?title=Talk:RandomPageThatDoesntexist&action=submit&section=new&preloadtitle=%3Cdiv%20class%3Dfrb%3E%3Cspan%20class%3D%22%25AVERAGE%25%22%20data-foo%3D%22%26lt%3Bscript%26gt%3Balert(%27XSS%20on%3A%20%27%20%2B%20document.domain)%26lt%3B%2Fscript%26gt%3B%22%3E%3C%2Fspan%3E%3C%2Fdiv%3E&nosummary=true&banner=scervantes_B1920_0701_enWW_dsk_p1_lg_template_share_inbanner&force=1&preview%00=yes

Doing regexes on html and then re-inserting that html into the document is very very tricky to get right. I'd suggest instead using .text() on each text node and inserting with .text(), so the regexes get only done over text. If that's a complicated fix, adding an attribute like data-mw-banner to the outer div, and ensuring all selectors only select stuff that is decendents of that div (Since in MW users are not allowed to use attributes starting with data-mw) might be a short term fix to reduce the risk of users being able to set malicious dom elements. But switching to using .text() for the regexes is a much more reliable fix.

Ugh, thanks for finding that, @Bawolff. I'm going to break that out into a separate high/ubn ticket.

Filed: T239919

@Bawolff thank you so much for finding this!!!! This same code is in live FR banners across enwiki. I've created a separate task: T239922

Thanks again!!!

In T239778#5715514, @sbassett wrote:

Ugh, thanks for finding that, @Bawolff. I'm going to break that out into a separate high/ubn ticket.

Filed: T239919

Thanks!!!

@AndyRussG - I get an error that I'm not auth'd to preview banners when I try to view https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners/edit/scervantes_B1920_0701_enWW_dsk_p1_lg_template_share_inbanner. Not sure if that's critical to this privacy review or not...

That's probably from clicking something in the "Live preview" section? You should be able to preview the saved version of the banner by clicking the "Preview last saved version" at the top?

Ok, now that the dust has settled a bit from T239778#5714105 :) , I've had a look at this within the context of the original request:

Regarding the Facebook and Twitter share buttons:

1. The only code I'm seeing related to the share buttons in the banner referenced within the task description are the two window.open calls to facebook.com and twitter.com URLs, as the corresponding SVGs seems fine. Please let me know if there's anything else that I'm missing. I believe these window.open calls should be fine since IIRC, once a user interacts with a banner (including clicking upon or activating a linked URL), they are then covered by the donor privacy policy, specifically the Other service providers sub-section of the Sharing Donor Information section. Though I'm not sure this is even completely relevant since such actions are basically the same as clicking on any external link, such as any article footnote, etc. @JFishback_WMF may have some further clarifying thoughts on this. I'm guessing this has also been at least brought to WMF-Legal's attention?
2. Regarding the transmission of an HTTP referer header, that isn't ever explicitly mentioned within the current Wikimedia privacy policy, which is more restrictive than the donor privacy policy. While this is obviously something that many WMF and community members care about (as indicated within T180921), I'm not certain any further hardening around referer transmission would be a hard requirement in this case. Again, @JFishback_WMF may have some clarifying thoughts here.

Additional issues:

1. Given T239922 and its quick resolution (thanks again, everyone) I had a quick look at the JS for the banner again and didn't see anything particularly egregious, though I certainly did not perform any kind of full code review. That might be a part of the additional audit I mentioned at T239922#5719396. I was curious if the JS used for banners like this is purely stored within the MediaWiki namespace without code review or CI checks within gerrit, etc. I know it's probably very convenient to work with such resources in this way, but the importance of CN banners might warrant a different approach more akin with how we treat MW core/extensions and other production code.

I agree with @sbassett 's analysis here and don't really have anything substantive to add.

1. I think this is pretty unobjectionable since the user must initiate any action (i.e. we don't automatically load anything from Twitter or FB).

2. I'm not aware of any written policy specifically addressing this either way. I don't think the current functionality violates the PP. But...

I also think WMF-Legal should sign off on this if they have not already.

Hey, this is Sam w/ the Online Fundraising banner team - I appreciate everything discussed in this thread, as well as the important offshoot of T239922. Thank you @AndyRussG for starting this! And double thanks to @sbassett and @JFishback_WMF for your review.

I'll make sure this is surfaced to WMF-Legal.