D-talk

A world without cookies

2011-06-27T20:00:00Z

Imagine a world wide web without cookies. And this might not be the strangest thing, since the use of cookies is severely limited since Wednesday the 22nd of June 2011 in the Netherlands. And more countries will follow: http://www.bbc.co.uk/news/technology-12668552.

The Law

The (Dutch) law, that requires a user to agree before storing data, doesn't only apply on HTTP cookies. But in fact any kind of data that is stored on the users computer. Such as; HTML5 storage, flash cookies. But also desktop applications, etc.. The law also states that cookies "required" for certain functionality, are allowed without confirmation. Personally I don't see how anything will change, with this exception in place. And I wonder how many experts were involved into making this law. But that is a subject for another article perhaps...

What are cookies

Cookies are little packages of information stored in the browser of a website visitor, they can contain "small" amounts of data such as an identifiable token or a user preference.

What purpose do cookies serve

Cookies are very generic and can be used for many things, good and bad. The most popular probably being tracking your activity and advertisement. But they are also used to keep a state between requests and to store a preference. Such as "remember me" at a login form, or perhaps "no I do not want to participate in your survey".

Cookie problems

If When the law becomes international, you are potentially violating laws by simply calling something like: setcookie() without the users consent. There are hacks around the typical HTTP cookies, by using flash cookies for example (Oh and btw, here a guide on how to clear those: http://www.macromedia.com/...ngs_manager07.html). And possibly HTML5 storage could play a role here (or any of it's derivatives).

Another thing that has been happening, is visitor awareness and thus browser features. More and more people block cookies to stop advertisement tracking, but unfortunately this also prevents a user to use the features he or she wants to use (such as login sessions, etc.). There is an answer for this and quite a few browser vendor's plan on implementing the "Do Not Track" (http://donottrack.us/) feature, or have already done so. But I'm not too happy with it. The downside of "Do Not Track" is that it's voluntary for website owners and advertisement companies to respect this feature. Other tools include projects such as "Ad Blocker", that only block cookies (and more) for advertisement purposes. It works pretty good, but that is hardly user-friendly.

But, back to "no more cookies"... How do you solve the problem of keeping a state between requests over a stateless protocol?

Some ideas

Well in short, I have some ideas but definitely no real answers. I don't think there is a real answer just yet.

Let's take the example of a login session. Where you want to offer a secure section to your visitors, where they can (e.g.) read their e-mail, privately. A few things come to mind:

Identifying yourself in every relevant request, using headers for example or an argument &userId=42 in the request. This however has some big problems on its own.
Digest authentication on every relevant request.
Take a look at other technologies, such as IPv6 and move authentication to a lower level.
Perhaps use a commit and rollback system. Where you can do a variety of actions and only your password will be asked in the end, either applying or discarding your actions. Requiring you only to enter your login once. Not the most ideal solution for e-mail though, I have to admit. With this system you would re-post your data to next screens in a similar fashion as e.g. a wizard.
Or perhaps we need to move away from complete server-side applications and move to the client, Javascript applications and use the HTTP spec a little better as it was intended and only have web-services.

Many, if not all, of the things I mentioned above would require secure connections (SSL/TLS) to avoid other security problems. Which might not be a bad move anyway.

Personally I think that there is a future, in an improved implementation of digest authentication over SSL. One that uses HMAC and stronger algorithms, SSL would then supply the missing server validation feature. It should also be more strict and not fall back to insecure legacy features.

Conclusion

All in all I firmly believe that the browser should play a big role in this new cookie recipe and should (partially) solve these problems. Also there should be a more clear separation between "generic storage" and authentication versus a simulated persistency. In more perfect world I would vote for a solution that works on other (underlying) layers and make it application agnostic.

I suppose the point I'm trying to make with this article is the following: Take away a feature the entire world uses (since 1996), and wait for the brilliant and creative minds, perhaps such as yourself, to come up with a more innovative feature. It's time for something better!

Another interesting read:

http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf

I made some updates to this article, based on some comments.

PHP Quiz part 4

2010-11-02T08:18:00Z

It has been a while, but here is part 4 of the PHP Quiz series! A few questions to crack your brain about, or perhaps you know them all? Try them and find out! Also do read the idea behind these quizzes, here: The PHP Quiz series

As always, think of the answer before you execute the code or look it up. Codepad might help you run the examples. You can find round three here.

Visibility is key

Now you see me, now you don't

class testClass {
private $fubar = "rabuf";

function test($test) {
var_dump($test->fubar);
}
}

class dummy {
function test($test) {
var_dump($test->fubar);
}
}

$object1 = new testClass;
$object2 = new testClass;
$dummy = new dummy;

$object1->test($object1); // Can $object1 see the private property of object1 ?
$object1->test($object2); // Can $object1 see the private property of object2 ?
$dummy->test($object1); // Can $dummy see the private property of object1 ?

Static, sticky, icky

class test {
public $counter = -1;

public function increment() {
static $cnt = 0;
$this->counter = ++$cnt;
return $this;
}
}

$object1 = new test;
$object1->increment()->increment();

$object2 = new test;

// What will the output be
echo $object2->increment()->counter;

Getting the class

class b {
function getClassA() {
echo get_class($this);
}
function getClassB() {
echo get_class();
}
function getClassC() {
echo __CLASS__;
}
}

class a extends b {
}

$a = new a;

// What will be returned, 'a' or 'b' ?
$a->getClassA();
$a->getClassB();
$a->getClassC();

The strptime function

$result = strptime('2010-11-28', '%Y-%m-%d');

// What is the output?
echo $result['tm_mday'] .'-'. $result['tm_mon'] .'-'. $result['tm_year'];

The oldtimer

for ($i = 0, $loop = 10, $a = 10; $i < $loop; ++$i, $a = 0) {
++$a;
}

// What is the output ?
echo $a;

What do you get when you mix; MSSQL, PDO and uniqueidentifier?

2010-06-08T19:58:00Z

You get NULL!

Well you get NULL when you don't cast. Say for example you do the following:

$dbh = new PDO([..]);
$stmt = $dbh->prepare('SELECT accountid FROM dbo.Account');
$stmt->execute();

echo $stmt->fetchColumn(); // NULL

But when you do the following:

$stmt = $dbh->prepare('SELECT CAST(accountid AS varchar(36)) accountid FROM dbo.Account');
$stmt->execute();

echo $stmt->fetchColumn(); // "F05C92A1-3119-4206-A123-49A759AC99FB"

I didn't think the casting would be necessary, since according to the manual: http://msdn.microsoft.com/en-us/library/aa226054(SQL.80).aspx the datatype 'uniqueidentifier' has implicit casts with multiple data-types. But I guess it's just one of those things...

Forms, buttons and prototypeJS's getInputs()

2010-10-19T10:36:00Z

In forms you use input elements to send your form. But you can also use "button" elements to achieve the same goal. Quite recently someone committed changes into a framework I use often and changed the "input" elements to "button" elements. Normally this is no problem, but in this case it broke some Javascript I had going on.

I used to use the following:

$('myForm').getInputs('submit').each(function (button) {
// ..
});

But with this function you don't get any "button" elements, to solve this situation I changed it to:

$('myForm').select('button', 'input[type=submit]').each(function (button) {
// ..
});

It works fine however simply filtering on 'button' might be too greedy and some tweaking might be required. I use this to to track down which button was pressed by the user and act accordingly (e.g. "Save and close" versus "save").