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.
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.
The bar at the top of the browser that acts as both a place to enter addresses and enter searches. It’s not strictly an address bar nor a search bar. It’s both. It’s all. It’s omni.
I second this. The Outlook PWA for mobile is actually a fairly decent example of a web app done right compared to a lot of other ones, it works in Firefox for Android, supports notifications, and can be installed to the home screen.
I don’t think any password managers that don’t have that feature currently are likely to implement this feature after the beating that LastPass took in the press about it:
LastPass breach is worse than you think because URLs were unencrypted
Maybe an app might be able to cache the metadata locally but I don’t think it would be something people expect to be unprotected at this point.
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?