On Sat, Jun 6, 2009 at 5:05 PM, Platonides wrote:
> Gregory Maxwell wrote:
>> It makes absolutely no sense for ES wiki to forbid a particular kind
>> of image but then allow it to be inlined unless its some file the WMF
>> couldn't legally host (and also wouldn't forbid as a part of the WP
>> conte
Gregory Maxwell wrote:
> It makes absolutely no sense for ES wiki to forbid a particular kind
> of image but then allow it to be inlined unless its some file the WMF
> couldn't legally host (and also wouldn't forbid as a part of the WP
> content).
>
> One of the main purposes in restricting non-fr
On Sat, Jun 6, 2009 at 3:31 PM, Platonides wrote:
> eswiki doesn't allow Fair Use images. It doesn't even allow loacl uploads.
> I could upload it at commons, but would be deleted in hours. Uploading
> at enwiki might be an option, but not a good one. English Wikipedia
> images are not there to se
K. Peachey wrote:
>> Taking advantage of this thread. Take a look at
>> http://es.wikipedia.org/wiki/Special:Search
>> Can those images be moved to a server under our control (WMF,
>> Toolserver...)?
>>
>> Potentially, those systems they could be retrieving the search queries
>> and ips of all visi
On Sat, Jun 6, 2009 at 9:02 AM, Platonides wrote:
> David Gerard wrote:
>> Keeping well-meaning admins from putting Google web bugs in the
>> JavaScript is a game of whack-a-mole.
>>
>> Are there any technical workarounds feasible? If not blocking the
>> loading of external sites entirely (I unders
David Gerard wrote:
> Keeping well-meaning admins from putting Google web bugs in the
> JavaScript is a game of whack-a-mole.
>
> Are there any technical workarounds feasible? If not blocking the
> loading of external sites entirely (I understand hu:wp uses a web bug
> that isn't Google), perhaps
On Fri, Jun 5, 2009 at 1:17 AM, John at Darkstar wrote:
> You don't have to inject javascript to do user tracking. This is
> possible with all kind of raw html that leads to inclusion of external
> elements, including style defs for ordinary markup.
The point on CSS is a good one. The site-wide s
You don't have to inject javascript to do user tracking. This is
possible with all kind of raw html that leads to inclusion of external
elements, including style defs for ordinary markup.
John
Daniel Kinzler skrev:
> David Gerard schrieb:
>> 2009/6/4 Gregory Maxwell :
>>
>>> Restrict site-wide JS
On Fri, Jun 5, 2009 at 1:00 AM, Gregory Maxwell wrote:
>
> What exactly are people looking for that isn't available from
> stats.grok.se that isn't a privacy concern?
A good question.
Related questions are:
1) what can't be built into stats.grok.se (or other services built on
the same data)?
2) i
Actually you can take a lesson from Google, and every once in a while
prefix all links e.g.,
"http://en.wikipedia.org/url?http://en.wikipedia.org/wiki/Norflblarg";.
(some kind of recording redirector). How do I know Google does this
every so often in their search results pages? I use
DontGet{:*://*
2009/6/4 Brian :
> That's why WMF now has a usability lab.
Yep. They'd dive on this stuff with great glee if we can implement it
without breaking privacy or melting servers.
- d.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lis
That's why WMF now has a usability lab.
On Thu, Jun 4, 2009 at 12:34 PM, David Gerard wrote:
> 2009/6/4 Brian :
>
> > How does installing 3rd party analytics software help the WMF accomplish
> its
> > goals?
>
>
> Detailed analysis of how users actually use the site would be vastly
> useful in i
On Thu, Jun 4, 2009 at 2:32 PM, David Gerard wrote:
> 2009/6/4 Gregory Maxwell :
>
>> I think the biggest problem to reducing accesses is that far more
>> mediawiki messages are uncooked than is needed. Were it not for this I
>> expect this access would have been curtailed somewhat a long time ago
2009/6/4 Brian :
> How does installing 3rd party analytics software help the WMF accomplish its
> goals?
Detailed analysis of how users actually use the site would be vastly
useful in improving the sites' content and usability.
- d.
___
Wikitech-l m
2009/6/4 Gregory Maxwell :
> I think the biggest problem to reducing accesses is that far more
> mediawiki messages are uncooked than is needed. Were it not for this I
> expect this access would have been curtailed somewhat a long time ago.
I think you've hit the actual problem there. Someone wi
On Thu, Jun 4, 2009 at 11:56 AM, Neil Harris wrote:
> However; writing a javascript sanitizer that restricted the user to a
> "safe" subset of the language, by first parsing and then resynthesizing
> the code using formal methods for validation, in a way similar to the
> current solution for TeX, w
2009/6/4 Andrew Garrett :
> When did we start treating our administrators as potentially malicious
> attackers? Any administrator could, in theory, add a cookie-stealing
> script to my user JS, steal my account, and grant themselves any
> rights they please.
That's why I started this thread talk
2009/6/4 Finne Boonen :
> On Thu, Jun 4, 2009 at 17:00, Gregory Maxwell wrote:
>> What exactly are people looking for that isn't available from
>> stats.grok.se that isn't a privacy concern?
>> I had assumed that people kept installing these bugs because they
>> wanted source network break downs
How does installing 3rd party analytics software help the WMF accomplish its
goals?
On Thu, Jun 4, 2009 at 8:31 AM, Daniel Kinzler wrote:
> David Gerard schrieb:
> > Keeping well-meaning admins from putting Google web bugs in the
> > JavaScript is a game of whack-a-mole.
> >
> > Are there any te
On Thu, Jun 4, 2009 at 12:04 PM, Andrew Garrett wrote:
>>> Is it feasible to allow admins to use raw HTML as appropriate but not
>>> raw JS? Being able to fix MediaWiki: space messages with raw HTML is
>>> way too useful on the occasions where it's useful.
>>>
>>
>> Possible yes, sensible no. Beca
On Thu, 2009-06-04 at 17:04 +0100, Andrew Garrett wrote:
> When did we start treating our administrators as potentially malicious
> attackers? Any administrator could, in theory, add a cookie-stealing
> script to my user JS, steal my account, and grant themselves any
> rights they please.
>
Thanks, that clarifies matters for me. I wasn't aware of #1, though I
guess upon reflection that makes sense.
-Mike
On Thu, 2009-06-04 at 11:07 -0400, Gregory Maxwell wrote:
> On Thu, Jun 4, 2009 at 11:01 AM, Mike.lifeguard
> wrote:
> > On Thu, 2009-06-04 at 15:34 +0100, David Gerard wrote:
> >
On 04/06/2009, at 4:08 PM, Daniel Kinzler wrote:
> David Gerard schrieb:
>> 2009/6/4 Gregory Maxwell :
>>
>>> Restrict site-wide JS and raw HTML injection to a smaller subset of
>>> users who have been specifically schooled in these issues.
>>
>>
>> Is it feasible to allow admins to use raw HTML
Neil Harris wrote:
> Daniel Kinzler wrote:
>
>> David Gerard schrieb:
>>
>>
>>> 2009/6/4 Gregory Maxwell :
>>>
>>>
>>>
Restrict site-wide JS and raw HTML injection to a smaller subset of
users who have been specifically schooled in these issues.
2009/6/4 Mike.lifeguard :
> On Thu, 2009-06-04 at 15:34 +0100, David Gerard wrote:
>
>> Then external site loading can be blocked.
>
>
> Why do we need to block loading from all external sites? If there are
> specific & problematic ones (like google analytics) then why not block
> those?
I can't t
On Thu, Jun 4, 2009 at 17:00, Gregory Maxwell wrote:
> On Thu, Jun 4, 2009 at 10:53 AM, David Gerard wrote:
>> I understand the problem with stats before was that the stats server
>> would melt under the load. Leon's old wikistats page sampled 1:1000.
>> The current stats (on dammit.lt and served
Daniel Kinzler wrote:
> David Gerard schrieb:
>
>> 2009/6/4 Gregory Maxwell :
>>
>>
>>> Restrict site-wide JS and raw HTML injection to a smaller subset of
>>> users who have been specifically schooled in these issues.
>>>
>> Is it feasible to allow admins to use raw HTML as appropri
David Gerard schrieb:
> 2009/6/4 Mike.lifeguard :
>> On Thu, 2009-06-04 at 15:34 +0100, David Gerard wrote:
>
>>> Then external site loading can be blocked.
>
>> Why do we need to block loading from all external sites? If there are
>> specific & problematic ones (like google analytics) then why n
David Gerard schrieb:
> 2009/6/4 Gregory Maxwell :
>
>> Restrict site-wide JS and raw HTML injection to a smaller subset of
>> users who have been specifically schooled in these issues.
>
>
> Is it feasible to allow admins to use raw HTML as appropriate but not
> raw JS? Being able to fix MediaW
On Thu, Jun 4, 2009 at 11:01 AM, Mike.lifeguard
wrote:
> On Thu, 2009-06-04 at 15:34 +0100, David Gerard wrote:
>
>> Then external site loading can be blocked.
>
>
> Why do we need to block loading from all external sites? If there are
> specific & problematic ones (like google analytics) then why
On Thu, Jun 4, 2009 at 10:53 AM, David Gerard wrote:
> I understand the problem with stats before was that the stats server
> would melt under the load. Leon's old wikistats page sampled 1:1000.
> The current stats (on dammit.lt and served up nicely on
> http://stats.grok.se) are every hit, but I
2009/6/4 Mike.lifeguard :
> On Thu, 2009-06-04 at 15:34 +0100, David Gerard wrote:
>> Then external site loading can be blocked.
> Why do we need to block loading from all external sites? If there are
> specific & problematic ones (like google analytics) then why not block
> those?
Because havi
2009/6/4 Gregory Maxwell :
> Restrict site-wide JS and raw HTML injection to a smaller subset of
> users who have been specifically schooled in these issues.
Is it feasible to allow admins to use raw HTML as appropriate but not
raw JS? Being able to fix MediaWiki: space messages with raw HTML is
On Thu, 2009-06-04 at 15:34 +0100, David Gerard wrote:
> Then external site loading can be blocked.
Why do we need to block loading from all external sites? If there are
specific & problematic ones (like google analytics) then why not block
those?
-Mike
_
Michael Rosenthal wrote:
> I suggest keep the bug on Wikimedia's servers and using a tool which
> relies on SQL databases. These could be shared with the toolserver
> where the "official" version of the analysis tool runs and users are
> enabled to run their own queries (so taking a tool with a goo
On Thu, Jun 4, 2009 at 10:19 AM, David Gerard wrote:
> Keeping well-meaning admins from putting Google web bugs in the
> JavaScript is a game of whack-a-mole.
>
> Are there any technical workarounds feasible? If not blocking the
> loading of external sites entirely (I understand hu:wp uses a web b
Michael Rosenthal schrieb:
> I suggest keep the bug on Wikimedia's servers and using a tool which
> relies on SQL databases. These could be shared with the toolserver
> where the "official" version of the analysis tool runs and users are
> enabled to run their own queries (so taking a tool with a g
2009/6/4 Michael Rosenthal :
> I suggest keep the bug on Wikimedia's servers and using a tool which
> relies on SQL databases. These could be shared with the toolserver
> where the "official" version of the analysis tool runs and users are
> enabled to run their own queries (so taking a tool with
I suggest keep the bug on Wikimedia's servers and using a tool which
relies on SQL databases. These could be shared with the toolserver
where the "official" version of the analysis tool runs and users are
enabled to run their own queries (so taking a tool with a good
database structure would be nic
2009/6/4 Daniel Kinzler :
> David Gerard schrieb:
>> Keeping well-meaning admins from putting Google web bugs in the
>> JavaScript is a game of whack-a-mole.
>> Are there any technical workarounds feasible? If not blocking the
> Perhaps the solution would be to simply set up our own JS based usag
David Gerard schrieb:
> Keeping well-meaning admins from putting Google web bugs in the
> JavaScript is a game of whack-a-mole.
>
> Are there any technical workarounds feasible? If not blocking the
> loading of external sites entirely (I understand hu:wp uses a web bug
> that isn't Google), perhap
Keeping well-meaning admins from putting Google web bugs in the
JavaScript is a game of whack-a-mole.
Are there any technical workarounds feasible? If not blocking the
loading of external sites entirely (I understand hu:wp uses a web bug
that isn't Google), perhaps at least listing the sites somew
42 matches
Mail list logo