Does this still need to be private?
Wed, May 13
Apr 22 2020
Feb 13 2020
It looks like the only actions that are disabled by default are block, rangeblock, and degroup. The reason blockautopromote is available on enwiki is that no one's ever explicitly disabled it with $wgAbuseFilterActions['blockautopromote'] = false;, yes? The question is, do we need "community consenus" to get that line added, given that AFAIK no one has used that option in years on enwiki?
Jan 29 2020
Marking this as low priority for now. @suffusion_of_yellow - could you expand a bit on why you think that the red circle is not a good enough indicator? I agree that we are most definitely not a social media site, but regardless I think it's an effective way to notify.
Jan 12 2020
Dec 18 2019
@suffusion_of_yellow regarding "range talk", lets assume for a moment that it did exist - how would you expect notification/clearing of such a notification to function?
I'm curious how high the rate of IP users is that are not ignoring "their" talk page. Especially if they don't have a static IP. (Anybody having any numbers?)
@ovasileva: Why was this one marked low priority? I understand that people might disagree with me about T240976, and I'll respond to your question there later, but this one's a big deal. We literally have no way whatsoever to initiate a discussion with logged-out mobile users. Worse, we think we're talking to them.
Dec 17 2019
@Xaosflux: Thanks! I consider the IP issue a high priority problem, the logged-in issue less so. I had assumed that the goal had been to deliver the banner to all users, in one form or another (as on desktop), and a simple bug was preventing the display. Now that I know that part of this is intentional, I will split the task.
@Ammarpad: I only see the red circle when I'm logged in. I see no indication of any kind that there is a message, when logged out. Do you?
Dec 16 2019
If this ticket is about the lack of a "You have new messages" banner in the mobile interface for logged out users, then I do not see any bug here. Not sure as the steps are confusing and don't explicitly list an expected and an actual outcome, and if that was in mobile or desktop or in that one window or that other window.
@suffusion_of_yellow: Is one of these browser windows in private mode, or not?
Dec 14 2019
Certainly seems resolved on enwiki. I re-enabled the filter in the task, and there were no hits in about a day. Thanks!
Dec 13 2019
It's a good default to try to find and test vulnerabilities like this locally, but again, sometimes that's just incredibly inconvenient or even impossible and so discreet testing somewhere like the testwikis becomes the only viable option to fixing these vulnerabilities.
How do I find out if an XSS impacts production? I don't want to save anything like that on testwiki, even if I delete it one minute later.
Anyhoo, this page works for me even with $wgFragmentMode = [ 'html5', 'legacy' ];:
Dec 11 2019
Dec 9 2019
Haven't tried to set up the 2017 editor locally. That means installing VE first, yes?
Could varnish be doing something with the line endings? I'm in the US, so we are probably connecting to different datacenters.
User agent: Mozilla/5.0 (X11; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0
Dec 8 2019
I just realized that almost all of those edits were saved, and _lines variables are just unavailable.
Reproduced on testwiki, again with the 2017 editor: See https://test.wikipedia.org/wiki/Special:AbuseLog/55835. The some content triggered this on enwiki; see https://en.wikipedia.org/wiki/Special:AbuseLog/25537680.
Nov 15 2019
Nov 14 2019
Nov 13 2019
Ok, that explains 25321331. I also don't see tboverride in user_rights, so it looks like GorillaWarfare didn't grant Huggle editprotected rights. This can probably be closed as invalid, but 'll leave that to Daimona.
@JJMC89: That makes sense, in theory. But is it really impossible to edit EC-protected pages from Huggle? If not, EC should still be part of the rights.
Nov 10 2019
@Urbanecm: That was quick! Your commit message says users can "view any version of any filter", but the problem isn't that severe. Only old public versions are visible, which is only a problem when filter managers tick the wrong box. At least, I get an error for:
Jul 11 2019
This change could actually reduce the privacy of registered users. If "privileged user" means CheckUser, this will require massively increasing the number of CheckUsers needed to deal with routine day-to-day vandalism. A compromised (or rogue) CheckUser account is a disaster, so the privacy of registered users depends on keeping the number of such accounts as low as possible.
Jun 26 2019
@Catrope: Now, in multiple browsers, document.body.scrollWidth > 10000 in MonoBook, producing a huge amount of empty space to the right of the content. Seemed to start with this fix.
May 15 2019
@matmarex: Also tried in my sandbox, and it seems to work! And based on the latest data (created by piping variable dumps from an existing abuse filter to a throwaway Perl script), the problem seems to have stopped for everyone else.
May 14 2019
May 13 2019
Based on this extract from one of our section-blanking filters, it looks like this problem started on around 9 May, and is happening about 40 times per day on enwiki.
Jan 15 2019
In principle, you should only get the session failure error if your token doesn't match your cookie, or if the request was missing some fields. In the event you have cookies disabled you should get a different error message. (I have not tested this myself - perhaps this code is broken and giving the wrong error message)
Nov 24 2018
A very quick fix would be to restore the status quo, and temporarily remove the abusefilter-private right from all CheckUsers.
Nov 8 2018
I'd call it a low severity csrf. Write actions can still be done from a third party site - its just not a super important write action (relative to actually moving a page). In theory something like this could maybe be used to spam the log making it harder to read or maybe make an innocent person look malicious (admittedly that is a little of a stretch)
Nov 7 2018
@Anomie: When the URL includes both wpNewTitle= and wpOldTitle=, MovePageCheckPermissions is called twice, once when the form is displayed (so as to "save a click" according to the comments in SpecialMovepage.php), and again when the move is actually attempted. The second call only happens after the token is passed, and is not the problem. The first call happens without a token, and results in a publicly visible log entry associated with one's username, which is a problem when the link is followed from an external site.
Nov 6 2018
Oct 18 2018
en wiki (https://en.wikipedia.org/w/index.php?title=Wikipedia:Edit_filter_noticeboard&oldid=864548831#VisualEditor) has created an edit filter to stop the rampant misuse of indexing in user space, that upon review we think is from this tool.
Do you have evidence of that, or is it a guess?
It would be relatively straightforward to figure that out, by seeing how many of the edits that add the magic word have the "Visual edit" tag on them.