Every site that I sign up for asks me to upload an avatar to represent myself. Whenever I change my photo, I have to log in to a hundred sites and change it there⁰.

Perhaps they could all use Gravatar - but that's a centralised service¹ and doesn't work with wildcard email addresses. Libravatar also relies on email addresses and requires implementers to set up new DNS entries.

So I'm proposing .well-known/avatar. Here's how it works (for now). I'd like your feedback before going further².

I sign up to a service and use the email address whatever@shkspr.mobi.

The service looks up my avatar using a well-known path. For example, request https://shkspr.mobi/.well-known/avatar?resource=acct:whatever@shkspr.mobi and you'll get back this JSON:

{
    "subject": "acct:whatever@shkspr.mobi",
    "links": [
        {
              "rel": "http:\/\/webfinger.net\/rel\/avatar",
             "type": "image\/webp",
             "href": "https:\/\/shkspr.mobi\/.well-known\/avatar\/avatar-1024.webp",
            "sizes": "1024x1024"
        },
        {
              "rel": "http:\/\/webfinger.net\/rel\/avatar",
             "type": "image\/jpeg",
             "href": "https:\/\/shkspr.mobi\/.well-known\/avatar\/avatar-512.jpg",
            "sizes": "512x512"
        }
    ]
}

That's a slightly enhanced https://webfinger.net/rel/#avatar which adds a sizes parameter. The service can then pick the appropriate MIME and size.

Alternatively, you can request the same URl but with a header of Accept: image/gif and receive the default sized avatar in that specific format.

Try it by running:

curl -H "Accept: image/avif" https://shkspr.mobi/.well-known/avatar/ --output "test.avif"

You should receive an auto-converted version of my avatar.

Some Thoughts

Please add your thoughts to the comments box. Here's some feedback I've received so far.

Perhaps this is too complicated? What's wrong with just serving up an image when the URl is requested? That would make it easier for static sites.

Simon Josefsson

@jas@fosstodon.org

@Edent Thinking about this, while I like content negotiation as a clever hack, I wonder if maybe it isn’t too clever. The nice thing with WKD is that you can deploy it with any normal static HTTP file without any special magic. Maybe the protocol could be dumbed down to simply rely on WKD-style URLs? I’m not sure how to configure my web server (Apache) for your avatar well known URL with negotiation magic.

2025-10-23, 16:50 0 boosts 1 favorites

What about a size parameter?

Chip

@chip@talking.dev

@Edent It'd be nice if the query could limit the size of the avatar being returned. If only there were `Accept-Max-Size`, but maybe a query param? I wouldn't want my performance taking a dive if Alice has a 35M avatar that my client starts downloading. If my client had requested with `max_size=3072` I'd rather not see the avatar than degrade performance/pull excess data

2025-10-23, 15:02 0 boosts 1 favorites

Will anyone actually use it?

Andreas Gohr

@splitbrain@fedi.splitbrain.org

@Edent good luck with getting the hundreds of services to implement it. I mean it. it would be awesome and you might be well connected enough to make it happen.

2025-10-23, 15:03

What about hashing the email?

David Bushell 🎮

@db@social.lol

@Edent would using a hash of the email address in its place improve privacy? 🤔

2025-10-25, 11:52 0 boosts 0 favorites

You've already given the service your email address, and your domain already knows your account name - so there's no privacy leak here. Obviously, a service shouldn't hotlink to your avatar image.

How about DNS?

I like it. Is there an argument that service / endpoint should be specifiable at the DNS level?As others in your comments pointed out, if your site is currently just static, some users might prefer to run an entirely separate dedicated avatar service.

— Emily Shepherd (@emi.ly) 2025-10-25T11:57:43.456Z

Personally, I think that's a bit complicated, but I'm happy to be convinced.

Is this restricted to email?

No! For example, if you know my GitHub username then you should be able to get the avatar from https://github.com/.well-known/avatar?resource=acct:edent

How can a service tell if the avatar has been updated?

Perhaps a hash, timestamp, or something else?

Can requests for multiple accounts be sent at once?

I'm not sure how / if WebFinger handles this. I suppose there ought to be some limit to avoid overwhelming a server.

Proposal

I think the default should be to return an image.

If an accept of image/… is requested, the server should try to return an image in that format.

If an accept of application/json or similar is requested, the server should return a JSON document listing the available avatars.

I don't think a ?size= GET parameter is necessary; services can resize once they've downloaded, or use the JSON document to get the right size.

A limited amount of alt text could be added using the title attribute in the JSON.

Before I start writing up anything formal - I'd love your constructive criticism on this.

You click the relevant icon and get taken to the site with the sharing details pre-filled.

The problem is, every different site has a different intent for sharing links and text. For example:

• https://www.facebook.com/sharer.php?u=…&t=…
• https://www.linkedin.com/sharing/share-offsite/?url=…
• https://bsky.app/intent/compose?text=…
• https://www.threads.net/intent/post?url=…&text=…
• https://www.reddit.com/submit?url=…&title=…

As you can see, some only allow a URL, some text and a URL, and some just a plain text which could contain the URl. A bit of a mess! It's probably impossible to get every site to agree on a standard for their sharing intent. But there could be a standard for exposing their existing sharing mechanism.

That's the proposal from Ben Werdmuller with "Share Openly".

ShareOpenly knows about most major social networks, as well as decentralized platforms like Mastodon, Bluesky, and Known.

However, if ShareOpenly is having trouble sharing to your platform, and if your platform supports a share intent, you can add the following metatag to your page headers:

<link rel="share-url" href="https://your-site/share/intent?text={text}">

Where https://your-site/share/intent?text= is the URL of your share intent.

The special keyword {text} will be replaced with the URL and share text.

I think that's a pretty nifty solution.

For sites which take a URl and an (optional) title, the meta element looks like:

<link rel="share-url" href="https://www.facebook.com/sharer.php?u={url}&t={text}">
<link rel="share-url" href="https://lemmy.world/create_post?url={url}&title={text}">

For those which only take URl, it looks like:

<link rel="share-url" href="https://www.linkedin.com/sharing/share-offsite/?url={url}">

It's slightly trickier for sites like Mastodon and BlueSky which only have a text sharing field and no separate URl. The current proposal is just to use the text. For example

<link rel="share-url" href="https://bsky.app/intent/compose?text={text}">

But it could be something like

<link rel="share-url" href="https://mastodon.social/share?text={text}%0A{url}">

What Next?

The HTML specification has this to say about adding new link types:

Extensions to the predefined set of link types may be registered on the microformats page for existing rel values.

Adding to that page merely requires a formal specification to be written up. After that, some light lobbying might be needed to get social networks to adopt it.

So, I have three questions for you:

1. Do you think <link rel="share-url" is a good idea for a new standard?
2. What changes, if any, would you make to the above proposal?
3. Would you be interested in using it - either as a sharer or sharing destination?

Please leave a comment in the box - and remember to hit those sharing buttons!

The pitch is simple. A website owner places a single new line in their HTML's <head> - something like this:

<link rel="monetization" href="https://wallet.example.com/edent" />

That address is a "Payment Pointer". As a user browses the web, their browser takes note of all the sites they've visited. At the end of the month, the funds in the user's digital wallet are split proportionally between the sites which have enabled WebMonetization. The user's budget is under their control and there are various technical measures to stop websites hijacking funds.

This could be revolutionary⁰.

But there are some interesting fraud angles to consider. Let me give you a couple of examples.

Pointer Hijacking

Suppose I hacked into a popular site like BBC.co.uk and surreptitiously included my link in their HTML. Even if I was successful for just a few minutes, I could syphon off a significant amount of money.

At the moment, the WebMonetization plugin only looks at the page's HTML to find payment pointers. There's no way to say "This site doesn't use WebMonetization" or an out-of-band way to signal which Payment Pointer is correct. Obviously there are lots of ways to profit from hacking a website - but most of them are ostentatious or require the user to interact. This is subtle and silent.

How long would it take you to notice that a single meta element had snuck into some complex markup? When you discover it, what can you do? Money sent to that wallet can be transferred out in an instant. You might be able to get the wallet provider to freeze the funds or suspend the account, but that may not get you any money back.

Similarly, a Web Extension like Honey could re-write the page's source code to remove or change an existing payment pointer.

Possible Solutions

Perhaps the username associated with a Payment Pointer should be that of the website it uses? something like href="https://wallet.example.com/shkspr.mobi"

That's superficially attractive, but comes with issues. I might have several domains - do I want to create a pointer for each of them?

There's also a legitimate use-case for having my pointer on someone else's site. Suppose I write a guest article for someone - their website might contain:

<link rel="monetization" href="https://wallet.example.com/edent" />
<link rel="monetization" href="https://wallet.coin_base.biz/BigSite" />

Which would allow us to split the revenue.

Similarly, a site like GitHub might let me use my Payment Pointer when people are visiting my specific page.

So, perhaps site owners should add a .well-known directive which lists acceptable Pointers? Well, if I have the ability to add arbitrary HTML to a site, I might also be able to upload files. So it isn't particularly robust protection.

Alright, what are other ways typically used to prove the legitimacy of data? DNS maybe? As the popular meme goes:

@atax1a@infosec.exchange

mx alex tax1a - 2020 (5)

@jwz @grumpybozo just one more public key in a TXT record, that'll fix email, just gotta add one more TXT record bro

---

Someone with the ability to publish on a website is less likely to have access to DNS records. So having (yet another) DNS record could provide some protection. But DNS is tricky to get right, annoying to update, and a pain to repeatedly configure if you're constantly adding and removing legitimate users.

Reputation Hijacking

Suppose the propaganda experts in The People's Republic of Blefuscu decide to launch a fake site for your favourite political cause. It contains all sorts of horrible lies about a political candidate and tarnishes the reputation of something you hold dear. The sneaky tricksters put in a Payment Pointer which is the same as the legitimate site.

"This must be an official site," people say. "Look! It even funnels money to the same wallet as the other official sites!"

There's no way to disclaim money sent to you. Perhaps a political opponent operates an illegal Bonsai Kitten farm - but puts your Payment Pointer on it.

"I don't squash kittens into jars!" You cry as they drag you away. The police are unconvinced "Then why are you profiting from it?"

Possible Solutions

A wallet provider needs to be able to list which sites are your sites.

You log in to your wallet provider and fill in a list of websites you want your Payment Pointer to work on. Add your blog, your recipe site, your homemade video forum etc. When a user browses a website, they see the Payment Pointer and ask it for a list of valid sites. If "BonsaiKitten.biz" isn't on there, no payment is sent.

Much like OAuth, there is an administrative hassle to this. You may need to regularly update the sites you use, and hope that your forgetfulness doesn't cost you in lost income.

Final Thoughts

I'm moderately excited about WebMonetization. If it lives up to its promises, it could unleash a new wave of sustainable creativity across the web. If it is easier to make micropayments or donations to sites you like, without being subject to the invasive tracking of adverts, that would be brilliant.

The problems I've identified above are (I hope) minor. Someone sending you money without your consent may be concerning, but there's not much of an economic incentive to enrich your foes.

Think I'm wrong? Reckon you've found another fraudulent avenue? Want to argue about whether this is a likely problem? Stick a comment in the box.

As I've moaned about before, TOTP has never been properly standardised. It's a mish-mash of half-finished proposals with no active development, no test suite, and no-one looking after it. Which is exactly what you want from a security specification, right?!

So let's try to find some edge-cases and see where things break down.

One Punch Man

This is possibly the least secure TOTP code I could create. Scan it and see whether your app will accept it.

What makes it so crap? There are three things which protect you when using TOTP.

1. The shared secret. In this case, it is abcdefghijklmno - OK, that's not the easiest thing to guess, but it isn't exactly complex.
2. The amount time the code is valid for before changing. Most TOTP codes last 30 seconds, this lasts 120.
3. The length of the code. Most codes are 6 digits long. In theory, the spec allows 8 digits. This is 1. Yup. A single digit.

If you were thick enough to use this¹, an attacker would have a 1/10 chance of simply guessing your MFA code. If they saw you type it in, they'd have a couple of minutes in which to reuse it.

Can modern TOTP apps add this code? I crowdsourced the answers.

Surprisingly, a few apps accept it! Aegis, 1password, and BitWarden will happily store it and show you a 1 digit code for 120 seconds.

A few reject it. Authy, Google Authenticator, and OpenOTP claim the code is broken and won't add it.

But, weirdly, a few interpret it incorrectly! The native iOS app, Microsoft Authenticator, and KeepassXC store the code, but treat it as a 6 digit, 30 second code.

Do The Right Thing

What is the right thing to do in this case? The code is outside the (very loosely defined) specification. Postel's Law tells us that we should try our best to interpret malformed data - which is what Aegis and BitWarden do.

But, in a security context, that could be dangerous. Perhaps rejecting a dodgy code makes more sense?

What is absolutely daft² is ignoring the bits of the code you don't like and substituting your own data! Luckily, in a normal TOTP enrolment, the user has to enter a code to prove they've saved it correctly. Entering in a 6 digit code where only 1 is expected is likely to fail.

We're Only Human

A one-digit code is ridiculous. But what about the other extreme? Would a 128-digit code be acceptable? For a human, no; it would be impossible to type in correctly. For a machine with a shared secret, it possibly makes sense.

On a high-latency connection or with users who may have mobility difficulties, a multi-minute timeframe could be sensible. For something of extremely high security, sub-30 seconds may be necessary.

But, again, the specification hasn't evolved to meet user needs. It is stagnant and decaying.

What's Next?

There's an draft proposal to tighten up to TOTP spec which has expired.

It would be nice if the major security players came together to work out a formal and complete specification for this vital piece of security architecture. But I bet it won't ever happen.

• Google have archived their work on authentication standards.
• Apple points to Google's outdated spec.
• YubiCo's incompatible spec hasn't been updated in 4 years.
• The otpauth registration lists a consortium called https://openauthentication.org who don't appear to published anything in a decade.
• Microsoft don't have any documentation whatsoever.

So there you have it. We're told to rely on TOTP for our MFA - yet the major apps all disagree on how the standard should be implemented. This is a recipe for an eventual security disaster.

How do we fix it?

The TOTP algorithm uses a Hash-based Message Authentication Code (HMAC). The hash is calculated from a shared key and a time-based component.

The key is a short string of characters. The time-based component is calculated as the number of seconds between now and the Unix Epoch. When is the Unix Epoch? 00:00:00 UTC on Thursday, 1 January 1970⁰. It has been roughly 1.7 billion seconds since then. 64 bit computer systems can count up for another 290 billion years¹. So chrononauts journeying to the future should be fine.

But what about people travelling backwards? You and your friends want to go and see The Beatles perform in 1966. That's before 1970. So the time-based component will be a negative number.

I've tried a bunch of different TOTP generators and fed them a variety of negative numbers. They all crashed.

So, no. TOTP doesn't work for anyone travelling backwards in the 4th dimension. Pity.

Is there a serious point to this? Well, sort of.

Negative time is an unexpected input and leads to unusual behaviours. Could a crash in HMAC generation lead to an exploit?

Standards get used in all sorts of places - including retrospectively. Should standards writers specifically account for inputs which occur in the past?

How should computers deal with "preposterous" times?

What other common security tools fail if they're subjected to time-travel?

Which Beatles concert would you go to in 1966?

When I sign up to a web service, I don't want to faff around uploading an image to use as my avatar. I want that service to look at my email address or social-sign-in and automatically pick up my preferred graphic.

Here's how I see it working.

1. A user signs in to a service with the email address username@example.com
2. In a similar way to WebFinger, the service makes a request to:
   • example.com/.well-known/avatar?resource=acct:username@example.com
3. If the request's Accept header has a MIME type of image/*, then the server immediately returns an image.
4. If the request's Accept header has a MIME type of application/json, then the server can return a WebFinger-style document with "rel":"http://webfinger.net/rel/avatar" and, perhaps, a list of different images, formats, and sizes.

This makes it incredibly simple for people to use the same avatar everywhere.

It also means that if you're designing a service which publicly shows usernames, you can make avatars available without an expensive API call. For example, Twitter could make user's avatars available at: twitter.com/.well-known/avatars?resource=acct:edent

But what about...?

This is a sketch of an idea. I'd like to know if people think it is useful before I take it any further.

I don't think it breaches privacy - a user's image is public on all services anyway.

Users should still be given the option of changing their avatar if they want.

A service shouldn't expose the user's email address - they should proxy the image.

Anything else I should have thought of?

Updates

To stave off some common points raised.

• No this isn't like Gravatar. That works by being a 3rd party service and using the MD5 of your email address.
• No this isn't like Libravatar. See above.
• No this isn't like WebFinger. That only returns JSON.
• No this isn't like h-card. That requires a server to parse HTML in order to find an image.
• No this isn't like BIMI. That's expensive and only supports SVG.

1. Launch a product to great fanfare
2. Spend a few years hyping it as ✨the future✨
3. Stop answering emails and pull requests
4. If you're lucky, announce that the product is abandoned but, more likely, just forget about it.

Open Graph Protocol (OGP) is one of those products. The value-proposition is simple.

• It's hard for computers to pick out the main headline, image, and other data from a complex web page.
• Therefore, let's encourage websites to include metadata which tells our services what they should look at!

OGP works pretty well! When you share a link on Facebook, or Twitter, or Telegram - those services load the website in the background, look for OGP metadata, and display a friendly snippet.

Facebook Meta were the driving force behind OGP - and have now left it to fester.

• The website - https://ogp.me/ - still works.
• But the Facebook OGP Discussion Group is now full of spam.
• The Developer Mailing List is broken.
• The Google Documentation links to a dead Google+ page.
• And the GitHub Page has been archived.

Is OGP finished?

And, that might be fine. Facebook Meta are a small company with limited resources. They can't afford to fund standards work indefinitely. And, anyway, OGP is complete, right? It has all the tags that anyone could ever possibly want. Why does it need any improving?

Well, that's not the case. We know, for example, that Twitter have created their own proprietary OGP-like meta tags. Similarly, Pinterest have their own as well. And even Google are going their own way with Rich Snippets.

This is annoying for developers. Now we have to write multiple different bits of metadata if we want our links to be supported on all platforms.

Standards work is never "finished". Developers want to add new features. Users want to interact with new forms of content.

Tomorrow someone is going to invent a way to share smells over the Internet. How does that get represented in an Open Graph Protocol compliant manner?

<meta property="twitter:olfactory" content="C₃H₆S"> or <meta property="facebook:nose" content="InChIKey/MWOOGOJBHIARFG-UHFFFAOYSA-N"> or <meta property="og:smell" content="pumpkin spice"> or...

We know from bitter experience that having several mutually incompatible ways to implement something is a nightmare for developers and provides a poor user-experience.

So we create standards bodies. They're not perfect, but a group of interested folks can do the hard work to try and satisfy oppositional stakeholders.

This is my plea to Facebook Meta. If you're no longer interested in improving OGP, OK. You do you. But hand it over to people who want to keep this going. Maybe it's the W3C, or IndieWeb, or Schema.org or someone. Hell, I'm not busy, I'll take it on.

Remember, if you love something, let it go.

Where do we see compatibility - and incompatibility - within the Star Wars universe? How might the lives and fates of our protagonists have been changed by better standardisation?

Data Tapes

Admiral Motti: Don't try to frighten us with your sorcerer's ways, Lord Vader. Your sad devotion to that ancient religion has not helped you conjure up the stolen data-tapes.

At the very end of Rogue One, an unnamed soldier downloads the Death Star plans onto a "data tape" - and pulls it from the Tantive IV's mainframe.

The tape makes its way to Princess Leia, who inserts it into R2-D2 - an astromech droid.

This tells us a few interesting things about the Star Wars universe. Firstly, the physical format of data tapes are standardised. A computer from one part of the galaxy can exchange physical media with a droid from somewhere else. Data tapes are common enough for their drives to be built into droids. The physical size - and formats - of tapes has obviously remained relatively consistent.

Imagine Leia trying to squeeze a CD-RW into a Zip Drive slot. Or even a Mac formatted floppy into a DOS drive!

Without the mutual compatibility of this exchange format, there would be no escape for the Rebels!

Computer Terminals

When the gang of heroes arrive on the Death Star, R2-D2 immediately inserts his probe (no, seriously, that's what it is called) into a computer terminal, and starts interrogating the system:

He does the same thing on a different level of the Death Star as his chums are running around:

This shows us that these ports have a standard physical interface - at least for R2 units or droids of a similar height. Despite the Death Star's modernity, they retain a standard way of accessing information with older computers.

The lack of standards shows up when Artoo visits the Cloud City of Bespin. His friend, C-3PO, asks him to interface with the computer to override the security systems - with disastrous consequences:

Poor Artoo! But, also, poor planning from a standards' perspective. C-3PO's non-apology shows the problem.

Look at that image. The power socket is at the same height as a computer terminal and uses a physically similar connector. A good standard would have made the sockets mutually incompatible - you shouldn't be able to shove a USB plug into an electrical socket and vice-versa.

A few moments later, the droid opens one of the doors on Cloud City:

Can you immediately tell the difference between the data socket and the power socket? There are no labels, no warnings, and few physical differences.

Standards Save Lives!

Ships

Astromech droids, like R2, are handy, diverse, and standardised.

The Phantom Menace shows them interfacing with N-1 star fighters

Attack of the Clones shows them in other ships:

Yet more in Revenge of the Sith:

And, A New Hope also shows a variety of Atromechs in a bunch of different ships:

What I'm getting at is that standardisation is the secret to success. You can take any Astromech droid and plonk it in any small spaceship at it'll just work! That means standard physical sizes for the robots, standard interfaces, standard protocols, standards everywhere!

Imagine the palaver if R2-D2 had to have a conversion kit when swapped between a Jedi Interceptor and an X-Wing - what chaos! Bought a brand new Y-Wing? Sorry pal, you'll need to replace all your little robots. What a waste!

Let's Go Fly A Kite Spaceship

I particularly like this sideways look at Star Wars:

Lilah Sturges (Inactive)

@LilahSturges

Rebel: who are you?
Luke: I’m a farmer who accidentally got a message intended for Leia and got captured attempting to deliver it. But I rescued her!
Leia: I mostly rescued myself.
Luke: so can I fly one of these fighters?
Rebel: have you ever flown one?
Luke: NOPE
Rebel: ok cool

---

The whole thread is brilliant - and I recommend it. But it makes a small error. Luke is proficient at flying a T-16. So why shouldn't he be able to fly an X-Wing?

In most countries, if you have a basic driving licence, you are allowed to drive any make and model of car. The accelerator, brake, and clutch pedals are all in the same location. The gears are in the same order on the stick. Mirrors adjust in much the same way. Lights, indicators, and wipers are all clearly marked. If you're a competent driver - standards means that you can hop from one car to another with ease.

We see the same thing in The Force Awakens. Poe has never flown a TIE Fighter:

Same with Rey after flying the Millennium Falcon:

Standards make it easy to go from one craft to the next. Does Poe know what every switch does in the cockpit? No - but he eventually works out how to release the docking tether.

I'm not sure how easy it is for, say, a MiG-21 pilot to fly an F-35. I'm sure some of the basics are the same, right? There are standards for how joysticks work, at the very least, I assume.

Imagine if Poe had to take 30 week course before jumping into a TIE Fighter. What if Luke needed to get a thousand flight-hours in on a simulator before they let him near an X-Wing? Standardised technologies make it easier for people to use new equipment.

6 Million Forms of Communication

We all know Threepio's famous boast: But what does he mean by that? The full quote is:

Sir, I am fluent in six million forms of communication. This signal is not used by the Alliance. It could be an Imperial code.

By "forms of communication" - Threepio means codes and other protocols. Remember how he introduces himself to Own Lars?

OWEN: What I really need is a droid that understands the binary language of moisture vaporators. THREEPIO: Vaporators! Sir, my first job was programming binary load lifters... very similar to your vaporators in most respects.

C-3PO can't speak 6 million languages. But he does have 6 million printer drivers installed!

And on it goes

There are dozens of other standards hidden away in the Star Wars universe. Radio comms just work across a menagerie of different space-ships. Restraining bolts are standardised no matter the droid. Clones are the very apotheosis of standardisation!

This isn't intended to be an exhaustive list of standards. And it only covers the movies - rather than the endless comics, cartoons, books, and games you played with your toys.

Speaking of which... one last thing. When I was a lad, my original Star Wars toys (which would be worth a fortune if I hadn't played with them) all had a standardised feature. Can you guess what it was?

5 points if you remembered that all the original toys had the same size hole in the soles of their feet for foot pegs!

You can read more about them in "The Ultimate Guide to Vintage Star Wars Action Figures 1977-1985". The standard allowed Kenner - the manufacturer - to create playsets of all shapes and sizes, and to have their action figures clip in nicely to them. If you wanted Darth Vader in your Millennium Falcon, or Lando Calrissian in the Mos Eisley cantina - standards helped you have fun.

I hope, in my small way, I've shown you why standards are important throughout the galaxy.

I have loved working with the AC. They are a team of brilliant individuals who are all committed to trying to make AMP better, and I'm sorry to leave them. I've been a member of the AC for a little over two years and now is the time to step away and let a wider variety of people work on the committee.

As I mentioned in a previous blog post, I am starting an MSc in January so I'm trying to cut back on my extracurricular activities.

The stated goal of the AMP AC is to "make AMP a great web citizen."

I am concerned that - despite the hard work of the AC - Google has limited interest in that goal.

When I joined, I wondered whether I could make a difference. I hope that I have been a critical friend. The AC has encouraged AMP to think more about user needs - rather than Google's needs. And changes to the search carousel were also a concern of the committee which have been partly addressed.

Google's thesis is that the mobile-web is dying and people prefer to use apps - therefore making the web faster and more app-like will retain users. Google don't publish data about this, so I can't directly criticise their motives. But I do not think AMP, in its current implementation, helps make the web better.

I remain convinced that AMP is poorly implemented, hostile to the interests of both users and publishers, and a proprietary & unnecessary incursion into the open web.

I am glad that I tried to make it better, but I'm sad to have failed.

Amazon sells eBooks in KF8 format. That is an ePub with some proprietary extras. ePub is a standard based off HTML5. You can read the ePub 3 specification but, basically, it is a .zip of HTML files. If you unzip an eBook, you can read the source code behind it.

When trying to read a Kindle book on a non-Kindle device, I noticed a bug. Some words were not displaying. I took a look at the underlying source code, and found this:

Sometimes words and letters were wrapped with a pagebreak span like this:

<span id="pg5" epub:type="pagebreak">‘But</span> of course!’

When I tried to read the book using KOReader the word "‘But" didn't appear. Why? Let's take a look at the ePub3 specification concerning page breaks:

pagebreak

• A separator denoting the position before which a break occurs between two contiguous pages in a statically paginated version of the content.
• HTML usage context: phrasing and flow content, where the value of the carrying elements title attribute takes precedence over element content for the purposes of representing the pagebreak value

Here's the problem - eBooks can have page numbers. Despite "Page Numbers in eBooks Considered Harmful" lots of publishers still use them. I guess it is kind of useful if you want to refer to something on a printed page - but eReaders allow you to change font size and line spacing, so the concept of a page is somewhat nebulous.

The way the spec is written, means that you can write something like:

<span epub:type="pagebreak" id="page_123_a" title="123">123</span>

You use the id for internal linking and the title attribute for the value.

Because of this, most eReaders do not display the physical page number inside the span. It has no semantic content for the reader, and breaks flow. If they did display it, you might end up reading text like this:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean vel

9

risus at metus molestie tincidunt. Donec aliquet aliquam lorem, ...

So KOReader deliberately ignores any text which is wrapped with epub:type="pagebreak".

If you look at the example ePubs provided by the International Digital Publishing Forum, you'll see that the majority of their spans are self-closing.

<span epub:type="pagebreak" id="p123-a" title="123"/>

Very occasionally, you see something which has just a page number in it:

<span epub:type="pagebreak" title="169" id="Page_169">169</span>

I checked with KOReader and they confirmed that they were following the spec. I agree with them. There's no reason to wrap readable content in a metadata span like that.

I've checked several other books from different publishers. None of them abuse pagebreaks this way. I think Penguin Random House are doing it wrong and I would like to correct them.

Reporting it

I've previously reported buggy ebooks to vendors. But because the Kindle app doesn't exhibit this problem, I thought it was futile going via Amazon. So I thought I'd try going directly to the publisher.

Sadly, Penguin UK's GitHub repo is dead. Their dedicated digital publishing team haven't tweeted in 2 years.

Their contact page has a suggestion for what to do if there is an error in an eBook:

It is best if you return the book to the original bookshop from which it was purchased; they should be happy to exchange it for a perfect copy. If you have any difficulty with this then please return the cover and title page of the book to us.

Hmmm....

I dropped them an email, and got back this very reasonable reply:

Thank you for reaching out and bringing this to our attention. The distinction you’ve made is already a part of our specification; this was an oversight which we’re looking into as a result of your input—it bypassed checks both because it validates and also passes visual checks on all the major platforms we screen for. This isn’t reflective of our entire library and should be limited to specific titles which we’re currently investigating.

That's fair enough. The rendering quirk is specification compliant - but hard to spot because of the Kindle monoculture.

Change the spec, change the world

I've made a suggestion on GitHub that the spec should be clarified. I don't think it's particularly obvious that content in a pagebreak may not be displayed.

Most resources agree that the content of a pagebreak should either be blank, or be the page number.

If you include the page numbers as text content within a span or div, the pages will be more easily accessible to both sighted users and users using assistive technologies. This method has been employed in previous DAISY standards. The potential downside, however, is that mainstream user agents will not provide equivalent functionality to turn off unwanted content, forcing users to hear and view the page numbers.

Digital Accessible Information System (DAISY)

Whose fault is it anyway?

This is a tricky one. I think Penguin have undoubtedly made a mistake with the way they publish ePubs. But, so far, KOReader is the only rendering engine I've found which suppresses the content of pagebreaks by default.

Generally speaking, a user wouldn't want to display page numbers on an eBook. Software could have a user defined toggle to switch them on or off. Luckily, KOReader has a variety of style-sheets for rendering eBooks - so I picked one which displayed pagebreak content.

Software is hard.

But what about interactive images? Like panoramas and photospeheres?

Here's a 360° image. You can drag it to see all around.

That uses the fantastic Pannellum JavaScript Library. At the moment, there's no native way to represent that in HTML. If you use an <img> you'll get a flat, equirectangular image like this:

Here's two possible ways I've just thought of...

(These are just sketches of ideas - think of them as a starting point for user research, rather than a completed product.)

Extend <img> to be like <video>

An HTML5 video element looks something like this:

<video controls=false autoplay=true>

That tells the browser to start playing the video, but not to show any playback controls in the UI. Panoramic images could use something like:

<img panorama=true photosphere=false xdegress=270 src="...">

That is, this image is a panorama - but not a sphere - with 270 degrees of movement on the horizontal axis.

Or

<img panorama=true photosphere=true startx=120 starty=330 src="...">

Display a photosphere, make the initial view start at the following co-ordinates.

Use <picture>

As I've said before, I'm no fan of the <picture> element. I think it is inconsistently designed compared to other parts of HTML5.

Perhaps we could use it like this:

<picture>
  <source type="image/jpeg;panorama=true" srcset="pano.jpg">
  <img src="flat.png" alt="your browser doesn't support panoramics">
</picture>

That gives the MIME type of the image an extra parameter. Obviously, you'd need to put in other configuration options something.

What next?

A quick search didn't show anyone working on this as a proposal. That normally means either I'm not looking in the right places, or no one else is interested.

If you think this could be developed into a future standard, please let me know!

Me and my colleagues at Microsoft have decided that the world needs more Clippy - the adorable animated paperclip. To help with that, we're bringing a new feature to Edge 6.0.

Web Developers can now use <clippy> to call up an animated virtual assistant.

I've spoken to several people in Microsoft, and we all agree it is a good idea.

We looked through a number of great software projects (mostly from Microsoft) and found lots of inconsistencies in the way Clippy is presented and invoked.

So I've written a spec for how I think it should work. I've not actually spoken to many other developers about what their user needs are. I'm pretty sure I'm representative of the majority viewpoint.

Because users keep buying and using our products, I'm going to assume they all love Clippy as much as I do. The little rascal! So, no need to waste time worrying about how users actually feel.

You can start using Clippy on your websites right now!

Fear not my friends! I don't work for MS and this isn't a real proposal. The above is a satirical look at the current state of web "standards" development.

fantasai

@fantasai

Web standardization according to Google? "Nobody outside my team has reviewed or approved of the explainer in my private repo, but if we implement and encourage devs to use it, surely our competitors will agree to implement it [because our market dominance determines compat]".

---

Google have decided the world needs a <toast> element. For the record - I think that's probably a great idea.

But my views don't matter much. They shouldn't matter much. I'm not the average user. I'm not representative of all developers.

The way Google has gone about this seems to be…

1. Ooh! I have a cool idea!
2. Other people in Google agree with me!
3. Other Google projects could benefit from this?
4. Let's stick it in Chrome!
5. Oh, guess we should tell the community what we're doing.

(I'm deliberately simplifying and probably being a bit rude to the people behind this.)

Here's (my) idealised version of how a new element should be introduced:

1. Have a cool idea
2. Speak to real users and see if it meets a user need
3. Publish the (vague) user research and start discussing with peers around the world
4. Design and iterate based on feedback
5. Test with users. Pass/Fail based on beta testing
6. Publish test results
7. Work with community to improve things
8. Etc.

Look, I get the "Move fast! Break things!" attitude. And I think it is exactly right that Google should experiment with the web. We all should! And, again, I think that <toast> is probably a useful addition to HTML.

But the way Google has gone about introducing it to the world betrays a huge lack of empathy for the poor sods who have review standards, for other browsers, for users, and for the broader Web community.

It feels like a Google-designed, Google-approved, Google-benefiting idea which has been dumped onto the Web without any consideration for others.

I know that isn't the case. And I know how many dedicated people have worked hard on this proposal.

For old fart like me, this feels like the Microsoft Internet Explorer days. MS dumping features onto the web and everyone had to do what they say because they're the biggest kid in the playground.

I think the chaps at Google probably think they're the good guys. That they're doing the web a favour. That users love them.

They genuinely don't see that people feel they have to give in to Google's demands or face irrelevance.

To reiterate - I think <toast> is a good idea. But Google have presented it in such an arrogant way - and with no user research - that I'm getting afraid of what they'll do next.

It looks like you've finished writing this blog post. Would you like help publishing it?

(And, a special note for Geeks like me. All analogies break down eventually. They are a rhetorical device used to illustrate a problem space - not to fully map it out. Please don't let the inconsistencies of the analogy be the focus of your comments.)

NHS

@NHSuk

Need help fast, but not sure what to do? Go straight to 111.nhs.uk .
To find out more about NHS 111 including how to use the NHS 111 BSL interpreter service visit nhs.uk/111 #NHS111 pic.x.com/tk18uvm2vy

---

Is it possible to have multiple Sign Languages available to a video?

What you may not know is that British Sign Language and American Sign Language are completely different languages. Not like written English and American English with the occasional difference in spelling, but mutually incomprehensible.

Wouldn't it be nice if users could flip between different Sign Languages as easily as different subtitles?

HTML5 gives us the power to add multiple subtitles to a video. For example:

<video>
   <source src="example.mp4" type="video/mp4">
   <track label="English" kind="subtitles" srclang="en" src="en.vtt" default>
   <track label="Español" kind="subtitles" srclang="es" src="es.vtt">
</video>

How could we do the same for Sign Language?

Overlays

The aim is to overlay one video on top of another. That is, have the main video in the background and the the person signing in front.

Here's a simple way to do it in HTML. Two videos, in a <div>.

<div class="video-container">
   <video class="main" autoplay>
      <source src="video.mp4" type="video/mp4">
   </video>
   <video class="sign" autoplay>
      <source src="bsl.mp4"   type="video/mp4">
   </video>
</div>

Then some CSS to layer one on top of the other:

.video-container {
  position:relative;
  width:400px;
}
.main {
    height: 200px;
    width: 400px;
    float: left;
    position: absolute; 
}
.sign {
    width: 100px;
    position: absolute;
    bottom:-200px;
    right:0px;
}

That gives you this effect:

There's deliberately no audio, and the Signing is not related to the main video. This is just an experiment. My CSS may break in unusual ways!

Source videos Creative Commons - How to greet someone in English and Learn Basic Greetings in British Sign Language.

Three points to note:

1. There's no synchronisation - both are set to autoplay, but some JS magic will be needed to keep them both in sync, or to pause at the same time.
2. No way to switch between different Sign Languages. Again, will need some JS to do that.
3. No transparency.

The last one is very annoying.

Alpha Video

Most Signers are usually "green screened" - that is, the background image is transparent and they are seamlessly overlayed onto the video.

HTML5 videos don't have an "alpha" channel. That is, no transparency. Chrome had an experimental alpha flag - but that doesn't seem to have gone very far.

There are some hacky open source plugins, and a few experiments using canvas - but nothing mainstream.

Separate Video Tracks

The final alternative is to produce multiple videos, each with a different Sign Language superimposed. In which case, you'd need a small user interface asking the user which video they want to see.

Standards

I do some work on web standards - but I'm ignorant about this area. It looks like there was some attempts at standardising having multiple video tracks, or improving the accessibility of web video - but they don't seem to have got much further.

I suppose what I'm looking for is:

<video controls>
  <source src="video.mp4" type="video/mp4">
  <video label="British Sign Language" kind="overlay" srclang="sgn-GB" src="bsl.mp4">
  <track label="English" kind="subtitles"  srclang="en" src="en.vtt" default>
  <audio label="English" kind="Commentary" srclang="en" src="en.mp3" default>
</video>

Would that be useful, I wonder?

So, I decided to join the AC (Advisory Committee) for AMP. I don't want them surrounded with sycophants and yes-men. A few weeks ago, a bunch of the AC met in London for our first physical meeting after several exploratory video calls.

These are my impressions and highlights of the meeting. You should also read the official minutes to get a more rounded view of the issues.

I am not representing my employer while working on the AC. I do not get paid for being a member - although our host (Akamai) provided refreshments, and another member paid for lunch. These views are mine and mine alone. I will be respecting the Chatham House Rule.

AMP isn't loved by publishers

We heard, several times, that publishers don't like AMP. They feel forced to use it because otherwise they don't get into Google's news carousel - right at the top of the search results.

Some people felt aggrieved that all the hard work they'd done to speed up their sites was for nothing. They felt that they had a competitive advantage against slower publishers. That was destroyed by AMP.

My recommendation is that Google stop requiring that organisations use Google's proprietary mark-up in order to benefit from Google's promotion.

AMP is not accessible

There has not been a thorough accessibility review of AMP. Many of the components are not accessible.

This is legally and morally troubling. AMP need to do much better at testing accessibility. I also think that their validator should refuse to pass a page if it doesn't meet a threshold of automatic accessibility testing.

No user research

AMP claims to be doing the best for the user. But they have published no user research about what users want, how they interact with components, or what they have difficulty with. The launch of AMP Email highlights this. It is impossible for a publisher to use without understanding the user needs it attempts to solve.

I don't want AMP to publish videos of users, or other identifiable information. We need to see the same sort of publication as you'd deliver to your CEO.

Without user research support, there's no acceptable route to creating new AMP components.

AMP spreads fake news

When you visit an AMP page, your URL bar shows google.com/amp/.... - that has led to lots of extremely dubious content being shared by people who think they're looking at an "authoritative" Google Page.

Removing the URL bar is not the answer. Users need to be able to see who is actually responsible for publishing the content they are reading. Obfuscating it damages the web ecosystem.

Perhaps Signed Exchanges are the answer?

Signed Exchanges are not the answer

Yet another Google product to solve the mess created by a different Google product! Signed Exchanges are complicated. Basically, a website packages up a page and cryptographically signs it. An entirely different site can then serve the bundle but the browser shows the URL of the original site!

That is, I download a page from Google, but my browser says "example.com".

It looks like Firefox and Safari won't support this. Content Delivery Networks are worried about how much traffic it will take from them. Security experts worry about the holes in the scheme. And publishers fear losing analytics.

It's a clever idea - and possibly really useful for a fully distributed network. But the current implementation looks like Google trying to keep users within its walled garden with no hope of escape.

Browser compatibility

When a user uses Chrome for Android to search Google, they get AMP results. When a user tries the same search in Firefox, they only get regular results. We found the same thing occurring with several other mobile browsers.

Google has effectively said "You have to use our browser on our search engine to get the fastest content written in our langauge."

That strikes me as possibly being anti-competitive and certainly antithetical to the idea of an open and neutral web.

My top recommendations

• Publish all user research
  • Don't allow new components to be created without a clear user story and research to support them.
• Accessibly audit
  • Don't validate pages which can't pass an automated a11y test
• Stop the forced bundling
  • Let users opt-out of seeing AMP pages
  • Don't require AMP for prominent placement
  • Stop discriminating against non-Google browsers
• Reconsider AMP4Email
  • Lots of concerns from smaller email providers
  • Security and archiving concerns
• Work with the ecosystem rather than imposing

Conclusions

The meeting was good natured. While there were some robust discussions, the AC seemed fairly unified that Google had to seriously rework parts of the AMP project.

As I said in the meeting - if it were up to me, I'd go "Well, AMP was an interesting experiment. Now it is time to shut it down and take the lessons learned back through a proper standards process."

I suspect that is unlikely to happen. Google shows no sign of dropping AMP. Mind you, I thought that about Google+ and Inbox, so who knows!

My personal view as advisory committee member - if AMP is to continue then it needs to become a much better citizen of the open web.

W3W is a closed product. It is a for-profit company masquerading as an open standard. And that annoys me.

A brief primer.

• The world is a sphere.
• We can reference any point on the surface of Earth using two co-ordinates, Longitude and Latitude.
• Long/Lat are numbers. They can be as precise or as vague as needed.
• Humans can't remember long strings of numbers, and reading them out is difficult.

W3W aims to solve this. It splits the world into a grid, and gives every square a unique three-word phrase.

So the location 51.50799,-0.12803 becomes ///mile.crazy.shade

Brilliant, right?

No.

Here's all the problems I have with W3W.

It isn't open

The algorithm used to generate the words is proprietary. You are not allowed to see it. You cannot find out your location without asking W3W for permission.

If you want permission, you have to agree to some pretty long terms and conditions. And understand their privacy policy. Oh, and an API agreement. And then make sure you don't infringe their patents.

You cannot store locations. You have to let them analyse the locations you look up. Want to use more than 10,000 addresses? Contact them for prices!

It is the antithesis of open.

Cost

W3W refuses to publish their prices. You have to contact their sales team if you want to know what it will cost your organisation.

Open standards are free to use.

Earthquakes

When an earthquake struck Japan, street addresses didn't change but that their physical location did.

That is, a street address is still 42 Acacia Avenue - but the Longitude and Latitude has changed.

Perhaps you think this is an edge case? It isn't. Australia is drifting so fast that GPS can't keep up.

How does W3W deal with this? Their grid is static, so any tectonic activity means your W3W changes.

Internationalisation

Numbers are fairly universal. Lots of countries use 0-9. English words are not universal. How does W3W deal with this?

Is "cat.dog.goose" straight translated into French? No! Each language has its own word list.

There is no way to translate between languages. You have to beg W3W for permission for access to their API. They do not publish their word lists or the mappings between them.

So, if I want to tell a French speaker where ///mile.crazy.shade is, I have to use ///embouchure.adjuger.saladier

Loosely translated back as ///mouth.award.bowl an entirely different location!

You're not allowed to know what word lists W3W use. They take a paternalistic attitude to creating their lists - they know best. You cannot propose changes.

Anecdotally, their non-English word lists are confusing even for native speakers.

Cultural Respect

Numbers are (mostly) culturally neutral. Words are not. Is "mile.crazy.shade" a respectful name for a war memorial? How about ///tribes.hurt.stumpy for a temple?

How do you feel about ///weepy.lulls.emerge and ///grouchy.hormone.elevating both being at Auschwitz? Or ///klartext.bestückt.vermuten - "cleartext stocked suspect"?

This is a classic computer science problem. Every sufficiently long word list can eventually be recombined into a potentially offensive phrase.

Open Washing

W3W know that the majority of technical people are not fooled by their attempts to lock down addressing.

They include this paragraph to attempt to prove their openness:

If we, what3words ltd, are ever unable to maintain the what3words technology or make arrangements for it to be maintained by a third-party (with that third-party being willing to make this same commitment), then we will release our source code into the public domain. We will do this in such a way and with suitable licences and documentation to ensure that any and all users of what3words, whether they are individuals, businesses, charitable organisations, aid agencies, governments or anyone else can continue to rely on the what3words system.

I don't know how they propose to bind a successor organisation. They don't say what licences they will use. If they go bust, there's no guarantee they'll be legally able to release this code, nor may they have the time to do so.

There's nothing stopping W3W from releasing their algorithms now, subjecting them to scrutiny by the standards community. They could build up a community of experts to help improve the system, they could work with existing mapping efforts, they could help build a useful and open standard.

But they don't. They guard their secrets and actively promote their proprietary product in the hope it will become widely accepted and then they can engage in rent-seeking behaviour.

This is not a new argument

My mate Leigh wrote about this three years ago. Lots of people have criticised W3W.

Andy Allan @gravitystorm@gravitystorm.co.uk

@gravitystorm

.@what3words is bad technical idea, and ethically terrible too. But all VCs like patented economic rents so the juggernaut rolls on. #geomob

---

But W3W have a great PR team - pushing press releases which are then reported as uncritical news.

The most recent press release contains a ludicrous example:

• Person dials the emergency services
• Person doesn't know their location
• Emergency services sends the person a link
• Person clicks on link, opens web page
• Web page geolocates user and displays their W3W location
• Person reads out their W3W phrase to the emergency services

Here's the thing... If the person's phone has a data connection - the web page can just send the geolocation directly back to the emergency services! No need to get a human to read it out, then another human to listen and type it in to a different system.

There is literally no need for W3W in this scenario. If you have a data connection, you can send your precise location without an intermediary.

What Next?

W3W succeeds because it has a superficially simple solution to a complex problems. It is a brilliant lesson in how marketing and PR can help a technologically inferior project look like it is a global open solution.

I'm not joking. Their branding firm says:

Edelman helped what3words frame their story to be compelling by tapping into human emotion. We also created a story for CEO Chris Sheldrick about how having an address can drive social transformation and business efficiency, securing profiling and speaker opportunities. Through paid social campaigns we re-targeted these stories, getting through to the decision makers that mattered most. We articulated their purpose narrative and refined their strategy to engage investors and excite the media.

It takes too much time to refute all their claims - but we must. Whenever you see people mentioning What3Words, politely remind them that it is not an open standard and should be avoided.

Terence Eden is on Mastodon

@edent

Your periodic reminder that W3W is a closed and proprietary system, with opaque licencing, hefty pricing, and poor internationalisation.
It does have a very good PR team though.

BBC News Technology

@BBCTech

Three-unique-words 'map' used to rescue mother and child bbc.in/2FBnJ5O

---

---

Sadly, Hadley Beeman does not have a TARDIS (Well, as far as any of us can tell...). What she does have is an interesting new job for me. Take a deep breath, because it's a heck of a long title:

Senior Technology Advisor to the Chief Technology Advisor to the Secretary of State for Health and Social Care

Sweet! So, what does a STAttCTAttSoSfHaSC do? Apart from scoring 25 points in Scrabble, obviously?

I'm going to help improve the health and social care system - within and beyond the NHS. Not all of it, and not necessarily the bits that you'll see, but some of the deep magick which runs the technology behind it.

My job will be to keep saying "Hey! Let's use internationally recognised, free and open standards. Y'know, rather than handing a single company a life-long monopoly."

I'll also occasionally point my Sonic Screwdriver at a bit of kit and say "If we reverse the polarity of the neutron flow, we may be able to replace this with Open Source Software."

This is akin to redesigning and replacing the engine of a plane, while it is in flight. Without losing altitude or causing the passengers any discomfort. While under attack from Weeping Angels.

If I'm lucky, the team will help set the course for the future of NHS technology. I'm not talking AI-powered iPhone apps to show you your polyps in virtual reality - I'm talking about your consultant being able to share data with your GP without resorting to SnapChat. Or fax.

Can we put user needs at the heart of technology standards decisions? Can we give Clinical Commissioning Groups the tools and frameworks they need to make smarter decisions about technology? Can we make things open and make things better?

There's only one way to find out...!

This is a temporary secondment. I'm grateful to the whole team at GDS for letting me go on this adventure. Much like the Meta-Crisis 10th Doctor (do keep up), this role has a limited lifespan. Looks like the 2019 season of "The Terence Eden Adventures" is going to be epic!

Allons-y, Alonso!

There may only be one title in any document. It should identify the content of the document in a fairly wide context. It may not contain anchors, paragraph marks, or highlighting.

Remarkably little has changed in the intervening decades. The modern HTML5 spec defines it as only containing text. That means you can't nest tags inside it. For example, this is invalid: <title>I love <em>you</em>!</title> Try it - you won't get emphasised text.

This is a problem for internationalisation and accessibility - and one the HTML5 editors have been wrestling with.

(Usual disclaimer, I'm HMG's representative on the W3C's Advisory Committee and I'm an editor on HTML5 - these are my personal views.)

Let's imagine this potential page title which includes multiple languages:

<html lang="en-gb">
<head>
   <title>A review of La vie en rose</title>
   ...

At the moment a screen reader would assume the whole title, including "la vie en rose", is in British English (the document's language). Hearing a computerised voice reading French in a British accent is akin to hearing Vogon poetry read in Dick Van Dyke's "cockornay". Unpleasant for all involved.

What we want to write is something like:

<html lang="en-gb">
<head>
   <title>
      <span lang="en">A review of</span> <span lang="fr">La vie en rose</span>
   </title>
   ...

This is invalid HTML - in most browsers it will display like this:

Incidentally, this is a long known limitation. How can we fix it?

Possible Solutions

1. Change the element
2. Make a new meta element
3. Something else

Changing the element

This is impossible if we want to maintain backwards compatibility. Either we accept that older browsers will see garbled titles, or that newer browsers may get confused by older pages.

Any page with a title like <title>This page is about the <span> element</title> is going to require a work-around for new browsers.

New meta element

How about a new element like <title-multilang>

Nope! If a browser doesn't recognise an element in the <head> it will print it in the body.

Something else

Here are two existing things which could be repurposed.

The accessibility attribute longdesc lets an author place a "long description" elsewhere in the page. It is currently only valid on the <img> element. But let's imagine it used elsewhere:

<title longdesc="#desc">A review of La vie en rose</title>
</head>
<body>
   <h1 id="desc"><span lang="en">A review of</span> <span lang="fr">La vie en rose</span></h1>
   ...

That might help screen readers - but it doesn't improve the semantics of the page.

Here's some Schema.org MicroData:

<html lang="en-gb">
<head itemscope itemtype="https://schema.org/WebPage">
    <meta itemprop="alternativeHeadline" content="A review of <span lang='fr'>La vie en rose</span>"/>
    <title>...

That might be better for semantics, but would require screen readers to support it.

We could also hope that AI improves sufficiently that it can immediately recognise individual words within a sentence are from a different language. A task which befuddles most humans.

Next steps

What should be done? If you're interested in working on this - come join in with the HTML5 development process at the W3C

Recently, I've seen lots of people getting het up about its "misuse" - so I want to clarify a few things.

The GDPR (General Data Protection Regulation) gives people in the EU strong data protection rights.

Some companies do not wish to comply with these laws. Those companies block content to people within the EU.

Here's the kicker - they use HTTP 451 "Unavailable for Legal Reasons".

Sven Slootweg 🏳️‍🌈 (@joepie91@pixie.town)

@joepie91

Well, this is the first time I've seen a website use the "451: Unavailable For Legal Reasons" HTTP status code. Who would've thought that it would be a result of the GDPR... pic.x.com/nzv7obo9a0

---

Is this the correct use of the status code? Some people are quite sure that it is not right.

I've had extended discussion with people on social media who are convinced that 451 should only be used in the case of government censorship. Those people are wrong.

Here's what I reckon

The RFC which specifies HTTP 451 does not mention censorship once. Similarly, there are no mentions of governments whatsoever.

From the introduction:

This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when a server operator has received a legal demand to deny access to a resource or to a set of resources that includes the requested resource.

What is a legal demand? And what does it mean to receive one? (I don't want this to go all "It depends upon what the meaning of the word 'is' is" - but I think this is important).

If a court orders you to remove an illicit photo of me wearing a mankini, you would have received a legal demand. 451 would be appropriate.

What about if my lawyer sends you an email which says "Take down that photo of Terence wearing a mankini or we'll sue you for a million quid"? I think 451 would be appropriate.

Let's read further. The actual specification is (emphasis added):

This status code indicates that the server is denying access to the resource as a consequence of a legal demand.

• One does not have to have specifically received a demand. I've never personally been instructed by the courts not to deface money - it's just what UK law demands.
• The specification says nothing about the validity of the demand. Perhaps the demand is mistaken, or wrong, or legally deficient - you can still use 451 while attempting to clarify.
• The RFC doesn't mention specificity. Perhaps the law bans a single page on your site - using 451 on the whole site may make sense for you.

These companies have seen a legal demand from EU countries that their citizens' rights must be protected. If they want to continue to abuse their users' privacy without legal consequence, they should block users who could successfully sue them. 451 is appropriate.

If the only way to access a resource would involve serving content which breaks the law, then 451 is appropriate.

We can take another theoretical example. UK law bans the sale of pistols and some other weaponry. A US site may choose to use 451 to refuse service to users in the UK - even if the site believes in the right to arm bears. They may not have specifically received a legal demand, but UK law does demand that they don't sell to people in its territory.

The easiest fix would be for these companies to comply with the law and respect their users' privacy. That's what the law demands of them.

Media comprehension

I suspect that lots of people get hung up on the number 451 being a direct reference to Ray Bradbury's famous novel about censorship. Except, like in this case, Fahrenheit 451 is not about censorship.

Luckily, the Internet works due to rough consensus and running code. No one gets damaged if an http code is used incorrectly. And if the majority of sites use 451 to protect users from endless data mining, well that's just fine with me.

Anyway, that's what I reckon. Feel free to disagree with me - I promise I won't sue you. This does not confer any legally binding protection against lawsuits brought by me. All rights reserved. See back of packet for full terms and conditions. Errors and Omissions Excluded. Not valid in the state of Kentucky. Nil illegitimi carborundum.

1963 - ASCII

In the beginning* was ASCII. A standard way for computers to exchange text. ASCII was originally designed with 7 bits - that means 128 possible symbols. That ought to be enough for everyone, right?

Wrong! ASCII is the American Code for Information Interchange. It contains a $ symbol, but nothing for other currencies. That's a problem because we don't all speak American.

*ASCII has its origins in the telegraph codes of the early 20th Century. They derive from Baudot codes from the 19th Century.

1981 - Extended ASCII

So ASCII gradually morphed into an 8 bit language - and that's where the problems began. Symbols 0-127 had already been standardised and accepted. What about symbols 128 - 255?

Because of the vast range of symbols needed for worldwide communication - and only 256 symbols available in an 8 bit language - computers began to rely on "code pages". The idea is simple, the start of a file contains a code to say what language the document is written in. The computer uses that to determine which set of symbols to use.

In 1981, IBM released their first Personal Computer. It used code page 437 for English.

Each human script / alphabet needed its own code page. For example Greek uses 737 and Cyrillic uses 855. This means that the same code can be rendered multiple different ways depending on which encoding is used.

Here's how symbols 162, 163, and 164 are rendered in various code pages.

As you can see, characters are displayed depending on which encoding you use. If the computer gets the encoding wrong, your text will become incomprehensible mix of various languages.

This made everyone who worked with computers very angry.

1983 - DEC

This is silly! You can't have the same code representing different symbols. That's too confusing. So, in 1983, DEC introduced yet another encoding standard - the Multinational Character Set.

On the DEC VT100, the British Keyboard Selection has the £ symbol in position 35 of extended ASCII (35 + 128 = 163). This becomes important later.

Of course, if you sent text from a DEC to an IBM, it would still get garbled unless you knew exactly what encoding was being used.

People got even angrier.

1987

Eventually, ISO published 8859-1 - commonly known as Latin-1.

It takes most of the previous standards and juggles them around a bit, to put them in a somewhat logical order. Here's a snippet of how it compares to code page 437.

8859-1 defines the first 256 symbols and declares that there shall be no deviation from that. Microsoft then immediately deviates with their Windows 1252 encoding.

Everyone hates Microsoft.

1991 - Unicode!

In the early 1990s, Unicode was born out of the earlier Universal Coded Character Set. It attempts to create a standard way to encode all human text. In order to maintain backwards compatibility with existing documents, the first 256 characters of Unicode are identical to ISO 8859-1 (Latin 1).

A new era of peace and prosperity was ushered in. Everyone now uses Unicode. Nation shall speak peace unto Nation!

2017 - Why hasn't this been sorted out yet?

Here's what's happening. I think.

• The restaurateur uses their till and types up the price list.
• The till uses Unicode and the £ symbol is stored as number 163.
• The till connects to a printer.
• The till sends text to the printer as a series of 8 bit codes.
• The printer doesn't know which code page to use, so makes a best guess.
• The printer's manufacturer decided to fall back to the lowest common denominator - code page 437.
• 163 is translated to ú.
• The customer gets confused and writes a blog post.

Over 30 years later and a modern receipt printer is still using IBM's code page 437! It just refuses to die!

Even today, on modern windows machines, typing alt+163 will default to 437 and print ú.

As I tap my modern Android phone on the contactless credit card reader, and as bits fly through the air like færies doing my bidding, the whole of our modern world is still underpinned by an ancient and decrepit standard which occasionally pokes its head out of the woodwork just to let us know it is still lurking.

It's turtles all the way down!

ASK Italian last week PJ Evans

I went to see a film today. I thought @edent might appreciate what I saw when buying my ticket. Skylar

Or is it?

Of course, when we look at the full receipt, we notice something weird.

The £ is printed just fine on some parts of the receipt!

⨈Һ?ʈ ╤ћᘓ ?ᵁʗꗪ❓

By "Chat Apps", I'm talking about the new wave of messengers - WhatsApp, WeChat, Telegram, Wire, and the like.

What do I mean by "URI Scheme"? You're probably familiar with:

• https://example.com

The "scheme" is https - it tells the computer "Open the web browser and load the specified resource."

You may also be aware of:

• mailto:me@example.com

This tells the computer to open the email app and fill in "me@example.com" as the destination address.

Also fairly common are:

• tel:+447700900123 open the phone dialler and prepare to dial this number.
• sms:+447700900123 open the text message app and use this number.
• skype:terence.eden open the Skype app and contact the specified user.

There are hundreds of URI schemes in use. Older chat apps like ICQ and AIM made use of schemes - yet modern chat apps mostly ignore them. Why?

At the moment, there's is literally no way I can send you a link which says "This is my account on Wire, chat to me using the app."

URI Support

Firstly, it's not all bad news! There are a few apps which do have rudimentary URI support.

WhatsApp

There is an undocumented URI Scheme:

• whatsapp://send/?phone=447700900123

In repeated testing with friends, it performed inconsistently. Sometimes it would open a chat window, other times it gave an error.

Telegram

Again, an undocumented URI Scheme. This is how to look up users by username:

• tg://resolve?domain=edent

In tests it worked reliably across all platforms.

WeChat

The popular Chinese messenger has the bare minimum of a scheme:

• weixin://

That will launch the app, if installed. That's it. There's no way to target a specific user.

When it all goes wrong

We take it for granted that everyone who clicks on a link has a web browser and email client installed. If they're on mobile, they probably have the ability to make phone calls and send SMS.

So what happens if you don't have a chat app installed? This hot mess:

It's pretty much the same on Android or iPhone - the user is sent to an unhelpful error page.

Why not use an HTTP resolver?

Both Telegram & WhatsApp let you look up a user on their website and then redirect you to the app.

• https://t.me/edent
• https://api.whatsapp.com/send?phone=447700900123

If you open that in your browser, it will take you to the provider's site and they will then redirect you to their app.

This introduces a number of problems.

• An extra step which adds latency.
  • It forces everything through the browser - so you have to wait for that to load, resolve, and close before you can chat.
• Leaks metadata.
  • Your ISP now knows that you're doing a lookup.
• Increases vendor lock in.
  • What if Telegram decides that it will only allow lookups from registered users?
• Security
  • What if Telegram lies about the resolved account?
• It doesn't actually work
  • There's no way for a website to tell if the user has an app installed.
  • The user is often redirected to a URI they can't open.

For now, it seems that using an HTTP resolver is the least worst option. It can easily be shared and understood by users - and it doesn't tie the receiver in to a specific technology like Android Intents.

But, for the future - perhaps there's a better way?

Federation

Given that WhatsApp, Wire, Allo, Facebook and many others all use the Open Whisper Systems protocol, it seem bizarre to me that they can't communicate with each other. Imagine if your iPhone couldn't make calls to your friend's Nokia - unacceptable!

Similarly, all the major voice/video calling apps are converging on WebRTC to pipe your call around the world. The app is merely the user interface. You may prefer to use OutLook, I prefer Gmail - but they both use email as the underlying communications platform.

I've explained before why using a mobile phone number is a poor choice of identifier (mostly because the user doesn't own it and can't transfer it overseas) - but given that's what most people use now, it makes sense to include it as an option.

Problem Statement

I want to share a link with someone so they can talk to me on my preferred chat app.

Solution

Let's create a new URI scheme - chat:

It is short and it doesn't tie itself to a specific action (videocall:, text:, voice:), or to a specific protocol (Signal, WebRTC).

When clicking on a chat: link, your device will either:

• Open up your chat client.
• If you have several installed, give you a choice of chat client.

Let's take a look at some examples:

Just a phone number

chat:+447700900123

• An internationally formatted E.164 phone number.
• The +CountryCode at the start is mandatory.
• This is to disambiguate between users with similar numbers but provided by different countries.

This assumes that both parties are on the same chat app.

If I'm on WhatsApp and my friend only has WeChat installed - what happens? Well, part of Federation means that you can talk across different chat apps.

Named account at a provider

chat:me@example.com

• This will open the "example.com" chat app.
• Possible confusion with an email address (see later)?
• Might be more sensible to use account@com.example? But users are unlikely to understand that.
• It could be chat:@shkspr.mobi and let my domain manage where I want the chat to be directed.
• Could just use "me@whatsapp" - does a hierarchy need to be imposed?

A name can also be a number

chat:+447700900123@whatsapp

With specific actions

chat:me@example.com?body=URL%20Encoded%20String

• This pre-fills a message to be sent to the specific user.
• Identical syntax to email's mailto:
• Could also include base64 encoded data for images and other attachments.

With multiple participants

chat:me@example.com,+447700900123,alice@example.org

• Start a chat with several participants.
• Again, identical to email's mailto syntax.
• Could also be combined with the ?body= above.

Ephemeral Support

chat:me@example.com?timeout=60&body=This message will self destruct

• Requests that the receiving client will discard the message after a timeout specified in seconds.
• It is up to the receiver to comply with this request.

And Then...

Are URI Schemes the future once more? I think they have to be. Messaging app providers will shut down (MySpace), people will migrate away from platforms (ICQ), phone numbers and email addresses will change - but people will still want to chat with the minimum of fuss.