Talk:Apple iCloud Private Relay

We are looking for answers to the following questions:

• Are you seeing problems related to the current iCloud Private Relay global blocks on your wiki?
• Do you think that it's likely that good-faith editors will be affected by blocks?
• While we do not know for sure, we think that this situation may grow over the next couple of years. It is possible that other browsers, such as Chrome and Firefox, could follow a similar pattern and also restrict access to IP addresses. If this happens, it will be a major change in how the internet works. What do you think, in what ways would this change affect the wikis?

Write in any language you are comfortable with. Thank you!

(Translate this page)

References

Blocked editors?

On the question Do you think that it's likely that good-faith editors will be blocked?:

No editor is blocked here, but a set of proxy ranges. Affected (not blocked) editors will be able to continue editing through other browsers, it does not affect the Wikipedia iOS app. It will not affect users who disable Apple iCloud Private Relay either (and there are good privacy reasons to disable it). So, to have a more fruitful discussion, we should discuss the exact circumstances in which editors are affected (not blocked), and what are the different ways to mitigate it, and instructions we can give them. MarioGom (talk) 09:10, 17 October 2021 (UTC)

There are some important changes to consider. First, macOS Monterey (released Nov 2021) includes Private Relay. There is no whitelist option and unlike a VPN, it isn't simple to turn on and off as it is buried in OS settings (which requires Admin access). For now it is opt-in. As of last year, iCloud+ had over 170m users and growing.

When the most common IP block was either through VPN, Opera, or TOR, the IP policy made sense. Apple users opt-in for privacy features like App Tracking (blocking IFDA) has grown to the point of affecting 2021 Q3 earnings for Facebook/Meta and Snap. That feature has been available for public users since April 2021. Within 3 weeks, over 90% of users chose to opt-in to the privacy feature (https://www.flurry.com/blog/ios-14-5-opt-in-rate-att-restricted-app-tracking-transparency-worldwide-us-daily-latest-update/). As for Apple subscribers, I read an estimate of 190m last year, and Apple's recent financial report (which doesn't break out subscription type e.g. Apple One vs Apple Music) which noted 745m subscribers CountryMama27 (talk) 18:37, 20 November 2021 (UTC)

I cannot stress this enough, and I think it's important to frame this debate correctly when it comes to discussing these blocks. I have made somewhere around 1200 rangeblocks of webhosting providers in the last 5 weeks or so. Not one of them was targeted at a user. Blocks of webhosts and other anonymisers are a purely technical matter; the only block targets they have are server racks standing in some industrial facility, not the people using them. The only thing a VPN user needs to do in order to edit is to turn off the proxy. iCloud Private Relay is more or less functionally equivalent to a VPN service (though there are some implementation differences), and considering the crucial role IPs play for our current (and lackluster) anti-abuse tooling (and hence the substantial damage anonymisers do), we have no choice but to block it. The important question is how we can communicate these blocks in a way where affected users are fully informed about why they were blocked, and how they can disable the relay to continue editing. Blablubbs (talk) 10:42, 17 October 2021 (UTC)

This is an absolutely critical distinction that needs to be made very very clear in this debate. Proxy blocks are not targeted at individuals. Blocking iCloud Private Relay is in effect the same as any other proxy or VPN. Indeed, global policy states that [p]ublicly available proxies (including paid proxies) may be blocked for any period at any time. While this may affect legitimate users, they are not the intended targets [...] (emphasis mine). In my opinion the phrasing in the original post needs changing ASAP to prevent confusion. firefly ( t · c ) 11:40, 17 October 2021 (UTC)

@MarioGom, @Blablubbs, @Firefly, @GeneralNotability thank you for pointing this out. This very discussion is for us all to have a common picture, which includes the WMF learning from you. Do you think I successfully corrected this? Perhaps I omitted something? As this discussion continues, I will be improving the page based on your feedback. SGrabarczuk (WMF) (talk) 16:17, 19 October 2021 (UTC)

SGrabarczuk (WMF): Yes. I think the changes look good. Thank you! MarioGom (talk) 16:27, 19 October 2021 (UTC)

I'm glad to learn that. I'm thinking of linking to a page making it easier to understand the difference between a blocked editor and a blocked IP range. Apparently, there's no jargon-free page explaining exactly that. There are WikiProject on open proxies/Help:blocked and Help:Range blocks, but are they helpful in this context, really? SGrabarczuk (WMF) (talk) 16:39, 19 October 2021 (UTC)

I don't know about the right page to link to, but I would like to know if there is one too. I think one of the action items for this issue would be having a user-facing information page for CDN blocks, and one specific for Private Relay (in line with the proposal at #Actions). See No open proxies/P2P for a similar information page dealing with P2P proxies, and en:Template:CDNblock for the current block template for CDN blocks on English Wikipedia. MarioGom (talk) 18:07, 19 October 2021 (UTC)

@SGrabarczuk (WMF) yes I think that is far more accurate, thank you :) firefly ( t · c ) 16:47, 19 October 2021 (UTC)

@MarioGom, I've now updated the page. I've written about the iOS app, the option to disable the service, and to change the browser. SGrabarczuk (WMF) (talk) 02:17, 27 October 2021 (UTC)

First, background: I could not reply from Safari. As a good-faith editor, I could neither edit nor comment (but see below, the end). Please therefore be aware that this conversation is likely to exclude people who might have commented but are blocked. That affects the data.

How I got in: I used a browser that I do not usually use, signed in again (but see below), retrieving my password, and took the trouble.

Before that: I wondered what the problem was. I went to Safari preferences and unblocked everything I could for Wikipedia. No change. For my university, I have access to a VPN but I checked that it was not in use. I spent some time searching to find out what the problem was. Did not find an answer, in fact until I found this page. Apple's Private Relay.

Rebuttal point: It is specious to say that no persons are blocked. Persons - as good faith contributors - are the foundation of the Wikipedia world. When you block their interface you block them. To forget that is to forget what Wikipedia is about, I would argue. I'm therefore using a personal experience, for the purpose of illustration, to make a general assertion.

It could be that all the other Mac Safari users (and any in like circumstances now or later as suggested in the Talk) will take the same route that I have done, it may be that they will not. It may be more likely to affect those who are specialists in certain fields and sometimes contribute, it's not a routine part of their working week. I cannot predict with certainty, but I can say that I was alarmed to discover myself blocked and did not like the experience. My guess is that will not be uncommon.

Here is the final irony: I see a message that says: You are not logged in. To receive attribution with your name instead of your IP address, you can login. So when i was logged in I could not post and when not logged in I can. And the update on making the reply: "You are no longer logged out, so the action could not be completed." At the same time it still says that i am logged out. So I am both logged in and logged out at the same time with my credentials above Maven111 (talk) 17:59, 20 February 2022 (UTC)

It may occur or happens to block a good faith editors. This matter really need to be checked. And it will be scary if chrome or Firefox take the line also Musa Vacho77 (talk) 10:16, 19 October 2021 (UTC)

I don't see any evidence this will be the case for Chrome or Firefox in the near future (see the section below). MarioGom (talk) 10:35, 19 October 2021 (UTC)

Well to me I don't think it's not a good idea if good faith editors are been blocked it will be very very bad for that to happen Mc aboki (talk) 07:17, 25 October 2021 (UTC)

I am a good-faith editor whose editing of pages including talk pages (but not this page) has been IP blocked after using Apple iCloud Private Relay (Beta). I turned it off to edit and reloaded the pages in Safari but am still blocked. I submitted an appeal ticket. Jeisenberg (talk) 15:50, 11 March 2022 (UTC)

Hi everyone. I’ve been using Private Relay on my iOS device for a little while now and on macOS more recently. I’m a casual Wikipedia editor and noticed an IP range block when I went to edit a page today. Two stacked blocks, no mention of Private Relay. It wasn’t apparent to me why this happened, and I don’t think many users in similar situations would know why it happens either. Just because it’s turned on does not mean a user is acutely aware that it is turned on. There’s no visual indicator inside Safari about it, which I think will lead a lot of people to scratch their heads and give up on editing. That’s what I almost did today. And just before I did, I thought, “Maybe it’s Private Relay?” To turn it off, you have to navigate outside of Safari to iCloud preferences. And then you have to quit and relaunch Safari (they don’t tell you this part.) And while I can edit after this is turned off, that doesn’t mean I want to turn it off.

I’ve read some comments here about having a more-specific “iCloud Private Relay” message so users know how to turn it off, but I want to address “turning it off.” While users can do this to edit Wikipedia, because it cannot be turned off per domain (as others have mentioned), it is going to come up again and again if iCloud users want to have this feature enabled for their own privacy. (Which I imagine many will feel inclined to do and forget it’s on entirely.)

Since editing Wikipedia is volunteer work, I think it’s in Wikipedia’s best interest to make it as easy as possible to edit, removing any barriers that might get in the way so that Wikipedia content can continue to grow and improve in quality. If the prevailing idea here is to continue to block these ranges, thus blocking users from editing, I wouldn’t be surprised if people give up because they either don’t want to bother turning it off or because they don’t know why they’re blocked.

I read comments from others how “users” aren’t being blocked, but “ranges” are being blocked instead. I don’t think there’s a functional difference here. I recognize the technical difference, but if users are prevented from editing, I think they’re effectively blocked. They certainly will feel that way. (I did.) Editing Wikipedia is not always easy, and I think not everyone is aware how to navigate the minutiae of Wikipedia’s policies to request an exclusion. I know I’m not aware of how to do it, and I’m internally debating whether it’s worth more of my time to figure that out just to I can contribute more volunteer work.

Finally, I’d love some clarification from someone about why a logged-in user would experience a IP range block to begin with. Is it wholly necessary to do this, if we can identify a user another way than their IP address? It seems that people who have an account should maybe not be affected by this (or perhaps be less affected by it?). It’d be good to know why there’s not some kind of exception for logged-in users, because I only see this situation getting worse. A better, more-clear alert of why someone is prohibited from editing won’t solve this issue.

If every Wikipedia editor who has this feature turned on runs into a block message, then Wikipedia becomes tougher to access and edit. That does not help Wikipedia or those who benefit from editors’ contributions. Louiemantia (talk) 16:32, 17 March 2022 (UTC)

I have been unable to edit Wikipedia for some time now, due to this block. I have been editing Wikipedia since 2007, and I consider myself adept at using Wikipedia and the internet in general, but this block was very difficult to understand, and frustrating. The difference between an IP block and a user block is irrelevant to someone like me, who wants to edit a page but cannot. As more and more people use iCloud Private Relay, this will become a major issue. Julian BH (talk) 01:06, 20 April 2022 (UTC)

I had this same issue, but I didn’t realize it was related to Private Relay until after having my block appeal denied, told I was using an open proxy (which confused me as I was not), I contacted my ISP, they checked some things then had me check to see what my IP address is, and that’s where it indicated something about iCloud relay. I had to google that, which lead me to find Private Relay enabled in my settings on iPadOS. I use Safari on iPadOS 15.4 currently. I don't know if Wikipedia can tell if it’s related to Private Relay or not, but it certainly would have helped me out if I had known my block was related to it instead of a blanket statement about open proxies. Maybe a sentence about Private Relay being enabled in the block message would help for us dummies who need a shove in that direction since we may not associate Open Proxies with Private Relay? Wickedlizzie (talk) 01:04, 21 April 2022 (UTC)

Hi, I believe the policy of blocking edits from Editors with an account in good standing just because they're using iCloud Private Relay (IPR) is flawed because it forces Editors to switch off IPC, thus putting them at risk of government/ISP surveillance, which is a problem for people editing 'controversial' topics, such as LGBT-related pages in countries with homophobic laws. And on the subject of vandalism, I do not see how this is an issue for edits from logged-in editors. --Friend-of-the-planet-99 (talk) 15:33, 8 May 2022 (UTC)

On Chrome and Firefox

About Chrome and Firefox also restrict access to IP addresses:

Do we have any information that suggests that Google and Mozilla will be enabling a VPN/proxy for their users by default? I'm not aware of such plans. And if they do, I doubt it will be enabled by default, and without a way to add site exclusions. If Google had plans to route all their users' traffic through their servers by default, I would urge you to oppose this change, as it will eventually lead to a major privacy issue, see en:PRISM (surveillance program). MarioGom (talk) 09:14, 17 October 2021 (UTC)

I agree with MarioGom 's opinion of more fruitful discussion. I don't know why we need to discuss this hypothetical question since it is meaningless to mitigate the effect of blocking iCloud Private Relay IPs. Google and Mozilla have their own VPN service already and AFAIK there is not a plan of restricting access to IP address at present. Thus it may impossibly Chrome and Firefox restrict access to IP addresses. Thank you. SCP-2000 12:24, 17 October 2021 (UTC)

Well I agree SCP-2000. That it's meaningless to mitigate the effect of blocking iCloud private relay ips, on my own opinion I think they should trade with courtion Mc aboki (talk) 07:26, 25 October 2021 (UTC)

@MarioGom, @SCP-2000, @GeneralNotability, in my latest update, I've explained that the statement about Chrome and Firefox being likely to follow is based not on direct evidence but on market analysis. Is that part clear now? SGrabarczuk (WMF) (talk) 02:21, 27 October 2021 (UTC)

I found two interesting articles of note. The first, by IAB Tech Lab, written after WWDC but before Private Relay's release, refers to Apple's 170m iCloud+ subscribers, and mentions Microsoft's PARAKEET and Google's FLEDGE IP relay/anonymizing projects. I have zero interest in researching what those are, but you are welcome to: https://iabtechlab.com/blog/private-relay-by-apple-data-protection-middleware-and-proprietary-approaches-vs-standards/. The second article is from a marketer's POV, and posits that Private Relay will grow in scope and depth (https://digiday.com/marketing/how-apples-private-relay-could-be-the-beginning-of-the-end-for-fingerprinting-on-ios-devices/). Given the widespread adoption of App Transparency in iOS 14.5 and other micro and macro trends, I think IP redirection will expand to affect more than just Apple users. CountryMama27 (talk) 19:43, 20 November 2021 (UTC)

PARAKEET is an anonymizer proxy and web API, intended to expose a controlled amount of information to advertisers and trackers. Probably doesn't affect normal websites.

FLEDGE, these days called the Protected Audience API, is a similar web API but does not involve a proxy (Google has a separate project called IP Protection for that).

Both of these are around the idea of websites being able to sell ad slots on their pages to advertisers, with the browser mediating the ad selection so the ad is relevant to the user's interests but the advertiser and the ad hosting website doesn't learn much about the user. Tgr (talk) 19:08, 9 September 2023 (UTC)

FWIW Edge also has a privacy proxy (called Microsoft Edge Secure Network), since 2022 May. It's opt-in for now. Tgr (talk) 19:10, 9 September 2023 (UTC)

IPv6

With the advent of IPv6, IP addresses are more dynamic than before. This problem will only be worse in the future as more users come online.

The document mentions IPv6, but I'm not sure how it is related to iCloud Private Relay at all. Also, is there any evidence that IPv6 (/64 ranges) are more dynamic than IPv4? It might be more dynamic for some ISPs, and it might be less dynamic for other ISPs. But the overall assessment that it will be more dynamic seems somewhat counter-intuitive. MarioGom (talk) 10:08, 17 October 2021 (UTC)

I agree - I think this impression (that IPv6 addresses are more dynamic) comes from a slight misunderstanding of how IPv6 works in contrast to IPv4. With IPv4, end users are generally assigned a single address. However, with IPv6, given that there is an enormous pool of addresses (and one of the ultimate 'goals' of IPv6 adoption is to remove the need for network address translation and private subnets), end users are generally assigned a "/64" - or a range of 18,446,744,073,709,551,616(!) addresses. Each one of those addresses 'belongs' to the same LAN. (There are exceptions of course, particularly with mobile/cell providers.)

As such, an IPv6 /64 can effectively be treated the same way as a single IPv4 in most cases - indeed on enwiki we have a widely-used saying courtesy of functionary TonyBallioni - "just block the /64". If administrators block individual IPv6 addresses they will indeed get the impression that the user can just 'switch IPs at will' or that addresses are more dynamic - if they block the /64, that will have the same effect as a single IPv4 block. firefly ( t · c ) 11:35, 17 October 2021 (UTC)

IPv6 solves a lot of problems that hacks like NAT are causing. I don't se how IPv6 makes anything 'worse'. /37.247.4.194 06:53, 19 October 2021 (UTC)

I think it is mostly to emphasise that IP assignment will be more fluent in general. This stuff gets a bit complicated. Even with the advent of IPv6, the chances that you have a fixed or even just a long lease IP address are becoming lower and lower. This is counter to what the point of IPv6 originally was expected to deliver perhaps. The cause of this is that there are simply so many new devices being added to the pool of what we call the 'Internet'. All these 'newer' devices are increasingly mobile and multi network as they travel around (and many use IPv6 and more will). That some blocks of /64 are somewhat static (to a home for instance) is true but in the grand scheme does that weigh up to how many devices are receiving 'dynamic' /64 blocks ? We also know that some ISPs have been subdividing /64 addresses among multiple customers. That again goes counter to the idea of IPv6, but it has been observed and in the end, the /64 rule is not really a hard rule at all. —TheDJ (talk • contribs) 08:25, 20 October 2021 (UTC)

You are right. My point is that this dynamicness is already present on IPv4. MarioGom (talk) 10:36, 20 October 2021 (UTC)

Provider IP pools, railroad travellers

Indeed: in dewiki we do get complaints from benevolent contributors who are affected by range blocks: customers of T-Mobile Austria, Magenta Austria, Unitymedia Germany, travellers on Deutsche Bahn trains (they get en:DigitalOcean-IPs), and probably other situations where you get a pooled IP together with a thousand people. Not many (4-5 times a year) but there might be some underreporting. I'd like to suggest significant shorter range blockings, and exclusion of registered users by standard. --MBq (talk) 14:57, 18 October 2021 (UTC)

MBq, I think there's a conversation to be had about lowering standards for IPBE, but the potential for abuse via these sorts of providers is so high that I believe blocking them is the only practical option. GeneralNotability (talk) 14:59, 18 October 2021 (UTC)

Can’t prove you wrong. Vandals hide their identity. But non-vandals want to obfuscate their IP too (I’m doing it myself right now). If the predictions overleaf are right, we will soon have to change our policy, or to turn away lots of contributors. Forced to chose between safety and openness, I would take the latter. —MBq (talk) 20:28, 18 October 2021 (UTC)

Complaint [1] incoming today: block on en:Hurricane Electric (2001:470::/32), very busy range, might affect hundreds if not thousands of possible users… to fight against one [2] vandal. Method seems corrupted to me —MBq (talk) 19:40, 21 October 2021 (UTC)

Objection

SGrabarczuk (WMF), you've posted a message about this to (at the very least) enwiki's Village Pump/Miscellaneous, enwiki's Administrators' noticeboard, the Global Sysops talk page, the Wikimedia Forum, and the Stewards' noticeboard. I have to object to the way this announcement was constructed, because:

• It is unnecessarily alarmist (scare quotes around "open proxies", claiming 3-5% of editors will be blocked without actual evidence as to the number of users who use the premium iCloud)
• Is inappropriately worded in a "we're running out of time" way (I will note that I raised this on enwiki four months ago and a Phab task has been open for about two months, so this isn't us scrambling to react to surprise news)
• It does not separate speculation from fact (Next, other browser providers may do the same. The problem will grow. - I have seen no evidence of this other than the questions at the top of this page)
• It ignores the fact that users can turn off Private Relay
• Generally, it appears to frame the debate in such a way that people who show up to this discussion will be inclined to oppose the existing policy.

You have also not acknowledged the concerns made on this talk page, which is quite disappointing. If this were a normal RfC, rather than a WMF discussion, you would (at the very least) have been reprimanded for how you presented the discussion to others in a non-neutral fashion. I cannot help but think we're in another one of those situations where the WMF has already made their decision and does not intend to actually listen to community feedback (compare, for example, the recent community objections to how rebranding was handled). Those who know me will know that I do not make that accusation lightly or hysterically; I generally try to do my best to cooperate with the WMF, but I am very unhappy with how this is being approached. I respectfully ask that you pause further announcements and engage with the community members who have already raised concerns here. GeneralNotability (talk) 22:27, 18 October 2021 (UTC)

The most upsetting part is that I know there are things we can do better - for example, we can discuss changes to our IPBE policy, and we definitely have work to do on the blocks on known Private Relay ranges (I believe most are just "colocation webhost" or "proxy" blocks, which is unintelligible to the average person - on enwiki we have a template specifically designed to say "you're using Private Relay, turn it off please"). I want to make things better for the end user. But if this is how the WMF wants to approach things, it doesn't make me want to improve, it just makes me want to dig in my heels and protest. GeneralNotability (talk) 22:31, 18 October 2021 (UTC)

When I edit on enwiki logged out using iCloud Private Relay, I just see a message saying my IP address is blocked. I don't see a reason template (on mobile). Note that iCloud Private Relay is not available on desktops ATM, except in beta versions. When I edit logged in, I see a generic "web host provider / colocation provider" block message. There is definitely no tailored block message, at least not IME. ProcrastinatingReader (talk) 00:04, 19 October 2021 (UTC)

As of November 2021's release of MacOS Monterey (12.0), iCloud+ Private Relay is opt-in on Mac desktops. Too soon to gather data on its adoption. Of note, > 90% of apps were (opt-in) blocked by iOS users within 3 weeks of App Tracking Transparency in iOS 14.5 last April CountryMama27 (talk) 19:19, 20 November 2021 (UTC)

...proper display of block messages would be an immediate step to mitigate the impact this has, for example. Blablubbs (talk) 22:33, 18 October 2021 (UTC)

SGrabarczuk (WMF): Given that you decided to push this message before amending any of the issues raised here, I think we should spare frustration to every party: what is your desired outcome, exactly? MarioGom (talk) 22:57, 18 October 2021 (UTC)

Hello @GeneralNotability. Before any of us (WMF staff) will reply to your main points of concern, I'd like to explain that this was a single announcement written a week ago. At that time, no comments were added, and no concerns were raised. In the meantime, it was translated into several languages. We haven't talked about any follow-up messages yet. I think if any are created, they will reflect the discussion. I'm sorry that this was misleading. We didn't plan any solutions within the WMF. SGrabarczuk (WMF) (talk) 22:58, 18 October 2021 (UTC)

@SGrabarczuk (WMF): Where was this announcement drafted up? Blablubbs (talk) 23:03, 18 October 2021 (UTC)

In my sandbox. You can find everything in my contributions here on Meta-Wiki. Anyway, seeing the first reactions, I know this announcement was not good. Also, take a look what I wrote in reply to Yair rand's comment. I made some of you concerned about the announcement. The objective was just to inform you about the page (this is a reply to @MarioGom's question). Again, I'm really sorry. SGrabarczuk (WMF) (talk) 23:55, 18 October 2021 (UTC)

Thanks for the update. There's been an obvious mismatch in our expectations about communication and timeline around this issue, but I'm moving on to discuss some technical aspects of Private Relay and possible mitigation strategies in separate sections. Best, MarioGom (talk) 08:24, 19 October 2021 (UTC)

Seconded, and I apologize for getting so worked up about this in my previous message - that was not in line with how I want myself to interact with others, and I'm sorry. SubjectiveNotability (talk) 13:42, 19 October 2021 (UTC)

This doesn't seem to be about "mass ip blocking" at all - as was communicated, this is blocking of a very targeted set of published addresses isn't it? — xaosflux ^Talk 23:17, 18 October 2021 (UTC)

Yes. And those blocks have been happening for quite some time now. Blablubbs (talk) 23:22, 18 October 2021 (UTC)

Yup. iCloud Private Relay is known to use three major providers for endpoints: CloudFlare, Fastly, and Akamai. CloudFlare has been widely blocked since before I picked up w:User:AntiCompositeBot/ASNBlock (which generates lists of unblocked webhost/VPN IPs) from SQLBot a year ago. Fastly and Akamai were added to the list in June, and iCloud Private Relay has been specifically targeted since August. AntiCompositeBot does not automatically implement blocks, that's left up to human admins and stewards. AntiCompositeNumber (talk) 04:14, 19 October 2021 (UTC)

Just to note (since I use iCloud Private Relay), yes it can be turned off, but only globally (for all sites) and not for Wikipedia specifically. So I don't think the fact it can be disabled entirely excuses the issue. Users turn it on because they want to use the feature. Whether they want to keep toggle-disabling it (or abandon it altogether) to contribute to a single volunteer site is, well... ProcrastinatingReader (talk) 00:01, 19 October 2021 (UTC)

I can see no reason to treat this anonymization proxy any differently from others just because it is provided by Apple. /37.247.4.194 06:51, 19 October 2021 (UTC)

Me too: simply I don't see any reason to make changes just because Apple wants ... --Bramfab (talk) 09:16, 19 October 2021 (UTC)

There are a few key differences between Private Relay and a VPN. First, VPN requires launching the app to use. Thus it took an explicit act for me to do rather than use by default, and to quit it to do certain work was not a big deal. Private Relay is integrated in the OS and buried somewhat in Preferences. It isn't easy to toggle on and off. I haven't played with toggling it off - if there are multiple ways (in Safari Preferences vs. System Preferences), if I have to restart Safari, etc. Second, users cannot be able to turn it on or off unless they have Admin privileges, unlike a VPN. Lastly, I doubt Apple gives a hoot about sites like Wiki that restrict certain mass IP addresses. The feature was introduced as a marketing draw and expansion of their message of data privacy. As it was just added in Nov 2021 to MacOS Monterey, it's difficult to estimate user base. The impact isn't on Apple, but on users who prefer Safari (and/or hate Chrome like me) and want to limit a portion of their digital footprint that cannot be opted-out of at least in the US. We're kidding ourselves if we think that Apple will be the only company to integrate IP redirection into its OS. CountryMama27 (talk) 19:30, 20 November 2021 (UTC)

I want to tack onto @GeneralNotability's objection here, this is being billed as tho it affects all safari users, it does not. Private relay requires a paid iCloud+ account. I'm not sure that this will affect nearly as many users as we think. SQL^{Query me!} 11:06, 19 October 2021 (UTC)

It sounds like the concern is Safari at least on Apple platforms are eventually going to have this on by default for everyone without payment. I wouldn't be completely surprised if they do eventually do this and while it may be crystal-bally this is a matter of policy not an article and IMO it's not so remote it's not worth considering. But I don't think this matters per my comment below. Nil Einne (talk) 12:53, 19 October 2021 (UTC)

"For Apple is an honourable company;

So are they all, all honourable companies--

Come I to speak in honesty's funeral."

-- apologies to Shakespeare - Julius Caesar Act III, scene II

Are Apple doing this to improve the security of iCloud users or to ensure that they alone hold the key pieces to accurately target advertising to Safari users? What are the odds they will follow up with a "premium" tool to effectively handle (at a price) CheckUser functions on behalf of "verified bona-fide" websites?

In any case, this isn't a matter of responding to the initial impact of Apple's decision, but of seeing the direction of progress and being ahead of the curve, not struggling to catch up later.

WMF have been working towards the masking of IP addresses. While this looked like a push forward for privacy & a sea-change for checkuser tools, it now looks like that work will need revisiting or soon becoming obsolete. The software doesn't change quickly, so the time to start planning our response is now, not to kick the problem down the road. - Cabayi (talk) 15:05, 19 October 2021 (UTC)

@Nil Einne Do you have a source for that? If apple decides to go that route, it sounds more like Apple making issues for Apple users than it does our problem. SQL^{Query me!} 13:29, 27 October 2021 (UTC)

@SQL, I've clarified that it doesn't all Safari users. Thank you for noticing this issue. SGrabarczuk (WMF) (talk) 02:26, 27 October 2021 (UTC)

@SGrabarczuk (WMF) You did a great job there. Thank you. SQL^{Query me!} 13:27, 27 October 2021 (UTC)

It's not like this is the first time we've dealt with something like this. I can't be the only person to remember when Wikipedia:en:Wikipedia:AOL made Wikipedia:AOL OpenRide available to everyone in ?2006. While AOL may have been far smaller than Apple and weren't doing it for the same reasons so ended up enabling Wikipedia:X-Forwarded-For, until they did we dealt with it the same way we should deal with Apple, Mozilla, Microsoft, Google or whoever tries this. Block their open proxies. If editors are unwilling to turn it off, so be it, they can't edit. I agree with those who've said we shouldn't give some company a pass just because they are big or popular. If we want to change the way we deal with this sort of stuff for other reasons, that's fine but it shouldn't be because some big popular company is demanding it. Nil Einne (talk) 12:53, 19 October 2021 (UTC)

They aren't demanding it. Apple probably couldn't care less. It's our own editors we're blocking (or, more accurately, their underlying IPs). ProcrastinatingReader (talk) 19:36, 19 October 2021 (UTC)

I think this is true. The big 4 don't care about things like this. As long as ppl can read Wikipedia, they'll probably not receive too many complaints themselves, we will get the complaints. Especially if we don't show ppl that they are blocked specifically because they are using iCloud Private Relay. —TheDJ (talk • contribs) 08:31, 20 October 2021 (UTC)

@ProcrastinatingReader and TheDJ: noticed a very old ping when checking something else out, and sorry I phrased that poorly. I believe when I said that, I was using the term "demanding" loosely, in the fashion of big popular company is saying "this is what we are going to do, we DGAF about your concerns, you need to adapt or lose out/die". In any case, my point was we shouldn't change our policy just because it involves a big popular company. Whether it's the big popular company demanding it, or their users, it seems fundamentally unfair that we tell other editors to fuck off but once it involves a big popular company we change how we deal with things because we couldn't dare inconvenience these users. If the situation starts to affect so many users that it becomes untenable to just leave things as is then sure. Or if the plight of these editors prompts us to re-evaluate and realise we were being dumb then we obviously shouldn't cut off our noses to spite our faces. I'd also not I'm not convinced that this is complete a big 4 issue. I mean sure any company with significant users is going to mean the issue receives more attention. But the reality is there's IMO strong evidence of an unfair bias in favour of Apple beyond the size of the user base which is IMO one reason why we have to take special care we aren't doing something we wouldn't do for anyone else. Nil Einne (talk) 00:11, 24 August 2022 (UTC)

@GeneralNotability, I've mentioned the discussion you initiated in June and the option to turn iCloud Relay off. Please take a look at the diff and see if it's accurate and clear enough. Thank you! SGrabarczuk (WMF) (talk) 02:25, 27 October 2021 (UTC)

What is the difference between this and User_talk:-revi/FAQ#opera

Per the title, what is the difference in the way we are handling this IP mask vs Opera IP mask which we have a SOP on it? Thanks. Camouflaged Mirage (talk) 08:25, 19 October 2021 (UTC)

Hello @Camouflaged Mirage. According to my knowledge, it's at least about the numbers. Opera isn't as popular or influential as Safari/Apple. As we wrote on the page: This is likely to become a non-beta feature, then default (opt-out). It may also eventually be included in the operating system for free, as a similar service for how Mail is now free. [...] Once Apple makes this change, other browser providers like Google and Mozilla may remove browser information sent with requests as well. SGrabarczuk (WMF) (talk) 13:35, 19 October 2021 (UTC)

@SGrabarczuk (WMF) Thanks for the reply, so the basis of the issue is the same, just now the scope is much larger? That's the TLDR? Camouflaged Mirage (talk) 08:28, 20 October 2021 (UTC)

@Camouflaged Mirage Yes, the scope is much larger. This is one major difference between iCloud Private Relay and Opera's VPN. Certainly this is not the TLDR for this entire page and the discussion that's taking place. Please note that I'm sharing my perspective, and I've never been a steward or a CU. SGrabarczuk (WMF) (talk) 19:20, 21 October 2021 (UTC)

@SGrabarczuk (WMF) Thanks for the reply. The issue I gather is that people don't really know how to disable this thing, so education of users how to remove might be a good idea. However, for institutions using the subscriptions, that's another issue as the disabling needs the iCloud account of the Mac / device which the students might not have access to as it's unlike Opera where the disabling is built into the browser. Hence, WikiEd etc might needs to be looked into with this in mind, as well as all our campus outreach events etc. Camouflaged Mirage (talk) 11:41, 26 October 2021 (UTC)

Private Relay isn't a simple thing to turn on and off, and as of now, it doesn't offer a whitelist option. Given the adoption thus far by iOS 15 users, I anticipate that its recent extension to MacOS Monterey (12.0) will only increase its use. I know how to disable it, but to disable it to log into one site, and then reenable it is not something that I see myself doing, despite the fact that I'm fairly techy. The point about SysAdmins not permitting it to be toggled on or off by employees/individual users is valid. As it is buried in System Preferences, most institutions that I've worked with block all Prefs access by denying Admin access to all users. CountryMama27 (talk) 19:09, 20 November 2021 (UTC)

I think IP Block Exemptions are already granted very liberally for WikiEd events. MarioGom (talk) 14:04, 26 October 2021 (UTC)

@Camouflaged Mirage, I've just updated the page and mentioned Opera. Thanks for bringing this point up. What do you think, is it clear now? SGrabarczuk (WMF) (talk) 02:08, 27 October 2021 (UTC)

@SGrabarczuk (WMF) Thank you. Much clearer now. Camouflaged Mirage (talk) 09:31, 27 October 2021 (UTC)

@SGrabarczuk (WMF): macOS Monterey has just been released, so I think So far, iCloud Relay is only available to iOS 15 users, not to desktop users. is now out of date. ProcrastinatingReader (talk) 11:06, 27 October 2021 (UTC)

Block messages

As others have pointed out above, there's not really much new here, apart from potentially some increased experience of these blocks. We've seen these blocks before with Opera, Puffin Browser, GWA, plus others, and probably already blocked most of the IPs anyway. However, others have also pointed out that the messaging to blocked users generally sucks. According to en:Wikipedia:THEYCANTHEARYOU, we don't even know if Apple's mobile editors see any block message at all (apparently they don't). When there are multiple blocks on an IP, which is certainly common on enwiki, the block message for any user is just confusing. If WMF is going to get concerned about anything here, they need to concentrate on better messaging to blocked users - especially mobile users. I also think the messaging typically used by stewards in global blocks could also be improved and some coordination there might help. -- zzuuzz ^(talk) 11:23, 19 October 2021 (UTC)

Indeed, community-wise, I think we should create a specific block template (and localized information page for global blocks) for Private Relay with a more relevant description and instructions. But it will only be effective if it can be seen by affected users... MarioGom (talk) 11:42, 19 October 2021 (UTC)

@MarioGom and Zzuuzz: the issue with global blocks is that we can't use templates, so we can't really inform people of what's going on at a glance, we need to link them to a page where they can then find more info. As usual, there's a task pending, which we hope is solved quickly considering WMF is now "scared" of this VPN. —Thanks for the fish! ^{talk•contribs} 13:30, 19 October 2021 (UTC)

I agree that this seems like an important area of improvement if we want to deal with this in any sort of way. —TheDJ (talk • contribs) 08:33, 20 October 2021 (UTC)

Just a note, that for Mobile web, as an IP user with private relay enabled, I DO see a block reason for my egress, which is apparently via Akamai. I get a full rendering of {{Colocationwebhost}}. The block log entry was: 08:52, 27 June 2021 L235 talk contribs blocked 2a02:26f0::/29 talk with an expiration time of 2 years, 60 days, 12 hours, 21 minutes and 36 seconds (account creation blocked) ({{Colocationwebhost}} <!-- Akamai -->) —TheDJ (talk • contribs) 09:10, 20 October 2021 (UTC)

It's helpful to hear that even in the app, the blocking still occurs. I'm loathe to use apps rather than websites unless they are required (my annoying ISP) or helpful (banking) or offer features not otherwise available (pharmacy). As I primarily edit using my laptop rather than my mobile device, app usage is not an option regardless. It is easy to use Safari 99% of the time, especially with the improvements in iCloud password services, and yes, I prefer Private Relay on. Why not? CountryMama27 (talk) 19:04, 20 November 2021 (UTC)

An experience from enwiki

• Are you seeing problems related to the current iCloud Private Relay global blocks on your wiki?
• Do you think that it's likely that good-faith editors will be blocked?

I tend to deal with a lot of abusive editing, and I have come across exactly one use of Private Relay in the past few months. It was the result of an abusive sockpuppeteer using it to evade a block. It's actually a huge range. I checkuser'd a sample from the range, and found it was overwhelmingly used by good-faith editors. I decided to not block any part of it. As of today, the range appears to remain completely unblocked.-- zzuuzz ^(talk) 13:05, 19 October 2021 (UTC)

A couple remarks, not necessarily directed at your experience: first, there's a mapping of IP range to geographic area here, but as far as I'm aware these are not actually announced as their own prefixes, so it isn't immediately obvious that you can block a particular sub-range. Second, as I understand it, there's an option to pick between city-level egress and country + timezone-level egress, so I don't think blocking at the city level would be effective. Third, the ranges in question are (if memory serves) all owned by CDNs. It is unclear to me whether these ranges exclusively belong to Apple Private Relay, or can be used by similar CDN-based IP-hiding services (like Cloudflare WARP). SubjectiveNotability (talk) 13:35, 19 October 2021 (UTC)

Apple are asking geoip databases to reflect the locations in their databases for those IP addresses (based on the list Apple provides) and even asking them to mark them as belonging to Apple. But at least recently, these IP addresses definitely were not exclusive Not sure if that was the intent and either Apple or Cloudflare messed up. —TheDJ (talk • contribs) 08:58, 20 October 2021 (UTC)

Good point. If we confirm that the ranges listed at https://mask-api.icloud.com/egress-ip-ranges.csv are not exclusive to Private Relay, then we cannot create block templates specific to Private Relay, and will need to rely on en:Template:CDNblock (or equivalent information page on Meta) to have further instructions for Private Relay users, CloudFlare WARP users, etc. MarioGom (talk) 10:40, 20 October 2021 (UTC)

Actions

I see a few community actions we should take to prepare for Private Relay (admittedly, speaking mostly for enwiki):

• Fix the multi-block template to actually display correctly.
• Reblock the Private Relay endpoints with a more specific message that says "you're blocked because you're using Private Relay, here's how to turn it off" (we have w:en:CDNBlock, just need to tweak it a bit)
• Do some more discussion on IPBE - should we be more willing to grant it?

SubjectiveNotability (talk) 13:39, 19 October 2021 (UTC)

Thank you being in this conversation, and some context

Hi everyone -- I'm Marshall Miller; I'm a product manager at the WMF. I mostly work on Growth features for new editors, and I'm one of the WMF staff who will be replying in this conversation, along with @DannyH (WMF) and @SGrabarczuk (WMF) (and maybe a few others). Thank you all for joining in. We created this page and started the conversation because we're worried about how a trend of changes in the internet could both (a) make it difficult to counter abuse and, (b) make it difficult for users to edit. I'm sorry if it initially came across as overly alarmist; we don't mean to inflate the impact of iCloud Relay, but we do have genuine concern and feel urgency around preventing abuse without excluding good-faith contributors.

These issues are certainly complicated, and we definitely have a lot to learn from the people who are dealing with blocking and IP issues on a day-to-day basis. We don't have a plan yet for how to adapt to these changes, and we know that any successful plan will require us all working together, so we're eager to hear your clarifications and opinions.

• First, I think we should make sure we've got the right facts. I apologize that our project page misses nuances of how IP addresses function in our projects -- our goal was to try to summarize succinctly and help get the right people in the conversation. As we learn more of the details from you, we'll update the project page so that it becomes more accurate. That way, our project page can be our ongoing shared understanding of the situation.
• Next, we'll want to talk about potential options for how to address changes resulting from iCloud Relay over the coming months. I definitely want to underscore that we don't already have a solution in mind here -- this is a genuinely tough problem that we need to talk about together to solve so that we can maintain security while keeping the wikis open for good faith contributors. It may be that we end up with changes that the WMF can implement, or that volunteers can implement, to improve things for people affected by iCloud Relay.
• Then, perhaps we'll continue the conversation to think about the larger shifts in the internet, and how we might adapt our projects to a future where IP addresses become less and less useful.

I expect that this conversation may go on for some days or weeks, since there is a lot to sort out and lots of people to include. On our end, there are many WMF staff who have knowledge around these issues, but to keep this conversation a little bit more organized, only a few of us will be replying. Therefore, it might sometimes take us a day or two to find accurate answers to your questions and reply.

First, we're going to be responding to / clarifying the comments you've already made on this talk page, and figuring out what we should update about the project page. Please do keep the thoughts coming! And if there are other volunteers who you think should have eyes on this conversation, please feel free to ping them and bring them in.

Thank you for working with us on this! Do you have any questions about what we're trying to achieve here? Or ideas for how to go about it differently? MMiller (WMF) (talk) 20:42, 19 October 2021 (UTC)

Wikimedia's anti-abuse tools are nearly bankrupt from technical debt. If I told you it would take at least one week of work to add a checkbox to the delete form that deletes the accompanying talk page, you probably would laugh at me. Guess what? It's true. Who knows how many more horror stories like this there are in the codebase? The WMF needs to start spending $10 million+ per year (because that is what it would take) on anti-abuse tools now so that we are ready for this with shiny, state of the art tools in several years time. MER-C 18:25, 20 October 2021 (UTC)

Hi MER-C: The specific task that you're talking about is one of the top wishes on the Community Wishlist Survey, and the Community Tech team is going to work on it: here's the project page. It's not surprising that a software change takes a week of work to produce, even if it seems like a small change; our software teams work in two-week sprints, and changes need to be code-reviewed and go through QA testing.

But I agree that there's a lot of work that needs to be done on the anti-abuse tools, and that's part of what we want to talk about here. Are there other tools that you think are particularly important to help with this iCloud Relay concern? — DannyH (WMF) (talk) 19:08, 20 October 2021 (UTC)

I'm referring to the complexity of the task - this is something that isn't hard: adding a checkbox, an if statement to check whether the checkbox was checked and a short function to delete both the original page and the talk page (if it is in a content namespace and the talk page exists). No more than 100 lines of code and easy to test. Instead, the developer has to spend a week or more refactoring. Then there's the issue that this is sufficiently obvious functionality that should have been implemented when deletion was implemented and not as a result of some popularity contest that is ill-suited to this type of work over fifteen years later.

It is likely that we will have to replace IPs with a combination of things. We cannot build for the future on a foundation of sand, and that is exactly what we have.

en.wp will end up treating this like every other VPN - by blocking it. Pity that the mobile users can't really tell that's the reason they're blocked. MER-C 20:11, 20 October 2021 (UTC)

Apparently the iOS app does not use Private Relay, see phab:T289795, so the lack of custom block templates in the iOS app shouldn't affect this particular case. MarioGom (talk) 07:56, 21 October 2021 (UTC)

Short and long term issues

In 2021, 2022 and perhaps 2023 it might be okay to bounce back attempts to edit WMF content via private Safari etc.

• The precise situation could be detected, which would need global maintenance of a new ranges list of involved public private anonymizers.
• Users should be informed on attempt, that their current networking environment does not permit WMF editing.
• At least existing messages need to mention explicitly Safari et al., since users are not aware of the cause, and they even cannot ask their village pump.
• They need to get advice, temporarily leaving private mode.

In the long run WMF will need to discontinue IP based user identification.

• It is a legitimated way to keep privacy against bad governments, data swallowing global companies and other threats of unauthorized surveillance around the clock.
• The global players identify people by browser fingerprints, IP address and collect and analyze all personal search engine queries, profiling for best advertising and more profit. Their businesss partners are refusing to rent flats or cars, or contracting insurances or bank account if they do not like the scoring and behaviour of internet users.
• Political players are utilizing collected data for influencing citizens. This happens not only by dictatorship and endangered democracies, but even in trusted states. We have seen microtargeting campaigns in US and UK, affecting results of polls and elections, and recently Austrian government used taxpayer money to launch faked opinion polls suggesting that the people is loving the prime minister. We cannot rely on benevolent governments.
• A new culture will be heading for anonymized www inhabitants with privacy protection rather than a number plate on everybody’s backside.
• It is not the best approach to run all your traffic via a major global company for privacy protection, but other services may arise.
• For a movement based upon freedom of information and human rights an approach requiring privacy violation cannot be maintained for the next decades. I predict the classic procedures will be terminated around 2030. Start pondering on alternatives now.
• Communities in repressive environment will need protected communication.

The concept of IP and user agent identification used by Wiki world is based in the beginning of the century.

• At that time there has been a limited number of desktop devices.
• You had to go to office, to your company, to university for an internet connection.
• Therefore it has been quite easy to guess that a person using the same IP address of a company or school and the same browser version is the identical human being.
• Nowadays people have a desktop at home, a cellular phone with one provider and a tablet with a different provider, and a network for business. Members of the family have other cellular phones with other providers.
• It is no longer a big deal to use a separated device for sockpuppetry or paid editing if you are a bit smart.
• Check users will catch the stupid ones only.
• IP geolocation told by the provider may be the last indicator, telling that two user accounts both are editing in New York City via a major mobile provider. However, private VPN tunneling might make a paid editor showing up virtually in a city far away.

Greetings --PerfektesChaos (talk) 20:51, 20 October 2021 (UTC)

Your first three bullet points are already done. Although the block messages can still improve with specific instructions. I think there is consensus here to add specific guidance to block templates (on English Wikipedia) and information pages (on Meta).

On data swallowing global companies, routing all your traffic through Apple, a big US corporation with one of the leading ad targeting platforms, is not really keeping your data safe from ad tech, and it is not particularly a good idea against Government surveillance either. MarioGom (talk) 08:01, 21 October 2021 (UTC)

I don't think PerfektesChaos was talking about Private Relay with that point, but specifically about all forms of editing with IP as the identification instead of a user account. —TheDJ (talk • contribs) 13:26, 21 October 2021 (UTC)

Thank you PerfektesChaos. I like the reference to our movement’s commitment. “We believe that you shouldn’t have to provide personal information to participate in the free knowledge movement” [3] is in the footer of this (and every other) page. MBq (talk) 19:54, 21 October 2021 (UTC)

IP address is currently the least worst option we have. To not use IP addresses in the way we do now (blocks to combat abuse and sockpuppetry detection), we would have to require account creation and collect some other sort of identifier, like an email address. That's worse for privacy, in my view. If you've got any better ideas, feel free to share them. AntiCompositeNumber (talk) 20:12, 21 October 2021 (UTC)

I'm worried too. There's no easy answer to your question. But if we are no longer able to identify people by their ip adress - because the internet has moved on - we will have to rely on innovation. For example, dewiki mitigates local vandalism by hiding unreviewed changes. Edit filtering helps a lot to keep our LTAs at bay. We could adopt the required login. We could pour new WMF money into old research, boost some software development. ...And I'd even give AI a try. --MBq (talk) 07:07, 22 October 2021 (UTC)

Some comments:

• There is Mozilla VPN now offered for 5 Euro/month.
• I do expect that in next years there might be a donation funded non-commercial citizen anonymizer, run by a trusted NGO, physically served off U.S. authorities range, open source, trusted users board.
  • Not as sophisticated as TOR, not with three levels protecting more or less against NSA, but one level which is sufficient to obfuscate commercial tracking.
  • Reducing technically redundant user agent details to major revisions really needed, and swallowing blacklisted cookies and perhaps some beacons get fried.
  • You may choose, even per retrieval, your country. All access from the same country might be located at address of PM or president. Or, since shopping, travel offers and credit rates get calculated from the environment of your current position, tell that US users swim in the middle of Salt Lake, Utah. Perhaps cheaper scoring there than in neighbourhood of the government.
• @ “routing all your traffic through Apple,” … “is not really keeping your data safe from ad tech”
  • I commented in my first statement already: “It is not the best approach to run all your traffic via a major global company for privacy protection”
  • To order anonymization by Google is not a big progress.
• Safe sockpuppetry is very easy today.
  • Just use the mobile devices of people sharing your flat.
  • At best a different ISP, almost different agent, no cookies, definitely not the same as your regular working environment.
  • Only stupid and lazy users will be caught who just log out and continue in the same environment.
  • Sockpuppetry chasing relying on IP and user agent is pointless today. It is based on internet connections available in last century. Forget about that.
• Sockpuppetry detection is heading for finding that two registered contributions are probably originated by the identical person.
  • Registered users cannot be recognized as identical without CU, and only if the user is a fool.

Greetings --PerfektesChaos (talk) 20:13, 31 October 2021 (UTC)

Having used Apple's service since it appeared in the first beta, I'd like to note that in my experience, the process of switching it on or off has been less than stellar: there are at least three different places where it can be controller: in the Safari privacy preferences, in the network settings in System Preferences, and iCloud settings (also in System Preferences). As far as I can tell, these are three independent switches that all need to be set to "on" to turn it on for Safari. It also had a tendency to reactivate after every update. Point being: I could see this being enough of a hassle for people to give up in frustration.

I find the process and result of an estimated 3 % of editors being affected by this to be highly plausible, and I would caution against considering 3 % to be a minor loss. On iOS, it is also not possible to avoid the issue by switching to a different browser, since Safari is the only browser on iOS (the firefox and Chrome apps are just different frontends, with Safari underneath). Users of corporate hardware (Mac and iOS) may also not have the administrator privileges to control the feature and override their IT department's choice. With privacy seemingly working out quite well as a marketing strategy for Apple, it is only a matter of time before others follow. Indeed, Chrome is already using proxies to protect users' privacy in the context of prefetching content. Indeed, every second or third article in their blog seems to be on privacy, and the overwhelming majority are specifically on disclosure of user-identifying information to websites. This, from January is among the more salient ones. Taken together, I do not believe that the the rather definitive declarations that IP data correlated with user identities is a strict requirement will remain as luxuriously possible to make. I'd give it about even odds that > 50 % of users will typically use such a setup five years from now. As such, I'd be interested to hear more about the dynamics of the system as it works now from people more familiar with it. For example, I'm not exactly sure why these bans have to apply for logged-in users? In the second blog post linked, above, there is also discussion of several mechanisms Google is implementing to cushion the impact of such changes. Most are aimed at ad tracking, obviously, but there's something about "trust tokens" in there. And that sounds exactly like what I would expect for a mechanism helping with this problem. Even if it isn't, they might be quite willing to listen, if it gives them a benevolent non-adtech site like WP as a reference for these efforts. They are also scrambling to mitigate "inauthentic political messaging" across their platforms and the web. And son a technical level, that is exactly the same as sock-puppetry. Indeed it is frequently one-and-the-same on every level. As a final note, I want to mention that, not being familiar with any of the people writing here nor the social dynamics that are involved, I am having a hard time matching some of the accusations being made against what I gather to be Foundation employees to their actions. This isn't to say that these accusations lack merit: there definitely are scenarios of prior history that might warrant to bring out the big guns here. But even it that is case, one should be conscious of the fact that the level of antagonism is not proportional to the misdeeds allegedly committed here. The discussion of IP blocks vs. account blocks that dominates the first third of the page may be technically illuminating, for example, but I'm having trouble seeing any impact on the issue. And while I completely get where such emotions may come from, they are unlikely to get better effects with repeated administration. It also raises the question if those prior events involved the same set of people now reaping the consequences and, if not, if there isn't some way to magnanimously free new hires from the burden of baggage acquired before their times. --Karl Oblique (talk) 22:23, 18 November 2021 (UTC)

I can see the need in the past to block certain IP addresses. I recall reading about deliberate graffiti attempts coming from isolated IP addresses, and the point about certain governments acting to control information is valid. However, given that VPNs are available for free, isn't it likely that if a particular user or regime is interested in subverting content for their own purposes, they would easily use a VPN or other service to misdirect their IP address? Also since IP address is not reflective of an individual, does it make sense to continue to use? We recently traveled to a city that has free wifi hotspots everywhere. What meaning then is the IP address? What if more free wifi providers decide to redirect IP addresses for privacy?

It bothered me when I was blocked for using iCloud Private Relay while logged in to my account. I didn't however mind entering a captcha when updating this page. I've had my account for as long as I can remember, and enjoy fixing and updating pages where appropriate. I fail to see how restricting users who use OS-integrated IP redirection is aligned with the objectives of Wikipedia. I also find it hard to believe that IP relay is a small and manageable trend. When over 90% of iOS 14.5 users chose to opt-out of allowing apps to track them within 3 weeks of its release, and huge companies like FB had their quarterly ad revenue significantly affected by a minor iOS release, I take notice. Perhaps some people see Apple's privacy tools as a chance for Apple to own the data itself. Those people are welcome to run their own traffic through VPN, or to use other browsers. I see privacy tools as a marketing draw that has thus far shown to be highly attractive. For this discussion, it matters little as to WHY a company provides this service, but rather HOW users see its benefits for themselves. Even if the service is a siphon of data for Apple, choosing to turn it on doesn't increase Apple's data, but like app-tracking, it at least provides an improvement in privacy, however modest.

It's time for Wiki's Foundation to recognize that IP address tracking is soon to be an outdated trend, one that they should get ahead of and embrace, rather than fight the tide. As a side note, I had to use Chrome to write this. I dislike Chrome. I trust Google less than I trust Apple, and I know from experience that Chrome is exceptionally "leaky." Thanks CountryMama27 (talk) 18:57, 20 November 2021 (UTC)

"It bothered me when I was blocked for using iCloud Private Relay while logged in to my account."

Yeah, me too. What's the point in this? Gymate (talk) 19:56, 7 February 2024 (UTC)

Size/duration of blocks

Q: is there a way to measure the overall size and duration of ip blocks in our major project? Like, percentage of complete ipv4 adress space, or of the biggest providers' space? Are we shutting out a substantial part of the population right now, or will this be more of a future problem? MBq (talk) 06:54, 3 November 2021 (UTC)

MBq, is this really related to Private Relay? More generally - it's hard to map number of IP blocks to number of people affected; some ISPs put a hundred customers behind one IP, while IPs that belong to, say, a hosting provider will probably never be used to edit. (and, of course, we must remember not to count the big chunks of IP space that cannot possibly edit, like everything above 224.0.0.0) GeneralNotability (talk) 20:49, 3 November 2021 (UTC)

And that's just IPv4... AntiCompositeNumber (talk) 21:12, 3 November 2021 (UTC)

As GeneralNotability said, number of IPv4 addresses means almost nothing, but to avoid leaving the question unanswered, Private Relay currently consists of 91,638 individual IPv4 addresses, which is 0,002134% of the total IPv4 space (someone might want to calculate the percentage of the public IPv4 space). This is a relatively low number for a proxy block, in terms of individual IPv4 addresses. Some blocked colocation providers like M247 might have even an order of magnitude more individual IPv4 addresses blocked. MarioGom (talk) 16:46, 5 November 2021 (UTC)

The question's mention of "duration" suggests there may be a misunderstanding: it's policy and practice to ban any known "open" (including paid) proxies a.k.a. consumer VPNs. It is not done in response to specific incidences. As such, users will tend to encounter this not in the form of transitory episodes of being blocked, but essentially permanent blocks of the specific connection they are using. Karl Oblique (talk) 21:13, 18 November 2021 (UTC)

Yes, you're right. Block duration varies depending on a number of factors. Proxies that are likely on dynamic IPs may get a few days block, while proxies on datacenters may get 1 or 2 year blocks. These are renewed when they expire if they are still proxies, so they are effectively indefinite as long as the IP is still a proxy. MarioGom (talk) 10:15, 19 November 2021 (UTC)

Some input from Apple

I came across this document from Apple that speaks to a few of the issues. Most interesting may be their point that every user of Private Relay is a customers of theirs in good standing and with a credit card on file, i. e. a self-selected group that may be lower risk than the seedy underbelly of the web that is TOR, for example. They also seem to say that a user's IP is static for some duration. It's not quite clear what timeframe this means, but at the very least it is not possible to jump across hundreds of proxies in dozens of countries within minutes, as is common with VPNs.

I believe this block is a significant change that doesn't feel like it because it is the result of outside decisions. Blocking some single-digit percentage of editors would never happen without even informing them adequately if it didn't happen to be the 'default' here, but that sequence of events makes no difference to those affected. At the very least, the block should be lifted temporarily/regionally/randomly to measure if it makes a measurable difference. Karl Oblique (talk) 14:23, 10 April 2022 (UTC)

@Karl Oblique The problem is that we can't distinguish iCloud Private Relay customers from other users of CloudFlare, Akamai, and other services. It's all well and good that Apple has taken a modicum of anti-abuse measures, but that can't be said for the products and services provided by the underlying service providers. No editors are being blocked here, only internet connections. AntiCompositeNumber (talk) 03:07, 11 April 2022 (UTC)

I'll also note for the record that AOL of the past and T-Mobile of the present have had orders of magnitude more impact than iCloud Private Relay. AntiCompositeNumber (talk) 03:09, 11 April 2022 (UTC)

@AntiCompositeNumber: The problem is that we can't distinguish iCloud Private Relay customers from other users of CloudFlare, Akamai, and other services that's not true though, is it? Cloudlare has made a commitment that exit IPs (vended to Apple) would be for exclusive use by iCloud Private Relay customers and no one else Cloudflare relays maintain a pool of IP addresses for exclusive use by Private Relay.. That guarantee coupled with Apple's policy on provable yet stringent identity attribution (via "blind signatures" and pre-provisioned "security keys") makes it easier to trust the exit IPs than usual, I'd think.

Addn: A list of iCloud Private Relay IPs Murtaza.aliakbar (talk) 18:28, 15 April 2022 (UTC)

@Murtaza.aliakbar The problem is that those IPs are inside the larger ranges allocated to and used by the service providers. We don't have the technical ability to easily exempt certain parts of a range from a rangeblock. AntiCompositeNumber (talk) 03:06, 16 April 2022 (UTC)

The only kind of collaboration I can see working from CloudFlare and Apple is if they allowed us to send them vandalism reports, and they took steps to notify the relevant users about the abuse. MarioGom (talk) 18:27, 21 April 2022 (UTC)

@AntiCompositeNumber So it would be possible but it needs further development (of the Special:Blockip system)? It would be really useful as currently there is no option on iOS or macOS to permanently turn off Private Relay on a domain. So I have to bump into the IP block, open the Safari menu and reload the site without Private Relay each time I want to make an edit to a page, which is quite frustrating. (I know, Apple could also make it easier to disable Private Relay, but we can't do much about that...) Gymate (talk) 12:19, 10 January 2024 (UTC)

The problem AntiCompositeNumber is describing seems like phab:T42439. Johannnes89 (talk) 13:08, 10 January 2024 (UTC)

Thanks! Gymate (talk) 19:54, 7 February 2024 (UTC)

One way to prevent blocks

I changed the Safari privacy setting [Safari > Preferences > Privacy > Hide IP address] from “From Trackers and Websites” to “From Trackers Only” and (thus far) I am no longer blocked. (HT to Izno for helping me understand the issue - in response to my post on Wikipedia/Village pump). Mark D Worthen PsyD (talk) [he/him] 07:49, 4 May 2022 (UTC)

My duck go address is changed

I have to use the identification pictures and I still can’t get into my account 2601:180:200:1148:5149:E4B5:6A8E:8197 05:25, 23 September 2022 (UTC)

Why is it ok to exclude 3% of legitimate users?

At present, Private Relay wiki editors remain excluded - I’m excluded for another 7 months.

I have carefully read the explanations. They amount to either a statement that it is not technically possible to validate the specific (and known) relevant IPs or that the users behind the IPs can’t be validated by wiki.

I know for a fact - we all do - that the technical knowhow to run Wikipedia requires skills that make fixing this a trivial and almost cost-free implementation.

So, what’s really going on please? Coolcmsc (talk) 20:38, 31 July 2023 (UTC)

Here is the policy information you can read about this. You are not being excluded, simply the proxy server that you are buying is, you should be free to stop using a third party proxy server at any time and contribute here. — xaosflux ^Talk 21:28, 31 July 2023 (UTC)

This technological approach is becoming very unfunny indeed. Now that Apple Private Relay is switched on by default in MacOS Ventura's startup, more and more Apple-based editors will get a block message that "There are multiple blocks against your account and/or IP address." Very few new editors are going to make their way around that block. At a minimum, there should be a customized warning encouraging editors to switch off their private relay while editing. Fiachra10003 (talk) 12:42, 21 September 2023 (UTC)

FYI: Chrome to implement similar open proxy

Here's some links. — Frostly (talk) 03:18, 18 September 2023 (UTC)

More recent statistics?

No idea if WMF is still even remotely interested in this topic, and I'll share my abysmal daily experience as an editor at a later time in a separate section, but can we get some more recent statistics?

It's been almost 2.5 years since iCloud Private Relay has been launched in an opt-out capacity. By now WMF should be able to collate more recent and relevant statistics that can help with the debate. We can move from hypotheticals, guesswork, and reasonable assumptions to some hard facts that can help form arguments from all POVs and that can be used to update the article.

That information is essential to have a debate here on meta, but also individual wikis, with the scope ranging from just ICPR, to the role of IP-based moderating, to even something as big as WMF's general goals and policies in terms of being accessible and inclusive.

So if @SGrabarczuk (WMF) or any other WMF staff could get us updated numbers, that would be great. ConcurrentState (talk) 07:04, 2 March 2024 (UTC)