At Codebar the other night, I was doing an intro chat with some beginners. At one point I touched on DNS. This explanation is great for detailing what’s going on under the hood.
Transcript of Tim Berners-Lee’s talk to the LCS 35th Anniversary celebrations, Cambridge Massachusetts, 1999/April/14
Twenty years ago—when the web was just a decade old—Tim Berners-Lee gave this talk, looking backwards and forwards.
For me the fundamental Web is the Web of people. It’s not the Web of machines talking to each other; it’s not the network of machines talking to each other. It’s not the Web of documents. Remember when machines talked to each other over some protocol, two machines are talking on behalf of two people.
HTTPS session identifiers can be disabled in Mozilla products manually by setting ‘security.ssl.disablesessionidentifiers’ in about:config.
A great post by Tim following on from the post by Eric I linked to last week.
Is a secure site you can’t access better than an insecure one you can?
He rightly points out that security without performance is exlusionary.
…we’ve made a move to increase the security of the web by doing everything we can to get everything running over HTTPS. It’s undeniably a vital move to make. However this combination—poor performance but good security—now ends up making the web inaccessible to many.
Security. Performance. Accessibility. All three matter.
This is a heartbreaking observation by Eric. He’s not anti-HTTPS by any stretch, but he is pointing out that caching servers become a thing of the past on a more secure web.
Can we do anything? For users of up-to-date browsers, yes: service workers create a “good” man in the middle that sidesteps the HTTPS problem, so far as I understand. So if you’re serving content over HTTPS, creating a service worker should be one of your top priorities right now, even if it’s just to do straightforward local caching and nothing fancier.
What an excellent question! And what an excellent bit of sleuthing to get to the bottom of it. This is like linguistic spelunking on the World Wide Web.
Oh, and of course I love the little sidenote at the end.
BBC News has switched to HTTPS—hurrah!
Here, one of the engineers writes on Ev’s blog about the challenges involved. Personally, I think this is far more valuable and inspiring to read than the unempathetic posts claiming that switching to HTTPS is easy.
This is a great illustrated explanation of how DNS resolution works.
I share many of these concerns.
The web is huge. Even bigger than Google. I love that the web preserves all the work. I don’t think anyone has the right to change the web so they no longer work.
All the books, Montag.
If we want a 100% encrypted web then we need to encrypt all sites, despite whether or not you agree with what they do/say/sell/etc… 100% is 100% and it includes the ‘bad guys’ too.
I’m all in favour of HTTPS everywhere, but this kind of strong-arming just feels like blackmail to me.
All new CSS properties won’t work without HTTPS‽ Come on!
I thought Mozilla was better than this.
Many, many years ago, Tim Berners-Lee wrote this page of answers to (genuinely) frequently asked questions he got from school kids working on reports. I absolutely love the clear straightforward language he uses to describe concepts like hypertext, packet switching, and HTTP.
Here’s a nice one-sentence definition for the marketing folk:
A Progressive Web App is a regular website following a progressive enhancement strategy to deliver native-like user experiences by using modern Web standards.
But if you’re talking to developers, I implore you to concretely define a Progressive Web App as the combination of HTTPS, a service worker, and a Web App Manifest.
Well, I guess it’s time to change all my locally-hosted sites from
.dev domains to
.test. Thanks, Google.
A fantastic piece by Aaron who—once again—articulates what I’ve been thinking:
Your site—every site—should be a PWA.
He clearly explains the building blocks of progressive web apps—HTTPS, a manifest file, and a service worker—before describing different scenarios for different kinds of sites:
Progressive Web Apps may seem overly technical or beyond the needs of your project, but they’re really not. They’re just a shorthand for quality web experiences—experiences that can absolutely make a difference in our users’ lives.
The slides from Calum’s presentation about progressive web apps. There are links throughout to some handy resources.
This primer on progressive web apps starts by dispelling some myths:
- Your thing does not have to be an “Application” to be a PWA.
- PWAs are not specifically made for Google or Android.
- PWAs are ready and safe to use today.
Then it describes the three-step programme for turning your thing into a progressive web app:
- The Manifest.
- Go HTTPS.
- The Service Worker.
Tell it, brother!
I love, love, *love, traintimes.org.uk—partly because it’s so useful, but also because it’s so fast. I know public transport is the clichéd use-case when it comes to talking about web performance, but in this case it’s genuine: I use the site on trains and in airports.
Matthew gives a blow-by-blow account of the performance optimisations he’s made for the site, including a service worker. The whole thing is a masterclass in performance and progressive enhancement. I’m so glad he took the time to share this!