Re: [Wikitech-l] MediaWiki's Login Security

[Ori Livneh]

Tim Starling wrote:
> The test used upload.wikimedia.org, at a time when the
> browser would already have a keepalive connection open to port 80 but
> not port 443. Client-side aborts caused by navigating away from the
> page are not logged, and so if the HTTP request completes earlier than
> the HTTPS request, this opens a window for a systemic error in the
> results. If the user navigates away after the completion of the HTTP
> request, but before the completion of the HTTPS request, this would be
> logged as an HTTPS failure.

This is simply not true. The request to log the event hits
bits.wikimedia.org and is distinct from either request used as part of the
test. Navigating away before both requests have completed (or have been
forcibly timed-out) prevents the event from being logged at all.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki's Login Security

[Risker]

On 23 August 2013 19:55, Rob Lanphier  wrote:

> On Fri, Aug 23, 2013 at 3:43 PM, Risker  wrote:
> > No it doesn't change the security consideration. What changes is the
> > recognition that the problem may actually be bigger than initially
> thought.
> > Everyone knew about China and Iran.  Probably nobody knew about Pakistan,
> > Indonesia, Philippines, India, etc - all of which have multiple language
> > projects.  Even just HTTPS logins may be a challenge for some of these
> > countries, and it gives the WMF reason to consider how to better support
> > them just so everyone is protected and isn't left with the choice of
> > editing by IP or not editing at all.
>
> Hi Risker,
>
> We made a mistake in publishing those numbers.  We hadn't fully vetted
> the numbers, and after they went out, we discovered a flaw in our
> methodology that meant we were likely overcounting (probably
> drastically) the number of HTTPS failures we would see in practice.
>
> I'm going to quote Tim Starling's internal analysis below.  My
> apologies to Tim to forwarding without permission, though I doubt he
> would object.
>
> The main point is that we shouldn't draw too many conclusions about
> the data.  It was useful in seeing where we are being blocked (China
> and Iran), but the numbers <15% probably shouldn't be counted to draw
> any conclusions about problems in other countries.
>
> Rob
>

Thanks for the clarification, Rob.

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

Re: [Wikitech-l] MediaWiki's Login Security

[Risker]

On 23 August 2013 19:40, Marc A. Pelletier  wrote:

> On 08/23/2013 07:35 PM, Marc A. Pelletier wrote:
> > Would you care to share with whom that offline discussion
> > is happening?
>
> ... and, more importantly, /why/ is that discussion taking place offline
> in the first place?
>
>
As you and others may realise by now, I'm possibly the least technically
knowledgeable person who comments on this list. There's a limit as to how
often I feel the need to expose my limited knowledge to the immortal glare
of this mailing list. I had some questions which I sent to Chris Stiepp
(with whom I have worked in the past) and James Alexander (who is working
with Chris on reviewing technical and other processes related to advanced
permissions).  Seems my thoughts weren't completely stupid, and I've been
advised they're being discussed further internally at WMF.  I have no
reason to doubt that is true, and from the first post in this thread it is
clear that Chris is actively involved in the entire HTTPS/ secure login
action plan.

It's a big Engineering Department, so I wouldn't expect that everyone knows
what everyone else is doing all the time; nor would I expect that every
discussion about security issues and solutions would necessarily take place
on this mailing list, or even on a public mailing list.

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

Re: [Wikitech-l] MediaWiki's Login Security

[Brion Vibber]

On Fri, Aug 23, 2013 at 4:38 PM, Tilman Bayer  wrote:

> On Fri, Aug 23, 2013 at 3:51 PM, Brion Vibber 
> wrote:
> > I would strongly recommend a saner signup/account moderation system for
> > "less trusted" network origins such as Tor nodes, though. The key is that
> > you have to actually allow creating an account from a Tor node in the
> first
> > place, or you're limited to people who live in "free internet" countries
> or
> > have the money or clout to go abroad to create their accounts...
>
> Well yes, such a system would be nice to have, but as discussed
> previously on this list, it's a hard problem to solve ("Can we help
> Tor users make legitimate edits?",
> http://www.gossamer-threads.com/lists/wiki/wikitech/323006 ).
> Basically, the problem is that all the existing proposals would at
> best provide a substitute for autoblocks, but not for Checkuser.
>

I would make the argument that Checkuser is a) ineffective and b) dangerous
to privacy: it's incapable of actually identifying people in the first
place if they make any effort to work around it, and it exposes network
locations of people who aren't explicitly hiding to a fairly large group of
people.

That we've built a bureaucracy around checking to see what IP addresses
people came from and banning them if they appear to be the same as a
previously-banned person is pretty freaky at best and at worst **doesn't
actually help** against anyone with the slightest incentive to game the
system.

I'd recommend some out-of-the-box thinking instead, perhaps:
* stop exposing IP addresses of any users at all (whether logged-in or
anonymous)
* replace "IP editing" with a simple solution for creating a consistent
anonymous identity with a minimum of effort (for example, automatically
create an ID cookie which links to an anonymous 'account' which you can
optionally turn into a registered, named, emailable user account in the
future, or discard and replace every time if you're super-anonymous!)
* have much, much better inter-user communication and moderation tools that
can prioritize attention on activity of new users, low-reputation users,
at-risk network origins or user-agents, etc without exposing individual IP
addresses to actual users on the site

No, making a good system is not going to be easy. It's going to be hard,
and require a lot of thinking. But I really hope we get to it.



> Also, there is already
>
> https://en.wikipedia.org/wiki/Wikipedia:Advice_to_users_using_Tor#Need_an_account_.26_Tor_won.27t_let_you_create_one.3F
> (although I don't know how frequently/successfully it's being used
> currently)
>

At best, that's not very user friendly (and the page strongly discourages
anybody to use it by reminding that it's only for trusted people under
'exceptional circumstances'). At worst, it exposes your shiny new login
over plaintext email, so negative actors can sniff the data and associate
your account with your person.

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

Re: [Wikitech-l] MediaWiki's Login Security

[Rob Lanphier]

On Fri, Aug 23, 2013 at 3:43 PM, Risker  wrote:
> No it doesn't change the security consideration. What changes is the
> recognition that the problem may actually be bigger than initially thought.
> Everyone knew about China and Iran.  Probably nobody knew about Pakistan,
> Indonesia, Philippines, India, etc - all of which have multiple language
> projects.  Even just HTTPS logins may be a challenge for some of these
> countries, and it gives the WMF reason to consider how to better support
> them just so everyone is protected and isn't left with the choice of
> editing by IP or not editing at all.

Hi Risker,

We made a mistake in publishing those numbers.  We hadn't fully vetted
the numbers, and after they went out, we discovered a flaw in our
methodology that meant we were likely overcounting (probably
drastically) the number of HTTPS failures we would see in practice.

I'm going to quote Tim Starling's internal analysis below.  My
apologies to Tim to forwarding without permission, though I doubt he
would object.

The main point is that we shouldn't draw too many conclusions about
the data.  It was useful in seeing where we are being blocked (China
and Iran), but the numbers <15% probably shouldn't be counted to draw
any conclusions about problems in other countries.

Rob

Tim Starling wrote:
> The test used upload.wikimedia.org, at a time when the
> browser would already have a keepalive connection open to port 80 but
> not port 443. Client-side aborts caused by navigating away from the
> page are not logged, and so if the HTTP request completes earlier than
> the HTTPS request, this opens a window for a systemic error in the
> results. If the user navigates away after the completion of the HTTP
> request, but before the completion of the HTTPS request, this would be
> logged as an HTTPS failure.
>
> My theory two days ago was that the size of the window would be the
> time it took the browser to do the connection setup, or possibly the
> whole request. But it occurs to me now that the browser may have its
> maximum number of concurrent connections open when the test starts. So
> the request might be queued by the browser until a connection slot
> opens up. That queue wait time might depend on network bandwidth, as
> well as RTT.
>
> If both the HTTP and the HTTPS tests used a hostname which is unlikely
> to have a keepalive connection open, and if the order of the two tests
> was randomized rather than always sending the HTTP request first, then
> I think you would get closer to accurate results. However, actual
> performance differences between HTTPS and HTTP would still cause a
> systemic error.

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

Re: [Wikitech-l] MediaWiki's Login Security

[Marc A. Pelletier]

On 08/23/2013 07:35 PM, Marc A. Pelletier wrote:
> Would you care to share with whom that offline discussion
> is happening?

... and, more importantly, /why/ is that discussion taking place offline
in the first place?

-- Marc


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

Re: [Wikitech-l] MediaWiki's Login Security

[Tilman Bayer]

On Fri, Aug 23, 2013 at 3:51 PM, Brion Vibber  wrote:
> On Fri, Aug 23, 2013 at 3:47 PM, Risker  wrote:
>
>> Just for the record, anyone at administrator level or higher has IPBE built
>> into their tools (I believe on all projects), so they can
>> edit/administer/checkuser/etc using Tor.
>>
>> But given that over 95% of anything that comes through an unblocked Tor
>> node onto English Wikipedia is either spam or vandalism, I can't support
>> allowing unbridled Tor editing on at least that project.
>>
>
> Well, we don't allow "unbridled" anything; our administrators litter the IP
> address universe and logged-in users alike with blocks constantly. :)
>
> I would strongly recommend a saner signup/account moderation system for
> "less trusted" network origins such as Tor nodes, though. The key is that
> you have to actually allow creating an account from a Tor node in the first
> place, or you're limited to people who live in "free internet" countries or
> have the money or clout to go abroad to create their accounts...
>
> -- brion

Well yes, such a system would be nice to have, but as discussed
previously on this list, it's a hard problem to solve ("Can we help
Tor users make legitimate edits?",
http://www.gossamer-threads.com/lists/wiki/wikitech/323006 ).
Basically, the problem is that all the existing proposals would at
best provide a substitute for autoblocks, but not for Checkuser.

Also, there is already
https://en.wikipedia.org/wiki/Wikipedia:Advice_to_users_using_Tor#Need_an_account_.26_Tor_won.27t_let_you_create_one.3F
(although I don't know how frequently/successfully it's being used
currently)

-- 
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB

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

Re: [Wikitech-l] MediaWiki's Login Security

[Marc A. Pelletier]

On 08/23/2013 05:33 PM, Risker wrote:
> there's already an offline discussion happening looking
> for ways to effectively manage this without outright banning editors from
> those geographical regions from serving Wikimedia communities

Interesting.  Would you care to share with whom that offline discussion
is happening?  Your email makes it look as though you speak on behalf of
the Foundation, which is clearly not the case and - as far as I know -
that discussion isn't taking place with the members of the ops team who
actually are working on HTTPS.

-- Marc


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

Re: [Wikitech-l] MediaWiki's Login Security

[Brion Vibber]

On Fri, Aug 23, 2013 at 3:47 PM, Risker  wrote:

> Just for the record, anyone at administrator level or higher has IPBE built
> into their tools (I believe on all projects), so they can
> edit/administer/checkuser/etc using Tor.
>
> But given that over 95% of anything that comes through an unblocked Tor
> node onto English Wikipedia is either spam or vandalism, I can't support
> allowing unbridled Tor editing on at least that project.
>

Well, we don't allow "unbridled" anything; our administrators litter the IP
address universe and logged-in users alike with blocks constantly. :)

I would strongly recommend a saner signup/account moderation system for
"less trusted" network origins such as Tor nodes, though. The key is that
you have to actually allow creating an account from a Tor node in the first
place, or you're limited to people who live in "free internet" countries or
have the money or clout to go abroad to create their accounts...

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

Re: [Wikitech-l] MediaWiki's Login Security

[Risker]

On 23 August 2013 18:42, Brion Vibber  wrote:

> So, some ideas:
>
> 
>
> And for the "some countries block our HTTPS" issue:
> * *actually support* use of Tor etc for editing, allowing folks "in the
> know" to work around the government blocks and use the site over HTTPS
>
>


Just for the record, anyone at administrator level or higher has IPBE built
into their tools (I believe on all projects), so they can
edit/administer/checkuser/etc using Tor.

But given that over 95% of anything that comes through an unblocked Tor
node onto English Wikipedia is either spam or vandalism, I can't support
allowing unbridled Tor editing on at least that project.

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

Re: [Wikitech-l] MediaWiki's Login Security

[Tyler Romeo]

On Fri, Aug 23, 2013 at 6:43 PM, Risker  wrote:

> Well, I'm not terribly technical, but I don't think there's ever been
> consideration of linking login requirements to user permissions. Perhaps
> that needs to change. I'm concerned too.
>

Unfortunately it's very difficult to do this. On our login forms you enter
your username and password simultaneously, which means the server can't
possibly know if the user has to be using HTTPS until they've already
submitted their password, thus defeating the purpose. That's why
$wgSecureLogin is made to *always* put logins over HTTPS, no matter what,
and then direct the user to the appropriate protocol afterwards.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki's Login Security

[Risker]

On 23 August 2013 18:35, David Gerard  wrote:

> On 23 August 2013 23:31, Risker  wrote:
>
> > There are other options. The question is whether or not they can be made
> to
> > work in the MediaWiki/WMF circumstances.  If you looked at the data
> > collected to see where HTTPS attempts were unsuccessful, you'd see that
> > there are editors in a lot of countries with issues (i.e., greater than
> 5%
> > failure rates), and most of them are technical issues.  Suddenly you're
> not
> > just talking about a few projects, you're talking about dozens who may
> have
> > difficulty getting CU/OS support internally.
>
>
> That doesn't change the security consideration.
>

No it doesn't change the security consideration. What changes is the
recognition that the problem may actually be bigger than initially thought.
Everyone knew about China and Iran.  Probably nobody knew about Pakistan,
Indonesia, Philippines, India, etc - all of which have multiple language
projects.  Even just HTTPS logins may be a challenge for some of these
countries, and it gives the WMF reason to consider how to better support
them just so everyone is protected and isn't left with the choice of
editing by IP or not editing at all.


>
> > The people in our many overlapping MediaWiki and Wikimedia communities
> have
> > come up with a lot of very creative solutions to problems that other
> sites
> > haven't figured out or don't care enough to bother with.  I have a lot of
> > faith that some out of the box thinking might very well resolve this
> > specific issue, and possibly open a gateway to solving the security issue
> > for even larger groups.
>
>
> And until then, it actually needs to be HTTPS-only. I'm horrified it
> isn't already.
>
>
Well, I'm not terribly technical, but I don't think there's ever been
consideration of linking login requirements to user permissions. Perhaps
that needs to change. I'm concerned too.

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

Re: [Wikitech-l] MediaWiki's Login Security

[Brion Vibber]

So, some ideas:

As for the idea that we need to fix internet that's so bad it can't handle
HTTPS for "technical reasons"; anything that's that broken is pretty
hopeless to "fix" from the web server's end. Instead, consider:
* provide support to groups working for improving internet access in areas
with poor connectivity

And for the "some countries block our HTTPS" issue:
* *actually support* use of Tor etc for editing, allowing folks "in the
know" to work around the government blocks and use the site over HTTPS
* provide support to groups working against government censorship of the
internet
* sponsor an official hosted-and-run-in-PRC censor-friendly mirror, and
devise some way to migrate edits back

This last would probably be controversial, but if we're serious about
'providing access to knowledge' in PRC, I suspect that's our best bet. Good
news is, we're an open-source open-content project, and so this service
could be launched *by anyone at any time*. Arguably, Baidupedia already
beat us to this.

-- brion



On Fri, Aug 23, 2013 at 3:31 PM, Risker  wrote:

> On 23 August 2013 18:13, Tyler Romeo  wrote:
>
> > On Fri, Aug 23, 2013 at 5:33 PM, Risker  wrote:
> >
> > > As I said, Marc, there's already an offline discussion happening
> looking
> > > for ways to effectively manage this without outright banning editors
> from
> > > those geographical regions from serving Wikimedia communities.  A
> > decision
> > > to prevent users from certain countries or with certain technical
> > > challenges from holding these permissions is as much a policy issue as
> it
> > > is a security issue (it's also a cross-wiki one), so that aspect needs
> to
> > > be considered from a broad community perspective.
> > >
> >
> > It's statements like these that make me question whether the WMF actually
> > cares about its users' privacy in the first place. There's some big talk
> on
> > this list about "subverting the NSA" and making sure that users are
> secure
> > within their accounts when using Wikipedia. But if you're not willing to
> > actually do something about privacy, then it's just talk.
> >
>
>
> > It is completely unacceptable for checkusers in China to be logging in
> over
> > an insecure connection. The Chinese government directly monitors these
> > connections and can easily harvest these passwords en masse. I truly
> > sympathize with Chinese Wikipedians who aspire to hold checkuser
> positions,
> > but putting at risk the IP address information of every user on Wikipedia
> > just for the sake of one person who wants to volunteer in a certain
> > capacity is completely unacceptable.
> >
>
> I'm not disagreeing with you about Checkusers (wherever they're from)
> needing to have secure connections when using the tools.  If a community
> RFC was posted today, I would support that requirement.
>
>
>
> >
> > If a technical solution can be found that facilitates affected users
> being
> > > able to securely use the tools, then the policy discussion would focus
> on
> > > whether we require those editors to use the technical solution, instead
> > of
> > > recommending outright bans to granting advanced permissions to those
> > > affected by HTTPS issues.  Solutions are already being considered and
> > > examined for this; granted, the discussion is occurring off-wiki so you
> > > wouldn't have been aware.
> >
> >
> > There is no technical solution, as has been discussed previously. The
> China
> > firewall blocks all HTTPS connections. There is no legal method of
> getting
> > around this. The only solution that would preserve both accessibility and
> > security would be if Wikipedia implemented its own application level TLS
> > protocol, which would be an absurd undertaking, and would probably just
> > result in the Chinese government blocking Wikipedia completely anyway.
> >
> > You're going to have to choose: risk everybody's privacy or deny
> checkuser
> > opportunities to people in China.
> >
> >
> There are other options. The question is whether or not they can be made to
> work in the MediaWiki/WMF circumstances.  If you looked at the data
> collected to see where HTTPS attempts were unsuccessful, you'd see that
> there are editors in a lot of countries with issues (i.e., greater than 5%
> failure rates), and most of them are technical issues.  Suddenly you're not
> just talking about a few projects, you're talking about dozens who may have
> difficulty getting CU/OS support internally.
>
> The people in our many overlapping MediaWiki and Wikimedia communities have
> come up with a lot of very creative solutions to problems that other sites
> haven't figured out or don't care enough to bother with.  I have a lot of
> faith that some out of the box thinking might very well resolve this
> specific issue, and possibly open a gateway to solving the security issue
> for even larger groups.
>
> Risker/Anne
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
>

Re: [Wikitech-l] MediaWiki's Login Security

[Tyler Romeo]

On Fri, Aug 23, 2013 at 6:35 PM, David Gerard  wrote:

> And until then, it actually needs to be HTTPS-only. I'm horrified it
> isn't already.
>

Also, now would be a good time to mention that it is impossible to force
HTTPS login for checkusers due to the current GeoIP solution that was just
implemented.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki's Login Security

[David Gerard]

On 23 August 2013 23:31, Risker  wrote:

> There are other options. The question is whether or not they can be made to
> work in the MediaWiki/WMF circumstances.  If you looked at the data
> collected to see where HTTPS attempts were unsuccessful, you'd see that
> there are editors in a lot of countries with issues (i.e., greater than 5%
> failure rates), and most of them are technical issues.  Suddenly you're not
> just talking about a few projects, you're talking about dozens who may have
> difficulty getting CU/OS support internally.


That doesn't change the security consideration.


> The people in our many overlapping MediaWiki and Wikimedia communities have
> come up with a lot of very creative solutions to problems that other sites
> haven't figured out or don't care enough to bother with.  I have a lot of
> faith that some out of the box thinking might very well resolve this
> specific issue, and possibly open a gateway to solving the security issue
> for even larger groups.


And until then, it actually needs to be HTTPS-only. I'm horrified it
isn't already.


- d.

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

Re: [Wikitech-l] MediaWiki's Login Security

[Risker]

On 23 August 2013 18:13, Tyler Romeo  wrote:

> On Fri, Aug 23, 2013 at 5:33 PM, Risker  wrote:
>
> > As I said, Marc, there's already an offline discussion happening looking
> > for ways to effectively manage this without outright banning editors from
> > those geographical regions from serving Wikimedia communities.  A
> decision
> > to prevent users from certain countries or with certain technical
> > challenges from holding these permissions is as much a policy issue as it
> > is a security issue (it's also a cross-wiki one), so that aspect needs to
> > be considered from a broad community perspective.
> >
>
> It's statements like these that make me question whether the WMF actually
> cares about its users' privacy in the first place. There's some big talk on
> this list about "subverting the NSA" and making sure that users are secure
> within their accounts when using Wikipedia. But if you're not willing to
> actually do something about privacy, then it's just talk.
>


> It is completely unacceptable for checkusers in China to be logging in over
> an insecure connection. The Chinese government directly monitors these
> connections and can easily harvest these passwords en masse. I truly
> sympathize with Chinese Wikipedians who aspire to hold checkuser positions,
> but putting at risk the IP address information of every user on Wikipedia
> just for the sake of one person who wants to volunteer in a certain
> capacity is completely unacceptable.
>

I'm not disagreeing with you about Checkusers (wherever they're from)
needing to have secure connections when using the tools.  If a community
RFC was posted today, I would support that requirement.



>
> If a technical solution can be found that facilitates affected users being
> > able to securely use the tools, then the policy discussion would focus on
> > whether we require those editors to use the technical solution, instead
> of
> > recommending outright bans to granting advanced permissions to those
> > affected by HTTPS issues.  Solutions are already being considered and
> > examined for this; granted, the discussion is occurring off-wiki so you
> > wouldn't have been aware.
>
>
> There is no technical solution, as has been discussed previously. The China
> firewall blocks all HTTPS connections. There is no legal method of getting
> around this. The only solution that would preserve both accessibility and
> security would be if Wikipedia implemented its own application level TLS
> protocol, which would be an absurd undertaking, and would probably just
> result in the Chinese government blocking Wikipedia completely anyway.
>
> You're going to have to choose: risk everybody's privacy or deny checkuser
> opportunities to people in China.
>
>
There are other options. The question is whether or not they can be made to
work in the MediaWiki/WMF circumstances.  If you looked at the data
collected to see where HTTPS attempts were unsuccessful, you'd see that
there are editors in a lot of countries with issues (i.e., greater than 5%
failure rates), and most of them are technical issues.  Suddenly you're not
just talking about a few projects, you're talking about dozens who may have
difficulty getting CU/OS support internally.

The people in our many overlapping MediaWiki and Wikimedia communities have
come up with a lot of very creative solutions to problems that other sites
haven't figured out or don't care enough to bother with.  I have a lot of
faith that some out of the box thinking might very well resolve this
specific issue, and possibly open a gateway to solving the security issue
for even larger groups.

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

Re: [Wikitech-l] MediaWiki's Login Security

[Tyler Romeo]

On Fri, Aug 23, 2013 at 6:16 PM, Ryan Lane  wrote:

> Well, it's also possible that you're just not having clever enough ideas,
> eh? ;)
>

True, but to be honest, if we come up with a clever enough idea, from
China's perspective that's just us getting around their security, which
they wouldn't exactly take kindly towards...

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki's Login Security

[Ryan Lane]

On Fri, Aug 23, 2013 at 3:13 PM, Tyler Romeo  wrote:

> On Fri, Aug 23, 2013 at 5:33 PM, Risker  wrote:
>
> > As I said, Marc, there's already an offline discussion happening looking
> > for ways to effectively manage this without outright banning editors from
> > those geographical regions from serving Wikimedia communities.  A
> decision
> > to prevent users from certain countries or with certain technical
> > challenges from holding these permissions is as much a policy issue as it
> > is a security issue (it's also a cross-wiki one), so that aspect needs to
> > be considered from a broad community perspective.
> >
>
> It's statements like these that make me question whether the WMF actually
> cares about its users' privacy in the first place. There's some big talk on
> this list about "subverting the NSA" and making sure that users are secure
> within their accounts when using Wikipedia. But if you're not willing to
> actually do something about privacy, then it's just talk.
>
> It is completely unacceptable for checkusers in China to be logging in over
> an insecure connection. The Chinese government directly monitors these
> connections and can easily harvest these passwords en masse. I truly
> sympathize with Chinese Wikipedians who aspire to hold checkuser positions,
> but putting at risk the IP address information of every user on Wikipedia
> just for the sake of one person who wants to volunteer in a certain
> capacity is completely unacceptable.
>
> If a technical solution can be found that facilitates affected users being
> > able to securely use the tools, then the policy discussion would focus on
> > whether we require those editors to use the technical solution, instead
> of
> > recommending outright bans to granting advanced permissions to those
> > affected by HTTPS issues.  Solutions are already being considered and
> > examined for this; granted, the discussion is occurring off-wiki so you
> > wouldn't have been aware.
>
>
> There is no technical solution, as has been discussed previously. The China
> firewall blocks all HTTPS connections. There is no legal method of getting
> around this. The only solution that would preserve both accessibility and
> security would be if Wikipedia implemented its own application level TLS
> protocol, which would be an absurd undertaking, and would probably just
> result in the Chinese government blocking Wikipedia completely anyway.
>
> You're going to have to choose: risk everybody's privacy or deny checkuser
> opportunities to people in China.
>
>
Well, it's also possible that you're just not having clever enough ideas,
eh? ;)

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

Re: [Wikitech-l] MediaWiki's Login Security

[Tyler Romeo]

On Fri, Aug 23, 2013 at 5:33 PM, Risker  wrote:

> As I said, Marc, there's already an offline discussion happening looking
> for ways to effectively manage this without outright banning editors from
> those geographical regions from serving Wikimedia communities.  A decision
> to prevent users from certain countries or with certain technical
> challenges from holding these permissions is as much a policy issue as it
> is a security issue (it's also a cross-wiki one), so that aspect needs to
> be considered from a broad community perspective.
>

It's statements like these that make me question whether the WMF actually
cares about its users' privacy in the first place. There's some big talk on
this list about "subverting the NSA" and making sure that users are secure
within their accounts when using Wikipedia. But if you're not willing to
actually do something about privacy, then it's just talk.

It is completely unacceptable for checkusers in China to be logging in over
an insecure connection. The Chinese government directly monitors these
connections and can easily harvest these passwords en masse. I truly
sympathize with Chinese Wikipedians who aspire to hold checkuser positions,
but putting at risk the IP address information of every user on Wikipedia
just for the sake of one person who wants to volunteer in a certain
capacity is completely unacceptable.

If a technical solution can be found that facilitates affected users being
> able to securely use the tools, then the policy discussion would focus on
> whether we require those editors to use the technical solution, instead of
> recommending outright bans to granting advanced permissions to those
> affected by HTTPS issues.  Solutions are already being considered and
> examined for this; granted, the discussion is occurring off-wiki so you
> wouldn't have been aware.


There is no technical solution, as has been discussed previously. The China
firewall blocks all HTTPS connections. There is no legal method of getting
around this. The only solution that would preserve both accessibility and
security would be if Wikipedia implemented its own application level TLS
protocol, which would be an absurd undertaking, and would probably just
result in the Chinese government blocking Wikipedia completely anyway.

You're going to have to choose: risk everybody's privacy or deny checkuser
opportunities to people in China.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Labs-l] Etherpad Lite labs instance going down in two weeks - backup time

[Ken Snider]

Rob H. has been doing this manually for us, and we've essentially been ensuring 
our pads are in wikitext to assist with the drop-in ease of this process.

Sounds like a fun project, though, once we get etherpad-lite up to a current 
rev :)

Thanks.

--Ken.

On Aug 23, 2013, at 4:43 PM, Greg Grossmeier  wrote:

> 
>> Thanks to Mark Holmquist for maintaining http://etherpad.wmflabs.org for
>> the past long while. It is going down in 2 weeks, so please retrieve
>> your text.
>> 
>> I recommend that you:
>> 
>> * go into your browser history
>> * search it for etherpad.wmflabs.org
>> * go to each of those pads and copy-and-paste the content someplace,
>> preferably on a public wiki, even if it's just in your userspace
>> * replace the content of the Etherpad with a link to the wiki page
>> you've moved the text to
> 
> Has anyone made an automatic etherpad -> wiki script yet? I'd love to
> have a list of etherpad urls in some txt file I maintain of important
> pads/pads I want sync'd on a wiki page for public consumption. I guess
> the text file might need to have the relationship of pad to wikipage.
> 
> My duckduckgo searching wasn't successful.
> 
> Greg
> 
> -- 
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
> 
> ___
> Labs-l mailing list
> lab...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l


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

Re: [Wikitech-l] Etherpad Lite labs instance going down in two weeks - backup time

[Ryan Lane]

We don't consider etherpad archive-worthy. It's always been considered an
ephemeral service and we're not willing to put any effort into to save data
from it. If you care about data that you've personally hosted in it, please
put it somewhere that's meant to be archived.

We don't have backups for the service and never will.


On Fri, Aug 23, 2013 at 1:55 PM, Federico Leva (Nemo) wrote:

> Why is a DB merge not possible? Will the DB be kept somewhere, e.g. in the
> private data of downloads.wikimedia.org?
>
> Nemo
>
>
> __**_
> 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] Deployment highlights for the week of August 26th

[Greg Grossmeier]

Hello!

Here is your deployment highlights email for next week!

The full schedule can be found at:
https://wikitech.wikimedia.org/wiki/Deployments#Week_of_August_26th


== Monday ==
* MediaWiki 1.22wmf14 will roll out to the second group of wikis:
  All non-Wikipedia sites (Wiktionary, Wikisource, Wikinews, Wikibooks,
  Wikiquote, Wikiversity, and a few other sites)
  Information about MediaWiki 1.22wmf14:
  https://www.mediawiki.org/wiki/MediaWiki_1.22/wmf14

* At the same time, Wikidata Phase 2 will be enabled on WikiVoyage.


== Tuesday ==
* The Mobile team will be enabling Notifications on mobile sites for all
  Echo-enabled projects.


== Wednesday ==
* The much anticipated new search backend will be deployed to
  mediawiki.org.

* SecureLogin for all wikis. The full (including technical) details are
  available here:
  https://www.mediawiki.org/wiki/Requests_for_comment/Login_security

  The official 'plan of record' for what will be happening can be seen
  in RobLa's email here:
  http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071441.html


== Thursday ==
* MediaWiki 1.22wmf14 will be rolled out to all Wikipedias.

* CodeEditor support will be enabled for all JS and CSS on all wikis



As always, let me know if you have any questions.

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |


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

Re: [Wikitech-l] MediaWiki's Login Security

[Risker]

On 23 August 2013 17:10, Marc A. Pelletier  wrote:

> On 08/23/2013 04:35 PM, Risker wrote:
> > I'd like to see what can be developed, however, to support
> > Checkusers/Oversighters/Stewards who have difficulty using HTTPS
>
> Pretty much by definition the accounts holding those bits are the one we
> /least/ want to have their password snooped, and the ones most likely to
> be targeted by malicious eavesdroppers.  If we could only support some
> accounts to use HTTPS, those are the ones we would need to force.
>
> Yes, it does mean that there could not be checkusers in mainland China,
> for instance as long as they are unable to log in through HTTPS.  That
> would be a /good/ thing.
>
>
As I said, Marc, there's already an offline discussion happening looking
for ways to effectively manage this without outright banning editors from
those geographical regions from serving Wikimedia communities.  A decision
to prevent users from certain countries or with certain technical
challenges from holding these permissions is as much a policy issue as it
is a security issue (it's also a cross-wiki one), so that aspect needs to
be considered from a broad community perspective.

If a technical solution can be found that facilitates affected users being
able to securely use the tools, then the policy discussion would focus on
whether we require those editors to use the technical solution, instead of
recommending outright bans to granting advanced permissions to those
affected by HTTPS issues.  Solutions are already being considered and
examined for this; granted, the discussion is occurring off-wiki so you
wouldn't have been aware.

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

Re: [Wikitech-l] MediaWiki's Login Security

[Marc A. Pelletier]

On 08/23/2013 04:35 PM, Risker wrote:
> I'd like to see what can be developed, however, to support
> Checkusers/Oversighters/Stewards who have difficulty using HTTPS

Pretty much by definition the accounts holding those bits are the one we
/least/ want to have their password snooped, and the ones most likely to
be targeted by malicious eavesdroppers.  If we could only support some
accounts to use HTTPS, those are the ones we would need to force.

Yes, it does mean that there could not be checkusers in mainland China,
for instance as long as they are unable to log in through HTTPS.  That
would be a /good/ thing.

-- Marc


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

Re: [Wikitech-l] Etherpad Lite labs instance going down in two weeks - backup time

[Federico Leva (Nemo)]

Why is a DB merge not possible? Will the DB be kept somewhere, e.g. in 
the private data of downloads.wikimedia.org?


Nemo

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

Re: [Wikitech-l] Etherpad Lite labs instance going down in two weeks - backup time

[Greg Grossmeier]

> Thanks to Mark Holmquist for maintaining http://etherpad.wmflabs.org for
> the past long while. It is going down in 2 weeks, so please retrieve
> your text.
> 
> I recommend that you:
> 
> * go into your browser history
> * search it for etherpad.wmflabs.org
> * go to each of those pads and copy-and-paste the content someplace,
> preferably on a public wiki, even if it's just in your userspace
> * replace the content of the Etherpad with a link to the wiki page
> you've moved the text to

Has anyone made an automatic etherpad -> wiki script yet? I'd love to
have a list of etherpad urls in some txt file I maintain of important
pads/pads I want sync'd on a wiki page for public consumption. I guess
the text file might need to have the relationship of pad to wikipage.

My duckduckgo searching wasn't successful.

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

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

Re: [Wikitech-l] MediaWiki's Login Security

[Risker]

On 23 August 2013 16:25, Marc A. Pelletier  wrote:

> On 08/23/2013 02:36 PM, Tyler Romeo wrote:
> > You mean like my $wgSecureGroups approach? Because if people actually
> still
> > want that I can attempt to revive that part of my patch. I think it'd be
> of
> > especial interest to require HTTPS for checkusers and oversight people,
> due
> > to the legal problems associated with breaches to those accounts.
>
> +1
>
>
I also see some value to this, and I speak as a member of both those
groups. I'd like to see what can be developed, however, to support
Checkusers/Oversighters/Stewards who have difficulty using HTTPS, and I
have already initiated an offline discussion with Chris and others at the
WMF about this.

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

Re: [Wikitech-l] MediaWiki's Login Security

[David Gerard]

On 23 August 2013 21:28, Marc A. Pelletier  wrote:
> On 08/23/2013 03:23 PM, Martijn Hoekstra wrote:

>> Requiring https for advanced privileges seems odd. Would that require a
>> second set of credentials over a https only page?

> You're missing the point.  People who have (for instance) checkuser or
> oversight should be simply disallowed from logging in through HTTP at all.


+1

There can't really be a geoIP exemption for this.


- d.

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

Re: [Wikitech-l] Etherpad Lite labs instance going down in two weeks - backup time

[Marc A. Pelletier]

On 08/23/2013 04:02 PM, Mark Holmquist wrote:
> And in the future: If a URL has "wmflabs.org" in it...don't put anything,
> ANYTHING, important there. The purpose of labs is to let us experiment with
> new technology without having to worry about reliability.

It'd be more correct to say that any specific labs project /may/ not
have reliability as a concern.  I'm pretty sure that tool labs users
find their tools are important.  :-)

-- Marc

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

Re: [Wikitech-l] MediaWiki's Login Security

[Marc A. Pelletier]

On 08/23/2013 03:23 PM, Martijn Hoekstra wrote:
> Requiring https for advanced privileges seems odd. Would that require a
> second set of credentials over a https only page?

You're missing the point.  People who have (for instance) checkuser or
oversight should be simply disallowed from logging in through HTTP at all.

-- Marc


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

Re: [Wikitech-l] MediaWiki's Login Security

[Marc A. Pelletier]

On 08/23/2013 02:36 PM, Tyler Romeo wrote:
> You mean like my $wgSecureGroups approach? Because if people actually still
> want that I can attempt to revive that part of my patch. I think it'd be of
> especial interest to require HTTPS for checkusers and oversight people, due
> to the legal problems associated with breaches to those accounts.

+1

-- Marc


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

Re: [Wikitech-l] Etherpad Lite labs instance going down in two weeks - backup time

[Tomasz Finc]

CC'ing staff as we might have some non engineers using this service
who should know.

On Fri, Aug 23, 2013 at 1:02 PM, Mark Holmquist  wrote:
> The day we have all equally hoped for and dreaded is come to pass: Etherpad
> Lite has now replaced Etherpad "Classic" in production, and the labs instance
> is on its way out.
>
> This is my as-wide-as-possible email warning to say that everything on the
> labs instance, as really should have been expected, is going to be gone soon.
> Not immediately - we intend to give you two weeks to get your important data
> off the instance and onto the new one at https://etherpad.wikimedia.org/ -
> but you should _absolutely_ be moving things as soon as possible. We will
> also keep a data dump around, in case anything else needs to get pulled out
> of the pads, but I would suggest not relying on that if you don't have to.
>
> And in the future: If a URL has "wmflabs.org" in it...don't put anything,
> ANYTHING, important there. The purpose of labs is to let us experiment with
> new technology without having to worry about reliability.
>
> Thanks so much for your help and understanding in the course of this
> migration.
>
> tl;dr: http://etherpad.wmflabs.org is going down in 2 weeks, get yer stuff
> off it.
>
> --
> Mark Holmquist
> Software Engineer, Multimedia
> Wikimedia Foundation
> mtrac...@member.fsf.org
> https://wikimediafoundation.org/wiki/User:MHolmquist
>
> ___
> 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] Etherpad Lite labs instance going down in two weeks - backup time

[Mark Holmquist]

The day we have all equally hoped for and dreaded is come to pass: Etherpad
Lite has now replaced Etherpad "Classic" in production, and the labs instance
is on its way out.

This is my as-wide-as-possible email warning to say that everything on the
labs instance, as really should have been expected, is going to be gone soon.
Not immediately - we intend to give you two weeks to get your important data
off the instance and onto the new one at https://etherpad.wikimedia.org/ -
but you should _absolutely_ be moving things as soon as possible. We will
also keep a data dump around, in case anything else needs to get pulled out
of the pads, but I would suggest not relying on that if you don't have to.

And in the future: If a URL has "wmflabs.org" in it...don't put anything,
ANYTHING, important there. The purpose of labs is to let us experiment with
new technology without having to worry about reliability.

Thanks so much for your help and understanding in the course of this
migration.

tl;dr: http://etherpad.wmflabs.org is going down in 2 weeks, get yer stuff
off it.

-- 
Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
mtrac...@member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist

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

Re: [Wikitech-l] MediaWiki's Login Security

[Rob Lanphier]

On Fri, Aug 23, 2013 at 10:46 AM, Chris Steipp  wrote:
> With all the talk about turning on $wgSecureLogin for WMF sites, there has
> been a lot of misconceptions about how the option works, and difference of
> opinions about how they should work in the future.
>
> I started:
> https://www.mediawiki.org/wiki/Requests_for_comment/Login_security

Hi folks,

I filled in a few things for our plan of record, which I'll summarize here:

1. Use of GeoIP to disable HTTPS for the MediaWiki login vs enabling
on per wiki basis

Plan of record: Implement GeoIP-based exclusion from the HTTPS default
for China and Iran for all wikis, and rely exclusively on GeoIP for
exclusion strategy (do not vary based on wiki).

2.  Use of a preference vs login form checkbox vs hidden option vs
sensible default

Plan of record: Have a preference (default: on) for always using a
secure HTTPS connection as a logged user. This preference will be
hidden for users in China and Iran, where the behavior will be off.

3.  How interactions with login.wikimedia.org will work

Plan of record: we'll keep the status quo for Wednesday, August 28,
but this will be the next item we explore.

4.  Validation of our HTTPS test methodology

Plan of record: TBD.  We haven't had a chance to regroup after
figuring out the problems with our initial methodology.  We'll do more
next week.

Rob

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

[Wikitech-l] Bugzilla Tips: Greasemonkey scripts

[Andre Klapper]

Hi,

shameless plug to remind you of my regular blogging on Bugzilla use:

If you deal a lot with Wikimedia Bugzilla and if you deal with a lot of
bug reports with varying quality (for example because you triage bug
reports), I recommend to take a look at my latest blogpost covering
Greasemonkey scripts to save some time:

http://blogs.gnome.org/aklapper/2013/08/23/bugzillatips-triage-helpertools-greasemonkey/

Comments, testing, feedback, patches, unicorns welcome.

Cheers & enjoy the weekend!
andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/




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

Re: [Wikitech-l] MediaWiki's Login Security

[Martijn Hoekstra]

On Aug 23, 2013 7:46 PM, "Chris Steipp"  wrote:
>
> Hi all,
>
> With all the talk about turning on $wgSecureLogin for WMF sites, there has
> been a lot of misconceptions about how the option works, and difference of
> opinions about how they should work in the future.
>
> I started:
> https://www.mediawiki.org/wiki/Requests_for_comment/Login_security
>
> It would be great to get feedback on the "Longer Term Questions" section.
> Also, if anyone isn't entirely clear about how the preferences work,
> hopefully this will provide some clarification.
>

Requiring https for advanced privileges seems odd. Would that require a
second set of credentials over a https only page? If not, the most
important consideration is already lost, the credentials. If yes, will
people actually use different credentials? Should that be enforced? Is that
worth the software complexity? What are the advantages here?

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

Re: [Wikitech-l] MediaWiki's Login Security

[Tyler Romeo]

>
>
>- Should MediaWiki support allowing some users to use http for their
>login, while most users use https? If yes, what are reasonable criteria for
>determining who can use http (e.g., user groups, GeoIP, or some other
>criteria)?
>
>
I don't have an answer for this, but if it is done it should not be in
core, which seems to be the current approach anyway (since the current
patch just adds a CanUseHTTPS hook).


>
>- Should MediaWiki support logged in users using HTTP, when HTTPS is
>available to them but they don't want to use it (typically for performance
>reasons-- low end devices, lack of caching, etc)?
>
>
I think so. I mean the difficulty of allowing a user to go back to HTTP is
not that difficult.


>
>- Should MediaWiki support requiring HTTPS for users with advanced
>privileges?
>
>
You mean like my $wgSecureGroups approach? Because if people actually still
want that I can attempt to revive that part of my patch. I think it'd be of
especial interest to require HTTPS for checkusers and oversight people, due
to the legal problems associated with breaches to those accounts.


*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com


On Fri, Aug 23, 2013 at 1:46 PM, Chris Steipp  wrote:

> Hi all,
>
> With all the talk about turning on $wgSecureLogin for WMF sites, there has
> been a lot of misconceptions about how the option works, and difference of
> opinions about how they should work in the future.
>
> I started:
> https://www.mediawiki.org/wiki/Requests_for_comment/Login_security
>
> It would be great to get feedback on the "Longer Term Questions" section.
> Also, if anyone isn't entirely clear about how the preferences work,
> hopefully this will provide some clarification.
> ___
> 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] Weighted random article

[Tyler Romeo]

On Fri, Aug 23, 2013 at 1:38 PM, Bináris  wrote:

> Unfortunately, there is no exact measure of the human or bot factor of the
> creator of an article, and I have long been sad because of this. Botness of
> an editor is only stored in recent changes table for a while, and cannot be
> retrieved from page history.
>

That's pretty much accurate, at least until there becomes a way to
add/change revision tags through the API.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki's Login Security

[Chris Steipp]

Hi all,

With all the talk about turning on $wgSecureLogin for WMF sites, there has
been a lot of misconceptions about how the option works, and difference of
opinions about how they should work in the future.

I started:
https://www.mediawiki.org/wiki/Requests_for_comment/Login_security

It would be great to get feedback on the "Longer Term Questions" section.
Also, if anyone isn't entirely clear about how the preferences work,
hopefully this will provide some clarification.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Veracity check for Tech news #34

[Brian Wolff]

On 8/23/13, Guillaume Paumier  wrote:
> Hi,
>
> It would be great if a few pairs of eyes could take a look at
> https://meta.wikimedia.org/wiki/Tech/News/2013/34 before I send it to
> translators, to check that I haven't missed anything super-important
> or misunderstood what the commits are about.
>
> The tech newsletter is aimed at non-expert Wikimedians whose knowledge
> of English may be limited, so the language may seem vague or naive to
> developers. If you see factual errors, please correct them (or let me
> know directly), but please keep the language simple :)
>
> Many thanks for your help.
>
> --
> Guillaume Paumier
> Technical Communications Manager — Wikimedia Foundation
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Note there's two issues with file redirects. The one fixed also
applies to local images in addition to foreign issues. The fixed issue
is that redirects on commons didn't start to work until 24 hours after
they are created. The issue that still remains is after a file moves,
someone has to edit the page (or purge the page) of the page using the
redirected name, before the image works again. (I've submitted a patch
for that - https://gerrit.wikimedia.org/r/#/c/80135/ but its still
pending review).

--bawolff

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

Re: [Wikitech-l] Weighted random article

[Bináris]

2013/8/23 Lars Aronsson 

> A naive approach would be
> to ask for a random article that wasn't created by a
> bot, but this is not to the point. Users want bot
> generated articles to come up, only not so often.


Unfortunately, there is no exact measure of the human or bot factor of the
creator of an article, and I have long been sad because of this. Botness of
an editor is only stored in recent changes table for a while, and cannot be
retrieved from page history.

Tell me if I am out of date, and I will open a glass of champagne at once.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia's anti-surveillance plans: site hardening

[Faidon Liambotis]

On Fri, Aug 23, 2013 at 06:53:29AM -0700, Bry8 Star wrote:

At my first few small-scale implementations, i did not pay attention
to rate-limiting techniques, then i realized its importance over time.


RRL support for gdnsd is being tracked upstream at:
https://github.com/blblack/gdnsd/issues/36
(filed by yours truly, 7 months ago; Brandon has left some really good 
and large responses there)


You're right that it's a prerequisite to DNSSEC support, due to the 
large DNSSEC responses -and more importantly, for tiny queries- being 
appealing to DNS amplification attackers.


Thanks,
Faidon

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

Re: [Wikitech-l] OAuth

[Chris Steipp]

On Fri, Aug 23, 2013 at 8:59 AM, Petr Bena  wrote:

> I am just wondering if we really need so complicated names like
>
> [[Special:MWOAuthManageMyGrants]]
>
> Couldn't it be just [[Special:MWOAuthManage]]
>
> or  [[Special:MWOAuthGrants]]
>
>
I think it would make sense. Could you open an enhancement bug so we don't
loose track of it?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth

[Chris Steipp]

On Fri, Aug 23, 2013 at 7:38 AM, Nicolas Vervelle wrote:

> > The best workaround now is probably to have each user register their copy
> > of your desktop application as its own consumer. It's a little ugly
> having
> > to give your user instructions on cutting and pasting tokens and keys
> > around, but it can work (in the early days of Salesforce, several OAuth
> > apps were configured this way).
> >
>
> Seems very complex for users, so I won't go that way for WPCleaner.
> Is it possible to use only one client, with the secret key included in the
> distribution ?
> (A user with enough determination will be able to extract it)
> This would mean that there's not 100% certainty about the client being the
> true one.
> But, the attacker would only be able to impersonate the application, not
> the user.


Unfortunately, no. This is one of the subtleties of OAuth 1. Since we don't
require HTTPS for getting the user token, or using a user token, it's
possible to impersonate a user by compromising the consumer's secret key if
the attacker has also been able to sniff traffic generated by that consumer
also.

It does sound like the current iteration of the extension may not be the
best fit. But it's good to know about these use cases, so we can set
priorities for future development.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Veracity check for Tech news #34

[Greg Grossmeier]

> My first thought when reading "You can now use new styles of galleries and
> give feedback to User:Bawolff." was "We couldn't give feedback to Bawolff
> before?"
> 
> Also, is it worth mentioning the pending resolution of bug 39653, currently
> scheduled for next week and in test on test wikis and mediawiki.org now?

Which is about enabling CodeEditor for JS/CSS.

Yes, we should. I was going to highlight that in my deploy highlights
email this afternoon.

I'll also being doing a quick once over of the changes included in wmf14
and highlighting the more important/interesting changes.

I wasn't able to get to the Roadmap update last week (you can see the
raw diff here, I just didn't have time to turn it into paragraphs:
https://www.mediawiki.org/w/index.php?title=Roadmap&diff=765438&oldid=748215
), but would that be something people want in the TechNews as well?

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

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

Re: [Wikitech-l] Veracity check for Tech news #34

[Brad Jorsch (Anomie)]

My first thought when reading "You can now use new styles of galleries and
give feedback to User:Bawolff." was "We couldn't give feedback to Bawolff
before?"

Also, is it worth mentioning the pending resolution of bug 39653, currently
scheduled for next week and in test on test wikis and mediawiki.org now?


On Fri, Aug 23, 2013 at 11:36 AM, Guillaume Paumier
wrote:

> Hi,
>
> It would be great if a few pairs of eyes could take a look at
> https://meta.wikimedia.org/wiki/Tech/News/2013/34 before I send it to
> translators, to check that I haven't missed anything super-important
> or misunderstood what the commits are about.
>
> The tech newsletter is aimed at non-expert Wikimedians whose knowledge
> of English may be limited, so the language may seem vague or naive to
> developers. If you see factual errors, please correct them (or let me
> know directly), but please keep the language simple :)
>
> Many thanks for your help.
>
> --
> Guillaume Paumier
> Technical Communications Manager — Wikimedia Foundation
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth

[Petr Bena]

I am just wondering if we really need so complicated names like

[[Special:MWOAuthManageMyGrants]]

Couldn't it be just [[Special:MWOAuthManage]]

or  [[Special:MWOAuthGrants]]



On Fri, Aug 23, 2013 at 5:52 PM, Brad Jorsch (Anomie)
 wrote:
> On Fri, Aug 23, 2013 at 10:38 AM, Nicolas Vervelle wrote:
>
>> On Wed, Aug 21, 2013 at 5:04 PM, Chris Steipp 
>> wrote:
>>
>> > For bots too, I'd like to have the extension implement something like
>> >
>> https://developers.google.com/accounts/images/OauthUX_nocallback.pngdirectly
>> > in the extension, but that wasn't something we were able to finish before
>> > this release.
>>
>> Ok, so unless there's a mechanism to work without callback URL, there's no
>> way for a desktop application to work.
>> I something like that is implemented, I will look again at OAuth for
>> WPcleaner.
>>
>
> https://gerrit.wikimedia.org/r/#/c/80569/
>
>
> --
> Brad Jorsch (Anomie)
> Software Engineer
> 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] OAuth

[Brad Jorsch (Anomie)]

On Fri, Aug 23, 2013 at 10:38 AM, Nicolas Vervelle wrote:

> On Wed, Aug 21, 2013 at 5:04 PM, Chris Steipp 
> wrote:
>
> > For bots too, I'd like to have the extension implement something like
> >
> https://developers.google.com/accounts/images/OauthUX_nocallback.pngdirectly
> > in the extension, but that wasn't something we were able to finish before
> > this release.
>
> Ok, so unless there's a mechanism to work without callback URL, there's no
> way for a desktop application to work.
> I something like that is implemented, I will look again at OAuth for
> WPcleaner.
>

https://gerrit.wikimedia.org/r/#/c/80569/


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Veracity check for Tech news #34

[Guillaume Paumier]

Hi,

It would be great if a few pairs of eyes could take a look at
https://meta.wikimedia.org/wiki/Tech/News/2013/34 before I send it to
translators, to check that I haven't missed anything super-important
or misunderstood what the commits are about.

The tech newsletter is aimed at non-expert Wikimedians whose knowledge
of English may be limited, so the language may seem vague or naive to
developers. If you see factual errors, please correct them (or let me
know directly), but please keep the language simple :)

Many thanks for your help.

-- 
Guillaume Paumier
Technical Communications Manager — Wikimedia Foundation

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

Re: [Wikitech-l] Weighted random article

[C. Scott Ananian]

On Fri, Aug 23, 2013 at 9:24 AM, Lord_Farin wrote:

> The probability of displaying a "bad" page would be:
>
> B q ((p B)^N - 1) / (p B - 1) + B (p B)^N
>
> (modulo errors), where B is the fraction of bad pages, p is the
> probability of repeating, q is the probability of displaying (so p+q =
> 1), and N is the allowed number of repetitions.
>

I'm going to rewrite that as:
B (1-p) ((p B)^N - 1) / (p B - 1) + B (p B)^N
...and I'm also going to take your word on the math, because my brain is
lazy this morning.

Let's run the numbers, assuming the 500,000 articles Swedish wiki had in
Sept 2012 were all good, and the million articles added since are all bad.
 Thus B = 2/3.  Let's start with N at 5, so worse case we're going to be
doing 5x as many SQL queries.  p is the tunable parameter.  So if:
 p = 0prob of getting a bad page = 67% (sanity check, this is what
they've got now)
 p = 0.5 prob of getting a bad page = 50%
 p = 0.75 prob of getting a bad page = 34%
 p = 0.80 prob of getting a bad page = 30%
 p = 0.90 prob of getting a bad page = 20%
 p = 0.95 prob of getting a bad page = 15%
 p = 1.00 prob of getting a bad page = 9% (this is set by N)

If you let N go up to 10, then:
 p = 0.90 prob of getting a bad page = 17%
 p = 0.95 prob of getting a bad page = 10%
 p = 1.00 prob of getting a bad page =  1%

My expectation that about a 10% chance of getting a 'bad page' would make
Swedish wikipedians happy, so I'd recommend p=1 N=5.  But the knobs can be
twiddled.
  --scott

-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth

[Nicolas Vervelle]

On Wed, Aug 21, 2013 at 5:04 PM, Chris Steipp  wrote:

> On Wed, Aug 21, 2013 at 2:05 AM, Nicolas Vervelle  >wrote:
>
> > Hi,
> >
> > I'm completely new to OAuth, so bear with me if my questions are basic
> or I
> > missed a point ;-)
> > It seems interesting, but seems very oriented for web applications, not
> so
> > much for desktop applications.
> >
>
> This is true, for exactly the reason you were asking about-- the secret key
> needs to be kept private, which is impossible when you distribute the
> application to other users. OAuth 2 has a framework for dealing with this,
> but it makes controlling consumers nearly impossible. So we wanted to start
> with OAuth 1 while everyone gets familiar with the concepts, and we see
> which use cases actually get used. We may extend the framework to allow
> situations like this in the future.
>
> The best workaround now is probably to have each user register their copy
> of your desktop application as its own consumer. It's a little ugly having
> to give your user instructions on cutting and pasting tokens and keys
> around, but it can work (in the early days of Salesforce, several OAuth
> apps were configured this way).
>

Seems very complex for users, so I won't go that way for WPCleaner.
Is it possible to use only one client, with the secret key included in the
distribution ?
(A user with enough determination will be able to extract it)
This would mean that there's not 100% certainty about the client being the
true one.
But, the attacker would only be able to impersonate the application, not
the user.



> >
> > I'm interested in developing this for WPCleaner [1], which is a desktop
> > application.
> > Is the callback URL required ? If so, which one should you use for a
> > desktop application ?
> >
>
> For bots too, I'd like to have the extension implement something like
> https://developers.google.com/accounts/images/OauthUX_nocallback.pngdirectly
> in the extension, but that wasn't something we were able to finish before
> this release.
>

Ok, so unless there's a mechanism to work without callback URL, there's no
way for a desktop application to work.
I something like that is implemented, I will look again at OAuth for
WPcleaner.

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

Re: [Wikitech-l] Wikimedia's anti-surveillance plans: site hardening

[Bry8 Star]

1st wrote large response, while i was still in midst of reading
various responses, when i've seen last few responses which have
touched many important factors related to very large scale sites,
and that wikipedia want to keep geo-location & geo-feature based
separation(s), then removed various paragraph that are unnecessary.

Most users have no experience in such (large scale or geo-location
based implementations) areas, neither do i.

For (compared to very) small scale sites, i faced such problem(s) :
At my first few small-scale implementations, i did not pay attention
to rate-limiting techniques, then i realized its importance over time.

So before adding DNSSEC 1st, and then upgrade into DNSSEC+DANE in
2nd, ...  Admin(s) for sites with large user-base, must work early
on DNS rate-limiting solutions, various approaches should be tested
and applied first.  Some type of dynamic and elastic set of ranges
need to be implemented, based on previous data of daily or weekly
loads.  And it has to be "adaptive" as well, when it comes to a
situation when same (or same set of) IP-address is sending multiple
DNSSEC queries, too frequently.

When more understanding and discussion are carried on that
(rate-limiting), and better techniques are found and/or developed
for very large scale site(s), then implementing large scale DNSSEC
will be easier, or else it will remain scary/fearful.

Since my implementations cases are much much much smaller, i was
able to do in different order, first added dnssec, then dane, then
applied rate-limiting techniques.  When initially i've set much
lower ranges, then observed many initial queries were failing from
client sides, so had to increase that set of ranges. For small-scale
site(s), that worked out very fine.

In some areas (northern EU countries), DNSSEC has already reached
more than 60% usage, in those area's wikipedia servers should be
attempted first, for initial test cases, that should help (i guess).
 It is very unfortunate, here(USA) we are much much behind in many
real human-friendly techniques/products/systems.

-- Bright Star.



Received from Faidon Liambotis, on 2013-08-17 3:47 AM:
> On Fri, Aug 16, 2013 at 08:04:24PM -0400, Zack Weinberg wrote:
>> Hi, I'm a grad student at CMU studying network security in general 
>> and censorship / surveillance resistance in particular. I also used 
>> to work for Mozilla, some of you may remember me in that capacity. My 
>> friend Sumana Harihareswara asked me to comment on Wikimedia's plans 
>> for hardening the encyclopedia against state surveillance.
>> 
> 
> First of all, thanks for your input. It's much appreciated. As I'm sure 
> Sumanah has already mentioned, all of our infrastructure is being 
> developed in the open using free software and we'd be also very happy to 
> accept contributions in code/infrastructure-as-code as well.
> 
> That being said, literally everything in your mail has been already 
> considered and discussed multiple times :), plus a few others you didn't 
> mention (GCM ciphers, OCSP stapling, SNI & split certificates, 
> short-lived certificates, ECDSA certificates).  A few have been 
> discussed on wikitech, others are under internal discussion & 
> investigation by some of us with findings to be posted here too when we 
> have something concrete.
> 
> I don't mean this to sound rude, but I think you may be oversimplifying 
> the situation quite a bit.
> 
> Enabling HTTPS for everyone on a website our scale isn't a trivial thing 
> to do. Besides matters of policy -blocking Wikipedia in China isn't 
> something that can be lightly done- there are significant technical 
> restrictions. Just to lay a few examples here: there is no software that 
> can both do both SPDY and take as input the key for encrypting SSL 
> session tokens, something that's needed if you need a cluster of 
> load-balancers (you also need to rotate it periodically; a lot of people 
> miss this). There is no software out there than support both having a 
> shared SSL session cache and also do SPDY[1]. etc.
> 
> DANE is great and everything but there's no software availalble that 
> satisfies our GeoDNS requirements *and* supports DNSSEC. I know, I've 
> tried them all. Traditional DNSSEC signing proxies (e.g.  OpenDNSSEC) 
> don't work at all with DNSSEC. (FWIW, we're switching to gdnsd which has 
> a unique set of characteristics and whose author Brandon Black was hired 
> in the ops team shortly after we decided to switch to gdnsd.)
> 
> Plus, DNSSEC has only a marginal adoption client-side (and DANE has none 
> yet) and has important side effects. For example, you're more likely to 
> be used as a source for DNS amplification attacks as your responses get 
> larger. More importantly though, you're breaking users, something that 
> needs to be carefully weighted with the benefits.
> 
> If you need numbers, this is from a paper from USENIX Security '13 last 
> week titled "Measuring the Practical Impact of DNSSEC Deployment"[2]:
>

Re: [Wikitech-l] Weighted random article

[Lord_Farin]

The probability of displaying a "bad" page would be:

B q ((p B)^N - 1) / (p B - 1) + B (p B)^N

(modulo errors), where B is the fraction of bad pages, p is the
probability of repeating, q is the probability of displaying (so p+q =
1), and N is the allowed number of repetitions.
--
LF


On 23 August 2013 14:37, C. Scott Ananian  wrote:
> This "make a second draw" approach would also let you tune how often you
> saw the "bad" articles.  That is, if it's a bad article, then flip a coin
> to see if you should make a second draw.  Repeat if the new article is bad,
> but never make more than N draws.  Someone with time on their hands and a
> statistical bent could compute how often "good" and "bad" articles come up
> as a function of the ratio of good and bad articles, the coin flip
> probability, and the limit N.
>   --scott
> On Aug 22, 2013 10:47 PM, "Lars Aronsson"  wrote:
>
>> On 08/23/2013 03:57 AM, Tim Starling wrote:
>>
>>> An approximation would be to select, say, 100 articles from the
>>> database using page_random, then calculate a weight for each of those
>>> 100 articles using complex criteria, then do a weighted random
>>> selection from those 100 articles.
>>>
>>
>> Interesting. An even easier/coarser approximation
>> would be to make a second draw only when the
>> first draw doesn't meet some criteria (e.g.
>> bot-created, shorter than L bytes, lacks illustration).
>>
>> On an average day, Special:Random (and its
>> translation Special:Slumpsida) seems to be
>> called some 9000 times on sv.wikipedia
>>
>>
>> --
>>   Lars Aronsson (l...@aronsson.se)
>>   Aronsson Datateknik - http://aronsson.se
>>
>>
>>
>> __**_
>> 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] Weighted random article

[C. Scott Ananian]

This "make a second draw" approach would also let you tune how often you
saw the "bad" articles.  That is, if it's a bad article, then flip a coin
to see if you should make a second draw.  Repeat if the new article is bad,
but never make more than N draws.  Someone with time on their hands and a
statistical bent could compute how often "good" and "bad" articles come up
as a function of the ratio of good and bad articles, the coin flip
probability, and the limit N.
  --scott
On Aug 22, 2013 10:47 PM, "Lars Aronsson"  wrote:

> On 08/23/2013 03:57 AM, Tim Starling wrote:
>
>> An approximation would be to select, say, 100 articles from the
>> database using page_random, then calculate a weight for each of those
>> 100 articles using complex criteria, then do a weighted random
>> selection from those 100 articles.
>>
>
> Interesting. An even easier/coarser approximation
> would be to make a second draw only when the
> first draw doesn't meet some criteria (e.g.
> bot-created, shorter than L bytes, lacks illustration).
>
> On an average day, Special:Random (and its
> translation Special:Slumpsida) seems to be
> called some 9000 times on sv.wikipedia
>
>
> --
>   Lars Aronsson (l...@aronsson.se)
>   Aronsson Datateknik - http://aronsson.se
>
>
>
> __**_
> 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