Wikitech-l May 2016

wikitech-l@lists.wikimedia.org

113 participants
123 discussions

Recent authentication session instability (was Re: Update from the Wikimedia Performance Team)
by Bryan Davis 19 Jun '16

19 Jun '16

On Thu, Feb 4, 2016 at 8:20 AM, MZMcBride <z(a)mzmcbride.com> wrote: > Federico Leva (Nemo) wrote: >>Login pretty much never does what I expect nowadays, but I'm not sure my >>expectations are correct so I can't identify actual bugs. > > There are various open tasks in Phabricator about user sessions currently, > such as <https://phabricator.wikimedia.org/T124440>. Being unexpectedly > logged out lately has been a bit annoying, though I don't know if it's > related to the Performance team or some other team. The origin of the unexpected logouts falls on the AuthManager project and specifically the SessionManager component that rolled out in 1.27.0-wmf.11 [0]. We had various issues related to the session handling changes including a bug that was overloading the storage capacity of the Redis servers that store session data [1] and two other issues which required rolling the wikis back to 1.27.0-wmf.10 [2][3]. Both rollbacks were accompanied by a run of the "resetGlobalUserTokens.php" maintenance script which updates each user's CentralAuth records in such a way that their authentication session will be considered invalid the next time it is used on a wiki. This was done from an abundance of caution point of view concerning possible issues with sessions that had been issued by the SessionManager software. The reset script is not fast [4], so session invalidation has slowly worked its way across the CentralAuth user table. Part of the enhancements that are being applied in order to bring SessionManager back to production with 1.27.0-wmf.13 is a new config setting that can be used to give us a nearly instant switch to throw to invalidate all active sessions. This setting is actually included in 1.27.0-wmf.12, but the configuration on the Wikimedia cluster has not been changed to make use of it yet. Invalidating all user sessions is not something we plan to do for fun certainly, but there have been in the past (and likely will be in the future) software and configuration issues that necessitate the use of that heavy hammer approach. [0]: https://phabricator.wikimedia.org/T123451 [1]: https://phabricator.wikimedia.org/T125267 [2]: https://wikitech.wikimedia.org/wiki/Incident_documentation/20160123-Session… [3]: https://tools.wmflabs.org/sal/log/AVKZtfQXW8txF7J0uNE2 [4]: https://phabricator.wikimedia.org/T124861 Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

7 13

New mirror of 'other' datasets
by Ariel Glenn WMF 17 Jun '16

17 Jun '16

I'm happy to announce a new mirror for datasets other than the XML dumps. This mirror comes to us courtesy of the Center for Research Computing, University of Notre Dame, and covers everything "other" [1] which includes such goodies as Wikidata entity dumps, pageview counts, titles of all files on each wiki (daily), titles of all articles of each wiki (daily), and the so-called "adds-changes" dumps, among other things. You can access it at http://wikimedia.crc.nd.edu/other/ so please do! Ariel [1] https://dumps.wikimedia.org/other/

2 2

Should we switch the default category collation to uca-default?
by Ryan Kaldari 03 Jun '16

03 Jun '16

There are currently 94 WMF wikis using UCA category collation rather than the default "uppercase" collation. The Unicode Collation Algorithm (UCA) is the official standard for how to sort Unicode characters, and generally follows how a human would typically alphabetize strings. For example, uppercase collation sorts Aztec, Ärsenik, Zoo, Aardvark as "Aardvark, Aztec, Zoo, Ärsenik", but uca-default collation sorts them as "Aardvark, Ärsenik, Aztec, Zoo". UCA collation also (optionally) supports natural numeric sorting so that 100, 1, 99 sorts as "1, 99, 100" rather than "1, 100, 99". The WMF Community Tech team has recently posted proposals on English Wikipedia and several Wiktionaries asking if these communities would support switching to UCA collation. The proposal on English Wikipedia has received unanimous support so far.[1] We thought that Wiktionaries would be more skeptical of the change, but so far we have received only positive responses.[2] Since it seems that most wikis are receptive to switching to UCA, maybe we should just make it the default rather than waiting on all the wikis to request it separately. Of the large Wikipedias, French, Dutch, Polish, Portuguese, and Russian are already using UCA, and German is in the process of switching.[3] For non-Latin scripts, my understanding is that UCA will be a big improvement, especially if we switch them to language-specific implementations, like uca-ja, uca-zh, uca-ar, etc. Three questions: 1. Does switching the default collation from "uppercase" to "uca-default" sound like a good idea? 2. Should this be proposed on meta or is it too technical? 3. Are there any wikis that would need to opt out of this for some reason? (I know there are issues with Kurdish,[4] but that's the only one I know about.) 1. https://en.wikipedia.org/wiki/Wikipedia_talk:Categorization#OK_to_switch_En… 2. https://phabricator.wikimedia.org/T128502 3. https://phabricator.wikimedia.org/T128806 4. https://phabricator.wikimedia.org/T48235

8 9

Campaigns extension / ServerSideAccountCreation log - does anyone still use it?
by Brad Jorsch (Anomie) 03 Jun '16

03 Jun '16

Question 1: Would anyone care if we kill the "loginCTA" campaign, which tracks when people use the link at the bottom of Special:UserLogin to get to the account creation page? Question 2: Would anyone care if we remove the extension entirely from Wikimedia wikis? Wikiapiary seems to show only one user outside of Wikimedia. Background: The extension needs a rewrite for AuthManager, and in particular the "loginCTA" campaign will be a bit of a pain to keep working. If someone is making use of the extension that's fine, but if not we may as well not continue to spend development resources on it. -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation

4 7

Community Wishlist Survey: Status report #2
by Johan Jönsson 01 Jun '16

01 Jun '16

Hi everyone, The important part of this email is this link: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Status_repor… This is the second Community Wishlist Survey status report. In November and December, active contributors to Wikimedia projects proposed, discussed and voted on the features and fixes that they most want to see. The Wikimedia Foundation Community Tech team has been tasked with working on these. Additionally, Wikimedia Deutschland's Technical Wishes team has been working on wishes from the German-speaking community. There's overlap between the two wishlists, and the teams are collaborating on various wishes, so this report includes progress made by both teams as well as great work being done by volunteer developers and other WMF staff. So far, we (in the broad sense) have added support for: *) Migrating dead external links to archives (but there's more work to be done!) *) Pageview stats *) Global notifications *) A category watchlist We're currently working on: *) Improving the plagiarism detection bot *) Improving the diff compare screen *) Numerical sorting in categories *) The possibility to add an expiry date to watchlist items *) A revision slider to help editors navigate through diff pages For more information on these projects as well as upcoming tasks, see the full status report on Meta: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Status_repor… We're looking forward to talking and working with you as we go along. Thanks, //Johan Jönsson User:Johan (WMF) --

3 2

2016-05-25 Scrum of Scrums meeting notes
by Grace Gellerman 01 Jun '16

01 Jun '16

https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-05-25 = 2016-05-25 = == Technology == === Analytics === - Trying to puppetize druid, harder than it looks - Working on scaling on pageview API and cassandra, doing perf testing on new nodes - Trying to add throttling to pageview API - Working on harvesting edit data from db/dumps into hadoop, WIP , main goal this quarter - Deployed visualization of Unique Devices: https://vital-signs.wmflabs.org/#projects=ptwiki/metrics=UniqueDevices - === Services === * RESTBase ** rate limiting in prod, log-only *** Analytics, we need to discuss pageview limits * Cassandra ** expanding from 2 to 3 instances per node in prod ** upgrade to 2.2.6 next * Change prop ** handling updates for summary and mobile-sections* endpoints ** will move purging to it soon * Math ** MathML by default on all wikibooks, early next week all projects * heads up: Services team on Wikimania, then off-site at the end of June === Release Engineering === * '''Blocking''': ??? * '''Blocked''': none * '''Updates''': ** wmf.3 is rolling forward this week ** rc.0 of 1.27 should be out this week === Technical Operations === * '''Blocking''': ** none * '''Blocked''': ** none * Updates: ** misc varnish cluster on route for being upgrade to varnish 4 again ** getting rid of tech debt on the database front (m1 cluster to be reimaged) ** helping releng with scap3 ** Getting finally a redundant link esams-eqiad ** libicu upgrade. See email from Giuseppe on wikitech-l === Security === * Two-factor authentication has been deployed to CentralAuth wikis with permission enabled for staff * Abbey and Daisy are assisting in usability surveying of two-factor * Darian and Chris are working on knowledge transfer prior to Chris' last day on Friday, May 27th * Darian is working on onboarding documentation in anticipation of Security Team hires in the near-ish future * Security review schedule remains on track ( https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Schedule ) and Brian Wolff will be assisting == Product == === Reading === ==== Web ==== * Getting ready for Hovercards A/B test (finialising bug fixes) ** Fundraising tech eng can have a look at JS variable for Popups enabled/disabled ==== Android ==== * released Beta with Reading Lists ==== iOS ==== ==== Mobile Content Service ==== * Working on feed endpoints ==== Reading Infrastructure === * AuthManager: please read email from Brad on wikitech-l * https://gerrit.wikimedia.org/r/#/c/290269 (testing gem) pending review as of 24-May-2016 === Community Tech === * No blockers * Numerical sorting in categories ** New indexes are in place thanks to JCrespo ( https://phabricator.wikimedia.org/T130692 ) ** Will be proposing on Wikitech-l that we switch to "uca-default" as the default page collation, rather than "uppercase" ( https://phabricator.wikimedia.org/T136113 ) * Launched MassViews interface for pageview stats ( http://tools.wmflabs.org/massviews/ ) * Working on new CopyPatrol tool for detecting plagiarism ( http://tools.wmflabs.org/plagiabot ) === Editing === ==== Parsing ==== (Subbu won't be there, updates only) * Work ongoing to migrate Parsoid to use service-runner after a bunch of fixes were pushed to service-runner - hoping to push this past the finish line by next week before attempting a migration of Parsoid cluster to jessie / node v4 (Follow along on https://phabricator.wikimedia.org/T135176 and blocking tasks). Conversation ongoing with services team to resolve details. * Tidy replacement work proceeding well. After last round of fixes and visual diff testing, ~88% of test pages render with pixel-perfect accuracy and ~97% pages with < 1% pixel diffs with HTML5depurate. Additional CSS fixes since then and new round of visual diff testing in progress. Tim working to make some fixes to doBlockLevels in core parser to iron out some kinks there which leads to different behavior in HTML5depurate compared to Tidy (similar effects in Parsoid). * Kunal's linker rewrite patch merged. Follow up work in progress to use the new linker code. * VE / CX: Please start thinking about how your code needs to change to use split data-mw format. The data-mw split code is probably 2-3 weeks away in terms of being ready for deployment, but you can start testing it with Parsoid master which can provide you the split data-mw (ping arlolra on IRC for details). ==== Language ==== * Blocked: ** Preference section "Internationalisation" balloons after clicking "More language settings" https://phabricator.wikimedia.org/T133114(Frontend/Style libs) ** Can't load In Progress or Published translation list https://phabricator.wikimedia.org/T135743 (For: Collobration/Roan) * Updates: ** Compact Language Links (as a non-beta feature) deployed in Beta/testwikis; work on it continue along with ULS === Fundraising tech === * (force) merged security patches to fr branch, deployed ** got tests passing again Monday * CentralNotice: api for a/b testing * More work to get off ActiveMQ, remove SPOF (just bit us again last week) * Prepping for fundraising in Israel, Japan and Ukraine ** Trying to mess with language fallbacks on payments cluster so we never show Russian messages to those whose preferred language is Ukrainian * Enhancing fraud & dos mitigation measures === Discovery === * '''Blocking''': none * '''Blocked''': none * Team offsite last week, got plans for next Q and year * Upgrade to ElasticSearch 2.3 is coming on Thursday ( https://phabricator.wikimedia.org/T133124) * Portal team added descriptive texts to project links on portal after A/B test showed (small) positive impact * Survey results for portal visitors: https://commons.wikimedia.org/wiki/File:Wikipedia_Portal_Survey_-_May_2016.… * Maps in Wikivoyage now support external layers: https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Maps_with_extra… == Wikidata == * Blockers: none. * Deleting files on Commons that are used in Wikidata statements was not possible due to a bug. https://phabricator.wikimedia.org/T135485 * First prototype for structured data on Commons is close, finally. https://phabricator.wikimedia.org/T125822 * QUnit tests timed out on Jenkins more often this week. Anybody knows why? https://phabricator.wikimedia.org/T136303

2 2

RFC: Add Content-Security-Policy header to MediaWiki
by Brian Wolff 01 Jun '16

01 Jun '16

So the RFC process page says I should email wikitech-l to propose an RFC, thus: Content-Security-Policy (CSP) header is a header that disables certain javascript features that are commonly used to exploit XSS attacks, in order to mitigate the risks of XSS. I think we could massively benefit from using this technology - XSS attacks probably being the most common security issue in MediaWiki. The downside is that it would break compatibility with older user scripts. Please see the full text of my proposal at https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy The associated phabricator ticket is: https://phabricator.wikimedia.org/T135963 I'd appreciate any comments anyone might have. Thanks, Brian

4 5

The Revision Scoring weekly update
by Aaron Halfaker 01 Jun '16

01 Jun '16

Hi folks, This is the 6th weekly update for the revision scoring team that we have sent to this mailing list. *New developments:* - We set up a system for expiring labeling tasks after they have not been completed [3] - We set up the ORES service in the Beta cluster [8] *Maintenance and robustness:* - We brought ores-beta (in the beta cluster) back online [1] - We solved a problem with ORES being able to score multiple revisions in batch [2] - We addressed some database connection issues in Wiki labels [4] - We brought Wikilabels back online after some deployment issues [5] and wrote up a post-mortem [6] - We addressed some puppet issues with ORES' staging environment [7] 1. https://phabricator.wikimedia.org/T135677 2. https://phabricator.wikimedia.org/T136278 3. https://phabricator.wikimedia.org/T135400 4. https://phabricator.wikimedia.org/T136502 5. https://phabricator.wikimedia.org/T136520 6. https://phabricator.wikimedia.org/T136523 7. https://phabricator.wikimedia.org/T136488 8. https://phabricator.wikimedia.org/T130404 Stay tuned! -Aaron

1 0

Tech Talk: Integrating user behavior to design better products: May 31
by Rachel Farrand 31 May '16

31 May '16

Please join for the following tech talk: *Tech Talk**:* Integrating user behavior to design better products *Presenter:* Pau Giner *Date:* May 31, 2016 *Time: *19:00 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?msg=Tech+Talk%3A+Integ…> *Length:* 30 minutes Link to live YouTube stream <http://www.youtube.com/watch?v=mLeTABdcdR4> *IRC channel for questions/discussion:* #wikimedia-office *Summary: *The design process helps us to find solutions that respond to the user needs. However, this process needs to rely on actual user behavior to make sure we are addressing the right problems with the best possible solutions. Wikimedia projects are developed in the open and they reach millions of users in very different contexts. This makes it challenging to integrate the different observed behaviors, measured actions, opinions and other forms of feedback. After applying the design process on different Wikimedia projects, I want to share some good practices and lessons learnt when integrating user behavior to inform product decisions, and how you (in whichever role you are playing) can help designers to better support this process. *Feel free to forward this email to any other relevant wikimedia lists.*

1 1

File handler options & InstantCommons (was Re: Update from the Perf Team)
by Brion Vibber 31 May '16

31 May '16

On Sun, May 29, 2016 at 11:22 AM, Gergo Tisza <gtisza(a)wikimedia.org> wrote: > On Sun, May 29, 2016 at 7:08 PM, Brion Vibber <bvibber(a)wikimedia.org> > wrote: > > We could change all that if there was a stable enough URL/linking > > API... Can probably fake it for common cases and supported handlers by > > generating a URL like we would for a local 404-handler repo; my main > > concern is for future expansion where we add more fancy types on Commons > > where the local site may not have an extension installed locally. > > > Not sure if trying to use an unhandled file type via InstantCommons makes > sense; the image parameters in the wikitext and the image parameters in the > URL (or imageinfo API or hypothetical linking API) don't necessarily use > the same syntax; what would transform that? (Granted, you get similar > problems when parameter transformation is handled by the local extension > and there is a version mismatch between the local and remote installation.) > Yep, it all comes back to T66214 <https://phabricator.wikimedia.org/T66214> doesn't it. :D > > (Iframe embedding as a fallback for unknown handlers sounds possible, > > could expose > > a frame URL in the imageinfo data.) > > > > In general that would be a nice idea (see T27854 > <https://phabricator.wikimedia.org/T27854>). Specifically for embedding > unknown file types in MediaWiki though, we would probably have to introduce > some standard key-value syntax for image parameters first, instead of the > current mess where it's parsed by an arbitrary set of regexes defined by > the media handlers and generated in a similarly flexible way. And then you > still have the problem of handling unknown media types in VisualEditor > which would need some kind of parameter metadata at least. > Indeed. iframe embedding of video might be a good place to start for unknown types; since we already have an iframe embedding system for video in TimedMediaHandler, it should be easy to adapt it as a provider so that sites can use videos from Commons without installing TimedMediaHandler locally. Key issues for options: * separate the layout parameters from the file rendering parameters (eg things like 'thumb' or 'frame' affect the layout, but the file handler/renderer only cares about the resulting size) * define standardish keys for file options already in use * if extra file options are needed, have a standard option for extended options! * define that extra options will not be localizable or have magical regexes; they should just be key-value pairs with fixed, predictable key names * define a standard way to pass file options to the iframe Existing file options: * 'width' and 'height' are implied through thumb/frame/upright/default size, or explicitly via /\d+px/ or /\d+x\d+px' etc regexes defined in core. * SvgHandler uses 'lang'; regex defined in core. * PdfHandler and PagedTiffHandler use 'page'; regex defined in core. * PagedTiffHandler uses 'lossy' switch to allow overriding the default thumbnail type (JPG vs PNG); regex defined in extension * TimedMediaHandler adds 'start', 'end', and 'thumbtime'; regex defined in extension There might be a couple more floating around out there, but that should cover those already in use in Wikimedia content. For compatibility we'd need to keep the core regexes, and might or might not want to move the 'lossy' and 'start/end/thumbtime' ones to core. I can imagine some extended attributes I'd like for video: * 'loop' * 'mute' * 'autoplay' (only allowed with 'loop' and 'mute', for GIF-like display) for zoomable panoramic images (flat or spherical): * 'zoom' - initial zoom level * 'center' - coordinates of initial centering (what coord system? separate x/y params or just one? should spherical use lat/lon? etc) for viewing a 3d model: * 'zoom' - just like panoramas * 'distance' - viewer distance from origin point; this is different from zoom! * 'center' - origin point/center of view, extended to 3 dimensions (for instance to concentrate on a portion of a larger model) Let's imagine a file type that uses everything! An animated 3d model that's localizable, and has multiple selectable "pages" of which we show one: [[File:Cool file type.mytype|  thumb |alt=A bouncing ball changes colors while a calendar in background counts off seasons in French.  |640x480px  |lang=fr |page=3  |start=25 |thumbtime=27.5 |end=35 |lossy=1  |zoom=1.5 |center-x=0.5 |center-y=0.667 |center-z=0.25 |distance=0.75 |loop=1 |muted=1 |autoplay=1  |Check out this an awesome [[3d model]] that's [[animation|animated]]! ]] There is some ambiguity with accepting any unknown key followed by '='... is [[File:Equation.mytype|E=mc^2]] using "E=mc^2" as a caption or passing a parameter "E" with value "mc^2"? We could add a 'caption=' magic option and use it explicitly: [[File:Equation.mytype|caption=E=mc^2]] Or just adding a stub <nowiki> ought to do it as a workaround, since it should break the regex check for the generic key followed by "=": [[File:Equation.mytype|<nowiki></nowiki>E=mc^2]] For the media dialog in VE there's a few things we can do... For locally-installed extensions, easy peasy! Extension registers the options it needs along with localized labels and whatever necessaries for validation/input. I'll have to take a look at how it works currently... For remote files... probably we'd want to have an API method for the remote site to expose a given file's option keys, localized labels, and some metadata about the fields (just like a local extension might supply, but without the ability to inject some JS or a custom widget). Another possibility is for the remote site to expose a layout option editor "preview" in its own iframe using a postMessage interface to bump data values in/out of the dialog. This might be good for, say, specifying the start/end/thumb times of a video, or the initial zoom/position of a panorama, by scrubbing/dragging/zooming on the actual media instead of manually typing in numbers. (Could use the exact same iframe interface for local handlers to avoid having multiple code paths, or could remove the intermediary frame for that case and have a common JS API for both methods.) Back to implementation of the viewer: basically we'd take the final file options in normalized key form (width & height and any other regex'd or extended keys) and pass them as query string parameters to an iframe. So when we look up info about the file itself, 'imageinfo' can return an 'iframe' key with, say, https://commons.wikimedia.org/wiki/File:Curiosity%27s_Seven_Minutes_of_Terr… we can take that iframe URL from the imageinfo and append our other options, so an invocation like: [[File:Curiosity's_Seven_Minutes_of_Terror.ogv| 640px|start=3:02|end=3:52|thumbtime=3:14]] would yield something like <iframe src="...?embedplayer=yes&width=640&height=360&start=3:02&end=3:52&thumbtime=3:14" width="640" height="360" frameborder="0" allowFullScreen ></iframe> Now this also brings up questions like did you want to play the video inline vs show a thumbnail that brings up the video in a popup, which may be something where we have to work out in general as well... this would allow using a *standard* popup on the wiki side (say, MultimediaViewer?) to load a remote media item. If using an iframe to embed something with "plain" thumbnail behavior where click means "link" or "zoom", we have to work out issues like passing click events from the iframe to the parent (or else do some clickjacking ;) -- brion

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l May 2016