[20:34:47] Does anyone have a link to the Gerrit patch that required re-auth for sitewide JS changes on Wikimedia wikis (mentioned @ https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation/Product_and_Technology/Product_Safety_and_Integrity/March_2026_User_Script_Incident#c-EMill-WMF-20260306163600-Ep%C3%ACdosis-20260306104800), or know if it was done via e.g. `PrivateSettings`? [20:35:43] (I tried looking myself but couldn't find it 😅) [21:49:50] Was there a change to the CSP that already got deployed? I haven't been following closely but e.g., Xtools isn't loading for me due to CSP errors [21:51:51] There were a bunch of recent CSP changes deployed [21:52:05] I'd suggest filing a phab ticket if its causing problems [21:53:26] how recently deployed? Surely xwiki user scripts being blocked by CSP would be noticed pretty fast [21:53:42] Like 3 days ago? [21:54:00] There was a giant screw up and CSP was deployed early as a response [21:54:01] yeah so surely someone has a ticket on it by now [21:54:20] If everyone assumes that, nobody files a ticket [21:54:37] noooo bystander effect isn't real; it can't hurt me :( [21:55:31] okay yeah there's some tickets for what domains are getting added https://phabricator.wikimedia.org/T419265 [21:58:10] gah, *.mediawiki.org and www.mediawiki.org are in the CSP but not mediawiki.org >.> [21:58:53] What else even is under mediawiki.org other than www.mediawiki.org? [21:59:15] seems odd to include the * [22:00:42] Not sure. I think I can workaround by just using the FQDN in my import, but it seems like better UX to add it to the CSP unless there's a good reason not to [22:01:18] I mean, the more things in the header the more bloated it gets [22:01:24] mm true [22:01:29] I guess that byte cost does add up [22:01:29] But at this point they seem to be adding the whole internet to it [22:02:01] Think of all the extra latency you will save by avoiding the redirect. that's one whole round trip :P [22:02:24] tbh, i don't really get the point of a CSP policy that has github and multiple CDNs in it [22:02:35] I too clear my cache after every request [22:02:46] lol [22:03:15] hm; the xtools page has the install instructions including the www, so my not including it could be chalked up to user error [22:04:31] ughhh but xtools.wmcloud.org is blocked by the CSP now [22:05:44] oh, report only, not an actual block [22:09:57] would be interesting to have some sort of standard for user controlled CSPs. It'd never really work on a large scale since only technical users would really get it, but being able to just locally choose what sites are on a given website's CSP would be very nice. [22:11:01] Once upon a time i was working on CSP (this was years ago and it never came to fruition), but the vauge plan was that gadgets would be able to declare what sites they needed and there would be a pop up for the user to authorize it when they enabled the gadget [22:11:24] idea thief! [22:12:12] I actually think having a preference is reasonable. I mean if people are technical enough to put random junk in Special:Mypage/common.js then they are technical enough to put random urls in a field in Special:Preferences [22:12:27] Although it all ind of comes down to what people are trying to accomplish with CSP [22:12:40] And I'm not actually sure what the security goals of the current iteration of CSP is [22:13:03] I mean isn't there a gadget that one-click installs stuff into your common.js for you [22:13:14] I think it's just limiting attack surface [22:13:17] It feels like the incident made everyone jump the gun when it came to communication [22:13:32] which is understandable [22:13:35] attack surface is pretty wide if you're including github.io [22:14:42] I personally feel that network restrictions in CSP are mostly useful as a good faith privacy control (make sure admins don't uninentionally compromise user privacy) then anything that guards against malicious people [22:15:48] Sure you could make data exfiltration and external communication really annoying, but its never going to be bullet proof [22:15:57] yeahhh [22:16:20] Now on the other hand, eliminationg 'unsafe-inline', that truly would make everything more secure [22:16:57] I mean it CSP standards really wasn't designed for this kind of use case of random user scripts that anyone can grab and install [22:17:45] I don't think any system can fix the problem of intentionally running maybe malicious code [22:18:00] You can't both trust and not trust people. You have to choose one [22:19:15] Like if we really wanted to eliminate the user script security problem, we'd have to do some sort of aggresive sandbox. I think figma solves this by compiling a js runtime to wasm and running user scripts inside that [22:19:30] but that would also defeat much of the point [22:19:56] Although imagine a world where you could have user-script like features written in lua. That'd be pretty cool [22:20:02] noooo [22:20:08] I don't like JS but I'd take it over lua any day [22:20:46] Come over the to the dark side, we have arrays starting at 1 [22:21:00] literally empty standard library [22:21:12] lol true [22:21:14] drives me nuts how imperative it is too [22:21:40] The other day i wanted the equivalent of javascript's String.indexOf [22:21:44] Lua literally does not have it [22:21:51] yeah it's painful