4 ms·

That sounds like treacherous computing. And I've argued before, that this smells like a rental with the name of a "sale". A computer does what its owner whats

That sounds like treacherous computing. And I've argued before, that this smells like a rental with the name of a "sale". A computer does what its owner whats it to do. And when Apple or another company is directing its actions, tells me that what I have is a rental. Either relinquish control, or put it on the market with the real name. It's not a sale.

hn_version_0023 5y ago
I agree with this take 110% As an aside, I’d also like to subscribe to “No as a service”.
- olliej 5y ago
  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?
  - eptcyka 5y ago
    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.
    - olliej 5y ago
      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?
Retric 5y ago
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.
- eptcyka 5y ago
  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.
  - Retric 5y ago
    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.
simonh 5y ago
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.
- eptcyka 5y ago
  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.
  - deleted 5y ago
    [deleted]
  - simonh 5y ago
    >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.
dkonofalski 5y ago
>A computer does what its owner whats it to do. If you've enabled Private Relay then it's doing exactly that.

hn_version_0023 5y ago

I agree with this take 110% As an aside, I’d also like to subscribe to “No as a service”.

olliej 5y ago
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?
- eptcyka 5y ago
  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.
  - olliej 5y ago
    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?

Retric 5y ago

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.

eptcyka 5y ago
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.
- Retric 5y ago
  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.

simonh 5y ago

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.

eptcyka 5y ago
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.
- deleted 5y ago
  [deleted]
- simonh 5y ago
  >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.

dkonofalski 5y ago

>A computer does what its owner whats it to do. If you've enabled Private Relay then it's doing exactly that.