Wikimedia Forum

← Discussion pages

Wikimedia Forums

Archives →

The Wikimedia Forum is a central place for questions, announcements and other discussions about the Wikimedia Foundation and its projects. (For discussion about the Meta wiki, see Meta:Babel.)
This is not the place to make technical queries regarding the MediaWiki software; please ask such questions at the MediaWiki support desk; technical questions about Wikimedia wikis, however, can be placed on Tech page.

You can reply to a topic by clicking the "[edit]" link beside that section, or you can start a new discussion.

Wikimedia Meta-Wiki

• About Meta
• Discussion pages
• Request pages
• Policies and guidelines
• Information and statistics
• Categories
• Help pages
• Meta-Wiki discussion page

Changes to the default site typography coming soon

This week, the typography on Wikimedia sites will be updated for all readers and editors who use the default "Vector" skin. This change will involve new serif fonts for some headings, small tweaks to body content fonts, text size, text color, and spacing between elements. The schedule is:

• April 1st: non-Wikipedia projects will see this change live
• April 3rd: Wikipedias will see this change live

This change is very similar to the "Typography Update" Beta Feature that has been available on Wikimedia projects since November 2013. After several rounds of testing and with feedback from the community, this Beta Feature will be disabled and successful aspects enabled in the default site appearance. Users who are logged in may still choose to use another skin, or alter their personal CSS, if they prefer a different appearance. Local common CSS styles will also apply as normal, for issues with local styles and scripts that impact all users.

For more information:

• Summary of changes and FAQ
• Discussion page for feedback or questions
• Post on blog.wikimedia.org

-- Steven Walling (Product Manager) on behalf of the Wikimedia Foundation's User Experience Design team

Is the Foundation serious about privacy?

On the 9th of August 2013, over eight months ago I reported a serious flaw in the privacy of default Mediawiki installations, that breaks the Foundations Privacy Policy. At least one Foundation employee commented on the report.

On the 18th I logged a bug pre-filled request, and on the 20th Louis Villa form the Legal team commented. Various clever people have commented and linked similar bugs. A patch was uploaded by Saper to Gerrit (92254) on 28 October, though as Please Stand commented, it did not remove all the fields required.

While I thank all those who have commented and worked on this issue, both from the community and the Foundation, there does seem to be a lack of urgency by the Foundation. Perhaps it is my background in compter security, but I would have assigned something like this TOP PRIORITY.

We are doing three things we don't want to do here:

1. Showing a careless attitude to security and privacy. That alienates a lot of people these days, not just the core of the Open Movement.
2. Exposing our editors' private details (editing history) to colleagues, family, housemates, fellow pupils/students, etc.
3. Becoming liable for civil actions as a result of damage, injury or distress caused by 2., if nothing else.

Please assign resource to implement a fix and roll out this change as soon as possible.

The change to the software is trivial, I will put the required code in the Bugzilla bug as soon as I have saved this edit. I will copy this post to Legal and Sue.

Rich Farmbrough 04:46 16 April 2014 (GMT).

These claims about WMF having a careless attitude, potentially creating legal liability, seem excessive. Your initial inquiry received a response, identifying the scenario as an edge case (users sharing an IP address and one of them being blocked and that resulting in victimization of the blocked user by the unblocked one, all in real life, not here). See

"We're talking about a very narrow case here, as I understand it: when multiple users are using the exact same IP address and one of the users is blocked. The likelihood of this rare case directly leading to harassment, as you're suggesting, seems almost non-existent, or at least statistically insignificant..." per MZMcBride on 16 August 2013.

Does this scenario have a greater scope, potential contributor vulnerability than is apparent from prior discussion?--FeralOink (talk) 19:46, 16 April 2014 (UTC)

• Security and privacy concerns are often based edge cases. That doesn't make them invalid.

• I provided an example of where we have published (to the world) the IP address of an editor. I chose an example that was subsequently redacted.

• Common carrier exemption is probably moot in this case, because the default message to an auto-blocked user encourages her to publish the IP address and the user name on their talk page.

• Moreover the software removes the ability of local administrators to completely suppress this information. The buck, in this case, stops firmly with WMF.

Rich Farmbrough 21:46 16 April 2014 (GMT).

FeralOink: With the large number of schools, employers, and other institutions that funnel all Internet traffic through a single public IP address, the privacy breach itself is not an "edge case." Or rather, if it is an edge case, it's a broad enough "edge" to be treated as if it weren't one. Now, I will say that some of the potential effects of a breach of privacy, e.g. stalking, etc., are edge cases, but even if they were non-existent it would still be a breach of privacy - it's nobody's business but mine those trusted Wikipedia (or here, Meta-) functionaries what my (davidwr's) IP address was at the time of a given edit. As far as the default message to auto-blocked users go, it should probably be changed to show a block-specific "incident token" that an appropriate functionary could look up to get the information he needed to see if the autoblock should be changed and/or if the complaining editor should be exempted from the autoblock. As a practical matter, I would trust English Wikipedia admins with the ability to see all of the information that the "incident token" unlocks, including the IP address that is auto-blocked and the editor whose block generated the auto-block, provided that there was a method for editors caught in an auto-block who did not want to have administrators know his IP address to communicate directly with a checkuser-level functionary. Since there are a lot fewer checkuser-level functionaries, such a request would by necessity mean there would be a slower response time than a "help me - see incident token #____" posted on the affected editor's talk page. Davidwr/talk 17:41, 25 April 2014 (UTC)

Thanks for raising the alarm bells quietly in August, and loudly now, Rich Farmbrough. FeralOink: the appropriate response is to fix the problem, not get all defensive. It's already been shown how this could, for example, easily leak information endangering someone's job to their colleagues or conceivably enable RL stalking. It's not an edge case that this discloses the identities of editors to other users who share their IP, through no fault of the editors. Steven Walling (WMF) said it's a Bad Thing. Dealing with identified security vulnerabilities isn't optional. Open source projects are supposed to be good at dealing with security vulnerabilities. Aside from the other reasons it needs to be closed, this bug provides a rather compelling reason for any recently blocked user who asks to be unblocked, to be unblocked. And if exposure caused by turning down such a request isn't "potentially creating legal liability", I don't know what is.

The bug,

Tracked in Phabricator:
Bug 53008

(see at right) is marked, per this comment:

The template has been updated. I thin enwiki community might want to discuss whether Template:Unblock-auto and friends (Template:Unblock-auto_on_hold, Template:Unblock-auto_reviewed) should accept IP address as $1 parameter. But that should be left to the local discussion.

Closing as RESOLVED/WONTFIX.

INVALID would mean fixing it is outside of power of MediaWiki development, which isn't fully true - in theory we are able to remove the parameter supplied to the template, but for reasons listed above we don't want to.

Take a look. Since the bug is marked WONTFIX, and the patch is marked ABANDONED, we need an {{editrequest}} on every wikipedia? We need a bureaucrat to or other user with global rights to make the change across all wikimedia sites, and someone to post to the appropriate mediawiki forums about the vulnerability? Is the WMF's position to leave this to the volunteer admins to fix? Or should we (I) reopen the bug, while changing the Product from MediaWiki to WikiMedia? I'm leaning toward doing the latter.

Is there a variant of {{tl:editrequest}} to summon such a super superuser? Is anyone listening such a superuser?

Is this bug unrelated? (see at right)

Tracked in Phabricator:
Bug 52975

--Elvey (talk) 01:50, 23 May 2014 (UTC)

Just editing the MediaWiki message locally doesn't prevent people from finding the information. You can just add "&uselang=qqx" to the query string to find it. You could probably get similar information from the API if you know what you're doing. PiRSquared17 (talk) 02:26, 23 May 2014 (UTC)

I was NOT getting all defensive, Elvey! I am not going to rant back at you. If it weren't for PiRSquared17, and to some extent, Rich Farmbrough (who brought the issue up originally, and managed to respond directly to my comment without any accusations of misbehavior!), I would be just another female editor who walked away after being told what "the appropriate response" was. I have responses to your points, but do not wish to engage in further discussion. This is not why... nevermind. Enough.--FeralOink (talk) 19:32, 26 May 2014 (UTC)

I am not an WMF attorney. I said "seems" regarding "potentially creating legal liability". Perhaps you, Elvey, know better though.

One more thing: THIS is very much not a valid assumption, "Open source projects are supposed to be good at dealing with security vulnerabilities." Case in point: OpenSSL and Heartbleed.

One thing, really. I shared an IP address with someone who does all sorts of things that cause trouble e.g. griefing in Second Life, illegal downloads of whatsit, "Call of Duty" version n for n = 1 to ad nauseum. He would get banned and blocked, but I would not. We had the same IPv4 address, but different MAC addresses. I never did what he did, and we never shared computers (we rarely talked to each other). I mention this because I was wondering if blocking/ banning on an IP and MAC level could be a potentially useful way of protecting user anonymity, in the shared IP address scenario. --FeralOink (talk) 19:58, 26 May 2014 (UTC)

To read a client MAC address requires dedicated software - I.E. the browser can't do it. It is generally regarded in the community^{[which community?]} as a Bad Thing, for the following reasons:

1. It is an invasion of privacy.
2. It is bad security to run untrusted programs.
3. Open source programs can be hacked to lie about MAC address
4. It is bad to transfer un-needed data
5. It is bad to create a risk of un-needed data leaking
6. It creates a false sense of security

Rich Farmbrough 23:25 26 May 2014 (GMT).

Thank you, Rich . That makes sense. MAC addresses are not the answer. --FeralOink (talk) 17:10, 28 May 2014 (UTC)

FeralOink: Preventing security vulnerabilities and dealing with them once notified (such as by a security researcher's responsible disclosure) are two different things. OpenSSL's Heartbleed was a disastrous vulnerability. We say, "A fixed version of OpenSSL was released on April 7, 2014, on the same day Heartbleed was publicly disclosed." This was apparently the same day that OpenSSL team members were first notified. I don't see in that evidence that the open source project dealt with the disastrous vulnerability improperly. By contrast, the WMF was notified of this problem a long time before any mitigation occurred, and the vulnerability has yet to be fully closed, even in source code repository. By contrast, the NSA allegedly dealt with Heartbleed improperly.

Also, I opined about whether the actual response had been the appropriate response, after you had done the same thing! Opining about whether the actual response had been the appropriate response is not unacceptable behavior, IMO. I'm sorry that you feel accused of misbehavior FeralOink, but I feel my words have been misinterpreted. Besides, although you accuse me of making a "very much" invalid assumption, I said "supposed to be" regarding "good at dealing with security vulnerabilities". And many folks agree with me on that, including the United States Department of Defense.

This bug comment from Luis Villa (WMF Legal) on 2014-04-22 00:42:56 UTC has as of yet received no response:

Marcin: I think I'm missing something - if we're able to fix[1] something globally by blanking $1, shouldn't we do that instead of requiring each individual community to fix their templates (guaranteeing that particularly in many smaller communities the problem will remain unresolved?)

[1] I realize it is not a complete fix, but at least makes the problem less likely to happen accidentally.

--Elvey (talk) 00:27, 28 May 2014 (UTC)

The WMF was notified of this problem a long time ago, there's an open bug in bugzilla, and the vulnerability (security hole) has yet to be fully closed, even in source code repository. Who's on it? Nobody. --Elvey (talk) 08:10, 4 July 2014 (UTC)

┌─────────────────────────────────┘
I have un-collapsed and un-hidden this section. If a WMF or admin sees fit to collapse what I wrote, so be it. It is not a decision that my interlocutor, Mr. Elvey, should be making.

Moving on, the OpenSSL vulnerability was disastrous. FOSS relies on a certain amount of integrity on the part of contributors and users. I think Richard Stallman is a morally upstanding individual, and he means well with FOSS. He is NOT a communist, even though lots of folks seem to wish he were! There are undeniable trade-off's between opensource and turn key closed source solutions (I'm not going to get into Stallman-esque GNU-ism distinctions between FOSS and open source here). Opensource has the benefit of many, many eyes having gone over the code with a fine-toothed comb. Eyes who may have seen many things, and want to help by making suggestions and precautionary advisories, for the common good, without disclosure or risk to themselves or family.

On the other hand, un-formalized trust mechanisms and lack of dedicated, compensated staff can result in neglect and other varieties of vulnerability. This is relevant, not tangential, in light of Rich's prior itemized list, that "to read a client MAC address requires dedicated software, the browser can't do it and it is generally regarded in the community as a Bad Thing, for the following reasons, it is an invasion of privacy; It is bad security to run untrusted programs; Open source programs can be hacked to lie about MAC address... etc.". You see, I was reconsidering what Rich said earlier, regarding the unsuitability of MAC address filtering. Although stated with authority and couched in the lingo of Wikipedia-speak or other online community argot, e.g. A Bad Thing, I'd like someone who knows more than I do about network security and Mediawiki to make an assessment of whether the stated objectives of this bug fix can be accomplished without inadvertently introducing worse privacy incursions, or otherwise hobbling Mediawiki in any other way that unacceptably impact the stability or performance for

• all non-IP editors
• IP editors who have an IP address of their own and
• shared IP address editors who are not blocked or banned by Wikipedia.

This issue is most relevant only to preserving the privacy of one shared IP address editor from the others of their shared IP address, in the event that said IP editor has been blocked or banned.--FeralOink (talk) 22:27, 5 June 2014 (UTC)

Oy. I collapsed what I collapsed (not the whole section) because, among other things, the MAC idea is a complete non-starter, and I concluded that you had realized that too once I read your reply to Rich's comment. There's no way for Wikipedia to reliably log the MAC address of editors. The web server simply doesn't receive the MAC address of editors machines; it's not included in the IP packets the web servers receive. As Rich said, "To read a client MAC address requires dedicated software - I.E. the browser can't do it." If you don't trust Rich and I when we tell you this, learn a bit about networking -- watch https://archive.org/details/warriors_of_net, which is excellent! Can we please stay focused on bug pre-filled request!!! --Elvey (talk) 08:10, 4 July 2014 (UTC)

Online Privacy Protection Act of 2003 - California Business and Professions Code sections 22575-22579

I've been looking at the new privacy policy. In connection with another matter, I've also been looking at what I take to be the relevant legislation in California (this is a link to the relevant sections).

The issue I want to raise concerns 22575 b (1), which reads: "The privacy policy required by subdivision (a) shall do all of the following:( 1) Identify the categories of personally identifiable information that the operator collects through the Web site or online service about individual consumers who use or visit its commercial Web site or online service and the categories of third-party persons or entities with whom the operator may share that personally identifiable information."

I'm uncertain (and would appreciate clarification) but it seems to me that the latter clause about sharing information must apply when abuse reports are filed with ISPs. The privacy policy cites the IP address as an item of personal information and 22577 a (6,7) of the CA codes implies that the IP address is also envisaged as personally identifiable information.

That ISPs are third-party entities with which Wikimedia may share personally identifiable information is in fact only ascertained on referring to an associated FAQ. I'm not sure that can be entirely wise (the FAQ states at the outset it is not part of the privacy policy), but the issue I want to raise concerns "categories". It happens that ISPs can sometimes be institutions such as schools, hosiptals, the armed services, and so on, and these might well be the user's employers. No doubt it often happens that when making an abuse complaint, Wikimedia will in fact be contacting an employer with potentially vexatious effect on the user. Of course that's unfortunate, but it's also so that Wikimedia does sometimes knowingly contact an employer in making that ISP report (the matter I refer to above which initiated my enquiry). In those circumstances, to comply with 22575 b (1), it should be made clear that this might happen, that third-party categories might include the user's employers, and in any case, in the spirit of presenting a privacy policy all can understand, that ought to be made clear.

I invite comment. Coat of Many Colours (talk) 11:09, 26 May 2014 (UTC)

Hi Coat of Many Colours, thank you for your comment. We believe that we are in compliance with CalOPPA. If you refer to the guidelines issued by California’s Attorney General, you will see that the law requires organizations to “explain [their] uses of personally identifiable information beyond what is necessary for . . . the basic functionality of an online service.” The guidelines further state that the privacy policy should include “categories of third parties with whom the operator may share the personally identifiable information.” If the Foundation were to share personally identifiable information with a user’s service provider because the user was abusing one of our sites, we believe that that sharing would be in line with protecting “the basic functionality” of the site.

Even if it doesn’t fall within basic functionality, reporting a user to their service provider to protect our sites from vandalism is directly addressed in our privacy policy. The “categor[y] of third parties with whom [we] may share the personally identifiable information” is described in the “To Protect You, Ourselves & Others” section of the Privacy Policy. You are correct that the section I just mentioned links to a FAQ which then states that user information may be shared with a service provider, but we believe that including this information in the FAQ section does not violate CalOPPA. The CalOPPA guidelines refer to a recommended approach of “supplement[ing] a comprehensive privacy policy with simpler, shorter privacy notices to alert consumers to potentially unexpected data practices.” We do not think that it is unexpected to users that we would share their information with their service provider in order to stop them from vandalizing our sites, but even if it is unexpected, we have included a category of third parties we may share data with “To Protect You, Ourselves & Others” and we have provided more details in a supplement, the FAQ. RPatel (WMF) (talk) 19:39, 12 June 2014 (UTC)

There is a question also of transmitting personal information between the US and the EU, which is done, for example, by CheckUsers based in the EU, and by users of the mailing lists maintained by WMF. This may bring this data in the scope of the EU directive on data protection, and indeed under the remit of the relevant national bodies. Bodies within the community that handle personal information (which all have agency relationships with the WMF), especially those having members in the UK should be registered with the Data Protection Registrar. Rich Farmbrough 23:43 26 May 2014 (GMT).

Hi Rich Farmbrough. The question of whether E.U. laws, including the Data Directive, apply to WMF was brought up during the privacy policy consultation. You will find some of the discussion here. To summarize, WMF is located in the United States, thus we follow United States laws. CheckUsers, although valued volunteers, are not the Foundation’s agents, and the same goes for users of our mailing lists. Accordingly, we do not believe that the activities you mentioned fall within the scope of the EU data directive, at least with respect to WMF. RPatel (WMF) (talk) 00:06, 13 June 2014 (UTC)

Including "Help" namespace in default search

In bugzilla:66066 I propose to add the Help namespace to the default search in all projects, as the "Help" tab has been removed from MediaWiki. To make an example, the top 150 Wikipedias have an average of 83 Help pages with a standard deviation of 172: searches are not going to be cluttered negatively by such a small amount of pages. Opinions? --Nemo 07:28, 5 June 2014 (UTC)

Can't you use the search option for that ? My opinion is that the "Help" namespace should better be aggregated in the search results within the "Project" namespace. But better not pollute searches in the main namespace. Basically the "Help" namespace does not fit well with the standard sed in the main namespace of the project, it frequently is just meta discussions with some documents about MediaWiki itself. Frequently it does not use the coding conventions used by the local wiki and often not the same language (but a wiki could contain several translated versions of the basic pages). Ideally, most the "Help" namespace should not even be present in the wiki, where it should remain in the Mediawiki documention wiki.

But some wikis will still prefer to have at least basic info stored locally to avoid leaving the site, at least for an initial period before the site develops its own local "Project:" namespace to adapt this help to local conventions (which will evolve over time, when "Help:" content will remain unmaintained: integrating the "Help:" content in results may give false hints and it's best to hide it, unless there's a local "Project:" page containing links to it. The wiki project maintainers will still want to keep the lead by driving people first to their true local "Project:" content giving the best directions.

So I tihnk it's best to exclude "Help:" by default. it should not be necessary to search in it, except for a short time when the wiki starts being developed. A wiki may even decide later to drop completely the "Help:" namespace completely, once the local "Project:" namespace is viable. And for more accurate results about how MediaWiki works and can be used, for the few people that want more information, these wikis are just driving users to visit the MediaWiki wiki where there are many more details than the basic unmaintained content of the local "Help:" namespace. And admins of those wikis won't also want to subscribe to all changes of the basic "Help:" package proposed for new installations of MediaWiki (whose installation on a new wiki also remains optional) to maintain in contantly (as this could also break their own local pages developed in their "Project:" namespace (broken red links). They will also have made some local changes in the "Help" pack to hide things that are not working locally, or no longer.

For me the "Help" namespace is transitional. it is used only for bootstrapping a wiki, and this means that it must not be reenabled by default in searches once it has been disabled. If people want updated info about MediaWiki they shoudl visit its wiki, and report and discuss the items they gin there in their local "Project" namespace with their local community of users and admins. They'll document in "Project" what works or wahat does not work (due to bugs or limitation in the original source, or due to locally decided restrictions; locally they may also lift the restrictions exposed in the core MEdiaWiki Help page because they have developed local tools or integrated additonal extensions that allow them to manage things more easily according to their local needs. The "Help" namepace is then only a last resort resource which will be less an less relevant over time.

Some wikis will find the content of "Help" also extremely undesirable (notably Wiktionary projects; they want the standard search to look only in their main namespace by default and nowhere else. This is less problematic for Wikipedias whose topics and presentations are extremely diversified) verdy_p (talk) 08:12, 5 June 2014 (UTC).

• I find this a reasonable proposal; thanks for suggesting it, @Nemo. odder (talk) 09:06, 5 June 2014 (UTC)
• +1. The help ns often doesn't contain many pages, but those that are there important. --MF-W 16:02, 5 June 2014 (UTC)

They are important at the begining, as I said as a minimum bootstrap. Then the pages in the "Project" space will take the lead and will correctly refer to the MediaWiki wiki or other community wikis for details and updates. Wikis will still prefer on focus on their content without taking too much time to explain things that could change later, including common practices based on newer technologies available. What people do today manually will be done later by automated tools. Even the Wiki syntax will have less importance than documenting the current best practices according to the current state of the wiki project and its evolutions (which means that not all technical tricks implemented will need to be used and things may be deprecated too that MediaWiki will still maintain for other projects evolving differently for their different content type.

In fact many people just avodi the basic "Help:" pages that give only generic false hints about best practices, simply because they are not maintained or tricks are no longer used or recommended locally. verdy_p (talk) 12:57, 10 June 2014 (UTC)

• I also agree implementing that proposal could have positive effects, especially to new users joining our wikis. Vogone (talk) 16:11, 10 June 2014 (UTC)

  But it may confuse readers. PiRSquared17 (talk) 16:16, 10 June 2014 (UTC)

  I believe readers are able to distinguish between content and the help namespace. And as Wikimedia projects tend to try getting readers to become contributors, such help pages would rather help to achieve that goal than to cause negative side effects. Vogone (talk) 23:11, 10 June 2014 (UTC)

  Moreover, especially readers may have a hard time finding help when needed, now that the "Help" tab on Special:Search was removed and given how hard to use the "advanced" tab is. FYI, added a link to main page. --Nemo 13:54, 19 June 2014 (UTC)

  I support Nemos proposal. Having the help namespace in the default search will help. I feel that the problem of discussion pages within the help namespace is just a part of a bigger problem; that there is a lot of overlap between the project namespace and the help namespace. If anything, this proposal would send out a message that this overlap should be sorted out, rather than doing the oposite.--Snaevar (talk) 19:08, 24 June 2014 (UTC)

• +1 support. Glaisher (talk) 12:54, 25 June 2014 (UTC)
• Oppose. Readers probably don't care about the Help namespace, they want to find content pages. And seriously, people, if you want this poll to have any validity you're going to have to invite comment from more than the tiny fraction of people across the wikis who watch this page (or even the tiny fraction that cares about Meta at all). Anomie (talk) 13:18, 25 June 2014 (UTC)
• Leaning toward oppose per Anomie. As I stated above, only a tiny portion of people searching will be interested in Help pages. This may confuse readers. Significant, Wikimedia-wide changes like this should not be made based on comments from a few people on Meta. Also see Manybubbles's comment on gerrit:139819 for some technical reasons why this is not practical currently. PiRSquared17 (talk) 13:24, 25 June 2014 (UTC)
• Oppose for theoretical reasons: searching for content shouldn't cause meta-content to be listed next to articles. 'Help' should be re-added as a separate option. --Ricordisamoa 00:28, 1 July 2014 (UTC)
• Question: Is it possible to change the default search, only for logged-in users? I.e. leave readers/anons with just the contentnamespaces, but add "Help:" for anyone who has logged-in. That would solve the 'reader-confusion' issue, and greatly reduce the cirrus issue. Quiddity (talk) 00:17, 7 July 2014 (UTC)
• I oppose mixing them with the main search results, but support adding a seperate column ("[search term] on [project]'s help pages").    FDMS  4    16:48, 7 July 2014 (UTC)

Checkuser abuse in the Spanish Wikipedia

Hi guys, I'd like to know the place to report the abuse of checkusers in the Spanish Wikipedia, with potential bleach of the data retention policy. Best regards --Discasto (talk) 19:59, 11 June 2014 (UTC)

I believe the Ombudsman commission is what you could be looking for. Regards, Vogone (talk) 20:36, 11 June 2014 (UTC)

OK, thanks. Do they handle several languages or do I have to write in English? --Discasto (talk) 22:31, 11 June 2014 (UTC)

At least three of them speak a basic level of Spanish (two speak es-1, one speaks es-2), but English will be more easily understood. I think it would be preferable to write in English, but they would probably be able to at least understand your message in Spanish. PiRSquared17 (talk) 22:33, 11 June 2014 (UTC)

Discasto what is happened on Spanish Wikipedia? --Kolega2357 (talk) 22:36, 11 June 2014 (UTC)

Well, it's a funny story. If you can read Spanish it's pretty much described in User:Discasto/Desbloqueo. I'll try to translate, but my English is possibly not enough.

On February 22, a CU verification on me was required. It was alleged that I was a sockpuppet of Ecemaml, who is indefinitely blocked on the Spanish Wikipedia (BTW, when this user required to be unblocked, a majority of admins and users accepted the request... he was not unblocked, since some admins alleged lack of consensus... yes, you know, consensus does not mean the same in the Spanish Wikipedia than in the rest of the Wikimedia projects... to see how harmful I can be for the Spanish Wikipedia you can read this article, it's a good article candidate and sincerely, you won't be able to find a better piece of knowledge about this woman, the mother of the assassin of Trotsky anywhere, feel free to translate it into English, it would be a really nice work). According to Bernard "Con los datos actuales son perfiles técnicos claramente diferenciados. No hay pues relación" (translation: With the information currenlty available, they are two clearly distinct technical profiles. Thus, there is no relationship [between them). The verification was required against users allegedly used by Ecemaml. Both the user Discasto and an IP address that I had used to openly edit were available. So, yes, that's right: no relationship.

More than three months afterwards, another verification was requested and now, Bernard said "according to the checkuser tool", that I'm a sock puppet of Ecemaml (see here), and I'm wondering how it can be possible provided that I have always edited with the same Mac, from the same location and with the same ISP. The explaination seems to be weird (at least for me): "Efectivamente en su momento ya se hizo un SVU a Discasto que dio negativo. Al hacerse con pocas ediciones los datos que teníamos para comparar eran escasos. Sin embargo, con los datos actuales sí se aprecian novedades que permiten relacionar ambas cuentas" (translation: A CU verification was indeed done at a given time and the result was negative. As it was carried out with very few editions, we had shortage of information to compare with. Now, with the information currently available, it is possible to observe news that allow to find a relationship between both accounts)

You see the weird situation if you consider that the checkuser information is no longer available after three months (at least is what the Foundation says (This information is only stored for a short period (currently 3 months), so edits made prior to that will not be shown via CheckUser, information that can be accessed by the CheckUser tool is deleted after three months y Personal information - Cllected automatically from a user - [is deleted After at most 90 days, it will be deleted, aggregated, or anonymized]). So, how is that possible? On February, Bernard could not find anything (it had data to compare with). On June, without any data to compare with, he was able to find a coincidence. Come on, Bernard was lying either in February or in June, but both statements can't be true at the same time.

Of course that the checkusers in the Spanish Wikipedia could have been recording locally the information gathered from the checkuser tool (it would be illegal according to the Spanish legislation and I don't know if allowed by the Foundation, in fact a former checkuser in the Spanish Wikipedia openly stated that CU information was not actually deleted from the Foundation systems and that at the end checkuser could access such information when "necessary", but I don't think that's true) to be used in for future verifications, but if that were the case, how did the February verification was negative if they had the same amount of available information to compare with in June (I've verified that any of the alleged Ecemaml's users edited in these three months)? An interesting point is that I was preparing the desysoping request for an admin that was sponsored by the same CU that in February wasn't able to find a coincidence but three months later, with much less information was finally able to find the longed coincidence. Is there an abuse? Well, for me it's pretty evident, especially as it's not possible that a neutral third party verifies that and especially when the mentioned CU is also an admin (which has shared in the past location information about users being investigated with his fellow administrators in a mailing list) and also one of those minority admins that successfully refused the unblocking of Ecemaml. That's all. Is that possible that the Ombudsman Commission say anything? I don't know. Best regards --Discasto (talk) 22:16, 17 June 2014 (UTC)

Just a note that Discasto, according to the checkuser tool, is a sock puppet of Ecemaml, who is indefinitely blocked on the Spanish Wikipedia. Over the years, several claims of CU abuse have been brought up by him, but none of them have actually been confirmed. LlamaAl (talk) 02:11, 13 June 2014 (UTC)

How do you know that? Are you part of the Ombudsman Commission? AFAIK, only one claim about a former CU that used CU information to blackmail other users has been brought up by Ecemaml to the Ombudsman Commission, but after one year time (such Commission seems to be there just for the Foundation to say that there is a place where common users can complain, but does not work at all), it asked a summary of the complaint to finally say that such a behavior was not a bleach of the privacy policy. So my conclusion, especially considering what I've said above ("a former checkuser in the Spanish Wikipedia openly stated that CU information was not actually deleted from the Foundation systems and that at the end checkuser could access such information when "necessary"), is that the Privacy Policy and the like is bullshit and that CU's work with complete impunity. But you know, Llama, that having sockpuppets is not a so bad thing, don't you? --Discasto (talk) 22:16, 17 June 2014 (UTC)

Using of wikipedia as web address

Hello,

I've found a website which use the word "wikipedia" in its address. See it. Is it authorized by the Foundation trademark policy ? - Bzh-99 (talk) 22:14, 14 June 2014 (UTC)

You should, probably, contact legal-tm-vio@wikimedia.org. Ruslik (talk) 11:03, 18 June 2014 (UTC)

Global renames

See SN#Preparing_for_global_renames permalink PiRSquared17 (talk) 03:35, 15 June 2014 (UTC)

Meta-Wiki administrators willing to provide copies of deleted Meta-Wiki pages

Are there any Meta-Wiki administrators willing to provide copies of deleted Meta-Wiki pages, who would like to announce that they are so willing? Thanks. Leucosticte (talk) 12:05, 19 June 2014 (UTC)

The correct forum is WM:RFH or Meta:Babel, not here. Do you have a specific request? PiRSquared17 (talk) 12:14, 19 June 2014 (UTC)

Emailed yesterday. Who knows, it may have gone to the spam folder. Leucosticte (talk) 14:00, 19 June 2014 (UTC)

I was asked about this offline, as I deleted a page you are requesting - a piece of pedophilia advocacy. This was inappropriate in the first place; so is asking others to email it to you. Since you were already asked in no uncertain terms to drop the topic entirely, I am inclined to reinstate MZM's block. –SJ talk  18:54, 22 June 2014 (UTC)

wikipedia.fr

Hi all, is wikipedia.fr related to wikipedia.org? Looking for information on Antoine Paternotte, proce specifically "Urbs mea nomen Athum, mercatu florida, mire est Carole, in obsequum dedita tota tuum", it suddenly appeared. Lotje (talk) 15:08, 19 June 2014 (UTC)

Yes, fr.wikipedia.org is where the string you mention appears and it is a subdomain of wikipedia.org. wikipedia.fr contains no such string. --Nemo 15:14, 19 June 2014 (UTC)

Rectius: I see some search engine indexes a search result on wikipedia.fr which returns that sentence. Yes, wikipedia.fr is a legitimate domain owned by Wikimédia France. --Nemo 15:18, 19 June 2014 (UTC)

Great, thank you. Lotje (talk) 15:54, 19 June 2014 (UTC)

Media Viewer is now live on this wiki

Media Viewer lets you see images in larger size

Greetings,

The Wikimedia Foundation's Multimedia team is happy to announce that Media Viewer was just released on this site today.

Media Viewer displays images in larger size when you click on their thumbnails, to provide a better viewing experience. Users can now view images faster and more clearly, without having to jump to separate pages — and its user interface is more intuitive, offering easy access to full-resolution images and information, with links to the file repository for editing. The tool has been tested extensively across all Wikimedia wikis over the past six months as a Beta Feature and has been released to the largest Wikipedias, all language Wikisources, and the English Wikivoyage already.

If you do not like this feature, you can easily turn it off by clicking on "Disable Media Viewer" at the bottom of the screen, pulling up the information panel (or in your your preferences) whether you have an account or not. Learn more in this Media Viewer Help page.

Please let us know if you have any questions or comments about Media Viewer. You are invited to share your feedback in this discussion on MediaWiki.org in any language, to help improve this feature. You are also welcome to take this quick survey in English, en français, o español.

We hope you enjoy Media Viewer. Many thanks to all the community members who helped make it possible. - Fabrice Florin (WMF) (talk) 21:54, 19 June 2014 (UTC) --This message was sent using MassMessage. Was there an error? Report it!

It still is kinda slow to load. Leucosticte (talk) 13:47, 20 June 2014 (UTC)

Definitely not slow for me. But yes it takes some time to load the actual high resolution photo, the mediaviewer still shows instantly the low resolution image of the thumbnail while loading the high resolution version (and for that time, you see the progress bar at bottom of the image).

Then I can can close it, and reopen it later or from a new navigation window; it is in fact very fast (even faster to load than most wiki pages) contaning many thumbnails such as galeries in Commons.

But may be you are requesting a maximum resolution for the Media Viewer, requiring you to click on the maximize button at top-right to view the full resolution (and possibly loading it only when zoomng inside with additional scollbars or click-and-drag to load the rest of the image sent in a "tiled" format? This would require some additional development in MediaWiki in order to allow it to produce separate tiles on demand, from the full resolution image. verdy_p (talk) 02:52, 21 June 2014 (UTC)

Centralization of wikis in general

I was wondering if there was a website out there, that could allow easy unifications of all wikis, from all hosters, whether from Wikimedia, Wikia, Atlassian, or just any wiki out there. See, I am an Administrator on a small biblical-history wiki, with one active contributor aside from myself. This contributor is desperately wanting administration rights;however, they are lacking the maturity and experience to lead so. I am very involved in the site creating many on-site edits, reviewing the edits of the one contributor, etc. I do have much Administration work related to the site directly, but as well as some few indirect, external resources that are used in conjunction with the site (like me posting this for example), and a sister project to the wiki, not being a wiki, but being open source. Much of my on-site work requires a joint-admin effort in order to build, organize and plan certain features and the like. I lacking in my wikitext knowledge (liking a direction of an organized set of tutorials that can teach start from finish how to learn wikitext beginner's to advanced) and the assistance of a fellow experienced admin (I do have experience in social aspects, tools etc, skills required to be a qualified admin). I was wondering in conclusion if there was a site I could perhaps recruit a qualified admin (through extensive means to find a qualified one) in order to assist me in growing the wiki. This wiki is not a wikimedia wiki. Thanks --Superdadsuper (talk) 18:56, 21 June 2014 (UTC)

Definition: Compensated Editing?

Hi, please let me express first, how disgusted I am about the TOU-amendment and that the board agreed to it, without a discussion that I would deem appropriate to the issues at hand. But now that it is part of the TOU I need your answers to a real-life question. In both cases, I made the decision to write about a specific topic myself, but got some kind of value from the subject of the article.

Once upon a time, I received an invitation for dinner by a private person, who is owner of a business and has been quite active as a philanthropist, but kept a pretty low profile about it. The occasion for this dinner was the European day of Volunteers and he had invited people who are volunteers in very different fields. Over the excellent dinner I learned more about his charity and talked of course about Wikipedia. At the end of the evening, I asked him for published information about his charity, because I planned to write an article about a foundation he founded and supported over the last decade or so. Two days later he sent me both publications by the charity and copies of newspaper and magazine articles on them. I wrote the article.

Question: Was that compensated editing?

On another occasion involving a charitable association, I met with two representatives of the organization to get access to their archive and got two cups of coffee and some cookies from them.

Question: Was that a compensation under the new TOU?

If something like that happens in the future: How am I to disclose the compensations? --h-stt !? 13:56, 25 June 2014 (UTC)

No one want's to answer? Are my questions somehow odd? Or is it maybe the TOU-amendment, that is odd, once you look at real life? --h-stt !? 14:37, 28 June 2014 (UTC)

Hello. There is no possible answer to your questions because the ToU are unclear by design, see also Talk:Terms of use. My personal opinion is that under the new ToU the situations you describe are a legal risk for you, so I suggest to avoid them or seek a clarification: the only way you can get a clear answer is by making the wikis you edit adopt clearer, alternative paid contribution disclosure policies (as Commons just did). --Nemo 15:10, 28 June 2014 (UTC)

I think if you are acting netural about the article you write and it just goes all right without telling other people those trivia, it is fine to not say anything about those.--朝鲜的轮子 (talk) 07:24, 30 June 2014 (UTC)

Ok, but by saving the message above you subscribed a contract which says the opposite. --Nemo 07:25, 30 June 2014 (UTC)

Telling it or not, I suppose such trivia does not make a difference if you are not doing things too bad. An earlier version of "ignore all rules" states "If rules make you nervous and depressed, and not desirous of participating in the wiki, then ignore them entirely and go about your business."--朝鲜的轮子 (talk) 09:31, 30 June 2014 (UTC)

Ok. Try that in court and report the results. --Nemo 09:33, 30 June 2014 (UTC)

Thanks again for your comments and questions, User:H-stt. The definition of compensation under the Terms of Use is broad, as there may exist many hypothetical scenarios when analyzing the "exchange of goods" language of the FAQ definition for compensation, such as the ones you describe. An excellent dinner could indeed be compensation, if such was offered as a direct quid pro quo exchange: "goods" for edits. The scenario you described is different: in the course of a dinner party hosted by a private entity for the European Day of Volunteers, you get to know about the host's work on charitable organizations, and decide in your volunteer capability that it would be a good idea to contribute to Wikipedia about what you just learned. You also asked yourself for material to work with as references. This looks quite different than being approached by an organization who offers to pay for a nice dinner in exchange for your contributions to their article. The other scenario that you described - receiving coffee and cookies while getting permission to access the archives of an organization to look for sources - would definitely not fall under the definition of compensation in the Terms of Use. The same rule applies: you're not getting a direct quid pro quo exchange for edits.

The focus of this change is about clarifying and strengthening the existing rules about deceptive editing - not to catch users who make occasional good-faith mistakes. Rather than analyzing the nature of the goods you may receive while editing, it's more useful to ask yourself: am I being transparent about my affiliations and motivations? Is there a reason for me not to be transparent? If for some reason you’re concerned about whether you need to provide disclosure, consider discussing it on the relevant talk page before making the edit. Best, Stephen LaPorte (WMF) (talk) 19:29, 2 July 2014 (UTC)

If that is the focus, why didn't you write the amendment in way that reflects this focus? Right now, the ToU focus on compensation, not on intent or deception.

My examples above were the easy ones. How about this one: I registered along with journalists for an event to take pictures for Commons and Wikipedia. While there, all journalists were showered with gifts and gadgets. Most of it worthless trinkets, but some stuff at least useful. I took two or three things, combined value below $10, probably below $5, but had I taken everything offered, it would have been much more.

Next example: I registered for an award ceremony to write about those who were given a significant award. Unexpectedly for me a recently published book on the founder of the award was handed out to guests and journalists. The value of that book is above $50. I took one and used it to expand the de-Wikipedia biography of that person.

Compensation? At least in the first example the organizer obviously tried to "bribe" the journalists. They went way beyond smallish give aways with a logo print. And it was clearly intended to be a kind of compensation. --h-stt !? 13:41, 4 July 2014 (UTC)

Hello h-stt, In both of these examples, the same rules apply. If you receive these gifts as a quid pro quo for contribution, then you should disclose. Thanks, Stephen LaPorte (WMF) (talk) 15:10, 4 July 2014 (UTC)

@Slaporte (WMF):: Oh, I didn't expect to be banned for any of the activities reported above. But my point is, that the wording of the ToU amendment is crap, as it uses ambiguous words without a decent definition. For a ToU this is deadly, because it can be used in favor or against persons in an arbitrary way, depending if it is me or someone suspicious of POV. But let me give this discussion one more turn. The intention of the ToU amendment can't be defined any better and will always be ambiguous, because no one ever defined the problem in a consistent way. The wish to keep out paid editors alone is not an appropriate definition of the real or perceived problem, but without such a definition you will not be able to get a practical solution. --h-stt !? 12:48, 7 July 2014 (UTC)

A technical suggestion: plausible deniability for checkusers

Though fortunately we know this has never happened, I am quite worried about if some infamous government agencies try to compromise Checkusers on different wikis and try to extort access from them, like the case when French DCRI pressured French wikipedia admin Rémi Mathis to delete an article[1]. If such case happens, the checkuser will face a hard choice: either face detention/torture, or give them access and let them rip anything they want from our privacy, and face criticism for being immoral afterwards. Both choices are not pleasant.

I have an idea to avoid this dilemma: Let the system give a checkuser two passwords, say A and B, A is for everyday use and B is for plausible deniability. When goverment agencies ask the checkuser to give them access, the checkuser gives them password B. When password B is used to log on to the wikimedia server, we will know that that checkuser might be compromised and we can remove the access. When government agencies use password B to perform Checkuser actions, the system will yield false checkuser data instead of real ones. In that way we can avoid privacy leakage and criticism of leaking privacy.

Furthermore, If government agencies somehow find the real data (for example by traffic analysis or by fishing the target) and think we are intentionally tricking them, we can just explain that as a "technical problem", since they will never know.--朝鲜的轮子 (talk) 07:01, 30 June 2014 (UTC)

Wikimedia Highlights from May 2014

Highlights from the Wikimedia Foundation Report and the Wikimedia engineering report for May 2014, with a selection of other important events from the Wikimedia movement

• Wikimedia Foundation highlights
  • 12 new individual engagement grants
  • Inviting anonymous editors to join the Wikipedia community
  • Funds Dissemination Committee (FDC) recommendations announced
• Data and Trends
• Financials
• Other highlights from the Wikimedia movement
  • Annual Wikimedia Hackathon in Zürich, Switzerland
  • "Wikidata Game": A fun new way to improve Wikidata
  • Wiki Loves Earth goes international

About · Subscribe/unsubscribe, 16:33, 3 July 2014 (UTC)

New password

Dear Meta Wiki! I'm User:Doncsecz from the commons.wikimedia.org and necessary for me the urgent help. I was lost my password and the e-mail. Exchange of the password is impossible. I was mentioned also here. Contrary to the opinion of Odysseus1479 I'm not invader. My email: doncsecz.akos@gmail.com. Doncsecz^talk 17:47, 7 July 2014 (UTC)

I believe you have misunderstood my suggestion that your Hungarian Wikipedia account might be able to usurp your Commons account; in the Wikimedia context the term is quite neutral, with no implication of impropriety. Apologies again, for neglecting to provide more explanation, and I hope a steward or someone else here will be able to help you out.—Odysseus1479 (talk) 01:08, 8 July 2014 (UTC)

Translations of the newest version of Privacy Policy

I did the old Privacy Policy-translation to Norwegian by cut and paste to a user-subpage not long ago. Then I wanted to translate the current version. For some reason I got stymied by clicking the wrong links all the time.

This one at first refused to be edited at all. The layout is not made for cut/paste-operations. When I finally found the correct link to the work-area (some of them sent me to the wrong address where I got told that the English version was the one and only.)

It also became a very long day-into-night-job, since there was only an eternally long sheet of text to be translated, and no way to store for lunch- or diner breaks underway.

That was yesterday and tonight. Today the Norwegian bokmål-version is a mix of translated and untranslated. (only in some parts I took in the English version on top, to make it easier for a reader to compare texts) Somehow there must have been a mixup in the templates (or whachamacallit). I didn't make so much of a mess out of it, although it might have happened by oversights and shortcuts I didn't see.

Conclutions: #1. Something about the layout seems to make trouble. #2. seriously long-lasting jobs may need some pitstops underway. (could be done by telling that "if you leave the page with unfinished translations, the following will happen: -----") #3. At present the translation is in need of proofreading. The present layout is IMO not exactly favorable for such,. --Bjørn som tegner (talk) 10:17, 11 July 2014 (UTC)