[00:04:55] @seen andre__ [00:05:03] wm-bot: Why you do this to me... [01:26:37] legoktm: is there an updated CodeReview dump I can test? [01:26:48] (I suspect there is but couldn't find where) [01:26:55] given recent patches [01:33:18] Krinkle: it's on static-codereview.wm.o [01:40:35] legoktm[m]: thx. looks like the pages are missing , as a result browsers are loading quirks mode default agent styles, which result in having a reset font size that's unusually large in Firefox. [01:40:54] I'll jot down a few more minor fixes and a CSS patch to make it a bit more readable baseline. [01:41:02] but LGTM otherwise, and that could be done post-launch if needed [01:46:08] Krinkle: great, CSS is quick to update and if we just need to prepend the doctype we can do that without running the whole script again [01:48:26] legoktm[m]: one other thing, maybe, how do you feel about a hack to strip the purge link? There's other links that won't make sense but this seems like the most prominent one that we can do without. [01:49:28] Yeah we can regex it out [01:50:23] Guess there's no CSS class to hide it with [01:50:49] yeah [01:50:52] well, not yet :D [01:50:58] but let;s regex it [08:08:54] "Any attempts... to enable gadgets or deploy common.js code that involves communicating with Cloud VPS or other non-prod infrastructure has been and will continue to be... shot down on-sight..., citing the WMF Privacy Policy." https://phabricator.wikimedia.org/T239077#6135626 [08:09:36] Could there be a way to create "non-prod infrastructure" that complies with the WMF Privacy Policy? [08:10:50] that would just be prod then? [08:11:19] * enterprisey didn't expect a reponse that fast and hurries to dust the potato chip dust off his fingers [08:12:21] alright, to get the XY problem out of the way, my current project is a better edit-request process on enwiki, implemented in a gadget [08:12:44] the user may give a URL as a source/citation, and I want the gadget to check the URL in various ways [08:13:15] that it resolves, that it's not on Google's phishing list, that it's not banned on WP:RSP, etc [08:13:55] I can't do (some of) these checks from the browser because of CORS, and I can't do them from toolforge or "non-prod" because of what I quoted above [08:14:10] it's fine to contact toolforge as long as you've informed the user that you're doing so [08:14:37] that's cool [08:14:42] for example, https://en.wikipedia.org/wiki/Special:Gadgets marks gadgets that contact external sites with "(E)" [08:14:46] will it hit the CSP in the future? [08:15:08] in your case, the input field could saying something like "This will use the XX tool on Toolforge to evaluate the URL" or something [08:15:30] there's a task somewhere about allowing users to maintain a CSP domain exemption list [08:15:58] yeah, https://phabricator.wikimedia.org/T208188 [08:16:04] what if I want logged-out users to use this? [08:17:27] my idea, then, is "toolforge but different enough that it can go on the CSP approved-list" [08:18:07] probably infeasible, but I'm asking here just in case. (So, no UAs in logs, etc) [08:18:13] the things that make it "different enough" is that the code has been reviewed for security, privacy, and any data collected is only seen by people who are NDA'd...which is basically the bar to get something into production [08:19:16] well, that's reasonable enough [08:19:24] it would be nice if the (soon to be renamed) SpamBlacklist could check with the Google phishing list, and was nuanced enough to know about fully banned domains vs "deprecated" vs ... [08:19:42] my next complaint was going to be about how the people who do the reviews are ridiculously busy, but what else is new :) [08:21:02] the not-so-secret loophole is that deploying modifications to existing extensions usually doesn't require formal reviews, it's on the standard code review process to catch those kinds of issues [08:22:52] ugh... I'd inquire about doing that for this project, but the rules for checking URLs would change frequently and I wouldn't want to do a code review each time [08:23:14] people have abused this in the past to create omnibus extensions, but I think this would be reasonably in scope for SB. [08:23:54] for your project I think doing a prototype or intial implementation as a gadget seems like a good idea, and if it takes off, it could be integrated into SB [08:24:08] are SB's owners busy, or mega-busy? [08:24:17] non-existent ;) [08:24:34] you could also have it split a bit - an API that does the heavy lifting on the MW side, and then your gadget code interprets the results however you want, and gives you more flexibility with updates [08:25:07] https://phabricator.wikimedia.org/T224921 [08:25:50] well that paints a grim picture for the feasability of my project [08:26:15] *feasibility (ugh!) [08:27:41] although perhaps my initial belief that it would be easy to toss some stuff into prod on the ~7th most visited website :) [08:27:50] *[...] was flawed [08:29:20] it gets easier the more you do it and the more familiar you get with the process :) [08:31:24] would you say going the SB route as you suggested is rated as "entirely unfeasible" or "there's an outside chance"? [08:37:09] outside chance I guess, if you break it down a bit, e.g. does checking the Google list require us having a mirror of the data set? Or are we making an API request to Google each time? Does that require an API key? Does it cost money? If we expose it via a free API, is Google going to be OK with that? Do we need usage limits? [08:38:00] "we’ve made Safe Browsing services free and publicly available for developers and other companies to use in their applications and browsers" -docs [08:38:56] For the RSP part, we need some structured format to read that data with, so maybe a JSON page. Are editors/admins going to be OK with having a separate page to need to update? Is JSON going to be OK with that or do we need some other format? Could it be integrated with the current spam blacklist page format? [08:39:17] all doable, just requires a bit of figuring out first [08:39:23] and nice [08:40:14] I figure RSP can be clientside because we can pull it with the API [08:40:34] although honestly we'll probably want a different machine-readable database with only the obvious/clearcut cases, to minimize Strangeness [08:40:57] I have a whole design doc, but unfortunately it's currently in the form of some scribbly papers on my desk [08:41:11] probably should type it up [08:42:00] :D [08:42:06] The script would want the HTML of the website at some point - would a service that just grabs the HTML of a page make it through review? [08:42:07] don't you still need it in a machine-readable format? [08:42:27] (it = RSP) [08:42:30] why do you want the HTML? [08:42:51] check for wordpress/mediawiki [08:43:06] also, later, the user provides a quote from the source and I'd like to check if the quote is really from the website [08:43:44] (and check for other common blogging platforms; it's probably going to change, so might as well keep the frequently-changing part in JS) [08:43:54] ("it" = "the rules for checking the HTML") [08:46:39] I think in safeguards in place (timeouts, size limits, etc.) it seems doable. Citoid/Zotero is hitting arbitrary websites already [08:47:17] neat, thanks for all the answers [08:47:51] probably some BEANSy issues too, like making sure we don't end up as a DoS vector [08:48:15] ah, or a paywall defeater... [08:48:36] OK, I guess we want to move the logic serverside after all... [08:48:52] could I get away with Node or something or would it have to be PHP? [08:50:13] MediaWiki extensions are all server-side PHP. There are also nodejs (and Python and golang) services that are deployed on Kubernetes, but IMO the path to production for a nodejs service is less defined than extensions [08:50:20] gotcha [08:50:38] * enterprisey sighs [08:50:42] why can't I pick easy projects [08:51:41] they're not as fun :-) [09:04:18] https://en.wikipedia.org/wiki/User:Enterprisey/Edit_Wizard_design_doc [09:04:37] and on this day I learned that MediaWiki turns ftp:/// into a link (just the three slashes and then the end of the line) [09:04:48] that code path probably hasn't been hit since the pleistocene [09:07:32] https://en.wikipedia.org/w/index.php?target=ftp%3A%2F%2F*&title=Special%3ALinkSearch [09:08:53] https://gerrit.wikimedia.org/g/mediawiki/core/+/3cf9b2e64db22623a512d1ca7f7a688835722d61/includes/DefaultSettings.php#4902 is the list of supported URL protocols [09:12:27] I clicked ready to see some protocols I'd never seen before, and I was not disappointed [09:12:57] also, that first link is a little funny [09:19:28] at any rate, thank you very much for all the help, I'll carry on with the prototype [10:56:55] [[Tech]]; 49.199.99.88; 0; https://meta.wikimedia.org/w/index.php?diff=22618394&oldid=22616254&rcid=21212481 [10:57:16] [[Tech]]; Synoman Barris; Reverted edits by [[Special:Contribs/49.199.99.88|49.199.99.88]] ([[User talk:49.199.99.88|talk]]) to last version by 1234qwer1234qwer4: reverting vandalism; https://meta.wikimedia.org/w/index.php?diff=22618395&oldid=22618394&rcid=21212482 [10:57:25] [[Tech]]; 49.199.99.88; Gone; https://meta.wikimedia.org/w/index.php?diff=22618397&oldid=22618395&rcid=21212484 [10:58:05] [[Tech]]; 49.199.99.88; -; https://meta.wikimedia.org/w/index.php?diff=22618399&oldid=22618397&rcid=21212489 [10:58:14] [[Tech]]; Synoman Barris; Reverted edits by [[Special:Contribs/49.199.99.88|49.199.99.88]] ([[User talk:49.199.99.88|talk]]) to last version by Synoman Barris: reverting vandalism; https://meta.wikimedia.org/w/index.php?diff=22618400&oldid=22618399&rcid=21212490 [10:58:21] [[Tech]]; 49.199.99.88; [none]; https://meta.wikimedia.org/w/index.php?diff=22618401&oldid=22618400&rcid=21212494 [10:58:45] [[Tech]]; 49.199.99.88; -; https://meta.wikimedia.org/w/index.php?diff=22618402&oldid=22618401&rcid=21212495 [11:01:19] [[Tech]]; Hulged; Reverted 2 edits by [[Special:Contributions/49.199.99.88|49.199.99.88]] ([[User talk:49.199.99.88|talk]]): Rvv ([[:en:w:WP:Twinkle|TwinkleGlobal]]); https://meta.wikimedia.org/w/index.php?diff=22618407&oldid=22618402&rcid=21212502 [23:33:40] musikanimal, since we were talking about it the other day, is there a good way to signal "I think this proposal should be archived" for the wishlist? [23:40:18] Yay Izno ! An AbuseFilter will prevent non-WMF accounts from (un)archiving proposals because unfortunately it is abused; but comments from everyone, in particular well-versed, knowledgeable people who understand the stack like you (staff or not) is enough. We read everything everyone says :) [23:41:06] ah, thought there might be a {{maybe should be archived}} lying around :P [23:41:15] with associated category [23:43:07] Nope, you can certainly say that if you want but there's no official system or templates involved. Tomorrow is day 1 of our "grand undertaking" to go through every proposal [23:46:45] It's all in the FAQ but for anyone reading who's unaware, we have a 2-week review period overlapping with the proposal phase. This is when we make the yes/no on the proposals, gauging if they're in our scope [23:48:12] This year though we have a "larger suggestions" category, which serves as a way for the community to express what they want without us suppressing it solely because it's too big our team [23:48:26] yeah, I like that add [23:49:02] * Izno puts global templates, completion of MCR and subsequent use, and nuke all the old javascript systems deployed on there [23:49:04] I'm personally very excited about it! So propose whatever you want, small or large. All ideas welcomed :) [23:49:16] Hehe exactly! [23:53:09] actually, rewrite all the gadgets/scripts to not use deprecated Javascript might not be too far outside what commtech could handle [23:53:26] maybe outside your expertise though? [23:56:26] Lol [23:56:43] Make it only support IE6 [23:57:23] You probably won't get any bug reports for supported platforms either, since no-one would go through the pains of using IE in the first place. [23:57:34] +1 ! [23:57:56] perryprog, galaxy brain [23:58:10] We officially don't write new features that support IE now, at least, unless we have to [23:58:36] So ES6+ is largely OK in MediaWiki Core