stuff by antimatter15

1_vgexamples_F_k1pC2sJzEqEynh

Here’s an idea for fighting phishing that seems to be a good idea (at least to me). I’m no security expert, but from what I understand about MITM and other issues, this should provide a decent solution. It could probably even help fight tabnapping.

The identicon was first thought of by Don Park and he has envisioned something pretty interesting that uses identicons for a similar purpose, however it requires certain changes to user agents and no browsers have yet implemented it.

The basic idea is that on the login page, the server generates an Identicon based on the hash of the user’s IP address and a certain secret salted string). This will generate a unique, and extremely hard-to-fake image that is associated with whatever computer (or network under NAT) the user is at. The great thing is that it requires absolutely no changes to the existing user experience, isn’t too aesthetically jarring and completely ignorable. If the user’s under a proxy and is aware of it, this doesn’t detract from the user experience, it’s just a visual sign that the user might be on the wrong site and it’s up to the user to decide whether or not to go on.

The login identicon is a unique signature of the server you’re communicating to and the IP address of your computer, if either one is slightly different, the icon will be completely different.

As the tabnapping issue shows, the problem isn’t that users are too lazy to read the URL bar, it shouldn’t even really be necessary to read the URL bar. There are far too many funky unicode hacks that can make URLs look like other URLs, and people’s memory of exact textual strings isn’t that good. Plus, imagine how much of humanity’s time will be wasted having to break the usual eye movement and look at a small box on the top, thinking intensely for a few seconds before returning back to the usual login procedure. Expecting people to do that is just too much.

This solution, however should provide an image that can be embedded (ideally) on or immediately next to the login box, so the user just notices it instead of searching for it.

I’ll probably provide a proof of concept soon, it’s six in the morning and I’m about to go to school. And here it is.

Screenshot-11

I just prototyped the anti phishing system described on the earlier post. Gareth Hayes noted that the the page could have been wrapped in an <iframe> to reuse the identicon. This implementation only shows the identicon if both javascript is present and functional and top==window. Hopefully there aren’t many other huge flaws with it. So it would be awesome if you tried it out.

https://launchpad.net/~xorg-edgers/+archive/ppa

This post was never finished, but I think that link is helpful enough without a write up.

Screenshot-2

This was a fun little project to create venn diagrams out of google suggest results. Try it out here.

Screenshot-19

With help from @Frenzie and @paul_irish, the latest not-yet-versioned release of Weppy, my Javascript WebP to WebM conversion library, or something of a polyfill for a format that is yet to be part of any specification (HTML5 seems to specifically reference the image src attribute are examples such as PNG, GIF, JPEG, APNG, PDF, XML, SVG, SMIL, and MNG). The new release brings some awesome new features that really don’t change much and shouldn’t really be used in the real world because most browsers in the world still aren’t Firefox, Chrome or Opera - that is, a large portion of the browser market includes browsers like Safari and IE, either suffering from antiquity (IE6! aah!) or just liking h264 (IE9 + Safari).

The new release supports Opera. I never bothered debugging Opera, I figured it was another huge issue that would demand a rewrite (as supporting Firefox had needed, because the order of the object keys isn’t preserved and breaks the EBML result, or at least for Firefox’s parser which seems to be somewhat stricter than Chrome’s, is that ffmpeg?). And after premature optimization (stripping “unnecessary” EBML tags), my code didn’t work in chrome, so I had to revert to an earlier revision. All my testing code was based on file drag-drop stuff, and Opera doesn’t support that. Until I saw this mozillazine topic, I didn’t care, but it was a lot easier to fix than I feared.

Part of the solution was getting rid of the canvas stage. Admittedly, the canvas stage was pretty useless once the toDataURL() stage was removed before the first public release, but I didn’t feel like deleting code, so it stayed there. Also, I noticed that the global variable that gets introduced was accidentally named “WebM”, which is wrong, it should be “WebP”, but because of the uncreative format naming and similarities, I didn’t notice. Not sure, but it seems to be more stable now.

Chrome probably will add WebP soon, and it needs to be future proof, detecting whether or not a browser supports the WebP format. To do that, it creates an Image, sets the src to a data url of a 4x4 webp image and listens to the onload and onerror events, checking if the size is correct and there were no errors loading it. The routine is expected to error and totally untested as there aren’t any browsers that support the feature yet for me to try.

Another change, is that by default, it will automatically load all the same-origin (because of the limitations of XHR) webp images (from <img> tags), on the DOMContentLoaded event, so the library is practically drop-in now. In any web page, you can pretty much add <script src=”http://antimatter15.github.com/weppy/weppy.js“></script> and on the supported browsers, it should automatically load and replace all WebP images, though not something I would really recommended.

The demo is the same place it always was: http://antimatter15.github.com/weppy/demo.html

There is also this nifty hack that uses <canvas> to add an alpha channel to the WebP image (adapted from the original JPEG one): http://antimatter15.github.com/weppy/alpha/alpha.html

Also, please follow me on twitter.