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 feel like it’s less a conspiracy and more that some people will accept nothing less than no ads or tracking whatsoever, even if it makes no economic sense with regards to how sites support themselves.
Meanwhile, attempts like Mozilla’s Privacy-Preserving Attribution to allow for showing that an advertising campaign is effective without the granular, per-user tracking are rejected by the community, meaning that the situation never improves in even a small way.
I’d imagine that making it a user choice gets around some of the regulatory hurdles in some way. I can see them making a popup in the future to not use third-party cookies anymore (or partition per site them like Firefox does) but then they can say that it’s not Google making these changes, it’s the user making that choice. If you’re right that there’s few that would answer yes, then it gets them the same effective result for most users without being seen to force a change on their competitors in the ad industry.
What’s the UK CMA going to do, argue that users shouldn’t be given choices about how they are tracked or how their own browser operates?
Looking at it most favorably, if they ever want to not be dependent on Google, they need revenue to replace what they get from Google and like it or not much of the money online comes from advertising. If they can find a way to get that money without being totally invasive on privacy, that’s still better than their current position.
I’m pretty sure that people were unhappy because it was opt-out at first. Now that bridging is opt-in, I don’t think most people have a problem with it and I’ve seen a number of posts from both sides of the bridge so it seems to be working.
I don’t think there’s a lack of empathy, especially when you consider that we may be concerned for the more numerous viewers who could potentially see your comments if we help you bypass the filters that you seem to be running into more than just occasionally.
It’s not that they need to know that to provide a potential answer, it’s that they want to know that before they decide to help you bypass a filter.
They changed it in the article after it was originally posted: https://web.archive.org/web/20231116232800/https://www.theverge.com/2023/11/16/23964509/google-manifest-v3-rollout-ad-blockers
They have a note about it at the bottom:
Correction November 16th, 9:41PM ET: Firefox is based on Gecko, not Chromium. We regret the error.
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?
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.
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
Here’s Microsoft’s information page on it:
https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby
It’s been in there for weeks/months: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/components/privacy_sandbox
Most if not all other Chromium-based browsers have disabled it though.
I think the Firefox settings now call it the address bar when selecting if you want it to do both functions or have separate boxes. It may still be that internally.
Also I just looked it up and apparently I was wrong anyways and the Chrome internal docs call it the omnibox actually…
And the chromium developers blog calls it the address bar…
And so does The Keyword (blog.google)…
I think they’ve both given up on getting the public to use their special names now that it’s just an expected feature of a browser.
When most sites refer to passkeys, they’re typically talking about the software-backed kind that are stored in password managers or browsers. There are still device-bound passkeys though. Also since they’re just FIDO/WebAuthn credentials under the hood, you can still use hardware-backed systems to store them if you really want.
While you’re right that device bound and non-exportable would be best from a security standpoint, there needs to be sufficient adoption of the tech by sites for it to be usable at all and sufficient adoption requires users to have options that have less friction/cost associated with them, like browser and password-manager based ones.
Looking at it through the lens of replacing passwords instead of building the absolutely highest-security system helps explain why they’re not limited to device-bound anymore.