Apple testers are reporting that it's not just logged out users who are impacted – it appears logged in users on Relay may not be able to edit, either. Is there a way for us to reproduce this?

Screenshots sent over from Apple (attempting to edit a non-protected page on mobile web) below:

Confirmed this does not affect iOS app editing, anonymous or logged in only Safari.

Most logged-in editors will not be able to edit from a blocked IP. A fairly small minority are not affected, e.g. admins and users who have specifically requested to be able to edit from blocked IPs if logged in (a request they have to file from a different IP, one that isn't blocked, and which might not be granted to newcomers). Generally an IP block will block all users, registered or not.

Which projects (aside from Portuguese Wikipedia) currently disallow anonymous editing?
I have verified with @jwang (AHT team) that Portugese Wikipedia is currently the only wiki that disallows anonymous editing.

@SNowick_WMF Last week Farsi Wikipedia also made the decision to block anonymous editing. I am not 100% sure if they already did it -- last I heard they were working on making the technical changes needed for the block.

I was talking with @Urbanecm about this around mid-August, and they did some log-analysis. At that time, ~30% of beta users of iOS 15 visiting wikipedias were using Private Relay. That's perhaps a high-water mark, as I'd suspect that the sort of person who installs a beta OS is also relatively more-likely to be paying Apple for extra storage.

Someone with the appropriate access to logs could rerun the script to check how these numbers are looking post-launch. (Though since Relay is heavily flagged as being still-in-beta, I'd guess it'd skew lower than wherever it's going to settle out come 15.1/15.2.)

Flagging Analytics as IPs are used to flag readers as automated or not.

I would suspect that these IPs wouldn't be producing many (any?) automated actions, as inherently any requests from them should be coming from inside a Safari browser.

In T289795#7373088, @DLynch wrote:

I would suspect that these IPs wouldn't be producing many (any?) automated actions, as inherently any requests from them should be coming from inside a Safari browser.

Plus the script from above checks user agents, too. Or maybe I miss something?

Generally an IP block will block all users, registered or not.

This depends on block settings, but blocks under No open proxies policy indeed are generally for both logged in and anonymous users.

Note: I've added a link to the Edit Attempts by Browser and OS Superset dashboard @MNeisler created to the task description for easy reference.

I just re-organized the description to clarify actionable analytics questions. We will figure out this week how to resource answering those questions.

I would suspect that these IPs wouldn't be producing many (any?) automated actions, as inherently any requests from them should be coming from inside a Safari browser.
Plus the script from above checks user agents, too. Or maybe I miss something?

@DLynch @Urbanecm what @JAllemandou was referring to was Data Engineering's approach to identifying "sneaky" bots -- i.e. bots that don't declare themselves obviously via the user-agent information (wikitech:BotDetection). Specifically, if more than 800 pageviews come from the same IP address + user-agent in a 24-hour window (there are a few other similar checks), these requests are flagged as automated (code) and filtered out of most of our reader metrics. If Safari (and more browsers presumably) begin adopting this technology, you might see more actual human readers sharing the same IP+UA fingerprint and potentially being labeled as automated. Obviously this issue is not specific to Apple -- any increase in VPN usage could trigger the same issue -- and maybe the pageview metrics concerns are sufficiently different from the editor-oriented ones in this task, but it is worth flagging that these changes could lead to the bot detection code began returning more false positives and that would lead to corresponding (false) drops in pageview metrics.

Comment from enwiki - we routinely hardblock open proxies, including CDNs being used as proxies, which is why @Maryana was blocked from editing. Cloudflare already has Cloudflare WARP, and earlier data indicated that Cloudflare, Fastly, and Akamai were all possible exit points for Private Relay traffic, they are all on our block-open-ranges-on-sight list. We have made a specific block template for these services, but we haven't gone through and reblocked all of the known Private Relay exits using that template yet. Related discussion on enwiki from a few months ago can be found at https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Archive334#Upcoming_Apple%27s_iCloud_Private_Relay_(sort-of_VPN). If it helps anyone, a list of current egress points can be found at https://mask-api.icloud.com/egress-ip-ranges.csv (credit to @Urbanecm for showing that to me)

@Base: “but blocks under No open proxies policy indeed are generally for both logged in and anonymous users”
@GeneralNotability: “enwiki - we routinely hardblock open proxies, including CDNs being used as proxies”

This should change. If I'm logged-in, why can't I edit from anywhere?

(I'm not an iCloud+ subscriber, but I've been affected by IP hardblocks before. Can someone change the description to say “iCloud+“ instead of “iCloud”, please?)

The specific reasons for hardblocking are a bit BEANSy to describe on a public task, but suffice it to say that denying most editors the use of open or anonymizing proxies, including commercial VPNs, is necessary to prevent serious abuse. Editors who have a legitimate reason to use open or anonymizing proxies may request IP block exemption.

We (the Product department, Wikimedia Foundation) are working on an announcement. Within a week, we'll post it on Meta-Wiki, and within two weeks, promote it across the communities. Thank you!

In T289795#7408864, @sgrabarczuk wrote:

We (the Product department, Wikimedia Foundation) are working on an announcement. Within a week, we'll post it on Meta-Wiki, and within two weeks, promote it across the communities. Thank you!

https://meta.wikimedia.org/wiki/Apple_iCloud_Private_Relay, for anyone else looking for it.

Thanks for the update @AntiCompositeNumber. I have posted some thoughts at https://meta.wikimedia.org/wiki/Talk:Apple_iCloud_Private_Relay
but before this is announced more widely, I think it should be improved. For example, it should talk about affected editors, not blocked editors. No editor is blocked here, they are affected by an IP block under some circumstances, and there are many ways for them to continue editing (some have been discussed above in this ticket).

Also it conflates some privacy features such as User-Agent masking in Chrome, with opt-out VPN built into a browser. Are you aware of Google or Mozilla planning to route all their users' traffic through their servers by default? I'm not. I doubt that will happen. So it's not helpful for the discussion.

In T289795#7382434, @GeneralNotability wrote:

a list of current egress points can be found at https://mask-api.icloud.com/egress-ip-ranges.csv (credit to @Urbanecm for showing that to me)

Just a note that while some reports by Apple made it sound as if these ranges they advertised are exclusively leased to Apple, there is real world data that suggests they are NOT exclusive: https://community.cloudflare.com/t/icloud-private-relay/301450/8

Seems important.