Monday, September 19th, 2022
Tuesday, September 6th, 2022
The obvious answer to why you should build a website that doesn’t need
jsis… because some people don’t use
js. But how many?!
Thursday, August 11th, 2022
Adrian brings an excellent historical perspective to the horrifying behaviour of Facebook’s in-app browsers:
Somewhere along the way, despite a reasonably strong anti-framing culture, framing moved from being a huge no-no to a huge shrug. In a web context, it’s maligned; in a native app context, it’s totally ignored.
Yup, frames are back—but this time they’re in native apps—with all their shocking security implications:
By the way, this also explains that when you try browsing the web in an actual web browser on your mobile device, every second website shoves a banner in your face saying “download our app.” Browsers offer users some protection. In-app webviews offer users nothing but exploitation.
Wednesday, June 1st, 2022
A well-written evisceration of cryptobollocks signed by Bruce Scheier, Tim Bray, Molly White, Cory Doctorow, and more.
If you’re a concerned US computer scientist, technologist or developer, you’ve got till June 10th to add your signature before this is submitted to congress.
Thursday, February 3rd, 2022
Remember when I said you should avoid third-party dependencies?
Saturday, January 8th, 2022
Wednesday, December 15th, 2021
Thursday, December 9th, 2021
I’d like to tell you something not to do to make your website better. Don’t add any third-party scripts to your site.
That may sound extreme, but at one time it would’ve been common sense. On today’s modern web it sounds like advice from a tinfoil-hat wearing conspiracy nut. But just because I’m paranoid doesn’t mean they’re not out to get your user’s data.
All I’m asking is that we treat third-party scripts like third-party cookies. They were a mistake.
Browsers are now beginning to block third-party cookies. Chrome is dragging its heels because the same company that makes the browser also runs an advertising business. But even they can’t resist the tide. Third-party cookies are used almost exclusively for tracking. That was never the plan.
In the beginning, there was no state on the web. A client requested a resource from a server. The server responded. Then they both promptly forgot about it. That made it hard to build shopping carts or log-ins. That’s why we got cookies.
In hindsight, cookies should’ve been limited to a same-origin policy from day one. That would’ve solved the problems of authentication and commerce without opening up a huge security hole that has been exploited to track people as they moved from one website to another. The web went from having no state to having too much.
Just take a minute to consider the implications of that: any third-party script on your site is allowing someone else to execute code on your web pages. That’s astonishingly unsafe.
It gets better. One of the pieces of code that this invited intruder can execute is the ability to pull in other third-party scripts.
You might think there’s no harm in adding that one little analytics script. Or that one little Google Tag Manager snippet. It’s such a small piece of code, after all. But in doing that, you’ve handed over your keys to a stranger. And now they’re welcoming in all their shady acquaintances.
Request Map Generator is a great tool for visualizing the resources being loaded on any web page. Try pasting in the URL of an interesting article from a news outlet or magazine that someone sent you recently. Then marvel at the sheer size and number of third-party scripts that sneak in via one tiny
script element on the original page.
That’s why I recommend that the one thing people can do to make their website better is to not add third-party scripts.
Easier said than done, right? Especially if you’re working on a site that currently relies on third-party tracking for its business model. But that exploitative business model won’t change unless people like us are willing to engage in a campaign of passive resistance.
I know, I know. If you refuse to add that third-party script, your boss will probably say, “Fine, I’ll get someone else to do it. Also, you’re fired.”
This tactic will only work if everyone agrees to do what’s right. We need to have one another’s backs. We need to support one another. The way people support one another in the workplace is through a union.
So I think I’d like to change my answer to the question that’s been posed.
The one thing people can do to make their website better is to unionize.
Saturday, December 4th, 2021
Chris is doing another end-of-year roundup. This time the prompt is “What is one thing people can do to make their website bettter?”
This is my response.
I’d like to tell you something not to do to make your website better. Don’t add any third-party scripts to your site.
Tuesday, October 26th, 2021
Sneaky social engineering in Slack.
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
At some point, you won’t be able to visit the first web page ever published without first clicking through a full-page warning injected by your web browser:
Chrome will offer HTTPS-First Mode, which will attempt to upgrade all page loads to HTTPS and display a full-page warning before loading sites that don’t support it. Based on ecosystem feedback, we’ll explore making HTTPS-First mode the default for all users in the future.
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.
Tuesday, August 3rd, 2021
Facebook Container for Firefox
Firefox has a nifty extension—made by Mozilla—called Facebook Container. It does two things.
First of all, it sandboxes any of your activity while you’re on the facebook.com domain. The tab you’re in is isolated from all others.
Secondly, when you visit a site that loads a tracker from Facebook, the extension alerts you to its presence. For example, if a page has a share widget that would post to Facebook, a little fence icon appears over the widget warning you that Facebook will be able to track that activity.
It’s a nifty extension that I’ve been using for quite a while. Except now it’s gone completely haywire. That little fence icon is appearing all over the web wherever there’s a form with an email input. See, for example, the newsletter sign-up form in the footer of the Clearleft site. It’s happening on forms over on The Session too despite the rigourous-bordering-on-paranoid security restrictions in place there.
Hovering over the fence icon displays this text:
If you use your real email address here, Facebook may be able to track you.
That is, of course, false. It’s also really damaging. One of the worst things that you can do in the security space is to cry wolf. If a concerned user is told that they can ignore that warning, you’re lessening the impact of all warnings, even serious legitimate ones.
Sometimes false positives are an acceptable price to pay for overall increased security, but in this case, the rate of false positives can only decrease trust.
I tried to find out how to submit a bug report about this but I couldn’t work it out (and I certainly don’t want to file a bug report in a review) so I’m writing this in the hopes that somebody at Mozilla sees it.
What’s really worrying is that this might not be considered a bug. The release notes for the version of the extension that came out last week say:
Email fields will now show a prompt, alerting users about how Facebook can track users by their email address.
Like …all email fields? That’s ridiculous!
I thought the issue might’ve been fixed in the latest release that came out yesterday. The release notes say:
This release addresses fixes a issue from our last release – the email field prompt now only displays on sites where Facebook resources have been blocked.
But the behaviour is unfortunately still there, even on sites like The Session or Clearleft that wouldn’t touch Facebook resources with a barge pole. The fence icon continues to pop up all over the web.
I hope this gets sorted soon. I like the Facebook Container extension and I’d like to be able to recommend it to other people. Right now I’d recommed the opposite—don’t install this extension while it’s behaving so overzealously. If the current behaviour continues, I’ll be uninstalling this extension myself.
Update: It looks like a fix is being rolled out. Fingers crossed!
Tuesday, June 29th, 2021
If you download Safari Technology Preview you can test drive features that are on their way in Safari 15. One of those features, announced at Apple’s World Wide Developer Conference, is coloured browser chrome via support for the
meta value of “theme-color.” Chrome on Android has supported this for a while but I believe Safari is the first desktop browser to add support. They’ve also added support for the
media attribute on that
meta element to handle “prefers-color-scheme.”
This is all very welcome, although it does remind me a bit of when Internet Explorer came out with the ability to make coloured scrollbars. I mean, they’re nice features’n’all, but maybe not the most pressing? Safari is still refusing to acknowledge progressive web apps.
That’s not quite true. In her WWDC video Jen demonstrates how you can add a progressive web app like Resilient Web Design to your home screen. I’m chuffed that my little web book made an appearance, but when you see how you add a site to your home screen in iOS, it’s somewhat depressing.
The steps to add a website to your home screen are:
- Tap the “share” icon. It’s not labelled “share.” It’s a square with an arrow coming out of the top of it.
- A drawer pops up. The option to “add to home screen” is nowhere to be seen. You have to pull the drawer up further to see the hidden options.
- Now you must find “add to home screen” in the list
- Add to Reading List
- Add Bookmark
- Add to Favourites
- Find on Page
- Add to Home Screen
It reminds of this exchange in The Hitchhiker’s Guide To The Galaxy:
“You hadn’t exactly gone out of your way to call attention to them had you? I mean like actually telling anyone or anything.”
“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a torch.”
“Ah, well the lights had probably gone.”
“So had the stairs.”
“But look you found the notice didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of The Leopard.’”
Safari’s current “support” for adding progressive web apps to the home screen feels like the minimum possible …just enough to use it as a legal argument if you happen to be litigated against for having a monopoly on app distribution. “Hey, you can always make a web app!” It’s true in theory. In practice it’s …suboptimal, to put it mildly.
It’s a little bit weird that this stylistic information is handled by HTML rather than CSS. It’s similar to the
viewport value in that sense. I always that the plan was to migrate that to CSS at some point, but here we are a decade later and it’s still very much part of our boilerplate markup.
Some people have remarked that the coloured browser chrome can make the URL bar look like part of the site so people might expect it to operate like a site-specific search.
I also wonder if it might blur “the line of death”; that point in the UI where the browser chrome ends and the website begins. Does the unified colour make it easier to spoof browser UI?
Probably not. You can already kind of spoof browser UI by using the right shade of grey. Although the removal any kind of actual line in Safari does give me pause for thought.
I tend not to think of security implications like this by default. My first thought tends to be more about how I can use the feature. It’s only after a while that I think about how bad actors might abuse the same feature. I should probably try to narrow the gap between those thoughts.
Saturday, April 3rd, 2021
This responds to your Freedom of Information Act (FOIA) request, which was received by this office on 5 February 2016 for “A digital/electronic copy of the NSA old security posters from the 1950s and 1960s.”
The graphic design is …um, mixed.
Monday, March 29th, 2021
Just over a year ago, I pondered some default browser behaviours and how they might be updated.
The first one is happening: Chrome is going to assume
https before checking for
Now what about the other default behaviour that’s almost 15 years old now? When might a viewport width value of
device-width become the default?