Block appeals of large ranges and redirect to ACC

[dqwiki]

IPv6 /40
IPv4 /18
These ranges will never be unblocked, and an account is all that is required to get through most of them. ACC can provide that without wasting admin time.
I'm hoping for more of a when filling an appeal stopper, but I may have to settle for an after-the-fact depending on the best method.
Courtesy Ping: @stwalkerster

[stwalkerster]

With the multiple request form stuff that I'm planning as part of enwikipedia-acc/waca#517 and enwikipedia-acc/waca#532, we should be able to expose a URL for you to link/redirect to which has more specific information relating to blocks, or which can route a request to a specific queue - would that suit your needs?

[supertassu]

I wonder if it be possible to have a one-click (or couple of clicks, but close enough) solution for moving most information (account, reason) to ACC so that users don't have to type that again in ACC when they have already typed it in UTRS.

I'm hoping for more of a when filling an appeal stopper, but I may have to settle for an after-the-fact depending on the best method.

I get where you're coming from, but I'm not a fan of performing logic talking to external APIs (possibly multiple times) sync during the HTTP request that stores the appeal.

[stwalkerster]

@supertassu - it need not be sync with the HTTP request - if you can capture the information which ACC needs in the appeal - namely a requested username and an email address to send the password to - you can report back to the user that a request will be submitted on their behalf and to expect an email confirmation, and then send the API call in the background to ACC. We've implemented a background job queue where tasks can be queued up for later execution by a CLI script for this purpose.

@dqwiki - perhaps we should resurrect enwikipedia-acc/waca#26 which you closed a couple of months ago?

[dqwiki]

Right now, there are so many requests coming in for these large ranges that they need to be addressed sooner than later. One /34 has 11 requests in a half a month period and several are already banned that need a proper notice.

@stwalkerster I think the plan here should be three fold.

Phase 1: Block and reroute
During this phase appeals where some options for immediate blocking and manually sending there maybe with a modified URL with parameters to autofill parts of the ACC form. I don't know if Javascript is a good option here, or if it's better to increase server load time, and run a quick check of the API on submit before storing the appeal. Maybe an extra option to include the IPv6 that is blocked would be a good idea too.

Phase 2: Supported data transfer
This would transfer only non-sensitive data (including email) though a specified API, and IPs and UAs would have to be collected after the fact from email verification on the ACC side. This would allow us to phase in the change of handling of private data and policy changes.

Phase 3: Unsupported data transfer
This would be a transfer of requested data from appeals including requiring the email on our side (though not using it - the whole point of UTRS 2 was to avoid emails and issues with spam folders) and having that in the request we send to ACC Post-appeal after validation.

[supertassu]

I was bored so I started working on the UTRS changes on the send-appeals-to-acc branch. It adds a service for checking if an appeal needs to be sent for ACC, a new status for marking that need to be sent there and some interface elements to send the user to ACC.

@stwalkerster How do you want the data on the ACC side? Should we ask for username/email from the UTRS side before sending the data to ACC or should that data be collected on the ACC interface?

[stwalkerster]

Honestly, I don't know. That's seemingly such a simple question loaded with so many hidden architectural design questions.

From ACC's perspective, we have the option of:

1. receiving a user who has been redirected to us via a simple HTTP 302 redirect and the user completes and submits the request form with no data hand-off from UTRS
2. UTRS can work with ACC to autofill a request form via passed parameters somehow, for the user to submit themselves
3. UTRS can submit a request on the user's behalf (errorring back to our standard request form), and we then do our standard email confirmation cycle
4. UTRS can submit a request on the user's behalf, which immediately enters our queues instead of going through an email confirmation pass.

I guess it depends on what data UTRS has as part of the appeal at the moment. Do you already collect verified email addresses at UTRS? Anything but (1) will require work on ACC's side, but I'm happy to do that.

How will the referral work on UTRS' side? At what point in the process will it happen?

If we're following @dqwiki's plan above (which seems like a fairly sane idea), I guess we'd go with (2) to begin with, which means we'd be able to collect any of the data which UTRS misses - hence I'm happy for ACC to collect the requested username. If we want to go for further integration, then UTRS will need to collect the necessary info. I don't mind at which point the username is collected, but it's worth noting that ACC has a bunch of checks on the submitted username which UTRS will either need to re-implement, or we'll need to reject and prompt the user for a new username at some point during the flow.

As a "phase 1" idea - how does this sound? We'll accept a POST request "redirect" from UTRS, which would let you pass on the appeal ID and email address. We would use that data to populate our standard request form with a comment linking to the appeal (are there privacy concerns here?), and ask the user to fill in a username. At that point, our standard flow will take over - we'll send an email confirmation request, and when they confirm, the request will enter our queues for processing.

I'm not keen on using a GET request to transfer data, as parameters containing private data are going to be sucked up into webserver logs - and that's not something I'm keen on. I'm also considering whether we want to exchange asymmetric encryption keys so UTRS can cryptographically sign the data passed to ACC, so we can be more confident there's not a malicious third party in the middle.

The other option is that we expose an API for UTRS to POST the private data, we respond with a token, then UTRS does a 302 redirect to ACC passing the token, and we collect the remaining info from there. It'd be a bit more effort on our side.

I haven't really thought about it in detail yet.

[supertassu]

I guess it depends on what data UTRS has as part of the appeal at the moment. Do you already collect verified email addresses at UTRS?

UTRS does not collect or store any e-mail addresses. I guess that means that the only data we need to transfer is the UTRS appeal number and (possibly) the appeal text. I'm not 100% sure what to do with the appeal text, as that probably is useful for the ACC folks but that might have privacy concerns.

Anything but (1) will require work on ACC's side, but I'm happy to do that.

I have no idea how ACC works internally but I'm happy to help with the changes if needed.

As a "phase 1" idea - how does this sound? We'll accept a POST request "redirect" from UTRS, which would let you pass on the appeal ID and email address. We would use that data to populate our standard request form with a comment linking to the appeal (are there privacy concerns here?), and ask the user to fill in a username. At that point, our standard flow will take over - we'll send an email confirmation request, and when they confirm, the request will enter our queues for processing.

By "POST request "redirect" from UTRS" do you mean that UTRS fills in the data in a hidden form field and the user then submits that form and is redirected to ACC? That sounds like a good starting point but if the data passes thru the users browser then cryptographically signing it is a must.