That said, there's nothing novel here. People have been doing this for decades, and extensions to the bittorrent protocol use it all the time to prioritize LAN seeds over internet seeds. In fact, I believe there was talk a while back about optimizing BT to prioritize peers and seeds on the same subnet/ISP as a way of mitigating ISP bandwidth concerns and whatnot.
[1] https://facebook.com//download/1411324735760067/devops.pdf
Specifically, a LANSync peer can only request blocks for which it shares namespace authorization. Each distinct shared folder context (e.g. a folder shared between users, a whole Dropbox folder authorized for a single user on multiple computers) has a different namespace, and that namespace is associated with a keypair, issued by Dropbox. Block discovery and exchange is conducted over HTTPS, with each client and server having to use the key associated with the namespace of the block they wish to exchange.
Since Dropbox clients/peers use SNI to identify the namespace, an eavesdropper on the network could know that two computers have access to the same namespace/folder (it is not clear from the post if the namespace contains any specific identifying information beyond its uniqueness), but not which files (or, more accurately, blocks) that namespace contained. A user who knew the key for a namespace could identify blocks being exchanged, but such a user would already have owned the Dropbox installation enough to have access not just to the list of files but to the files themselves.