4 ms·

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

olliej 4y 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 4y 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 4y 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?

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 4y 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 4y 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?