The porron wine pitcher is a festive way to serve wine or sangria. Just pick up the porrón and tilt it so that a thin stream of wine pours directly into your mouth! It takes some skill, but it is fun at a party to see how well you and your friends master the technique. It is also a great way to share sangria with friends. Each porron holds 1 liter, well over a bottle of wine.

Ahhhh yeah!

LaTienda.com - Glass Porron Wine Pitcher

Google's new Favicon pisses me off. I'm not sure why. I know this is irrational, but that doesn't make me dislike that lowercase "g" any less.

Faked, but still funny.

Fake, but funny: Cell phones cook popcorn

So .NET MD5 Crypto providers are *not* thread safe.

... [sigh] 20 minutes of my life that I will not get back.

.NET MD5 Crypto providers are *not* thread safe

I went diving into my email archive today looking for something and located this gem quite by happenstance.

From: "Billy Hoffman" [billy.hoffman@spidynamics.com]
To: ****
Cc: ****
Sent: 8/7/2006 1:29 PM
Subject: Re: ****

I want to take all these no talent, tech trendy ass clowns and drown them in the ocean.

The reason we have insecure programmers is these "evangelists" are spending too much time hyping things up to get people to buy into their shitty technology and are spending no time teaching those very people how to properly use it. They then turn around and say “no problem here, this is caused by novices” all while ignoring that their hip and witty blogosphere bullshit is what brought the “novices” into the field in the first place.

This is like leading a horse to water, forgetting about him, yelling at everyone how stupid the horse is for not drinking, and then publicly shooting the horse.

Now, unless you really want me to say all that to these fellows, I suggest someone else kindly point these guys to our whitepaper.

Billy

Left Hand: Hi, I'm the left hand. We've never met before, but I'm going to do things that make no sense whatsoever and that will undermine all the hard work of the right hand! Yeah team!

Right Hand: Wait, what did you just say? [shit lands on right hand]

Such is my life at times.

We're in the final week before Summercon 2008! Come out Friday night @ 7PM and meet at the Wyndham Hotel bar, a.k.a. "The Mojito Lounge". Don't be shy, just look for someone wearing a Summercon t-shirt and introduce yourself. They won't bite or fight... probably. We'll plan on hanging out at the hotel for a bit and then herd everyone to another fine drinking establishment. Friday night is an ice-breaker, so come out and get to know your friendly neighborhood hacker. Don't sleep in much past noon on Saturday, presentations start at 12:30PM.

Operation Summercon 2k8 in Da House | summercon 2008

An exploit in standard parlance is a program that can get control of another program, not just crash it. Crashing a program is known as producing a proof-of-concept. It's the difference between screaming "Haberdashery!" at someone until they go away and convincing them with reasoned argument.

Move over dancery and hateration. Thanks to Dave, I'm adding "Haberdashery!" to my general vocabulary.

Dave Aitel: "Haberdashery!"

Wow... this is on par with all the sexual innuendo in American Gladiators that makes me wonder "What were they thinking?"

Venus: "And once she had her legs around me I had to take a dive."

You just can't make this stuff up!

Asylum | For All Mankind

In the early days of the web HTTP sat at the application layer (layer 7) and rode atop TCP, its transport layer.

An interesting thing happened on the way to the 21st century; HTTP became an application transport layer. Many web applications today use HTTP to transport other application protocols such as JSON and SOAP and RSS.

This is not the same as tunneling a different application through port 80 simply because almost all HTTP traffic flows through that port and it is therefore likely to be open on the corporate firewall. They're essentially just pretending to be HTTP by using the same port to fool firewalls into allowing their traffic to pass unhindered.

No, this is different.

This is the use of HTTP to wrap other application protocols and transport them. The web server interprets the HTTP and handles sessions and cookies and parameters, but another application is required to interpret the messages contained within because they represent the protocol of yet another application.

The problem is, of course, that there are no standards beyond HTTP. My JSON-based Web 2.0 application looks nothing like your SOAP-based Web 2.0 application. And yet a single solution must be able to adapt to those differences and provide the same level of scalability and reliability for me as it does you. It has to be extensible. It has to provide some mechanism for adding custom behavior and addressing the specific needs of application protocols that are unknown at the time the solution is created.

Applications aren't about HTTP anymore, they're about undefined and unknowable protocols.

There's a lot of traffic out there that's just HTTP, as it was conceived of and implemented years ago. But there's a growing amount of traffic out there that's more than HTTP, that's relegated this ubiquitous protocol to an application transport layer protocol and uses it as such to deliver custom applications that use protocols without RFCs, without standards bodies, without the W3C.

This is why Layer 4 IDS/IPS will not win. There's an RFC that defined IPv4, IPv6, TCP, SSL, etc. You can easily test structure and determine malformed IP packets. You can use stateful packet inspection to check FTP. There is no RFC that defines JSON. There is no RFC that defines what what the data inside the JSON literals is going to look like. There is no RFC about the character encodings that I'm applying. I've seen web applications using pipe (|) separated quoted strings that are Base64-ed to transfer data back and forth. How do you deep inspect something when you don't know the format?

(actually, this reminds me of an awesome presentation I saw in Toorcon back in 2004, Protocol Analysis using Bioinformatics Algorithms)

HTTP has become the long haul, reliable application transportation protocol of web applications, and we have no idea what the traffic traveling over it is supposed to look like. So how is an appliance in your DMZ suppose to validate it?

HTTP: The Application Transport Layer?