Page MenuHomePhabricator

Understand impact of Apple's Relay Service
Open, HighPublic

Description

In the most recent OS updates (iOS 15, iPad OS 15 released on Sept 20, 2021) and the upcoming Mac OS 12 (likely to be released in mid-late October 2021) Apple has created a new service for users of iCloud to anonymize their internet requests. Although not a VPN service, the impact is similar, in that users IPs will no longer be transmitted with requests, instead an IP from Apple's service will be used. Initially this feature will be in "Beta", even when the rest of the OS is released, but it will be available on all apple devices, and will impact both desktop and mobile traffic.

Given that IPs are a primary signal and only way to prevent repeated account creation and sock-puppetry, this means many Wikis will likely need to or will at least consider blocking all edits from Apple's IPs, as we do with VPN. English Wikipedia has already discussed this here.

Because this is a new feature for Apple it is not clear how big the uptake and impact here will be. The goal of this task is to estimate how severe these impacts might be to determine what if any mitigation strategies or conversations are needed.

Below are questions we intend to answer, all in service of understanding the potential loss in editors and edits from a wholesale block of these users, and to come up with ways to allow those users to easily continue contributing.

  • Market info
    • [Roughly from public info] What proportion of Apple editors are iCloud users?
    • [Roughly from expertise/past experience/public info] what proportion of iCloud users are likely to use this feature?
  • User experience: Given our issues with unclear, undisplayed or unusable block messages, what user experience will these editors have when they try to edit after installing the OS update?
  • Community: Is the IP exemption policy and admins dealing with IP exemptions aware of this change and able to handle additional requests? What would their general stance to these requests be?

References

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Elitre added a subscriber: Johan.

Adding editing and growth folks as their numbers will be most directly impacted.

@JMinor: I suspect I am not the person you wanted to Cc:

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:

image0.png (2×1 px, 1 MB)

image1.png (2×1 px, 1012 KB)

image3.png (2×1 px, 929 KB)

image2.png (2×1 px, 818 KB)

JMinor raised the priority of this task from Medium to High.

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.)

JAllemandou added a subscriber: JAllemandou.

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.

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.

MMiller_WMF added a subscriber: kzimmerman.

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

JMinor updated the task description. (Show Details)

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)

PMG added a subscriber: PMG.

@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!

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.

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.