Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[Pine W]

Good point. Perhaps there is a case to be made for a small-scale experiment
of removing the CAPTCHA. I suggest consulting the stewards for their
thoughts. We have at least one steward who is supposedly an expert on
spambots, and his input may be valuable. You might also consult the admins
of whichever community you would like to use for the home wiki of the
experiment.

Pine
On Nov 6, 2014 10:54 PM, "Dan Garry"  wrote:

> On 6 November 2014 22:39, Pine W  wrote:
>
> > I'm interested both in improving our user stats and stamping out
> spambots.
> > Dan, how do we know that those 17 percent were predominantly humans?
> >
>
> We don't know for certain that they're human. That said, why would a
> spambot try to use the Wikipedia app? You're only creating extra hurdles
> for yourself by doing so. I've seen no evidence so far that anyone except
> humans use the Wikipedia app. Well, and Googlebot, but it reports itself to
> us using a special user agent and also only reads articles. :-)
>
> Dan
>
> --
> Dan Garry
> Associate Product Manager, Mobile Apps
> Wikimedia Foundation
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Announcement: Yuvi Panda joins Ops

[Gerard Meijssen]

Hoi,
I am really happy for Yuvi. He will continue to do what he does and will
become even more awesome at it.

At the same time I find it sad that he moves to the USA because he was
invaluable because he was available when the other Labs people were not
around. As such he provided a much needed service exactly because he lives
in India.
Thanks,
 Gerard

On 7 November 2014 06:44, Ashish Dubey  wrote:

> Awesome. Congrats Yuvi!
>
> On Fri, Nov 7, 2014 at 1:14 AM, Derric Atzrott <
> datzr...@alizeepathology.com
> > wrote:
>
> > Agreed! Congrats!
> >
> > > Awesome Yuvi. Congratulations! :D
> > >
> > >> On Nov 6, 2014, at 10:47 PM, Danese Cooper  wrote:
> > >>
> > >> Woot!  Way to go, Yuvi!
> > >>
> > >> D
> > >>
> > >> On Thu, Nov 6, 2014 at 4:55 PM, Mark Bergsma 
> > wrote:
> > >>
> > >>> Hi all,
> > >>>
> > >>> I'm very pleased to announce that as of this week, Yuvi Panda is part
> > of
> > >>> the Wikimedia Technical Operations team, to work on our Wikimedia
> Labs
> > >>> infrastructure. Yuvi originally joined the Wikimedia Foundation
> Mobile
> > team
> > >>> in December 2011, where he has been lead development for the original
> > >>> Wikipedia App and its rewrite, amongst many other projects.
> > >>>
> > >>> Besides his work in Mobile, Yuvi has been volunteering for Ops work
> in
> > >>> Wikimedia Labs for a long time now. One of the notable examples of
> his
> > work
> > >>> is a seamlessly integrated Web proxy system that allows public web
> > requests
> > >>> from the Internet to be proxied to Labs instances on private IPs
> > without
> > >>> requiring public IP addresses for each instance. This very user
> > friendly
> > >>> system, which he built on top of NGINX, LUA, redis, sqlite and the
> > >>> OpenStack API, sees a lot of usage and has dramatically reduced the
> > need
> > >>> for Labs users to request (scarce) public IP address resources via a
> > manual
> > >>> approval process.
> > >>>
> > >>> Another example of his work that has made a big difference is the
> > >>> initiation of the Labs-Vagrant project; bringing the virtues of the
> > >>> Mediawiki:Vagrant project to Wikimedia Labs, and allowing anyone to
> > bring a
> > >>> MediaWiki development environment up in Labs with great ease. More
> > recently
> > >>> Yuvi has been working on our much needed infrastructure in Labs for
> > >>> monitoring metrics (Graphite) and service availability (Shinken). We
> > expect
> > >>> this will give us a lot more insight into the internals and
> > availability of
> > >>> software and services running in Wikimedia Labs and its many
> projects,
> > and
> > >>> we should be able to deploy it in Production as well.
> > >>>
> > >>> Of course all of this work didn't go unnoticed, and about half a year
> > ago
> > >>> we've asked Yuvi if he was interested to move to Ops. With his
> > extensive
> > >>> development experience and his demonstrated ability to join this with
> > solid
> > >>> Ops work to create stable and highly useful solutions, we think he's
> a
> > >>> great fit for this role.
> > >>>
> > >>> Yuvi recently had his VISA application accepted, and is planning to
> > move to
> > >>> San Francisco in March 2015. Until then he will be working with us
> > remotely
> > >>> from India.
> > >>>
> > >>> Please join me in congratulating Yuvi!
> > >>>
> > >>> --
> > >>> Lead Operations Architect
> > >>> Director of Technical Operations
> > >>> Wikimedia Foundation
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> Ashish Dubey
> http://dash1291.github.io
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[Dan Garry]

On 6 November 2014 22:39, Pine W  wrote:

> I'm interested both in improving our user stats and stamping out spambots.
> Dan, how do we know that those 17 percent were predominantly humans?
>

We don't know for certain that they're human. That said, why would a
spambot try to use the Wikipedia app? You're only creating extra hurdles
for yourself by doing so. I've seen no evidence so far that anyone except
humans use the Wikipedia app. Well, and Googlebot, but it reports itself to
us using a special user agent and also only reads articles. :-)

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[Pine W]

I'm interested both in improving our user stats and stamping out spambots.
Dan, how do we know that those 17 percent were predominantly humans?

I've heard that automated captcha cracking is common. Perhaps so, but if
taking away captchas increases the workload of stewards and admins, that
situation presents a need for tradeoffs between making registration be easy
for humans and making registration be difficult for bots.

Pine
On Nov 6, 2014 9:34 PM, "Dan Garry"  wrote:

> On 6 November 2014 21:06, Tim Starling  wrote:
>
> > I think it would be best if we just removed the captcha, rather than
> > deploying a new engine.
>
>
> I'd absolutely love that.
>
> On the mobile app, almost everyone who tries to create an account is shown
> a captcha. Of those people, 31% of them get the captcha wrong on their
> first try, and 17% of those people give up trying to create an account. The
> success rate for account creation is less than 50%, in no small part due to
> the captcha.
>
> I'd love to eliminate giving our users that headache.
>
> Dan
>
> --
> Dan Garry
> Associate Product Manager, Mobile Apps
> Wikimedia Foundation
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Announcement: Yuvi Panda joins Ops

[Ashish Dubey]

Awesome. Congrats Yuvi!

On Fri, Nov 7, 2014 at 1:14 AM, Derric Atzrott  wrote:

> Agreed! Congrats!
>
> > Awesome Yuvi. Congratulations! :D
> >
> >> On Nov 6, 2014, at 10:47 PM, Danese Cooper  wrote:
> >>
> >> Woot!  Way to go, Yuvi!
> >>
> >> D
> >>
> >> On Thu, Nov 6, 2014 at 4:55 PM, Mark Bergsma 
> wrote:
> >>
> >>> Hi all,
> >>>
> >>> I'm very pleased to announce that as of this week, Yuvi Panda is part
> of
> >>> the Wikimedia Technical Operations team, to work on our Wikimedia Labs
> >>> infrastructure. Yuvi originally joined the Wikimedia Foundation Mobile
> team
> >>> in December 2011, where he has been lead development for the original
> >>> Wikipedia App and its rewrite, amongst many other projects.
> >>>
> >>> Besides his work in Mobile, Yuvi has been volunteering for Ops work in
> >>> Wikimedia Labs for a long time now. One of the notable examples of his
> work
> >>> is a seamlessly integrated Web proxy system that allows public web
> requests
> >>> from the Internet to be proxied to Labs instances on private IPs
> without
> >>> requiring public IP addresses for each instance. This very user
> friendly
> >>> system, which he built on top of NGINX, LUA, redis, sqlite and the
> >>> OpenStack API, sees a lot of usage and has dramatically reduced the
> need
> >>> for Labs users to request (scarce) public IP address resources via a
> manual
> >>> approval process.
> >>>
> >>> Another example of his work that has made a big difference is the
> >>> initiation of the Labs-Vagrant project; bringing the virtues of the
> >>> Mediawiki:Vagrant project to Wikimedia Labs, and allowing anyone to
> bring a
> >>> MediaWiki development environment up in Labs with great ease. More
> recently
> >>> Yuvi has been working on our much needed infrastructure in Labs for
> >>> monitoring metrics (Graphite) and service availability (Shinken). We
> expect
> >>> this will give us a lot more insight into the internals and
> availability of
> >>> software and services running in Wikimedia Labs and its many projects,
> and
> >>> we should be able to deploy it in Production as well.
> >>>
> >>> Of course all of this work didn't go unnoticed, and about half a year
> ago
> >>> we've asked Yuvi if he was interested to move to Ops. With his
> extensive
> >>> development experience and his demonstrated ability to join this with
> solid
> >>> Ops work to create stable and highly useful solutions, we think he's a
> >>> great fit for this role.
> >>>
> >>> Yuvi recently had his VISA application accepted, and is planning to
> move to
> >>> San Francisco in March 2015. Until then he will be working with us
> remotely
> >>> from India.
> >>>
> >>> Please join me in congratulating Yuvi!
> >>>
> >>> --
> >>> Lead Operations Architect
> >>> Director of Technical Operations
> >>> Wikimedia Foundation
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Ashish Dubey
http://dash1291.github.io
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [x-post] Language Engineering IRC Office Hour on November 12, 2014 (Wednesday) at 1700 UTC

[Runa Bhattacharjee]

[x-posted announcement]

Hello,

The next monthly IRC office hour of the Wikimedia Language Engineering team
will be on Wednesday, November 12, 2014 at 1700 UTC on #wikimedia-office.
We will be taking questions and also discussing about the availability of
the new version of the Content Translation tool[1][2] and upcoming plans.

Please see below for event details and local time

Thank you.
Runa

[1] https://www.mediawiki.org/wiki/Content_translation
[2]
http://blog.wikimedia.org/2014/11/03/announcing-the-second-version-of-the-content-translation-tool/

Monthly IRC Office Hour:
==
# Date: November 12, 2014 (Wednesday)

# Time: 1700 UTC (Check local time:
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20141112T1700)

# IRC channel: #wikimedia-office

# Agenda:
1. Content Translation project updates and plans
2. Q & A (Questions can be sent to me before the event)

-- 
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[Dan Garry]

On 6 November 2014 21:06, Tim Starling  wrote:

> I think it would be best if we just removed the captcha, rather than
> deploying a new engine.


I'd absolutely love that.

On the mobile app, almost everyone who tries to create an account is shown
a captcha. Of those people, 31% of them get the captcha wrong on their
first try, and 17% of those people give up trying to create an account. The
success rate for account creation is less than 50%, in no small part due to
the captcha.

I'd love to eliminate giving our users that headache.

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[Tim Starling]

I think it would be best if we just removed the captcha, rather than
deploying a new engine.

-- Tim Starling

On 07/11/14 13:13, Ryan Kaldari wrote:
> Wasn't a new CAPTCHA engine merged a couple weeks ago? What's the
> status of that? If I remember, the goal of the new engine was to
> make the CAPTCHA more difficult for bots, so it may (or may not)
> make things worse for humans. Have we ever done any research to
> find out how likely humans are to be able to solve our captchas?
> 
> Ryan Kaldari
> 
> On Nov 6, 2014, at 5:52 PM, Jon Harald Søby 
> wrote:
> 
>> Hi all,
>> 
>> My apologies if this is the wrong place to start a discussion on
>> this, but it's a better place than nowhere. I recently took part
>> in two very different Wikipedia workshops -- one in Uganda for
>> schoolchildren aged 14-17, and one Bodø, Norway, for GLAM people
>> aged 35-55. One glaringly obvious barrier of entry that was
>> common for both groups is that the CAPTCHA we use is too freaking
>> hard.
>> 
>> The main concern is obviously that it is really hard to read, but
>> there are also some other issues, namely that all the fields in
>> the user registration form (except for the username) are wiped if
>> you enter the CAPTCHA incorrectly. So when you make a mistake,
>> not only do you have to re-type a whole new CAPTCHA (where you
>> may make another mistake), you also have to re-type the password
>> twice *and* your e-mail address. This takes a long time,
>> especially if you're not a fast typer (which was the case for
>> the first group), or if you are on a tablet or phone (which was
>> the case for some in the second group).
>> 
>> So I would like to start a discussion about changing to a CAPTCHA
>> that is more user-friendly, and hopefully one that isn't as 
>> English/Latin-alphabet-centric as the one we currently use. If
>> Ugandan children and old Norwegian people, which all use the
>> Latin alphabet, have such problems deciphering the CAPTCHA, what
>> about people speaking languages that don't use the Latin
>> alphabet? I would prefer something more simplistic, like some
>> sort of math or image-based CAPTCHA, instead of the current
>> CAPTCHA we use.
>> 
>> -- mvh Jon Harald Søby
>>  
>> ___ Wikitech-l
>> mailing list Wikitech-l@lists.wikimedia.org 
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> 
> ___ Wikitech-l mailing
> list Wikitech-l@lists.wikimedia.org 
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> 



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Our CAPTCHA is very unfriendly

[Ryan Kaldari]

Wasn't a new CAPTCHA engine merged a couple weeks ago? What's the status of 
that? If I remember, the goal of the new engine was to make the CAPTCHA more 
difficult for bots, so it may (or may not) make things worse for humans. Have 
we ever done any research to find out how likely humans are to be able to solve 
our captchas?

Ryan Kaldari

On Nov 6, 2014, at 5:52 PM, Jon Harald Søby  wrote:

> Hi all,
> 
> My apologies if this is the wrong place to start a discussion on this, but
> it's a better place than nowhere. I recently took part in two very
> different Wikipedia workshops -- one in Uganda for schoolchildren aged
> 14-17, and one Bodø, Norway, for GLAM people aged 35-55. One glaringly
> obvious barrier of entry that was common for both groups is that the
> CAPTCHA we use is too freaking hard.
> 
> The main concern is obviously that it is really hard to read, but there are
> also some other issues, namely that all the fields in the user registration
> form (except for the username) are wiped if you enter the CAPTCHA
> incorrectly. So when you make a mistake, not only do you have to re-type a
> whole new CAPTCHA (where you may make another mistake), you also have to
> re-type the password twice *and* your e-mail address. This takes a long
> time, especially if you're not a fast typer (which was the case for the
> first group), or if you are on a tablet or phone (which was the case for
> some in the second group).
> 
> So I would like to start a discussion about changing to a CAPTCHA that is
> more user-friendly, and hopefully one that isn't as
> English/Latin-alphabet-centric as the one we currently use. If Ugandan
> children and old Norwegian people, which all use the Latin alphabet, have
> such problems deciphering the CAPTCHA, what about people speaking languages
> that don't use the Latin alphabet? I would prefer something more
> simplistic, like some sort of math or image-based CAPTCHA, instead of the
> current CAPTCHA we use.
> 
> -- 
> mvh
> Jon Harald Søby 
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Our CAPTCHA is very unfriendly

[Jon Harald Søby]

Hi all,

My apologies if this is the wrong place to start a discussion on this, but
it's a better place than nowhere. I recently took part in two very
different Wikipedia workshops -- one in Uganda for schoolchildren aged
14-17, and one Bodø, Norway, for GLAM people aged 35-55. One glaringly
obvious barrier of entry that was common for both groups is that the
CAPTCHA we use is too freaking hard.

The main concern is obviously that it is really hard to read, but there are
also some other issues, namely that all the fields in the user registration
form (except for the username) are wiped if you enter the CAPTCHA
incorrectly. So when you make a mistake, not only do you have to re-type a
whole new CAPTCHA (where you may make another mistake), you also have to
re-type the password twice *and* your e-mail address. This takes a long
time, especially if you're not a fast typer (which was the case for the
first group), or if you are on a tablet or phone (which was the case for
some in the second group).

So I would like to start a discussion about changing to a CAPTCHA that is
more user-friendly, and hopefully one that isn't as
English/Latin-alphabet-centric as the one we currently use. If Ugandan
children and old Norwegian people, which all use the Latin alphabet, have
such problems deciphering the CAPTCHA, what about people speaking languages
that don't use the Latin alphabet? I would prefer something more
simplistic, like some sort of math or image-based CAPTCHA, instead of the
current CAPTCHA we use.

-- 
mvh
Jon Harald Søby 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki:Common.js and MediaWiki:Common.css blocked on Special:Login and Special:Preferences

[Daniel Friesen]

On 2014-11-06 4:45 PM, Chris Steipp wrote:
> On Thu, Nov 6, 2014 at 11:41 AM, Derric Atzrott
>  wrote:
>> This seems completely reasonable to me. I'd merge is personally.  Is there
>> any reason not to?
> It's fairly easy to inject javascript via css, so merging that patch
> means an admin can run javascript on the login/preferences page, while
> we specifically block javascript from Common.js, etc.
>
> For me, I like knowing that when I login on a random wiki in our
> cluster, a site admin can't have (maliciously or unintentionally) put
> javascript on the login page to sniff my password. I'd prefer Kunal's
> patch had a feature flag so we could disable this on WMF wikis, but
> sites with robust auditing of their common.css can enable it.

I should probably take some time to remind everyone that things hiding
any form of JS from single pages like the login pages makes them secure,
that restrictions like those are not that hard to bypass by using JS on
a non-login page to use AJAX and history.pushState to trick someone
clicking the login link into thinking that they actually navigated the
page and are safe from site-js, when in reality they're actually still
on the same page with malicious site-js running.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki:Common.js and MediaWiki:Common.css blocked on Special:Login and Special:Preferences

[Chris Steipp]

On Thu, Nov 6, 2014 at 11:41 AM, Derric Atzrott
 wrote:
> This seems completely reasonable to me. I'd merge is personally.  Is there
> any reason not to?

It's fairly easy to inject javascript via css, so merging that patch
means an admin can run javascript on the login/preferences page, while
we specifically block javascript from Common.js, etc.

For me, I like knowing that when I login on a random wiki in our
cluster, a site admin can't have (maliciously or unintentionally) put
javascript on the login page to sniff my password. I'd prefer Kunal's
patch had a feature flag so we could disable this on WMF wikis, but
sites with robust auditing of their common.css can enable it.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki:Common.js and MediaWiki:Common.css blocked on Special:Login and Special:Preferences

[Mark A. Hershberger]

"Derric Atzrott"  writes:

>>> TL;DR: Should we merge https://gerrit.wikimedia.org/r/#/c/165979/ and
>>> release it with MediaWiki 1.24?

> This seems completely reasonable to me. I'd merge is personally.  Is there
> any reason not to?

The discussion on the bug and the fact that this was in a security
release.

I'll merge it tomorrow for RC.1 unless someone objects or a problem
arises.

Mark.

-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Announcement: Yuvi Panda joins Ops

[Derric Atzrott]

Agreed! Congrats!

> Awesome Yuvi. Congratulations! :D 
>
>> On Nov 6, 2014, at 10:47 PM, Danese Cooper  wrote:
>> 
>> Woot!  Way to go, Yuvi!
>> 
>> D
>> 
>> On Thu, Nov 6, 2014 at 4:55 PM, Mark Bergsma  wrote:
>> 
>>> Hi all,
>>> 
>>> I'm very pleased to announce that as of this week, Yuvi Panda is part of
>>> the Wikimedia Technical Operations team, to work on our Wikimedia Labs
>>> infrastructure. Yuvi originally joined the Wikimedia Foundation Mobile team
>>> in December 2011, where he has been lead development for the original
>>> Wikipedia App and its rewrite, amongst many other projects.
>>> 
>>> Besides his work in Mobile, Yuvi has been volunteering for Ops work in
>>> Wikimedia Labs for a long time now. One of the notable examples of his work
>>> is a seamlessly integrated Web proxy system that allows public web requests
>>> from the Internet to be proxied to Labs instances on private IPs without
>>> requiring public IP addresses for each instance. This very user friendly
>>> system, which he built on top of NGINX, LUA, redis, sqlite and the
>>> OpenStack API, sees a lot of usage and has dramatically reduced the need
>>> for Labs users to request (scarce) public IP address resources via a manual
>>> approval process.
>>> 
>>> Another example of his work that has made a big difference is the
>>> initiation of the Labs-Vagrant project; bringing the virtues of the
>>> Mediawiki:Vagrant project to Wikimedia Labs, and allowing anyone to bring a
>>> MediaWiki development environment up in Labs with great ease. More recently
>>> Yuvi has been working on our much needed infrastructure in Labs for
>>> monitoring metrics (Graphite) and service availability (Shinken). We expect
>>> this will give us a lot more insight into the internals and availability of
>>> software and services running in Wikimedia Labs and its many projects, and
>>> we should be able to deploy it in Production as well.
>>> 
>>> Of course all of this work didn't go unnoticed, and about half a year ago
>>> we've asked Yuvi if he was interested to move to Ops. With his extensive
>>> development experience and his demonstrated ability to join this with solid
>>> Ops work to create stable and highly useful solutions, we think he's a
>>> great fit for this role.
>>> 
>>> Yuvi recently had his VISA application accepted, and is planning to move to
>>> San Francisco in March 2015. Until then he will be working with us remotely
>>> from India.
>>> 
>>> Please join me in congratulating Yuvi!
>>> 
>>> --
>>> Lead Operations Architect
>>> Director of Technical Operations
>>> Wikimedia Foundation


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki:Common.js and MediaWiki:Common.css blocked on Special:Login and Special:Preferences

[Derric Atzrott]

>> TL;DR: Should we merge https://gerrit.wikimedia.org/r/#/c/165979/ and
>> release it with MediaWiki 1.24?
>> 
>> A lot of sites have used MediaWiki:Common.js and MediaWiki:Common.css to
>> customize the appearance of their site.
>> 
>> In a recent security release[1], support for JS and CSS with on-wiki
>> origins was removed from being displayed on the Special:Login and
>> Special:Preferences page.
> 
> To be clear, only CSS was removed. JS was already not allowed on
> Special:Login/Preferences.
>
>> Because of how the on-wiki MediaWiki:Common.* pages are used and the
>> access restrictions on them, I think it is reasonable to allow JS and
>> CSS from them while continuing to disallow individual's JS and CSS on
>> the Special:Preferences and Special:Login page.
>> 
>> Alexia filed a bug[2] and Kunal (Legoktm) has provided a patch[3] to allow
>> site-wide styling back on those pages.
>
> Right, the patch only re-adds site-wide CSS, not JS.
>

This seems completely reasonable to me. I'd merge is personally.  Is there
any reason not to?

Thank you,
Derric Atzrott


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Announcement: Yuvi Panda joins Ops

[Niharika Kohli]

Awesome Yuvi. Congratulations! :D 

> On Nov 6, 2014, at 10:47 PM, Danese Cooper  wrote:
> 
> Woot!  Way to go, Yuvi!
> 
> D
> 
> On Thu, Nov 6, 2014 at 4:55 PM, Mark Bergsma  wrote:
> 
>> Hi all,
>> 
>> I'm very pleased to announce that as of this week, Yuvi Panda is part of
>> the Wikimedia Technical Operations team, to work on our Wikimedia Labs
>> infrastructure. Yuvi originally joined the Wikimedia Foundation Mobile team
>> in December 2011, where he has been lead development for the original
>> Wikipedia App and its rewrite, amongst many other projects.
>> 
>> Besides his work in Mobile, Yuvi has been volunteering for Ops work in
>> Wikimedia Labs for a long time now. One of the notable examples of his work
>> is a seamlessly integrated Web proxy system that allows public web requests
>> from the Internet to be proxied to Labs instances on private IPs without
>> requiring public IP addresses for each instance. This very user friendly
>> system, which he built on top of NGINX, LUA, redis, sqlite and the
>> OpenStack API, sees a lot of usage and has dramatically reduced the need
>> for Labs users to request (scarce) public IP address resources via a manual
>> approval process.
>> 
>> Another example of his work that has made a big difference is the
>> initiation of the Labs-Vagrant project; bringing the virtues of the
>> Mediawiki:Vagrant project to Wikimedia Labs, and allowing anyone to bring a
>> MediaWiki development environment up in Labs with great ease. More recently
>> Yuvi has been working on our much needed infrastructure in Labs for
>> monitoring metrics (Graphite) and service availability (Shinken). We expect
>> this will give us a lot more insight into the internals and availability of
>> software and services running in Wikimedia Labs and its many projects, and
>> we should be able to deploy it in Production as well.
>> 
>> Of course all of this work didn't go unnoticed, and about half a year ago
>> we've asked Yuvi if he was interested to move to Ops. With his extensive
>> development experience and his demonstrated ability to join this with solid
>> Ops work to create stable and highly useful solutions, we think he's a
>> great fit for this role.
>> 
>> Yuvi recently had his VISA application accepted, and is planning to move to
>> San Francisco in March 2015. Until then he will be working with us remotely
>> from India.
>> 
>> Please join me in congratulating Yuvi!
>> 
>> --
>> Lead Operations Architect
>> Director of Technical Operations
>> Wikimedia Foundation
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki:Common.js and MediaWiki:Common.css blocked on Special:Login and Special:Preferences

[Legoktm]

On 11/6/14 6:58 AM, Mark A. Hershberger wrote:
> 
> TL;DR: Should we merge https://gerrit.wikimedia.org/r/#/c/165979/ and
> release it with MediaWiki 1.24?
> 
> A lot of sites have used MediaWiki:Common.js and MediaWiki:Common.css to
> customize the appearance of their site.
> 
> In a recent security release[1], support for JS and CSS with on-wiki
> origins was removed from being displayed on the Special:Login and
> Special:Preferences page.

To be clear, only CSS was removed. JS was already not allowed on
Special:Login/Preferences.

> Because of how the on-wiki MediaWiki:Common.* pages are used and the
> access restrictions on them, I think it is reasonable to allow JS and
> CSS from them while continuing to disallow individual's JS and CSS on
> the Special:Preferences and Special:Login page.
> 
> Alexia filed a bug[2] and Kunal (Legoktm) has provided a patch[3] to allow
> site-wide styling back on those pages.

Right, the patch only re-adds site-wide CSS, not JS.

-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Announcement: Yuvi Panda joins Ops

[Danese Cooper]

Woot!  Way to go, Yuvi!

D

On Thu, Nov 6, 2014 at 4:55 PM, Mark Bergsma  wrote:

> Hi all,
>
> I'm very pleased to announce that as of this week, Yuvi Panda is part of
> the Wikimedia Technical Operations team, to work on our Wikimedia Labs
> infrastructure. Yuvi originally joined the Wikimedia Foundation Mobile team
> in December 2011, where he has been lead development for the original
> Wikipedia App and its rewrite, amongst many other projects.
>
> Besides his work in Mobile, Yuvi has been volunteering for Ops work in
> Wikimedia Labs for a long time now. One of the notable examples of his work
> is a seamlessly integrated Web proxy system that allows public web requests
> from the Internet to be proxied to Labs instances on private IPs without
> requiring public IP addresses for each instance. This very user friendly
> system, which he built on top of NGINX, LUA, redis, sqlite and the
> OpenStack API, sees a lot of usage and has dramatically reduced the need
> for Labs users to request (scarce) public IP address resources via a manual
> approval process.
>
> Another example of his work that has made a big difference is the
> initiation of the Labs-Vagrant project; bringing the virtues of the
> Mediawiki:Vagrant project to Wikimedia Labs, and allowing anyone to bring a
> MediaWiki development environment up in Labs with great ease. More recently
> Yuvi has been working on our much needed infrastructure in Labs for
> monitoring metrics (Graphite) and service availability (Shinken). We expect
> this will give us a lot more insight into the internals and availability of
> software and services running in Wikimedia Labs and its many projects, and
> we should be able to deploy it in Production as well.
>
> Of course all of this work didn't go unnoticed, and about half a year ago
> we've asked Yuvi if he was interested to move to Ops. With his extensive
> development experience and his demonstrated ability to join this with solid
> Ops work to create stable and highly useful solutions, we think he's a
> great fit for this role.
>
> Yuvi recently had his VISA application accepted, and is planning to move to
> San Francisco in March 2015. Until then he will be working with us remotely
> from India.
>
> Please join me in congratulating Yuvi!
>
> --
> Lead Operations Architect
> Director of Technical Operations
> Wikimedia Foundation
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki:Common.js and MediaWiki:Common.css blocked on Special:Login and Special:Preferences

[Mark A. Hershberger]

TL;DR: Should we merge https://gerrit.wikimedia.org/r/#/c/165979/ and
release it with MediaWiki 1.24?

A lot of sites have used MediaWiki:Common.js and MediaWiki:Common.css to
customize the appearance of their site.

In a recent security release[1], support for JS and CSS with on-wiki
origins was removed from being displayed on the Special:Login and
Special:Preferences page.

Because of how the on-wiki MediaWiki:Common.* pages are used and the
access restrictions on them, I think it is reasonable to allow JS and
CSS from them while continuing to disallow individual's JS and CSS on
the Special:Preferences and Special:Login page.

Alexia filed a bug[2] and Kunal (Legoktm) has provided a patch[3] to allow
site-wide styling back on those pages.

I'd like to merge this, but I want some input from the community and
security people before I do that.

Thanks,

Mark.

(Reply-to set to mediawiki-l.)


Footnotes: 
[1]  https://bugzilla.wikimedia.org/70672

[2]  https://bugzilla.wikimedia.org/71621

[3]  https://gerrit.wikimedia.org/r/#/c/165979/


-- 
Mark A. Hershberger
NicheWork LLC
717-271-1084

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Announcement: Yuvi Panda joins Ops

[Mark Bergsma]

Hi all,

I'm very pleased to announce that as of this week, Yuvi Panda is part of
the Wikimedia Technical Operations team, to work on our Wikimedia Labs
infrastructure. Yuvi originally joined the Wikimedia Foundation Mobile team
in December 2011, where he has been lead development for the original
Wikipedia App and its rewrite, amongst many other projects.

Besides his work in Mobile, Yuvi has been volunteering for Ops work in
Wikimedia Labs for a long time now. One of the notable examples of his work
is a seamlessly integrated Web proxy system that allows public web requests
from the Internet to be proxied to Labs instances on private IPs without
requiring public IP addresses for each instance. This very user friendly
system, which he built on top of NGINX, LUA, redis, sqlite and the
OpenStack API, sees a lot of usage and has dramatically reduced the need
for Labs users to request (scarce) public IP address resources via a manual
approval process.

Another example of his work that has made a big difference is the
initiation of the Labs-Vagrant project; bringing the virtues of the
Mediawiki:Vagrant project to Wikimedia Labs, and allowing anyone to bring a
MediaWiki development environment up in Labs with great ease. More recently
Yuvi has been working on our much needed infrastructure in Labs for
monitoring metrics (Graphite) and service availability (Shinken). We expect
this will give us a lot more insight into the internals and availability of
software and services running in Wikimedia Labs and its many projects, and
we should be able to deploy it in Production as well.

Of course all of this work didn't go unnoticed, and about half a year ago
we've asked Yuvi if he was interested to move to Ops. With his extensive
development experience and his demonstrated ability to join this with solid
Ops work to create stable and highly useful solutions, we think he's a
great fit for this role.

Yuvi recently had his VISA application accepted, and is planning to move to
San Francisco in March 2015. Until then he will be working with us remotely
from India.

Please join me in congratulating Yuvi!

-- 
Lead Operations Architect
Director of Technical Operations
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How does new revert token system works?

[Petr Bena]

That is of course what I do, full api query is meta=tokens&type=watch|rollback

I do receive a rollback token, but it works only sometimes. It
randomly gets invalid.

On Thu, Nov 6, 2014 at 2:25 PM, florian.schmidt.wel...@t-online.de
 wrote:
> For rollback you need a rollback token (if i'm right), with 
> api.php?action=query&meta=tokens you get a csrf token (like the api page 
> says). What is, if you use api.php?action=query&meta=tokens&type=rollback to 
> retrieve a token?
>
> Freundliche Grüße / Kind regards
> Florian Schmidt
>
> -Original-Nachricht-
> Betreff: [Wikitech-l] How does new revert token system works?
> Datum: Thu, 06 Nov 2014 14:00:26 +0100
> Von: Petr Bena 
> An: Wikimedia developers 
>
> Hey,
>
> I've seen a lot of changes in token system, however how it works is a
> mystery to me. So far I understood it as:
>
> You no longer get revert token per each edit using intoken but get
> some kind of global rollback token using action=query&meta=tokens
>
> Is this how it should work? If yes, there is a bug in mediawiki,
> because token returned by this api is randomly invalid. That means,
> sometimes it can be used and sometimes it return badtoken, which can
> be fixed only by either logging out and back in, or using the
> deprecated intoken parameter which returns working token (but is
> deprecated).
>
> If this is not how it should work, can someone explain to me how it
> works? Thanks
>
> here are some logs (read from bottom to top):
>
> Thu Nov 6 13:57:57 2014  DEBUG[1]: Failed to deliver message to 122.176.67.4
> Thu Nov 6 13:57:57 2014  Did not revert Tourism in Jammu and Kashmir:
> ERROR: Cannot rollback, token
> 0c59203d7b4d176f28540646c82e264a545b7039+\ is not valid for some
> reason (mediawiki bug), please try it once more
> Thu Nov 6 13:57:57 2014  DEBUG[1]: Query failed: badtoken details: See
> https://en.wikipedia.org/w/api.php for API usage
> Thu Nov 6 13:57:57 2014  DEBUG[1]: Rolling back Tourism in Jammu and Kashmir
> Thu Nov 6 13:57:57 2014  WARNING: API query (info): The intoken
> parameter has been deprecated.
> Thu Nov 6 13:57:57 2014  DEBUG[1]: Sending message to user 122.176.67.4
> Thu Nov 6 13:57:29 2014  DEBUG[1]: enwiki mediawiki 1.25wmf6
> Thu Nov 6 13:57:29 2014  DEBUG[2]: Token for enwiki rollback
> 0c59203d7b4d176f28540646c82e264a545b7039+\
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How does new revert token system works?

[florian.schmidt.wel...@t-online.de]

For rollback you need a rollback token (if i'm right), with 
api.php?action=query&meta=tokens you get a csrf token (like the api page says). 
What is, if you use api.php?action=query&meta=tokens&type=rollback to retrieve 
a token?

Freundliche Grüße / Kind regards
Florian Schmidt

-Original-Nachricht-
Betreff: [Wikitech-l] How does new revert token system works?
Datum: Thu, 06 Nov 2014 14:00:26 +0100
Von: Petr Bena 
An: Wikimedia developers 

Hey,

I've seen a lot of changes in token system, however how it works is a
mystery to me. So far I understood it as:

You no longer get revert token per each edit using intoken but get
some kind of global rollback token using action=query&meta=tokens

Is this how it should work? If yes, there is a bug in mediawiki,
because token returned by this api is randomly invalid. That means,
sometimes it can be used and sometimes it return badtoken, which can
be fixed only by either logging out and back in, or using the
deprecated intoken parameter which returns working token (but is
deprecated).

If this is not how it should work, can someone explain to me how it
works? Thanks

here are some logs (read from bottom to top):

Thu Nov 6 13:57:57 2014  DEBUG[1]: Failed to deliver message to 122.176.67.4
Thu Nov 6 13:57:57 2014  Did not revert Tourism in Jammu and Kashmir:
ERROR: Cannot rollback, token
0c59203d7b4d176f28540646c82e264a545b7039+\ is not valid for some
reason (mediawiki bug), please try it once more
Thu Nov 6 13:57:57 2014  DEBUG[1]: Query failed: badtoken details: See
https://en.wikipedia.org/w/api.php for API usage
Thu Nov 6 13:57:57 2014  DEBUG[1]: Rolling back Tourism in Jammu and Kashmir
Thu Nov 6 13:57:57 2014  WARNING: API query (info): The intoken
parameter has been deprecated.
Thu Nov 6 13:57:57 2014  DEBUG[1]: Sending message to user 122.176.67.4
Thu Nov 6 13:57:29 2014  DEBUG[1]: enwiki mediawiki 1.25wmf6
Thu Nov 6 13:57:29 2014  DEBUG[2]: Token for enwiki rollback
0c59203d7b4d176f28540646c82e264a545b7039+\

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] How does new revert token system works?

[Petr Bena]

While retrieving the new token withing same session I get a different
rollback token, which doesn't work as well:

Thu Nov 6 14:03:19 2014  WARNING: API query (revisions): The rvtoken
parameter has been deprecated.
Thu Nov 6 14:03:18 2014  DEBUG[1]: Failed to deliver message to Nickpick12345
Thu Nov 6 14:03:18 2014  Did not revert Flag of the United States:
ERROR: Cannot rollback, token
833a4455b71819f6a4bad42677bb9c73545b7056+\ is not valid for some
reason (mediawiki bug), please try it once more
Thu Nov 6 14:03:18 2014  DEBUG[1]: Query failed: badtoken details: See
https://en.wikipedia.org/w/api.php for API usage
Thu Nov 6 14:03:18 2014  DEBUG[1]: Rolling back Flag of the United States

On Thu, Nov 6, 2014 at 1:59 PM, Petr Bena  wrote:
> Hey,
>
> I've seen a lot of changes in token system, however how it works is a
> mystery to me. So far I understood it as:
>
> You no longer get revert token per each edit using intoken but get
> some kind of global rollback token using action=query&meta=tokens
>
> Is this how it should work? If yes, there is a bug in mediawiki,
> because token returned by this api is randomly invalid. That means,
> sometimes it can be used and sometimes it return badtoken, which can
> be fixed only by either logging out and back in, or using the
> deprecated intoken parameter which returns working token (but is
> deprecated).
>
> If this is not how it should work, can someone explain to me how it
> works? Thanks
>
> here are some logs (read from bottom to top):
>
> Thu Nov 6 13:57:57 2014  DEBUG[1]: Failed to deliver message to 122.176.67.4
> Thu Nov 6 13:57:57 2014  Did not revert Tourism in Jammu and Kashmir:
> ERROR: Cannot rollback, token
> 0c59203d7b4d176f28540646c82e264a545b7039+\ is not valid for some
> reason (mediawiki bug), please try it once more
> Thu Nov 6 13:57:57 2014  DEBUG[1]: Query failed: badtoken details: See
> https://en.wikipedia.org/w/api.php for API usage
> Thu Nov 6 13:57:57 2014  DEBUG[1]: Rolling back Tourism in Jammu and Kashmir
> Thu Nov 6 13:57:57 2014  WARNING: API query (info): The intoken
> parameter has been deprecated.
> Thu Nov 6 13:57:57 2014  DEBUG[1]: Sending message to user 122.176.67.4
> Thu Nov 6 13:57:29 2014  DEBUG[1]: enwiki mediawiki 1.25wmf6
> Thu Nov 6 13:57:29 2014  DEBUG[2]: Token for enwiki rollback
> 0c59203d7b4d176f28540646c82e264a545b7039+\

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] How does new revert token system works?

[Petr Bena]

Hey,

I've seen a lot of changes in token system, however how it works is a
mystery to me. So far I understood it as:

You no longer get revert token per each edit using intoken but get
some kind of global rollback token using action=query&meta=tokens

Is this how it should work? If yes, there is a bug in mediawiki,
because token returned by this api is randomly invalid. That means,
sometimes it can be used and sometimes it return badtoken, which can
be fixed only by either logging out and back in, or using the
deprecated intoken parameter which returns working token (but is
deprecated).

If this is not how it should work, can someone explain to me how it
works? Thanks

here are some logs (read from bottom to top):

Thu Nov 6 13:57:57 2014  DEBUG[1]: Failed to deliver message to 122.176.67.4
Thu Nov 6 13:57:57 2014  Did not revert Tourism in Jammu and Kashmir:
ERROR: Cannot rollback, token
0c59203d7b4d176f28540646c82e264a545b7039+\ is not valid for some
reason (mediawiki bug), please try it once more
Thu Nov 6 13:57:57 2014  DEBUG[1]: Query failed: badtoken details: See
https://en.wikipedia.org/w/api.php for API usage
Thu Nov 6 13:57:57 2014  DEBUG[1]: Rolling back Tourism in Jammu and Kashmir
Thu Nov 6 13:57:57 2014  WARNING: API query (info): The intoken
parameter has been deprecated.
Thu Nov 6 13:57:57 2014  DEBUG[1]: Sending message to user 122.176.67.4
Thu Nov 6 13:57:29 2014  DEBUG[1]: enwiki mediawiki 1.25wmf6
Thu Nov 6 13:57:29 2014  DEBUG[2]: Token for enwiki rollback
0c59203d7b4d176f28540646c82e264a545b7039+\

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l