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
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
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
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 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
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
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 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, 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
_
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
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
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
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
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
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
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
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
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
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.
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
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 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.
>
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
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
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
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
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 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
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
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
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
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
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{:*://*
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
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: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
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 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
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 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
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 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
42 matches
Mail list logo
