Hi!
> Couldn't the stats job you want run on toolserver?
Really, this isn't much of foundation-l issue - we have been
collecting and providing detailed article viewership statistics for
over a year.
People are building various applications on top of that data, like
http://wikirank.com/en/Jim
Couldn't the stats job you want run on toolserver?
Peter Gervai wrote:
> Hello,
>
> I wasn't subscribed to this list, since I usually try to avoid the
> politics around.
>
> I was notified, however, that some interesting claims were made and
> some steps taken (again) without any discussion what
Hi!
> Assuming you're not taking this out of context, please explain the
> difference between how it works and my conception of how it works.
Sorry, I misread your statement. I took "Volunteer admins" as
"Volunteer sysadmins" - my greatest apology.
BR,
Domas
__
On Sun, Jun 7, 2009 at 11:17 AM, Domas Mituzas wrote:
>
>
> And, Brian,
> > Volunteer admins cannot take user privacy into their own hands,
> > under their
> > own interpretation. That's just not how it works!
>
>
> You don't seen to have sufficient understanding how it works. :(
>
>
> Domas
>
As
Hello,
> If I were to compile a wishlist of stats things:
> 1. stats.grok.se data for non-Wikipedia projects
the raw data is available, anyone can build anything like that, as
long as they have resources. I've suggested Henrik to opensource his
software, but probably it suffers from "not nice
Hi!
> I believe there was no such claim, if anything, it was pointed out
> that
> setting up the stats engine didn't give access to information that
> was not
> accessible before by the Checkusers (even if logged), and that most
> fears of
> data being handled by the wrong hands are mitigate
Hi!
> Are the developers lawyers?
IANAL.
> A developer claiming something has an
> unwanted privacy issue is very different from making claims about
> something being a legal issue on the behalf of Foundation. Simply
> don't
> do it.
I failed to phrase what I wanted to write you in a way, tha
I'm going off of statements like this:
" I happen to be the one who have created the Hungarian checkuser policy,
which is, as far as I know, the strictest one in WMF projects, and it's no
joke, and I intend to follow it."
On Sun, Jun 7, 2009 at 11:13 AM, Bence Damokos wrote:
> This might be goi
This might be going off topic, and not really helpful in finding a solution
(along the lines of wamping up WMF stats capabilities in the near future or
reinstating the huwiki solution in a way accpetable to the WMF and the hu.wp
community and possibly benefitting other communities, as well):
On Su
Just to be clear, it has been claimed in this thread that the CheckUser
right also gives those admins the right to collect additional data on users
and analyze it. I've just read the privacy policy and that is not true.
You'll also find [[Privacy policy]] interesting, although you might decide
to
It is a WMF legal issue, in addition to being a social issue. No "claim" is
being made that its a legal issue, it's just a fact.
On Sun, Jun 7, 2009 at 2:43 AM, John at Darkstar wrote:
> Discussing something as a general social concern is one thing, claiming
> that it is a wmf legal issue is som
Discussing something as a general social concern is one thing, claiming
that it is a wmf legal issue is something different.
John
Michael Snow skrev:
> John at Darkstar wrote:
>> Are the developers lawyers? A developer claiming something has an
>> unwanted privacy issue is very different from maki
John at Darkstar wrote:
> Are the developers lawyers? A developer claiming something has an
> unwanted privacy issue is very different from making claims about
> something being a legal issue on the behalf of Foundation. Simply don't
> do it.
>
Privacy is not simply a legal issue, it's a general
Are the developers lawyers? A developer claiming something has an
unwanted privacy issue is very different from making claims about
something being a legal issue on the behalf of Foundation. Simply don't
do it.
John
Brian skrev:
> Or by one of the WMF developers removing the web bug.
>
> 2009/6/6
Or by one of the WMF developers removing the web bug.
2009/6/6 John at Darkstar
> You can make claims about what you yourself wants or believe, but do
> *not* claim that your personal beliefs reflects legal issues for
> Foundation. If Foundation needs to make claims about what is and whats
> not
You can make claims about what you yourself wants or believe, but do
*not* claim that your personal beliefs reflects legal issues for
Foundation. If Foundation needs to make claims about what is and whats
not a legal issue, then such claims should be made by Mike.
John
Brian skrev:
> I also have
The strange thingh is, some such servers seems to be outside discussion
while others are not. ;)
John
Tisza Gergő skrev:
> Nathan writes:
>
>> Others have since discussed more centralised and secure methods for
>> providing these statistics via the WMF - this is the ideal outcome, and one
>> th
* clap - clap *
John
Peter Gervai skrev:
> Hello,
>
> I wasn't subscribed to this list, since I usually try to avoid the
> politics around.
>
> I was notified, however, that some interesting claims were made and
> some steps taken (again) without any discussion whatsoever.
>
> First, let me tel
I also have not seen a clear explanation of what those who would like to
generate statistics using web bugs plan to do with that data. How do they
plan to use the data, and why aren't the plethora of statistics now made
officially available by the WMF not satisfactory?
You have bypassed the correc
This is another e-mail on this subject that just strikes me as flawed. These
are not vague privacy fears - they are real privacy fears. I see a
fundamental failure by those involved in this controversy to understand this
point.
On Sat, Jun 6, 2009 at 1:31 AM, Tisza Gergő wrote:
> Robert Rohde w
On Sat, Jun 6, 2009 at 3:05 AM, Robert Rohde wrote:
> On Fri, Jun 5, 2009 at 4:30 PM, Peter Gervai wrote:
>
> >> The community cannot decide that Random_user1
> >> and Random_user2 etc will agree with the communities view on the stats
> being
> >> passed to an external server.
> >
> > As you are
On Sat, Jun 6, 2009 at 12:30 AM, Peter Gervai wrote:
> Just a few sidenotes now.
>
> 2009/6/5 Mark (Markie) :
>
> > There are a few issues with this. Devs have access to logs on WMF
> servers,
> > not random external servers.
>
> This is a good suggestion, basically you say that I should request
On Sat, Jun 6, 2009 at 12:12 AM, Tisza Gergő wrote:
> Aryeh Gregor writes:
>
> > I believe the major problems with the script are
> >
> > 1) It sent data to a server not directly controlled by the Wikimedia
> > Foundation. No personally identifiable information should be sent in
> > bulk to any
I don't think that "any random admin on one of the projects should be able
to insert a web bug into
Common.js" is what he suggests. The Hungarian situation seems to have been
in place with support of the hungarian community, at least at start.
Frankly, I'd rather see private sensitive data on an
On Fri, Jun 5, 2009 at 8:46 PM, Samuel Klein wrote:
> Peter said that he could run whatever was being done on an external
> server on a WMF machine that [core] developers have access to. What
> does this have to do with being Foundation staff?
He is trying rationalize his previous behavior by
Michael Snow writes:
> Maybe it's just the lawyer in me, but I read those comments primarily as
> a defense against a perceived "prosecution" for allegedly violating the
> privacy policy.
I don't read them that way - rather as saying "This isn't clearly in
violation; it has been working for a long
On Fri, Jun 5, 2009 at 6:22 PM, Tisza Gergő wrote:
> Tisza Gergő writes:
>> I do argue that it is not in violation of the privacy policy (whether
>> the people here find it acceptable is another question).
>
> Just to make it clear, I don't think accordance with the privacy policy
> automatically
On Fri, Jun 5, 2009 at 4:30 PM, Peter Gervai wrote:
>> The community cannot decide that Random_user1
>> and Random_user2 etc will agree with the communities view on the stats being
>> passed to an external server.
>
> As you are aware it's not really random user, so what you write is
> more rhetor
This argument - which is effectively that community members should be
considered Wikimedia Foundation staff members - is very brittle. It is
neither sound nor valid. Do yourself a favor and consider the logic of the
other side. It will save you from confusion later when you realize that you
were th
Just a few sidenotes now.
2009/6/5 Mark (Markie) :
> There are a few issues with this. Devs have access to logs on WMF servers,
> not random external servers.
This is a good suggestion, basically you say that I should request the
foundation to provide me a server inside WMF with developer acces
Aryeh Gregor wrote:
> On Fri, Jun 5, 2009 at 5:22 PM, Michael Snow wrote:
>
>> As I understand it, nobody is arguing that it's considered acceptable at
>> this point.
>>
> Peter Gervai seemed to argue exactly that, unless I badly misread him:
>
>
> And so did Tisza Gergő:
>
Maybe it's ju
On Fri, Jun 5, 2009 at 5:58 PM, Tisza Gergő wrote:
> I do argue that it is not in violation of the privacy policy (whether the
> people
> here find it acceptable is another question).
It may be within the letter of the privacy policy. I think that's
entirely arguable, since the policy is so vagu
Michael Snow writes:
> As I understand it, nobody is arguing that it's considered acceptable at
> this point. People involved in the Hungarian Wikipedia have been
> explaining the background, trying to establish that they shouldn't be
> blamed for having this in place. That's understandable as
On Fri, Jun 5, 2009 at 4:44 PM, Tisza Gergő wrote:
> Mark (Markie writes:
>
> > I still fail to see how, at this point (not before when there was no
> policy)
> > this can be considered to be acceptable. IP information etc is still
> being
> > passed to an external server, regardless of who it
On Fri, Jun 5, 2009 at 5:22 PM, Michael Snow wrote:
> As I understand it, nobody is arguing that it's considered acceptable at
> this point.
Peter Gervai seemed to argue exactly that, unless I badly misread him:
> someone from outside seriously interfere with other project
> based on, as it turns
Apologies for this, I'm getting confused between multiple threads on this.
Regards
Mark
On Fri, Jun 5, 2009 at 10:22 PM, Michael Snow wrote:
> Mark (Markie) wrote:
> > I still fail to see how, at this point (not before when there was no
> policy)
> > this can be considered to be acceptable.
> A
Mark (Markie) wrote:
> I still fail to see how, at this point (not before when there was no policy)
> this can be considered to be acceptable.
As I understand it, nobody is arguing that it's considered acceptable at
this point. People involved in the Hungarian Wikipedia have been
explaining the b
On Fri, Jun 5, 2009 at 9:49 PM, Tisza Gergő wrote:
> Bence Damokos writes:
>
> > I'd like to note in the interest of facts that the Huwp stats have been
> > implemented (without complaint till now, June 2009) since October 2006;
> the
> > current version of the privacy policy has been available
And that without any complain from 2005 onward (practically from the
beginning of huwiki's real existence).
B.
-Original Message-
It is linked from the statistics page and other relevant places, not exactly
a secret.)
__ ESET Smart Security - Vírusdefiníciós adatbázis: 4134
effe iets anders wrote:
> 2009/6/5 Peter Gervai
>
>>
>> The stats (which have, by surprise, a dedicated domain under th hu
>> wikipedia domain) runs on a dedicated server, with nothing else on it.
>> Its sole purpose to gather and publish the stats. Basically nobody
>> have permission to log in
2009/6/5 Peter Gervai
>
> The stats (which have, by surprise, a dedicated domain under th hu
> wikipedia domain) runs on a dedicated server, with nothing else on it.
> Its sole purpose to gather and publish the stats. Basically nobody
> have permission to log in the servers but me, and I since I
I'd like to note in the interest of facts that the Huwp stats have been
implemented (without complaint till now, June 2009) since October 2006; the
current version of the privacy policy has been available in English since
October 2008.
I think it might not be very productive to judge the action of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nathan wrote:
> I can understand your frustration, Peter, but perhaps hu.wp could also have
> taken a more collaborative approach. If you would like to use a method for
> collecting statistics that others will view as violating the privacy policy,
> or
I can understand your frustration, Peter, but perhaps hu.wp could also have
taken a more collaborative approach. If you would like to use a method for
collecting statistics that others will view as violating the privacy policy,
or as presenting risks normally not considered throughout the rest of t
On Fri, Jun 5, 2009 at 2:14 AM, John at Darkstar wrote:
> Its not that it won't be perfect, it simply will not work.
It will in most cases if you don't mind some false positives. False
positives would be acceptable if it's just a warning page that the
admin could click through. Check for anythin
Thomas Dalton wrote:
> 2009/6/5 Neil Harris :
>
>> Thomas Dalton wrote:
>>
>>> 2009/6/4 Jon :
>>>
>>>
Has apache/proxy level filtering been considered?
>>> Filtering for what? Javascript is executed client-side, ie. after the
>>> page has gone through the apac
John at Darkstar wrote:
>
> Alex skrev:
>> John at Darkstar wrote:
Hmm? There's no reason to do anything like that. The AbuseFilter would
just prevent sitewide JS pages from being saved with the particular URLs
or a particular code block in them. It'll stop the well-meaning but
Alex skrev:
> John at Darkstar wrote:
>>> Hmm? There's no reason to do anything like that. The AbuseFilter would
>>> just prevent sitewide JS pages from being saved with the particular URLs
>>> or a particular code block in them. It'll stop the well-meaning but
>>> misguided admins. Short of rest
John at Darkstar wrote:
>> Hmm? There's no reason to do anything like that. The AbuseFilter would
>> just prevent sitewide JS pages from being saved with the particular URLs
>> or a particular code block in them. It'll stop the well-meaning but
>> misguided admins. Short of restricting site JS to t
>
> Hmm? There's no reason to do anything like that. The AbuseFilter would
> just prevent sitewide JS pages from being saved with the particular URLs
> or a particular code block in them. It'll stop the well-meaning but
> misguided admins. Short of restricting site JS to the point of
> uselessnes
>
> Is this enough? Of course not, there is so much more to learn.
>
>
> Erik Zachte
>
There are a few very important missing items for the moment
* Number of unique visitors
* Number of page visits per visitors
All should be analyzed on user roles, possibly also on different time
spans (ho
John at Darkstar wrote:
>> One idea is the proposal to install the AbuseFilter in a global mode,
>> i.e. rules loaded at Meta that apply everywhere. If that were done
>> (and there are some arguments about whether it is a good idea), then
>> it could be used to block these types of URLs from being
> On Thu, Jun 4, 2009 at 6:20 AM, John at Darkstar wrote:
>> User privacy on Wikipedia is is close to a public hoax, pages are
>> transfered unencrypted and with user names in clear text. Anyone with
>> access to a public hub is able to intercept and identify users, in
>> addition to _all_ website
On Jun 4, 2009, at 11:27 PM, John at Darkstar wrote:
>> Not to mention, as
>> far as I know the program is proprietary.
>
> This is an example of whats the real problem here; its not the
> security
> issues but the users political issues.
I fail to see what that has to do with anything. I'm ju
> One idea is the proposal to install the AbuseFilter in a global mode,
> i.e. rules loaded at Meta that apply everywhere. If that were done
> (and there are some arguments about whether it is a good idea), then
> it could be used to block these types of URLs from being installed,
> even by admin
> Not to mention, as
> far as I know the program is proprietary.
This is an example of whats the real problem here; its not the security
issues but the users political issues.
> I'm not convinced that
> we need to be tracking user behavior at this point in time, or that
> the tradeoffs for
Neil Harris wrote:
> John at Darkstar wrote:
>
>> The interesting thing is "who has interest in which users identity".
>> Lets make an example, some organization sets up a site with a honeypot
>> and logs all visitors. Then they correlates that with RC-logs from
>> Wikipedia and then checks out
2009/6/5 Neil Harris :
> Thomas Dalton wrote:
>> 2009/6/4 Jon :
>>
>>> Has apache/proxy level filtering been considered?
>>>
>>
>> Filtering for what? Javascript is executed client-side, ie. after the
>> page has gone through the apache servers/proxies.
>>
>
> Filtering to remove _all_ Javascript,
Thomas Dalton wrote:
> 2009/6/4 Jon :
>
>> Has apache/proxy level filtering been considered?
>>
>
> Filtering for what? Javascript is executed client-side, ie. after the
> page has gone through the apache servers/proxies.
>
Filtering to remove _all_ Javascript, other than references to
2009/6/4 Erik Zachte :
> Considering web bugs: comScore also proposed such a scheme to us.
> Apart from the question how much it would bring us that we don't or can't
> figure out ourselves an overriding concern is privacy.
So if we ran our own internal web bug mechanism, with due attention to
p
David Gerard wrote:
> 2009/6/4 Robert Rohde :
>
>> Aryeh Gregor wrote:
>>
>>> However, perhaps a default AbuseFilter could be installed telling
>>> admins that installing Analytics is a violation of Foundation policy
>>> and that they'll get desysopped if they continue. That wouldn't stop
2009/6/4 Unionhawk :
> So how do you propose we enforce this? I'm thinking we need to prevent this
> from happening in the first place. Analytics like this could pretty much
> give checkuser powers to anybody!
There's not that many places where this sort of thing could be
implemented - would it
2009/6/4 Robert Rohde :
> On Thu, Jun 4, 2009 at 10:44 AM, Aryeh Gregor
> wrote:
>> However, perhaps a default AbuseFilter could be installed telling
>> admins that installing Analytics is a violation of Foundation policy
>> and that they'll get desysopped if they continue. That wouldn't stop
>
On Thu, Jun 4, 2009 at 10:44 AM, Aryeh Gregor
wrote:
> On Thu, Jun 4, 2009 at 12:53 PM, Robert Rohde wrote:
>> One idea is the proposal to install the AbuseFilter in a global mode,
>> i.e. rules loaded at Meta that apply everywhere. If that were done
>> (and there are some arguments about whether
2009/6/4 Jon :
> Has apache/proxy level filtering been considered?
Filtering for what? Javascript is executed client-side, ie. after the
page has gone through the apache servers/proxies.
___
foundation-l mailing list
foundation-l@lists.wikimedia.org
Uns
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aryeh Gregor wrote:
> On Thu, Jun 4, 2009 at 6:01 AM, Neil Harris
wrote:
>> Surely this is something which should be possible to block at the
>> MediaWiki level, by suppressing the generation of any HTML that loads
>> any indirect resources (scripts,
On Thu, Jun 4, 2009 at 6:01 AM, Neil Harris wrote:
> Surely this is something which should be possible to block at the
> MediaWiki level, by suppressing the generation of any HTML that loads
> any indirect resources (scripts, iframes, images, etc.) whatsoever other
> than from a clearly defined wh
On Thu, Jun 4, 2009 at 8:35 AM, Dan Rosenthal wrote:
> Installing Google Analytics, even for our own purposes, is a bad idea.
> For one, it creates a link to google that is not necessarily what we
> want; it would be a big target for people to try and hack, and it
> presents tempting security risk
Dan Rosenthal wrote:
> Installing Google Analytics, even for our own purposes, is a bad idea.
> For one, it creates a link to google that is not necessarily what we
> want; it would be a big target for people to try and hack, and it
> presents tempting security risks on Google's end. Not to
Installing Google Analytics, even for our own purposes, is a bad idea.
For one, it creates a link to google that is not necessarily what we
want; it would be a big target for people to try and hack, and it
presents tempting security risks on Google's end. Not to mention, as
far as I know t
David Gerard wrote:
> External web bug trackers should be removed without
> exception. People who add them innocently, out of an understandable
> interest in collecting aggregated information that would not violate the
> privacy policy, should be directed to request and help with internal
> solutio
David Gerard wrote:
> Web bugs for statistical data are a legitimate want but potentially a
> horrible privacy violation.
>
> So I asked on wikitech-l, and the obvious answer appears to be to do
> it internally. Something like http://stats.grok.se/ only more so.
>
> So - if you want web bug data in
>Surely this is something which should be possible to block at the
MediaWiki level
Maybe if we set up Google Analytics in the first place (done by the
Foundation office) and never used it; the foundation could set up analytics
for all projects with a super secure password, and never use it. Will th
Web bugs for statistical data are a legitimate want but potentially a
horrible privacy violation.
So I asked on wikitech-l, and the obvious answer appears to be to do
it internally. Something like http://stats.grok.se/ only more so.
So - if you want web bug data in a way that fits the privacy pol
Nikola Smolenski wrote:
> Domas Mituzas wrote:
>
>> Do note, hu.wikipedia.org has external stats aggregator,
>> 'stats.wikipedia.hu', which is hosted on vhost102.sx6.tolna.net - and
>> all our traffic is sent there (
>> http://hu.wikipedia.org/w/index.php?title=MediaWiki:Lastmodifiedat&oldi
John at Darkstar wrote:
> The interesting thing is "who has interest in which users identity".
> Lets make an example, some organization sets up a site with a honeypot
> and logs all visitors. Then they correlates that with RC-logs from
> Wikipedia and then checks out who adds external links back t
Hi,
2009/6/4 Tisza Gergő :
> As for Doubleclick, that was probably a mistake on KnowPrivacy's part - maybe
> they misidentified the aggregator (we use awstats) because Doubleclick uses a
> similar method? If not, I would appreciate if they could serve with more
> detailed information.
Sad but tru
The Ombudsman Commission would likely be that group. Although their
focus has traditionally been CheckUser, their purview actually covers
any and all violations of the privacy policy. Here is one such case. At
this moment, I agree: this sysop shouldn't be.
-Mike
On Thu, 2009-06-04 at 06:21 -0500,
2009/6/4 Tim 'avatar' Bartel :
> I think we should stop the current use of Google Analytics ASAP.
Indeed.
For the record, we've discussed Google Analytics before:
* in July 2007, for pms.wiki - nothing implemented, I think
* in October 2007, for en.wikibooks - implemented but then stopped. at
The interesting thing is "who has interest in which users identity".
Lets make an example, some organization sets up a site with a honeypot
and logs all visitors. Then they correlates that with RC-logs from
Wikipedia and then checks out who adds external links back to
themselves. They do not need d
2009/6/4 Pedro Sanchez :
> What I propose is this being re-added would cause a removal of sysop bit due
> to misuse of powers.
> Don't we have a committee that checks privacy violations?
The Foundation would surely have this power.
- d.
___
foundati
On Thu, Jun 4, 2009 at 1:18 AM, Tim 'avatar' Bartel <
wikipe...@computerkultur.org> wrote:
> Hi,
>
> recently the report of the KnowPrivacy [1] study - a research project
> by the School of Information from University of California in Berkeley
> - hit the German media [2].
>
The case of vlswiki i
John at Darkstar wrote:
> We need tools to track user behavior inside Wikipedia. As it is now we
> know nearly nothing at all about user behavior and nearly all people
> saying anything about users at Wikipedia makes gross estimates and wild
> guesses.
>
> User privacy on Wikipedia is is close to a
Forgot a link to an article which describes very well privacy on
Wikipedia! ;)
http://en.wikipedia.org/wiki/The_Emperor%27s_New_Clothes
John at Darkstar skrev:
> We need tools to track user behavior inside Wikipedia. As it is now we
> know nearly nothing at all about user behavior and nearly all
We need tools to track user behavior inside Wikipedia. As it is now we
know nearly nothing at all about user behavior and nearly all people
saying anything about users at Wikipedia makes gross estimates and wild
guesses.
User privacy on Wikipedia is is close to a public hoax, pages are
transfered
Domas Mituzas wrote:
> Do note, hu.wikipedia.org has external stats aggregator,
> 'stats.wikipedia.hu', which is hosted on vhost102.sx6.tolna.net - and
> all our traffic is sent there (
> http://hu.wikipedia.org/w/index.php?title=MediaWiki:Lastmodifiedat&oldid=4493139
>
> - as well as few
Tim 'avatar' Bartel wrote:
> Hi,
>
> recently the report of the KnowPrivacy [1] study - a research project
> by the School of Information from University of California in Berkeley
> - hit the German media [2].
>
> It came to the conclusion that "All of the top 50 websites contained
> at least one w
Hi,
> I think we should stop the current use of Google Analytics ASAP.
I'm usually proponent of indefinite bans to people who do this, but
there are others who want milder approaches :-)
Indeed, this is violation of our privacy policy, and never should be
allowed. Thanks for headsup.
Do note
88 matches
Mail list logo
