I’m genuinely not understanding, can you describe the specific scenario / play-by-play for me?
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!).
I think Akamai too unless something has recently changed.
Per this research (which is critical of Private Relay!), Akamai is the entry node for ~30% of the IP space but 50%+ traffic, apparently (Apple doesn’t disclose this). In fact, I think Akamai operating the 1st hop is even better for Attester <> Origin unlinkability?
Anyways, to me, it seems like Obscura is some ways from that, despite inviting comparisons.
1 Like
Glad to hear it 
BTW, we did recently publish our audit with Cure53 which indepdently verified our claims: Obscura’s First Independent Audit by Cure53
I’m obviously biased, but I think that eliminating the need to trust a single party for your privacy is a substantial win, and we take great care to make sure that the browsing experience is still smooth (I run all my video calls through Obscura and stream 4K HDR through it).
2 Likes
What is the OS you’re using here?
Because unless it’s Linux and you’re streaming down some Netflix, I am not sure how it might be relevant.
Yet I am curious and excited to know. 
(mods feel free to move this convo if it does not belong here)
I’m using macOS with Obscura.
Now sure why OS would significantly impact speed? Are you talking about kernel differences in the TCP/IP stack?
In any case, we’re doing internal testing on our Linux CLI alpha now 
Sorry for the confusion but I was wondering how
stream 4K HDR through it
was relevant here.
I know that streaming services like Netflix would bottleneck movies/shows if watched from “an unusual device” like a FOSS DIY TV box will only allow for 720p. Does Obscura allow to bypass that kind of restriction?
Last time I checked it was mostly a hardware DRM issue.
Anyway, not sure if I’m getting it right here overall (I’m probably the confused one here, sorry ahead of time). 
Oh I was just saying that to indicate that the overhead from our Two-Party Relay’s improved privacy is minimal and doesn’t noticeably affect your connection speed.
Hope that’s clear 
1 Like
Oooooh, very unrelated indeed. 
But yes, I wouldn’t expect anything less given that you’re probably based on Wireguard and doing a great job overall (from the feedback I read on here).
Of course, latency would need to be tested by Mullvad is already doing amazing and I don’t think that 10ms or alike is noticeable anyway if not playing competitive e-sports haha.
1 Like
Ah yeah I see, it is true that the original Private Relay is better in this regard. Though I will note that with Obscura, from Mullvad’s perspective:
- The “identity” has no PII (payment info, connecting IP address) attached to it
- It is only “static” until the next key rotation, which we do every 30 days: source code
I believe @jonah brought this up to me originally when we launched last year and it inspired us to add the Rotate WireGuard key button to manually rotate keys in our Settings page.
3 Likes
GNOME integration would be awesome. Just a simple navbar icon would be enough for now.
Having the RPM in SecureBlue repo’s would be the nicest thing ever, Flatpack can do too.
Oh interesting… That would have to be an integration specifically for GNOME.
Once we move on from the CLI to a full GUI we may do some integration with Network Manager so that it’ll show up on top navbar, that may it!
Seems like I gotta check out SecureBlue…
GNOME just uses network manager (vpn shows up on quick settings/top nav bar)
By adding support to a desktop environment you essentially support all Linux distros that uses it - and imho GNOME has no competition.
1 Like
Only secure Desktop there is!
I’m assuming this is how multihop works with Mullvad and IVPN too?
Key rotation, no matter how frequent, does nothing to address the fact that Mullvad has a static identifier on the client? As long as this remains the case, I don’t see how Obscura’s different than Mullvad’s multi-hop (which costs ~60% less?); especially, when there’s more than one way to purchase Mullvad VPN anonymously.
Besides, I don’t think key rotation will be as seamless (if possible at all) with exported WireGuard configuration for use with 3p clients? So, that’s another foot gun, too. If Obscura doesn’t already, it could warn users that they shouldn’t really use 3p WireGuard clients, unless absolutely necessary.
Hm… when the examples are Phreeli and T-Mobile & not VPN companies, I guess it is easier to grok? 
1 Like
I am not following what you are not following here.
There are basically two identifiers that Mullvad sees in normal non-Obscura use: your IP address, and your account/WireGuard public key.
Obscura hides the first identifier from Mullvad, so that answers this question:
…and, Obscura rotates the second identifier too, by periodically rotating the private WireGuard key being used with Mullvad. This is the issue I immediately identified last February and then they fixed.
This I agree.
Phreeli does no such IMEI or IMSI rotation or shielding from T-Mobile at all, which again is my point against Phreeli, and was my point against Obscura last year lol
1 Like
Given Mullvad’s no logs policy, in the multi-hop mode, Mullvad’s entry “sees” the client IP, while the exit “sees” the public key. While, Mullvad also supports KYC-less payments and virtually anonymous sign-ups …
… hence the point such two-party MPRs are no different than “trust me bro” no-logs multi-hops that PG already recommends (that most here are, in fact, inclined to trust for good reasons).
If Obscura also “rotates” the Mullvad account ID, in addition, then you’re probably right about “was”.
Setting aside their “double blind” (non) implementation, I must note that Phreeli claims the only KYC they need for eSIMs is the zipcode; a neat “anonymity set” to hide behind, if Phreeli’s userbase grows large enough in that zipcode.
1 Like
Obscura is really in alpha isn’t it even the apps are buggy. Mullvad is blocked most places so it’s unusable and there is no choice to pick the exit server to overcome blocks. Support don’t have a ticketing system. They don’t even reply. Instead of moving on to the next Os to support sort out your apps what already are out there.