Firefox as the asphyxiating canary in the coalmine of the web.
Tuesday, January 11th, 2022
Saturday, January 8th, 2022
This is something I bump against over and over again: so-called evergreen browsers that can’t actually be updated because of operating system limits.
From what I could gather, the version of Chrome was tied to ChromeOS which couldn’t be updated because of the hardware. No new ChromeOS meant no new Chrome which meant stuck at version 76.
But what about the iPad? I discovered that my Mom’s iPad was a 1st generation iPad Air. Apple stopped supporting that device in iOS 12, which means it was stuck with whatever version of Safari last shipped with iOS 12.
So I had two older browsers that couldn’t be updated. It was device obsolescence because you couldn’t install the latest browser.
Websites stop working and the only solution is to buy a whole new device.
Wednesday, December 1st, 2021
Prompted by my talk, The State Of The Web, Brian zooms out to get some perspective on how browser power is consolidated.
The web is made of clients and servers. There’s a huge amount of diversity in the server space but there’s very little diversity when it comes to clients because making a browser has become so complex and expensive.
But Brian hopes that this complexity and expense could be distributed amongst a large amount of smaller players.
10 companies agreeing to invest $10k apiece to advance and maintain some area of shared interest is every bit as useful as 1 agreeing to invest $100k generally. In fact, maybe it’s more representative.
We believe that there is a very long tail of increasingly smaller companies who could do something, if only they coordinated to fund it together. The further we stretch this out, the more sources we enable, the more its potential adds up.
Tuesday, November 9th, 2021
Forgive me for linking to The Rag, but for completeness’s sake, it would be remiss of me not to point out more coverage of “that” question I asked:
It was to the company’s credit that it chose to take the question posed by Clearleft’s Jeremy Keith, well known in the web standards community and who was briefly on the advisory committee for AMP (Accelerated Mobile Pages), before resigning saying that “it has become clear to me that AMP remains a Google product.” AMP has been in the news of late with a lawsuit alleging Google deliberately throttled ad load times to promote it, and Keith asked: “Given the court proceedings against AMP, why should anyone trust FLOC or any other Google initiatives ostensibly focused on privacy?”
Sunday, November 7th, 2021
An article by Sarah Gooding, prompted by the question I asked at Chrome Dev Summit:
Jeremy Keith’s question referencing the AMP allegations in the recently unredacted antitrust complaint against Google was extremely unlikely to receive an adequate response from the Chrome Leadership team, but the mere act of asking is a public reminder of the trust Google has willfully eroded in pushing AMP on publishers.
Thursday, November 4th, 2021
What I want instead is an anarchist web browser.
Throw away everything and start again and focus intensely about what people care about when it comes to the web.
Writing on web.dev
Chrome Dev Summit kicked off yesterday. The opening keynote had its usual share of announcements.
There was quite a bit of talk about privacy, which sounds good in theory, but then we were told that Google would be partnering with “industry stakeholders.” That’s probably code for the kind of ad-tech sharks that have been making a concerted effort to infest W3C groups. Beware.
But once Una was on-screen, the topics shifted to the kind of design and development updates that don’t have sinister overtones.
My favourite moment was when Una said:
We’re also partnering with Jeremy Keith of Clearleft to launch Learn Responsive Design on web.dev. This is a free online course with everything you need to know about designing for the new responsive web of today.
This is what’s been keeping me busy for the past few months (and for the next month or so too). I’ve been writing fifteen pieces—or “modules”—on modern responsive web design. One third of them are available now at web.dev/learn/design:
The rest are on their way: typography, responsive images, theming, UI patterns, and more.
I’ve been enjoying this process. It’s hard work that requires me to dive deep into the nitty-gritty details of lots of different techniques and technologies, but that can be quite rewarding. As is often said, if you truly want to understand something, teach it.
Oh, and I made one more appearance at the Chrome Dev Summit. During the “Ask Me Anything” section, quizmaster Una asked the panelists a question from me:
Given the court proceedings against AMP, why should anyone trust FLOC or any other Google initiatives ostensibly focused on privacy?
(Thanks to Jake for helping craft the question into a form that could make it past the legal department but still retain its spiciness.)
The question got a response. I wouldn’t say it got an answer. My verdict remains:
I’m not sure that Google Chrome can be considered a user agent.
The fundamental issue is that you’ve got a single company that’s the market leader in web search, the market leader in web advertising, and the market leader in web browsers. I honestly believe all three would function better—and more honestly—if they were separate entities.
Monopolies aren’t just damaging for customers. They’re damaging for the monopoly too. I’d love to see Google Chrome compete on being a great web browser without having to also balance the needs of surveillance-based advertising.
Tuesday, October 26th, 2021
At first glance, this looks like a terrible idea. But the key is in the implementation. In this case, the implementation is truly awful.
The section on detecting “auto dark theme” is, as far as I can tell, not intended as a joke.
Mind you, this could all be a galaxy-brain idea to encourage more developers to provide their own dark mode styles. (In much the same way that AMP was supposed to encourage better performance.)
Friday, August 20th, 2021
…you would be forgiven if you saw an API where a feature went from green (supported) to red (unsupported) and you thought: is the browser being deprecated?
the onus is not on web developers to keep track of older features in danger of being deprecated. That’s on the browser makers. I sincerely hope we’re not expected to consult a site called canistilluse.com.
It’s weirdly gratifying to see a hastily-written sarcastic quip tuned into something real.
Wednesday, August 18th, 2021
Monday, August 16th, 2021
After I jotted down some quick thoughts last week on the disastrous way that Google Chrome rolled out a breaking change, others have posted more measured and incisive takes:
- Chris Ferdinandi wrote Google vs. the web,
- Rich Harris wrote Stay alert,
- Jim Nielsen wrote I Want To Confirm a Prompt That We Stay Alert
In fairness to Google, the Chrome team is receiving the brunt of the criticism because they were the first movers. Mozilla and Apple are on baord with making the same breaking change, but Google is taking the lead on this.
As I said in my piece, my issue was less to do with whether
alert() should be deprecated but more to do with how it was done, and the woeful lack of communication.
Thinking about it some more, I realised that what bothered me was the lack of an upgrade path. Considering that
dialog is nowhere near ready for use, it seems awfully cart-before-horse-putting to first remove a feature and then figure out a replacement.
I was chatting to Amber recently and realised that there was a very different example of a feature being deprecated in web browsers…
We were talking about the
KeyboardEvent.keycode property. Did you get the memo that it’s deprecated?
But fear not! You can use the
KeyboardEvent.code property instead. It’s much nicer to use too. You don’t need to look up a table of numbers to figure out how to refer to a specific key on the keyboard—you use its actual value instead.
So the way that change was communicated was:
Hey, you really shouldn’t use the
keycodeproperty. Here’s a better alternative.
But with the more recently change, the communication was more like:
Hey, you really shouldn’t use
alert(). So go fuck yourself.
Tuesday, August 10th, 2021
It’s not just a story about unloved APIs, it’s a story about power, standards design, and who owns the platform — and it makes me afraid for the future of the web.
A thoughtful, considered post by Rich Harris on the whole ballyhoo with
alert and its ilk:
For all its flaws, the web is generally agreed to be a stable platform, where investments made today will stand the test of time. A world in which websites are treated as inherently transient objects, where APIs we commonly rely on today could be cast aside as unwanted baggage by tomorrow’s spec wranglers, is a world in which the web has already lost.
Monday, August 9th, 2021
Believe it or not, I generally am a fan of Google and think they do a good job of pushing the web forward. I also think it’s appropriate to waggle fingers when I see problems and request they do better. “Better” here means way more developer and user outreach to spell out the situation, way more conversation about the potential implications and transition ideas, and way more openness to bending the course ahead.
With any changes to the platform, but especially breaking ones, communication and feedback on how this will impact people who actually build things with the web is super important, and that was not done here.
Chris has written a thoughtful reflection on last week’s brouhaha around
alert being deprecated in Chrome. The way that the “developer relations” folks at Google handled feedback was less than ideal.
I reached out to one of the Google Chrome developer advocates I know to see if I could learn more. It did not go well.
Sunday, August 8th, 2021
’Sfunny, when I look back at older journal entries they’re often written out of frustration, usually when something in the dev world is bugging me. But when I look back at all the links I’ve bookmarked the vibe is much more enthusiastic, like I’m excitedly pointing at something and saying “Check this out!” I feel like sentiment analyses of those two sections of my site would yield two different results.
My journal entries have been even more specifically negative of late. I’ve been bitchin’ and moanin’ about web browsers. But at least I’m an equal-opportunities bitcher and moaner.
- Mozilla, I complained about your Facebook Container extension for Firefox.
- Apple, I complained about the ridiculous way Safari’s update cycle is tied to operating system.
- Google, I complained about the way a breaking change was rolled out in Chrome (and the implications for future breaking changes).
- Microsoft, you got off lightly. But please consider any of my criticisms of Chrome to apply to Edge too, seeing as they’re basically the same now.
I wish my journal weren’t so negative, but my mithering behaviour has been been encouraged. On more than one occasion, someone I know at a browser company has taken me aside to let me know that I should blog about any complaints I might have with their browser. It sounds counterintuitive, I know. But these blog posts can give engineers some ammunition to get those issues prioritised and fixed.
So my message to you is this: if there’s something about a web browser that you’re not happy with (or, indeed, if there’s something you’re really happy with), take the time to write it down and publish it.
Publish it on your website. You could post your gripes on Twitter but whinging on Jack’s website is just pissing in the wind. And I suspect you also might put a bit more thought into a blog post on your own site.
I know it’s a cliché to say that browser makers want to hear from developers—and I’m often cynical about it myself—but they really do want to know what we think. Share your thoughts. I’ll probably end up linking to what you write.
Friday, August 6th, 2021
There was quite a kerfuffle recently about a feature being removed from Google Chrome. To be honest, the details don’t really matter for the point I want to make, but for the record, this was about removing
confirm dialogs from cross-origin iframes (and eventually everywhere else too).
It’s always tricky to remove a long-established feature from web browsers, but in this case there were significant security and performance reasons. The problem was how the change was communicated. It kind of wasn’t. So the first that people found out about it about was when things suddenly stopped working (like CodePen embeds).
The Chrome team responded quickly and the change has now been pushed back to next year. Hopefully there will be significant communication before that to let site owners know about the upcoming breakage.
So all’s well that ends well and we’ve all learned a valuable lesson about the importance of communication.
Or have we?
While this was going on, Emily Stark tweeted a more general point about breakage on the web:
Breaking changes happen often on the web, and as a developer it’s good practice to test against early release channels of major browsers to learn about any compatibility issues upfront.
Yikes! To me, this appears wrong on almost every level.
First of all, breaking changes don’t happen often on the web. They are—and should be—rare. If that were to change, the web would suffer massively in terms of predictability.
Secondly, the onus is not on web developers to keep track of older features in danger of being deprecated. That’s on the browser makers. I sincerely hope we’re not expected to consult a site called
No, no, no, no! One of the best things about developing for the web is that, as a rule, browsers don’t break old code. Expecting every website and application to have an active team of developers maintaining it at all times is not how the web should work!
Most organizations and individuals do not have the resources to properly test and debug their website against Chrome canary every six weeks. Anybody who published a spec-compliant website should be able to trust that it will keep working.
This statement seriously undermines my trust in Google as steward for the web platform. When did we go from “never break the web” to “yes we will break the web often and you should be prepared for it”?!
It’s worth pointing out that the original tweet was not an official Google announcement. As Emily says right there on her Twitter account:
Opinions are my own.
Still, I was shaken to see such a cavalier attitude towards breaking changes on the World Wide Web. I know that removing dangerous old features is inevitable, but it should also be exceptional. It should not be taken lightly, and it should certainly not be expected to be an everyday part of web development.
It’s almost miraculous that I can visit the first web page ever published in a modern web browser and it still works. Let’s not become desensitised to how magical that is. I know it’s hard work to push the web forward, constantly add new features, while also maintaining backward compatibility, but it sure is worth it! We have collectively banked three decades worth of trust in the web as a stable place to build a home. Let’s not blow it.
If you published a website ten or twenty years ago, and you didn’t use any proprietary technology but only stuck to web standards, you should rightly expect that site to still work today …and still work ten and twenty years from now.
There was something else that bothered me about that tweet and it’s not something that I saw mentioned in the responses. There was an unspoken assumption that the web is built by professional web developers. That gave me a cold chill.
But the common narrative in the web development community—and amongst browser makers too apparently—is that web development has become more complex; so complex, in fact, that only an elite priesthood are capable of making websites today.
You can choose to make it really complicated. Convince yourself that “the modern web” is inherently complex and convoluted. But then look at what makes it complex and convoluted: toolchains, build tools, pipelines, frameworks, libraries, and abstractions. Please try to remember that none of those things are required to make a website.
This is for everyone. Not just for everyone to consume, but for everyone to make.
Wednesday, July 7th, 2021
We’ve enjoyed a relatively long period when we didn’t have to think about which browser to use. Alas, that period is ending: I must now keep Chrome running all the time, much like I needed that PC in the early 2000s.
Wednesday, April 21st, 2021
Get the FLoC out
I’ve always liked the way that web browsers are called “user agents” in the world of web standards. It’s such a succinct summation of what browsers are for, or more accurately who browsers are for. Users.
The term makes sense when you consider that the internet is for end users. That’s not to be taken for granted. This assertion is now enshrined in the Internet Engineering Task Force’s RFC 8890—like Magna Carta for the network age. It’s also a great example of prioritisation in a design principle:
When there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users.
So when a web browser—ostensibly an agent for the user—prioritises user-hostile third parties, we get upset.
Google Chrome—ostensibly an agent for the user—is running an origin trial for Federated Learning of Cohorts (FLoC). This is not a technology that serves the end user. It is a technology that serves third parties who want to target end users. The most common use case is behavioural advertising, but targetting could be applied for more nefarious purposes.
The Electronic Frontier Foundation wrote an explainer last month: Google Is Testing Its Controversial New Ad Targeting Tech in Millions of Browsers. Here’s What We Know.
Let’s back up a minute and look at why this is happening. End users are routinely targeted today (for behavioural advertising and other use cases) through third-party cookies. Some user agents like Apple’s Safari and Mozilla’s Firefox are stamping down on this, disabling third party cookies by default.
Seeing which way the wind is blowing, Google’s Chrome browser will also disable third-party cookies at some time in the future (they’re waiting to shut that barn door until the fire is good’n’raging). But Google isn’t just in the browser business. Google is also in the ad tech business. So they still want to advertisers to be able to target end users.
Yes, this is quite the cognitive dissonance: one part of the business is building a user agent while a different part of the company is working on ways of tracking end users. It’s almost as if one company shouldn’t simultaneously be the market leader in three separate industries: search, advertising, and web browsing. (Seriously though, I honestly think Google’s search engine would get better if it were split off from the parent company, and I think that Google’s web browser would also get better if it were a separate enterprise.)
Anyway, one possible way of tracking users without technically tracking individual users is to assign them to buckets, or cohorts of interest based on their browsing habits. Does that make you feel safer? Me neither.
That’s what Google is testing with the origin trial of FLoC.
If you, as an end user, don’t wish to be experimented on like this, there are a few things you can do:
- Don’t use Chrome. No other web browser is participating in this experiment. I recommend Firefox.
- If you want to continue to use Chrome, install the Duck Duck Go Chrome extension.
- Alternatively, if you manually disable third-party cookies, your Chrome browser won’t be included in the experiment.
- Or you could move to Europe. The origin trial won’t be enabled for users in the European Union, which is coincidentally where GDPR applies.
That last decision is interesting. On the one hand, the origin trial is supposed to be on a small scale, hence the lack of European countries. On the other hand, the origin trial is “opt out” instead of “opt in” so that they can gather a big enough data set. Weird.
The plan is that if and when FLoC launches, websites would have to opt in to it. And when I say “plan”, I mean “best guess.”
I, for one, am filled with confidence that Google would never pull a bait-and-switch with their technologies.
In the meantime, if you’re a website owner, you have to opt your website out of the origin trial. You can do this by sending a server header. A
meta element won’t do the trick, I’m afraid.
I’ve done it for my sites, which are served using Apache. I’ve got this in my
<IfModule mod_headers.c> Header always set Permissions-Policy "interest-cohort=()" </IfModule>
If you don’t have access to your server, tough luck. But if your site runs on Wordpress, there’s a proposal to opt out of FLoC by default.
Interestingly, none of the Chrome devs that I follow are saying anything about FLoC. They’re usually quite chatty about proposals for potential standards, but I suspect that this one might be embarrassing for them. It was a similar situation with AMP. In that case, Google abused its monopoly position in search to blackmail publishers into using Google’s format. Now Google’s monopoly in advertising is compromising the integrity of its browser. In both cases, it makes it hard for Chrome devs claiming to have the web’s best interests at heart.
But one of the advantages of having a huge share of the browser market is that Chrome can just plough ahead and unilaterily implement whatever it wants even if there’s no consensus from other browser makers. So that’s what Google is doing with FLoC. But their justification for doing this doesn’t really work unless other browsers play along.
- Third-party cookies are on their way out so advertisers will no longer be able to use that technology to target users.
- If we don’t provide an alternative, advertisers and other third parties will use fingerprinting, which we all agree is very bad.
- So let’s implement Federated Learning of Cohorts so that advertisers won’t use fingerprinting.
The problem is with step three. The theory is that if FLoC gives third parties what they need, then they won’t reach for fingerprinting. Even if there were any validity to that hypothesis, the only chance it has of working is if every browser joins in with FLoC. Otherwise ad tech companies are leaving money on the table. Can you seriously imagine third parties deciding that they just won’t target iPhone or iPad users any more? Remember that Safari is the only real browser on iOS so unless FLoC is implemented by Apple, third parties can’t reach those people …unless those third parties use fingerprinting instead.
Google have set up a situation where it looks like FLoC is going head-to-head with fingerprinting. But if FLoC becomes a reality, it won’t be instead of fingerprinting, it will be in addition to fingerprinting.
Google is quite right to point out that fingerprinting is A Very Bad Thing. But their concerns about fingerprinting sound very hollow when you see that Chrome is pushing ahead and implementing a raft of browser APIs that other browser makers quite rightly point out enable more fingerprinting: Battery Status, Proximity Sensor, Ambient Light Sensor and so on.
When it comes to those APIs, the message from Google is that fingerprinting is a solveable problem.
But when it comes to third party tracking, the message from Google is that fingerprinting is inevitable and so we must provide an alternative.
Which one is it?
Google’s flimsy logic for why FLoC is supposedly good for end users just doesn’t hold up. If they were honest and said that it’s to maintain the status quo of the ad tech industry, it would make much more sense.
The flaw in Google’s reasoning is the fundamental idea that tracking is necessary for advertising. That’s simply not true. Sacrificing user privacy is fundamental to behavioural advertising …but behavioural advertising is not the only kind of advertising. It isn’t even a very good kind of advertising.
FLoC seems to be Google’s way of saving a dying business. They are trying to keep targeted ads going by making them more “privacy-friendly” and “anonymous”. But behavioral profiling and targeted advertisement is not compatible with a privacy-respecting web.
What’s striking is that the very monopolies that make Google and Facebook the leaders in behavioural advertising would also make them the leaders in contextual advertising. Almost everyone uses Google’s search engine. Almost everyone uses Facebook’s social network. An advertising model based on what you’re currently looking at would keep Google and Facebook in their dominant positions.
Google made their first many billions exclusively on contextual advertising. Google now prefers to push the message that behavioral advertising based on personal data collection is superior but there is simply no trustworthy evidence to that.
I sincerely hope that Chrome will align with Safari, Firefox, Vivaldi, Brave, Edge and every other web browser. Everyone already agrees that fingerprinting is the real enemy. Imagine the combined brainpower that could be brought to bear on that problem if all browsers made user privacy a priority.
Until that day, I’m not sure that Google Chrome can be considered a user agent.
Monday, April 5th, 2021
Google Is Testing Its Controversial New Ad Targeting Tech in Millions of Browsers. Here’s What We Know. | Electronic Frontier Foundation
Following on from the piece they ran called Google’s FLoC Is a Terrible Idea, the EFF now have the details of the origin trial and it’s even worse than what was originally planned.
I strongly encourage you to use a privacy-preserving browser like Firefox or Safari.
Monday, March 29th, 2021
Good to see Google, Mozilla, and Apple collaborating on fixing cross-browser CSS compatability issues:
- position: sticky
You can track progress here.