Battling DPM
I’ve previously criticized Digital Privacy Management (complicated systems which try to publish data with coupled usage rights) from the “like DRM, it can’t work” perspective. Today I encountered the “and like DRM, it impedes utility” side.
So I’m tinkering with Twitter. As well as using it as One More Publishing Destination, I also want to follow some friends. I don’t want yet another reader to check, and for the most part I’d prefer to read in batches rather than real-time.
Well, Twitter offers an RSS feed for the updates of my friends, and I already wrote a feed summarizing service. Syndicating a daily summary of friend tweets to my one true public feed reader should be an easy exercise in glueing together willing services.
Except, the Twitter feed in question requires HTTP basic authentication. Yes, I have to supply my username and password in order to read my friend’s public tweets. Attack of the pointless privacy controls.
Now I can’t just supply a username:password@twitter.com URL to my feed reader, because that URL is public, and the same credentials would give write access to my own Twitter account. Twitter do provide OAuth access mechanisms, but standard feeding machinery isn’t going to start digitally signing requests even if I do jump through the token hoops.
I end up hiding the authentication details behind a reverse proxy on my own website. Here’s an Apache recipe for that since it wasn’t at all obvious to me:
RewriteEngine On
SetEnvIf Request_URI /your/proxy/url authorize_remote
RequestHeader set Authorization "Basic BASE64-of-username:password" env=authorize_remote
Header unset Set-Cookie env=authorize_remote
<Proxy http://remote.example.com/requiring/authorization>
Order allow,deny
Allow from all
</Proxy>
RewriteRule ^/your/proxy/url$ http://remote.example.com/requiring/authorization
This feels distinctly like burning DRM-ed music files to CDs and ripping them back to MP3, and for all I know the encoding round-trip possibly degrades sound (security) quality. Sigh.
