We partnered with Mullvad as our exit node and launched with QUIC-based obfuscation, so you bet I’m happy to see more of this! 
It’s great seeing more QUIC-based protocols getting launched, the VPN industry needs to invest in more core innovation and less in FUD-y marketing.
A few points on TCP obfuscation (“the old way”):
- TCP obfuscation when done over a reliable/vanilla TCP socket suffers from the TCP-over-TCP meltdown problem (bad performance, jittery-ness)
- TCP obfuscation when done by not actually running TCP, but sending IP packets that look like TCP won’t work on networks like airlines where they do TCP re-termination (a la Performance-enhancing Proxy)
This is why QUIC-based is great, it looks like an HTTP/3 connection and doens’t suffer from the TCP-over-TCP meltdown problem because the application dictates the congestion control rules (more here).
It doesn’t mean that it’ll get around IP blocks or port blocks (it’s not magic), it simply makes it:
- Far less likely for a network admin to block your access by collateral damage with overly-zealous firewall rules (e.g. “we’re blocking all ports other than 80, 443, and 53!”, unfortunately far more common than you’d expect)
- Far trickier for nation-state censors to implement a fine-tuned DPI system (especially with Chaos Protection)
Any VPN that has to work in various network environments need a variety of obfuscation strategies to get around network blocks, and each strategy comes with its tradeoffs. Having QUIC obfuscation in the toolbelt makes it far more likely that you’re successfully connecting in the first place, and that your connection is reliable and non-jittery.
Sidenote: One of our engineers did recently come up with a way to do TCP obfuscation without suffering from the TCP-over-TCP meltdown and work even when being re-terminated. We’re researching this method internally now 
typed and sent over Obscura’s QUIC-obfuscated tunnel with a Mullvad exit node 