tempalias.com – now with bookmarklet
let's say you want to create one of these temporary aliases, but you don't actually want to leave the page you are on.
Good news is: Now you can.
- Visit tempalias.com once.
- Create any alias you want the bookmarklet to create for you in the future
- In the confirmation screen, you will be offered the bookmarklet to drag to your bookmarks bar.
Now whenever you are on a site you want to create a temporary alias for, just click that bookmarklet, hover the email field and press the left mouse button. The alias will be generated and filled into that email form.
If you are interested in how this was made, read the next entry of my development diary.
If you like to find out more about tempalias and more projects of mine, you should follow me on twitter here.
tempalias.com – creating the bookmarklet
Now that the bookmarklet feature is finished, let me take a few minutes to reflect on its creation, in the spirit of continuing the development diary.
The reason for the long silence after the launch is, believe it or not, the weather: Over the time I made the initial tempalias service, I began to really enjoy taking my 17inch MacBook Pro outside on the balcony and write code from there. In fact, I enjoyed it so much that I really wanted to continue that tradition when doing more work on the site.
Unfortunately from May first until May 21st it was raining constantly which made coding on the balcony kind of no-fun to do.
Now the weather was great and I could finish what I began way earlier.
So. How does one create a bookmarklet?
I didn't know much either, but in the end, the essence of a bookmarklet is JavaScript code that gets executed in the context of the page you are on when you are executing it. So that's something to work with.
Of course, you don't want to add all the code you need for your magic to work into that link target - that would be unmaintainable and there's some risk of breakage once the link gets too big - who knows at what size of the script browsers begin cutting off the code.
So you basically do nothing but creating a script tag sourcing the real script. This is what I'm doing too - the non-minified version of that code is in util/bookmarklet_launcher_test.js.
Looking at that file, you'll notice that the bookmarklet itself is configurable using that c variable (keeping the names short to keep the code as short as possible). The configuration is done on the results page that is shown once the alias has been generated (public/templates/result.template).
Why the host name? Because the script that is injected (public/bookmarklet.js) doesn't know it - when it's sourced, window.location would still point to the site it was sourced on. The script is static code, so the server can't inject the correct host name either - in fact, all of tempalias is static code aside of that one RESTful endpoint (/aliases).
This is a blessing as it keeps the code clean and a curse as it makes stuff harder than usual at places - this time it's just the passing around of the host name (which I don't want to hard-code for easier deployment and development).
The next thing of note is how the heavy lifting script is doing its work: Because the DOM manipulation and event-hooking up needed to make this work is too hard for my patience, I decided that I wanted to use jQuery.
But the script is running in the context of the target site (where the form field should be filled out), so we neither can be sure that jQuery is available nor should we blindly load it.
So the script is really careful:
- if jQuery is available and of version 1.4.2, that one is used.
- If jQuery is available, but not of version 1.4.2, we load our own (well - the official one from Google's CDN) and use that, while restoring the old jQuery to the site.
- If jQuery is not available, we load our own, restoring window.$ if it pointed to something beforehand.
This procedure would never work if jQuery wasn't as careful as it is not to pollute the global namespace - juggling two values (window.$ and window.jQuery) is possible - anything more is breakage waiting to happen.
The last thing we need to take care of, finally, is the fact that the bookmarklet is now running in the context of the target site and, hence, cannot do AJAX requests to tempalias.com any more. This is what JSONp was invented for and I had to slightly modify the node backend to make JSONp work for the bookmarklet script (this would be commit 1a6e8c - not something I'm proud of - tempalias_http.js needs some modularization now).
All in all, this was an interesting experience between cross domain restrictions and trying to be a good citizen on the target page. Also I'm sure the new knowledge will be of use in the future for similar projects.
Unfortunately, the weather is getting bad again, so the next few features will, again, have to wait. Ideas for the future are:
- use tempalias.com as MX and CNAME as to create your own aliases for our own domain
- create an iphone / android client app for the REST API (/aliases)
- daemonize the main code on its own without the help of some shell magic
- maybe find a way to still hook some minimal dynamic content generation into paperboy.
tempalias.com – bookmarklet work
While the user experience on tempalias.com is already really streamlined, compared to other services that encode the expiration settings and sometimes even the target) into the email address (and are thus exploitable and in some cases requiring you to have an account with them), it loses in that, when you have to register on some site, you will have to open the tempalias.com website in its own window and then manually create the alias.
Wouldn't it be nice if this worked without having to visit the site?
This video is showing how I want this to work and how the bookmarklet branch on the github project page is already working:
The workflow will be that you create your first (and probably only) alias manually. In the confirmation screen, you will be presented with a bookmarklet that you can drag to your bookmark bar and that will generate more aliases like the one just generated. This works independently of cookies or user accounts, so it would even work across browsers if you are synchronizing bookmarks between machines.
The actual bookmarklet is just a very small stub that will contain all the configuration for alias creation (so the actual bookmarklet will be the minified version of this file here). The bookmarklet, when executed will add a script tag to the page that actually does the heavy lifting.
The script that's running in the video above tries really hard to be a good citizen as it's run in the context of a third party webpage beyond my control:
- it doesn't pollute the global namespace. It has to add one function, window.$__tempalias_com, so it doesn't reload all the script if you click the bookmark button multiple times.
- while it depends on jQuery (I'm not doing this in pure DOM), it tries really hard to be a good citizen:
- if jQuery 1.4.2 is already used on the site, it uses that.
- if any other jQuery version is installed, it loads 1.4.2 but restores window.jQuery to what it was before.
- if no jQuery is installed, it loads 1.4.2
- In all cases, it calls jQuery.noConflict if $ is bound to anything.
- All DOM manipulation uses really unique class names and event namespaces
While implementing, I noticed that you can't unbind live events with just their name, so $().die('.ta') didn't work an I had to provide all events I'm live-binding to. I'm using live here because the bubbling up delegation model works better in a case where there might be many matching elements on any particular page.
Now the next step will be to add some design to the whole thing and then it can go live.
tempalias.com – debriefing
This is the last part of the development diary I was keeping about the creation of a new web service in node.js. You can read the previous installment here.
It's done.
The layout is finished, the last edges too rough for pushing the thing live are smoothed. tempalias.com is live. After coming really close to finishing the thing yesterday (hence the lack of a posting here - I was too tired when I had to quit at 2:30am) last night, now I could complete the results page and add the needed finishing touches (like a really cool way of catching enter to proceed from the first to the last form field - my favorite hidden feature).
I guess it's time for a little debriefing:
All in all, the project took a time span of 17 days to implement from start to finish. I did this after work and mostly during weekdays and sundays, so it's actually 11 days in which work was going on (I also was sick two days). Each day I worked around 4 hours, so all in all, this took around 44 hours to implement.
A significant part of this time went into modifications of third party libraries, while I tried to contact the initial authors to get my changes merged upstream:
- The author of node-smtp isn't interested in the SMTP daemon functionality (that wasn't there when I started and is now completed)
- The author of redis-node-client didn't like my patch, but we had a really fruitful discussion and node-redis-client got a lot better at handling dropped connection in the process.
- The author of node-paperboy has merged my patch for a nasty issue and even tweeted about it (THANKS!)
Before I continue, I want to say a huge thanks to fictorial on github for the awesome discussion I was allowed to have with him about node-redis-client's handling of dropped connections. I've enjoyed every word I was typing and reading.
But back to the project.
Non-third-party code consists of just 1624 lines of code (using wc -l, so not an accurate measurement). This doesn't factor in the huge amount of changes I made to my fork of node-smtp the daemon part of which was basically non-existant.
Overall, the learnings I made:
- git and github are awesome. I knew that beforehand, but this just cemented my opinion
- node.js and friends are still in their infancy. While node removes previously published API on a nearly daily basis (it's mostly bug-free though), none of the third-party libraries I am using were sufficiently bug-free to use them without change.
- Asynchronous programming can be fun if you have closures at your disposal
- Asynchronous programming can be difficult once the nesting gets deep enough
- Making any variable not declared with var global is the worst design decision I have ever seen in my life especially in node where we are adding concurrency to the mix)
- While it's possible (and IMHO preferrable) to have a website done in just RESTful webservices and static/javascript frontend, sometimes just a tiny little bit of HTML generation could be useful. Still. Everything works without emitting even a single line of dynamically generated HTML code.
- Node is crazy fast.
Also, I want to take the opportunity and say huge thanks to:
- the guys behind node.js. I would have had to do this in PHP or even rails (which is even less fitting than PHP as it provides so much functionality around generating dynamic HTML and so little around pure JSON based web services) without you guys!
- Richard for his awesome layout
- fictorial for redis-node-client and for the awesome discussion I was having with him.
- kennethkalmer for his work on node-smtp even though it was still incomplete - you lead me on the right tracks how to write an SMTP daemon. Thank you!
- @felixge for node-paperboy - static file serving done right
- The guys behind sammy - writing fully JS based AJAX apps has never been easier and more fun.
Thank you all!
The next step will be marketing: Seing this is built on node.js and an actually usable project - way beyond the usual little experiments, I hope to gather some interest in the Hacker community. Seing it also provides a real-world use, I'll even go and try to submit news about the project on more general outlets. And of course on the Security Now! feedback page as this is inspired by their episode 242.
tempalias.com – SMTP and design
After being sick the end of last week, only today I found time and willpower to continue working on this little project of mine.
For people just coming to the series with this article: This is a development diary about the creation of a web service for autodestructing email addresses. Read the previous installment here.
The funny thing about the projcet is that people all around me seem to like the general idea behind the service. I even got some approval from Ebi (who generally dislikes everything that's new) and this evening I was having dinner with a former coworker of mine whom I know for doing kick-ass web design.
He too liked the idea of the project and I could con him into creating the screen design of tempalias.com. This is a really good thing as whatever Richard touches comes out beautiful and usable.
For example, he told me that it makes way more sense to just expose a valid until date and in the form of "Valid for x days" instead of asking the user to provide a real date. This is not only much clearer and easier to use, it also fixes a brewing timezone problem I had with my previous design:
Valid for "3 days from now" is 3 days from now wherever on the world you are. But valid until 2010-04-16 is different depending on where you are.
This is a rare case of where adding usability also keeps the code simpler.
So, this is what Richard came up with so far:
It's not finalized yet, but in the spirit of publishing here early and often, I'm posting this now. It's actually the third iteration already and Richard is still working on making it even nicer. But it's already 2124 times better than what I could ever come up with.
On the code-front, I was looking into the SMTP server, where I found @kennethkalmer's node-smtp project which provides a very rough implementation of an SMTP daemon.
Unfortunately, it doesn't run under node trunk (or even 0.1.30), but with the power of github, I was able to create my own fork at
http://github.com/pilif/node-smtp
My fork contains a bit of additional code compared to the source:
- Runs under node trunk (where trunk is defined as "node as it was last tuesday")
- Enforces proper SMTP protocol sequence (first: HELO, then MAIL FROM, then RCPT TO and finally DATA)
- Supports multiple recipients (by handling multiple RCPT TO)
- Does some email address validation (which is way too strict for being RFC compliant)
Tomorrow, I'm going to use this fork to build an SMTP server that we'll be using for alias processing, where I will have to put some thought into actual mail delivery: Do I deliver the mail myself? Am I offloading it to a mail relay (I really want to do this. But read more tomorrow)? If so, how is this done with the most memory efficiency?
We'll see.
tempalias.com – another day
This is the second installment of an article series about creating a web service for self-destructing email aliases. Read part 1 here.
Today, I spent a lot of thought and experimentation with two issues:
- How would I name and identify the temporary aliases?
- How would I store the temporary aliases
Naming and identifying sounds easy. One is inclined to just use an incrementing integer or something alike. But that won't work for security reasons. If the address you got is 12@tempalias.net, with any likelyhood, there will be an 11@ and a 13@.
Using that information, you could easily bring the whole service down (and endlessly annoy its users) by requesting an address to get the current ID and then sending a lot of mail to the neighboring IDs. If those were created without a mail count limitation, then you could spam the recipient for the whole validity period and if they were created with a count limitation, you could use up all allowed mails.
So the aliases need to be random.
Which leads to the question of how to ensure uniqueness.
Unique random numbers you ask? Isn't this what UUIDs were invented for?
True. But considering the length of an UUID, would you really want to have an alias in the form e8ea98ce-dabc-42f8-8fcd-c50d20b1f2c5@tempalias.net? That address is so long that it might even hit some length limitation of the target site, which of course is true even if you apply cheap tricks like removing the dashes.
Of course, using base16 to encode an UUID (basically an 128 bit integer) is hopelessly inefficient. By increasing the amount of characters we use, we might be able to decrease the amount of characters.
Keep in mind though, that the string in question is to be a local part of an email address and those tend to be case insensitive with not much guarantees that case is preserved over the process of delivering the message.
That, of course, limits the amount of characters we can use to basically 0-9 and A-Z (plus a few special characters like + . - and _).
This is what Base32 was invented for, but unfortunately, a base32 encoded UUID would still be around 26 characters in length. While that's a bit better, I still wouldn't want the email address scheme to be eda3u3rzcfer3fztdvvd6xnd3i@tempalias.com
So in the end, we need something way smaller (adding + . - and _ to the character space wouldn't help much - what comes out is about 20 characters in length).
In the end, I would probably have to create a elaborate scheme doing something like this:
- pick a UUID. Use the first n bytes.
- base32 encode.
- Check whether that ID is free. If not, add 1 to n and try again.
- Keep n around so that in the future, we can already start with taking bigger chunks.
So the moment we reach the first collision, we increase the keyspace eight-fold. That feels sufficiently safe from collisions to me, but of course it increases the maintenance burden somewhat.
The next question was how to get UUIDs and how to base32 encode them from JavaScript.
I tried different aspects, one of which even included using uuidjs and doing the b32 encoding/decoding in C. The good part about that: I now have a general idea of how to extend nodejs with C++ code (yeah. it has to be C++ and my b32 code was C, so I had to do a bit of trickery there too).
In the end though, considering that I can't use UUIDs anyways, we can go forward using Math.uuid.js and use their call using both len and radix (with the additional change of only using lowercase to encode the data), increasing the length as we hit collisions.
So the next issue is storage: How to store the alias data? How to access it?
This will be part of the next posting here.
tempalias.com – development diary
After listening to this week's Security Now! podcast where they were discussing disposeamail.com. That reminded me of this little idea I had back in 2002: Selfdestructing Email Addresses.
Instead of providing a web interface for a catchall alias, my solution was based around the idea of providing a way to encode time based validity information and even an usage counter into an email address and then check that information on reception of the email to decide whether to alias the source address to a target address or whether to decline delivery with an "User unknown" error.
This would allow you to create temporary email aliases which redirect to your real inbox for a short amount of time or amount of emails, but instead of forcing you to visit some third-party web interface, you would get the email right there where the other messages end up in: In your personal inbox.
Of course this old solution had one big problem: It required a mail server on the receiving end and it required you as a possible user to hook the script into that mailserver (also, I never managed to do just that with exim before losing interest, but by now, I would probably know how to do it).
Now. Here comes the web 2.0 variant of the same thing.
tempalias.com (yeah. it was still available. so was .net) will provide you with a web service that will allow you to create a temporary mail address that will redirect to your real address. This temporary alias will be valid only for a certain date range and/or a certain amount of email sent to it. You will be able to freely chose the date range and/or invocation count.
In contrast to the other services out there, the alias will direct to your standard inbox. No ad-filled web interface. No security problems caused by typos and no account registration.
Also, the service will be completely open source, so you will be able to run your own.
My motivation is to learn something new, which is why I am
- writing this thing in Node.js (also, because a simple REST based webapp and a simple SMTP proxy is just what node.js was invented for)
- documenting my progress of implementation here (which also hopefully keeps me motivated).
My progress in implementing the service will always be visible to the public on the projects GitHub page:
http://github.com/pilif/tempalias
As you can see, there's already stuff there. Here's what I've learned about today and what I've done today:
- I learned how to use git submodules
- I learned a bunch about node.js - how to install it, how it works, how module separation works and how to export stuff from modules.
- I learned about the Express micro framework (which does exactly what I need here)
- I learned how request routing works
- I learned how to configure the framework for my needs (and how that's done internally)
- I learned how to play with HTTP status codes and how to access information about the request
What I've accomplished code-wise is, considering the huge amount of stuff I had plain no clue about, quite little:
- I added the web server code that will run the webapp
- I created a handler that handles a POST-request to /aliases
- Said handler checks the content type of the request
- I added a very rudimentary model class for the aliases (and learned how to include and use that)
I still don't know how I will store the alias information. In a sense, it's a really simple data model mapping an alias ID to its information, so it's predestined for the cool key/value stores out there. On the other hand, I want the application to be simple and I don't feel like adding a key/value store as a huge dependency just for keeping track of 3 values per alias.
Before writing more code, I'll have to find out how to proceed.
So the next update will probably be about that decision.
JSONP. Compromised in 3…2…1…
To embed a vimeo video on some page, I had a look at their different methods for embedding and the easiest one seemed to be what is basically JSONP - a workaround for the usual restriction of disallowing AJAX over domain boundaries.
But did you know, that JSONP not only works around the subdomain restriction, it basically is one huge cross site scripting exploit and there's nothing you can do about it?
You might have heard this and you might have found articles like this one thinking that using libraries like that would make you save. But that's an incorrect assumption. The solution provided in the article has it backwards and only helps to protect the originating site against itself, but it does not help at all to protect the calling site from the remote site.
You see, the idea behind JSONP is that you source the remote script using <script src="http://remote-service.example.com/script.js"> and the remote script then (after being loaded into your page and thus being part of your page) is supposed to call some callback of the original site (from a browsers standpoint it is part the original site).
The problem is that you do not get control over the loading let alone content of that remote script. Because the cross-domain restrictions prevent you from making an AJAX request to a remote server, you are using the native HTML methods for cross domain requests (which should not have been allowed in the first place) and at that moment you relinquish all control over your site as that remotely loaded script runs in the context of your page, which is how you get around the cross domain restrictions - by loading the remote script into your page and executing it in the context of your page.
Because you never see that script until it is loaded, you cannot control what it can do.
Using JSONP is basically subjecting yourself to an XSS attack by giving the remote end complete control over your page.
And I'm not just talking about malicious remote sites... what if they themselves are vulnerable to some kind of attack? What if they were the target of a successful attack? You can't know and once you do know it's too late.
This is why I would recommend you never to rely on JSONP and find other solutions for remote scripting: Use a local proxy that does sanitization (i.e. strict JSON parsing which will save you), rely on cross-domain messaging that was added in later revisions of the upcoming HTML5 standard.
Newfound respect for JavaScript
Around the year 1999 I began writing my own JavaScript code as opposed to copying and pasting it from other sources and only marginally modifying it.
In 2004 I practically discovered AJAX (XmlHttpRequest in particular) just before the hype started and I have been doing more and more JavaScript since then.
I always regarded JavaScript as something you have to do, but which you dislike. My code was dirty, mainly because I was of the wrong opinion that JavaScript was a procedural language with just one namespace (the global one). Also, I wasn't using JavaScript for a lot of functionality of my sites, partly because of old browsers and partly because I have not yet seen what was possible in that language.
But for the last year or so, I'm writing very large quanitites of JS in very AJAXy applications, which made me really angry about the limited ways you could use to structure your code.
And then I found a link on reddit to a lecture of a yahoo employee, Douglas Crockford, which really managed to open my eyes.
JavaScript isn't procedural with some object oriented stuff bolted on. JavaScript is a functional language with object oriented and procedural concepts integrated where it makes sense for us developers to both quickly write code and to understand written code even with only a very little knowledge of how functional languages work.
The immensely powerful concept of having functions as first class objects, of allowing closures and of allowing to modify object prototypes at will makes turns JS into a really interesting language which can be used to write "real" programs with a clean structure.
The day when I have seen those videos, I understood that I had the completely wrong ideas about JavaScript mainly because of my crappy learning experience so far which initially consisted of Copying and Pasting crappy code from the web and later of reading library references, but always ignoring real introductions to the language («because I know that already»).
If you are interested to learn a completely new, powerful side of JavaScript, I highly recommend you watch these movies.