True, but this isn't where you are going to store your credit card information. My guess is that this is a defense against those who want to control the Internet through legislation.
Imagine a world where SOPA had passed, and everyone who ran a website was legally responsible for everything that their users did.
In that scenario, one way for website operators to protect themselves is to make it impossible to know what their users are doing.
The 3rd party URL shorting service is not storing or associated with the encrypted data and is also not responsible for it.
So this may not be about private data so much as it is about protecting the freedom of information.
It would be pretty easy to build a tool to route around that type of law. I create a service that encrypts blobs of data (encryptmyblo.bs), and uses a (publicly defined somewhere) postMessage API to communicate that blob to and from a key value store provided by a third party. I have my friend set up a key value store service provider that stores and retrieves blobs (storemyblo.bs), including the facility to search for stored blobs of data based on binary strings.
Because the services exchange those KVPs via a postMessage API, neither service is actually communicating with one another directly or have a formal association. The user is effectively (via the browser) moving the data from one service to another. Since EncryptMyBlo.bs doesn't store any data, and StoreMyBlo.bs doesn't have visibility into the data, neither service would be in violation of those requirements.
Imagine a world where SOPA had passed, and everyone who ran a website was legally responsible for everything that their users did.
In that scenario, one way for website operators to protect themselves is to make it impossible to know what their users are doing.
The 3rd party URL shorting service is not storing or associated with the encrypted data and is also not responsible for it.
So this may not be about private data so much as it is about protecting the freedom of information.