Re: [Wikitech-l] Fwd: New newsletter: Tech Showcase
Hi Brian, Hi Quim, Thank a lot for your detailed answers! I understand the trade-offs there, and I want to thank you again for the notifications which, whatever their form, are definitely a valuable improvement over… well… no notification :) Best regards, -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: New newsletter: Tech Showcase
Dear Quim, 2017-10-13 12:40 GMT+02:00 Quim Gil : > TLDR: Please give this a try, subscribe, and forward the link to other > mailing lists or projects: https://www.mediawiki.org/ > wiki/Newsletter:Tech_Showcase. > > The simplest and easiest way to know > about interesting software being developed by staff or volunteers for our > readers and our contributors. > > No tech knowledge needed and no time commitment required either. You will > just receive one sentence notifications linking to the fresh software > showcased. Thank you! Do you think it would be possible somehow to receive the actual content, either by RSS (preferred) or by email (fine as well)? Here, I'm getting an email with only a link to a newsletter with only a link to the actual content. That's two levels of indirection with little information on what the notification is about, nor any way to easily keep the content at hand for reading later. We had a discussion about the ambassadors' announce format a few months ago (was it with Benoît or Johan? I think Benoît, but I'm not sure) and I already underlined how the mailing-list and RSS formats currently in use were great for people who have to deal with hundreds of notifications per week. I understand that this would mean more work for whoever writes the newsletter and that the mediawiki newsletter extension may not yet provide a way to send more content than just a title, so I'd be perfectly fine with a negative answer. I just want to draw attention to the the added cost to access the information. Thanks again and best regards, -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Superprotect is gone
2015-11-05 18:34 GMT+01:00 Quim Gil : > today we are removing Superprotect from Wikimedia servers. This is great news, thanks! -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New RFC: better JS minification
2015-09-04 1:37 GMT+02:00 Roan Kattouw : > On Thu, Sep 3, 2015 at 4:15 PM, Jon Robson wrote: > >> Thanks, I thought I was alone with being confused by this e-mail. As >> Jérémie correctly states we'll likely to get __less__ bugs with a more >> maintained library. > > Less than zero? No one has managed to find a single bug in > JavaScriptMinifier.php since 2011. Yeah! Could I be the last person to have reported a bug in it? :D https://phabricator.wikimedia.org/T30207 More seriously: I assume we still use JSMin+ somewhere, don't we? When saving scripts, for validation, maybe? The issues I've encountered a few weeks ago with gadgets that broke when migrated to ResourceLoader because of their use of reserved identifiers were clearly related to it (I traced them back to include/libs/jsminplus.php in core) and not to JavaScriptMinifier. I thought it was at minification time, but it seems I was wrong. -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New RFC: better JS minification
2015-09-02 1:53 GMT+02:00 MZMcBride : > Ori Livneh wrote: >>On Tue, Sep 1, 2015 at 8:43 AM, Jérémie Roquet >>wrote: >>> Has the RFC been abandonned because of lack of interest? >> >>Speaking for myself: at the time the RFC was written, I was skeptical that >>the benefits would be worth incurring a dependency on an external service >>(or the requirement of shelling out). But since then we have had a lot of >>discussions (in the RFC meetings) on how to do micro-services correctly, >>and some good abstractions have come out of that. So +1 for reviving it. > > I'd personally prefer that we move in the other direction, removing the > minification. I think it's harmful to the open Web to minify, or worse, > obfuscate our code. As expected, we've encountered a number of bugs that > disappear when the debug=true URL parameter is specified. And given other > performance optimization work and existing optimizations such as gzip > compression, I don't see the benefits outweighing the costs. I had the same point of view only a few days ago (discussions at Debian got me there), but since then, I've changed my mind after some experiments: minification can save additional percents compared to gzip (the actual impact for our code is to be computed, but for jQuery, it's already about half the size). I see no need to obfuscate for the sake of obfuscation, indeed, but neither do I see how minification can be harmful to the open Web per se: in our case, the original, non-mangled source code is always available. In my eyes, it's not different from running binaries or bytecode instead of interpreting the source code for performance reasons: as long as you have the source code and the ability to do reproducible builds, it's ok. As for bugs, I fully agree with you. It's an argument against minification, but also an argument in favor of dropping JSMin+ for another more used and actively maintained minifier, such as UglifyJS. Best regards, -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New RFC: better JS minification
Hi everyone, I was running some experiments with UglifyJS lately and so I stumbled upon this RFC which shows that if I've not discovered anything new, we can still get ~15% smaller JS files. 2014-03-19 22:16 GMT+01:00 Max Semenik : > Hi, I'd like to present a new RFC for your consideration: > https://www.mediawiki.org/wiki/Requests_for_comment/Minifier > > It is about how we can shave 10-15% off the size if JavaScript > delivered to users. Now, it's also about supporting newer versions of ECMAScript (if we don't target full backward compatibility, of course), because it seems to me that unlike UglifyJS, JSMin+ has not been updated for a while and could choke on some valid syntax with error messages that are not exactly… explicit for casual JS developers (I've experimented that a few weeks ago with local scripts making use of reserved words as identifiers — not exactly valid code, indeed, but code that had worked for years in most browsers). Has the RFC been abandonned because of lack of interest? Best regards, -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: wikiscan / similar for english wikipedia
Hi everyone, 2013/1/30 Paul Selitskas : > Perhaps, we should not limit such requests to just English Wikipedia. It's > better to contact the project maintainers directly first. If you're looking for the maintainer of Wikiscan, here's his talk page: https://fr.wikipedia.org/wiki/Discussion_utilisateur:Akeron . Best regards, -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] IDE for wiki-markup
Hi, I'm using Emacs for mediawiki editing on a daily basis. mediawiki-mode has a number of cool features including syntax highlighting, snippets, quick moves, helpers for talk pages, ability to open, navigate and publish without leaving the editor… And as it's not an editor designed specifically for wikitext, you also have the extra benefit other modes such as javascript or css. There is no contextual auto-completion, though; ie, completion is only based on what has already been typed before. Best regards, -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] jQuery 1.9 will remove $.browser (deprecated since jQuery 1.3 - January 2009)
Hi Timo, 2012/11/7 Krinkle : > Just a reminder that jQuery will (after almost 4 years of deprecation!) drop > $.browser [1] in jQuery 1.9. Thanks for the reminder: it was still used in the MediaWiki:Commons.js of the French Wikipedia. What frightens me a bit is that I've been unable to find it using the internal MediaWiki search engine; I've had to search by myself. Best regards, -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Secure.w.o in js on wiki sites
Hi, sorry for the late reply. 2012/2/23 Antoine Musso : > Le 17/02/12 13:47, Jérémie Roquet a écrit : >> The reference in this script is still useful for people that continue >> to use s.w.o; it shouldn't break anything even if s.w.o is down. >> >> What about a 301 redirect from s.w.o to the new URLs so that we can >> clean up all the references to s.w.o without breaking anything? > > We really should, personally want, stop using the secure.wikimedia.org > domain. Sure, that's exactly why I suggest we redirect s.w.o to the new URLs. > Any occurence should be replaced on sight :-) As long as we still provide s.w.o, it seems to me that we shouldn't make it less secure. Best regards, -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Secure.w.o in js on wiki sites
2012/2/17 Jérémie Roquet : > What about a 301 redirect from s.w.o to the new URLs so that we can > clean up all the references to s.w.o without breaking anything? https://bugzilla.wikimedia.org/show_bug.cgi?id=31563 :-) -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Secure.w.o in js on wiki sites
Hi Mark, 2012/2/17 Mark A. Hershberger : > Today, secure.wikimedia.org was offline for a bit and, in my tour of > Village Pumps after the rollout of 1.19, I saw some problem reports that > were the result of secure.w.o but were mistakenly attributed to 1.19. > > Using Google, I found several instances refering to secure.w.o. I can't > fix these, but maybe some of you guys can. > > ** https://fr.wikipedia.org/wiki/MediaWiki:Common.js The reference in this script is still useful for people that continue to use s.w.o; it shouldn't break anything even if s.w.o is down. What about a 301 redirect from s.w.o to the new URLs so that we can clean up all the references to s.w.o without breaking anything? Best regards, -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Cross-wiki user talk notification
2011/1/17 Platonides : > Jérémie Roquet á écrit: >> I guess I should really dive into MediaWiki development… > Feel free to send us patches. :) > See my previous message about using CentralAuth for that. CentralAuth > extension is not really an entry level extension, but you may have luck > since you would just be adding hooks. Yeah, thanks for the clues :-) -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Cross-wiki user talk notification
2011/1/11 Ilmari Karonen : > On 01/11/2011 11:59 AM, Jérémie Roquet wrote: >>> And there's a handy property to determine if you have new messages: >>> http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=hasmsg >> >> Unfortunately (or fortunately), userinfo cannot be retrived using jsonp [1]. >> >> [1] « callback - If specified, wraps the output into a given function >> call. For safety, all user-specific data will be restricted. » — > > Hmm, true. You might be able to emulate the functionality by using > prop=info on the user's talk page (and perhaps storing the last time the > user visited the page in a cookie). Hi again. Sorry for the late reply (as I read most of wikitech-l threads in batch, I missed that one after the subject change). Yes, that's a good idea and I think I'll do something like this. Thanks! > (Ps. It strikes me that the simplest and most efficient way to implement > cross-wiki user talk notifications would be as a MediaWiki extension. > Why do we not have one already?) Sure. It would be both far more efficient and easier to set up. I guess I should really dive into MediaWiki development… Best regards, -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] X-Frame-Options DENY / SAMEORIGIN and cross-wiki userscripts
Hi Platonides, 2011/1/10 Platonides : > Jérémie Roquet wrote: >> It's not as powerful as the iframe hack was (since it's limited to >> the api), but I think it's enough for me to release a quick fix for >> iKiwi (not for xmsg, unfortunately, because userinfo is not accessible >> that way). > Why do you consider the api less powerful than "dom scraping" ? > What can't you do with it? Well, it's not an issue about the api per se, but rather a weakness of the jsonp approach: - You can't fetch user-specific data [1] - You can't send POST requests, meaning you can't edit or create pages [2] Both limitations are of course fortunate because it would allow malicious sites to know about their visitors or to edit Wikipedia on their behalf. > It fits perfectly for fetching the interwikis: > http://en.wikipedia.org/w/api.php?action=parse&page=Main_Page&prop=langlinks Yes, that's the good point. I'm very happy Ilmari came with the jsonp idea as it's exactly what I need for iKiwi to work again. And thanks for the langlinks idea! > And there's a handy property to determine if you have new messages: > http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=hasmsg Unfortunately (or fortunately), userinfo cannot be retrived using jsonp [1]. Hopefully, with CORS we'll have access to the whole api (including userinfo and writeapi) (and to scrapping, if needed for any reason). Thanks for your ideas! Best regards, [1] « callback - If specified, wraps the output into a given function call. For safety, all user-specific data will be restricted. » — [2] « action=edit * Create and edit pages. [...] This module only accepts POST requests. » -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] X-Frame-Options DENY / SAMEORIGIN and cross-wiki userscripts
2011/1/9 Roan Kattouw : > 2011/1/9 Jérémie Roquet : >> - It would be very nice to have CORS enabled across the Wiki[mp]edia >> subdomains (I see it has been mentioned by Brion in the `JavaScript >> access to uploaded file contents' thread [3][4] for >> upload.wikimedia.org) => is it something that can be done / discussed? > This has been discussed in a few contexts now, and we all seem to > agree that this is a good idea and should definitely be enabled. I'd > propose doing this after we deploy 1.17wmf1 and stuff has calmed down > a bit (it's not uncommon for things to break after a major > deployment). Hi Roan. It's great if there's no major opposition to it :) >> I looks like the code for this is already there [5], maybe I should >> open a new bug right now? > Would be nice to track it in BZ, yes. Will do so and give the link there. Thanks! 2011/1/9 Aryeh Gregor : > I don't see any detailed documentation for X-Frame-Options anywhere. > It looks like IE8 made it up with no detailed spec and other browsers > copied the general idea still with no detailed spec. So I don't know, > sorry. No worries :) Thanks again. 2011/1/9 Ilmari Karonen : >> Both of them use a trick with an iframe to allow javascript requests >> across the wikipedia.org subdomains (something that is not possible >> using AJAX). > Use JSONP. The MediaWiki API supports it through the "callback" parameter. Hi Ilmari, great idea! It's not as powerful as the iframe hack was (since it's limited to the api), but I think it's enough for me to release a quick fix for iKiwi (not for xmsg, unfortunately, because userinfo is not accessible that way). I didn't know about the callback parameter, so you just saved my business ;-) Thanks a lot! 2011/1/10 Tim Starling : > On 10/01/11 01:23, Jérémie Roquet wrote: >> - Taking the document.domain trick into account ⇒ would setting >> X-Frame-Options to SAMEORIGIN instead of DENY allow frames between >> /sub/domains? > No, SAMEORIGIN does not allow framing from say en.wikipedia.org to > fr.wikipedia.org. It only allows framing within the exact same domain. > http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx Hi Tim, thanks for the link and the explanations! -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] X-Frame-Options DENY / SAMEORIGIN and cross-wiki userscripts
Hi Aryeh, thanks for answering! 2011/1/9 Aryeh Gregor : > 2011/1/8 Jérémie Roquet : >> Both of them use a trick with an iframe to allow javascript requests >> across the wikipedia.org subdomains (something that is not possible >> using AJAX). > > It would be possible if we started using CORS, at least in recent > enough browsers. It would be awesome to have this enabled to allow AJAX requests across all the Wikimedia projects. I mean, not only it would allow to make my tools work again without the iframe hack, but I have many other ideas of really cool new tools that could be built upon CORS (including interactions between Wikipedia and Wikimedia Commons, which I could not achieve with the iframe trick). Sure, it wouldn't work in as many browsers as the iframe trick did, but I really prefer something that requires a modern browser to work to something that requires an old one ;-) >> - Does anybody know if having X-Frame-Options set to SAMEORIGIN would >> allow such tricks while still preventing clickjacking attacks from >> other domains (the actual question is: `would it work'?) > > en.wikipedia.org is not the same origin as fr.wikipedia.org. True, but it appears that setting document.domain to the same value for both subdomains (ie. 'wikipedia.org') is enough to have the same origin. [1] That's what I was already doing for iKiwi and xmsg to work, because without this, most browsers already enforce the same origin policy for DOM manipulations inside (i)frames. With it, it works fine, even with the NoScript addon. >> Any other idea on how to make such tools work again would of course be >> highly appreciated. > > I'm not very knowledgeable in this sort of thing, I'm afraid. HTML5's > postMessage() might be useful. Thanks for the tip, I never heard about this before. However, reading the description at MDN [2], I'm afraid it doesn't address the current issue at all because it requires two windows to communicate together (which is exactly what X-Frame-Options forbids). That would have allowed to make cross-domain requests (eg. between Wikipedia and Wikimedia Commons), but with X-Frame-Options I'm afraid it's just as useless as the iframe hack. That said, my questions now are: - It would be very nice to have CORS enabled across the Wiki[mp]edia subdomains (I see it has been mentioned by Brion in the `JavaScript access to uploaded file contents' thread [3][4] for upload.wikimedia.org) ⇒ is it something that can be done / discussed? I looks like the code for this is already there [5], maybe I should open a new bug right now? - Taking the document.domain trick into account ⇒ would setting X-Frame-Options to SAMEORIGIN instead of DENY allow frames between /sub/domains? Thanks again! Best regards, [1] http://en.wikipedia.org/wiki/Same_origin_policy#Additional_document.domain_logic [2] https://developer.mozilla.org/en/dom/window.postmessage [3] http://lists.wikimedia.org/pipermail/wikitech-l/2011-January/050972.html [4] https://bugzilla.wikimedia.org/show_bug.cgi?id=25886 [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=19907 -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] X-Frame-Options DENY / SAMEORIGIN and cross-wiki userscripts
Hello everyone, happy new year. Following #26561 [1] and the MediaWiki security release 1.16.1 [2], some cross-wiki userscripts of mine do not work anymore. Namely, these scripts are: - iKiwi [3] which is used to retrieve all interwikis of a local article from another wiki and is extensively used by the French interwikification project [4]; - xmsg [5] which is used to check new messages on other wikis when login on (and I'm probably the only person to use). Both of them use a trick with an iframe to allow javascript requests across the wikipedia.org subdomains (something that is not possible using AJAX). So, my question are: - Does anybody know if having X-Frame-Options set to SAMEORIGIN would allow such tricks while still preventing clickjacking attacks from other domains (the actual question is: `would it work'?) - If so, is there any reason to use DENY instead of SAMEORIGIN, ie. is there any pragmatic reason to forbid frames from the very same domain (wikipedia.org)? Any other idea on how to make such tools work again would of course be highly appreciated. Thanks in advance, [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=26561 [2] http://lists.wikimedia.org/pipermail/mediawiki-announce/2011-January/93.html [3] http://en.wikipedia.org/wiki/User:Arkanosis/iKiwi.js [4] http://fr.wikipedia.org/wiki/Projet:Interwikification [5] http://fr.wikipedia.org/wiki/User:Arkanosis/xmsg.js -- Jérémie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
