Archive for May 9, 2015

Saturday, May 9, 2015

Why Lisp?

Ron Garret:

The reason that Lisp is so cool and powerful is that the intuition that leads people to try to represent code as data is actually correct. It is an incredibly powerful lever. Among other things, it makes writing interpreters and compilers really easy, and so inventing new languages and writing interpreters and compilers for them becomes as much a part of day-to-day Lisp programming as writing parsers is business as usual in the C world. But to make it work you must start with the right syntax for representing code and data, which means you must start with a minimal syntax for representing code and data, because anything else will drown you in a sea of commas, quotes and angle brackets.

Which means you have to start with S-expressions, because they are the minimal syntax for representing hierarchical data. Think about it: to represent hierarchical data you need two syntactic elements: a token separator and a block delimiter. In S expressions, whitespace is the token separator and parens are the block delimiters. That's it. You can't get more minimal than that.

Redesigning Overcast’s Apple Watch App

Marco Arment:

WatchKit load times are inconsistent and problematic.

Every time the interface loads or changes, the Watch and iPhone communicate round-trip over Bluetooth. Whether due to wireless flakiness, 1.0 OS bugs, or (most likely) both, WatchKit is frustratingly unreliable. Apps or glances will sometimes just spin forever instead of loading, and even when everything’s working perfectly, apps still take so long to load and navigate that the watch’s screen often turns off before you’ve accomplished anything.

[…]

After using my initial app on a real Apple Watch for just one day, I set out to completely rethink and restructure it.

[…]

Trying to match the structure of the iOS app was a mistake. For most types of apps, the Apple Watch today is best thought of not as a platform to port your app to, but a simple remote control or viewport into your iPhone app.

Safari Reading List

Ben Brooks:

There are three major problems with Safari Reading List:

  • It didn’t always save the links that I wanted it to save. So I had no confidence in the system, which lead to constant checking just to see if things were saved.
  • As any Reading List user knows, there are many times when you cannot remove a saved link because ‘Safari Reading List is Syncing’ or some shit like that.
  • Syncing is painfully slow across devices.

Chat Wars

David Auerbach (via Nitesh Dhanjani and Nicolas Seriot):

Our client just ignored it, but the AOL client responded to this gobbledygook with a shorter version of the same gobbledygook. I didn’t know what it was. It was maddening. After staring at it for half a day, I went over to Jonathan, a brilliant server engineer on our team, and asked what he thought. He looked at it for a few minutes and said, “This is code.” As in, actual x86 assembly code. The repeated 90s were what tipped him off: they signify an empty instruction in x86 Assembler.

The pieces then came together. Normally, these protocol messages sent from the server to the client are read and understood as data, not as code. But AOL’s client had a security bug in it, called a buffer overflow. The buffer is a place where a program temporarily stores data while running some operation. However, it’s all too easy in lower-level languages to allow in more input than the buffer can actually accommodate. In this case, very large protocol messages could flood it, overwriting the client code and arbitrarily controlling the functioning of the client program—this is why it’s called a buffer overflow, and it’s a huge security hole, since it gives the server control of the client PC. In the wrong hands, the server can choose to shut down or corrupt or do other terrible things to your computer. AOL knew about this bug in their program and now they were exploiting it! That was what all those double zeros were for—they were just filling up space in the program’s buffer until they hit the end of the AOL client’s buffer and started overwriting executable code with the remainder of the protocol message. AOL was causing the client to look up a particular address in memory and send it back to the server. This was tricky, vastly trickier than anything they’d done so far. It was also a bit outside the realm of fair play: exploiting a security hole in their own client that our client didn’t have!

[…]

Someone had the bright idea of telling the press about the buffer overflow, figuring that if people knew that AOL’s client could and in fact was executing whatever a server sent to it, AOL would be forced to patch their client and could no longer use it to determine that Messenger was an impostor.

No iOS Privacy Controls for Accessing Purchase History

Tim Burks:

Maybe you already knew that [MPMediaQuery playlistsQuery] gives arbitrary app developers full visibility of your iTunes purchase history.

For my account that’s at least songs, podcasts, movies, and iBooks.

Surprising.