Apple does tell you how to block this stuff if that’s your concern. Having highly opinionated defaults is required for “it just works” which millions of users really do want, but those same defaults will always annoy someone.

Circumventing a system firewall is not an opinionated default. By default, the firewall isn't enabled. Nothing requires the traffic to leak here, it just doesn't need to behave this way. This makes nothing simpler. And, this is undocumented behavior. Don't buy into the argument that this makes some UX better. It doesn't.

By default this feature is also disabled.

What happens when multiple features in conflict are both turned on is a classic UI problem. Quietly doing a compromise between them is the exact kind of opinionated default that I am talking about.

As a user you have made the choice to both enable private relay, and enable a VPN. Now PR isn't itself a VPN as such, but clearly there's some level of potential conflict in making such a decision. If you don't want Private Relay interfering with network traffic routing, pretty much it's job as advertised, for goodness sake just switch it off and the whole problem goes away.

There are exactly 0 reason why the private relay couldn't be routed within the VPN or vice versa. There's exactly 0 reasons to make the private relay traffic circumvent the firewall.

>There are exactly 0 reason why the private relay couldn't be routed within the VPN or vice versa.

You don't know that for sure, unless you know exactly how the Apple side of PR works, there could well be circumstances where that would cause problems. At the scale Apple operates at they must come across all sorts of weird an unusual configuration combinations.

There are 0 reasons for enabling private relay and also configuring a VPN, yet that's what the user did. In any case this is documented and Apple provides instructions how to block it.

The issue here is thinking that the VPN subsystem and firewall subsystem and how they work are the product from Apple's point of view. They're not, they're just implementation details. For Apple the intended high level user experience is the product, in this case the UX of the private relay service. If they need to bypass some subsystem to achieve a better more consistent high level user experience then that's what they will do.

I agree with this take 110%

As an aside, I’d also like to subscribe to “No as a service”.

Dude, literally the article says: data gets sent to private relay if you have it enabled. You can stop it from being sent by not turning it on.

What is apple meant to do? Just not provide the service at all?

Because private relay is vastly superior to a VPN for web content, which is what matters to most users?

The problem is that it's proof that PF firewall can't block all traffic. This essentially means one cannot trust PF to protect themselves from leaking traffic.

It seems entirely plausible that this is a simple implementation bug.

PF is not the thing that does actual networking, on any OS.

As far as I understand networking and firewalls like PF, you essentially have the lowest level, where the kernel/driver puts bytes onto the channel.

Then you have the various userspace networking interfaces for various transport mechanisms, TCP, UDP, QUIC, etc

Each one of those is doing

    <transport protocol specific thing>
    <send the bytes>

The <send the bytes> part is below where your firewall stuff is going to happen, so I'm going to guess (I have never written kernel level networking because that stuff seems like relentless misery) that it means that every transport implementation has to independently have some code that looks like

    packet_data = <build the packet>
    if (auto firewall = current_firewall()) {
        if (firewall->should_block(packet_data))
            return E_BLOCKED; // or whatever
    }
    kernel_send_the_bytes_yo(packet_data);

Or something like that, all super super pseudo code of course.

Anyway, if that general concept is vaguely accurate then that means every time someone brings up a new transport protocol that another opportunity for this to get missed. Not saying its good that such a thing is possible, or that not catching it is ideal, just saying it seems like a plausible path to this kind of bug happening - Hell, I'm not even sure it would be the first case of an OS missing PF, I have some vague recollection from the distant past?

>A computer does what its owner whats it to do.

If you've enabled Private Relay then it's doing exactly that.