Imprint

Things you cannot say on Facebook, SQL Edition

EDIT: This is now fixed. Facebook worked on the bug report and fixed the problem within 72 hours, including rollout.

Where I work, I am using an instance of Facebook at Work to communicate with colleagues. That is basically a grey-styled instance of Facebook which is supposed to run a forked codebase on isolated servers.

Today, it would not let me write the following SQL in Chat, in Facebook notes or comments:

Other versions of the error message complain about it being Spam, or mention the string sd.date as being problematic.

Why is that?

So when you write anything anywhere in Facebook, Facebook tries to URLify things.

For that, it breaks things into items that look like potential domain names, and checks if they could be domain names. It then create an “a href” wrapper around that and links to that.

Because that’s a way to transport Spam and malicious content, there is a list of blocked things, and that then triggers the above blocking mechanism.

So we have the above SQL, which contains the phrase “sd.date_of_delivery”.

The underscore is not part of DNS, so the tokeniser turns this into sd.date.

So Facebook wrongly tries to turn sd.date_of_delivery into sd.date_of_delivery, which clearly is not my intention, and then spamblocks me.

This is wrong on many levels:

On a business instance of Facebook it has literally no business to listen in, but does.

When every word of the english language turns into a TLD, auto-URLifying stuff becomes completely, utterly useless. The above example contains the expression sd.id, too, and no, it’s not intended to be a link.

The is clearly and obviously code, SQL to be specific. All the machine learning in the world did not help you to detect that, though.

And it’s not even sd.date, you only made it into that, because

You can’t write proper parsers, too.

And you forgot to implement the switch to globally turn off that misfeature in the preferences. Because I am old-school. When I want a link, I actually write https://

So annoying.

EDIT: As a colleague of mine cleverly pointed out, you can fool the thing with zero width characters in UTF-8. I am undecided if that is a bug or a feature.

EDIT: As a user, I want control over URLification: Give me an off switch that does not URLify unless I prefix http:// or https://.

As a user, I want a proper parser, that does not try to turn sd.date_of_delivery into a sd.date-URL.

As a user, I would rather have anything not URLified, but also not blocked, than having things blocked after URLification.

As a user of corporate facebook, I’d like to have the entire product take into account that it is in a corporate environment instead of still trying to behave like blue facebook. The engagement engine, the link-wrapping and and much of the other stuff are a complete nuisance and counterproductive in a paid-for corp use-case.

That will not prevent sd.date from being spamblocked (nor will it prevent facebook from trying to run sd.date_of_delivery through the URLifier, creating sd.date from wrong parsing, and then triggering the spamblock).

I’ve had the same problem with Slack. I’m kinda sure their backtick code escaping will not misbehave as badly as this but I’m also not completely sure.
You definitely can’t just post stuff (that is not code) without it mangling the text, always need to treat it as preformatted :(

“When you decided, as a company, to purchase closed source software, you gave away part of your intellectual process to a third party without any say in it. You’ve found your partner has different priorities wrt software, and you are too small a client to get special attention.”

And which software specifically? We are talking about anything that can facilitate communication for a 20.000 people corporation, including individual and group streams, large scale chat and live video streaming of meetings.