't Bijstere spoor

Just got a new alpha for this WebDAV library, this version mostly contains bugfixes, and:

• Makes use of gzuncompress() instead of gzdecode()
• Support for Smultron temporary files.
• Now a pear package and also has a phing build script.

I found it hard to figure out all non-standard behaviours for the common WebDAV clients, as there wasn't a lot of information to be found on the net. I documented all my findings, which could perhaps be of use for other implementors of the protocol. I'm hoping this will become a good resource for this stuff.

• OS/X Finder
• Microsoft Windows (Vista and XP)
• DavFS/2

The package is still very much alpha state. Theo reported a segmentation fault while running the package on OS/X + Apache2 + PHP 5.2.5. My own testing environment is Debian Etch + Apache 2 + PHP 5.2.0-8+etch11, and I got some good results there.

Download here.

I was on a trip to NYC, and the internet addict in myself decided I better take my macbook with me while doing some of the touristy stuff. I must have not been careful enough, because when I opened up the laptop later on I ended up with this:

My LCD screen is completely gone, except a small area in the top of the screen. I got the 3 year extended warranty, but browsing around on some of the forums out there it seems like Applecare doesn't cover broken LCD's :(.

Oh well, I'll be going to the apple store at 7 tonight, lets see what they say..

Update: Unsurprisingly, they didn't want to fix it. The bill was going to be 563 CAD for the parts, + an estimated 200 CAD for the actual repair, ending up at around 900 dollars including tax. I got a first generation cheap macbook at the time, and was not really happy with the HD space, so I decided to buy a new 250GB model, and I'll be using the old one at work, as a desktop. This way I'll also reduce risk of breaking the new one by carrying it around. Still an expensive joke though..

Later on I also figured it might have been the heat. I've been walking around with the mac in downtown manhattan for hours on a really hot day in a black backpack, and the screen part was pretty warped as well.. So another lesson is to not do that :)

Last week I heard I was going to a finalist for the canadian new media awards, in the category 'Best programmer of the year'. While I strongly feel there's way better programmers out there, who just weren't submitted, I am both honored and shocked.

Looks like I'm gonna have to get a suit, which is, as my friend put it, "trying to give a cat a bath". My company also got nominated in the category 'Most promising company of the year'. Too cool!

Via: Jeremiah Grossman.

A proposal for a Site Security Policy has been proposed by mozilla employee Brandon Sterne. This is an extremely important specification for the web, and could be a big step ahead for security on the web.

<rant>

Over the last decade websites have transformed into feature-rich web applications, with the introduction of Javascript and XMLHTTPRequest, Flash and whatnot. While great for user experience, this has also brought huge security implications, resulting in over 80% of all documented security vulnerabilities in 2007 being carried out using XSS.

While implementing all this new fancy stuff, browser vendors have been slacking thinking about the security implications and essentially the responsibility of safe browsing has been put on the user. (Remember the 90's advice of disabling cookies while browsing?). Browsers have become better over time, but one single XSS hole on any site can still have devastating effects for you and your users.

With the demand for web development and web developers still way higher than the supply, education is in a sorry state too. In job interviews I've conducted it's been rare to find a junior who knows of the concept XSS, and finding one who can explain the implications of CSRF, is, well, I've yet to meet one. I don't claim to be a security expert myself, but I feel everybody who's in the profession of web development, should at least be aware of the basic attack vectors and how to prevent them.

“If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.”

- Weinberg’s Second Law

</rant>

With the Site Security Policy we're given the ability to lock down certain types of behaviours. It allows us to disable javascript included from unknown domains (a whitelist approach), and HTTP requests initiated by external domains, essentially fixing the CSRF problem completely. Additionally, it defines a way for a browser to log attempts to violate the policy.

For the actual implementation details, I'd suggest just reading the spec, even though its still a proposal, it's good reading material.

So whats next?

The spec needs to be finished. While the current policy is distributed through HTTP headers, some people seem to prefer an external file, like how crossdomain.xml or robots.txt is implemented. The latter would have my vote, because the policy can then be easily cached, which can save some bytes in the end. It would also be easier for people to upload a policy file to a server where there's no scripting available and allows the policy to be enforced for a complete domain, instead having to add it to each and every script.

And last but not least, browser vendors would need to implement it. Sterne works at Mozilla, so that's a good sign already. Personally, I can't wait.

I killed the sshd daemon from one of our servers by accident today. I wanted to avoid going to the data center, so I was able to upload and run a PHP script to give me a shell..

Problem was, that it would run under the www-data user and trying to su to root gave me the following message:

After some googling, I found the solution from Tero's glob. If you have python installed, just run the following from your shell:

You now have a proper terminal, and things like 'su' will work as usual.