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.
Sneaky social engineering in Slack.
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.
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.
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.
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.
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?
This is a terrific approach to tackling cross-site surveillance. I’d love it to be implemented in all browsers. I can imagine Safari implementing this. Chrome …we’ll see.
Favicons are snitches.
This is a very thoughtful and measured response to Alex’s post Platform Adjacency Theory.
Unlike Alex, the author doesn’t fire off cheap shots.
Also, I’m really intrigued by the idea of certificate authorities for hardware APIs.
I spent most of the weekend reading through this and I’ve still barely scratched the surface—a lot of work has gone to the analyses and write-ups!
The sections on accessibility and performance get grimmer each year but the raw numbers on framework adaption are refreshingly perspective-setting.
Collusion between three separate services owned by the same company: the Google search engine, the YouTube website, and the Chrome web browser.
Gosh, this kind of information could be really damaging if there were, say, antitrust proceedings initiated.
In the meantime, use Firefox
Take a look at your smartphone and delete all the apps you don’t really need. For many tasks, you can use a browser on your phone instead of an app.
Privacy-wise, browsers are preferable, because they can’t access as much of your information as an app can.
Tess calls for more precise language—like “site” and “origin”—when talking about browsers and resources:
When talking about web features with security or privacy impact, folks often talk about “first parties” and “third parties”. Everyone sort of knows what we mean when we use these terms, but it turns out that we often mean different things, and what we each think these terms mean usually doesn’t map cleanly onto the technical mechanisms browsers actually use to distinguish different actors for security or privacy purposes.
This was an absolute delight to read! Usually when you read security-related write-ups, the fun comes from the cleverness of the techniques …but this involved nothing cleverer than dev tools. In this instance, the fun is in the telling of the tale.
John weighs in on the clashing priorities of browser vendors.
Imagine if the web never got CSS. Never got a way to style content in sophisticated ways. It’s hard to imagine its rise to prominence in the early 2000s. I’d not be alone in arguing a similar lack of access to the sort of features inherent to the mobile experience that WebKit and the folks at Mozilla have expressed concern about would (not might) largely consign the Web to an increasingly marginal role.
I wrote something recently about telling the story of performance. Sue Loh emphasis the importance of understanding what makes people tick:
Performance engineers need to be an interesting mix of data-lovers and people-whisperers.