This would be a fascinating experiment to run in Firefox nightly! This is in response to that post I wrote about third-party scripts.
Saturday, November 16th, 2019
Tuesday, November 12th, 2019
The web turned 30 this year. When I was back at CERN to mark this anniversary, there was a lot of introspection and questioning the direction that the web has taken. Everyone I know that uses the web is in agreement that tracking and surveillance are out of control. It seems only right to question whether the web has lost its way.
Without cookies, the web was stateless. This was by design. Now, I totally understand why cookies—or something like cookies—were needed. Without some way of keeping track of state, there’s no good way for a website to “remember” what’s in your shopping cart, or whether you’ve authenticated yourself.
But why would cookies ever need to work across domains? Authentication, shopping carts and all that good stuff can happen on the same domain. Third-party cookies, on the other hand, seem custom made for tracking and frankly, not much else.
Browsers allow you to disable third-party cookies, though it’s not yet the default. If enough people do it—and complain about the sites that stop working when third-party cookies are disabled—then maybe it can become the default.
Firefox is taking steps in this direction, automatically disabling some third-party cookies—the ones that known trackers. Safari is also taking steps to prevent cross-site tracking. It’s not too late to change the tide of third-party cookies.
- Embedding video, audio, and maps would get a lot finickier.
- Analytics would need to be self-hosted. I don’t think that would bother any site owners. An analytics platform like Google Analytics that tracks people across domains is doing it for its own benefit rather than that of site owners.
- Advertising wouldn’t be creepy and annoying. Instead of what’s so euphemistically called “personalisation”, advertisers would have to rely on serving relevant ads based on the content of the site rather than an invasive psychological profile of the user. (I honestly think that advertisers would benefit from this kind of targetting.)
93% of pages include at least one third-party resource, 76% of pages issue a request to an analytics domain, the median page requests content from at least 9 unique third-party domains that represent 35% of their total network activity, and the most active 10% of pages issue a whopping 175 third-party requests or more.
CSS for all
There have been some great new CSS properties and values shipping in Firefox recently.
In another video, Jen describes some new properties for styling underlines (on links, for example):
text-decoration-thickness: 0.1em; text-decoration-color: red; text-underline-offset: 0.2em; text-decoration-skip-ink: auto;
As far as I can tell, all of these properties are available to you regardless of whether you are serving your website over HTTP or over HTTPS. That may seem like an odd observation to make, but I invite you to cast your mind back to January 2018. That’s when the Mozilla Security Blog posted about moving to secure contexts everywhere:
Despite that “effective immediately” clause, I haven’t observed any of the new CSS properties added in the past two years to be restricted to HTTPS. I’m glad about that. I wrote about this announcement at the time:
I am in total agreement that we should be encouraging everyone to switch to HTTPS. But requiring HTTPS in order to use CSS? The ends don’t justify the means.
If there were valid security reasons for making HTTPS a requirement, I would be all for enforcing this. But these are two totally separate areas. Enforcing HTTPS by withholding CSS support is no different to enforcing AMP by withholding search placement.
There’s no official word from the Mozilla Security Blog about any change to their two-year old “effective immediately” policy, and the original blog post hasn’t been updated. Maybe we can all just pretend it never happened.
Thursday, November 7th, 2019
I really like the work that IF are doing to document patterns around handling data:
- Signing in to a service
- Giving and removing consent
- Giving access to data
- Getting access to data
- Understanding automated decisions
- Doing security checks
Each pattern has a description, advantages, limitations, and examples.
Tuesday, October 29th, 2019
Periodic background sync
Yesterday I wrote about how much I’d like to see silent push for the web:
I’d really like silent push for the web—the ability to update a cache with fresh content as soon as it’s published; that would be nifty! At the same time, I understand the concerns. It feels more powerful than other permission-based APIs like notifications.
hi there, just read your blog post about Silent Push for acthe web, and wondering if Periodic Background Sync would cover a few of those use cases?
Periodic background sync looks very interesting indeed!
It’s not the same as silent push. As the name suggests, this is about your service worker waking up periodically and potentially fetching (and caching) fresh content from the network. So the service worker is polling rather than receiving a push. But I’ll take it! It’s definitely close enough for the kind of use-cases I’ve been thinking about.
Interestingly, periodic background sync also ties into the other part of what I was writing about: permissions. I mentioned that adding a site the home screen could be interpreted as a signal to potentially allow more permissions (or at least allow prompts for more permissions).
Well, Chromium has a document outlining metrics for attempting to gauge site engagement. There’s some good thinking in there.
Monday, October 28th, 2019
Silent push for the web
While I’m very unwilling to grant permission to be interrupted by intrusive notifications, I’d be more than willing to grant permission to allow a website to silently cache timely content in the background. It would be a more calm technology.
Phil Nash left a comment on the Medium copy of my post explaining that Seb’s demo of using the Push API without showing a notification wouldn’t work for long:
The browsers allow a certain number of mistakes(?) before they start to show a generic notification to say that your site sent a push notification without showing a notification. I believe that after ~10 or so notifications, and that’s different between browsers, they run out of patience.
He also provided me with the name to describe what I’m after:
You’re looking for “silent push” as are many others.
Silent push is something that is possible in native apps. It isn’t (yet?) available on the web, presumably because of security concerns.
It’s an API that would ripe for abuse. I mean, just look at the mess we’ve made with APIs like notifications and geolocation. Sure, they require explicit user opt-in, but these opt-ins are seen so often that users are sick of seeing them. Silent push would be one more permission-based API to add to the stack of annoyances.
Still, I’d really like silent push for the web—the ability to update a cache with fresh content as soon as it’s published; that would be nifty! At the same time, I understand the concerns. It feels more powerful than other permission-based APIs like notifications.
Maybe there could be another layer of permissions. What if adding a site to your home screen was the first step? If a site is running on HTTPS, has a service worker, has a web app manifest, and has been added to the homescreen, maybe then and only then should it be allowed to prompt for permission to do silent push.
In other words, what if certain very powerful APIs were only available to progressive web apps that have successfully been added to the home screen?
Frankly, I’d be happy if the same permissions model applied to web notifications too, but I guess that ship has sailed.
Anyway, all this is pure conjecture on my part. As far as I know, silent push isn’t on the roadmap for any of the browser vendors right now. That’s fair enough. Although it does annoy me that native apps have this capability that web sites don’t.
It used to be that there was a long list of features that only native apps could do, but that list has grown shorter and shorter. The web’s hare is catching up to native’s tortoise.
Wednesday, October 2nd, 2019
This is good news. I have third-party cookies disabled in my browser, and I’m very happy that it will become the default.
It’s hard to believe that we ever allowed third-party cookies and scripts in the first place. Between them, they’re responsible for the worst ills of the World Wide Web.
Sunday, September 1st, 2019
As a resident of Brighton—home to the most beautiful of bandstands—this bit of background to their history is fascinating.
Wednesday, August 7th, 2019
Boolean logic manifested in a Turing-complete game
Tuesday, July 16th, 2019
An interesting look at the mortality causes for Internet Explorer 6 and Internet Explorer 8, and what they can tell us for the hoped-for death of Internet Explorer 11.
Monday, July 15th, 2019
Correlation does not imply causation.
Saturday, July 6th, 2019
The Hiding Place: Inside the World’s First Long-Term Storage Facility for Highly Radioactive Nuclear Waste - Pacific Standard
Robert McFarlane’s new book is an exploration of deep time. In this extract, he visits the Onkalo nuclear waste storage facility in Finland.
Sometimes we bury materials in order that they may be preserved for the future. Sometimes we bury materials in order to preserve the future from them.
Thursday, May 30th, 2019
This starts as a good bit of computer science nerdery, that kind of answers the question in the title:
Alone, CSS is not Turing complete. CSS plus HTML plus user input is Turing complete!
And so the takeaway here is bigger than just speculation about Turing completeness:
Given that CSS is a domain-specific language for styling user interface, this makes a lot of sense! CSS + HTML + Human = Turing complete.
At the end of that day, as CSS developers that is the language we really write. CSS is incomplete without HTML, and a styled interface is incomplete without a human to use it.
Wednesday, April 24th, 2019
A terrific six-part series of short articles looking at the people behind the history of Artificial Intelligence, from Babbage to Turing to JCR Licklider.
- When Charles Babbage Played Chess With the Original Mechanical Turk
- Invisible Women Programmed America’s First Electronic Computer
- Why Alan Turing Wanted AI Agents to Make Mistakes
- The DARPA Dreamer Who Aimed for Cyborg Intelligence
- Algorithmic Bias Was Born in the 1980s
- How Amazon’s Mechanical Turkers Got Squeezed Inside the Machine
The history of AI is often told as the story of machines getting smarter over time. What’s lost is the human element in the narrative, how intelligent machines are designed, trained, and powered by human minds and bodies.
Thursday, April 11th, 2019
If you’re using Apple’s VoiceOver, both your phone and your computer will broadcast your assumed disability to the entire internet, unless and until you specifically tell it to stop.
Thursday, April 4th, 2019
I also discussed this accessibility events feature with my friend who is a screen reader user herself. She said it feels like it’s a first step towards a well-meant digital apartheid.
Monday, March 18th, 2019
Some lovely data visualisation by Brendan:
The work features three main components — the threats, represented by black obelisk style objects, the system which detects and deals with these threats, represented by an organic mesh like structure, and finally the creativity that is allowed to flow because the threats have been neutralised.
Friday, March 15th, 2019
Tuesday, February 19th, 2019
Honestly, cryptocurrencies are useless. They’re only used by speculators looking for quick riches, people who don’t like government-backed currencies, and criminals who want a black-market way to exchange money.
Bruce Schneier on the blockchain:
What blockchain does is shift some of the trust in people and institutions to trust in technology. You need to trust the cryptography, the protocols, the software, the computers and the network. And you need to trust them absolutely, because they’re often single points of failure.
Sunday, January 27th, 2019
A browser extension that encrypts and decrypts posts on Facebook—if two users have the extension installed, they can communicate without Facebook being able read their messages.