You cannot start a tweet with “D. Tusk” | Hacker News Reader

You cannot start a tweet with “D. Tusk”

twitter.com

211 pointsdavb87 comments

Open articleView on HN

There is a list[1] of things you can't start tweets with

[1] - https://support.twitter.com/articles/14020

It's not clear why the SMS codes would be restricted on the web, but good to know.

Because they are still used on the web as well. I still use "D {handle} {message}" to DM people.

Seems like a mistake waiting to happen.

Yep, it has already happened!

A few years back you could tweet FOLLOW USERNAME and that username would follow you

Yes, but only in Soviet Russia.

For @chucknorris this feature has always existed.

Anyone remember Anthony Weiner? His infamous tweet (that ended up with him resigning from Congress) was intended to be a direct message but he started it with @, not D, so it went (briefly) to his public timeline [1].

And it seems that, when you're a congressman, posting a dick pic even briefly is enough to attract some attention.

[1] http://www.nationaljournal.com/how-weiner-fell-into-the-twit...

It's so ironic, the whole thing could have been avoided if he'd given her the D... (sorry)

You're not sorry.

The fact that "D Name" starts a direct message doesn't explain why "D. Something" gives an error, except for shoddy coding.

It's probably so that people don't accidentally publish something they intended to DM by tapping the spacebar twice after the command. It'd still imagine it should be allowed from a full keyboard, at least.

That's an interesting idea but very speculative.

Nice idea, but 'internal server error' (per the linked tweet, didn't try it) isn't exactly a good reaction. IF someone thought that this might make sense, the result should not/would not be a 500..

It could be that an internal service is returning an error, which the externally facing server is not handling properly.

Allowing multiple spaces makes sense, I suppose, but why support a dot stuck there? Seems like an oversight.

On many mobile keyboards double space turns into '. ' as a quick way to begin a new sentence.

yes, absolutely! It has to be this. Plus, a tiny little period is really hard to miss on mobile (where the shortcut you mention applies). it's almost justified.

"d. something" is not the only offender. I suspect it's a badly written parser. "m. anything" also breaks. And for fun, without the following word ("something"), the tweet just vanishes with no error at all.

I tried all of the non-space non-alphanumeric characters on my keyboard. Some worked, most caused an error.

d` d~ d$ d% d^ d& d( d) d- d+ d[ d] d{ d} d| d; d' d" d, d< d. d> d/ d?

I typed 'WTF' and it got posted as a tweet, even though it's on that list:

> SUGGEST, SUG, S, or WTF - this command returns a list of Twitter users we think you might find interesting and would like to follow.

Curious - via the web, an app, or SMS?

I got the impression those were SMS commands only, but it would be interesting to learn they'd shut down some of the functions but not all.

Via the web - the same input box that would error out on "D. <any-word>"

Ah, I see. "Who To Follow". Mental acronym disconnect there for a moment. :)

Nah, the other meaning of the acronym usually fits as well

I'd guess this is related to the in-band use of 'd nickname" to send a direct message. Which is also a bad idea, since that makes it too easy to accidentally make a private message public.

There used to be(still are?) phrases you can't start tweets with. For example "get better", it had to do with the twitter SMS interface.

This was the only way to do it with the SMS interface.

They could have provided a different number for direct messages.

I'd be really interested to see how many users still use the SMS interface. I switched away from it as soon as I got my first smartphone and haven't looked back.

My guess is that the number has recently increased, with most phone plans now offering unlimited talk+text but metered data. On a prepaid plan, when you've run out of data, some carriers will just do a hard stop on your data and others will reduce it to a slow trickle, so the SMS interface might be the best.

I very much doubt it. Using Twitter is such a way would be absolutely awful these days, and few people (outside of the tech bubble) hit their data plan limits.

The tech bubble? More like the teenagers with snapchat, youtube and twitch.

A lot of data plan limits out there are 100MB, 250MB, etc.

Twitter doesn't hog that much data.

It's not about how much data it hogs -- it's that for prepaid plans (which are the vast majority of overall subscribers worldwide), when your data runs out it often just completely turns off until you get another top-up card.

2-300MB per month on my phone, that is too much for many data plans.

SMS is much more global and accessible to countries lower on the digital divide.

Ha. I now have a throwback to my earlier days, when I subscribed to Ron Paul and I used to get all his tweets as messages on my dumbphone. And I read each single one.

Luckily, I bought a smartphone later and stopped being a libertarian.

I honestly wonder how many people even know the SMS gateway stuff exists at all and think Twitter can only be used via the app/site.

"Note about DM fails: Your service provider may split SMS messages greater than 160 characters into multiple messages. In this case, the second message will post as a normal Tweet because it doesn't begin with d+username, as the first message did. Please be careful to ensure that your messages are under 160 characters."

That could certainly be interesting.

The opposite problem sucks just as bad:

"first 160 characters... and then I calle"

"d joe_blow to tell him about the secret company merger"

Magically aligning a perfect string at a 160 character offset, and somehow have it being a user who would have any idea about what you're discussing? A total non-problem.

I think you're vastly underestimating the amount of tweets that are typed every day.

It's not magic.

Bizarre edge case with a non-zero chance of happening? Someone will inevitably stumble across it...

reminds me of the shitty email filter the school I taught at back in the late 90s used. It would filter out curse words but it ignored spaces so if you typed something like "push it" is would see "sh it" and delete those letters. It rendered your emails basically unreadable.

Ha, ours was really naive about URLs. A lot of teachers got annoyed by it constantly blocking Weightwatchers :)

I'm from Poland. We have Donald Tusk (D. Tusk) here, who is the President of the European Council since 1 December 2014, and previously he was Prime Minister of Poland from 2007 to 2014. It would be funny if that had any connection to this issue.

That's how I noticed. I tried to tweet something about Donald Tusk and had to abbreviate his name because of the length. I know about the "D handle" prefix but apparently it also triggers for "D. handle" which is why I wrote about how I dislike in-band signalling.

He's in the news today due to his role in the Greece crisis over the weekend: http://www.ft.com/intl/cms/s/0/f908e534-2942-11e5-8db8-c033e...

Which he keeps fucking tweeting about: https://twitter.com/eucopresident/status/620486708233129984

He actually used the phrase "we have an a Greek ment". David Brent couldn't have said it better.

For those commenting about why you would want to do this in the era of smartphone and apps: its useful in areas of low bandwidth.

I'm in IL typing this from a 2G mobile network. It's painfully slow, the data connection goes in and out. Loading my Twitter app is a feat of patience.

SMS works fine though, and getting and sending messages via 40404 is easy. If this is how you're used to using Twitter, why shouldn't you be able to interact this way on the web?

Though if you'd really want to: https://twitter.com/9uuso/status/620680719245946880?s=09

Is there an escape mechanism?

I just did this by modifying the curl request to '…status='\1'D.+Tusk…'

From the Twitter help center: "Note about DM fails: Your service provider may split SMS messages greater than 160 characters into multiple messages. In this case, the second message will post as a normal Tweet because it doesn't begin with d+username, as the first message did. Please be careful to ensure that your messages are under 160 characters."

Twitter doesn't have multipart SMS reassembly? Twitter advertises that the size limit for direct messages is now 10,000 characters.[1] But apparently you can only send big from their app, or when advertising ("sponsored tweets"), not from SMS.

Multipart SMS reassembly isn't all that hard; every smartphone does it. Messages are split into 153 byte fragments with a binary header, with a max of 255 fragments. At Twitter's scale message parts may come in to different front end machines, which means having to reassemble fragments across multiple processes/machines. Most SMS gateways don't reassemble fragments on inbound because of that scaling problem, but Nexmo and Twilio will pass through the fragment numbers so you can do it. (This is a new Twilio feature in beta. Ask Twilio to turn it on if you need it.) Outbound, SMS gateways almost always handle multipart. Have to be able to send big ads in bulk, after all.

[1] http://time.com/3918810/twitter-direct-messages-length/

While the ordering of messages is part of the protocol, it's not a required part - there's no guarantee that a phone will correctly indicate the number of parts of the message in the header(s).

Given that, I'd rather say "this feature will fail in this way" than "sometimes, depending on your phone and carrier, your long SMSs may be split into multiple parts, the second of which will posted as a public message".

For GSM, number of parts is a required item in the multipart message header.[1] It's field 5 of the UDH.

Some phones have had trouble with reassembly. There's an old Android bug which manifests as a new incoming message being reassembled with parts of an old one, sometimes an old one from months ago.[2][3] That indicates a broken reassembly implementation. It's easy to see how that can happen. The "unique ID" on multipart messages is only 8 bits (16 bits with an alternate header format). That number is generated by the calling phone. Unmatched fragments should be discarded (or delivered as an error) after a few minutes. Android keeps unmatched SMS fragments for the life of the phone, resulting in the occasional reuse of long-forgotten message fragments. Worse, when this happens, when the correct fragment comes in, it's saved as an orphan. So once there's been an orphaned fragment, 256 long messages after that, there will be another bogus reassembly using the old fragment, with the correct fragment being saved as a new orphan. Some users changed their phone number to get around this bug.

Google's reaction to years of bug reports on the problem was to close the bug report as "Obsolete" without fixing it.[3]

To work around this botch, there's an app: "SMS Multi-Part Cleaner". Really.

[1] https://en.wikipedia.org/wiki/Concatenated_SMS [2] https://code.google.com/p/android/issues/detail?id=17769 [3] https://code.google.com/p/android/issues/detail?id=28697

"For GSM, number of parts is a required item in the multipart message header.[1] It's field 5 of the UDH. "

number != order.

As said, sms's are not guaranteed to be received in a particular order, nor is the order recoverable (because the clocks are not guaranteed right, etc, so even sorting by time, ...)

Read the spec. The header on each multipart message fragment has the number of fragments, the fragment number (counted from 1, for some reason), and a semi-unique ID generated by the sending phone. You also get the source phone number along with the message. This is sufficient for correct reassembly.

The semi-unique ID is normally only one byte, and so old unmatched fragments can match new messages. Android keeps old unmatched fragments in a database for the life of the phone, which is insane. (We drop them after 5 minutes in our system. A more conservative approach would be to wait until a successful message from the same phone, indicating communications have been reestablished, and a few minutes after that, purge old fragments from the same source.)

I've read the spec. In fact, i'll go further. I've built multiple election systems that use SMS to send data around :)

Every carrier tech i've talked to tells me the same thing - the order of messages is not guaranteed nor is it recoverable.

So while it's not that i don't believe you, it's that "in practice, it seems everyone thinks and does otherwise".

"This is sufficient for correct reassembly." Except, as you prove later, it isn't when the unique ids can match other messages :)

If you have your own system which doesn't send UDH headers, and you can't reassemble, it's your problem. SMS messages are not ordered, but then can contain ordering info. The major smartphones all send UDH headers, which have enough data for reassembly. At least if you don't keep old fragments for insanely long periods.

One trick for faking out various tweet parsing is U+200B, Zero Width Space. I use it a lot to tweet domain names without them being turned into t.co links. There should be one for you to copy and paste here >< there.

Whats the intended use case for having this character in the first place? It seems like you could use it in a whole bunch of places to bypass regex/classifiers, or potentially a lot of things without proper encoding. I could potentially register at NelsonM<>inar somewhere and who would know the difference at a cursory glace?

Lots of services limit usernames to a certain range of characters, but some don't. However, there's tons of invisible unicode characters that you can use instead, so even without this one, the problem would still exist.

Thеrе arе many cyrillic lеttеrs looking idеntically to latin lеttеrs. In previous sentence all "e" letters were cyrillic, for example. So probably the only sane way is to limit username characters to latin letters.

Just like all the other spaces and zero width characters[1], it's originally for typography and typesetting. It is used to create word boundaries so that text would break at the right places in paragraphs, but without creating the visible, well, space between words.[2]

[1]: https://en.wikipedia.org/wiki/Whitespace_character#Unicode

[2]: https://en.wikipedia.org/wiki/Zero-width_space

That is because Tusk isn't following you on twitter. D. followed by username and then a message sends the tweet as a direct message to that user.

I would guess the inband signaling is a carry form Twitter's SMS days, but DM's and mentions were after-the-fact additions to Twitter.

I wonder what the 160 character equivalent of 2600 hz tone is?

Wavelength of 2600Hz at 44100Hz sampling rate would be slightly under 17 samples, so any repeating string of 17 single-byte characters would do (44100/17 = 2594Hz, dunno if that's close enough). Or 34 or 68, depending on whatever is playing it expects stereo and/or 16-bit data.

Unless the higher harmonics (5200Hz, 7800Hz, etc) mess up the tone (no idea how strict the old 2600Hz hack used to be). In which case you need some characters that approximate a sine wave. Which isn't too hard, given that you don't care about DC bias and max amplitude.

As far as I can tell, you can't start any tweet with "D." without getting an Internal Server Error. Not related at all to the "Tusk" part.

Had a similar issue when I tried to tweet about M. Night Shyamalan at some point. I thought my Twitter account was limited for some reason.

D.TUSK sounds like a secret Street Fighter character.

It also sounds like someone listed his fourth favorite Fleetwood Mac song.

Somewhere someone is finding a way to make this a buffer overflow. Wonder how long this will take to get fixed. I totally forgot about Twitter's in-band and SMS features until now.

It is likely a scala program running, no buffer overflows to be found. In a modern language, you have to be very careless to allow RCE.

buffer overflow is not the only way to get a RCE.

String manipulation and 'eval' (which gives access to system APIs) is a common culprit

Is anything like eval commonly used in Scala? That language is static as all get-out.

I've started seeing (and occasionally using) util-eval as a configuration language for Scala, but it's generally pretty rare.

Using eval is gratuitous carelessness. At least a buffer overflow can be a mistake.

This is just an accidental coincidence. Has nothing to do with Daniel Tusk

He's name is actually Donald.

Pronounced Donalt

I think everyone knows Donald Duck.

My bad, thanks for the correction

Seems like someone should submit a PR for this. Oh wait.

Reply on news.ycombinator.com