TimMc: If I understood correctly what you're getting at is that we currently have certain schemes to help limit data exfiltration from vulnerable programs (e.g. a server that loads and displays arbitrary user XML and pulls in any data the XML asks for) that might not work in IPFS-land.

That's true, the existing strategies don't work and to a large extent they shouldn't. For example, a file F that an organization may think/wish was private, but has in fact already been publicly leaked should be retrievable by some anyone asking for hash(F). This isn't to say that other more IPFSy solutions wouldn't solve the same problems. For example, the vulnerable XML viewing server you described could be protected by having the server whitelist/blacklist hashes of data (which would prevent the server from even propagating blacklisted publicly available data) or whitelist/blacklist the networks/peers that it connects to. The model changes a bit, but the problems aren't really that different.

One other point here is that IPFS really should make it much easier to use cryptography to protect the data that you care about and should also make it much easier for more software to be run client side than server side, both of which help with the types of vulnerabilities you've mentioned