1. could the error replaced by a clear error which says what really happens on PHP 7 ?
2. apparently the max count of nodes is broken on the current setup of mediawiki. Maybe it is not that useful ? Once the count is write, Probably it can't be fully removed, but can it be increase that it don't create problems.

Sorry for the disturbance, I remembered wrongly to see such entry older than 2018. I must have confuse with creation of users. One can close the ticket from my point of view.

What is the rational behind using UUID ? some kind of counter could not work ?

as T151770 shows the heavy use of cookies lead to randoms bugs with intensive user of wikimedia websites on lastest default versions of firefox. I hope so that enough workforce is put in. I'm afraid it is not the case as this bug depend on T19108 which is not taken by anybody

It looks like it was a transient issue and was fixed since,

thanks a lot

@Josve05a If I understand well, it is just a matter of wikidata policy, if Category would be treated as a valid interwiki for commons, it is not a technical issue (I mean there is no need of new development). So it would be relevant discussion on wikidata, but not here. (Anyway, before a development, a consensus on political issue must be reached first)

@Acer: what is your "reasonable, valid, correct, ethic reasons to do so" ? Making your purpose less clear make not more reasonable, valid, correct an ethic.

As I see, the ip limit removing for saving is not needed as the participant of an event should create an account.

In T109724#1939021, @Nemo_bis wrote:

In T109724#1892727, @xcombelle wrote:

That depend on which stats you are looking http://en.wikipedia.org/wiki/User:Xavier_Combelle/TriggerInLog doesn't exist and it appears in http://stats.grok.se/en/201508/User:Xavier_Combelle/TriggerInLog

Yes, that used to happen but no longer does AFAIK. See the link I provided.

In T109724#1889830, @Nemo_bis wrote:

A request to Special:MyPage/ccvhjhdkjvkvkhjhkvkjvdh appears in the pagecounts as a visit to User:Xavier_Combelle/ccvhjhdkjvkvkhjhkvkjvdh

I'm not convinced of the proposed solution. Why downgrade MediaWiki functionality because of an information leak in Wikimedia Foundation infrustructure? I'd rather reverse the burden: we could just stop counting one visit to "User:Xavier_Combelle/ccvhjhdkjvkvkhjhkvkjvdh" and instead add 1 to
"Special:MyPage/ccvhjhdkjvkvkhjhkvkjvdh".

We stopped counting the 302'ing special pages after https://meta.wikimedia.org/wiki/Research_talk:Page_view/Archive_1#Special_namespace_and_actual_problems . It doesn't seem impossible to do the opposite (under some condition):

how would the definition count redirects? Only towards the redirect source, only to the target, both, or some other scheme? --QChris (WMF) (talk) 11:33, 23 October 2014 (UTC)

In T109724#1889831, @Nemo_bis wrote:

Also, the description of the problem lacks one step: the attacker first needs to create "User:Xavier_Combelle/ccvhjhdkjvkvkhjhkvkjvdh" (presumably by creating such a subpage for all users of a wiki?) because 404 are excluded: https://meta.wikimedia.org/wiki/Research:Page_view#Step_1:_apply_general_filters

In T109724#1637303, @csteipp wrote:

Well this solution does seem kind of icky due to all the special casing very early in the MW setup process, I will admit its elegant in that

• Not specific to our setup. Would work with other analytic setups that third parties might use.
• Does not require extra url parameters that user's could forge, or really long ugly tokens.
• Would allow us to do something like "redirected from Special:MyPage", although this patch does not do that (or other things like setting rel=canonical link)

I'm starting to think this might be the way to go, since I think this would also prevent the attack on very low traffic wikis where there might only be a handful of visits to User: namespace pages in an hour, so even sending the user to just Special:MyPage could leak that the user was one of small subset of users.

In T109724#1634944, @Bawolff wrote:

My question is when using the X-analytics:dnt=1 header, where does and where does not appear the visit on the different log and stats? To avoid the leak, the only thing it needs is not appear in page counts. It can still appear on all wikimedia logs and stats. So I thought that setting the header would just remove it from page counts and so would not impact other internal stats as the ones needed for "tracking visiting stats of the target of Special:MyLanguage" but maybe I'm wrong.

Oh my bad, I was using page stats and the public page counts as synonyms. I meant just the public page counts (e.g.the stuff on dumps.wikimedia.org , stats.grok.se etc)

Do you mean that in the envision setting the visits are not tracked? What I thought is that they will simply not appear in public page counts?

I'm not sure what you mean by this. Currently Special:MyLanguage/foo redirects to foo/en-gb or foo/fr, etc based on a setting in Special:Preferences. This yields a small amount of private info being leaked by the public stats, which could be exploited, but seems like it would be much more difficult to exploit, compared to Special:MyPage.

In T109724#1633566, @Bawolff wrote:

For reference, there's also similar issues with

• Special:MyTalk
• Special:MyContributions (redirects to Special:Contributions/Username)
• Special:MyUploads
• Special:AllMyUploads

In T109724#1628569, @csteipp wrote:

T109724.patch1 KBDownload

Simple patch to add dnt=1 into x-analytics for User / User_talk namespace pages that don't exist.

An attacker can still send the user to just Special:MyPage on a wiki where they hope the user has created their userpage, and that might narrow down the user to a set of potential users. But that would only work for very targeted attacks, and I'm not sure if that's in the same category of adding a clearly wrong reference in an article to a site you own, log the IP's referred from the wiki, and then watching which account deletes it on wiki.

In T109724#1619307, @Bawolff wrote:

From a MediaWiki code prespective, to do what you're referring to as a "soft redirect", we would have to add a special case to MediaWiki::initializeArticle (or use the InitializeArticleMaybeRedirect hook). It would be much cleaner to just make special:mypage add a url paramter to the page it redirects to, and set mediawiki to add the dnt header on detection of that url parameter (if we're worried about people forging the header, it could be hashed with some secret/time sensitive or something). However, this would look less elegant to the user (And I'm unclear how it would interact with varnish cache. Presumably we would only send the header if the user is logged in, and then that would be less of a concern. There's also the issue about if varnish would override the header that csteipp is talking about, which I have no idea about)

@csteipp or somebody else: Could a developer of mediawiki be involved for analysis of my "soft" redirect solution ?

@csteipp actually the URL is also replaced in browser history

filtering the non existent page could limit the attacking power but not removing it. For example a burst on page view could still be detected

A possibility would be [[Flow:<some-id>/original-title]] would be the canonical link to a flow discussion, which if the discussion is renamed, would become a permanent redirect to [[Flow:<some-id>/new-title]] it is what http://stackoverflow.com does for questions and I found it handy (modulo the fact here is a lot of more Flow-id than stackoverflow questions)

If you watch on the request your browser does https://en.wikipedia.org/w/index.php?title=Special:MyPage is redirected to https://en.wikipedia.org/wiki/Special:MyPage witch is redirected to https://en.wikipedia.org/wiki/User:<your_ip_or_your_user_name>

@Bawolff just tested https://en.wikipedia.org/w/index.php?title=Special:MyPage/ccvhjhdkjvkvkhjhkvkjvdh redirect to https://en.wikipedia.org/wiki/Special:MyPage/ccvhjhdkjvkvkhjhkvkjvdh

Sorry for the noise, it's clearly a browser thing I had got similar behavior with another site.

thanks

On French wikipédia, still with IE9 there is different behavior on debug mode and on normal mode.
The major problems are the edit button (in wiki mode: "Modifier") doesn't display neither the portal parts nor the categories.
It was described the 7th august on Le Bistro (the French village pump) first in this thread
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro/7_ao%C3%BBt_2015#Les_portails_et_les_cat.C3.A9gories_n.27apparaissent_plus_.21