I have a program which takes text files with ASCII line art and automatically turns them into text files with UNICODE line art.[1] I wrote this for some very old documents, but it's still useful.
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Source Port ┃ Destination Port ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┻━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ Sequence Number ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ Acknowledgment Number ┃
┣━━━━━━━┳━━━━━━━━━━━┳━┳━┳━┳━┳━┳━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ Data ┃ ┃U┃A┃P┃R┃S┃F┃ ┃
┃ Offset┃ Reserved ┃R┃C┃S┃S┃Y┃I┃ Window ┃
┃ ┃ ┃G┃K┃H┃T┃N┃N┃ ┃
┣━━━━━━━┻━━━━━━━━━━━┻━┻━┻━┻━┻━┻━╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ Checksum ┃ Urgent Pointer ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┻━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┫
┃ Options ┃ Padding ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┻━━━━━━━━━━━━━━━┫
┃ data ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
Not everyone and not everywhere, and depending on the font, the line-drawing characters may not be the same width as the others even if it's a monospace font (e.g. see https://blog.helftone.com/ascii-art-unicode/ ). The whole point of text files in things like RFCs is to be as portable as possible, and using Unicode somewhat defeats that point.
The box drawing characters aren't even in the astral planes. They're in plane 0 in the 0x2xxx range. So even old 16-bit Unicode implementations should support them.
(The TCP header from an RFC was just an example. I'm converting some old troff documents to PDF, and they have lots of box drawings.)
I wouldn't put the finger on Unicode but rather that not all fonts have all Unicode glyphs yet, as I seem to recall was the case with ASCII line drawing glyphs years back. Definitely seen that before and it's good to know why. Thanks!
https://github.com/jaebradley/uber-cli/blob/master/src/servi...
Obviously, this is a security issue that is pretty much bottom-of-the-barrel-shitty.
My explanation is that I didn't feel like standing up a middleware service to direct traffic through in order to obfuscate the server token. Especially for a tool that I anticipated being used by pretty much only me.
Not a satisfying answer, but thanks for exposing this security flaw - definitely going to add it to my project task queue.
Like many others, I'm done with the tire fire that is uber.
Tell me, what would be enough?
Sources for subprime loans: http://valleywag.gawker.com/uber-and-its-shady-partners-are-... https://www.bloomberg.com/news/articles/2016-05-31/inside-ub... https://twitter.com/shashashasha/status/688734478181732352 Self driving shit: https://www.theguardian.com/technology/2016/dec/19/uber-self... the rest is either obvious or recent enough not to need a source.
dig +short myip.opendns.com @resolver1.opendns.com | xargs -I {} echo "ipinfo.io/"{} | xargs curl | grep loc | cut -d: -f2 | sed "s/,$//" | xargs uber time
dig +short myip.opendns.com @resolver1.opendns.com | xargs -I {} echo "ipinfo.io/"{} | xargs curl | grep loc | cut -d: -f2 | sed "s/,$//"
curl ipinfo.io/loc
But ip geolocation usually gives you city or zipcode level accuracy, which may or may not be good enough to get an accurate uber estimate depending on how big your city/zip area is.
I think the authors intent was just for his own use and some fun.