I thought it would simply be described in the block reason (a.k.a. custom block message), which can be arbitrarily long and detailed, and which is shown in almost all editing interfaces now (https://en.wikipedia.org/wiki/Wikipedia:Mobile_communication_bugs). Apparently not in the iOS app though, so that should be prioritized.

To what extent could we specify that a message only be shown to people who are accessing Wikipedia through an IP proxy that is known to be blocked and associated with Apple's iCloud Private Relay Service?

It is possible to do this in a fully accurate way. All Private Relay ranges are officially announced here: https://mask-api.icloud.com/egress-ip-ranges.csv

For block messages, it requires re-blocking Private Relay ranges with a specific message (it can be a template for local blocks, and a link to an information page for global blocks). So, in practice, this is 4 steps: creating a meta information page, creating local block templaes (e.g. on English Wikipedia), re-block local blocks, re-block global blocks.

My previous comment might have not been accurate. Some comments at meta suggest that Private Relay egress ranges could be not exclusively used by Private Relay. We'd need to confirm if that's the case or not.

In T293849#7443348, @matmarex wrote:

I thought it would simply be described in the block reason (a.k.a. custom block message), which can be arbitrarily long and detailed, and which is shown in almost all editing interfaces now (https://en.wikipedia.org/wiki/Wikipedia:Mobile_communication_bugs). Apparently not in the iOS app though, so that should be prioritized.

@matmarex: in the above, it sounds to me like you are speaking to how the content contained within block messages can be customized.

While customizing what content appears within block messages would be necessary to ensuring people who have Apple's iCloud Private Relay feature enabled aware of why they are being prevented from editing and what they can do about it, this task is asking for what capacity we have to target who sees these messages.

...does the distinction I am trying to draw above make sense?

...does the distinction I am trying to draw above make sense?

I’m a bit confused — the block notices will be shown to people who are blocked from editing. I’m not sure what other targeting would be needed?

In T293849#7446545, @DLynch wrote:

...does the distinction I am trying to draw above make sense?

I’m a bit confused — the block notices will be shown to people who are blocked from editing. I’m not sure what other targeting would be needed?

Mmm, I see the fuzziness. Let me try articulating this another way...

Situation
Let's say...

• A) There are 1,000 people visiting Wikipedia
• B) Of those 1,000 people visiting Wikipedia, 500 people would be blocked from editing Wikipedia were they to attempt to do so
• C) Of the 500 people who would be blocked from editing Wikipedia were they to attempt to do so, 200 of these people have Apple's iCloud Private Relay enabled

Resulting question
Of the 200 people in "C)" what – if any – capacity do we have to target them with specific messages?

We can show them pretty much whatever we want, I think? (I'm not used to this specific system, so there might be format restrictions I don't know about, but at a minimum it's pretty broad.)

Each IP block can be given a custom message. Here's one of the affected addresses -- note the "reason" field, which will be displayed whenever the block is triggered (and on the user page for the IP).

Here's the full display when the editor is opened:

Note that the central orange block has some text specific to explaining the VPN issue, because of the type of block. @MarioGom's suggestion above was that the existing blocks could be edited so that the template they reference is even more specific and addresses the iCloud Relay issue.

One of my primary communication concerns is the way that layered blocks are currently handled. We want to be able to block individual exits with highly informative block messages. We can do that (and are doing that), the issue is that if they are on an underlying range that is already blocked for one reason or another, (enwiki) users see the following, which is a transclusion of https://en.wikipedia.org/wiki/MediaWiki:Blockedtext-composite.

It's not feasible to block "around" every exit node out there, and it is often necessary to block the underlying ranges as well. I'm not sure whether this is just an issue with the way enwiki has the composite text set up, or whether it's a mediawiki issue (if it's the latter, it's probably already tracked somewhere), but addressing it should be a priority task if we want to ensure that we are clearly communicating to people why they currently can't edit.

A second issue that is mostly going to be a concern for wikis that rely on Stewards to handle proxyblocks is that global blocks are currently plain text only, as opposed to the block template transclusions that are possible on individual projects. The very broad wording about webhosts that global NOP-block messages currently use is probably not going to be easy to parse for the average internet user.