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 H
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. Probab
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 ot
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 c
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,
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 li
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
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 d
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 unblock
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,
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 logi
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 unsucce
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
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
imple
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 coun
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 Wi
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 exa
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 se
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 fro
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 Grossm
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
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,
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 w
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 m
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
> 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
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
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) checkuse
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 s
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
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 problem
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
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
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.mediawik
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 sc
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.m
>
>
>- 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
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
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
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.
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 o
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
(
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 enhancem
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
> > arou
> 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 a
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.
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 wrot
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, b
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 Wiki
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),
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 applic
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 para
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 Augus
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
st
54 matches
Mail list logo
