Didn't EMpeg (a british company that I _thought_ got bought out by Rio) have an 80GB in-dash (and I suspect component model as well) mpeg player over a year ago? A guy I knew had a 20GB version in his truck that was pretty slick, and when I checked, they went up to 80GB. That being said, they were pretty expensive at the time...well over $1K.
It does to me. A VP of Marketing is usually responsible for Product Management, which in turn is responsible for the product as a whole. If the components of their product are crappy, they're the ones who feel the heat. A good VP of Marketing at a technology company is going to be technically competent. May not be able to write-code/spin-chips but will be able to sort the technical issues out sufficiently to ship a product and guide it's evolution through the market place.
Most of these attacks are aiming to get the
web server to do something it shouldn't be
doing in any case. This is a good argument
for running it in a solid sandbox. There are
many ways of doing this (VM's and chroot'ing
are some simple mechanisms, there are numerous
more robust mechanisms), so that even if the
web server were exploited, it would be unable
to perform malicious actions on behalf of the
attacker.
This is not to say that you shouldn't attempt
to write robust server code, but to put all of
your security eggs in the basket of your
request parser is a dangerous idea.
Didn't EMpeg (a british company that I _thought_ got bought out by Rio) have an 80GB in-dash (and I suspect component model as well) mpeg player over a year ago? A guy I knew had a 20GB version in his truck that was pretty slick, and when I checked, they went up to 80GB. That being said, they were pretty expensive at the time...well over $1K.
It does to me. A VP of Marketing is usually responsible for Product Management, which in turn is responsible for the product as a whole. If the components of their product are crappy, they're the ones who feel the heat. A good VP of Marketing at a technology company is going to be technically competent. May not be able to write-code/spin-chips but will be able to sort the technical issues out sufficiently to ship a product and guide it's evolution through the market place.
Most of these attacks are aiming to get the web server to do something it shouldn't be doing in any case. This is a good argument for running it in a solid sandbox. There are many ways of doing this (VM's and chroot'ing are some simple mechanisms, there are numerous more robust mechanisms), so that even if the web server were exploited, it would be unable to perform malicious actions on behalf of the attacker. This is not to say that you shouldn't attempt to write robust server code, but to put all of your security eggs in the basket of your request parser is a dangerous idea.