I am operating under the model Apple sets for Private Relay. In it, Attester <> Origin, Issuer <> Client, Origin <> Client unlinkability (I am assuming, and correct me if I am wrong, that “Origin” is entry in our case, Obscura’s data plane; “Attester” & “Issuer” both are Obscura’s control plane) is cryptographically guaranteed by enrollment facilitated via Privacy Pass.
In Obscura’s case, additionally the exit (run by Mullvad) here has a static identity for the client (the WireGuard public key). In Private Relay’s case, from what I can tell, there’s no such static identity, no client identifier that’s visible to exit, and in fact there’s 2 different exit providers in Cloudflare and Fastly (which lines up with recommendation made in Privacy Pass Architecture).
And so, imo, from the Client’s perspective, the 2 hop MPR Obscura implements is no different than multi-hop VPN, which hides Client IP from the 2nd hop and … that’s about it.
Well you could say, the Obscura data plane won’t collude with the Obscura control plane (both server side) and that Mullvad won’t exploit the fact that it has a static identifier on the client and that’s… imo, “trust me bro”.
All of that said, it could be that I am grossly mistaken. Now that Cure53 has audited the Obscura MPR protocol (and you had even hired someone to help with Privacy Pass?), I was hoping to stand corrected, but unfortunately, the audit report did no go much into the details about it (which is okay!).