wisniewskit
In a nutshell, adding new case-specific web APIs seems to be the likely way forward here. There are proposals floating around like an "is logged in" API, the Federated Credential Management API, and so on.
I'm not sure there's ever going to be a perfect solution for everything, but I would certainly rather have users more informed and empowered about their privacy than they currently are (even if some folks prefer to just "allow all").
I guess we'll just have to wait and see which proposals win out, and in the meantime rely on heuristic-based solutions like Total Cookie Protection to iteratively get us to a better place.
It's currently controlled by setting `network.cookie.cookieBehavior` to `5`. (There is also a similar setting for private browsing mode which is already 5 by default).
Perhaps unsurprisingly, Microsoft logins are the most glaring exceptions right now (Teams, Logins, Office, Live), and we're working with MS to see if we can find an acceptable fix (or work-around while it's fixed). There are also exceptions for github.dev and history.com right now.
It's worth mentioning that these aren't simply exceptions which blanket enable tracking for those sites, it's just to work around specific breakage.
We're also working around some other specific site logins or features breaking, which would not break if sites called the new requestStorageAccess API appropritately. We're using SmartBlock to shim those cases until the sites can fix it themselves.
One is that the login service can request access from the user using a new web API (requestStorageAccess). Another is heuristics which apply when the user interacts with the page in a way which implies a login might be taking place.
In these cases, specific third parties can be granted access to allow the login. There are some more details here: https://developer.mozilla.org/en-US/docs/Web/Privacy/Storage...
Total Cookie Protection is about isolating third party cookies/web storage, without breaking as much of the web as simply blocking third party cookies does.
It would definitely be interesting to compare and contrast the various approaches of different browsers.
It's easy to blame others and excuse yourself, but if I could find the will to get a job at Mozilla to try to help the company to a better end, then why can't some of you folks who always act like you have all the answers?
If we aren't willing or able to do better than Mozilla, then we're stuck with the Mozilla we get, no matter how much we complain about it.
That is, it all depends on the full context. Competition is fine, but not anti-competitive behaviour. I maintain that we have had too much of the latter from Google, and that it is only increasing as folks intentionally look the other way and try to boil arguments away to mere deflections and other apologia.
Google didn't merely "ship a feature someone else didn't". They keep shipping new features as they wish, whether others even agree. They have in fact accelerated that attitude with Project Fugu. Some of them are quite complex or consequential APIs.
They do not deserve a free pass for it because Mozilla once shipped one or two relative minor features before Chrome did, or Apple added some weird CSS visual property for their latest iPhones without consensus. We're talking orders of magnitude of difference here.
The problem isn't who is first to ship. It's the casual disregard for even reaching consensus on the basics before shipping something, the sheer rate of output, the interop issues left in the wake, and the anti-competitive tactics being applied. Those are not "hypotheticals" in the slightest.
What is hypothetical is acting like anyone else could just magically compete on those terms. Microsoft couldn't keep up with them. Opera couldn't. No new engine has even come close to breaking into a general market yet, though a couple are feverishly trying.
Is that really ok with us? If so, then let's just be honest. Let's just say "new APIs are more important to us than engine diversity, and we don't mind Google being as evil as possible to kill the other engines off." As a webcompat worker, I'd love to see that honesty.
Google did not have to publicly ship their pre-standard experimental "v0" web components implementation so early in Chrome. They chose to do so regardless of what other browser vendors expressed.
Likewise they did not have to make YouTube use them so soon, thus forcing other browsers to rely on a polyfill that could not feasibly be made remotely performant compared to just implementing web components more quickly, wink wink.
They chose to do these things the way they did. They wanted to ship it on their timeline, and to hell with what other browsers wanted to spend time on first instead. They wanted to look like they were heroes for pushing the web forward, while in reality they were just holding other vendors and APIs back to get the one they valued the most done first, no matter how much of a mess they caused in the process (the transition from v0 to v1 was hardly quick or painless). And that's just web components.
When is the last time you saw Firefox ship such a major web API in such a non-final and un-vetted state, and then use one of the largest web properties on Earth to get others to prioritize it as they wished? Or even Apple, for that matter?
It's flat out ridiculous to try equating the vendors in this manner. They don't have the market dominance or even the same force of apologists burying the lede on their bad behaviour.
I'm sure the other browsers also have their own Project Fugus underway too, where they're just shipping a slurry of new APIs regardless of whether anyone else will ever implement them? Or is that the others' fault somehow too, because they should also be trying to fragment the web as much as possible as quickly as possible?
If we collectively just want Chromium to be the only engine because we value rapidly iterating on new APIs more than anything, then let's at least be honest about it.
The folks who actually care and work on non-Chrome browsers have been telling us for a decade that Google is not being a good faith player, and is creating an obvious browser engine mono culture. And instead of listening to them, you ignore them to defend Google instead.
You're the one who should get out of here, and educate yourself on this stuff first before you talk big about it. Go find out just what a mess WebRTC has been thanks to Google and its ever-shapeshifting "plan B" (and not just from Google's point of view). It helped kill two major browser engines already, and it certainly wasn't because they didn't try to work with Google to figure it out, or spend a lot of time trying to reverse-engineer it as it changed, or even just trying to import enough of Chromium into their own browsers to ship "plan B" themselves after Google remained silent.
And while I'd love to help you with your pet bugs, including such basic web functionality as "offloading large chunks of image processing to a web worker", I'm here diagnosing live web sites to find that Chrome shipped `event.path` before it was standardized, or haven't fixed three year old bugs with `text-underline-offset`: things that are breaking such hyper-advanced and unimportant functionality on the web as clicking on links and underlining text properly.
So tell me again how I'm wrong and Google's bugs don't affect other browsers. And how it's my fault that Google seems to ignore interop bug reports until they become issues on live pages, and then conveniently say "well, the web relies on this now, so you change the standards and your own browsers to follow suit now"? I guess I need to be flawless myself before I have any right to complain about their bad behaviour?
Do go on. Tell me more about your theories about what I and other Mozilla folks do with our time, and how Google and its defenders aren't making it harder for us to do what we'd really rather be doing for our users.
For ten years now we've been watching non-Chromium browser engines die off while complaining about this, with no new one able to really compete because of the gigantic web API footprint Chrome has championed.
But yeah, go on telling me how some UI changes in Firefox are responsible for all that is wrong with Firefox. I'm sure all of the users still who still can't use Chrome-WebRTC apps in Firefox care about that more.
I personally spend most of my time figuring out the Chrome-specific quirks that pages rely on which are non-standard, and the Chrome devs almost never fix before conjuring up some new, ill-defined "standard" that they ship to production before others have even had a chance to figure out the last three.
It's maddening, especially when you look at Google's not-so-sterling track record just with major new "standards" like Web Components, WebRTC and Pointer/Touch events, not to mention how often they ignore Chrome's spec bugs until the web is reliant on them, and other vendors have to change their behavior and the spec to match them. Folks always seem to ignore all of the trouble Google causes, and just think "ooh, shiny new toy! Google good!"
Just imagine trying to implement all of those "standards" while Google is constantly changing them, under-documenting everything, have no reference implementation aside from the one they ship that's deeply tied to Chrome, and expect you to work on their time frame. All while not fixing bugs in the last two new APIs they pushed out, while pushing out two more at the same time. You wonder if they're doing it on purpose so no matter what the "standards" say, they just wait for the web to become reliant on their bugs, and then everyone else has to figure the whole mess out for them, like glorified janitors.
And then you look at the backlog of things you'd like to have fixed instead of figuring out the latest interop issue with some quirk that has a crbug open for three years, and the new privacy APIs and features you'd like to push and you start to feel a bit burned out. So you hop onto HN only to see yet another comment like yours, acting like we're doing nothing at all except "chasing shiny baubles". It's enough to make me wonder whether people like you actually care about the web at all or just want more half-broken new APIs to complain about.
I'm also confused as to why you think an executive search would surely find a better candidate when it clearly hasn't. We can't just pretend the problem away. If we can't find a better candidate than the woman who ran MoCo when it was founded, then we're grasping at straws.
It also doesn't matter whether we want to believe Eich could have done better. He didn't, and he isn't going to be their CEO now. So I'd rather not pick at old wounds too much.
I think Eich was actually lucky, in a twisted way. It's not like he managed to turn their fortunes around while he was their CTO for so long. He wasn't some powerless underdog who would have gained special superpowers as their CEO.
Even if he had avoided controversy to become their CEO, he would almost certainly have just been the one we're scapegoating now instead of Baker. She was our angle when Mozilla was founded and when Microsoft needed an antitrust spanking, and now she's uor devil.
Right now a site could disingenuously call the relevant Facebook SDK API to unblock the Facebook resources listed here, and only on that site: https://searchfox.org/mozilla-central/source/browser/extensi...
I'm not too sure why that would be worthwhile as an attack, though. If you have anything in mind that would make it so, please let me know.
In the meantime, I'm working on a way to further tighten this a bit so the unblocking will only happen if a popup is successfully opened (so that at least if the popup blocker kicks in, nothing will happen unless the user intentionally allows that popup). I'm not 100% sure if that will work well, but I hope so.
Site compatibility is a surprisingly broad topic that doesn't tend to fit neatly into our ideal vision of the web.
SmartBlock also contains special logic for Google Analytics, Google Publisher Tags, and other trackers that cause sites to break when blocked. It's not meant for their benefit, but the user's.
In fact all browsers have special web-compatibility interventions for sites which don't work correctly in them. Even Chrome. And sometimes even for major sites and services, especially when it comes to anti-tracking features.