Only for ones that are explicitly a replacement for them.

gorhill’s reasoning from the FAQ:

Will uBO automatically transition to uBO Lite in the Chrome Web Store?

No.

You will have to find an alternative to uBO before Google Chrome disables it for good.

I consider uBO Lite to be too different from uBO to be an automatic replacement. You will have to explicitly find a replacement to uBO according to what you expect from a content blocker. uBO Lite may or may not fulfill your expectations.

From the article’s second paragraph:

uBlock Origin has launched uBlock Origin Lite, which uses Manifest V3, in response to the transition.

A Chromium thing. Some Chromium-based browsers are going to keep some kind of internal ad blocker that has more functionality than MV3 allows for but I don’t know of any that are keeping the older functionality for extensions in general.

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.

There was the one case with the scammers in the UK using a homemade cell tower to essentially send out phishing texts directly to cell phones in an area, completely bypassing the phone company. It seems like this scare texts scenario would fit that kind of tech even better, as you only need to send out a message once to a large amount of people and you don’t need to collect information in response like in a phishing scenario.

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.

Composable moderation/custom labeling and custom algorithmic feeds are two things that Mastodon doesn’t have that Bluesky does.

Isn’t the main problem that most people don’t use the E2E encrypted chat feature on Telegram, so most of what’s going on is not actually private and Telegram does have the ability to moderate but refuses to (and also refuses to cooperate)?

Something like Signal gets around this by not having the technical ability to moderate (or any substantial data to hand over).

Before people can be persuaded to use them, we have to persuade or force the companies and sites to support them.

A multi-billion dollar social media company sued an ad industry group that was trying to have help companies have some kind of brand safety standards to prevent a company’s ads from appearing next to objectionable content. They reportedly had two full-time staff members. This isn’t some big win, it’s bullying itself.

Basically with passkeys you have a public/private key pair that is generated for each account/each site and stored somewhere on your end somehow (on a hardware device, in a password manager, etc). When setting it up with the site you give your public key to the site so that they can recognize you in the future. When you want to prove that it’s you, the website sends you a unique challenge message and asks you to sign it (a unique message to prevent replay attacks). There’s some extra stuff in the spec regarding how the keys are stored or how the user is verified on the client side (such as having both access to the key and some kind of presence test or knowledge/biometric factor) but for the most part it’s like certificates but easier.

Don’t most DoH resolversl settings have you enter the IP (for the actual lookup connection) along with the hostname of the DoH server (for cert validation for HTTPS)? Wouldn’t this avoid the first lookup problem because there would be a certificate mismatch if they tried to intercept it?

With a breach of this size, I think we’re officially at the point where the data about enough people is out there and knowledge based questions for security should be considered unsafe. We need to come up with different authentication methods.

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?

The plan was only to kill off third-party cookies, not first-party so being able to log into stuff (and stay logged in) was not going to be affected. Most other browsers have already blocked or limited third-party cookies but most other browsers aren’t owned by a company that runs a dominant ad-tech business, so they can just make those changes without consulting anyone.

Also, it looks like there might be some kind of standard for federated login being worked on but I haven’t really investigated it: https://developer.mozilla.org/en-US/docs/Web/API/FedCM_API

They definitely knew it would impact their ad business but I think what did it was the competition authorities saying they couldn’t do it to their competitors either, even if they were willing to take the hit on their own services.

Impact on their business (bold added): https://support.google.com/admanager/answer/15189422

• Programmatic revenue impact without Privacy Sandbox: By comparing the control 2 arm to the control 1 arm, we observed that removing third-party cookies without enabling Privacy Sandbox led to -34% programmatic revenue for publishers on Google Ad Manager and -21% programmatic revenue for publishers on Google AdSense.
• Programmatic revenue impact with Privacy Sandbox: By comparing the treatment arm to control 1 arm, we observed that removing third-party cookies while enabling the Privacy Sandbox APIs led to -20% and -18% programmatic revenue for Google Ad Manager and Google AdSense publishers, respectively.