Yeah, parent comment is correct. MD5 roots are not important *yet*, though they may be an issue in the future when MD5 collisions can be created arbitrarily (versus using birthday attacks).
MD5 certs anywhere in the chain (with the exception of the trusted root) mean that the certificate is suspicious *today*.
It's a problem for all websites. All you need to do is forge a certificate from Amazon that uses MD5 and redirect someone's browser via Wifi hacking or DNS redirection.
The browser doesn't know that Amazon didn't use Verisign's busted MD5 cert root.
But nature has a lot longer than us to retaliate. It's like that creepy guy in the office you pissed off a few years ago - he's just waiting for the right time to get you back.
I'd wager "contributory copyright infringement" or "accomplice to copyright infringement on a gross level". Those sound like nice, scary terms to charge someone with. If they aren't a crime yet, they will be.
Enterprise and business software used far more draconian DRM in the 80's than games.
Lotus 1-2-3 (that was the example I was looking for before) used to force a single install from a set of floppies. It basically invalidated a physical set of floppies that *you owned*.
Anyways, I'm just saying that sofware companies have been leaving bits of their software over your data. They've been doing it with floppies and hard drives since those existed.
There were other copy-protection schemes that existed for DOS and before Windows '95.
You might have been too young for this, but some early software was actually removed from the installation disks during the installation process. You need to run an uninstall process to remove it from the hard drive and return it to the floppies (yeah, it's weak but it existed).
There were plenty of other "hide a system file on your DOS partition" installers too. You could also do tricks where you leave tracks within the dead space of directory contents on the old FAT16 partitions.
So to re-iterate, companies have been doing this since the first hard drives existed and haven't thought twice about it.
Reminds me of when I bought Worms 3D ten years ago. The copy protection was so bad I couldn't get it to run no matter what. It just refused to install and refused to go.
I ended up having to pirate the game just to get it running. Unfortunately the no-cd cracks took months, so the software sat unused on my shelf.
Since then I've only bought a couple of pieces of gaming software. It's too much of a hassle to game on a PC - I've given up.
Mmmm... Mode X. That crazy bastard stepchild of Mode 13h and something else.
Re:Put blame where blame is due
on
jQuery in Action
·
· Score: 1
These days, cross-browser issues fall into two camps:
- IE and everyone else - Minor intepretations of the spec that are easy to fix
The first ones are pretty insidious - you end up tweaking things so far for IE that it breaks the standard browsers. Examples: hasLayout, iframe contentDocument, etc.
The second ones are easy to fix. Usually it's a corner case anyways.
AJAX isn't the problem - it's just broken code. The same thing happens with non-AJAX websites all the time. I'll click something that submits to the server, wait for a while, give up and click it again and it fails because it was already submitted.
Normal websites are virtually unusable on crappy wireless connections. You are waiting all the time. Well written apps like Google Docs/Google Reader handle crappy network connection situations much better.
Another big advantage is structured testing in JUnit across all browsers. You can run your build in Hudson, start VMs and test your code at a unit-level in IE6, IE7, FF, Safari, etc.
Sharing code between server and client isn't a guarantee. The GWT emulation of the java.* hierarchy is spotty and you end up having to emulate some of the less-common-path Java features in some rare cases. For the most part, well structured code runs fine on both client and server.
As a GWT developer I'd agree with the above statement. We're using it for all sorts of Javascript-generation tasks and it works really well - it's just that you need to understand the abstraction.
I consider it to be a strongly typed version of Javascript, rather than a full abstraction layer. It's just too leaky to cover up all the differences. You still need to understand IE's hasLayout and CSS shortcomings.
That said, if any of you know GWT inside and out and are looking for a job, we at dotspots.com are hiring (you'll figure out how to find us).:)
Yeah, parent comment is correct. MD5 roots are not important *yet*, though they may be an issue in the future when MD5 collisions can be created arbitrarily (versus using birthday attacks).
MD5 certs anywhere in the chain (with the exception of the trusted root) mean that the certificate is suspicious *today*.
If you blacklist all CA's that use MD5 hashes in the root, you are likely safe (unless there's an unsafe intermediate somewhere).
IMHO, this needs a browser fix to mark any certificate with MD5 in its chain as potentially untrusted.
It's a problem for all websites. All you need to do is forge a certificate from Amazon that uses MD5 and redirect someone's browser via Wifi hacking or DNS redirection.
The browser doesn't know that Amazon didn't use Verisign's busted MD5 cert root.
Zing!
But nature has a lot longer than us to retaliate. It's like that creepy guy in the office you pissed off a few years ago - he's just waiting for the right time to get you back.
They've been secretly stealing all the cameras. Go ahead and check - I bet yours is missing. Bastards got mine last week.
Easy fix:
Build the elevator in the Florida everglades and use mosquito carcasses as reaction mass.
Apollo 1 doesn't count, as NASA declared a mulligan.
If homeopathy works, then my distilled water is more powerful than any of their concoctions!
It's not Lupus.
I'd wager "contributory copyright infringement" or "accomplice to copyright infringement on a gross level". Those sound like nice, scary terms to charge someone with. If they aren't a crime yet, they will be.
If you get into Aphex Twin, make sure you keep your copy of Windowlicker hidden at work. It tends to scare the coworkers...
Like I always said: "It's always a tough choice between cure and death squad."
Enterprise and business software used far more draconian DRM in the 80's than games.
Lotus 1-2-3 (that was the example I was looking for before) used to force a single install from a set of floppies. It basically invalidated a physical set of floppies that *you owned*.
Reference
Anyways, I'm just saying that sofware companies have been leaving bits of their software over your data. They've been doing it with floppies and hard drives since those existed.
The answer is simple: anti-arthritis death sqauds. If you end up with arthritis, we kill you and your whole family.
It's obvious- why hasn't anyone implemented it yet?
There were other copy-protection schemes that existed for DOS and before Windows '95.
You might have been too young for this, but some early software was actually removed from the installation disks during the installation process. You need to run an uninstall process to remove it from the hard drive and return it to the floppies (yeah, it's weak but it existed).
There were plenty of other "hide a system file on your DOS partition" installers too. You could also do tricks where you leave tracks within the dead space of directory contents on the old FAT16 partitions.
So to re-iterate, companies have been doing this since the first hard drives existed and haven't thought twice about it.
Reminds me of when I bought Worms 3D ten years ago. The copy protection was so bad I couldn't get it to run no matter what. It just refused to install and refused to go.
I ended up having to pirate the game just to get it running. Unfortunately the no-cd cracks took months, so the software sat unused on my shelf.
Since then I've only bought a couple of pieces of gaming software. It's too much of a hassle to game on a PC - I've given up.
Somewhere in the 80's. Basically right around the time where computers came with permanent attached storage.
Easy fix - buy a widescreen TV and put your sticky notes and family pictures on the side.
Mmmm... Mode X. That crazy bastard stepchild of Mode 13h and something else.
These days, cross-browser issues fall into two camps:
- IE and everyone else
- Minor intepretations of the spec that are easy to fix
The first ones are pretty insidious - you end up tweaking things so far for IE that it breaks the standard browsers. Examples: hasLayout, iframe contentDocument, etc.
The second ones are easy to fix. Usually it's a corner case anyways.
AJAX isn't the problem - it's just broken code. The same thing happens with non-AJAX websites all the time. I'll click something that submits to the server, wait for a while, give up and click it again and it fails because it was already submitted.
Normal websites are virtually unusable on crappy wireless connections. You are waiting all the time. Well written apps like Google Docs/Google Reader handle crappy network connection situations much better.
Another big advantage is structured testing in JUnit across all browsers. You can run your build in Hudson, start VMs and test your code at a unit-level in IE6, IE7, FF, Safari, etc.
Sharing code between server and client isn't a guarantee. The GWT emulation of the java.* hierarchy is spotty and you end up having to emulate some of the less-common-path Java features in some rare cases. For the most part, well structured code runs fine on both client and server.
As a GWT developer I'd agree with the above statement. We're using it for all sorts of Javascript-generation tasks and it works really well - it's just that you need to understand the abstraction.
I consider it to be a strongly typed version of Javascript, rather than a full abstraction layer. It's just too leaky to cover up all the differences. You still need to understand IE's hasLayout and CSS shortcomings.
That said, if any of you know GWT inside and out and are looking for a job, we at dotspots.com are hiring (you'll figure out how to find us). :)
One point four jiggapixels? One point four jiggapixels?? Great scott!