Sadly I’ve run into the same type of problem with a newer TLD as well. My solution was to get a domain in the older TLD space (e.g. .com, .net, .org). I doubt this will be the last site you run into that doesn’t support a newer TLD and the low likelihood that you’re going to be able to convince someone to fix the issue at every one of those outdated sites means that you’ll eventually need a backup domain for something.

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.

I can see warning fatigue being a problem and trying to avoid the use of the interstitial pages because of that. That don’t want to display the big warning when they’re not confident as then people might ignore those in other contexts (cert errors, phishing/dangerous sites, etc).

How it works: Chrome only displays the lookalike phishing protection screens for sites with similar domains to the ones you visit, which can be detected by a server when the site doesn’t load (the warning first appears instead).

Summary from the conclusion:

Lookalike Warnings are arguably a great safety feature that protects users from common threats on the web. It’s hard to balance effectiveness and good user experience, making Site Engagement a vital source of information. However, since disabling Site Engagement or Lookalike Warnings is impossible, we believe it’s important to discuss these features’ privacy implications. For some people, the risk of exposing their browsing history to a targeted attack might be far worse than being tricked by lookalike phishing websites. Especially given that site engagement is also copied into incognito sessions.

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.

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

The ability to easily link to a specific post or comment in a way that works across instances/clients, like you can with communities.

Are you talking about the “Make Chrome your own” page that walks you through a few customization options before asking if you want to sign in? You can just select “No thanks” and you’re not signed in. Incognito windows work just fine.

Or are you talking about the “Set up your new Chrome profile” screen that pops up when you make a new profile? It shows two options: Sign in [to Google] and “Continue without an account”. “Continue without an account” just has you name the new profile to distinguish it from any others you may have and then lets you start using it. Incognito windows work just fine.

This is Chrome on the desktop by the way.

Their browser doesn’t say that it protects you from websites (including their own) tracking you.

Also, they consider it a problem if a website can detect if you’re using incognito mode: https://www.blog.google/outreach-initiatives/google-news-initiative/protecting-private-browsing-chrome/

Chrome will likewise work to remedy any other current or future means of Incognito Mode detection.

Having a signal sent to websites to tell them that you’re in Incognito mode would make things worse for users and would probably work about as well to reduce tracking as the Do Not Track header.