4 ms·

This seems similar to Cloudflare + Apple partnership on Private Relay [0]; except the traffic first goes through Cloudflare before exiting via Apple / Akamai se

This seems similar to Cloudflare + Apple partnership on Private Relay [0]; except the traffic first goes through Cloudflare before exiting via Apple / Akamai servers; whereas in Chrome's case, the first hop is Google themselves. Apart from the all the QUIC vpn / proxy work Cloudflare et al (standardising Private Relay) are involved in [1][2], the OHAI working group [3] is closing in on its reviews too. Interestingly, there is an active IETF draft for how such private proxies could be built: https://datatracker.ietf.org/doc/draft-iab-privacy-partitioning/ https://datatracker.ietf.org/doc/draft-iab-privacy-partition... [0] https://blog.cloudflare.com/icloud-private-relay/ https://blog.cloudflare.com/icloud-private-relay/ [1] https://datatracker.ietf.org/wg/masque/documents/ https://datatracker.ietf.org/wg/masque/documents/ [2] https://datatracker.ietf.org/wg/privacypass/documents/ https://datatracker.ietf.org/wg/privacypass/documents/ [3] https://datatracker.ietf.org/wg/ohai/documents/ https://datatracker.ietf.org/wg/ohai/documents/

lxgr 3y ago
OHAI seems to be related to Oblivious HTTP. To be honest, I still don't understand the use case for that when there's already MASQUE, which seems like a more flexible and elegant solution to the same or at least a very similar problem. Do you know what OHAI does in detail and what its advantages over MASQUE would be?
- ignoramous 3y ago
  I might be wrong, but OHAI is an additional HPKE layer within the TLS protected HTTP tunnel; a more nauced take on the HTTP CONNECT method, if you will. MASQUE seems more of IPsec take 2. See section 3.1 for a brief comparison between the two: https://datatracker.ietf.org/doc/html/draft-schinazi-masque-proxy-01#name-ohttp https://datatracker.ietf.org/doc/html/draft-schinazi-masque-...
  - lxgr 3y ago
    Ah, so basically the distinction is private relaying at the HTTP exchange level vs. at the TLS flow level? MASQUE is more about tunneling TLS flows (i.e. TCP or TCP-ish connections such as QUIC/HTTP 3) than about the IP layer, is my understanding, but I suppose that's what you mean by IPsec take 2?
    - ignoramous 3y ago
      > MASQUE is more about tunneling TLS flows than about the IP layer, is my understanding, but I suppose that's what you mean by IPsec take 2? MASQUE has now evolved to the point one can potentially build VPNs with it: https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/ https://datatracker.ietf.org/doc/draft-ietf-masque-connect-i... see also apnic's post on ohttp & masque: https://blog.apnic.net/2023/03/23/hiding-behind-masques/ https://blog.apnic.net/2023/03/23/hiding-behind-masques/
      - lxgr 3y ago
        > MASQUE has now evolved to the point one can potentially build VPNs with it Wow, so we've gone full circle :D Hopefully this will only be used using the QUIC Datagram – IP-over-TCP isn't fun. But I can see it making sense in certain scenarios/as a last resort. I'm aware of the great apnic post, but it seems to predate OHAI. Hopefully somebody will write an explainer on that as well.
ignoramous 3y ago
> except the traffic first goes through Cloudflare before exiting via Apple / Akamai servers Correction: The traffic in fact is proxied via Apple-administered servers onto Cloudflare as exit.

lxgr 3y ago

OHAI seems to be related to Oblivious HTTP. To be honest, I still don't understand the use case for that when there's already MASQUE, which seems like a more flexible and elegant solution to the same or at least a very similar problem. Do you know what OHAI does in detail and what its advantages over MASQUE would be?

ignoramous 3y ago
I might be wrong, but OHAI is an additional HPKE layer within the TLS protected HTTP tunnel; a more nauced take on the HTTP CONNECT method, if you will. MASQUE seems more of IPsec take 2. See section 3.1 for a brief comparison between the two: https://datatracker.ietf.org/doc/html/draft-schinazi-masque-proxy-01#name-ohttp https://datatracker.ietf.org/doc/html/draft-schinazi-masque-...
- lxgr 3y ago
  Ah, so basically the distinction is private relaying at the HTTP exchange level vs. at the TLS flow level? MASQUE is more about tunneling TLS flows (i.e. TCP or TCP-ish connections such as QUIC/HTTP 3) than about the IP layer, is my understanding, but I suppose that's what you mean by IPsec take 2?
  - ignoramous 3y ago
    > MASQUE is more about tunneling TLS flows than about the IP layer, is my understanding, but I suppose that's what you mean by IPsec take 2? MASQUE has now evolved to the point one can potentially build VPNs with it: https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/ https://datatracker.ietf.org/doc/draft-ietf-masque-connect-i... see also apnic's post on ohttp & masque: https://blog.apnic.net/2023/03/23/hiding-behind-masques/ https://blog.apnic.net/2023/03/23/hiding-behind-masques/
    - lxgr 3y ago
      > MASQUE has now evolved to the point one can potentially build VPNs with it Wow, so we've gone full circle :D Hopefully this will only be used using the QUIC Datagram – IP-over-TCP isn't fun. But I can see it making sense in certain scenarios/as a last resort. I'm aware of the great apnic post, but it seems to predate OHAI. Hopefully somebody will write an explainer on that as well.

ignoramous 3y ago

> except the traffic first goes through Cloudflare before exiting via Apple / Akamai servers Correction: The traffic in fact is proxied via Apple-administered servers onto Cloudflare as exit.