While perusing the programme on the National Theatre website I stumbled upon a little bug. The incredible Ronkẹ Adékọluẹ́jọ́ has her name rendered in a most unusual style:

It rendered just fine in Chrome - but both Firefox and Safari misrendered some of the accented characters.

Here's a minimum viable demo to show what's happening:

Fonts are hard, OK?!?!

Broadly speaking⁰, accented characters can be made in two way.

1. Pre-composed. There is a separate code for the character é
2. Combining. The plain letter e is immediately followed by the combining character ◌́ and the computer smushes them together.

Similarly, a font file can have separate little drawings for each accented character or it can have separate accents.

In this case, the National Theatre is using the font "Helvetica Now Display W04".

The web font contains é (U+00E9) and both ◌́ (U+0301) & ̣◌ (U+0323).

But doesn't include ẹ (U+1EB9) or ọ (U+1ECD).

So the ẹ́ and ọ́ have to be made by combining characters in the font.

On Chrome this works. On Firefox and Safari, it seems to break when the CSS is set to font-weight: normal;. This causes the browser to render those characters in the default fallback font - hence the slightly weird look.

Next Steps

I've raised a bug with Firefox and one with WebKit.

Of course, it might be that they're doing the right thing and Chrome is in the wrong - but I think that's unlikely.

Now, time to fix the font I use on this website to prevent any rendering errors!

So how do computers deal with dates before The Beatles' Abbey Road was top of the UK album² charts?

Negative numbers! Most modern computers can deal with dates far in the past and, hopefully, far into the future. Again, for boring technical reasons, lots of computers can only save files with a date no earlier than 13th December 1901³.

When you download a file from the Internet, the sending server can tell you when that file was last modified. That's useful if you only want to download the file if it has changed since you last got it.

It presents the date using RFC 1123 format for reasons which are lost to the ages.

< Last-Modified: Wed, 09 Oct 1940 16:45:49 +0100

Great!

If you use the venerable wget utility, it will happily save the file on your disk and tell you that is when it was created.

But what if you use curl -OR to download the file? The -R option says:

Make curl attempt to figure out the timestamp of the remote file that is getting downloaded, and if that is available make the local file get that same timestamp.

THIS IS A LIE!⁴

If curl sees a date with a negative time, it pretends that the past doesn't exist and that what you really wanted was to save the file with today's date and time.

Why does it do this?

I think it is because this code only checks for times ≥ 0. Which, I guess, is pretty reasonable. There weren't many computers around before the 1970s⁵ so the chances of finding a file which predates disco are slim.

Should we storm the barricades and demand this temporal anomaly be rectified?⁶ Nah. I've raised it as a discussion item on curl's GitHub.

If you have strong opinions about this - please join in the discussion⁷.

I recently stumbled across what I think is a little bug which might be caused by a misreading of the SVG Animation specification. Here you should see two overlapping circles gradually appear:

If you're on Chrome, you might only see one circle animate. Why? Bloody semicolons! The bane of every programmer's existence².

The specification for SVG Animation has this text for human readers:

keyTimes

A semicolon-separated list of time values used to control the pacing of the animation. Each time in the list corresponds to a value in the ‘values’ attribute list, and defines when the value is used in the animation function.

[…]

If the last semicolon separator is followed by either just white space or no more characters, ignore both the separator and the trailing white space.

To me, that isn't ambiguous. The text keyTimes="0; 1;" has a final semicolon with nothing after it. Therefore it should be ignored. Instead, Chrome throws an hissyfit and says Error: <animate> attribute keyTimes: Invalid value, "0; 1;".

But maybe the humans who wrote the description were sloppy. There's also a machine-readable formal specification. It defines the acceptable sequence as being:

<number> [; <number>]* ;?

This isn't quite Backus–Naur form³, but rather CSS Values.

• The <number> is a component.
• The [ and ] are grouping combinators.
• The * and ? are component multipliers
  • * "indicates that the preceding type, word, or group occurs zero or more times."
  • ? "indicates that the preceding type, word, or group is optional (occurs zero or one times)."
• The ; is just a semicolon⁴.

Reading the definition tells us that a valid value will be a number, followed by zero-or-more groups of "semicolon and another number" with an optional final semicolon.

So, based on my reading, I think Chrome is wrong to throw an error here. Both Firefox and Safari work with a trailing semicolon.

Accordingly, I've raised a bug with the Chromium team. If you think I have erred in this matter, please let me know.

I've set up Windows so the taskbar disappears whenever my cursor isn't at the bottom of the screen. When my mouse touches the bottom, the bar appears. Lovely! But Outlook breaks this functionality - which I'm pretty sure existed back in Windows 95.

Microsoft have received several complaints about this⁰, but done nothing.

Anyway, here's two way you can fix it. Neither are particularly good, but they do work.

Don't maximise

Rather than pressing the big square icon in the top right of the window, just drag the edges of your window to be as big as possible.

This is a stupid fix. Your window is now the same size as your screen but technically isn't maximised. So the taskbar doesn't get stuck behind Outlook.

Use an external screen

This problem only occurs on my laptop's screen. So I plugged in an external monitor and moved the Outlook window to there.

When maximised, Outlook doesn't prevent the taskbar from appearing.

What causes this problem

I'm pretty sure the New Outlook uses "fullscreen" rather than "maximise". That mode is often used for things like games where you don't want a taskbar suddenly appearing.

But the root cause is Microsoft's decision to ignore customer feedback. Look, bugs happen. That's just a fact of life. But absolutely no-one from the MS team is looking at customer complaints. Being "feature-driven" is great - but you need to close the loop to see if those features are working for customers.

Sadly, that's not always enough.

Two years ago today, I wrote what I thought was a pretty comprehensive bug report for Android OS.

I included links to public forums where other people were experiencing the issue. I even posted some code which was designed to fix the issue.

Like most public Android bugs, it was assigned to some anonymous drone within the Googleplex - whereupon it was promptly ignored, never to be fixed.

The bug itself is quite minor. But it shows up in all sorts of places, and probably causes people around the world daily annoyance. I don't think it is a security bug - although I'd love to be proved wrong - so there's not much incentive for Google to fix things.

I get that Google receives thousands of bug reports. And I know that triaging them must be a time-consuming problem.

Open Source maintainers don't have to take orders from their users, nor do they have to prioritise trivial complaints. But it is just so frustrating to be unable to make even the merest dent in a bug.

See Chrome Bug #1242315 for details.

Demo

Here's a video of me on one site (Twistory.ml) opening a link to Twitter in a new tab. Twitter's mobile site contains a Web Manifest which should prompt the user to install an app. Rather than displaying this pop-up on Twitter's tab, Chrome displays it over the unrelated tab.

Why this is a problem

Here's a (somewhat unlikely) scenario.

You're on, for example, Reddit's website and see an interesting looking link to an external site. You open it in a new tab. All of a sudden, a pop-up appears saying "Reddit is better in the app! Click to download!!"

You download it. Unbeknownst to you, the pop-up was from the external site. They saw your referer header and automatically crafted a manifest file which sends you to a malicious copy-cat app. That app steals your password for Reddit, clones your identity, and kills your puppy.

Google's response

I was expecting Google to close this as WONTFIX. In my experience, Google's attitude to lots of bugs is the same as Steve Job's infamous "You're holding it wrong". Blame the user for not understanding how Google's poorly-tested and confusing products work.

But, to be fair, it was taken seriously. I didn't have to provide any extra detail and, while it was low severity, it was fixed promptly. Kudos!

Then came the agonising wait to see whether Google would pay out millions of dollars for this flaw...

Bounty

For UI bugs like this, Google tends to award $500 - see 1136714, 1133183, and 841622. Although if you can draw over the security UI, the rewards are much higher.

So I was pleasantly surprised to win a US$1,000 bounty!

Perhaps I could have sold it on the DarkWeb™ for digital Beanie Babies totally legitimate crypto-currency? Nah. Too much hassle! I'm going to plough the money into our OpenBenches project.

Timeline

• 2021-08-23 Discovered and disclosed. Within a few hours it was accepted, and triaged. With the (fair) comment that "This doesn't look very scary to me."
• 2021-08-26 Marked as fixed by this commit
• 2021-08-27 Further patches for related issue
• 2021-09-28 Given a gentle nudge, the Reward Panel offered $1k.
• 2021-10-08 After an annoying amount of back-and-forth, Google accepted my registration on their supplier platform. The cause of the delay? I used the W8 form from the IRS.gov site - and Google wanted me to use an older one 🙄
• 2021-11-01 After signing up on their supplier payment platform and jumping through yet more hoops, US$992.50 was deposited in my TransferWise account. Where's the missing $7.50? TransferWise fees? Plus, obviously, a fee to transfer it to GBP and then out to my normal bank account. After all the conversion and fees, it came to £722.64. Quite why the international behemoth Google can't pay in a local currency, I've no idea.
• 2021-12-03 Bug report set to public.
• 2021-12-04 Blog post published.

What's causing this?

Try opening this link to a window size detector in a background tab. Then visit that tab.

On Chrome, this is what I see.

If I hit the refresh button on that tab, the Outer window size snaps back:

What's going on?

According to the specification:

The outerWidth attribute must return the width of the client window. If there is no client window this attribute must return zero.

This is where I get confused. The inner width & height are the amount of space the the browser has to display web content - so ignores the browser bar, menu bars, window decorations etc. The outer width & height are the total amount of space the browser window has.

How can a browser window have no outer size, but simultaneously have an inner size???!?!

There is a client window. The tab may be rendering away in the background - but its parent still has a non-zero size.

There has been a bug report open on Chrome about this since 2017.

Firefox takes a different approach. On desktop, both outer and inner are reported correctly for background tabs. On mobile, both outer and inner dimensions are set to zero. This may change as it is a potential fingerprinting target.

So, web developers, please don't rely on window.innerHeight and window.outerHeight - users may be opening your site in the background, which causes the browser to lie to you.

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.

My mobile network provider sent me this message:

I clicked on the link, and got this error message from their website:

The error is caused by the trailing full-stop.

Remove the full-stop and the page loads.

There are four potential culprits here...

Virgin Media's Web Team

Should their website handle stray punctuation at the end of a URl?

Most webservers can be configured to take users to the page the server thinks they intended to go. This is mostly useful behaviour, but occasionally falls foul of the common DWIM (Do What I Mean) problems.

Even if the web team don't redirect, they should notice the elevated number of 404 errors and investigate the cause of it.

Whisper Systems' Signal App

My SMS app should parse URls without trailing punctuation. It is rare that a URl will deliberately end with a punctuation mark. This issue has been raised with the team before.

Apparently, according to the developers, this is a problem with Android's native library

Android's URl Parsing Library

The same question as above. Android has a built in Web URl regular expression. There are reports that it is inconsistent in the way it parses URls.

A URl which ends with a full-stop is valid. There is a semantic difference between /page and /page. or /?id=a and /?id=a.

But the RFC doesn't take into account how humans actually communicate.

If I send a message saying "visit example.com/go, then example.com/next!" do I really mean for the , and ! to be part of the path?

I can't find any evidence of Google testing this feature with users, nor a test suite to show people what URls are and are not matched.

It appears that the library only includes the punctuation if it is the last character in a string.

Virgin Media's Marketing Team

These are who I think the real villains. Software has bugs. Part of any communications strategy is to test your messages to see whether they work. Not just as calls-to-action, but whether they actually work.

In this case, Virgin should have tested their message on a range of handsets and popular SMS apps. If they had tested the end-to-end journey on Android, this wouldn't have happened.

What next

There's no point me asking Virgin to fix this. They have dreadful customer service and seem content to have a crappy user experience.

It's not Signal's fault that Android's parsing is buggy. Both Signal and Telegram greedily gobble up the . and treat it as part of the link. Interestingly, WhatsApp doesn't. I assume WhatsApp uses its own library.

So, I've raise a bug with Android where - no doubt - it will languish untouched for the next hundred years.

The Amazon 4K Fire Stick is a pretty cool bit of kit. It's an Android device which can push 4K HDR video with surround sound to your TV. But, like any technology, it's buggy. Here's the bug report I've tried to send to Amazon and the BBC. They haven't answered - so I'm publishing it here as well.

BBC iPlayer supplies 4K video - but the app doesn't switch to 4K mode, it stays at 1080p.

Amazon debug

To turn on the Fire stick's debug mode - and get access to X-Ray - follow these instructions.

This lets you see the bandwidth being used, HDCP information, and audio/video information. Here's a 4K presentation via Amazon's own video player. In the top left is the HDMI output information and bandwidth stats. On the right is the video codec data.

iPlayer

Within iPlayer you can opt-in to the beta programme, this gives you access to 4K content. But let's take a look at the debug information. 4K video is being streamed at 25fps. But if we look in the top left corner, the app hasn't switched out of 1080p @ 60fps.

The end result is a juddering rescaled mess.

So, if you or a friend works for either Amazon or the BBC, please ask them to take a look, eh?

The original Android phone - HTC Dream - had 192MB of RAM. The latest Android phones tend to have 6GB. A 32 times increase in a decade. Laptops have also leapt forwards in speed and memory. Sadly, no one on the Gmail team has noticed.

It's 2019, and Gmail app users are still seeing the dreaded "[Message Clipped] View entire message" error.

It's just as bad on the web version of Gmail - even on Desktop Chrome.

Google don't even do fancy AI magic to truncate these messages. You'd think they'd truncate at the end of a word. Or even in the middle of a word. They don't.

Nope, just slam straight through that HTML. YOLO!

What causes this? For unknown reasons, Gmail truncates messages at 102KB. That's about half the storage space of a floppy disk.

I'm talking 🖬, not 💾!

This is annoying for people sending newsletters - even the mighty MailChimp can do no more than offer some tips to shrink your latest newsletter.

Worse still, marketing emails know that if they pad out their messages, they can hide the unsubscribe link!

Oh, and as a bonus, if you click on "View entire message" - you get the old version of Gmail and Google's logo.

Google updated their logo in 2015. You'd think in the last four years, someone on the Gmail team would have received a long email and then filed a bug report. But no.

We can argue about whether emails should be chonkie-bois or not. But they are. People want full styling, images, and fancy features - not just ASCII text and the occasional uuencoded attachment. That's the world we're in now.

What can be done? There's literally no point me taking this up with Google. People have been complaining about this for over a decade and nothing has been done to fix it.

"User-focussed" my shiny metal arse.

So, here's a whinging blog post which - if I'm very lucky - won't make Google lock me out of my account again.

Bill Gates probably didn't say 640KB ought to be enough for anyone - but someone in the bowels of Google sure as hell believes 102KB ought to be enough for any email.

What happens if you use CSS to change the opacity of an emoji?

Here's a unicorn, with a pink font colour:

🦄 Unicorn

Let's wrap that in this scrap of CSS to make it 50% opaque.

color: rgba(255, 105, 180, 0.5);

🦄 Unicorn

Hopefully, you see a semi-transparent philosophical argument. What if we set the opacity to 0.0 - that is, completely transparent?

🦄 Unicorn

There's a shunicorn there. If you don't believe me, try highlighting it!

Now, let's try a see-though beastie, but this time adding a drop-shadow:

color: rgba(255, 105, 180, 0.5); text-shadow: .2em .2em .2em #000;

🦄 Unicorn

Good! And now fully transparent text plus a drop-shadow:

color: rgba(255, 105, 180, 0); text-shadow: .2em .2em .2em #000;

🦄 Unicorn

On Firefox, the text is invisible, but the emoji is completely visible - like this...

This bug is not present on Firefox for Android, nor Chromium for Linux.

The only way on Firefox, to get a completely invisible pink unicorn plus a drop shadow is to use:

color: rgba(255, 105, 180, 0.002); text-shadow: .2em .2em .2em #000;

🦄 Unicorn

color: rgba(255, 105, 180, 0.001); text-shadow: .2em .2em .2em #000;

🦄 Unicorn

0.002 is invisible, but 0.001 is visible.

I've raised this as a bug on Mozilla's Bugzilla.

In the meantime, if you can see the invisible pink unicorn, please let me know. Or contact a theologian.

I recently bought the new 4K Amazon Fire Stick. It's a little Android dongle which plays videos. It's neat - but quite often displays weird text errors.

Take the kids' TV show House of Anubis, the Fire displays the description like this:

Looking at the source code for the description:

That's the character "private use two" (U+0092). What on earth is that doing there?

Well, in the ancient Windows-1252 encoding, 0x92 is ’ - the curly quote. It looks like someone has tried to write "in the house’s attic" on an old Windows machine, Amazon have ingested the data thinking it was Unicode, and displayed an error!

Here's "Young Sheldon":

How does the word "isn't" become "isn’t"? There's a great explanation from Justin Weiss, basically:

• Unicode ’ (U+2019) contains 3 bytes - 0xE2 0x80 0x99
• When those three bytes are converted to Windows-1252, they become â € ™

The Android version of Prime video goes a step further:

The Euro Symbol has been converted into its HTML entity €

There are hundreds of examples of video descriptions being mangled like this.

And, occasionally, you find this hot mess: What's going on?

Two countries separated by a common language

Except, of course, this doesn't happen on the American version of Amazon Prime Video.

Here's the description of Gotham S03 from Amazon USA:

Once the text gets to this side of the pond, it goes horribly wrong.

As well as the â€TM issue, there's another new snag. The hyphen is actually - hyphen-minus (U+002D). Something in Amazon's conversion process is transforming that to – en dash (U+2013).

That then gets buggily encoded to â€".

I've reported these errors to my friends at Amazon - they are in the process of correcting them.

You can buy the Amazon Fire TV Stick 4K Ultra HD for just £50.

Let'S Ignore The Weird Capitalisation Virgin'S System Uses. What's that Â doing there?

Their website says:

No Â symbol, but also no £ sign. Ah, but let's look at the underlying code.

What's that weird character? It is the control character string terminator, of course...

Well, my discount is nearly finished, so I asked them for a larger discount. "Sure!" they said "How does Ÿ3 sound?"

Amusingly, when I copy the Ÿ from that PDF, it shows up as the character œ!

What's Going On?

I've written extensively about how the £ symbol is encoded - but here's a primer.

• £ in ISO-8859-1 (Latin-1) is decimal 163.
• £ in Unicode is also 163 - but it gets stored as two UTF-8 bytes - 194 & 163. In hex this is 0xC2 0xA3.
• In Windows-1252 - the legacy encoding for ancient version of Microsoft's software - 0xC2 gets rendered as Â.

So, at some point, Virgin's billing software is seeing 0xC2 0xA3, encoding it as £, and then grabbing the first character to print on the bills.

Where do the other characters come from?

• In Code Page 437 - an ancient IBM encoding - the £ symbol is 0x9C.
• 0x9C in Windows 1252 is œ
• The String Terminator is 0xC2 0x9C

And the Ÿ character? Not a clue! Inspecting the raw text of the PDF shows the underlying code is: 6m \2343.00 RIV Discount. PDFs escape octal characters. Octal 234 is decimal 156 - which is hex 0x9C.

Nearest I can get is the ISO/IEC 8859-15 encoding, where œ is 0xBD and Ÿ is 0xBE. Perhaps a font substitution error?

Everything is awful

This isn't just ugly. It points to the fact that Virgin don't test their software and don't upgrade their systems. What other horrors lie in their technology stack?

And it isn't just a tech issue. It is bad for screenreaders - meaning visually impaired users get a poor experience.

The year is 2018. And we're still battling text encoding issues due to crappy software.

"Fuzzing" is a computer science term which means "sending weird data into a program and seeing what happens." It's a useful way to see how your code can break in new and unexpected ways. It's particularly good at showing what a website's search engine does when it is confused.

For example, here's a fairly mundane Tweet.

Offshore A-Z

@OffshoreAZ

🏢 HONOUR INTERNATIONAL LIMITED
🇰🇾 Cayman Islands

🎯 <html>
<head><title>502 Bad Gateway</title></head>
<body b…

📒 offshoreaz.company/0061673

---

OK, the bot sending it appears to have had a bit of a meltdown, but that's not the interesting thing. If we search for some of the HTML elements in it, we get this hot mess:

WTF?! Let's take a look at what the search engine is doing. Here's some of the HTML for that tweet.

&amp;<strong>lt;html</strong>&gt;

&lt;head&amp;g<strong>t;&lt;title</strong>

&gt;502 Bad Gateway&amp;l<strong>t;/title</strong>

&gt;&lt;/head&gt;

This looks to me like an off-by-one error. I suspect that the internal parser is highlighting the zeroth character rather than the first. Because the < are stored as their escaped version - &lt - when going backwards by one extra character, the escaped element is bisected.

Or not. I'm not the Twitter Engineering Team. Might be dragons. Who knows?

Unfortunately, there's a rather annoying bug in the way it renders placeholder text. Consider the following HTML:

<textarea placeholder="In loving memory of
Buffy Anne Summers
She saved the world
A lot..."></textarea>

This should render a textarea (a multi-line input box) pre-filled with placeholder text. The text should be over multiple lines. Instead, it renders like this:

Is that right? No! Let's see what the spec says (disclaimer - I'm an editor on the HTML 5.3 spec).

User agents should present this hint to the user when the element’s value is the empty string and the control is not focused (e.g., by displaying it inside a blank unfocused control). All U+000D CARRIAGE RETURN U+000A LINE FEED character pairs (CRLF) in the hint, as well as all other U+000D CARRIAGE RETURN (CR) and U+000A LINE FEED (LF) characters in the hint, must be treated as line breaks when rendering the hint.

HTML 5.2 - 4.10.11. The textarea element

Amusingly, Mozilla's own documentation corroborates this:

placeholder

A hint to the user of what can be entered in the control. Carriage returns or line-feeds within the placeholder text must be treated as line breaks when rendering the hint.

MDN <textarea>

I've raised this as a bug with Mozilla - sadly, my C++ is too rusty to contribute a patch!

Google Pay now supports American Express cards in the UK. Hurrah! But if you try to ring Amex from within the app - a problem occurs. Can you spot what it is?

The country code should be +44. For some reason, it's missing the +.

It passes to the dialler correctly, but the call then fails because the number isn't recognised.

GSM requires an international call prefix when using country codes. If Amex wants customers to be able to call, it needs to change how it presents numbers to Google Pay.

Other providers get around this by using country specific dialling. The Halifax credit card uses an 0345 number which works perfectly.

Unless you're abroad. In which case, it will fail.

I know Google doesn't like testing things before they're released - but insisting that providers use properly formatted international dialling numbers seems like a sensible precaution.

It is actively dangerous to the web ecosystem, helps disseminate propaganda, and is disliked by many users.

If, like me, you made the mistake of trying out AMP on your website - you're in a tricky position if you try to remove it. Google doesn't like anything leaving its clutches.

After a few weeks of AMP, I decided that it wasn't suitable for me. So I uninstalled the WordPress plugin. That's when the problems started.

When someone searches for my site on mobile, they still get presented with an AMP link:

Which leads to an error page:

No matter, they can click through to the real page, right?

No. The /amp page doesn't exist and causes a 404 error. Google could use the canonical URl to serve the original page - but that's too much like hard work for them.

So, how do you fix this? Thanks to Google's legendary lack of support and pathological aversion to writing clear, updated documentation - it's really hard to find a straight answer.

You would have thought that after a few days of getting AMP errors, Google would take the hint and stop serving the content, right? Sadly no.

There is one scrap of information which might give you some hope:

Use the "update-ping" mechanism to permanently remove content from the Google AMP Cache after the content has been removed from its origin. For example, to purge content formerly served at https://cdn.ampproject.org/i/s/example.com/favicon.ico, send an update ping request to:

https://cdn.ampproject.org/update-ping/i/s/example.com/favicon.ico.

Cached content that no longer exists will eventually get removed from the cache; it's just faster to use "update-ping".

Google's Remove AMP content "documentation"

If I'm reading this right, I have to send a ping for every page on my site.

Something like

https://cdn.ampproject.org/update-ping/c/s/shkspr.mobi/blog/2015/09/i3-electric-car-review/amp

For a few thousand pages. That's... bonkers! And, best of all, it doesn't work.

I chose a page, sent the ping, waited a few hours and... nothing! The AMP links still showed up in Google's results.

What's the solution? At this point you only have two options:

1. Accept Google's benevolent intentions and reinstall AMP.
2. Wait and hope.

I should have learned my lessons from my last interaction with Google. Oh well, fool me once...

Earlier this year I purchased and reviewed the TinTag. I've spent the last month trying to get hold of the company to report a serious privacy problem with their Android app. I've not received an adequate response, so I'm publishing this post to let affected users know about the issue.

The TinTag is a BLE tracker. It's designed to attach to your keys or bag. An app on your phone can send a message to the tag, which causes it to light up and make a noise. Handy if you've lost your keys and you're within Bluetooth range.

But what if you drop your keys while out jogging - how will you find them again? These tags are too small and under-powered to run a GPS chip. Instead, the app does the heavy lifting. Every time the app detects the beacon, it records the phone's location and uses that as the "last known location".

And if you've lost your phone as well? No worries! The TinTag app uploads your precise location to its web server.

Completely unencrypted!

*sigh*

Let's fire up our trusty MITM app and see what the Android TinTag app is broadcasting to the world.

First off, all data is sent in the clear to Heroku.

TinTag are sending...

• The street address of the user.
• The MAC address of the TinTag.
• The precise latitude and longitude of the user.
• The tag's ID.
• A unique user ID.

Of these, the most obvious concern is the exact location of the user. They aren't encrypted in transit - what's the betting that they're encrypted on the server?

Given that TinTag haven't updated their Android app since the beginning of the year, do you think they've updated their server's software recently?

If TinTag's servers are attacked - someone could get your entire location history.

In part, I must say that I blame Heroku for some of these problems. They could make their domains SSL enabled by default - but they don't. Unfortunately, even if Heroku switched on SSL for all their users - that wouldn't help TinTag. Digging into the app's code, this is what we find...

My Java is a little rusty - but I'm reasonably sure that code is a "radically insecure" way to accept all HTTPS connections even if they are not valid!

The sad thing is, the TinTag is a great piece of hardware. It has a nifty wireless recharger, has brigher lights and a louder speaker than any other BLE token I've found. The software is so desperately insecure with your privacy that owners should stop using it immediately.

Timeline

• 17 October - repeated attempts to contact the company via their website.
• 26 October - contacted the CEO via LinkedIn.
• 01 November - response from CEO promising to look in to it.
• No further contact from TingTag despite trying to contact them.
• 17 November - publication.

One of the best things about them is their open API. Sure, you can use IFTTT if you want something easy - but us 1337 hax0rs want an API and Lifx provides it.

The API is pretty secure - good use of OAuth and tokens to make sure whatever you're building is resistant to infiltration. I mean, imagine if someone hacked your lightbulbs and ... err... switched off the light while you were reading. That'd be dreadful!

As I was wandering through the developer documentation, I noticed that there was a prominent login form. The pages were not served over HTTPS, and the form was similarly submitting to an insecure page. Typing in "https" before the URL showed a mismatched certificate error.

Not a great user experience - and a good way for customers to have their passwords intercepted.

24th April 2016

I took a quick note of my findings and used Lifx's contact form to alert them.

The URLs http://api.developer.lifx.com/ and http://lan.developer.lifx.com/ ask developers for their email address and password.

The site is NOT served over httpS. If a user tries to manually force it to https, they get a mismatched certificate error.

If a developer is on an insecure connection, this could cause their credentials to leak.

Can I strongly urge you to fix the certificates on the site and to reset the passwords of any user who has been affected.

27th April

I received this very positive note back from one of their engineers.

Thank you for reporting this issue to us. At LIFX we take our users and developers security extremely seriously. Here we clearly dropped the ball, and we need to be better.

Today I obtained certificates, sent them to our provider and set the documentation sites to enforce SSL. Finally I also changed most links to link to the SSL version of the site by default. We will be internally discussing how to best inform anyone affected.

Again thank you for your time finding and reporting this vulnerability to us. Your efforts have made us all more secure.

That's a pretty good response time for a company - especially given the timezone differences.

Conclusions

I checked, and the sites are now securely behind https.

It appears that the "log in" form is actually to log in to the ReadMe.IO documentation service. I would expect that most developers would see "Log In" and use their Lifx credentials. This means that ReadMe.IO (who I'm sure are honourable people) may inadvertently be receiving usernames and passwords for an entirely different service.

If you've previously clicked that Log In button, it would be sensible to reset your password and revoke and OAuth tokens you may have generated.

If you run a website, think hard about which login prompts you display - and whether tired developers are likely to make mistakes.

Bounty!

I obviously wasn't expecting a million dollar payout - but was pleasantly surprised to receive a clutch of new bulbs as a thank you gift. Anyway, here's me casting a spell on one of my bulbs.

Terence Eden is on Mastodon

@edent

That think where you have a kickarse idea only to find some beat you to it by FOUR DAYS! x.com/kelvzhan/statu…

Kelvin Zhang

@KelvZhan

First working implementation of voice controlled @LIFX lights using Python Jasper + lifx-cli @smarthall pic.x.com/lkfpjo7onz

---

---

Terence Eden is on Mastodon

@edent

Replying to @edentWoo! Using the WebKit Speech Recognition API I can now control my Lifx bulbs like Harry Potter :-) pic.x.com/ykphwepthy

---

Read more on my GitHub repo.