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 visitors via the
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-free
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 at
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), perhaps at
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
On Thu, Jun 4, 2009 at 10:19 AM, David Gerard dger...@gmail.com 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
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 good
2009/6/4 Mike.lifeguard mikelifegu...@fastmail.fm:
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
On Thu, Jun 4, 2009 at 10:53 AM, David Gerard dger...@gmail.com 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
On Thu, Jun 4, 2009 at 11:01 AM, Mike.lifeguard
mikelifegu...@fastmail.fm 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
David Gerard schrieb:
2009/6/4 Gregory Maxwell gmaxw...@gmail.com:
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
David Gerard schrieb:
2009/6/4 Mike.lifeguard mikelifegu...@fastmail.fm:
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
On Thu, Jun 4, 2009 at 17:00, Gregory Maxwell gmaxw...@gmail.com wrote:
On Thu, Jun 4, 2009 at 10:53 AM, David Gerard dger...@gmail.com 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
Neil Harris wrote:
Daniel Kinzler wrote:
David Gerard schrieb:
2009/6/4 Gregory Maxwell gmaxw...@gmail.com:
Restrict site-wide JS and raw HTML injection to a smaller subset of
users who have been specifically schooled in these issues.
Is it
On 04/06/2009, at 4:08 PM, Daniel Kinzler wrote:
David Gerard schrieb:
2009/6/4 Gregory Maxwell gmaxw...@gmail.com:
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
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
mikelifegu...@fastmail.fm wrote:
On Thu, 2009-06-04 at 15:34 +0100,
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.
We
How does installing 3rd party analytics software help the WMF accomplish its
goals?
On Thu, Jun 4, 2009 at 8:31 AM, Daniel Kinzler dan...@brightbyte.de wrote:
David Gerard schrieb:
Keeping well-meaning admins from putting Google web bugs in the
JavaScript is a game of whack-a-mole.
Are
2009/6/4 Finne Boonen hen...@gmail.com:
On Thu, Jun 4, 2009 at 17:00, Gregory Maxwell gmaxw...@gmail.com 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
2009/6/4 Andrew Garrett agarr...@wikimedia.org:
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
On Thu, Jun 4, 2009 at 11:56 AM, Neil Harrisuse...@tonal.clara.co.uk 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
2009/6/4 Brian brian.min...@colorado.edu:
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.
On Thu, Jun 4, 2009 at 2:32 PM, David Gerard dger...@gmail.com wrote:
2009/6/4 Gregory Maxwell gmaxw...@gmail.com:
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
That's why WMF now has a usability lab.
On Thu, Jun 4, 2009 at 12:34 PM, David Gerard dger...@gmail.com wrote:
2009/6/4 Brian brian.min...@colorado.edu:
How does installing 3rd party analytics software help the WMF accomplish
its
goals?
Detailed analysis of how users actually use the
2009/6/4 Brian brian.min...@colorado.edu:
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
25 matches
Mail list logo
