Several of the people who live in my phone use artistic black and white headshots. They look very cool. But my Android phone shows their image with inverted colours - so they look like pure shite.

Here's what my very real human girlfriend looks like when I ring her to go for brunch:

Come the evening, my phone switches to Dark Mode™ - so this is what she looks like when I ring her for a late-night booty call:

What's causing this? And is it expected behaviour?

I'm running com.android.contacts version 1.7.34 which appears to be the latest version of the AOSP contacts app. It's bundled with LineageOS.

Demo

If you're not lucky enough to be dating Marylin Monroe, here's a demo image for you to try:

Is this expected behaviour?

Based on some quick tests, it appears that the contacts app will invert some monochrome images when it thinks there's "too much" bright white in the image.

Interestingly, the contacts list doesn't invert avatars when in Dark Mode.

And... I don't know if I want this to happen. I guess that most people who use Dark Mode want to avoid blinding bright white light searing into their precious eyeballs. But, presumably, they don't want the photos of their friends inverted into a weird artefact-ridden mess?

So, before I get lost in Google's Kafka-esque bug reporting process - do you think this is expected or desirable behaviour?

When I search for my name in Google Books, it returns books I have reviewed. These aren't books that I've written. They don't mention, quote, or cite me. My reviews don't appear on the dust-jacket. Google has got confused.

Here's an example.

Go to the Google Books Advanced Search Page - marvel at how it retain the old Google logo and looks like it hasn't been updated since the early 2000s!

When I do a search for "Terence Eden" - these are the results.

I have reviewed both Terry Pratchett's Discworld Imaginarium (excellent) and Good Data by Sam Gilbert (terrible) - but that's my only connection to them. If you go into the results in Google Books, you won't find my name at all. It's not like Google adds my reviews into its service either.

This has been a problem for at least four years.

As I scroll through the results, there are several books which do mention me (thanks authors!) but loads which are just picking up my review.

To get an idea of the scale of the problem, here's a search for my name in books published during the last few years. Nearly every result is a book I have reviewed. None of those books contain my name.

Now, earlier I said it is impossible to report bugs to Google Books. That's not quite true. Last year I contacted them on Twitter. They said:

Google Books

@googlebooks

Replying to @edent@edent Hi, thank you for your feedback. I've passed it along to our engineering team. -Cait

---

*sigh*

Perhaps their pivot to AI will fix their towering pile of bugs?

------=_NextPart_001_009E_01D4D8BF.D0737E10
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=E6=8C=A8=E2=8E=92tml xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"=
urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-c=
om:office:word" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml=
" xmlns=3D"http://www.w3.org/TR/REC-html40">

What's going on?

• 挨 is a Chinese, Japanese, Korean (cjk) unified ideograph (U+6328)
• ⎒ is the passive-pull-up-output symbol (U+2392)

That's somehow replaced:

• < - less-than sign (U+003C)
• h - Latin small letter h (U+0068)

<h in binary is 00111100 01101000

挨⎒ in binary is 11100110 10001100 10101000 11100010 10001110 10010010

It was sent from Outlook 2010 to Gmail. But I receive lots of those emails.

Try as I might, I just can't work out where this error has crept in. A glitch in the Matrix? Electronic interference? Any clues, gang?

Facebook rewrite URLs with Unicode in the path - this is not best practice and could be dangerous.

It is possible to create a URL like http://bit.ly/😀 - the Unicode characters are valid in the path.

The URL Encoded representation is :

bit.ly/%F0%9F%98%80

Facebook mangles these URLs in such a way that it might be possible to redirect a user to a malicious site.

Here's what's happening. When Facebook sees the "😀" character in text, it rewrites it to the "󾰀" character (&#1043456;). That's a "private use character". This means Facebook can replace the user's computer's default smiley with a Facebook supplied image or font glyph - if it wants.

In normal text - such as "I passed my exams 😀" - changing the smiley is doesn't present a problem, but Facebook also replaces the text in a URL!

So, the URL :

bit.ly/%F0%9F%98%80%F0%9F%98%80

Will point to a Facebook security page.

Facebook changes the URL to :

bit.ly/%F3%BE%B0%80%F3%BE%B0%80

Which points elsewhere - bit.ly/󾰀󾰀.

I performed a couple of quick experiments. It is sometimes possible to post a link which displays a preview of a "good" site, but when clicked on leads to a bad site.

The chances of this being used as a successful attack vector are slim. Tricking the user into clicking on a link which subsequently steals their password is made marginally easier if the link and link preview don't match - but I'm sure there are easier ways of deceiving the user.

The real issue here is that Facebook is altering the text that you write - and that can have unexpected consequences.

We live in a non-ASCII world now. A URL like https://莎士比亚.org/奥瑟罗 is perfectly valid. Facebook - and other sites - should not be confused by non-Latin characters.

"Harry ‮".draziw a si ‭Potter

Now, try to select the text and see what happens.

WHAT WITCHCRAFT IS THIS?!

If you examine the source code for this page, you'll see that I'm using the Unicode Bi-Directional characters.

"Harry ‮".draziw a si ‭Potter

These characters are useful when writing text that includes, say, English and Arabic - but they can also be used for malicious purposes.

On a more mundane level, they can cause all sorts of UI bugs. I've just filed a bug against the Chrome browser for how it handles these characters.

If you right click on text with mixed direction, you'll notice that the UI behaves oddly.

In Firefox, the behaviour is correct - although one could argue whether "Potter" ought to be reversed.

Searching

So, what happens when we run these searches?

Neither Firefox nor Chrome do particularly well. I'm not sure if the reversed text in the window title and URL bar are bugs in Ubuntu - or whether it's the fault of the app itself.

On Windows and Mac, we see this happen:

This would suggest that Google isn't correcting the direction of the text and that is deforming its own title tags.

Are These Bugs?

Ok, so having the title reversed isn't the worst problem in the world. But do these examples count as bugs and, if so, who is responsible for them?

Every search engine I tried passed through the right-to-left-over-ride unscathed - so that's the fault of the search engine, right? How the hell do you a report a bug to Google?

The title bar could either be a problem with the browser - Firefox has a bug report over a year old on the issue - or the problem could be with the underlying operating system. How would one find out?

Thanks

Thanks to Yuan Phoon for asking the questions which prompted this discovery.

Recently, she added a note to her personal Google Calendar reading "Email alice@example.com to discuss pay rise" and set the date for a few months from now. She'd had a discussion with her boss, Alice, and they'd agreed to talk about salary later in the year.

A few moments later, Alice sent her a "Meeting Accepted" email.

What... The...?

Although pretty embarrassing, it could have been a lot worse. It could have been "Email mother-in-law@example.com with excuse why we can't see her" or perhaps "Email husband@example.com with divorce details" or even "Email co-worker@example.com to demand red stapler back" or... well, you get the picture.

Luckily, my wife doesn't have a Google+ profile, so there was no information leak other than her email address (which wasn't "huggle.wuggle.2012" or anything daft like that!)

We've tried several times to recreate this behaviour. Here's what we discovered:

• If you use Google Calendar on the web and put a Gmail address in the subject line, that user will have the event added to the calendar.
• They will not receive an email notification - although they will get a "meeting reminder" pop-up.
• Creating an event on an Android phone does not trigger a meeting request.
• Some non-Gmail addresses will also see the meeting in their calendar - but others will not.
• When you delete a calendar item, the "Cancellation" notification is emailed regardless of whether the user received the original invite.

We were unable to determine which non-Gmail addresses would receive the item in their calendar. Some which were hosted with Google didn't receive the pseudo-invitation. Some accounts hosted on Microsoft Exchange got the invite while others on seemingly similar systems didn't.

Here's a video showing it in action.

Note that when a user fills in the pop-up, Google Calendar asks for confirmation to send a meeting invite. When using the full interface, no warning whatsoever is given.

Impact

Google has tried to be clever here. It has failed. Just because I am talking about someone, it doesn't mean I am talking to someone.

There are two main risks here - the user could expose her private Gmail account and associated Google+ data, and she could also reveal her private thoughts and feelings.

Google really needs to work harder at protecting the privacy of its users.

Disclosure

This privacy issue was formally disclosed to Google on 6th January 2014. On 22nd January, they responded by saying they didn't consider it a problem.

We reviewed your report. After careful consideration by our security team, we feel that the issue has minimal impact on the security of our users. Let us know if you believe that this determination may be incorrect. If you'd submitted your report as part of our reward program, this means it doesn't qualify for reward or credit. Thanks for your help!

As much as I'm disappointed not to be getting a $10,000 bug bounty, I'm more upset that Google repeatedly finds itself failing to keep its users' private information private.

Update: according to a comment on the HackerNews discussion - problems like this have been reported to Google as far back as 2010.

Update 24 January: Google have agreed to fix this bug!

[W]e agree that the behavior you identified is undesirable, and we filed a bug with the Calendar team last week. They’ve been working on changing the behavior to make it clearer that someone has been added to the event in the situation you described.

While we won't be getting any of the monetary reward from the bug bounty, Google have graciously decided to include us in their Security Hall of Fame.

You can continue the discussion on The Verge, ars technica, Business Insider and Android Central.

Update 31 January: This flaw was discussed on the "This Week In Google" podcast.

Pretty obviously, that's the user's name and the ID of their tweet. Simple, right?

Not really, click on that link and you'll see this: That's my name in the URL bar - but the Number 10 Press Office's tweet on the page.

What's Going On?

Have I retweeted that status? Nope! Am I a 1337 h4x0r who has hacked Number 10? No sir! Is the screenshot a fake? Nuh-uh. Check the link yourself.

It's actually a curious bug / feature of Twitter. Each tweet you send has a unique ID. So there can only be one tweet with the ID 197967209459499008. And that ID will always belong to @Number10press.

The username part in the URL is redundant. It seems that it is not used except to give information to the user / search engines. It can be safely omitted or manipulated.

Malicious Use?

It strikes me that there is a slim chance of malicious use.

One could create a fake account - say Number1Opress (where the 0 has been replaced with a capital O). Make it tweet something ridiculous, then share a URL which has the real Number10press in the URL. Minor embarrassment is probably the worst consequence.

It's an interesting usability / security nexus. The username is placed in the URL to make it easier or more useful for users - but it is ignored by the back end system. As it's part of the hated hashbang syntax, I wonder if it could be simply be rewritten if there's a mismatch?

One of the advantages of the text processing is that it will recognise that www.example.com is a URL and automatically create a hyperlink. Considering that dropping the "http://" represents 5% saving on Twitter's 140 character limit for messages, this is great.

So, I was mightily surprised to get this bug report from user "schmmuck"

Dabr rendering error

How very odd... This is how it looks on m.twitter.com.

m.twitter rendering error

Twitter also use mobile.twitter.com for smartphones. Here's how that site renders the text.

mobile.twitter rendering error

Finally, let's take a look at the "canonical" rendering at Twitter.com

Twitter rendering error

The Problem(s)

The first issue is inconsistency.  Twitter ought to be using the same regex for each of its sites.  It doesn't.  This means that different developers will get divergent experiences.  This leads to confusion, which leads to fear, which, as we all know, leads to anger.... and so forth.

Secondly, and more importantly, parsing is hard.  There are so many edge cases that errors inevitably creep in.  My post about hashtags explains the problems in defining what should be recognised.

So, based on what we've seen, should Twitter recognise any of the following as URLs?

news.bbc.co.uk - no www there.

invalid.name - a silly URL, but a valid one.

खोज.com - International domains contain more than just ASCII

All the above are valid - yet they're not recognised by Twitter.

A (Simple) Solution?

There is a canonical list of TLDs which is also available as a plain text list.

Any string containing a "." followed by a valid TLD, then followed by a space or "/" should be treated as a URL.

Your thoughts?