1. 30
  1.  

  2. 36

    tldr; Tor but paid. Just two hops, the company (Invisiv) and a partner (Fastly).

    Invisiv sees your IP. Fastly sees where you’re connecting to (and the content if the destination is unencrypted). Only thing keeping this information uncorrelated is both companies agreeing to not share data.

    Sounds weak. Better than a regular VPN, but not much.

    EDIT: Closed source (or at leasr sources not disclosed on the webpage). App distributed thru Google Play. Release an update and the app could act as a regular VPN without users noticing anything.

    1. 2

      Correct, though we think the closer equiavlent to this is Apple’s iCloud Private Relay, in pretty much every way (same architecture, protocol, and infrastructure), except that it’s for Android and it works for most/all apps rather than just specific apps. (Also as I mention in another comment, we will be open sourcing it very soon.)

      1. 4

        Apple uses three exit node providers though, not just one.

        1. 4

          Yes and no – they do use three globally, but in each location they don’t use all three:

          https://arxiv.org/pdf/2207.02112.pdf

          1. 3

            But they don’t use just one either, they generally use two, a fact listed in section 4.2, paragraph “Geo Distribution” of the linked paper and easily verified by checking the assignment of addresses from https://mask-api.icloud.com/egress-ip-ranges.csv.

            Where I live, I constantly switch between Akamai and Cloudfare.

            1. 4

              Where I am, I’ve seen it stick with Akamai 90% of the time, sometimes go to Cloudflare. But yes, that’s a matter of resilience that a big company like Apple needs. We may add a second soon.

              1. 1

                Unrelated: why don’t you support iOS?

                1. 2

                  Tricky question on multiple levels, but the main reason is that we figured, since Apple already has Private Relay on iOS, that there wouldn’t be that much interest from users (even though ours has some differences). We could port it if there were enough interest.

    2. 17

      It looks like this is proprietary/“closed source” right now, which is concerning in a privacy product. It’s also Google Play only which makes it hard to use for any of the privacy nerds out there.

      Still, the article is spot on.

      1. 10

        We actually plan to open source this very soon – we just launched this beta and just need to get a green light before we do.

        1. 5

          What is your monetization strategy? I’m pretty sure a ton of shady VPN companies sell their customer’s traffic data to supplement their income. How do you ensure that this service keeps on running?

          1. 5

            It’s pretty straightforward: we offer infrastructure as a service, so for better or worse it’ll always be a paid service because that allows us to pay for servers and bandwidth.

            Ultimately we’re a infrastructure company so our intent here is not to be a consumer-facing VPN competitor as our primary thing – instead we’ve built this and other privacy services to prove that these privacy building blocks can be used by others in their own services. (We have more coming soon in this regard.) So we’re partnering with companies that care about privacy but who don’t have our infrastructure so that they can offer this to their existing users.

          2. 2

            🎉

            1. 2

              That’s good news you plan to release the code.

          3. 6

            Isn’t unencrypted SNI also an issue for VPNs?

            1. 4

              In the trace we collected for that VPN leak / analysis video, only a tiny fraction (a few percent IIRC) of the requests were using Encrypted Client Hello.

              1. 3

                Yeah and this paper suggests that “only around 1.5%–2.25% of domains on the Internet have ESNI supported” and that “ Cloudflare […] is the only Internet company supporting ESNI to the best of our knowledge”

                1. 1

                  Cloudflare […] is the only Internet company supporting ESNI to the best of our knowledge

                  Where do they support this? Is it in their function as a DNS / hosting provider for other people’s domains?

                  1. 3

                    ESNI

                    Cloudflare is MitMaaS for their DDoS protection. That’s where it’d come into play.

                    1. 1

                      Ah, I see. Weird. So then, the main subject of contemplation for me: these people couldn’t find a single actual hosting provider that supports ESNI? Or were they just not looking hard enough?

                      1. 2

                        check for yourself, it’s easy enough to query for TXT records on _esni.$DOMAIN.$TLD names. In fact, it looks like even _esni.cloudflare.com no longer returns a TXT record. Additionally, ESNI firefox has fully deprecated it, so we’re very much in a liminal state in between ESNI and ECH.

              2. 7

                I co-authored this piece – I’m of two minds about the pointed title I put on it, but I really do think we need to have a conversation about VPNs…

                1. 4

                  I agree with (at least the first half) of the title. Too many VPNs are marketed as increasing your privacy, when in reality you’re just shifting your risk of a privacy breach from your local ISP to a remote network run by a different company.

                  Edit: my only complaint is the second half of the title. MPRs aren’t a silver bullet for perfect privacy, though I understand the need to write from a slanted perspective to market your product. My main concern is that it sounds like there are only two parties (Fastly and INVIS) involved. So, only two parties would have to collaborate to deanonymize you on INVIS, whereas Tor, for example, would require hundreds of parties (each Tor routing node) in collaboration to deanonymize you.

                  1. 8

                    I think the unspoken question is: what’s the threat model? Nothing will ever grant you perfect privacy, due to the basic architecture of the internet. But there are things that can help with the specific threat models you care about, if you drop “perfect privacy” as the goal.

                    For example: I ran my own VPN (an instance of algo) for several years. It was a time when I was traveling a lot, and having to get work done via random airport/airline/hotel/cafe wifi. I didn’t want or need perfect privacy. I did want to avoid those entities being able to easily snoop on everything I was doing and/or inject things like ads into my traffic. And my VPN did that admirably!

                    So for that use case and threat model, at that time, a VPN was a good choice.

                    1. 7

                      Yeah. I generally like nuance so suppose if I had the room I would have the title say “…MPRs are Right given certain privacy goals, certain infrastructure assumptions, and certain policy regimes.” But at the very least for the things that most VPNs are used for today.

                      Edit to reply: I’d say this about the security model – the security model for Tor, iCloud Private Relay, and Invisv Relay are all the same, as there’s a non-collusion requirement for whoever is on the path. With Tor you don’t need collusion among hundreds of parties to mount an attack, just the on-path nodes (usually 3). All these systems – and any privacy system that doesn’t pump the network full of constant bitrate traffic flows – are also subject to third-party attackers mounting timing attacks (though this requires global visibility and typically can be done only by governmental agencies, so it’s not something the average user can reasonably be worried about / defend against).

                    2. 3

                      So, if the part I connect to, and the “infrastructure partner” are, as it says, partners, how can I know for sure they won’t share data? If they do, aren’t we back to the same problems as VPNs?

                      It sounded like I can’t choose a “infrastructure partner”, whatever I’m connecting to has to have a business relationship with the infrastructure partner, do I get this right?

                      1. 5

                        Yes, that’s right, though it’s not just back to VPN-level non-privacy – VPNs get breached, like other services and networks, all the time. But when they do, because of their visibility into everything, user privacy is immediately compromised. Whereas a Multi-Party Relay service has limited to no visibility at each hop, so a breach would have to be ongoing and simultaneous at all independent organizations for it to have the impact that it would with a VPN.

                        More broadly, there are non-collusion trust assumptions baked into most or all security and privacy services we depend upon, including things as fundamental as the certificate hierarchy that we depend upon for TLS to services like these MPR services to the hardware enclaves that AWS/GCP/Azure offer based upon hardware from Intel/AMD/Arm/… It’s definitely not a panacea but I think it’s a practical and important step forward.

                    3. 1

                      It’s a meaningful project that’s sure to have a lot of backing

                      Any alternatives to using cloudflare for private DNS lookups? Can we specify a DoH server?

                      1. 1

                        I think you should specify a DoH resolver at a system level, not in your VPN/MPR client, no?

                        1. 2

                          Yes and no – so unfortunately if the user enters a specific DoH resolver in their Android settings, this conflicts with the MASQUE protocol relaying that we’re doing to protect user privacy. My co-founder Paul developed Oblivious DNS, which was then rolled out as Oblivious DNS over HTTPS in Apple’s iCloud Private Relay service. We’re doing something similar – not just DoH to the server (which then knows who you are), but instead over the multiple hops of Relay.

                          As for configuring it – we plan to add that very soon. It’s already configurable in our network code – it’s just been an issue of adding a UI element for it somewhere convenient in the app. Which may give away the maybe-obvious fact that we’re networking/security/infrastructure people and not UI people. :)