Wikimedia Forum/Archives/2014-07

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)

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)

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)

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)

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)

Copyvio in Ukrainian wikipedia

I want to report about copyright violation in Ukrainian Wikipedia. I'm a freshman to Wikipedia. On July 5 I've mistakenly created an article Kuroda Yoshitaka. I took the text for the article from my Ukrainian book "Samurai chronicles" (Курода Йосітака // Коваленко О. Самурайські хроніки. Ода Нобунаґа. — К.: Дух і Літера, 2013. — 960 с. з іл. ISBN 978-966-378-293-5) P. 877–878. which is copyright protected. Because the article didn't fit the spelling standarts adopted in Ukrainian wikipedia and there were no any official permission (neither from me nor publishing house) to copy my book or parts from it, I've asked local administrators to delete the article basing on Wikipedia:Criteria for speedy deletion. G7. Author requests deletion. The article was quiclky deleted on July 5th. But then on July 10 it was restored by admin Aced. My protest was ignored, saying G7. rule is invalid. Several times (on 10th, 11th and 13th) I've made aditional requests to delete the article because of author requests and copyright violation. But the article was again restored by Ukrainian admins and I was blocked for 3 days because of "editing war". Please help to delete article which violates copyright. Adminstrators in Ukrainian ignore my requests.--O. Kovalenko (talk) 13:55, 13 July 2014 (UTC)

The user is very very likely to be uk:User:Alex K - long-standing editor of ukwiki (ex-admin in there) and jawiki (ja:user:Alex K blocked in there) who is known to live in the same city and bear the same name. Another fact to confirm it is that article about Ukrainian cyrillisation of Japanese was extended with Kovalenko's system by Alex K who was inactive for some time (he left ukwiki for some time). In last Alex K's activity he's been moving plenty of articles to his then even not published transliteration system and was warned by an administrator (ukwiki uses another cyrillisation system per past discussions). The creative commons license can't be withdrew and it all seems to be very bad theatre play. User just seems to be angry with community for not allowing him use his own transliteration system. Actually I think CUs should be involved. --Base (talk) 18:34, 13 July 2014 (UTC)

Omg, author mistakenly created and then edited article during 5 hours (also mistakenly?) and when it was renamed, decide to delete it.--Anatoliy (talk) 18:52, 13 July 2014 (UTC)

Google Search and wikisource.org

Hello! We in the Russian Wikisource have found that Google had stoped to index new pages starting from May 2014. For example, I had created page about Lithuanian Statut in 9 July 2014, but this page is absent in Google search results now, 14 July 2014. It seems that the problem also applies to other sections of the Wikisource. It requires something to do with it, because without text indexing by search engines all the work is not available for outside users and we can forget about attracting new members.--Вантус (talk) 17:03, 14 July 2014 (UTC)

Same things for a page created 10 days ago on en.wikisource.org, the .ru page doesn't use transclusion so the trouble doesn't come from that: The Aborigines of Florida. Phe (talk) 11:13, 17 July 2014 (UTC)

How to document an event?

I'm telugu wikimedian and WMF IEGrantee. Recently, a voluntary team of telugu wikimedians along with me recorded nearly 50 audio files of Carnatic music concerts. We took proper permissions to record the music from organizers and artists. Now I'm going to release these audio files in CC-BY-SA licence, eventually upload in commons so wikimedians can use them in various pages of carnatic music portals. Along with this re-release of licence we are planning to conduct an awareness programme for musicians and others on Copyright licensing along with edit-a-thons related to carnatic music(in telugu wikipedia).

I feel this event can be more successful by wikimedians' suggestions and even my experiences could help wikimedia too. So, can I document this as a meta.wikimedia page? and how?--Pavan santhosh.s (talk) 04:47, 17 July 2014 (UTC)

Well done, concerts are something we desperately need. Sure you can and should document this on Meta: just create a page and categorise it in Category:Events or Category:Content partnerships. For instance the title can be Carneatic music concerts and te.wiki and/or Music concerts records for generic docs (e.g. copyright issues specific to concerts, technical suggestions for recording, formats, benefits, how to convince concertists, link to previous success story). --Nemo 05:22, 17 July 2014 (UTC)

Thank you Nemo for suggestions. I'll create the page. Regards --Pavan santhosh.s (talk) 12:49, 19 July 2014 (UTC)

Oromo Wikipedia

I would like to create a template in the Oromo Wikipedia that can be opened and closed (like this one. Could anybody help me with that? --Chabi1 (talk) 10:03, 20 July 2014 (UTC)

@Chabi1: according to Help:Collapsing, the ability to collapse "is not part of MediaWiki. It depends on the code added by admins to the project's MediaWiki:Common.js". So, it seems that you would have to introduce that code in to om:MediaWiki:Common.js. Perhaps those at en:WP:Village pump (technical) can help you. Best regards···Vanischenu「mc|Talk」 19:44, 28 July 2014 (UTC)

@Chabi1 and Vanischenu: Actually, MediaWiki provides a jQuery.makeCollapsible plugin by default. It is documented at mw:Manual:Collapsible elements and mw:ResourceLoader/Default modules#jquery.makeCollapsible. Helder 19:48, 28 July 2014 (UTC)

Deep conflict over an instance of paid editing

Hi, I would appreciate you taking a moment to look at an issue raised at w:en:Wikipedia:Administrators' noticeboard/Incidents#Obviously conflicted edits to A2 milk. A complaint has been made against me by a Wikipedia editor in response to a disclosure notice at my user page that I have received a fee for editing an article. My response there details the context in which I began editing the specific article, on A2 milk, and my assertion that I have no intention of promoting that milk product or brand. It also details:

• The hostility that has been directed at me -- quite unfairly -- by other editors who are, understandably I suppose, suspicious of my motives; and
• The subsequent obstruction, associated with what seems to be a reflex action to ensure A2 milk is portrayed in a bad light (see talk page at BCM7 and Scientific evidence of A2 benefits over A1.

I would emphasise here, as I have done there, that I have accepted some extensive excisions from my original edit, and continue to work on a science section of the article to improve the sourcing and balance. I have strived to collaborate. But I am accused there of trying to create a marketing pamphlet for A2 Milk, which is utterly unjustified.

I appreciate that the Wikimedia Terms of Use now accept paid editing and establish clear rules on disclosure. I would hope that Wikimedia or Wikipedia subsequently provide individual editors who accept a fee (as I have done) with some support, rather than leaving us to be hung to dry. In many ways this is uncharted territory, and I appreciate that some editors will react with fear and loathing when they see it actually taking place. I would like some statement at that ANI to address this issue and provide some clarity. Many thanks. User:BlackCab —unsigned comment by BlackCab (talk) 09:08, 19 July 2014 (UTC)

RFC: Distinguishing Wikimedia Foundation staff accounts for official actions and personal use

This discussion has been moved to a RFC subpage. —unsigned comment by Zellfaze (talk) 23:20, 28 July 2014 (UTC)