It seems more and more of my sentences recently start "Fucking IE wouldn't do _______."

I spent last night re-working the 3 Memestreams recommendation bookmarklets into a single bookmarklet. It's a little clumsy to have 3, they don't all do the same thing or present the same UI, and there's a bug when selecting text inside of a frame. So I get going and quickly create a better one. Problems with IE quickly develop:

1- You cannot drag "javascript:" bookmarks onto the toolbar if you have IE6+XPSP2 for security reasons. Ok, I'm on broad so far, but a prompt would have been nice instead of a flat denial. To be able to drag bookmarklets, you have to add the site to the list of trusted sites! This is a huge jump in what a site can and cannot do and a good example of how Microsoft is too coarse with their security settings. There should be a prompt to temporarily add a bookmarklet. I should not have to drastically and permanently elevate a site's trust to do this.

2- IE's JavaScript debugger sucks big time. Even the advanced version. Oh my kingdom for full blown Firebug in IE.

3- IE limits the size of a "javascript:" link to 508 characters! This makes having advanced bookmarklets for IE very annoying. Instead the bookmarklet has to bootstrap a larger JavaScript file by dynamically creating a <SCRIPT SRC="http://site.com/more.js">. But this is actually a privacy violation, because the HTTP request for the larger JavaScript file will have a referer (sic) header with the webpage the person is invoking the bookmarklet on! For Memestreams that's not as big of a problem, because you were about to tell Memestreams what URL you were looking at anyway. However there are many other types of bookmarklets where this could be very bad.

Now to be fair, fucking Firefox! It allows you to have multiple pieces of text selected on a page at the same time. For example, I could have text selected in the regaulr page, in multiple textboxes and text fields, and in multiple frames and iframes. From a bookmarklet point of view this makes it tough to know what text the user really cares about. The existing bookmarklet concatenates all the text together which is probably not what most people want.

Conspiracy is not a theory. It is a crime.

May we all be blessed and live in accordance with His teachings.

...

Besides, stopping a chemical spill with chocolate is so much cooler than the Loaves and the Fishes.

WWMD: What Would Macgyver Do?

The United States Mint, concerned that rising metal prices could lead to widespread recycling of pennies and nickels, has banned melting or exporting them.

According to calculations by the Mint, the metal value of pennies, which are made of copper-coated zinc, is now more than one cent. The metal value of 5-cent coins, made from a copper-nickel blend, is up to 7 cents. Adding in the costs of manufacturing means the Mint now spends 1.73 cents for every penny and 8.74 cents for every nickel it makes.

Until 1982, pennies were made of 95 percent copper. The commodity metal value of one of those coins, which still make up a large percentage of the pennies in circulation, is 2.13 cents, according to the Mint.

The funny thing is, a guy name Darrin I used to work with was doing exactly this. He was collecting large quantities of coins because the metal in them was worth more than monetary value of the coin. Of course "large quantities" is relative, he had collected a few hundred dollars worth of coins.

Melting pennies for fun and profit

What the hell happened? Where did we go wrong? How was Christianity co-opted by a political party? Why are Christians supporting laws that force others to live by their standards? The answers to these questions are integral to the survival of Christianity.

While the current state of Christianity might seem normal and business-as-usual to some, most see through the judgment and hypocrisy that has permeated the church for so long. People witness this and say to themselves, "Why would I want to be a part of that?" They are turned off by Christians and eventually, to Christianity altogether. We can't even count the number of times someone has given us a weird stare or completely brushed us off when they discover we work for a church.

It's nice to see some people get it.

Bakker, Brown: What the hell happened to Christianity? - CNN.com

I'm hoping that last night was caused bythe vodka and not the wine, because this book would sure be hard to write without the wine
--Bryan Sullivan, my co-author

In preparing a report, someone asked me how Ajax affects Denial of Service attacks. As I said in this post XmlHttpRequest doesn't really change things, because JavaScript could already generate HTTP traffic. In fact, XmlHttpRequest (the workhorse of Ajax) can only talk to the domain it comes from. Thus, I could make a botnet of MySpace users using an XSS vuln, but with XmlHttpRequest I could only attack MySpace with it.

So yet another way for JavaScript to generate HTTP traffic doesn't really change things. Is there anything else about Ajax that could affect DoS attacks?

I think so.

I would argue the way Ajax applications can make you more open to a DoS is from all the open web services and Ajax endpoints. A flood of traffic to an Ajax endpoint is worse than a traffic flood against a random wenpage because each time you contact that webservice the server has some computation to do. Presumably moreso than the computation to simply serve a webpage. Furthermore, responses from Ajax endpoints are not typically cached by a Squid proxy or any other “website accelerator” the way web pages are. Even if they were, this wouldn't help very much. Think about how often someone requests the login webpage versus someone contacting a webservice to spell check Aardvark.

Another DoS vector I see with Ajax applications is something I'm going to call Control Logic Denial of Service. All those web services and Ajax endpoints are API calls into the application. By looking at the JavaScript code that’s pushed to the client, I can see in what order and how often these webservices are contacted, as well as what the parameters are. In essence, this is a blueprint of the steps the applications takes to function normally. However, it is also a blueprint on how to use the application incorrectly. Some webservice may allocated resources where as another one cleans it up. An attacker could simply never call the clean up functions. Or I simply call all the functions out of order. Even if the code fails gracefully, it is extremely expensive for a program to generate an Exception, even it gets caught.

A traffic flooding DoS is like throws millions of small punches hoping you take an opponent down. A Control Logic DoS is like cutting open their head and punching them a few times in the brain.

Now, before Memestreams gets a bunch of web sec people registering to bitch at me that this isn't new, you are right. I'm sure this has been done before in various situations. Could you do this attack against a web app before Ajax? Probably. If I have a three step registration process spread over three webpages, calling them out of order could have the same effect. One difference I see is that in this situtation, the only way I could know the control flow (i.e., PageA POSTs to PageB which POSTs to PageX) would be to actually walk through the web app myself. In contrast, Ajax applications typically expose their entire API in a single webpage with a mass of JavaScript which would contain the callback code. This happens more than you would think. See Alex Stamos's Blackhat presentation for more details on how Ajax apps expose their entire API.

Method binding

As a consequence of this being "passed" to functions, this is not fixed for a function. That means that a function does not have an "owner" or "parent", even if it is a method. In other words, a method is not bound to the object that it is a method of.

A more general explanation of the underline problem of my last post. Essentially, what object the keyword this references inside of a function can change, based "who" is calling the function.

    //constructor for new Car object
    function Car(name) {
        this.name = name;
    }
    //method for object
    function Car_display() {
        alert(this.name);
    }
    //adds the method display() to all car objects
    Car.prototype.display = Car_display;

    //creates a new Car object
    var car = new Car("Vette");

    car.display(); //prints out "Vette" as expected

    //creates a new Car object
    var car2 = new Car("Truck");

    car2.display(); //prints out "Truck" as expected


    //grab a reference to the car function
    var carfunc = car.display;
    //set a global variable whose name is name
    var name = "HAHAHA!";
    
    carfunc();     //prints out "HAHAHA"  WTF?
    Car_display(); //prints out "HAHAHA"  WTF?

Here is what's happening. When JavaScript executes the state car.display() it first finds the function pointed to by the variable car.display; That function is Car_display. JavaScript also sets the this variable to the object which called the function. In this case, that object was car which we created. Thus Car_display is executed and the this variable points to the object car which contains a member variable name.

What about car2.display()? The same thing. JavaScript it first finds the function pointed to by the variable car2.display; That function is still Car_display. JavaScript also sets the this variable to the object which called the function. In this case, that object was car2. Thus Car_display is executed and this is pointing to the car2 variable, whose name variable is "Truck."

There is a single function Car_display, and all instances of a car object simply call that function, and JavaScript sets up the "environment" so that is it accessing the proper variables.

Nothing so far is too different than a OO language like C# or Java.

Next we save a reference to the function car.display, which is really a reference to Car_display, in the variable carfunc When we execute the statement carfunc() are calling the function Car_display. But what is the value of this? Well, since the function was called in the global context, this references to the global object. All function and variables in the program are ultimately part of the global object. In this example the global object has the following variables:

-Car: a function
-Car_display: a function
-car: a variable, currently an instance of a Car object
-car2: a variable, currently an instance of a Car object
-carfunc: a variable which references the function Car_display
-name: a variable, currently set to the string "HAHAHA"

So, carfunc() calls the function Car_display, and sets the variable this to point at the global object. Since this.name reference to the global object's variable name, the function displays "HAHAHA."

A closure allows you to get around this weirdness. See the referenced article for more information

Its all relative: When 'this' doesn't actually refer to 'this'

Or, solving the scope issue of callback functions without resorting to global variables!

//set the var so we can scope the callback var _this = this;
//callback will be an anonymous function that calls back into our class
//this allows the call back in which we handle the response (_onData())
// to have the correct scope.
this._request.onreadystatechange = function(){_this._onData()};

Encapsulating XmlHttpRequest Calls within JavaScript classes

Good guidelines for the makers of the Dojo toolkit about JavaScript programming style. Covers things like variable naming, function naming, denoting datatype with JavaScript's late binding, etc

Javascript Programming Conventions