Talk:Privacy policy

Wikimedia Foundation Privacy Policy (discussion)

This is the talk page for discussing Wikimedia's Privacy Policy.
Please contact the Ombudsman commission if you wish to report a Privacy Policy violation.

Archives Talk:Privacy policy/Archive (for all comments made before the policy was approved by the Board in April 2005) 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2013 (2) 2014

NSA, FISC, NSL, FISAAA, PRISM...

The following discussion is closed: Closed since it looks like most of the discussion should now go to The active Safe Harbor discussion that Luis responded too. I'll leave for a bit before archiving unless it's reopened. 04:53, 7 January 2014 (UTC)

---

Localisation des serveurs aux Etats-Unis et loi applicable bis

Je demande le retrait du paragraphe Où se trouve la Fondation et qu’est-ce que ceci implique pour moi ? 78.251.243.204 19:05, 5 September 2013 (UTC)

My apologies for the response in English. If someone would be so kind as to translate this into French, I would be much obliged. Are there any particular reasons that you are requesting removal of that section? Is there any specific language that concerns you? If so, please specify. Mpaulson (WMF) (talk) 22:23, 5 September 2013 (UTC)

Traduction / translation : « Excusez-moi de répondre en anglais. Si quelqu'un avait la gentillesse de tranduire mon message en français, je lui en serai reconnaissant. Y a-t-il des raisons particulières pour que vous demandiez le retrait de cette section ? Y a-t-il une langue spécifique qui vous concerne ? Si tel est le cas, veuillez le préciser. » Jules78120 (talk) 22:37, 5 September 2013 (UTC)

Merci Mpaulson de votre réponse (et merci à Jules78120 pour sa sympathique traduction :-) ). Les raisons particulières qui me poussent à demander le retrait de cette section sont les mêmes que celle déjà développées plus haut dans la section Localisation des serveurs aux Etats-Unis et loi applicable et dans plusieurs autres sections telles par exemple que NSA, FISC, NSL, FISAAA, PRISM... Je me permets juste d'être un peu plus insistant dans ma demande, avec votre permission :-) 78.251.243.204 00:54, 6 September 2013 (UTC)

So, while we as an organization and I personally have some sizable objections to PRISM and many of the actions taken by the US government recently with regards to privacy, removing this section will not actually change the applicability of US law. The Foundation is located in the US, meaning that using our sites leads to the transfer of data to the US, and thus is subject to US law. Mpaulson (WMF) (talk) 01:09, 6 September 2013 (UTC)

Bien sûr que les serveurs sont situés aux EU et que les lois américaines s'appliquent (à ce propos, on devrait peut-être songer à redéménager les serveurs en dehors des EU !). Par contre, je ne suis pas d'accord avec la phrase « Vous consentez également au transfert de vos informations par nous depuis les États-Unis vers d’autres pays qui sont susceptibles d’avoir des lois sur la protection des données différentes ou moins contraignantes que dans votre pays, en lien avec les services qui vous sont fournis. » Je ne suis pas d'accord pour que mes données soient transmises n'importe où, y compris à des entreprises situées dans des pays où les lois autoriseraient n'importe qui à faire n'importe quoi avec. Si nos données sont transmises, elles ne doivent l'être qu'avec la garantie que nos données seront protégées au moins autant que dans notre pays, ou en tous cas au moins autant qu'aux EU. Quelque soit l'entreprise ou le pays vers lesquels sont transmises nos données, on doit s'assurer que la Charte de confidentialité soit garantie. Sinon, on ne transmet pas. La Charte n'établit, je trouve, pas ce point assez clairement (par exemple les paragraphes Si l’organisation est cédée (très peu probable !) et À nos prestataires de services manquent à mon avis de précision) 78.251.253.2 12:36, 6 September 2013 (UTC)

P.S. : EU en français = Etats-Unis = United States = US en anglais ; je m'excuse, j'aurais dû écrire Etats-Unis en toutes lettres :-) 85.170.120.230 01:51, 7 September 2013 (UTC)

Unfortunately, US privacy law is still very much developing and the EU considers the US to have less stringent data protection laws than the US. So using a Wikimedia Site means that, if you are a resident of Europe, your data is being transferred to a country with less stringent data protection laws that your country. There isn't really a way for you to use the Wikimedia Sites without consenting to that kind of transfer unfortunately. But differences in privacy regimes aside, the Wikimedia Foundation seeks to put into place contractual and technological protections with third parties (no matter what country they may be located in) if they are to receive nonpublic user information, to help ensure that their practices meet the standards of the Wikimedia Foundation's privacy policy. Mpaulson (WMF) (talk) 18:59, 6 September 2013 (UTC)

This is not quite correct. If I visit google.com from Italy, I'm asked whether I want to accept a cookie or not, though in USA you are not. Moreover, Google managers were held criminally liable for privacy violation in a meritless case which however ruled that «the jurisdiction of the Italian Courts applies [...] regardless of where the Google servers with the uploaded content are located».[1] --Nemo 19:26, 6 September 2013 (UTC)

What does this mean: "the EU considers the US to have less stringent data protection laws than the US"? PiRSquared17 (talk) 19:27, 6 September 2013 (UTC)

«Special precautions need to be taken when personal data is transferred to countries outside the EEA that do not provide EU-standard data protection.»[2] «The Commission has so far recognized [...] the US Department of Commerce's Safe harbor Privacy Principles, and the transfer of Air Passenger Name Record to the United States' Bureau of Customs and Border Protection as providing adequate protection.»[3] «In many respects, the US is a data haven in comparison to international standards. Increasing globalization of US business, evidenced by the Safe Harbor agreement, is driving more thinking about data protection in other countries. Still, political and economic forces make a European style data protection law of general applicability highly unlikely in the near future».[4] WMF is also not in [5], FWIW. --Nemo 19:46, 6 September 2013 (UTC)

Note that we cannot be in the Safe Harbor program, because the Federal Trade Commission does not have jurisdiction over non-profit organizations. (See "Eligibility for Self-Certification" on the Safe Harbor page.) We would likely join if we could. -LVilla (WMF) (talk) 22:47, 17 September 2013 (UTC)

Interesting. I was merely answering PiRSquared17's question, but if the WMF would like to join the self-certification program if only it was possible, why not adhere to those obligations in the policy? It won't trigger the law obligations (and advantages), but WMF is free to voluntarily stick itself to higher standards. --Nemo 14:13, 27 September 2013 (UTC)

Indeed. This is another example of a response we have seen elsewhere on this page, where WMF has argues that as a non-profit it is not required to adhere to certain privacy-related standards. It would of course be possible to adhere to those standards voluntarily, and I think there should be an explicit statement of what consideration if any has been given to such voluntary adherence. Spectral sequence (talk) 17:15, 27 September 2013 (UTC)

@Mpaulson : J'ai l'impression que vous avez mal compris mon abréviation EU, qui signifiait Etats-Unis (d'Amérique). Pardon. Ceci dit, même si les lois américaines sont en effet souvent considérées moins protectrices des données personnelles que les lois européennes, les Règles de protection des données personnelles (Privacy Policy) de Wikimédia peuvent tout à fait garantir un niveau de protection supérieur aux lois américaines. Garantir un niveau de protection inférieur aux lois américaines ne serait pas légal, mais garantir un niveau de protection supérieur aux lois américaines, et même supérieur aux lois européennes ou à d'autres lois, est tout à fait possible et compatible avec le droit américain. Il suffit d'adopter des Règles au moins aussi protectrices que les différentes législations nationales (un plus grand commun dénominateur des différentes législations, donc). Je ne vois pas ce qui nous en empêche. Et il faut bien entendu que tous les prestataires de services s'engagent ensuite à respecter ce niveau de protection (comme déjà stipulé dans le paragraphe À nos prestataires de services) 85.170.120.230 02:22, 7 September 2013 (UTC)

Dans un but de meilleure compréhension, serait-il possible que quelqu'un de compétent nous explique en quoi ces Règles de Confidentialités diffèrent du droit européen ? En quoi elles seraient moins protectrices que celui-ci ? Une explication du genre de celle donnée ci-dessus dans la section What is changing? serait très intéressante ! 85.170.120.230 02:32, 7 September 2013 (UTC)

En particulier, comme évoqué par Nemo, comment se situe la WMF par rapport au cadre juridique Safe Harbor ? 85.170.120.230 12:10, 8 September 2013 (UTC)

Hi Anonymous. Without going into exhaustive detail, the United States as a whole largely has no explicit privacy framework. The Safe Harbor framework is not so much a United States privacy framework as a system where organizations in the United States can agree to maintain minimum levels of protection similar to that provided in the European Union. This is a particularly helpful system for large companies that tend to have a big physical presence in Europe (and therefore are definitely subject to European laws) and have the need to send massive amounts of personal information between the United States and the European Union. As LVilla mentioned earlier, even if we had the resources available to meet the exact standards required to participate in the Safe Harbor program, we are not eligible because the FTC (who enforces the program) does not have jurisdiction over WMF because it's a non-profit. In the United States, there are federal (i.e. national) laws that may touch on privacy, such as those protecting children, but even those may not apply to every organization or every situation. There are also state laws that address specific aspects of privacy, but those vary from state-to-state and also tend to only address specific scenarios. California is amongst the most protective, but still does not come anywhere the regulatory framework that the European Union has.

One way organizations in the United States have attempted to provide higher standards is through their commitments to do so in their privacy policies. This is what we are doing here with our privacy policy. This draft is meant to explain the minimum levels of protections we can guarantee at this point in the organization's evolution. We are striving to provide greater protections as we learn and grow (and it should be noted that nothing in this or any privacy policy draft we will ever have will prevent us from providing greater protections than outlined in the policy). Mpaulson (WMF) (talk) 18:14, 27 September 2013 (UTC)

Closing off, stale. Will archive in 24-48 hours, a new section is probably best if further questions. Jalexander--WMF 22:15, 6 November 2013 (UTC)

Actually I think this is perfect. Comment by Spectral sequence 17:15, 27 September 2013 (UTC) has not been addressed (yes, we know this is legal in USA; would it be legal in EU? not hard to understand the question). LVilla said above "We would likely join if we could", so let's pretend that you can: what would it entail? --Nemo 22:42, 6 November 2013 (UTC)

By the way, Restoring Trust in EU-US data flows - Frequently Asked Questions (European Commission - MEMO/13/1059 27/11/2013). --Nemo 09:13, 2 December 2013 (UTC)

Hello Nemo, thanks for this link. We are in the process of researching and preparing a response to address Spectral sequence's questions. Stephen LaPorte (WMF) (talk) 20:06, 9 December 2013 (UTC)

Nice, looking forward to it. --Nemo 12:01, 19 December 2013 (UTC)

Please see LVilla's discussion of Wikimedia compliance with the Safe Harbor framework here. Thanks! RPatel (WMF) (talk) 18:35, 2 January 2014 (UTC)

Collection of "unique device identification numbers"

MOVED FROM WIKIPEDIA VILLAGE PUMP

Hi, at http://meta.wikimedia.org/wiki/Privacy_policy/BannerTestA, it says:

Because of how browsers work and similar to other major websites, we receive some information automatically when you visit the Wikimedia Sites. This information includes the type of device you are using (possibly including unique device identification numbers), the type and version of your browser, your browser’s language preference, the type and version of your device’s operating system, in some cases the name of your internet service provider or mobile carrier, the website that referred you to the Wikimedia Sites and the website you exited the Wikimedia Sites from, which pages you request and visit, and the date and time of each request you make to the Wikimedia Sites.

What sort of "unique device identification numbers" is it referring to? I thought browsers didn't provide that information. 86.169.185.183 (talk) 17:40, 4 September 2013 (UTC)

Looking at similar privacy policies, it looks like this may refer to mobile devices: "AFID, Android ID, IMEI, UDID". --  Gadget850 ^talk 17:45, 4 September 2013 (UTC)

You mean that when you access a website through a browser on an Android device the website can collect a unique device ID? Is that really correct? (I can believe it for general apps, where, presumably the app can do "anything" within permissions, but I didn't think there was any such browser-website mechanism). 86.169.185.183 (talk) 18:58, 4 September 2013 (UTC)

I think this question is more appropriate for the Talk page discussion on the privacy policy draft. Steven Walling (WMF) • talk 20:31, 4 September 2013 (UTC)

I see that this information is "receive[d] [...] automatically". That doesn't necessarily mean this information needs to be collected and stored. Personally I am fine with this information being temporarily handled in a volatile location in order to cater to the display needs of each individual device. I do not however, believe that this information should be stored or used for any other means. Participation in this data-mining should be off by default. WMF would of course be free to nag users into opting in. Because this is a _free_ encyclopedia, users should be _free_ to at least view it in the way they want, without having all their habits and device details harvested non-consensually. Contributions? Edits? Sure, take all you want. There's an implicit agreement to such data-mining when a user submits an edit. But there isn't one from just viewing a page. --129.107.225.212 16:59, 5 September 2013 (UTC)

Thanks, but that is not really relevant to my question (not sure if it was supposed to be), My question is whether it is technically possible for a website to obtain "unique device identification numbers" from a web browser. The text implies that it is; previously I believed it wasn't. I am hoping that someone will be able to answer the question. 86.167.19.217 17:27, 5 September 2013 (UTC)

You are correct in stating that browsers are sandboxed from retrieving this type of information. However, our mobile apps and our mobile app deployment infrastructure may utilize "unique device identification numbers" to identify mobile devices (such as a device tokens, device unique user agents, or potentially UDIDs). Our mobile apps may need this ID for certain functionality, such as sending push notifications or delivering test deployments. Thanks, Stephen LaPorte (WMF) (talk) 17:11, 6 September 2013 (UTC)

I think we have no intention of accessing or recording device UDID, IMEI number, or anything else like that. (It's also getting increasingly hard for apps to get access to those, as the OS vendors don't like creepy apps either.) In the cases where we do usage tracking and need identifiers, they'll be either based on something already in the system -- like your username/ID -- or a randomly-generated token. --brion (talk) 17:20, 6 September 2013 (UTC)

In that case, I think the wording needs adjusting since it currently says "Because of how browsers work [...] we receive some information automatically when you visit the Wikimedia Sites [...] possibly including unique device identification numbers". Mobile apps are not "browsers". 86.160.215.210 20:53, 9 September 2013 (UTC)

Thanks -- I made a small change to clarify that it applies to mobile applications. - Stephen LaPorte (WMF) (talk) 22:33, 6 November 2013 (UTC)

Thanks to the long term foundation policy of enabling widespread vandalism from IP addresses (because who cares how much time dedicated users spend reverting vandalism when they could be productively editing.. far more important not scare off someone who wants to add 'is a dick' to a biography), and the genius decision to enable vandalism from IPv6 addresses, Wikimedia is now actively enabling access to unique identifying data not just by Wikimedia admins, but by absolutely anyone in the world. Unless a Wikipedia user forced onto an IPv6 network takes extraordinary steps- steps which they are highly unlikely to be aware of unless they are reasonably technically savvy and thus have a Wikipedia account anyway- they will now be trackable to the household, if not the *device* level. Genius! John Nevard (talk) 14:37, 14 September 2013 (UTC)

w:IPv6#Privacy indicates that IPv6 privacy extensions are enabled by default on most systems. LFaraone (talk) 23:03, 1 January 2014 (UTC)

Further clarification on unique identifiers for mobile applications?

Below, @Nemo bis: asked for clarification about why the policy still mentions unique device identification numbers after Brion's response. The intention for this sentence is to clarify that our applications could possibly collect unique device identification numbers, which may still be applicable for some applications, although not all of them. This sort of technical detail will depend precisely on the operating system, device, and application. I would welcome an alternative phrasing, if you think this could be clarified further in the policy. Thanks for everyone's attention to detail here. Stephen LaPorte (WMF) (talk) 20:49, 22 November 2013 (UTC)

Yes, add that said unique device identification numbers are not accessed nor recorded, per Brion above. Covering them and not explicitly excluding their usage is worse than not mentioning them at all. --Nemo 10:35, 25 November 2013 (UTC)

Hello Nemo, after confirming with Brion, I clarified in the policy that unique device identifiers may possibly be used for some beta versions of our mobile applications. For example, we may need to use a unique number to whitelist devices that are beta testing an application on some versions of iOS. We cannot say that they will never be accessed or recorded, but it would be in a limited circumstance like this. Thanks, Stephen LaPorte (WMF) (talk) 00:00, 8 January 2014 (UTC)

So, what is the purpose of all this?

The following discussion is closed: closing the top section given staleness but leaving unsampled logs area open will archive when both sections done. Jalexander--WMF 22:25, 18 December 2013 (UTC)

---

I've read the draft from beginning to end, and I have no idea what you wanted me as a user to get from it. What's the purpose, what does it improve compared to the much shorter and more concise current policy which provides very clear and straightforward protections such as the four (4) magic words «Sampled raw log data» (see also #Data retention above)? Is the purpose just adding tracking pixels and cookies for everyone, handwashing (see section above) and generally reducing privacy commitments for whatever reason? --Nemo 21:31, 4 September 2013 (UTC)

Hi Nemo, Thanks for your comment. I outlined some specific reasons for why we needed an update above. YWelinder (WMF) (talk) 01:12, 6 September 2013 (UTC)

See here for Yana's summary. Geoffbrigham (talk) 02:12, 6 September 2013 (UTC)

The summary only says things I already knew, because I read the text. What's missing is the rationale for such changes, or why the changes are supposed to be an improvement. One hint: are there good things that we are not or will not be able to do due to the current policy and what changes are proposed in consequence?

Additionally, the summary doesn't even summarise that well IMHO, e.g. the language about cookies is not very clear and you didn't write anything about making request logs unsampled (which means having logs of all requests a user makes). --Nemo 06:47, 6 September 2013 (UTC)

I've forwarded your question to our tech team. Relevant members of the tech team are out for a conference and will respond to this shortly.YWelinder (WMF) (talk) 01:04, 12 September 2013 (UTC)

Unsampled request logs/tracking

Hey Nemo!

You have raised the question why we want the ability to store unsampled data and that’s a great question!

Two important use-cases come to mind. The first use case is funnel analysis for fundraising. As you know, we are 100% dependent on the donations by people like you -- people who care about the mission of the Wikimedia movement and who believe in a world in which every single human being can freely share in the sum of all knowledge.

We want to run the fundraiser as short as possible without annoying people with banners. So it’s crucial to understand the donation funnel, when are people dropping out and why. We can only answer those kind of questions if we store unsampled webrequest traffic.

The second use case is measuring the impact of Wikipedia Zero. Wikipedia Zero’s mission is to increase the number of people who can visit Wikipedia on their mobile phone without having to pay for the data charges: this is an important program that embodies our mission. Measuring the impact means knowing how many people (unique visitors) are benefiting from this program. If we can measure this then we can also be transparent to our donors in explaining how their money is used and how much impact their donations are making.

I hope this gives you a better understanding of why we need to store unsampled webrequest data. It is important to note that we will not build long historic reader profiles: the Data Retention Guidelines (soon to be released) will have clear limits on how long we will store this type of data.

Best regards,

(in my role as Product Manager Analytics @ WMF)

Drdee Drdee (talk) 23:03, 12 September 2013 (UTC)

Thank you for your answer. Note that this is only one of the unexplained points of the policy, though probably the most controversial one (and for some reason very well hidden), so I'm making a subsection. I'll wait for answers on the rest; at some point we should add at the top a notice of the expected improvements users should like this policy for (this is the only one mentioned so far apart from longer login duration, if I remember correctly).

Frankly, your answer is worse than anything I could have expected: are you seriously going to tell our half billion users that you want them to allow you to track every visit to our websites in order to target them better for donations and for the sake of some visitors of other domains (the mobile and zero ones)? This just doesn't work. I'm however interested in knowing more.

• Why does fundraising require unconditional tracking of all visits to Wikimedia projects? If the aim is understanding the "donation funnel" (note: the vast majority of readers of this talk doesn't understand you when you talk like this), why can't they just use something like the ClickTracking done in 2009-2010 for the usability initiative, or the EventLogging which stores or should store only aggregate data (counts) of events like clicks of specific things?
• I know that Wikipedia Zero has struggled to find metrics for impact measure, but from what I understood we do have some metrics and they were used to confirm that "we need some patience". If we need more statistics so desperately as to desire tracking all our visitors, I assume other less dramatic options have been considered as well? For instance, surely the mobile operators need how much traffic they're giving out for free that they would otherwise charge; how hard can it be for them to provide this number? (Of course I know it's not easy to negotiate with them; but we need to consider the alternatives.) --Nemo 06:51, 13 September 2013 (UTC)

Hi Nemo,

I think you are switching your arguments: first you ask why we would need to store unsampled webrequest data. You specifically asked "are there good things that we are not or will not be able to do due to the current policy and what changes are proposed in consequence?". I give you two use cases both being a type of funnel analysis that require unsampled data (the two use cases are btw not an exhaustive list). Then you switch gears by setting up a Straw man argument and saying that we will use it for better targeting of visitors. That's not what I said, if you read my response then I said we want to know when and why people drop out of a funnel.

The fact that you quote our half billion users indicates that we need unsampled data: we don't know for sure how many unique visitors we have :) We have to rely on third-party estimates. You see even you know of use-cases for unsampled data :)

Regarding Wikipedia Zero: the .zero. domain will soon be deprecated so that will leave us with only the .m. domain so we cannot restrict unsampled storage to .zero. In addition, most Wikipedia Zero carriers do not charge for .m. domains as well.

Regarding the Fundraising: I am answering your question and I am sure you know what a donation funnel is; I was not addressing the general public. EventLogging does not store aggregate data but raw unsampled data.

I am not sure how I can counter your argument 'This just doesn't work'.

Drdee (talk) 19:08, 18 September 2013 (UTC)

I'm sorry that you feel that way, I didn't intend to switch arguments. What does "We want to run the fundraiser as short as possible" mean if not that you want to extract more money out of the banners? That's the argument usually used by the fundraiding team, that the higher the "ROI" is the shorter the campaign will be. If you meant something else I'm sorry, but then could you please explain what you meant?

I'm also sorry for my unclear "This just doesn't work"; I meant that in this section I'm asking why the users, with whom we have a contract, should agree to revise it: what do they gain ("what is the purpose")? I still don't see an answer. For instance, knowing for sure how many unique users we have is not a gain for them; it's just the satisfaction of a curiosity the WMF or wikimedians like me can have.

As for Zero, I don't understand your reply. Are you saying that yes, other ways to get usage stats were considered but only unsampled tracking works? And that I'm wrong when I assume that operators would know how much traffic they're giving for free? --Nemo 14:55, 27 September 2013 (UTC)

Hi Nemo, I'll let other folks chime in to articulate the needs for the Fundraiser and Zero, I am with you on the fact that Wikimedia should collect as little data as possible but let me expand on the point you make about "curiosity regarding UVs". Measuring reach in terms of uniques is more than just a matter of "curiosity". We currently rely on third-party data (comScore) to estimate unique visitors but there are many reasons why we want to reliably monitor high-level traffic data based on uniques. We recently obtained data about the proportion of entries from Google properties as part of a review of how much of our readership depends on search engines. I cite this example because any significant drop in search engine-driven traffic is likely to affect Wikimedia's ability to reach individual donors, new contributors and potential new registered users. Similarly, we intervened in the past to opt out of projects such as Google QuickView based on evidence that they were impacting our ability to reach and engage visitors by creating intermediaries between the user and the content. Using UV data (particularly in combination with User Agents) also helps us determine whether decisions we make about browser support affect a substantial part of our visitor population. As Diederik pointed out, EventLogging does collect unsampled behavioral data about user interaction with our websites to help us run tests and improve site performance and user experience. The exact data collected by EventLogging is specified in these schemas and is subject to the data retention guidelines that the Legal team is in the process of sharing. DarTar (talk) 20:23, 9 December 2013 (UTC)

Strip Wikimedia Data Collection to the Barest Minimum - Further Considerations

Thanks Privacycomment for this post. I just want to add my perspective with some ideas on how to look at data-relevant processes in general and how to use the artificial differences in national laws on an action done in the physical or digital world.

• First and foremost Wikipedia is a labor of love of knowledge nerds worldwide. This means that it is from an outside view an "international organization" much like the Red Cross - only to battle information disasters. This could be used to get servers and employees special status and protections under international treaties (heritage, information/press etc)
• History teaches that those protections might not be a sufficient deterrent in heated moments of national political/legal idiocy, so Wikimedia should enact technical as well as content procedures to minimize the damage.

Data Protection

• Collect as few data as possible and purge it as fast as possible. Period. You cannot divulge what you do not have.
• Compartmentalize the data so that a breach - let's say in the US - does not automatically give access to data of other countries' userbases.
• Play with laws: as there are a lot of protections well established when used against homes, or private property shape your installation and software to imitate those - no "official" central mail server that can be accessed with provider legislature, but a lot of private servers that are each protected and must be subpoenaed individually etc...
• Offer a privacy wikipedia version that can only be accessed via tor - and where nothing is stored (I know this might be too much to admin against spam pros)
• Use Perfect forward secrecy, hashes etc to create a situation, where most of the necessary information can be blindly validated without you having any possibility to actually see the information exchanged. This also helps with legal problems due to deniability. Again - compartmentalize.

Physical and digital infrastructure concerns

• An internal organization along those lines and with the Red Cross as an example would offer a variety of possibilities when faced with legal threats: First and foremost, much like choosing where to pay taxes, one could quickly relocate the headquarters for a specific project to another legal system so that one can proof, that e.g. the US national chapter of wikimedia has no possible way of influencing let's say the Icelandic chapter who happens to have a national project called wikipedia.org
• Another important step in being an international and truly independent organization is to finally use the power of interconnected networks and distribute the infrastructure with liberal computer legislation in mind much more as is now the case. Not to compare the content - just the legal possibilities - of the megaupload case with those of wikimedia, as long as US authorities have physical access to most of the servers, they do not need to do anything but be creative with domestic laws to hurt the organisation and millions of international users, too...
• If this might be too difficult, let users choose between different mirrors that also conform to different IT legislation

Information Activism

• Focus on a secure mediawiki with strong crypto, which can be deployed by information activists

So: paranoia off. But the problem really is that data collected now can and will be abused in the next 10, if not 50-100 years. If we limit the amount of data and purge data, those effects can be minimized. No one knows if something that is perfectly legal to write now might not bite one in the ass if legislation is changed in the future.

Cheers, --Gego (talk) 13:53, 9 September 2013 (UTC)

Hi Gego,

The idea of having a secure mediawiki with strong crypto is a technical proposal and as such is best to be presented as an RFC on Mediawiki but it's outside the scope of the new Privacy Policy.

Drdee (talk) 00:40, 7 November 2013 (UTC)

There's a lot of discussion about the data collected from those who edit pages, but what about those who passively read Wikipedia? I can't figure out what's collected, how long it's stored, and how it's used.

Frankly I don't see why ANY personally identifiable information should EVER be collected from a passive reader. In the good old days when I went to the library to read the paper encyclopaedia, no one stood next to me with a clipboard noting every page I read or even flipped past. So why should you do that now?

I don't object to real time statistics collection, e.g., counting the number of times a page is read, listing the countries from which each page is read from at least once, that sort of thing. But update the counters in real time and erase the HTTP GET log buffer without ever writing it to disk. If you decide to collect some other statistic, add it to the real-time code and start counting from that point forward.

Please resist the strong urge to log every single HTTP GET just because you can, just in case somebody might eventually think of something interesting to do with it someday. This is EXACTLY how the NSA thinks and it's why they store such a terrifying amount of stuff. 2602:304:B3CE:D590:0:0:0:1 14:54, 10 September 2013 (UTC)

2602, I will be linking to this comment from below but you may be interested in the section started at the bottom of the page at Tracking of visited pages . Jalexander (talk) 03:37, 11 September 2013 (UTC)

There are a number of use cases for collecting unsampled data, including generating detailed understandings on how readers interact with Wikipedia content and how this might change over time, finding and identifying very low frequency (but important) events, and and looking at interactions with long-tail content that may reveal new sources of editors. But it's important to understand that we are interested in the behavior of Wikipedia readers, but in aggregate, not as individuals. TNegrin (WMF) (talk) 01:49, 19 December 2013 (UTC)

Dear 2602,

We need to store webrequest data for a very limited time from a security point of view: in case of a DDoS we need to be able to investigate where it originates and block some ip ranges. Sometimes we need to verify whether we are reachable from a certain country. And there other uses cases so not storing webrequest is not an option. The Data Retention guidelines, which will be published soon, will put clear timeframes on how long we can store webrequest data.

I hope this addresses your concern.

Best, Drdee (talk) 00:51, 7 November 2013 (UTC)

The current policy only allows sampled logs. Are you saying the the sysadmins are currently unable to protect the sites from DDoS? I never noticed.

Also, https://blog.archive.org/2013/10/25/reader-privacy-at-the-internet-archive/ , linked below, shows it definitely is an option. --Nemo 10:07, 8 November 2013 (UTC)

Generation of editor profiles

I'd like once more to point out serious concerns about the generation and publication of detailed user profiles on Wikimedia websites or servers. This issue is repeatedly dealt with, at least, on the German Wikipedia (i.e. here, and actually again in the signpost equivalent at deWP). While the toolserver's policy accords to European standards concerning data privacy, wmlabs (which will completly replace the toolsever in 2014) does not meet these requirements. A contributor's poll at Meta clearly showed the community's preference of an opt-in solution for user data mining tools. Nevertheless WMF is giving the opportunity to run a detailed user profiling tool that does not allow an opt-in, even not an opt-out. We are aware that American data protection standards differ from European standards, and that such tools are considered to be legal in the USA. They are yet not needed by anyone. Thus, we still hope that WMF does not impose US points of view on their global contributors, whenever weak data policies are not required by US law, nor needed by contributors to improve the projects' contents. Looking forward a WMF statement on this issue. --Martina Nolte (talk) 20:53, 24 November 2013 (UTC)

Can you expand on what you mean by a 'US point of view'? --Krenair ^{(talk • contribs)} 01:06, 25 November 2013 (UTC)

Sure. User contribution data are publicly available in the edit histories. According to US law, it is okay to aggregate these data and generate detailed user profiles; people tend to feel okay with such a tool. In European countries an aggregation of personal data and the publication of user profiles without consent are considered illegal; people feel offended by such a tool. The views on what is okay or not okay depend on local laws. Laws reflect a culture's values and points of views. --Martina Nolte (talk) 04:27, 25 November 2013 (UTC)

+1 - I would generally like to underline this. -jkb- 10:13, 25 November 2013 (UTC)

Other discussions: Kurier (2013-09), Kurier (2013-10), labs-l (2013-09), labs-l (2013-10). I regret bringing this up on dewiki a little, as I didn't realize it would start this much drama. On the other hand, I do think that this is something we really should be discussing. But all the data will be public as long as db dumps with detailed info are published. PiRSquared17 (talk) 17:39, 26 November 2013 (UTC)

No need to regret it, no drama. This is an important discussion and it has to be made: 5th most used website, 1.7 billion edits with user information, 14 years of data collecting, our data. NNW (talk) 18:23, 26 November 2013 (UTC)

You're right. It's good that this is being discussed at least. I was a bit surprised that almost nobody commented about it on enwiki though. PiRSquared17 (talk) 20:21, 26 November 2013 (UTC)

Perhaps the experience of the 20th century might explain why Germans are quite sensitive concerning these topics. NNW (talk) 09:07, 27 November 2013 (UTC)

Right, the raw data are available by dumps. But not yet aggregated to individual user profiles. WMF could even think about slimming down these dumps; a matter of data economy (as much personal data as needed, as few personal data as possible). Editors agreed to publish their content contributions under a free licence; they do not automatically agree to publish their editing behaviour, or even their individual profiles. As I said, the "drama" is due to a quite different view on data privacy issues. --Martina Nolte (talk) 19:49, 26 November 2013 (UTC)

I'm another who feels that this is a really pertinent Privacy issue which requires careful consideration here. And not just from a purely legal perspective (after all, if the Foundation is adopting a "cuddly" approach to volunteers, legality is surely just one dimension in the picture). User profiling—with its abuses as well as uses—is one reason why I prefer to edit Wikipedia as an IP. —MistyMorn (talk) 11:20, 27 November 2013 (UTC)

• I am disappointed that the concerns that were raised here and in this RFC are not addressed by the current draft of the new privacy policy. It is amazing that these collected records are not even mentioned in the section Information We Collect. --AFBorchert (talk) 20:30, 30 November 2013 (UTC)

I may have missed something, but the only comment I can see from a WMF member is this. The fact that user profiling—including provision of potentially sensitive personal information—may be done either with or (though rather more arduously for most) without tools made publicly available through Wikimedia doesn't mean that users cannot be informed of such possibilities in the present document. MistyMorn (talk) 20:37, 3 December 2013 (UTC)

To make clear that the above mentionned questions are not individual concerns of single Wikipedia/Wikimedia contributors, I'd like to point to this site (German language yet, a translation is planned). --Martina Nolte (talk) 19:40, 9 December 2013 (UTC)

Hi, Martina: thanks for notifying us about that discussion. We're discussing this issue and considering how best to handle. -LVilla (WMF) (talk) 20:21, 9 December 2013 (UTC)

I've been a Toolserver user for 6 years and the EU data protection directive along with other TS oddities has been a thorn in development. An example: My User activity tool which lists (more or less) publicly available data to make it easier to prune membership lists. If data-mining were allowed we could partially generate and manage these lists automatically. Or email an inactive user that is familiar with a particular city, if questions come up. See whose on IRC and likely up at this time of day.

Additionally, our cultural partners have requested in-depth analytics that cannot be done on the Toolserver because of the privacy policy. WikiProjects are also interested in see who reads their pages, how much they read, what links they follow, what search terms or forums brought them there, and more.

Finally, do not falsely misrepresent the German/European view as some sort of "global" view. The US and many other countries will not adopt data-protection style legislation (despite what WM-DE has said to my face). Also, it's technically impossible third parties from doing analysis on their own, the data is public afterall. You've had your chance and chose to continue decommissioning to (IIRC) free 5-10% of WM-DE's budget. —Dispenser (talk) 18:53, 10 December 2013 (UTC)

You know that a majority of users voted for opt-in? That's what's usually called This is wanted by the community. And you can check that not all of the opt-in voters come from Germany/Europe. NNW (talk) 20:29, 10 December 2013 (UTC)

A majority, but not an impressive one: 54% (possibly slightly higher if some people voted for multiple options) is not what I would call overwhelming consensus. More to the point, there seems to be a pretty strong split based on which projects people come from: I looked over the list of voters on the RfC, and I recognized a great many names from the English Wikipedia under "Remove opt-in completely" and almost none under "Keep opt-in". Not very scientific, I know, but I suspect a more methodical analysis would support the same conclusion. I'm not sure there's any middle ground to be reached on this in terms of the privacy policy; I expect the eventual solution will be to have Labs' policy be that you can't offer data-mining services, or you have to make them opt-in, for projects where the community has indicated they don't want them (or hasn't indicated that they do want them). Emufarmers (talk) 13:10, 13 December 2013 (UTC)

Standing in for Erik as he’s on vacation, my position is that we shouldn’t introduce a policy limitation on what can/can’t be created on WMF servers for public data. However, we can look into adopting a mechanism by which the community can disable specific tools on the basis of community consensus. Legal tells me the Labs Terms of Use already allows the Foundation to take something down if necessary, but a formal mechanism for disabling specific tools based on community consensus has not yet been developed.

This approach would allow the community both the ability to experiment and be bold with how we use our data, as well as provide a check on a tool if the tool is deemed inappropriate. I think this strikes the right balance of experimentation and user privacy protection.

Obfuscating user contributions data or limiting our existing export will not happen because we have a commitment to not only make all of Wikipedia available, but to allow anyone to fork and take the history, content, etc. with them. Removing that ability would be a disservice to the community and we currently have no plans to revisit it. Tfinc (talk) 21:38, 19 December 2013 (UTC)

One question that immediately comes to mind is "which community?". For example, consider the ongoing complaints by some on dewiki about wanting to prevent people from creating tools to analyze contributions. Is consensus on dewiki enough to take the tool down for everyone? Or a consensus on a metawiki discussion contributed to mainly by German editors? And then what if other wikis' communities who weren't notified of this discussion (or ignored it) are upset when a useful tool goes away? Or would we just force the tool author to "break" their tool so it doesn't work on dewiki but continues to function on all other wikis? Anomie (talk) 14:23, 20 December 2013 (UTC)

As the one who'd be tasked with enforcing this, I can tell you that I would require a very clear consensus, and that if the consultation seems to be dominated by a particular subgroup I'd make a serious effort to widen the discussion before any action is taken. Honestly, engineering should be very hesitant to step in and disable a tool or impose conditions on it beyond those of the terms of use; but it's also our responsibility to do so if the tool breaks something or if the community is overwhelmingly opposed to it: Labs isn't free hosting, it's a home for development work that benefits the projects.

I am hoping that if any (sub) community makes it clear that it would rather opt out of some tool, the tool maintainers would be considerate enough to heed the request without intervention by operations, though – and I believe most will without hesitation. MPelletier (WMF) (talk) 15:44, 20 December 2013 (UTC)

The sort of restrictions required to prevent tools like the DUI from existing would place a significant burden on development. You'd need to restrict the ability to access a users' contributions programmatically, but simply disabling the API access is not enough: you'd also need to attempt to curb screen-scraping, via rate limits which will be circumvented. There are numerous legitimate uses of of editor data, and the Foundation has historically released all data needed to build DUI via downloadable data dumps for over 10 years. In effect, attempting to prevent editor profiling would only significantly hinder legitimate users while not preventing malicious use. LFaraone (talk) 23:15, 1 January 2014 (UTC)

Summary; response; moving discussion elsewhere

I think that this section of the discussion boils down to two questions:

1. Should the Foundation prohibit creation of user profiles on servers controlled by the Foundation, such as Labs?
2. Should the Foundation prohibit creation of user profiles on servers not controlled by the Foundation, either by reducing the amount of information made available, or by using legal means to restrict how information is used?

Possible responses to question #1 are being discussed below in #Note_on_Labs_Terms_.2F_Response_to_NNW. If there are additional comments to be made on that topic, please make those comments in that section.

Question #2 has been responded to here by a number of people (including Tfinc and Lfaraone), and has also been responded to in #Handling_our_user_data_-_an_appeal by a variety of users, including Anomie, verdy_p, Coren, Nemo bis, and others. If there are additional comments to be made on question #2, please make those comments in #Handling_our_user_data_-_an_appeal, not this one, so that we can all be discussing in one place.

If there is another question or issue not covered by those two discussions below, please open a new section and refer back to this one so that it can be squarely addressed.

Because this section of the discussion is being extensively discussed elsewhere, I propose closing this section. Thank you to everyone who contributed in this part of the discussion for their serious, thoughtful responses on a complex and emotional topic. —LVilla (WMF) (talk) 00:09, 8 January 2014 (UTC)

When May We Share Your Information? Because You Made It Public

The following discussion is closed: closing because discussion seems to be done, please reopen if not

---

Privacy policy#Because_You_Made_It_Public: "Any information you post publicly on the Wikimedia Sites is just that – public."

Does this mean the WMF is allowed to share any of the information, by any means, in any form, for any purpose, to anyone? --Aviertje (talk) 13:03, 1 December 2013 (UTC)

It means that, for example, the WMF can distribute dumps with all your edits, etc. in them. I think this should be changed to exclude oversighted (or deleted?) info, though, even if it was originally public. PiRSquared17 (talk) 15:57, 1 December 2013 (UTC)

I doubt that going back to redact information from old dumps is really feasible, though. Anomie (talk) 14:15, 2 December 2013 (UTC)

We could, in theory, delete it from the dumps we provide. However, many other people mirror and distribute those dumps, and we can't (as a practical matter) reach out and take those down. So any promise here to exclude deleted information would be a false promise. We'd prefer to be up-front, and warn people that their public edits really are public- that's what this language attempts to do.

That said, I sort of see the original commenter's point about the language being perhaps somewhat confusing. We'd be happy to listen to any suggestions on how to improve it.-LVilla (WMF) (talk) 19:40, 9 December 2013 (UTC)

In theory, yes. But actually doing so would probably be technically prohibitive. Anomie (talk) 14:46, 10 December 2013 (UTC)

Oh, yes, absolutely. Don't worry, I highly doubt Legal (at least under my watch) will be in the business of forcing anybody to be open up and edit dumps :) -LVilla (WMF) (talk)

@Aviertje: I should have said this earlier, but this is about information you post publicly, as opposed to information we record privately and then later make public. So, for example, if you put your real name in your user name, or post your mailing address on your talk page, that is public information; we can't reasonably know about it or treat it specially (though in some circumstances the community may help you delete it). Does that make sense?

If it would help, we could add something like the italic text: "Any information you post publicly on the Wikimedia Sites is just that – public. For example, if you put your mailing address on your talk page, that is public, and not protected by this policy. Please think carefully about your desired level of anonymity before you disclose personal information on your user page or elsewhere." If you have any other suggestions on how to make it more clear, please let us know. -LVilla (WMF) (talk) 23:41, 18 December 2013 (UTC)

I've put this into the policy; thanks for the suggestion, Aviertje.

Regarding site visiting logs

The following discussion is closed: Closing because this looks to be answered, please reopen if not

---

First question: is our every visit to wikimedia sites logged (e.g. some ip, logged in or not, visited page https://meta.wikimedia.org/w/xxxx at some time) and stored? If yes, then how long will it be stored? The current Privacy policy says: "When a visitor requests or reads a page, or sends email to a Wikimedia server, no more information is collected than is typically collected by web sites. The Wikimedia Foundation may keep raw logs of such transactions, but these will not be published or used to track legitimate users.", in which the "may keep raw logs" is ambiguous. Also, regarding "these will not be published or used to track legitimate users." does that mean these data can be used to track illegitimate(for example, suspected vandalism) users?

Second question: recently I just heard some user claiming that though Checkusers' range of access excludes user visit log, in some necessary occasions they can apply to access those data. Is that true?--朝鲜的轮子 (talk) 06:57, 4 December 2013 (UTC)

CheckUser does not have access to a user's visit log. Legoktm (talk) 20:23, 4 December 2013 (UTC)

By "does not have access", do you mean "never ever, even when there is need", or "possible when checking such log can be helpful to proving connections between users"?--朝鲜的轮子 (talk) 03:15, 5 December 2013 (UTC)

Checkusers only have access to what is stored in the checkuser table. A user's visits are not stored in that table. Hence, checkusers "never ever" have access to it via the CheckUser tool. Legoktm (talk) 03:17, 5 December 2013 (UTC)

And Checkusers will never ever use anything beyond reach of Checkuser tool?--朝鲜的轮子 (talk) 03:56, 5 December 2013 (UTC)

What User:Legoktm wrote is incomplete. Is there other information, stored on some hardware controlled by the Wikimedia Foundation, in addition to the information available to checkusers? If so, what information is available at that location, and who has access to it? --Stefan2 (talk) 21:56, 7 December 2013 (UTC)

Well, I would likely be the one they'd have to apply to - and I've never heard of such a thing. To my knowledge, there is no such application process or access to any other data. I don't want to categorically speak to what may or may not be on the servers - I'm not technical enough to know - but I can say that if it exists, it is not and has not been used that way. At least, not for the last several years that I've been around. Philippe (WMF) (talk) 00:41, 8 December 2013 (UTC)

wikitech:Logs has a summary of the sorts of raw access logs that are probably being referred to here (note this may not be a complete list). Access to this data is limited to people with access to the servers involved, and as far as I know getting access requires an NDA and is generally limited to WMF employees and contractors involved in maintaining the site and software. Also as far as I know, the sorts of illegitimate uses this data might be used to track are more along the lines of someone trying to break or break into the servers, not on-wiki vandalism. BJorsch (WMF) (talk) 14:37, 9 December 2013 (UTC)

The current privacy policy only allows sampled logs, which means it's hard to do any tracking/user profiling/fingerprinting/user behaviour analysis/however you may wish to call it. The proposed text, in short, proposes to allow unlimited tracking; see in particular #Unsampled request logs/tracking and #Reader Privacy at the Internet Archive for more information. --Nemo 14:17, 7 December 2013 (UTC)

I think the major concern on unsampled tracking is fundraising and research. What about anti-vandalism? Does WMF think that it is necessary and legitimate to use anything to if it helps to identify a vandal, in principle?--朝鲜的轮子 (talk) 22:52, 11 December 2013 (UTC)

Thank you for your questions 朝鲜的轮子! For the first one, as you say, we collect different types of information from users (either automatically or intentionally) when visiting Wikimedia Sites, logged in or not. We are currently working on data retention guidelines that will apply to all non-public data we collect from Wikimedia Sites. The guidelines will describe the different types of information that we collect (with examples), and will describe for how long each type of information would be retained. The data retention guidelines would work along with the Privacy Policy, being updated over time to reflect current retention practices, and will allow us to further fulfill our commitment in the Privacy Policy of keeping your private data “for the shortest possible time”.

Regarding your second question, I believe Philippe (WMF)’s comment covers exactly what you ask. From my knowledge, we have no way for Checkusers to access any type of raw server log in their Checkuser capacity. Furthermore, we have never given log access to the community and we have no intention of doing so. Please let us know more information on where you heard this if you want us to dive deeper into this. Thanks again! --JVargas (WMF) (talk) 00:08, 19 December 2013 (UTC)

Please add concerning user profiles

Sorry, me English is not good enough to write it directly in English, so I hope somebody will translate it.

• Wir veröffentlichen ohne Deine ausdrückliche Zustimmung kein Nutzerprofil von Dir, also Daten, die Deine zeitlichen Editiergewohnheiten und Interessengebiete zusammenfassen. Wenn wir Daten an andere weitergeben, die das Erstellen solcher Profile ermöglichen (zum Beispiel WikiLabs), so verpflichten wir sie, ebenfalls keine in dieser Weise aggregierten Nutzerdaten ohne Deine Zustimmung zu veröffentlichen.

--Anka Friedrich (talk) 11:25, 7 December 2013 (UTC)

Rough translation: "Withour your explicit consent, we do not publish user profiles about you, i.e. data summarizing your temporal editing habits and interest areas. If we release data to others who enable the generation of such profiles (e.g. WikiLabs), we require them to likewise not publish user data that have been aggregated in this way, except with your consent." Regards, Tbayer (WMF) (talk) 03:34, 10 December 2013 (UTC)

Considering that second sentence would require us to stop publicly releasing data dumps and to break history pages and the API, I would oppose such a change. Anomie (talk) 14:49, 10 December 2013 (UTC)

Tbayer, thank You for Translation. --Anka Friedrich (talk) 15:25, 15 December 2013 (UTC)

Anomie, no, but everybody, who gets the dump or gets access to the API would have to aggree not to aggregate data without consent. --Anka Friedrich (talk) 15:25, 15 December 2013 (UTC)

The dumps and access to the API are given to everyone in the world without restrictions. And I oppose requiring people to "sign up" so we can force them to agree to some pointless requirement before allowing them to access these things. You also overlooked history pages, Special:Contributions, and other on-wiki interfaces which would also have to be restricted or broken. Anomie (talk) 14:16, 16 December 2013 (UTC)

@Anka Friedrich: This issue is now being discussed in great detail below in #Handling_our_user_data_-_an_appeal, so I will suggest closing this section out and continuing the discussion below. Thank you again for your serious, thoughtful contribution to this discussion, despite the language barrier. —LVilla (WMF) (talk) 00:26, 8 January 2014 (UTC)

The ability to store unsampled log data (a.k.a. loss of privacy in exchange for money)

One of the changes between the existing privacy policy and the new draft is that the draft will now allow the Foundation to retain unsampled log data — in effect, this means that every single visit by every single visitor to each and every Wikimedia project (and perhaps other sites owned/run by the Foundation) will now be recorded and retained on WMF servers. It is shocking to me that the only reasons given for such a broad, controversial and hardly advertised change are (1) fundraising and (2) the ability to measure statistics in Wikipedia Zero, a project that is limited in terms of geography, scope and type of access (mobile devices).

Given that Wikipedia Zero is just one of many project led by the Foundation, and that it applies to a limited number of visitors who are using a very specific medium to access the projects, I fail to see the need to sacrifice the privacy of everyone who will ever visit a Wikimedia project. Moreover, I am disappointed and terrified to learn that the Foundation thinks it is reasonable to sacrifice our privacy in exchange for more money — especially since our fundraising campaigns appear to have been quite effective, or at least to have enabled the WMF to reach their revenue goals without much trouble. odder (talk) 22:22, 7 December 2013 (UTC)

"will now be recorded and retained" is probably a bit strong. s/will/may/ would probably be more accurate. Personally, I can see the ability to record full logs when needed to be useful in debugging, performance analysis, and analysis of which features should be prioritized for improvement or development or even possible removal. Boring stuff to most people. BJorsch (WMF) (talk) 14:46, 9 December 2013 (UTC)

"May" is only a legalese euphemism for "will" (in this case). If there are no plans to store and use unsampled log data, for whatever purpose, then surely there will be no problem to revert to the wording of the current privacy policy, which only allows storing sampled data. odder (talk) 15:35, 9 December 2013 (UTC)

Believe whatever you want, I'm not about to engage in arguing over conspiracy theories. BJorsch (WMF) (talk) 15:25, 10 December 2013 (UTC)

No, it isn't such a euphemism. You use language like this to ensure that the Foundation has the flexibility to run programs that may make use of this capability. LFaraone (talk) 23:18, 1 January 2014 (UTC)

That's my point precisely. odder (talk) 19:47, 7 January 2014 (UTC)

Maybe I missed it somewhere but it would be helpful to listen all data types from the logs. Especially I am interested in this question: Do you save every pageview incl. IP address and/or username? Do you have logs in which you can see what page I have read (!), how long I have read them etc etc. Raymond (talk) 16:55, 9 December 2013 (UTC)

Yes, I also would appreciate to know if you have, or plan, such visitor logs. --Martina Nolte (talk) 19:46, 9 December 2013 (UTC)

+1 --Steinsplitter (talk) 19:48, 9 December 2013 (UTC)

+1, by all means! Ca$e (talk) 09:36, 10 December 2013 (UTC)

+1 ...84.133.109.103 09:38, 10 December 2013 (UTC)

+1 -jkb- 09:41, 10 December 2013 (UTC)

+1 I told you so."Dance" Alexpl (talk) 09:57, 10 December 2013 (UTC)

+1 for showing an example of the currently log data. --Zhuyifei1999 (talk) 10:08, 10 December 2013 (UTC)

+1 ---<(kmk)>- (talk) 13:46, 10 December 2013 (UTC) there is no need to trade my privacy for (even more) funds.

+1 -- smial (talk) 14:33, 11 December 2013 (UTC)

See wikitech for the format of the raw logs we receive from the front end caches. This data is sent 1:1 to a log aggregation server where it gets downsampled in real time. See the filters.*.erb files for what HTTP paths we currently log data on and with what frequency. The format is

pipe <sample rate> filter-program <filter -d specifies project, -p specifies the page> >> <output location>

Mwalker (WMF) (talk) 01:19, 9 January 2014 (UTC)

I do not know of any logs that record all pageviews, or of any plans to start collecting such logs. The logs testwiki.log and test2wiki.log mentioned on wikitech:Logs do contain user information and URL (as part of a larger amount of debugging information) for requests that aren't served from the caches, but only for testwiki and test2wiki which the vast majority of people have no reason to ever visit. I also don't know of any logs or log analyses that show pages read by any user or IP or how long anyone might have spent reading any particular page. BJorsch (WMF) (talk) 15:25, 10 December 2013 (UTC)

I thought the fundraising people already do exactly that and call it "User site behavior collection". (I cant actually tell from that link if those proposals have already been implemented ?!?) Alexpl (talk) 18:04, 10 December 2013 (UTC)

I was not aware of that. Note though that's a proposal and not something that is currently being done. It seems like a useful study though, and it's far from tracking everyone all the time that some of the more paranoid here seem to be expecting. BJorsch (WMF) (talk) 00:52, 11 December 2013 (UTC)

I am pretty sure their intentions were good. But due to the nature of the wikipedia project, it seems a bit "pre Snowden" or just unworldly to believe that WMF can limit the access to those Data once the mechanism to collect them has been installed. The first dude with access, who seeks future employment at a hip company (...), can do irreversable damage and sell every WP-contributor out. Alexpl (talk) 08:58, 12 December 2013 (UTC)

Two things; first, I delayed that experiment until after we'd sorted out the new privacy policy. No code has been written, no code has been deployed. Second, the experiment was designed explicitly to not send any data to the server beyond averages a single time (nor store locally on the client anything beyond counts and times). I wasn't even going to use cookies which could be sniffed from the wire. Data in the experiment that was stored locally would have been useful for statistical correlation if someone had access to your computer (or network connection); but if that was the case they wouldn't need to bother with my data, they would get it directly. I'll point out that the following places document what information would actually be collected: From the RfC, raw source Schema:EventCapsule and Schema:AnonymousUserSiteUsage. If you have concerns specifically about these data, I encourage you to put them on the talk page of the RfC. Mwalker (WMF) (talk) 01:05, 9 January 2014 (UTC)

@User:BJorsch (WMF). If there are no logs and no plans to start collecting them, why does was the draft changed, so that the foundation would be allowed to do just that?---<(kmk)>- (talk) 18:52, 10 December 2013 (UTC)

For the reasons that have been officially stated, perhaps? But really, you'd probably want to ask one of the people involved in drafting this. I just commented here to add a few other potential uses for the ability to collect non-sampled logs when needed, since people seemed to be focusing overmuch on the two examples in the draft. BJorsch (WMF) (talk) 00:52, 11 December 2013 (UTC)

does "I do not know of any logs that record all pageviews, or of any plans to start collecting such logs. " mean Wikimedia does not have such logs and plans or is it meant literally; you BJorsch do not know about it? ...Sicherlich ^Post 08:39, 11 December 2013 (UTC)

+1 -- smial (talk) 14:32, 11 December 2013 (UTC)

The latter, obviously. I'm certainly not aware of everything everyone associated with the Foundation does or plans, nor am I in any position to set policy. BJorsch (WMF) (talk) 15:19, 11 December 2013 (UTC)

I guess we just assumed that the "WMF" tag in your signature would grant you preferential access to all relevant information on this matter :) Alexpl (talk) 16:57, 11 December 2013 (UTC)

Okay, so now we know the private opinion and asuming of you BJorsch. Is it possible to get an officical statement of the WMF? ...Sicherlich ^Post 17:20, 12 December 2013 (UTC)

BJorsch's opinion is that users asking these questions are more paranoid. I would sure prefer an official, and hopeully more sober, WMF statement on this logging issue. --Martina Nolte (talk) 17:36, 20 December 2013 (UTC)

Why do you need special logging for WP Zero? PiRSquared17 (talk) 20:27, 20 December 2013 (UTC)

Regarding some introductory remarks

The following discussion is closed: closing and will archive in a couple days unless reopened, appears to be answered with changes made by geoff and no responses

---

Hi,

I would like to share some observations from reading the introductory remarks of this document. I apologize if anything has already been brought up.

• "[1] Gathering, sharing, and understanding information is what built the Wikimedia Sites. [2] Continuing to do so in novel ways helps us learn how to make them better. [3] We believe that information-gathering and use should go hand-in-hand with transparency. [4] This Privacy Policy explains how the Wikimedia Foundation, the non-profit organization that hosts the Wikimedia Sites, like Wikipedia, collects, uses, and shares information we receive from you." — That sounds really strange to me. What built the Wikimedia Sites? Our contributions to the project (i.e. content contributed by volunteers), and that's pretty obvious to the reader of this document. Reading [1] in isolation, information is hence understood in the sense of information about a public figure or a historical event. However, between [1,2] and [2,3,4], the meaning of "information" gradually shifts. Suddenly, "information" is no longer what is contributed to the projects but, in fact, "personal information." If I weren't sure that you're writing this policy in good faith, I'd probably interpret this as a (pretty obvious) rhetorical trick.

I see your point, Pajz. What would be your recommended rewrite? One possibility:

The Wikimedia movement is founded on a simple, but powerful principle: we can do more together than any of us can do alone. We cannot work collectively without gathering, sharing and analyzing information about our users as we seek new ways to make our Wikimedia Sites more useable, effective, safer, and useful.

We believe that information-gathering and use should go hand-in-hand with transparency. This Privacy Policy explains

Geoffbrigham (talk) 22:41, 18 December 2013 (UTC)

Yep, that's fine IMO. — Pajz (talk) 16:50, 19 December 2013 (UTC)

I will ask James to make the change (after Michelle gives her thumbs up). Thanks for the suggestion. Geoffbrigham (talk) 17:58, 19 December 2013 (UTC)

Done Jalexander--WMF 19:52, 19 December 2013 (UTC)

• "The Wikimedia Sites were primarily created to help you share your knowledge with the world, and we share your contributions because you have asked us to do so." — Really? As far as I'm aware, the Wikimedia Sites were primarily created to help you be able to access all knowledge of the world ("Imagine a world ..."). The sentence sounds like the sites were primarily a platform for users to express themselves whereas, in fact, I think it's quite clear that contributors are the means, not the end.

To be honest, I'm OK with this formulation. The Wikimedia vision is: "Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment." Consistent with this vision, the sites were created to allow users (like you) to "share [their] knowledge of the world." Also, a person's contributions are shared only when the user requests that we do so as part of this overall vision. I'm open to an alternative proposal that captures the needs of this paragraph, but for now I would personally leave it as it is. :) Geoffbrigham (talk) 23:01, 18 December 2013 (UTC)

Ah, never heard of that mission statement. What I had in mind was "Imagine a world in which every single person on the planet is given free access to the sum of all human knowledge. That's what we're doing." (https://en.wikiquote.org/wiki/Jimmy_Wales#Sourced) (Which makes sense.) Hmm. I don't like the mission statement either, but in this case it's outside the scope of this policy. — Pajz (talk) 16:50, 19 December 2013 (UTC)

Interesting. The nuances in the differences are meaningful. Here is the official vision statement (I think): http://wikimediafoundation.org/wiki/Vision I accordingly will leave this as it is. Geoffbrigham (talk) 17:58, 19 December 2013 (UTC)

• "Because everyone (not just lawyers) should be able to easily understand how and why their information is collected and used, we use common language instead of more formal terms. Here is a table of translations" — I don't quite see the connection between the first conditional clause and the presentation of a "table of translations". Actually, I was quite amused reading this passage. It sounds like "Hey, we want to make things really simple here, that's why we replaced everything difficult with a word, and here's the dictionary you need to understand these words". Which, of course, would be simplification voodoo. I think you should separate these statements. You first point is that you use common language, your second point is that, in order to avoid redundancy (or whatever), you prepend some definitions.

How about this:

Because everyone (not just lawyers) should be able to easily understand how and why their information is collected and used, we use common language instead of more formal terms throughout this Policy. To help ensure your understanding of some particular key terms, here is a table of translations:

Geoffbrigham (talk) 23:01, 18 December 2013 (UTC)

That's better. — Pajz (talk) 16:50, 19 December 2013 (UTC)

Great. I will ask for the change (as above). Geoffbrigham (talk) 17:58, 19 December 2013 (UTC)

Done Jalexander--WMF 19:57, 19 December 2013 (UTC)

Best, — Pajz (talk) 17:05, 13 December 2013 (UTC)

Short summaries of each section

Reading an entire privacy policy requires a lot of effort, even if it's well-written. Previously we had Rory to break up the sections and give you a pause while reading; now we only have the blue section icons, which I think are the bare minimum. I propose that we add back something to make reading more pleasant. One way to do that is 500px's short summaries of each section. What do you think? Can we do something similar? //Shell 09:59, 17 December 2013 (UTC)

Hi Shell! Thank you for the suggestion. We are working on drafting some summarizing bullet points to put into the left column and will put them up as soon as we have them ready. We would definitely appreciate your input (and input from others) on the bullet points once they are ready. Mpaulson (WMF) (talk) 20:39, 18 December 2013 (UTC)

Handling our user data - an appeal

Preface (Wikimedia Deutschland)

For several months, there have been regular discussions on data protection and the way Wikimedia deals with it, in the German-speaking community – one of the largest non-English-speaking communities in the Wikimedia movement. Of course, this particularly concerns people actively involved in Wikipedia, but also those active on other Wikimedia projects.

The German-speaking community has always been interested in data protection. However, this particular discussion was triggered when the Deep User Inspector tool on Tool Labs nullified a long-respected agreement in the Toolserver, that aggregated personalized data would only be available after an opt-in by the user.

As the Wikimedia Foundation is currently reviewing its privacy policy and has requested feedback and discussion her by 15 January, Wikimedia Deutschland has asked the community to draft a statement. The text presented below was largely written by User:NordNordWest and signed by almost 120 people involved in German Wikimedia projects. It highlights the many concerns and worries of the German-speaking community, so we believe it can enhance the discussion on these issues. We would like to thank everyone involved.

This text was published in German simultaneously in the Wikimedia Deutschland-blog and in the Kurier, an analogue to the English "Signpost". This translation has been additionally sent as a draft to the WMF movement-blog.

(preface Denis Barthel (WMDE) (talk), 20.12.)

Starting position

The revelations by Edward Snowden and the migration of programs from the Toolserver to ToolLabs prompted discussions among the community on the subject of user data and how to deal with it. On the one hand, a diverse range of security features are available to registered users:

• Users can register under a pseudonym.
• The IP address of registered users is not shown. Only users with CheckUser permission can see IP addresses.
• Users have a right to anonymity. This includes all types of personal data: names, age, background, gender, family status, occupation, level of education, religion, political views, sexual orientation, etc.
• As a direct reaction to Snowden’s revelations, the HTTPS protocol has been used as standard since summer 2013 (see m:HTTPS), so that, among other things, it should no longer be visible from outside which pages are called up by which users and what information is sent by a user.

On the other hand, however, all of a user’s contributions are recorded with exact timestamps. Access to this data is available to everyone and allows the creation of user profiles. While the tools were running on the Toolserver, user profiles could only be created from aggregated data with the consent of the user concerned (opt-in procedure). This was because the Toolserver was operated by Wikimedia Deutschland and therefore subject to German data protection law, one of the strictest in the world. However, evaluation tools that were independent of the Foundation and any of its chapters already existed.

One example is Wikichecker, which, however, only concerns English-language Wikipedia. The migration of programs to ToolLabs, which means that they no longer have to function in accordance with German data protection law, prompted a survey of whether a voluntary opt-in system should still be mandatory for X!’s Edit Counter or whether opt-in should be abandoned altogether. The survey resulted in a majority of 259 votes for keeping opt-in, with 26 users voting for replacing it with an opt-out solution and 195 in favor of removing it completely. As a direct reaction to these results, a new tool – Deep User Inspector – was programmed to provide aggregated user data across projects without giving users a chance to object. Alongside basic numbers of contributions, the tool also provides statistics on, for example, the times on weekdays when a user was active, lists of voting behavior, or a map showing the location of subjects on which the user has edited articles. This aggregation of data allows simple inferences to be made about each individual user. A cluster of edits on articles relating to a certain region, for example, makes it possible to deduce where the user most probably lives.

Problems

Every user knows that user data is recorded every time something is edited. However, there is a significant difference between a single data set and the aggregated presentation of this data. Aggregated data means that the user’s right to anonymity can be reduced, or, in the worst case, lost altogether. Here are some examples:

• A list of the times that a user edits often allows a deduction to be made as to the time zone where he or she lives.
• From the coordinates of articles that a user has edited, it is generally possible to determine the user’s location even more precisely. It would be rare for people to solely edit area X, when in fact they came from area Y.
• The most precise deductions can be made by analyzing the coordinates of a photo location, as it stands to reason that the user must have been physically present to take the photo.
• Places of origin and photo locations can reveal information on the user’s means of transport (e.g. whether someone owns a car), as well as on his or her routes and times of travel. This makes it possible to create movement profiles on users who upload a large number of photos.
• Time analyses of certain days of the year allow inferences to be drawn about a user’s family status. It is probable, for example, that those who tend not to edit during the school holidays are students, parents or teachers.
• Assumptions on religious orientation can also be made if a user tends not to edit on particular religious holidays.
• Foreign photo locations either reveal information about a user’s holiday destination, and therefore perhaps disclose something about his or her financial situation, or suggest that the user is a photographer.
• If users work in a country or a company where editing is prohibited during working hours, they are particularly vulnerable if the recorded time reveals that they have been editing during these hours. In the worst-case scenario, somebody who wishes to harm the user and knows extra information about his or her life (which is not unusual if someone has been an editor for several years) could pass this information on to the user’s employer. Disputes within Wikipedia would thus be carried over into real life.

Suggestions

Wikipedia is the fifth most visited website in the world. The way it treats its users therefore serves as an important example to others. It would be illogical and ridiculous to increase user protection on the one hand but, on the other hand, to allow users’ right to anonymity to be eroded. The most important asset that Wikipedia, Commons and other projects have is their users. They create the content that has ensured these projects’ success. But users are not content, and we should make sure that we protect them. The Wikimedia Foundation should commit to making the protection of its registered users a higher priority and should take the necessary steps to achieve this. Similarly to the regulations for the Toolserver, it should first require an opt-in for all the tools on its own servers that compile detailed aggregations of user data. Users could do this via their personal settings, for example. Since Wikipedia was founded in 2001, the project has grown without any urgent need for these kinds of tools, and at present there seems to be no reason why this should change in the future. By creating free content, the community enables Wikimedia to collect the donations needed to run WikiLabs. That this should lead to users loosing their right of anonymity, although the majority opposes this, is absurd. To ensure that user data are not evaluated on non-Wikimedia servers, the Foundation is asked to take the following steps:

• Wikipedia dumps should no longer contain any detailed user information. The license only requires the name of the author and not the time or the day when they edited.
• There should only be limited access to user data on the API.
• It might be worth considering whether or not it is necessary or consistent with project targets to store and display the IP addresses of registered users (if they are stored), as well as precise timestamps that are accurate to the minute of all their actions. The time limit here could be how long it reasonably takes CheckUsers to make a query. After all, data that are not available cannot be misused for other purposes.

Original signatures

1. Martina _Disk. 21:28, 24. Nov. 2013 (CET)
2. NNW 18:52, 26. Nov. 2013 (CET)
3. ireas :disk: 19:23, 26. Nov. 2013 (CET)
4. Henriette (Diskussion) 19:24, 26. Nov. 2013 (CET)
5. Raymond ^Disk. 08:38, 27. Nov. 2013 (CET)
6. Richard Zietz 22px|8)|link= 22:18, 27. Nov. 2013 (CET)
7. Alchemist-hp (Diskussion) 23:47, 27. Nov. 2013 (CET)
8. Lencer (Diskussion) 11:54, 28. Nov. 2013 (CET)
9. Smial (Diskussion) 00:09, 29. Nov. 2013 (CET)
10. Charlez k (Diskussion) 11:55, 29. Nov. 2013 (CET)
11. elya (Diskussion) 19:07, 29. Nov. 2013 (CET)
12. Krib (Diskussion) 20:26, 29. Nov. 2013 (CET)
13. Jbergner (Diskussion) 09:36, 30. Nov. 2013 (CET)
14. TMg 12:55, 30. Nov. 2013 (CET)
15. AFBorchert – D/B 21:22, 30. Nov. 2013 (CET)
16. −Sargoth 22:06, 2. Dez. 2013 (CET)
17. Hilarmont 09:27, 3. Dez. 2013 (CET)
18. --25px|verweis=Portal:Radsport Poldine - AHA 13:09, 3. Dez. 2013 (CET)
19. XenonX3 – (☎ – RIP Lady Whistler) 13:11, 3. Dez. 2013 (CET)
20. -- Ra'ike ^Disk. _LKU ^WPMin 13:19, 3. Dez. 2013 (CET)
21. --muns (Diskussion) 13:22, 3. Dez. 2013 (CET)
22. --Hubertl (Diskussion) 13:24, 3. Dez. 2013 (CET)
23. --Aschmidt (Diskussion) 13:28, 3. Dez. 2013 (CET)
24. Anika (Diskussion) 13:32, 3. Dez. 2013 (CET)
25. K@rl 13:34, 3. Dez. 2013 (CET)
26. --DaB. (Diskussion) 13:55, 3. Dez. 2013 (CET) (Auch wenn ich das mit den Dumps etwas übertrieben finde.)
27. --AndreasPraefcke (Diskussion) 14:05, 3. Dez. 2013 (CET) Gerade das mit den Dumps ist wichtig, und auch auf den Wikipedia-Websites sollte diese Info nicht angezeigt werden. So ungefähr (nicht genauer durchdacht, nur als ungefähre Idee): Edits von heute: wie gehabt sekundengenau angezeigt, Edits von dieser Woche: minutengenau, Edits der letzten sches Wochen: stundengenau, Edits der letzten 12 Monate: tagesgenau, Edits davor: monatsgenau – die Reihenfolge muss natürlich gewahrt werden; Edits und darauffolgende reine Reverts: ganz aus der Datenbank raus)

    Man sollte aber trotz berechtigter Interessen am Datenschutz nicht vergessen, dass diese Art der Datums-/Zeitbeschneidung ein zweischneidiges Schwert ist. Versionsgeschichtenimporte einerseits und URV-Prüfungen andererseits würden deutlich erschwert ;-) -- Ra'ike ^Disk. _LKU ^WPMin 14:19, 3. Dez. 2013 (CET) (wobei für letzteres eine tagesgenaue Anzeige für den Vergleich mit Webarchiv reichen würde)

28. --Mabschaaf 14:08, 3. Dez. 2013 (CET)
29. --Itti 14:28, 3. Dez. 2013 (CET)
30. ...Sicherlich ^Post 14:52, 3. Dez. 2013 (CET)
31. --Odeesi _{talk to me} ^{rate me} 16:29, 3. Dez. 2013 (CET)
32. --gbeckmann Diskussion 17:23, 3. Dez. 2013 (CET)
33. --Zinnmann d 17:24, 3. Dez. 2013 (CET)
34. --Kolossos 17:41, 3. Dez. 2013 (CET)
35. -- Andreas Werle (Diskussion) (heute mal "ohne" Zeitstempel...)
36. --Gleiberg (Diskussion) 18:03, 3. Dez. 2013 (CET)
37. --Jakob Gottfried (Diskussion) 18:30, 3. Dez. 2013 (CET)
38. --Wiegels „…“ 18:55, 3. Dez. 2013 (CET)
39. --Pyfisch (Diskussion) 20:29, 3. Dez. 2013 (CET)
40. -- NacowY ^Disk 23:01, 3. Dez. 2013 (CET)
41. -- RE rillke fragen? 23:17, 3. Dez. 2013 (CET) Ja. Natürlich nicht nur die API, sondern auch die "normalen Seiten" (index.php) sollten ein (sinnvolles) Limit haben. Eine Einschränkung von Endanwendungen durch Richtlinien lehne ich ab, genauso wie überstürztes Handeln. Man wird viel abwägen müssen und eventuell Ausnahmen für bestimmte Benutzergruppen schaffen müssen oder neue Wege, Daten darzustellen. Checkuser-Daten werden meines Wissens automatisch nach 3 Mon. gelöscht: S. User:Catfisheye/Fragen_zur_Checkusertätigkeit_auf_Commons#cite_ref-5
42. --Christian1985 (Disk) 23:25, 3. Dez. 2013 (CET)
43. --Jocian 04:45, 4. Dez. 2013 (CET)
44. -- CC 04:50, 4. Dez. 2013 (CET)
45. --Don-kun • Diskussion 07:10, 4. Dez. 2013 (CET)
46. --Zeitlupe (Diskussion) 09:09, 4. Dez. 2013 (CET)
47. --Geitost 09:25, 4. Dez. 2013 (CET)
48. Everywhere West (Diskussion) 09:29, 4. Dez. 2013 (CET)
49. -jkb- 09:29, 4. Dez. 2013 (CET)
50. -- Wurmkraut (Diskussion) 09:47, 4. Dez. 2013 (CET)
51. – Simplicius Hi… ho… Diderot! 09:53, 4. Dez. 2013 (CET)
52. --Hosse Talk 12:49, 4. Dez. 2013 (CET)
53. Port(u#o)s 12:57, 4. Dez. 2013 (CET)
54. --Howwi (Diskussion) 14:26, 4. Dez. 2013 (CET)
55.  — Felix Reimann ⚕ 17:17, 4. Dez. 2013 (CET)
56. --Bubo 容 18:30, 4. Dez. 2013 (CET)
57. --Coffins (Diskussion) 19:22, 4. Dez. 2013 (CET)
58. --Firefly05 (Diskussion) 20:09, 4. Dez. 2013 (CET)
59. Es geht darum, den Grundsatz und das Regel-Ausnahme-Schema klarzustellen. --Björn 20:13, 4. Dez. 2013 (CET)
60. --V ¿ 21:46, 4. Dez. 2013 (CET)
61. --Merlissimo 21:59, 4. Dez. 2013 (CET)
62. --Stefan »Στέφανος« ‽ 22:02, 4. Dez. 2013 (CET)
63. -<)kmk(>- (Diskussion) 22:57, 4. Dez. 2013 (CET)
64. --lutki (Diskussion) 23:06, 4. Dez. 2013 (CET)
65. -- Ukko 23:22, 4. Dez. 2013 (CET)
66. --Video2005 (Diskussion) 02:17, 5. Dez. 2013 (CET)
67. --Baumfreund-FFM (Diskussion) 07:30, 5. Dez. 2013 (CET)
68. --dealerofsalvation 07:35, 5. Dez. 2013 (CET)
69. --Gripweed (Diskussion) 09:32, 5. Dez. 2013 (CET)
70. --Sinuhe20 (Diskussion) 10:05, 5. Dez. 2013 (CET)
71. --PerfektesChaos 10:22, 5. Dez. 2013 (CET)
72. --Tkarcher (Diskussion) 13:51, 5. Dez. 2013 (CET)
73. --BishkekRocks (Diskussion) 14:43, 5. Dez. 2013 (CET)
74. --PG ein miesepetriger Badener 15:34, 5. Dez. 2013 (CET)
75. --He3nry Disk. 16:32, 5. Dez. 2013 (CET)
76. --Sjokolade (Diskussion) 18:15, 5. Dez. 2013 (CET)
77. --Lienhard Schulz Post 18:43, 5. Dez. 2013 (CET)
78. --Kein Einstein (Diskussion) 19:35, 5. Dez. 2013 (CET)
79. --Stefan (Diskussion) 22:19, 5. Dez. 2013 (CET)
80. --Rauenstein 22:58, 5. Dez. 2013 (CET)
81. --Anka ☺☻Wau! 23:45, 5. Dez. 2013 (CET)
82. --es grüßt ein Fröhlicher DeutscherΛV^¿? 06:42, 6. Dez. 2013 (CET)
83. --Doc.Heintz 08:55, 6. Dez. 2013 (CET)
84. --Shisha-Tom ohne Uhrzeit, 6. Dez. 2013
85. --BesondereUmstaende (Diskussion) 14:57, 6. Dez. 2013 (CET)
86. --Varina (Diskussion) 16:37, 6. Dez. 2013 (CET)
87. --Studmult (Diskussion) 17:30, 6. Dez. 2013 (CET)
88. --GT1976 (Diskussion) 20:51, 6. Dez. 2013 (CET)
89. --Wikifreund (Diskussion) 22:04, 6. Dez. 2013 (CET)
90. --Wnme 23:07, 6. Dez. 2013 (CET)
91. -- ST ○ 00:47, 7. Dez. 2013 (CET)
92. --Flo Beck (Diskussion) 13:45, 7. Dez. 2013 (CET)
93. IW 16:34, 7. Dez. 2013 (CET)
94. --Blech (Diskussion) 17:48, 7. Dez. 2013 (CET)
95. --Falkmart (Diskussion) 18:21, 8. Dez. 2013 (CET)
96. --Partynia ^{∞ RM} 22:53, 8. Dez. 2013 (CET)
97. --ElRaki 01:09, 9. Dez. 2013 (CET) so viele Benutzerdaten wie möglich löschen/so wenig Benutzerdaten wie unbedingt nötig behalten
98. --user:MoSchle--MoSchle (Diskussion) 03:57, 9. Dez. 2013 (CET)
99. --Daniel749 Disk. (ST–WPST) 16:32, 9. Dez. 2013 (CET)
100. --Knopfkind 21:19, 9. Dez. 2013 (CET)
101. --Saibot2 (Diskussion) 23:14, 9. Dez. 2013 (CET)
102. --Atlasowa (Diskussion) 15:03, 10. Dez. 2013 (CET) Der Aufruf richtet sich aber ebenso an WMDE, die ja die Abschaffung des Toolservers beschlossen hat und damit die Entwicklung zum DUI ermöglicht hat. Nur Briefträger zu WMF sein ist zu wenig. Wenn WMDE sich Gutachten zur Spendenkultur in Deutschland schreiben lassen kann, um beim WMF Lobbyismus für eine eigene Spendensammlung zu machen, dann kann WMDE ja wohl auch Gutachten zum dt./europ. Datenschutz in Auftrag geben.
103. ----Fussballmann ^Kontakt 21:38, 10. Dez. 2013 (CET)
104. --Steinsplitter (Disk) 23:40, 10. Dez. 2013 (CET)
105. --Gps-for-five (Diskussion) 03:03, 11. Dez. 2013 (CET)
106. --Kolja21 (Diskussion) 03:55, 11. Dez. 2013 (CET)
107. --Laibwächter (Diskussion) 09:50, 11. Dez. 2013 (CET)
108. -- Achim Raschka (Diskussion) 15:18, 11. Dez. 2013 (CET)
109. --Alabasterstein (Diskussion) 20:32, 13. Dez. 2013 (CET)
110. --Grueslayer Diskussion 10:51, 14. Dez. 2013 (CET)
111. Daten nur erheben, wenn unbedingt für den Betrieb (bzw. rechtlich) notwendig. Alles andere sollte gar nicht erhoben werden. Die Rückschlüsse auf die Zeitzonen und das Wohngebiet (häufig auch von Benutzern selbst angegeben) sehe ich gar nicht als gravierend an. Vielmehr, dass im Wiki alles protokolliert wird. Die halte ich nicht für nötig. Wer muss schon wissen, wer vor 10 Jahren wo genau editiert hat. Nach einem Jahr sollte die Vorratsdatenspeicherung anonymisiert werden (also in der Artikelhistorie kanns dirn bleiben, da nötig, jedoch nicht in der Benutzer-Beitragsliste).--Alberto568 (Diskussion) 21:51, 14. Dez. 2013 (CET)
112. --Horgner (Diskussion) 15:48, 16. Dez. 2013 (CET)
113. --Oursana (Diskussion) 21:52, 16. Dez. 2013 (CET)
114. --Meslier (Diskussion) 23:53, 16. Dez. 2013 (CET)
115. -- Martin Bahmann (Diskussion) 09:20, 18. Dez. 2013 (CET)
116. —DerHexer (Disk., Bew.) 15:24, 19. Dez. 2013 (CET)
117. —Neotarf (Diskussion) 01:58, 20. Dez. 2013 (CET)
118. --Lutheraner (Diskussion) 13:17, 20. Dez. 2013 (CET)
119. --Lienhard Schulz (talk) 07:53, 21 December 2013 (UTC)
120. --Brainswiffer (talk) 16:33, 1 January 2014 (UTC)

Comments

Can WMDE get an EU lawyer to assess whether such analysis of data is lawful under the current or draft EU directive and what it would take to respect it? I see that the draft contains some provisions on "analytics"; if the WMF adhered to EU standards (see also #Localisation des serveurs aux Etats-Unis et loi applicable bis) we might automatically solve such [IMHO minor] problems too. --Nemo 16:12, 20 December 2013 (UTC)

See also #Please_add_concerning_user_profiles (permalink, s) and #Generation_of_editor_profiles (permalink, s). PiRSquared17 (talk) 20:36, 20 December 2013 (UTC)

On a more personal note than the official response below, I shall repeat here advice I have regularly given to editors on the English Wikipedia in my capacity as Arbitrator: "Editing a public wiki is an inherently public activity, akin to participating in a meeting in a public place. While we place no requirement that you identify yourself or give any details about yourself to participate – and indeed do our best to allow you to remain pseudonymous – we cannot prevent bystanders from recognizing you by other methods. If the possibility of being recognized places you in danger or is not acceptable to you, then you should not involve yourself in public activities – including editing Wikipedia." MPelletier (WMF) (talk) 21:10, 20 December 2013 (UTC)

We can prevent creating user profiles by aggregating data. It has been done at the toolserver. It can be done at WikiLabs. NNW (talk) 21:29, 20 December 2013 (UTC)

No, you cannot. Those tools existed anyways, just elsewhere. You cannot prevent aggregation of public data without making that data not public anymore; including on the website itself (remove it from the API and people will just screen scrape for it) and in the dumps. Transparency isn't an accident, it's one of the basic principles of wikis in general and of the projects in particular. MPelletier (WMF) (talk) 18:12, 21 December 2013 (UTC)

Laws can prevent it though :) (looks like it may happen rather soon in EU). If everyone here takes extremist stances and collate everything as if there were no differences between publishing data and using it, or querying a database and making someone else query it, then it will be very hard to have any dialogue. To reiterate a point above, if a Wikimedia project includes Google Analytics and sends all private data to Google, our users don't care whether it was put by the WMF or a sysop, they just want it removed. --Nemo 18:23, 21 December 2013 (UTC)

No, actually, laws do not. The directive everyone refers to does not have anything to say about what people are allowed to do with publicly available information, but about private information which edit times most definitely are not.

Contrarywise, whether someone accesses a tool (or project page) is private information and this is why the rules already do forbid disclosing it; so your Google Analytics example is a good illustration of what we do already forbid. MPelletier (WMF) (talk) 20:55, 21 December 2013 (UTC)

I'm glad you have such legal certainties; I do not and I asked lawyers to comment, in the meanwhile I only said that law can forbid something if they wish (this seems rather obvious to me). As for Google Analytics, of course it's not the same thing, but it was just an example where it's easier to agree that it doesn't matter whether it's WMF or an user to place it on our servers (though the proposed draft explicitly does not cover the case of a sysop adding Google Analytics to a project). --Nemo 22:33, 21 December 2013 (UTC)

"your Google Analytics example is a good illustration of what we do already forbid." Oh, really? Just a short while ago a Software Engineer on the Wikimedia Foundation's Analytics team wrote about Analytics for tools hosted on labs?: "I don't think there are any technical reasons people can't use Google Analytics on a Labs instance. The only thing I can think of is that it'd be nice if people used something Open Source like PiWik. But I'll ask and report back in a bit." > later > "Google Analytics or any other analytics solution is strictly forbidden by Labs rules *unless* there's a landing page with a disclaimer that if the user continues, their behavior will be tracked." So that's the "good illustration of what we do already forbid": just put up a disclaimer. --Atlasowa (talk) 00:58, 22 December 2013 (UTC)

"Those tools existed anyways, just elsewhere.": This is told so often and it is still no good point. There are so many bridges and there are so many people crashing their cars into them. Does that mean we have to do it, too? A first step could be just to stop creating user profile on WMF servers. It was the end of the Toolserver limitations that started all the discussion. Of course there will be always someone who can and will do it somewhere but that is no reason to invite people to do it here on servers that are paid with donations for our work. I want to create an encyclopedia, not to collect money for spying on me. NNW (talk) 12:15, 22 December 2013 (UTC)

Additional signatures

1. --Geolina163 (talk) 16:06, 20 December 2013 (UTC)
2. --Density (talk) 16:35, 20 December 2013 (UTC)
3. --Minihaa (talk) 16:57, 20 December 2013 (UTC) bitte um Datensparsamkeit.
4. --Theaitetos (talk) 17:08, 20 December 2013 (UTC)
5. -- Sir Gawain (talk) 17:17, 20 December 2013 (UTC)
6. --1971markus (talk) 18:26, 20 December 2013 (UTC)
7. --Goldzahn (talk) 19:22, 20 December 2013 (UTC)
8. --Spischot (talk) 21:38, 20 December 2013 (UTC)
9. --Bomzibar (talk) 22:43, 20 December 2013 (UTC)

   --Charlez k (talk) 22:51, 20 December 2013 (UTC) already signed, see above (Original signatures) --Krib (talk) 23:05, 20 December 2013 (UTC)

10. --J. Patrick Fischer (talk) 09:14, 21 December 2013 (UTC)
11. --Túrelio (talk) 15:07, 21 December 2013 (UTC)
12. --Poupou l'quourouce (talk) 17:46, 21 December 2013 (UTC)
13. --Nordlicht8 (talk) 21:54, 21 December 2013 (UTC)
14. -- FelixReimann (talk) 11:16, 22 December 2013 (UTC)
15. --Asio otus (talk) 11:54, 22 December 2013 (UTC)
16. --Rosenzweig (talk) 12:26, 22 December 2013 (UTC)
17. --Mellebga (talk) 13:47, 25 December 2013 (UTC)
18. --Pasleim (talk) 15:24, 26 December 2013 (UTC)
19. Elvaube ^?! 13:32, 29 December 2013 (UTC)
20. --Zipferlak (talk) 13:18, 2 January 2014 (UTC)
21. --Gerbil (talk) 15:04, 5 January 2014 (UTC)

Response

Please note the response by Tfinc above in the Generation of editor profiles and my follow up to it. Obfuscating user contributions data or limiting our existing export will not happen. The Wikipedia projects are wikis, edits to it are by nature public activities that have always been, and always must be, available for scrutiny. MPelletier (WMF) (talk) 21:10, 20 December 2013 (UTC)

We don't need to keep around timestamps down to a fraction of a second forever. PiRSquared17 (talk) 21:13, 20 December 2013 (UTC)

Not sure about that. I wonder if de.wiki also has agreed to a decrease of its own right to fork, a right which they constantly use as a threat. Making dumps unusable would greatly reduce the contractual power of de.wiki, dunno if they really want it. --Nemo 21:43, 20 December 2013 (UTC)

While we believe this proposal is based on legitimate concerns, we want to highlight some of the practical considerations of such a proposal. Due to the holidays, we’ve addressed this only briefly, but we hope it serves to explain our perspective.

In summary, public access to metadata around page creation and editing is critical to the health and well-being of the site and is used in numerous places and for numerous use cases:

• Protecting against vandalism, incorrect and inappropriate content: there are several bots that patrol Wikipedia’s articles that protect the site against these events. Without public access to metadata, the effectiveness of these bots will be much reduced, and it is impossible for humans to perform these tasks at scale.
• Community workflows: Processes that contribute to the quality and governance of the project will also be affected: blocking users, assessing adminship nominations, determining eligible participants in article deletion discussions.
• Powertools: certain bulk processes will be broken without public access to this metadata.
• Research: researchers around the world use this public metadata for analysis that is useful for both to the site and the movement. It is essential that they continue to have access.
• Forking: In order to have a full copy of our projects and their change histories all metadata needs to be exposed alongside content.

In summary, public and open-licensed revision metadata is vital to the technical and social functioning of Wikipedia, and any removal of this data would have serious impact on a number of processes and actions critical to the project. Tfinc (talk) 00:54, 21 December 2013 (UTC)

How was it possible for Wikipedia to grow 13 years without aggregating user data? What has changed since the start of WikiLabs that this is necessary? Why is it necessary for creating an encyclopedia to know the exact second of my edit 5 years ago? Where does the licenses say that it is necessary that the exact second of my edit has to be part of a fork? NNW (talk) 10:38, 21 December 2013 (UTC)

I understand the part on aggregation and analytics, but the point about seconds is quite silly: sure, seconds could not be necessary in some ideal version of MediaWiki where they don't matter; but they also don't matter at all for your privacy. To avoid inferences about timezone we should remove hours of the day, not seconds. --Nemo 18:12, 21 December 2013 (UTC)

If you read the appeal above you will see that I do know that talking about seconds is silly. But it is senseless to start with hours when some people don't understand the basic proplem with that data. Seconds just carry the topic to extremes so it may get understood that no one needs five year old timestamps for preventing vandalism or whatever. NNW (talk) 12:02, 22 December 2013 (UTC)

Actually, I read it but I don't see that. The text does not specify what level of precision in timestamps you want to achieve. --Nemo 10:19, 29 December 2013 (UTC)

I cannot offer a complete solution to this problem. The appeal in a nutshell is As much transparency as necessary, as much privacy as possible. I am not that much into technical questions. Perhaps some of the suggestions cannot be implemented for some technical reasons I don't know. Perhaps there are some better ways to keep users’ anonymity. All I did was centralizing a growing dissatisfaction about the way our data is handled and to start a discussion about it. NNW (talk) 11:56, 29 December 2013 (UTC)

Thanks. This is a frank and reasonable way to frame it. --Nemo 12:03, 29 December 2013 (UTC)

It's true that most actions of plain vandalism can be efficiently performed if we know the exact order of events, in order to revert edits correctly.

But the precision of timestamps is needed for things where there are battles related to the order of events in the history, for example battles of licences: we need to be able to prove the anteriority of a work. Precise timestamps are then needed, but we could hide this info by replacing these exact timestamps by digital signatures generated by the server, and making an API reserved to CheckUser admins, that would be able to assert which event occured before another one. IT could also be used for anonimizing contributions made by users that asked their account to be deleted and their past contributions to be fully anonymized (while maintaining the validity of their past work and provability and permanence/irrevocability of their agreed licences).

Other open projects have experienced this issue when it was difficult to assert the licencing terms (for example on OpenStreetMap before it changed its licence from CC-BY-SA to ODbL for new controbutions, and needed to check its data according to the time the user actually accepted the new Contributor Terms and actually accepted to relicence, or not, its past contributions, in order to cleanup the active online database then published exclusively using the new licence: this did not mean that the old database was illegal, but that it has been frozen at a precise timestamp, and all further edits made exclusively on the new licence that users had to accept beore continuing making new edits).

Precise timestamps are then needed for long terms, and this is not just ot fight active abuses and spams (with bots interested in a short period of time not exceeding one month; after that time, a bot alone cannot work reliably without human review to restrict its searches, if something must be reverted, or in case of doubt, with all user rights transferred to a special aggregated/anonymized user account detached from the original user).

Note that timestamps and goelocation data stored in media files are a problem, users chsould have a way to cleanup a media file from these data by reducng the precision (for example only the date, or just the year, and a weaker geolocation, or deletion of unnecessary metadata such as stored hardware ID's of digital cameras, version of the tool used to modify the photos, possibly online by using external services like Google Picasa), or other kind of information which may store such data using stealth technics such as steganography (using technics that will be discovered only years laters): Commons should have a tool to inspect these metadata, to allow the orogonal uploaded to cleanup these hidden details, to be dropped permanently by dropping also the stored old versions of these media files.

Fully anonimizing photos and videos is a really difficult challenge (it is far easier to do it on graphics with reduced color spaces or with vector graphics accepting some randomized alteration of any unnecessary geometric precision), as things initially invisible may be revealed later by new procesing algorithms (like those already used now by Google which can precisely identify places and people by looking at some small portions of photos or assembling multiple ones from the same "exposed public user account" and in the same timestamp period, or photos/videos participating to the same topic elsewhere)!

Note that these media analysis tools may also be used to "assert" the licencing terms and legitimate author of a work, that has been reused elsewhere without permission (and there are already examples where legitimate Wikimedia contents have been attacked later by abusers trying to take the authorship and building a fake anteriority). This has already done severe damages in Wikimedia projects (for example when several editions of WikiQuotes had to be fully erased and restarted from zero, a few years ago, when we could no longer prove the origin or anteriority of a work). verdy_p (talk) 13:33, 22 December 2013 (UTC)

Question of context

AxelBoldt, NNW, and everyone else...

I regret to admit that the context in which the members of the appeal came up with the feature request is unclear to me due to the language barrier. Please provide me with links of where the opt-out idea originated; even if they're in German, I will be grateful as I would not have to try to search for the discussion myself. Gryllida (talk) 07:20, 31 December 2013 (UTC)

As far as I know the opt-out idea was made by Cyberpower678 first when he started the RFC for X!'s Edit Counter [6]. Such tools at the toolserver always had an opt-in (also as far as I know). NNW (talk) 13:08, 31 December 2013 (UTC)

NNW, is there a place lack of opt-in feature was discussed, first time, for the DUI tool specifically? Gryllida (talk) 15:13, 31 December 2013 (UTC)

Gryllida, the DUI was the direct result of the RFC for X!'s Edit Counter. Any opt-in/opt-out/nothing-at-all discussions were held there. As Ricordisamoa refused to change anything (see link in the thread below) there was nothing left to discuss. Some reactions to his tool can be found at User talk:Ricordisamoa#Deep user inspector. NNW (talk) 15:40, 31 December 2013 (UTC)

NNW, «the DUI was the direct result of the RFC for X!'s Edit Counter» is a useful observation. ☺ Where can I see evidence for that, for reference, as it appears to be of relevance to this thread? Gryllida (talk) 15:56, 31 December 2013 (UTC)

[7]. NNW (talk) 16:05, 31 December 2013 (UTC)

NNW, you have linked me to the RFC text at the initial stage while its discussion section is empty. Community views could be of interest in this discussion though. ☺ For me to not go through the history manually, could you please locate the RFC in an archive and link me to that? Gryllida (talk) 15:56, 31 December 2013 (UTC)

Ah, the latest revision appears to contain the archive. Thanks! ☺ Gryllida (talk) 15:58, 31 December 2013 (UTC)

Even though a translated message about the RfC was spammed to all wikis (by me), most commenters seem to be from enwiki or dewiki. I'd say dewiki mainly wanted to keep opt-in, enwiki wanted to remove it or use opt-out, which is not surprising. PiRSquared17 (talk) 23:55, 1 January 2014 (UTC)

NNWThanks for the context. It appears that the tool functions as a proxy to already available information, and the WMF lack authority to eliminate it entirely, such as if it were hosted externally. Hence it appears useless for them to add actionable clauses about it into their privacy policy.

I only see work on an Externsion as a last resort, for the DUI tool to fail to function at the wikis that choose to request such extension with community consencus. If the community is willing to experiment, the WMF labs resources are available for collaborative community work on it. Gryllida (talk) 09:22, 3 January 2014 (UTC)

Note on Labs Terms / Response to NNW

Hi, NNW: If you are asking here about the change from Toolserver to Labs about when “profiling tools” are allowed, we made the change because the edit information has always been transparently available, so the Toolserver policy was not effective in preventing “profiling” - tools like X edit counter could be (and were) built on other servers. As has been suggested above, since the policy was ineffective, we removed it.

However, this change was never intended to allow anarchy. The current Labs terms of use allows WMF to take down tools, including in response to a community process like the one that occurred for X edit counter. Would it resolve some of your concerns if the Labs terms made that more obvious? For example, we could change the last sentence of this section from:

If you violate this policy ... any projects you run on Labs, can be suspended or terminated. If necessary, the Wikimedia Foundation can also do this in its sole discretion.

to:

If you violate this policy ... any projects you run on Labs, can be suspended or terminated. The Wikimedia Foundation can also suspend or terminate a tool or account at its discretion, such as in response to a community discussion on meta.wikimedia.org.

I think this approach is better than a blanket ban. First, where there is a legitimate and widely-felt community concern that a particular tool is unacceptable, it allows that tool to be dealt with appropriately. Second, it encourages development to happen on Labs, which ultimately gives the community more leverage and control than when tools are built on third-party servers. (For example, tools built on Labs have default filtering of IP addresses to protect users - something that doesn’t automatically happen for tools built elsewhere. So we should encourage use of Labs.) Third, it encourages tool developers to be bold - which is important when encouraging experimentation and innovation. Finally, it allows us to discuss the advantages and disadvantages of specific, actual tools, and allows people to test the features before discussing them, which makes for a more constructive and efficient discussion.

Curious to hear what you (and others) think of this idea. Thanks.-LVilla (WMF) (talk) 00:02, 24 December 2013 (UTC)

Is there a need in distinguishing WMF's role in administering Labs tools? I would only stress the requirement of Labs Tools to obey this policy, here, and link to a Labs policy on smooth escalation (ask tool author; discuss in community; ask Labs admins; ask WMF). Gryllida (talk) 05:14, 24 December 2013 (UTC)

WMF is called out separately in the policy because WMF employees ultimately have control (root access, physical control) to the Labs servers, and so ultimately have more power than others. (I think Coren has been recruiting volunteer roots, which changes things a bit, but ultimately WMF still owns the machines, pays for the network services, etc.) I agree that the right order for conversation is probably tool author -> community -> admins, and that the right place for that is on in the terms of use but an informal policy/guideline on wikitech. -LVilla (WMF) (talk) 17:15, 24 December 2013 (UTC)

Yah, I just wanted to propose that the policy references both concepts (WMF's ultimate control, and the gradual escalation process) so the users don't assume that appealing to WMF is the only way. Gryllida (talk) 08:38, 25 December 2013 (UTC)

As I mentioned elsewhere on this page, the talk about "community consensus" raises questions such as "which community?" and "what happens when different communities disagree?" Anomie (talk) 14:30, 24 December 2013 (UTC)

Right, which is why I didn't propose anything specific about that for the ToU- meta is just an example. Ultimately it'll have to be a case-by-case judgment. -LVilla (WMF) (talk) 17:15, 24 December 2013 (UTC)

I would perhaps remove the "on Meta" bit then since it bears no useful meaning. «... such as in response to a community discussion.» looks complete to me. There doesn't even have to be a discussion in my view: a single user privately contacting WMF could be enough, granted his report of abuse is accurate. «... such as in response to community feedback.» could be more meaningful. Gryllida (talk) 08:38, 25 December 2013 (UTC)

This is meant as an example ("such as"), so I think leaving the reference to meta in is OK. Also, this is in addition to the normal reasons for suspension. For the normal reasons for suspension, a report by a single person would be fine, but I think in most cases this sort of discretion will be exercised only after community discussion and consultation, so I think the reference to discussion is a better example than saying "feedback".-LVilla (WMF) (talk) 22:28, 31 December 2013 (UTC)

I am referring to this argument from above: we made the change because the edit information has always been transparently available, so the Toolserver policy was not effective. The position that any analysis that can be performed by a third party should also be allowable on WMF servers with WMF resources is not convincing. It is clearly possible for a third party to perform comprehensive and intrusive user profiling by collating edit data without the user's prior consent. We could (and should!) still prohibit it on our servers and by our terms-of-use policy. (A different example: it's clearly possible for a third party running a screen scraper to construct a conveniently browsable database of all edits that have ever been oversighted; this doesn't mean WMF should allow it and finance it.) Now, why should this kind of user profiling be prohibited by WMF? Because WMF lives on the goodwill of its editors, and editor NNW above put it best: "I want to create an encyclopedia, not to collect money for spying on me." AxelBoldt (talk) 18:15, 24 December 2013 (UTC)

You're right, but I think removed (oversaught) edits are out of question here. Whatever else is available is available, and allowing to collect freely available information programmatically sounds reasonable to me. Gryllida (talk) 08:38, 25 December 2013 (UTC)

It's not reasonable if the editors don't want it and if it doesn't further any identifiable objective of the foundation. In fact it is not only unreasonable but it's a misuse of donor funds. AxelBoldt (talk) 22:28, 25 December 2013 (UTC)

You should be interested in contributing to the #Tool_settings section below. Gryllida (talk) 01:56, 28 December 2013 (UTC)

Hello LVilla (WMF)! Your suggestion means that any tool that will be programmed in future has to be checked and – if someone things that it is necessary – has to be discussed individually. My experiences until now: "the community should not have any say in the matter" and a quite short discussion "Technically feasible, legally okay... but want tools do we want?" started at lists.wikimedia.org. If we want it that way we will have to define who is "community". Is it the sum of all users of all WMF projects? Can single projects or single users declare to keep a tool (e.g. en:WP voted for no opt-out or opt-in for X!'s Edit Counter but that would mean that my edits there will be used in that tool although I deny it completely for my account)? Which way will we come to a decision: simple majority or best arguments (and who will decide then)? Does a community vote for tool X mean that there is no chance for a tool Y to try it a second time or do we have to discuss it again and again?

We have to be aware of our different cultures of handling private data or even defining what's private and what's not. Labs "doesn't like" (nice term!) "harmful activity" and "misuse of private information". US law obviously doesn't evaluate aggregating data as misuse, I do. We discuss about necessary "transparency" but do not have a definition for it. The time logs of my edits five years ago seem to be important but you don't want to know my name, my address, my sex, my age, my way how I earn my money… which would make my edits, my intentions and my possible vandalism much more transparent than any time log. Some say "the more transparency the better" but this is a discussion of the happy few – but dominating – who live in North America and Western Europe. I think we also should think of those users who live in the Global South and want to edit problematic topics (religion, sexuality…). For those aggregated user profiles may become a real problem and they will always be a minority in any discussion. NNW (talk) 17:56, 28 December 2013 (UTC)

Everyone involved is aware that privacy values vary a great deal from community to community; but it seems very ill-advised to give the most restrictive standards a veto over the discussion, in practice and in principle. A clear parallel with the discussion over images can be drawn: while it would have been possible to restrict our standards to the subset deemed acceptable by all possible visitors, to do so would have greatly impoverished us. The same goes for usage of public data: we should foster an encourage new creative uses; not attempt (and fail) to preemptively restrict new tools to the minuscule subset nobody could raise an objection to. This does not preclude acting to discourage or disable a tool the community at large objects to – and the Foundation will be responsive to such concerns – but it does mean that this is not something that can be done with blanket bans.

To answer your more explicit questions, the answer will generally be "it depends" (unsatisfying as this sounds). Ultimately yes, the final arbiter will be the Foundation; but whether or not we intervene is dependent entirely on context as a whole; who objects, why, and what could be done to address those concerns. MPelletier (WMF) (talk) 00:48, 1 January 2014 (UTC)

So for programmers sky's the limit, it's to the community to find out which tool might violate their rights and to discuss this again and again and again because every tool has to be dealt anew. The community has to accept that in the end a RFC like for X!’s Edit Counter is just a waste of time and that programmers – of course – are not interested in any discussion or compromise because it might cut their tools. WMF is in the comfort position that Meta is in the focus of only very few users and the privacy policy does not apply to Labs. It would be fair to admit that under these circumstances WP:ANON becomes absurd and in near future – with more powerful tools – a lie. I understood "The Wikimedia Foundation, Inc. is a nonprofit charitable organization dedicated to encouraging the growth, development and distribution of free, multilingual, educational content" as "free and multilingual and educational content" but a user profile generated with my editing behaviour isn't educational. NNW (talk) 13:50, 4 January 2014 (UTC)

Questions from Gryllida

Implementation as Extension

This requests to conceal time of an edit. Would any of the supporters of the appeal be willing to demonstrate a working wiki with the requested change implemented as an Extension which discards edit time where needed? If sufficiently safe and secure, it could be added to a local German wiki by request of the community, and considered by other wiki communities later on. Many thanks. Gryllida (talk) 04:43, 24 December 2013 (UTC)

Tool settings

Have you considered requesting the Tool author to add an opt-out (or opt-in, as desired) option at a suitable scope? Gryllida (talk) 04:45, 24 December 2013 (UTC)

Example: editor stats:
«Note, if you don't want your name on this list, please add your name to [[User:Bawolff/edit-stat-opt-out]]».
--Gryllida (talk) 02:14, 28 December 2013 (UTC)

FYI: The tool address is here. It is not mentioned in the appeal text. (I have notified the tool author, Ricordisamoa, of this discussion and potentially desired feature.) Gryllida (talk) 02:20, 28 December 2013 (UTC)

User:Ricordisamoa deliberately ignored the idea of an opt-in or opt-out and there is no chance to discuss anything: There's no private data collection, and only WMF could prevent such tools from being hosted on their servers: the community should not have any say in the matter. For complete discussion read Talk:Requests for comment/X!'s Edit Counter#Few questions. NNW (talk) 16:29, 28 December 2013 (UTC)

@Gryllida and NordNordWest: of course I accept community suggestions (e.g. for improvements to the tool) but the WMF only is competent about legal matters concerning Wikimedia Tool Labs. If there should be any actions, they will have to be taken by the WMF itself. See also [8]. --Ricordisamoa 03:04, 29 December 2013 (UTC)

Ricordisamoa, would you not be willing to add an opt-out? I would desire it be solved without legal actions or escalation, as it appears to be something within your power and ability, and many users want it. (It seems OK to decline OPT-IN feature request.) Gryllida (talk) 09:07, 29 December 2013 (UTC)

@Gryllida: No. --Ricordisamoa 16:44, 30 December 2013 (UTC)

Ricordisamoa, I understand your view. It might make sense to document that in FAQ, if not already, at leisure. I appreciate you being responsive. Gryllida (talk) 07:17, 31 December 2013 (UTC)

As long as WMF wants to encourage programmers to do anything as long as it is legally there is no reason for programmers to limit the capabilities of their tools. "Community" is just a word which can be ignored very easily when "community" wants to cut capabilities. Only "improvements" will be accepted and "improvements" mean "more, more, more". NNW (talk) 14:00, 4 January 2014 (UTC)

Discussion on same topic in other locations

Note that this issue has also been discussed in #Generation_of_editor_profiles and #Please_add_concerning_user_profiles. For a full history of this topic, please make sure to read those sections as well. —LVilla (WMF) (talk) 00:36, 8 January 2014 (UTC)

(Technical:) Cannot translate navigation box title

The following discussion is closed: closed because discussion appears resolved/done please reopen if not

---

Hi, I can't find the message that corresponds to "More On What This Privacy Policy Doesn’t Cover" in the original. — Pajz (talk) 12:25, 26 December 2013 (UTC)

It's the first search result for the string.[9] Or, just use the translation link provided at the top of all the pages related to this draft, Special:Translate/agg-Privacy_policy_2014_draft. --Nemo 22:19, 30 December 2013 (UTC)

When I click on "German" under "Other languages:", I get to Datenschutzrichtlinie. When I click on "Translate" in the upper bar, I cannot find untranslated messages at all. Similarly, "translate this page" gets me to an empty page. This is completely confusing. — Pajz (talk) 23:42, 30 December 2013 (UTC)

(resolved, — Pajz (talk) 23:42, 30 December 2013 (UTC))

Google Analytics, GitHub ribbon, Facebook like button, etc.

See also Exclusion of on-wiki actions from privacy policy, "Wikimedia Sites", Revision of "What This Privacy Policy Doesn’t Cover"

If a user wants to include Google Analytics, the GitHub ribbon, a Facebook like button, etc., does the proposed Wikimedia privacy policy forbid that? http://status.wikimedia.org/ is an example of a domain that currently loads Google Analytics. https://tools.wmflabs.org/ricordisamoa/dui/ is an example of a domain that currently loads the GitHub ribbon. --MZMcBride (talk) 02:52, 30 December 2013 (UTC)

Does github actually recommend hotlinking? PiRSquared17 (talk) 02:59, 30 December 2013 (UTC)

Dunno. In this case, it looks like it's GitHub account on Amazon Web Services, maybe? The relevant HTML is pasted below. --MZMcBride (talk) 05:28, 30 December 2013 (UTC)

<a href="//github.com/ricordisamoa/labs/tree/master/dui"><img style="position: fixed; top: 0; right: 0; border: 0;" src="//s3.amazonaws.com/github/ribbons/forkme_right_orange_ff7600.png" alt="Fork me on GitHub"></a>

Third-party cookies are forbidden. So as long as facebook/google cant sneak in one of those alternate tracking systems, your question is pretty much answered. Alexpl (talk) 10:15, 30 December 2013 (UTC)

Not really. I think you may be conflating cookies and requests. --MZMcBride (talk) 23:21, 1 January 2014 (UTC)

Google/Amazon can still track the IPs, visit times, etc. I think they might also get the URL of the page the user was visiting, but I'm not an expert in HTTP stuff. PiRSquared17 (talk) 23:41, 1 January 2014 (UTC)

In either case, I agree that the policy should address this. Either explicitly allow or disallow this so we don't have to have this discussion on every tool. PiRSquared17 (talk) 23:37, 1 January 2014 (UTC)

The draft policy very clearly allows it. Everything is allowed, as long as it's done by a sysop or third party e.g. on a MediaWiki:Common.js file or on non-WMF servers, or by a non-WMF tool maintainer. Adding Google Analytics to a Wikimedia project is not disallowed etc. --Nemo 23:40, 1 January 2014 (UTC)

Seriously? I can see allowing it on Labs, perhaps, but we definitely should not allow sysops to track readers. PiRSquared17 (talk) 23:42, 1 January 2014 (UTC)

Sure. The language was changed a bit in latest revisions but the substance is still the same: «situations are not covered by our Privacy Policy [...] Third-party data-collecting tools that are placed on Wikimedia Sites by volunteers or other third parties». Those may be graciously removed on request but it would not be a legal obligation. --Nemo 00:09, 2 January 2014 (UTC)

Wow, then there's almost no point to this policy. I could get information like ip and username, send it to some server, and that would be allowed? @LVilla (WMF): please consider fixing this. PiRSquared17 (talk) 00:11, 2 January 2014 (UTC)

Yeah. 111.111.111.111. looked at a music-video on youtube from 8:12 to 8:20, opened a new tab and visited a conservative political website from 8:13 to 8:15, then switched to wikipedia and read the article about "Hemorrhoids" in the english WP for the next 15 Minutes - Hey, lets generate some appropriate Ad´s for this guy! No WP reader should ever have to expect something like this, and no one would accept the lame excuse that this massive violation of privacy happend at WP-laps. Alexpl (talk) 08:16, 2 January 2014 (UTC)

Taking these slightly out of order:

status.wikimedia.org: This is a separate website, provided for us by a third party - what we call a "Service Provider" under the "More on what this privacy policy doesn't cover". When this privacy policy goes into effect, status will either (1) be covered by this policy or (2) get a separate privacy policy describing the privacy practices of the Service Provider. In general, we will negotiate contracts with Service Providers so that they do not use third-party tracking tools like GA, and otherwise are reasonably careful about privacy, but we want to be flexible so that we can make case-by-case judgments based on the specific facts of the particular website.

Labs: Labs projects are not covered by this privacy policy (unless they are created by WMF employees). That policy says that developers can't "share any Private Information outside of your Labs Project", which is supposed to cover things like this, but people have raised questions about it and I'm trying to draft some more clear language for it.

Volunteer-added data collection:

The privacy policy is a promise between the Foundation and users of the website. So, if the privacy policy tells users "the website will not do X", then the Foundation is promising that the website will not do X. This is why things done by users on the site aren't covered by the policy - we don't want to make a promise we can't keep.

We did not intend to say that these tools are acceptable: if you read the section Nemo cited, it encourages people to report them to us for investigation, or even remove them themselves! (We also make a similar comment in the section about cookies.) We're just saying that the Foundation can't make promises that these tools won't exist.

We should probably make it more clear that these tools should comply with the same general standards as things done by WMF. This is tricky to do right, so I don't have any proposals right now, but I am thinking hard about it and I welcome suggestions in the meantime.

Hope this helps clarify. Like I said, we're taking the point about third parties seriously and we're trying to figure out how to best address it, but it might take a while because of lingering holiday travel.-LVilla (WMF) (talk) 01:59, 3 January 2014 (UTC)

Hm, so WMF does not want to be held responsible for some individuals contribution which makes the website track its readers, but is willing to remove such tools if informed about and does encourage authors to remove them on their own as soon as identified. Makes sense. But if WMF starts to collect those data on their own, officially, like proposed in our "User site behavior collection", the entire idea becomes somewhat pointless. Now "The website will not do X" - and the "third party" can just download those data, feed them in their system - done. Alexpl (talk) 09:09, 3 January 2014 (UTC)

No, it's very different. For example, in the experiment you linked to, the only personally identifying data involved (user-agent string and IP address) are anonymized or not collected, and are not shared with third parties. In the more general case, we strive to collect only limited information, and we only share what we collect under very specific circumstances that protect your information. ("When we give access to personal information to third-party developers or researchers, we put requirements, such as reasonable technical and contractual protections, in place to help ensure that these service providers treat your information consistently with the principles of this Policy and in accordance with our instructions.") That's obviously not the case if a random person inserts Google Analytics or a tracking pixel on a page. So our collection is very different than collection by third parties, because of how we control the data after we collect it.-LVilla (WMF) (talk) 15:53, 3 January 2014 (UTC)

Do volunteers get access to the data collected in this experiment or contribute to the programming :) ? Alexpl (talk) 21:12, 3 January 2014 (UTC)

@Alexpl: I don't know the specifics of this particular experiment. In general, as the policy says, when personal information is collected by WMF through the site then volunteers who have access to the data will be asked to agree to confidentiality agreements, and volunteers who help write code will be subject to code review. Does that answer the question?—LVilla (WMF) (talk) 23:07, 3 January 2014 (UTC)

You are the second WMF person here who doesnt know the details of that experiment. Considering the extent (tracking readers) thats scary. But I made my point. Good luck. Alexpl (talk)

We're a big organization now. If we all had to know every detail of every project in every team, we wouldn't get much done. So I don't think it is scary. -LVilla (WMF) (talk) 02:32, 7 January 2014 (UTC)

And MWalker (WMF) has responded above about that experiment (diff). -LVilla (WMF) (talk) 01:08, 9 January 2014 (UTC)

@Alexpl: Iff the experiment goes ahead after the privacy policy discussion has died down, I am more than happy to ping you for code review. The raw data collected will not be easily available to the general public without them signing an NDA (unless something changes with how EventLogging works and where it puts its data) but the findings from the study will definitely be made public. Mwalker (WMF) (talk) 01:30, 9 January 2014 (UTC)

Thx, but thats not my field of expertise. I was only alarmed by the laxy, informal way the guys seemed to be able to put a potentially very dangerous concept into action. But if its carefully controlled and limited, I´m fine. Alexpl (talk) 11:26, 9 January 2014 (UTC)

@MZMcBride: @PiRSquared17: @Nemo bis: @Alexpl:Here's some proposed language to address the third-party data collection question.

Data Collection by Third Parties

In some circumstances, volunteers and other third parties may have the ability to place a data-collecting tool, such as a third-party cookie, script, gadget, tracking pixel, or share button, on a Wikimedia Site. Such tools are not permitted on Wikimedia Sites unless they first obtain permission from the affected user. Because this can be done without our knowledge, we cannot guarantee that these tools will not be installed. However, if you come across such a third-party tool, you can remove the tool yourself, tell administrators on the relevant Wikimedia Site, or report it to privacy[at]wikimedia.org so we can address the problem.

This would be in the "Important Information" section of the policy. I think the language meets the primary need, which is making much more clear that (1) this is not acceptable, and (2) anyone - WMF, admins, etc. - can solve the problem if they come across it. Thoughts? Comments? —LVilla (WMF) (talk) 20:46, 7 January 2014 (UTC)

Good. PiRSquared17 (talk) 21:27, 7 January 2014 (UTC)

Nice. So I could remove a WMF Labs tracking tool, because Labs is a third party and didnt ask me for permission ? Alexpl (talk) 11:28, 8 January 2014 (UTC)

A better route in the case of a tool hosted on Labs and included on a site covered by this privacy policy might be to check with the Labs developer first. Labs has built-in filtering of IP addresses at the proxy, which makes things like tracking pixels hosted at Labs very different from tracking pixels hosted elsewhere, since they can't get the IP address via the pixel - all they'd know is that someone visited the page, unlike a normal tracking pixel. Also, the privacy policy that makes it fairly difficult to use for collection of personal data. (They could violate the privacy policy, but in that case, the better approach is to ask the developer to fix it and then ask us to shut the tool down if they won't fix it.) So it is highly unlikely that a Labs tool is a data-collecting tool in the sense we mean here.

Answering that makes me realize that "data-collecting tool" is somewhat vague. I think the right thing to do is to call it a "tool that collects personal data", so basically this:

In some circumstances, volunteers and other third parties may have the ability to place a tool that collects personal data, such as a third-party cookie, script, gadget, tracking pixel, or share button, on a Wikimedia Site.

I removed script and gadget because, while they can be tools that collect personal data, that isn't their primary purpose, so they probably aren't as helpful as examples. But open to discussion/suggestion on that point. Does that edit make sense/improve things? —LVilla (WMF) (talk) 00:50, 9 January 2014 (UTC)

Non-English speakers beg some love

The following discussion is closed: Closed because discussion appears resolved/done, please reopen if not

---

Just two weeks before the proposed end date for this consultation, the translation statistics are very depressing: the top language is French with 80 % translated, only 5 languages are more than 2/3 translated. This means that 4 months have been wasted not involving the global community in the discussion and not spotting translatability issues that will bite later.
One obvious reason here is that the draft is a +200 % length increase compared to the current policy: otherwise, we'd have roughly 14 languages fully translated instead of 0. If the WMF staff is serious about making a privacy policy that people can understand, well of course that's not easy and it probably entails rewriting it from scratch under new premises, to embed the initial feedback received so far and reduce the length by about 66 %. --Nemo 10:28, 30 December 2013 (UTC)

If the document is too long, have you tried editing it down? :-) --MZMcBride (talk) 10:30, 30 December 2013 (UTC)

I've made some specific edit proposals but Luis declared they were not "serious" (though in the end he did make some minor changes). I didn't bother making more. --Nemo 10:32, 30 December 2013 (UTC)

If you want to suggest edits that make the language clearer without changing the policy, by all means - many people have done that and gotten changes in, including you, and the policy is better (and shorter) for it. (The unserious suggestion, if I recall correctly, essentially amounted to removing an entire section of the document.) -LVilla (WMF) (talk)

I don't know what's aggregated in this group but the policy document is fully translated into several languages, including French and German. — Pajz (talk) 12:06, 30 December 2013 (UTC)

No it isn't, the "More On What This Privacy Policy Doesn’t Cover" section is not translated at all in German. The only group you should use is the complete one I linked above. --Nemo 20:14, 30 December 2013 (UTC)

And how is one supposed to do that (see #(Technical:) Cannot translate navigation box title above)? — Pajz (talk) 22:11, 30 December 2013 (UTC)

Like the rest of the policy, this was originally translated into formal German (as well as four other widely-used language) by paid translators. It is now untranslated because we rewrote the whole section, making it 1/6th shorter (at Nemo's request and in part based on his suggestions), and the translators haven't caught up. This is unfortunate, but also unavoidable when you make changes to a translated document.

We can't have the professional translators re-translate every time we make a change - besides the money, the overhead of entering the new translations in with every change would be huge. (And my understanding is that the volunteer translators often aren't happy with the quality of the professional translations anyway :) So we can either slow the editing of the policy, or accept that sometimes sections of it will not be translated while we're discussing it. I admit neither option is ideal, but I think we have made the right choice in leaning towards fast changes.

If there are things we're doing wrong that are hindering the volunteer translators, I'm happy to listen to suggestions on that front - I do think we've been fixing translation software mistakes as quickly as we can, but if not, let me know. -LVilla (WMF) (talk) 01:52, 31 December 2013 (UTC)

If it's really essential that we get this translated beyond 5 languages, why don't we just pay for translation in the top 10-20 languages? This is too important to wait on. Steven Walling (WMF) • talk 00:53, 31 December 2013 (UTC)

Hi Nemo, what's stopping you from sending out a call for volunteer translators via the usual two channels - the translation notifications system and/or the Translators-l mailing list? As far as I can see, neither has been done in this case so far, so it's likely that many interested translators do not yet know about this translation task. (Regarding the first channel, there is a little technical issue in that notifications can only be sent for translatable pages, not for aggregated groups - cf. bug 56187 - but that can be mitigated by sending at least a notification for the main page, and linking the aggregated group in the accompanying text message.)

Regards, Tbayer (WMF) (talk) 03:42, 31 December 2013 (UTC)

Done I eventually sent out a translation notification myself (with an emphasis on main text of the privacy policy, to help translators focus their energy, but also inviting translation of the whole group). Many thanks to the volunteers who have since then already translated or updated around 500 translation units; hopefully more will be done over the coming days. So if it's really the case that there are indeed still serious translation problems remaining, we should have a good chance to uncover them before the deadline a week from now.

BTW, we are planning to do the same for the draft for the new data retention policy, which is going to be published soon.

Regards, Tbayer (WMF) (talk) 23:34, 8 January 2014 (UTC)

Changing Do Not Track section to clarify language, reflect fact that specification is not yet done

The following discussion is closed: Closing because no comments were made to the proposed language, please reopen if proposing changes

---

The week before Christmas, the World Wide Web Consortium's Tracking Protection Working Group changed the definitions of "tracking" and "first party/third party" in the proposed Do Not Track standard. WMF's behaviors still appear to be in compliance with the proposed standard. However, the changes highlight that the standard is still very much a work in progress. Because of that, I'd like to move the current reference to the standard from the privacy policy itself to a FAQ that makes more clear that the standard is a work-in-progress.

The old language is:

As noted throughout this policy, we are strongly committed to not sharing the information we collect from you with third parties, except under very specific circumstances. In particular, we do not allow tracking by third-party websites you have not visited (including analytics services, advertising networks, and social platforms), nor do we share your information with any third parties for marketing purposes. We may share your information only under particular situations, which you can learn more about in the “When May We Share Your Information” section of this Privacy Policy.

Because of this commitment, this Policy is generally as protective as, or more protective than, a formal implementation of the Do Not Track specification, and so we do not respond to the Do Not Track signal.

For more information regarding DNT signals, please visit our FAQ, Do Not Track Us, and the World Wide Web Consortium's Do Not Track Specification.

The new language would be:

We are strongly committed to not sharing non-public information with third parties. In particular, we do not allow tracking by third-party websites you have not visited (including analytics services, advertising networks, and social platforms), nor do we share your information with any third parties for marketing purposes. Under this policy, we may share your information only under particular situations, which you can learn more about in the “When May We Share Your Information” section of this Privacy Policy.

Because we protect all users, we do not change our behavior in response to a web browser's "do not track" signal.

For more information regarding Do Not Track signals and how we handle them, please visit our Do Not Track FAQ.

The relevant part of the FAQ answer would change from:

Because of this commitment, our Privacy Policy is generally as or more protective than a formal implementation of the Do Not Track specification, and so we do not respond to the Do Not Track signal.

to:

Because of this commitment, we protect everyone, and do not change our behavior in response to a web browser's DNT signal. We believe that, as of this writing, this approach is as or more protective than the obligations for "first parties" set out in the World Wide Web Consortium's Do Not Track specification. However, the specification is still being revised and changed, often in important ways. We will continue to monitor the specification as it moves towards completion and update our behavior and this FAQ consistent with the principles laid out in the Privacy Policy.

Anyone have thoughts/comments/suggestions on this language? If not, I'll put it in soon. Thanks. -LVilla (WMF) (talk) 19:53, 30 December 2013 (UTC)

The above-described changes were made in the "Important Info" section of the Privacy Policy, as well as the Do Not Track FAQ. --JVargas (WMF) (talk) 22:56, 7 January 2014 (UTC)

Safe Harbor

Nemo asked above what we could say about Safe Harbor compliance, putting aside the fact that we can't actually comply because the FTC cannot enforce the statute against us. So I have spent some time looking deeper into the question.

The Safe Harbor is made up of several principles. While we comply with most of them, we don’t see how we can comply with the “Onward Transfer” principle. In essence, this principle states that an organization can only transfer automatically collected information (like IP addresses) to third parties if the third party (1) is an agent and (2) the agent (a) is subject to the Safe Harbor, (b) is subject to the EU Directive, or (c) enters into a written agreement as strong as the relevant Principles.

Generally, we comply with this requirement, because in most cases we simply never transfer data to third parties. However, we do sometimes transfer certain information to third parties: our volunteers. In particular, we sometimes transfer automatically collected IP addresses. They, in turn, often transfer that information to other third parties, like the WHOIS tools that are used to gather more information about the IP addresses.

We do not at this time see how we can comply with the Onward Transfer principle (and therefore comply with Safe Harbor) while still allowing volunteers to fight abuse of the site. We do not believe our volunteers are our “agents”, and (in the ongoing identification discussion) relatively weak written agreements have been rejected. We also don’t see how we can practically prohibit those volunteers from using tools like WHOIS.

This is unfortunate, but again a situation where our unusual structure makes certain kinds of compliance difficult. As usual, we'll have to continue making best efforts in other areas to reduce the risk to users. Hope that helps clarify the situation. -LVilla (WMF) (talk) 19:49, 31 December 2013 (UTC)

Community comments acceptance deadline

Hi. According to the top of the page, the community comments acceptance deadline is 15 January 2014. I'm not sure this is a good idea. Discussion is ongoing and there appear to be a number of unresolved issues on this talk page and at Talk:Access to nonpublic information policy. Discussion should continue until there's consensus to move forward. --MZMcBride (talk) 07:32, 5 January 2014 (UTC)

Given the significant changes still expected, and the few, dated translations, I agree. How far should we push it out? A few weeks? Let's aim to get the expected changes ironed out in English by mid-month? --Elvey (talk) 06:28, 6 January 2014 (UTC)

I just made several edits. The last two are labeled Option A and Option B. They were prompted by this problematic edit: The new language "are kept confidential" was added, referring to 'email this user' email. That implies they are kept. (!) Should they be? Arguably not. Thus I suggest we go with option A, or if that's not accurate, to Option B. I hope we can go with Option A.--Elvey (talk) 06:28, 6 January 2014 (UTC)

@Elvey: As I noted in the edit page, please open a new section on this page for substantive edits, rather than making them directly in the doc. Thanks! —LVilla (WMF) (talk) 02:53, 7 January 2014 (UTC)

I think extending the non-public information policy discussion makes sense, and the data retention policy is still unpublished and so will obviously need to go past the 15th. But on this doc, I'd lean towards bearing down on the remaining open issues and still aiming to close on the 15th (with the obvious exception that there might be changes to it resulting from changes to the other two documents.) Michelle is on vacation, and we can't confirm that until she returns, but that is my sense of the right plan. —LVilla (WMF) (talk) 02:53, 7 January 2014 (UTC)

Edits about tracking and personal information

This edits User:Elvey was remedied. User:LVilla (WMF) Elvey, please share context? (Like you did for some other thing here). Gryllida (talk) 04:30, 7 January 2014 (UTC)

To explain why I changed those -

• this edit removed "retained" from the description of what we do with direct communications between users. I did this because we it is not accurate to say that we retain those - we may in some cases but in most cases that I'm aware of we don't.
• this edit removed an example about tracking pixels that Elvey had edited. Elvey's edit correctly pointed out that the example was a little hard to understand, but I don't think his edit improved it. I spent a little bit of time trying to explain it better without writing a book or assuming the reader is a web developer, and failed, so I deleted it. If folks want to take another stab at it, I'm happy to discuss it here.

Sorry for not explaining this earlier, User:Elvey - I do appreciate that you were trying to improve it :) —LVilla (WMF) (talk) 00:00, 9 January 2014 (UTC)