I commend Firefox for trying to do this... but it worries me.
3 obvious holes:
- Proliferation of dialogs. When you don't know whether a site will suddenly break or not, standard users will be implicitly trained to say yes to all dialogs.
- Domain "homogenizing" (spoofing) services will win. Trackers that offer a widget you can install on your server will win. Facebook et all will still know where they sent you, and will be able to track you server side. If mozilla provide a centralized whitelist, then SSO providers who also provide trackers will win. Essentially, the big players will find a way, the little players (who users weren't worried about anyway) will still lose.
- The web will break. SSO will be broken for a good couple of months on over 50% of websites using it - possibly more. "This only works in Google Chrome" will become more and more popular. Potentially, Firefox doesn't have the market share to make this work.
Those of us who will stick with Firefox regardless are in for a world of pain, and not a lot of gain. I guess it's necessary to move the web on, but the pessimist in me doesn't see that happening any time soon.
> ...the little players (who users weren't worried about anyway) will still lose.
The little players not having data is a win in my eyes, because those are more likely to get breached or sell data to the highest bidder.
> This only works in Google Chrome
Regardless of Firefox abiding by the standards (or doing what Chrome does) or not, this was always going to be the case, and so it isn't that big a deal.
> Trackers that offer a widget you can install on your server will win.
This is already a thing thanks to the popularity of content blockers like Pi-Hole and uBlockOrigin. Firefox's move here is another nail in the coffin for third-party tracking through third-party servers. At least, first-party tracking with third-party "widgets" means first-party would need to shell out the cost of running that infrastructure.
> The web will break.
The web always has been :)
> Those of us who will stick with Firefox regardless are in for a world of pain, and not a lot of gain.
For me, Firefox seems to be making decisions with user's security and privacy in mind, and I see that as a net positive. As a long time user, it is the only reason I use Firefox.
I agree with pretty much everything you've said :)
I guess my gripe is more "Why does the world not work right" than "Firefox has done a stinker here".
And I suppose my reaction really should be "How can we work to give Firefox a leg up, while still encouraging it to intentionally fail many of the metrics most people care about".
It's a hard battle to fight. Don't suppose Google will implement these things that might hurt their user tracking businesses... yeah?... no?... no.
> thanks to the popularity of content blockers like Pi-Hole and uBlockOrigin
Unfortunately these are "block these please" which hurts all the big players for the tiny portion of web users that use them. Every time I've ever moved a feature in software I've written from "all except this" to "none except this", it has always failed spectacularly, at least for a few people. The fact that users will get an option to unblock the services they need is encouraging... the fact that they mention that users might see the dialog multiple times for the same service is not.
But yes, I will try to be hopeful - and you are right, the fact that Firefox does this kind of thing is a big part of the reason I use them in the first place.
> Regardless of Firefox abiding by the standards (or doing what Chrome does) or not, this was always going to be the case, and so it isn't that big a deal.
It's a huge deal to me as a Firefox user. This is a total anecdote, but the number of websites and apps that are broken in Firefox seem to be on the rise. I try to report bugs when I can but the task is Sisyphean.
If Firefox is increasing the friction between web developers and the browser while chrome is lowering it, the problem will only get worse.
I remember a time when Firefox didn't work for anything that required ActiveX.
I remember when Firefox didn't support Flash without a seriously dangerous plugin.
I remember when somehow enough people woke up and banded against ActiveX and Flash.
It seems popular here to make the argument that "doing what's right" poses an existential threat to the right-doer. The corollary to that argument is that in order to survive you must do what is wrong.
For some, it is better to die than to go along with what is wrong. Luckily, it often works out that those who have the courage to do the right thing survive. And when they do the world is often a better place.
Don't cave into the naysayers who predict the end of the world. Keep fighting the good fight.
"And herein do I exercise myself, to have always a conscience void of offence toward God, and toward men."
Cool story, I still have to use Chrome to talk to my doctor, view my healthcare documents, and get my W2. While Firefox is "doing the right thing," me, the Firefox user, has to use a different browser that doesn't respect my privacy because they don't do what web developers expect.
And you can blame web developers, businesses who hire them, or Google for turning the world into this sorry state. But oftentimes the only choice I have as a consumer is what browser I use, and most of the time it's Firefox. But more and more frequently, I can't choose to use Firefox because some functionality is broken on a website I need to visit.
The more of this functionality that they break, the more often I need to use Chrome.
Your claims are suspicious. A company cannot require you to have internet access to supply you a W-2 tax form. You choose to keep your healthcare documents in some format that requires Chrome? That seems very very strange. Your doctor won't talk to you in person or on the telephone? Again, strange.
You are not forced into any of these things. You choose them as a matter of convenience, cost-savings, or some other reason. You have your reasons, but it is highly unlikely that you don't have a choice.
The choices you have purportedly made have allowed others to make poor choices with little consequence. With less effort than it took to install Chrome, you could have asked for a paper copy of your W-2. That would have put the pain of a bad decision back upstream where it belongs.
> The more of this functionality that they break, the more often I need to use Chrome
From context, "they" would refer to the party that breaks functionality. From the sentence above, I take that to be "Google for turning the world into a sorry state." Your response to this is to "need to use Chrome." Your choices seem irrational to me.
But again, they are your choices and you do have them.
Many of my documents are accessed electronically through various web services. Many of them function poorly or not at all with Firefox. I'm sure I could make a phone call and get them mailed to me, but "don't use the internet" is not an acceptable workaround to a website failing to load in Firefox.
The "they" I refer to is Mozilla's engineers. They have consistently broken or failed to implement their platform as developers expect, and since their market share is tiny, developers do not care and bug reports.
I accept that by using Firefox my experience on the web is degraded. That's a tradeoff I make. What I'm reacting to is that it seems you've put on the blinders from the high horse you're sitting on. In the real world, Firefox is technically limited by the many decisions to ignore what developers are doing.
Instead of blaming the users for following the path of least resistance, blame Mozilla for failing to make the "right thing" the path of least resistance for developers. If Firefox were easier to target than Chrome, supported more APIs and had better developer tools, then we wouldn't have this reality.
Your handle "freeopinion" reminds me that although people often say "you get what you pay for," just because something's free does not mean that it's worthless.
> For me, Firefox seems to be making decisions with user's security and privacy in mind, and I see that as a net positive. As a long time user, it is the only reason I use Firefox.
I agree that that is a good thing. However, the more firefox breaks compatibility with sites people use, the harder it will be to regain marketshare. And if Firefox keeps losing marketshare it will have less ability to influence web standards, and could potentially die altogether, which would be bad for privacy and security in the long run.
Fortunately, state partitioning isn't enabled by default on Firefox yet (it is part of "strict" ETP), so only people who are ok with it potentially breaking sites will turn it on.
> The little players not having data is a win in my eyes, because those are more likely to get breached or sell data to the highest bidder.
I somewhat agree with everything but the above. I’ve looked at data on thousands of breaches and have found that size of organization isn’t really correlated with “having better security”.
"Regardless of Firefox abiding by the standards (or doing what Chrome does) or not, this was always going to be the case, and so it isn't that big a deal."
The "dealedness" of this isn't a binary. One may tolerate a small amount while rejecting a large amount.
I point this out more to put the idea out there (it's an important concept even in your day-to-day job) than because I disagree with the main thrust being made here; as a uMatrix use I traded security for a functional web a long time ago. Breaking trackers is a feature, not a bug, for me. If that breaks your website, goodbye.
As a developer, shit like "Automatic unpartitioning through heuristics" alone is enough that I won't touch this. Full stop.
Firefox is now breaking the contract I expected it to fulfill as the user's agent, and it's doing it fucking at random.
I happen to live in a space where I do need cross site support (both for cookies and requests) and frankly, between Google's push for SameSite, and now Firefox's selectively breaking the cookie jar, I'm pissed.
I'm a bit boggled that we haven't settled on a decent solution to let a site declare how it wants to interact with other sites.
This already fucking exists for mobile too, both Android and iOS support an opt-in manifest declared at a /.well-known/ path on the origin in question, why the fuck are the browser vendors so DEAD SET on removing control from the sites themselves in favor of these rushed, half assed, shoddy solutions.
Let me declare the sites I want to allow to share my resources. Let me do it at a known location, with a standard manifest, with finer grain control than "Random fucking heuristic" and "strict/lax/none".
I feel like the entire purpose of this is to take the control from the sites and give it to the users. The site owners obviously do want the cookies to be shared with trackers if they embed them.
I don't mind at all if Firefox wanted to propose a standard way to declare cross site sharing, and then allows the user to overrule my settings as a dev (or even if they pick more restrictive defaults, if user opt in is a problem).
There's a standard in place, so arbitrary exceptions and heuristics don't create incredible headaches, and there's a clear path to resolving the issue in support/triage with the customer if they create a rule that does actually break my site's functionality.
I do mind, quite a bit, when Firefox essentially goes "Fuck the standards", and starts playing fast and loose with the rules. And I mind for two reasons
1. I expect better from them. I'm old enough to remember how much steam Firefox picked up from IE by just treating a standard as a standard. It was novel, and transformed front-end development in a great way.
2. They are not the market leader, and non-standard, site breaking bullshit only does more to sink their ship, and I desperately want a competitor in the browser ecosystem that is not Google Chrome (or a rebranded chromium port).
Isn't that pretty much exactly what this accomplishes? It means sites first have to request your permission in a popup.
I thought the article made it pretty clear that the heuristics are only intended as a temporary stop-gap measure to prevent every current SSO service from breaking.
> I thought the article made it pretty clear that the heuristics are only intended as a temporary stop-gap measure to prevent every current SSO service from breaking.
That sentence alone is mind boggling - Hey, Mozilla is breaking every standard that previously allowed cross domain authentication, or 3rd party authentication services, but don't worry, it's only temporary... until what exactly?
Either every site under the sun is suddenly asking the user to accept unpartitioning because critical features are broken and a user literally has to click yes to continue, in which case all you're doing is training users to always click yes (EU cookie popups, take two, lovely...)
Or users move away from Firefox because sites are just broken.
They don't even have a long term solution for how SSO services are expected to work here, other than "use this other API that happens to cause the behavior as a side effect, and oh, btw, the global market leader (chrome) doesn't support it yet! Enjoy!"
Where the fuck is my RFC. Where is real planning I'd expect from a from the company that I only know the name of because they actually gave a shit about standards when IE was doing this kind of crap left and right?
I like Firefox precisely because they normally don't do this bullshit (and their standards based docs on MDN are literally some of the best around).
---
My take is that this is essentially security advertising and social signaling, and is another death blow to Firefox from Mozilla trying to push privacy focused paid services.
I have been using the First-Party Isolation feature for a few months now. FPI (privacy.firstparty.isolate) is a flag that was originally created for the Tor Browser project. It's a strict version of State Partitioning without any way to unpartition (no permission dialogs, no heuristics).
So far I have only come across one broken website: Microsoft Teams login through Okta SSO.
The rest of my logins worked flawlessly with FPI turned on. Nothing close to the 50% that you mention.
I don't understand why the SSO would be broken. AFAICT, I'd just need to re-login to the SSO-provider (Okta in this case) in the context of the initiator (Microsoft Teams, in this case). They'd otherwise need to be doing something silly if it stops working.
Teams relies on iframe auth to fetch the Nth token from AAD (multiple resources to call, multiple tokens required). The iframe calls are partitioned and lose cookies, even under Firefox's helpful "redirect exemption" setup, it's not clear why.
That's encouraging news. Do you use a lot of sites with SSO? Are they mostly mainstream (where I would class MS Teams to fall in that bracket) or do they tend to be more niche services?
(I totally accept that my "50% of SSO systems will be broken by this" to be a worst-case random number i-have-no-idea-but-for-all-I-know value. Probably shouldn't have been so blasé about it! But very much interested to hear what real-world values look like)
Okta SSO is used heavily inside my company to access internal sites, but if there's a way to whitelist, or the user sees a popup the first time and allows Okta cookies after that, this problem is taken care of.
SSO really doesn't need cookies to function, you can e.g. pass short-lived authentication tokens via URL hash fragments, that is already supported by OAuth 2.0 via the implicit grant flow (and for API-based flows it's not a problem).
IMO this and referrer URL are the only information that ought to be able to be shared between two different domains via the browser. Either put it in the query string so the user can be aware of it or leave it alone.
Of course, there are downsides. Query string character limits constrain what can currently be passed (some would say a it's good thing in this context), and browsers are headed more and more towards showing only the domain in the address bar by default.
The other remaining problem would be tracking via XHR. The only mechanism for limiting which servers an XHR request can talk to currently is CORS, and that config is controlled by the server, not the user.
Mozilla went chasing Chrome, and lost almost all of its market share.
Chasing Chrome was a bad decision. When they realised it was, they should've corrected the mistake, but instead Baker doubled down on the wrong direction, breaking all fiduciary duties she has as a CEO of non-profit in the process.
If you're referring to XUL extensions being given the elbow, the small proportion of users using those does not correspond to Firefox market share loss.
That's not Mozilla's only or most significant misstep.
CEO drama, Hello, Pocket, UI indecisiveness, repeated feature removal over objections, breaking everyone's addons first with the XULening then with the addon cert fiasco, opt-out telemetry, force-pushing addons without affirmative consent, opt-out advertising, buying into scummy tracking outfits like cliqz (and trying to hide it), poor prioritization, lack of focus..
If there's ever a choice between giving the user more control and transparency or taking it away, Mozilla seems to take the latter option.
Outside of HN, no one I've ever talked to has mentioned any of those as reasons for using Chrome. The two most common reasons I've heard are "dunno" followed distantly by "I use ten hundred thousand million tabs and Firefox crashed on me once fifteen years ago."
I suspect the rise of mobile browsing, with Chrome as the default, plus users' Google account having strong integration with Chrome--not to mention Google pushing Chrome across all of their properties--have a lot more to do with Chrome's popularity than a button on Firefox's toolbar that you don't like.
Mozilla still hasn't figured out that they are synonymous with Firefox and until that happens you can expect the marketshare to further deplete. Meanwhile, Chrome gain little by little until Mozilla will be utterly irrelevant, which is a huge pity because we really need an independent browser.
I'm still writing this using Firefox but Chrome is now also running all the time on this machine because of one of my private projects which requires web midi (and which, according to Mozilla can not be implemented safely, though Chrome is existence proof that this is nonsense).
Wow, I had actually forgotten about a ton of this stuff, shines a different light on how hard it’s been working to gain trust and be the “privacy browser” in recent years.
> breaking everyone's addons first with the XULening then with the addon cert fiasco
You're forgetting back when they first switched to the rapid release cycle they broke plugins every release. After 3-4 release breaking half my plugins each time I switched to Chromium. It was when they dumped the XUL based extensions and finally had a stable extension API that I switched back.
Layering leaky abstractions over leaky abstractions and calling it security is what the web has turned into. All the while introducing new side channels and attack vectors like WebGL that allow completely covert access via unknown access paths in GPU driver binary blobs.
It’s a difficult argument, depleted of its true meaning by its overuse in VPN ads (which make it... easier to track you at the VPN level). But Firefox has a good enough corporate image to tell that _they_ are the ones who really do it.
I have only gotten a virus once on my computer, and it was because IE was harrassing me with dialog boxes on a regular basis, and one time when it was asking me a yes/no question about downloading code, my brain went into "SSL Warning mode" and didn't say "wait!" until my finger was descending on the OK button.
I only had the virus for ten minutes, but it reconfirmed everything I knew about dark UI patterns.
I think what you want is essentially an entirely fresh browser session for every website you visit. Pretty mind-boggling to what lengths we need to go in order to prevent companies from tracking us. That said most tracking companies seem to have devised strategies to construct fingerprints from data like IP addresses, user-agent strings and any other meta-data they can get their hands on, so the next step will probably be to restrict what kind of information can be learned about the browser environment via JS (e.g. getting exact screen resolution).
Also, data exfiltration via browser extensions is still not a solved problem, there are very popular extensions (Ghostery for example) that are highly privileged in the browser and often collect a ridiculous amount of data. Really can't get my head around why browser vendors still allow that while being so strict on all other forms of tracking.
There's the awesome 'Containerise'[1] add-on for Firefox that lets you define containers for specific sites based on URL filter expressions. Pretty handy to e.g. keep Google cookies in their own Google container.
(The only downside I've found is that, if you navigate from Google directly to a site belonging to a different container, the tab will forget its history and you won't be able to go back to the Google results using the Back button. You just need to remember to open results in a new tab instead.)
Using 'Cookie Quick Manager'[2] you can also move your existing cookies for some domain to their new container, so you don't have to re-login everywhere after creating your new custom containers.
Good luck solving Google's reCAPTCHA, it is nightmare if you have no tracking history. I think currently FF Containers is a best way in UX terms to isolate stuff.
I agree with you that web extensions is still a grey area, pity they can't be configured per container.
I use “private tabs” exclusively on my phone now, and it works great with not too many downsides.
On HN, I can browse just fine; when I want to vote or comment, logging in only takes a few seconds.
News sites either just work, work with some nagging that you have to click through, or hit paywalls and other dead ends. I’m happy to stick with the sites that work and spend less time on the more annoying ones.
Edit to add: I realise I’m still being tracked, but at least I’m making a best effort to limit it. So the idea of a completely siloed browsing session per site sounds great to me.
This needs to be bypassed to use SSO, to bypass it the SSO providers site will need to ask for Storage Access, in some cases the user will be asked for permission…
“After the user has granted access, Firefox will remember the storage permission for 30 days.”
So lay users will get used to just clicking through and blindly granting the permission.
The end result will be an additional step for trackers, and a bunch of headaches for all the legit services that get broken from this change.
I’m all for less tracking but this doesnt seem like a good solution.
> So lay users will get used to just clicking through and blindly granting the permission.
Does it break anything else besides cookie based SSO? Because for those, people will probably just login into the site, and ignore the permission.
Firefox is also adopting the policy of not showing those permission windows at most cases, just showing a small notification. It's not clear on that page if this is one of those cases.
Anyway, I agree that limiting the permissions to 30 days is bad. The users should be entitled to make permanent changes, and revert them themselves when they want. Firefox should at least give them the option, even if it's not the default one.
Lots of third party stuff like chat widgets and shopping carts are going to break. Had to deal with this when Chrome did their 3rd party cookie stuff. It's not insurmountable but adds friction for stuff like that.
It's a shame that "always" will whitelist a whole site though. It'd be nice if Lynx whitelisted a cookie name (per site). That way I could permit "PHPSESSID", but not "_ga".
I never found a Firefox plugin that let me whitelist specific cookies. I might try to write one when I have time.
Looking at the proposed permission UI, I would - as a programmer and heavy web user - have no real clue what to click/what the implications were. If it were Google - do I know and trust them? Well, sort of. I know them; I trust them in the same sense I don't trust a scammer.
Also: 30 day timeout? I'm getting pretty fed up of re-logging into websites already over the last couple of years. Add on re-allowing various permissions for access to various things (sometimes every single time), trying to figure out why websites are broken (ad-blocker vs browser blocker vs not cross-browser tested vs temporary problem vs just totally broken) and it's rather a big productivity drain.
30 day timeout? I'm getting pretty fed up of re-logging into websites already over the last couple of years.
Users having to log in to a website 12 times a year, or 13 times in a bad year, is a price worth paying to improve privacy and security across the internet.
I'm not sure why you'd think you should make a statement on behalf of everyone. If you are happy with this trade-off, you are free to make it.
The 30-day timeout is for Storage Access API - cookies expire much more often already.
As I said, there is an accumulation of productivity harms.
My claim is that the pro-privacy solutions are not good enough relative to the problems they cause (and their effect on improving privacy is also debatable).
I think the concept is good, I just think 30 days is too short. Make it 60 days and now we're talking 6 times per year, much more reasonable. Make it 90 days and I don't think anyone will notice.
This is going to affect every user of every website using federated auth. That's a lot of buttonclicking to add to the universe.
According to Firefox I have 217 saved logins in different websites.
Even if I only used a fifth of them once a month, I wouldn't want to re-login 521 times every year. This is a big UX decline for pretty much zero privacy gain.
I disagree. This is making a significant UX downgrade to a core workflow while making the tiniest blip on tracking. (Oh no! You lose cookies every 30 days)
This is a very positive change, but I'd be interested to know how the Mozilla folks think about 'collateral damage' from a policy point of view.
The exceptions and shared state lead me to believe they've thought about it and tried to mitigate it as much as possible, but how much is acceptable? If this breaks more than they thought it would, is it something they'd be comfortable rolling back or changing?
For example, if I read this post correctly, this change would put a hard upper limit in SSO logins to 30 days for Firefox users (because StorageAccess is only granted for 30 days). That might not be a _huge_ issue for most people, but it'll add a hard limit to something that's never had a browser enforced hard limit before.
I guess the SSO token will still be valid, just not usable for SSO purposes after those 30 days. And most likely you will just have to click "Accept" again on the cookie popup to get it working as before for another 30 days.
However, dont basically all SSO cookies live far shorter than 30 days? To my knowledge all SSO services i have used have expired earlier requiring me to log back in again.
> However, dont basically all SSO cookies live far shorter than 30 days?
At least in the case of Google auth: While G may reauthenticate you every 30 days, it's global to your web browser. So after you have reauthenticated, you are back to "logged in" to websites you've logged in to with Google.
In the "old way" you only need to reauthenticate to Google, Microsoft, etc once a month.
With this new Firefox UX, you still need to reauthenticate to Google, Microsoft, etc once a month, but you also need to click "OK Keep StorageAccess granted" once a month for every website that you use federated login on. There are few auth providers but many more auth consumers.
The 30 day limit is access to the storage API. So presumably the data is still there, you just need to give permission for it to be accessed again. It doesn’t necessarily imply that it just logs you out on 30 days by emptying the state.
Just do a redirect with session as a query parameter (like many OAuth apps do it anyway). Each site can then persist the user session for more than a month.
This seems brilliant! But the solution for SSO concerns me, given most SSO providers (Google, Facebook) are among the main ones partitioning aims to stop from tracking you. By giving Google SSO unpartitioned access, doesn’t that also let google track you anywhere?
My understanding is that if you use Google SSO from xyz.com Google can track you only there and not abc.com. So the partition is only lifted for a single domain.
I like this. After it rolls out, can we quit with those silly GPDR cookie messages? That always seemed like "a social solution for a technical problem", with all the jurisdictional and enforcement problems you would expect from one political body trying to legislate behavior worldwide.
Don't want to be tracked? It's your browser after all, just stop handing the trackers data!
Thanks for this! I'm at a point where I am way more annoyed by cookie banners all over the place than whatever tracking is being done on me that I almost wanted to go back in time before GDPR, now I don't have to :)
NoScript also blocks those fucking "give us your email address!!!!!!!!" popups and other similar trash. It's a hassle to use, and it sucks that it's required, but that's the web we built.
Can privacy focussed browsers that extend Chrome ( Brave, Vivaldi, etc) provide something similar to this, or is it baked deep within Chrome internals, and cannot be overriden?
Brave already does this as far as I know (cross-site cookies are blocked by default). Don't know about Vivaldi, but I would not be surprised if they do.
I'm unconvinced. It's not even possible to whitelist websites for their current "Enhanced Tracking Protection" feature[1]. This smells like another case of over engineering stuff that people never asked for while ignoring what your users ask for.
I understand from the article is they're saying the future way of doing SSO is through an iframe with the Storage Access API?
How does this work with being able to verify the HTTPS URL? How do I know I'm typing my credentials into my legit SSO provider and not a phishing site?
You don't need a shared storage if you do SSO the right way. Just redirect with a session token.
And if the SSO server wants to share state with the other services, like forcing a logout on a specific app, it can always do it on the server side (app backend <-> SSO backend with user token).
Sure and that is how we do SSO (though SameSite=Strict can interfere with that method too).
But if that's the recommended approach, why are they providing a standard route to do SSO via an iframe with the Storage Access API? Does that API have any other valid uses that aren't tracking or SSO related?
If the SSO system is legacy and must use cookies, then to request access for cookies you need to call requestStorageAccess() in a frame hosted on the origin, which will open a prompt asking the user to allow such cookie access.
Can you imagine the next step adtech will take in this arms race? I can imagine adtech giants like Google offering free web hosting and cloud resources to gather most of the Web under a few TLDs. They did it with e-mail, they can do it again with Web.
3 obvious holes:
- Proliferation of dialogs. When you don't know whether a site will suddenly break or not, standard users will be implicitly trained to say yes to all dialogs.
- Domain "homogenizing" (spoofing) services will win. Trackers that offer a widget you can install on your server will win. Facebook et all will still know where they sent you, and will be able to track you server side. If mozilla provide a centralized whitelist, then SSO providers who also provide trackers will win. Essentially, the big players will find a way, the little players (who users weren't worried about anyway) will still lose.
- The web will break. SSO will be broken for a good couple of months on over 50% of websites using it - possibly more. "This only works in Google Chrome" will become more and more popular. Potentially, Firefox doesn't have the market share to make this work.
Those of us who will stick with Firefox regardless are in for a world of pain, and not a lot of gain. I guess it's necessary to move the web on, but the pessimist in me doesn't see that happening any time soon.