Wikitech-l March 2015

wikitech-l@lists.wikimedia.org

116 participants
94 discussions

Tor proxy with blinded tokens
by Chris Steipp 17 Mar '15

17 Mar '15

Jacob Applebaum made another remark about editing Wikipedia via tor this morning. Since it's been a couple months since the last tor bashing thread, I wanted to throw out a slightly more modest proposal to see what people think. This is getting some interest from a few people: https://zyan.scripts.mit.edu/blog/rate-limiting-anonymous-accounts/ Which lays out a way for twitter to use an external, trusted identity provider to verify identifies / throttle requested, and then create an account in a way that neither twitter or the identity provider can link the account to the request (as long as you mitigate timing attacks). What if we turn this around a bit and let the wiki establish identity and throttle, and open up an editing proxy that is accessible via tor which consumes the identities? Basically: * Established wiki user who wants to use tor makes a blinded request (maybe public, maybe a private queue for some group with appropriate rights) for a tor-based account creation token. * User gets that blinded token signed if they're in good standing, and are limited to some number (3 total, not less than 6 months since the last request, or something like that). * User creates an account on the editing proxy via tor, and gives their unblinded token to the proxy. The proxy creates an account for them, and allows edits via OAuth token using that new account. If the use turns it to be a spammer: * The anonymous account can be blocked like a normal account. The user is throttled on how many requests for accounts they can make. * If the proxy generates to much spam, a steward can revoke the key, and we all go home to think up the next experiment. To make this happen, we need: * a light editing proxy (I already have a couple of those as demo OAuth apps) which is run by a *non-wmf* entity * something for normal users to download and run that does the blinding for them * work out how to address timing attacks if the volume of requestors is low enough that we can correlate request to first edit by the proxy. Anyone interested in helping? Is this conservative enough for those worried about the flood of tor spam, while being simple enough that the average editor would be able to understand and go through the process?

14 29

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
by Florian Schmidt 17 Mar '15

17 Mar '15

I fully upport and welcome this, but at least for Project:Support_desk you should communicate this on this LQT board, too, that it will be converted (if you didn't do hat already, i haven't looked now, because LQT ist terrible on mobile :P). There are probably very active supporters, who haven't subscribed this list, but they should have the possibility to post their needs and opinions about that. Best, Florian Gesendet mit meinem HTC ----- Reply message ----- Von: "Nick Wilson (Quiddity)" <nwilson(a)wikimedia.org> An: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org> Betreff: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org Datum: Di., März 17, 2015 01:51 LiquidThreads (LQT) has not been well-supported in a long time. Flow is in active development, and more real-world use-cases will help focus attention on the higher-priority features that are needed. To that end, LQT pages at mediawiki.org will start being converted to Flow in the next couple of weeks. There are about 1,600 existing LQT pages on Mediawiki, and the three most active pages are VisualEditor/Feedback, Project:Support_desk, and Help_talk:CirrusSearch.[1] The Collaboration team has been running test conversions of those three pages, and fixing issues that have come up. Those fixes are almost complete, and the team will be ready to start converting LQT threads to Flow topics soon. (If you’re interested in the progress, check out phab:T90788[2] and linked tasks.) The latest set is visible at a labs test server.[3] See an example topic comparison here: Flow vs LQT.[4]) The VisualEditor/Feedback page will be converted first (per James' request), around the middle of next week. We’ll pause to assess any high-priority changes required. After that, we will start converting more pages. This process may take a couple of weeks to fully run. The last page to be converted will be Project:Support_desk, as that is the largest and most active LQT Board. LQT Threads that are currently on your watchlist, will still be watchlisted as Flow Topics. New Topics created at Flow Boards on your watchlist will appear in your Echo notifications, and you can choose whether or not to watchlist them. The LQT namespaces will continue to exist. Links to posts/topics will redirect appropriately, and the LQT history will remain available at the original location, as well as being mirrored in the Flow history. There’s a queue of new features in Flow that will be shipped over the next month or so: * Table of Contents is done * Category support for Flow Header and Topics is done * VE with editing toolbar coming last week of March (phab:T90763) [5] * Editing other people’s comments coming last week of March (phab:T91086) * Ability to change the width & side rail in progress, probably out in April (phab:T88114]) * Search is in progress (no ETA yet) (phab:T76823) * The ability to choose which Flow notifications end up in Echo, watchlist, or both, and other more powerful options, will be coming up next (no ETA yet) That being said -- there are some LiquidThreads features that don’t exist in Flow yet. We’d like to hear which features you use on the current LQT boards, and that you’re concerned about losing in the Flow conversion. At the same time, we’d like further suggestions on how we could improve upon that (or other) features from LQT. Please give us feedback at https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it centralized, and test freely at the sandbox.[6] Much thanks, on behalf of the Collaboration Team, Quiddity (WMF) [1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and https://www.mediawiki.org/wiki/Project:Support_desk [2] https://phabricator.wikimedia.org/T90788 [3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback [4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_t… [5] https://phabricator.wikimedia.org/T90763 , https://phabricator.wikimedia.org/T91086 , https://phabricator.wikimedia.org/T88114 , https://phabricator.wikimedia.org/T76823 [6] https://www.mediawiki.org/wiki/Talk:Sandbox -- Nick Wilson (Quiddity) Community Liaison Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

2 1

Proposal for Outreachy program 2015
by Divya 17 Mar '15

17 Mar '15

Hi All, I am Dibya Singh and I am applying for FOSS Outreachy 10. I have selected a project from #possible-tech-projects list named One stop translation to improve consistency for translation. I have been in contact with mentor Niklas Laxström and Federico Leva alias for understanding the project in depth. I have drafted a rough proposal based on my interaction with the product as a user. Please find link for my proposal. Please give your valuable feedback. https://phabricator.wikimedia.org/T92929 Link for my mediawiki user page can be found here <https://www.mediawiki.org/wiki/User:Phoenix303> Regards, Dibya Singh

1 0

MediaWiki tests will verify the completeness of $wgAvailableRights
by hoo 17 Mar '15

17 Mar '15

Hi Everyone, just wanted to quickly let you know that MediaWiki will verify that extensions register all rights they define in $wgAvailableRights (or using the "UserGetAllRights" hook). To make sure your extension complies with that just add all the rights your extension defines to $wgAvailableRights (which is a simple string[] of theses user rights). This test will be introduced with https://gerrit.wikimedia.org/r/192087 Cheers, Marius

1 1

Changing contentmodel of pages
by Erik Bernhardson 16 Mar '15

16 Mar '15

When ContentHandler support was added to MediaWiki in 2012, the content type and content model of a revision is stored with it. However, the DB tables for WMF wikis did not have the new columns, so $wgContentHandlerUseDB was set to false on our wikis. Eventually the database jobs to add and populate the columns completed, and $wgContentHandlerUseDB has been true on some wikis including mediawiki.org for months. There are several projects that are requesting this be set true everywhere, T51193. However, changing the content model of an existing page is a disruptive change. We added the right `editcontentmodel` without which attempts to change content model through the API or EditPage.php fail. Currently no group (user or bot) has this right. So we think it's OK and safe to enable $wgContentHandlerUseDB on WMF wikis. https://gerrit.wikimedia.org/r/#/c/170129/ is the patch. There are issues with granting the editcontentmodel right, see T85847. The Flow discussion and collaboration software has its own contentmodel. Currently the Flow team changes a talk page to a Flow board by editing a PHP config variable (!), which doesn't scale. (FYI, plans for enabling Flow are at [1], and it is happening slowly.) When we do we archive the existing talk page content. The first change to the status quo is allowing a *new* page to be a Flow board. In particular, the Co-op project[2] wants to provide a Flow board for each new editor who signs up to collaborate with a mentor. This doesn't feel like changing the content model of a page, since there was nothing present before. So Flow has its own right, 'flow-create-board', which we grant to flow-bot group; attempting to add a Flow topic or Flow board header to an non-existent page fails unless the user has this right. The Co-op team will ask the Bot Approval Group on enwiki to grant their bot this right. Eventually we envision having a Special:Flowify page that will let admins turn a page into a Flow board. This will run PHP code to archive the current page, handle redirects, and then create a Flow board revision, etc. This feels like the 'editcontentmodel' right, but it will probably be a more restrictive right, 'flow-flowify'. Daniel Kinzler proposed that we should not grant the editcontentmodel right because any change to content model is a special case that requires smart handling via dedicated PHP code. Which is what Flow is doing for both the Co-op bot and the future Special:Flowify. So is there anything to discuss? :) [1] https://www.mediawiki.org/wiki/Flow/Rollout Relax, is happening slowly. [2] https://en.wikipedia.org/wiki/Wikipedia:Co-op

7 7

Wikimedia REST content API is now available in beta
by Gabriel Wicke 15 Mar '15

15 Mar '15

Hello all, I am happy to announce the beta release of the Wikimedia REST Content API at https://rest.wikimedia.org/ Each domain has its own API documentation, which is auto-generated from Swagger API specs. For example, here is the link for the English Wikipedia: https://rest.wikimedia.org/en.wikipedia.org/v1/?doc At present, this API provides convenient and low-latency access to article HTML, page metadata and content conversions between HTML and wikitext. After extensive testing we are confident that these endpoints are ready for production use, but have marked them as 'unstable' until we have also validated this with production users. You can start writing applications that depend on it now, if you aren't afraid of possible minor changes before transitioning to 'stable' status. For the definition of the terms ‘stable’ and ‘unstable’ see https://www.mediawiki.org/wiki/API_versioning . While general and not specific to VisualEditor, the selection of endpoints reflects this release's focus on speeding up VisualEditor. By storing private Parsoid round-trip information separately, we were able to reduce the HTML size by about 40%. This in turn reduces network transfer and processing times, which will make loading and saving with VisualEditor faster. We are also switching from a cache to actual storage, which will eliminate slow VisualEditor loads caused by cache misses. Other users of Parsoid HTML like Flow, HTML dumps, the OCG PDF renderer or Content translation will benefit similarly. But, we are not done yet. In the medium term, we plan to further reduce the HTML size by separating out all read-write metadata. This should allow us to use Parsoid HTML with its semantic markup <https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec> directly for both views and editing without increasing the HTML size over the current output. Combined with performance work in VisualEditor, this has the potential to make switching to visual editing instantaneous and free of any scrolling. We are also investigating a sub-page-level edit API for micro-contributions and very fast VisualEditor saves. HTML saves don't necessarily have to wait for the page to re-render from wikitext, which means that we can potentially make them faster than wikitext saves. For this to work we'll need to minimize network transfer and processing time on both client and server. More generally, this API is intended to be the beginning of a multi-purpose content API. Its implementation (RESTBase <http://www.mediawiki.org/wiki/RESTBase>) is driven by a declarative Swagger API specification, which helps to make it straightforward to extend the API with new entry points. The same API spec is also used to auto-generate the aforementioned sandbox environment, complete with handy "try it" buttons. So, please give it a try and let us know what you think! This API is currently unmetered; we recommend that users not perform more than 200 requests per second and may implement limitations if necessary. I also want to use this opportunity to thank all contributors who made this possible: - Marko Obrovac, Eric Evans, James Douglas and Hardik Juneja on the Services team worked hard to build RESTBase, and to make it as extensible and clean as it is now. - Filippo Giunchedi, Alex Kosiaris, Andrew Otto, Faidon Liambotis, Rob Halsell and Mark Bergsma helped to procure and set up the Cassandra storage cluster backing this API. - The Parsoid team with Subbu Sastry, Arlo Breault, C. Scott Ananian and Marc Ordinas i Llopis is solving the extremely difficult task of converting between wikitext and HTML, and built a new API that lets us retrieve and pass in metadata separately. - On the MediaWiki core team, Brad Jorsch quickly created a minimal authorization API that will let us support private wikis, and Aaron Schulz, Alex Monk and Ori Livneh built and extended the VirtualRestService that lets VisualEditor and MediaWiki in general easily access external services. We welcome your feedback here: https://www.mediawiki.org/wiki/Talk:RESTBase - and in Phabricator <https://phabricator.wikimedia.org/maniphest/task/create/?projects=RESTBase&…:> . Sincerely -- Gabriel Wicke Principal Software Engineer, Wikimedia Foundation

11 11

rel=canonical links changes
by Jiang BIAN 14 Mar '15

14 Mar '15

Hi wikimedia dev, I noticed "rel=canonical links" in ruwiki is using "https" (while enwiki is still using "http"). I'd like to understand if this is just a "bug" or is a starting of some large change across all language sites (then what's the timeline)? Thanks -- Jiang BIAN This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks.

3 2

What does it take to have a project hosted on the Wikimedia git server?
by Strainu 14 Mar '15

14 Mar '15

Hi, The Romanian Wikipedia has a code repository used mainly for robots of interest to the local community. So far, it has been hosted on Google Code. Since that site is closing, we are considering replacements and one of the possibilities was the Wikimedia git server. We would like to know what are the steps to follow in order to have a project created? Thanks, Strainu

10 13

Roadmap and deployment highlights - week of March 16th
by Greg Grossmeier 14 Mar '15

14 Mar '15

Hello and welcome to the latest edition of the WMF Engineering Roadmap and Deployment update. The full log of planned deployments next week can be found at: <https://wikitech.wikimedia.org/wiki/Deployments#Week_of_March_16th> For a longer term view, see the new Roadmap project in Phabricator: <https://phabricator.wikimedia.org/tag/roadmap/> A quick list of notable items for next week... == All Week == * Progressive rollout of RESTBase to all wikis ** <https://phabricator.wikimedia.org/T89066> == Tuesday == * MediaWiki deploy ** group1 to 1.25wmf21: All non-Wikipedia sites (Wiktionary, Wikisource, Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites) ** <https://www.mediawiki.org/wiki/MediaWiki_1.25/wmf21> == Wednesday == * MediaWiki deploy ** group2 to 1.25wmf21 (all Wikipedias) ** group0 to 1.25wmf22 (test/test2/testwikidata/mediawiki) Thanks and as always, questions and comments welcome, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

Re: [Wikitech-l] [Wikimedia-l] SUL finalization update (no, for real this time)
by Pine W 14 Mar '15

14 Mar '15

Excellent, thank you Keegan and all who have worked on this. Pine On Mar 13, 2015 1:07 PM, "Keegan Peterzell" <kpeterzell(a)wikimedia.org> wrote: > Hi all, > > Single-user login[1] finalization will be taking place next month.[2] I > know this has been said before over the past two years, but it is actually > going to take place after nearly a decade of waiting :) > > I just posted an important announcement about the renaming process itself > on Meta.[3] If you're interested, please take some time to read it over and > help translate if possible. A one sentence message about this has been sent > to village pumps as well, where available. > > All accounts that will be affected by this will be contacted on their talk > page within the next couple of days.[4] All local wikis also have a > publicly listed database of users who will be renamed, available at > Special:UsersWhoWillBeRenamed.[4] > > Thanks for your time, please help spread the word to your other mailing > lists and/or communities. > > 1. https://meta.wikimedia.org/wiki/Help:Unified_login > 2. > https://meta.wikimedia.org/wiki/Single_User_Login_finalisation_announcement > 3. > > https://meta.wikimedia.org/wiki/Single_User_Login_finalisation_announcement… > 4. > > https://meta.wikimedia.org/wiki/Single_User_Login_finalisation_announcement… > 5. for example, > https://vo.wikipedia.org/wiki/Patikos:UsersWhoWillBeRenamedHmm > > -- > Keegan Peterzell > Community Liaison, Product > Wikimedia Foundation > _______________________________________________ > Wikimedia-l mailing list, guidelines at: > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 March 2015