I think it was more targeting the client ISP side, than the VPN provider side. So something like having your ISP monitor your connection (voluntarily or forced to with a warrant/law) and report if your connection activity matches that of someone accessing a certain site that your local government might not like for example. In that scenario they would be able to isolate it to at least individual customer accounts of an ISP, which usually know who you are or where to find you in order to provide service. I may be misunderstanding it though.

Edit: On second reading, it looks like they might just be able to buy that info directly from monitoring companies and get much of what they need to do correlation at various points along a VPN-protected connection’s route. The Mullvad post has links to Vice articles describing the data that is being purchased by governments.

One example:

By observing that when someone visits site X, it loads resources A, B, C, etc in a specific order with specific sizes, then with enough distinguishable resources loaded like that someone would be able to determine that you’re loading that site, even if it’s loaded inside a VPN connection. Think about when you load Lemmy.world, it loads the main page, then specific images and style sheets that may be recognizable sizes and are generally loaded in a particular order as they’re encountered in the main page, scripts, and things included in scripts. With enough data, instead of writing static rules to say x of size n was loaded, y of size m was loaded, etc, it can instead be used with an AI model trained on what connections to specific sites typically look like. They could even generate their own data for sites in both normal traffic and the VPN encrypted forms and correlate them together to better train their model for what it might look like when a site is accessed over a VPN. Overall, AI allows them to simplify and automate the identification process when given enough samples.

Mullvad is working on enabling their VPN apps to: 1. pad the data to a single size so that the different resources are less identifiable and 2. send random data in the background so that there is more noise that has to be filtered out when matching patterns. I’m not sure about 3 to be honest.

And that’s a bad thing?

The desktop is finally catching up with the more restrictive permissions model where an app doesn’t just have the ability to do anything the user can do but instead only has access to what it needs.

Going with a familiar interface style like the ones people already use on mobile just makes sense.

What would you want it to look like instead?

Vizio makes twice as much profit from those ads and tracking services than the actual TVs:

https://www.theverge.com/2021/11/10/22773073/vizio-acr-advertising-inscape-data-privacy-q3-2021

Looks like it just concatenates them:

The shared secret is calculated as the concatenation of the X25519 shared secret (32 bytes) and the Kyber768Draft00 shared secret (32 bytes). The resulting shared secret value is 64 bytes in length.

https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html>

Yeah, I feel like it’s going to take both browser vendors shaming sites once a standard is developed/finalized and something like a quantum version of whynohttps.com to drive adoption.

The problem really is the store and decrypt nature of it. It could be used against old data so the time when it needs to be implemented is before it becomes possible to decrypt. I feel like people aren’t good about planning like that and tend to be more reacting to what is currently possible.

Considering this proposal is used for the key exchange, they definitely need to update both the client side and server side part to be able to make use of it. That’s the kind of thing that may take years but luckily it can fall back to older methods.

It also needs to be thoroughly vetted so that’s why it’s a hybrid approach. If the quantum resistant algorithm turns out to have problems (like some others have), they’re still protected by the traditional part like they would have been, with no leaking of all the data.

Currently being investigated by browser makers but not something they can just do on their own like Signal.

Here’s Chromium’s current proposal that they’re testing:

https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html