Class action lawsuits are *never* for the benefit of the actual aggrieved parties. They're simply cash cows for tort lawyers. Bill Lerach actually got caught *paying* people to be plaintiffs in shareholder class action suits - he went to jail for that, but how many others didn't?
It very well might be that heat dissipation requirements deem that laptop batteries be more efficient (read: latest-generation designs, which invariably will cost more per kWh), where lawnmower batteries can get away with models that throw off more waste heat.
Vixie didn't justify it - he acknowledged that it was a design flaw with no practical airtight fix besides DNSSEC - but he was one of the main players that coordinated the patches to get source port randomization, the best possible fix easily deployable, out there before the bug became public knowledge.
I suspect anycast would be a better method, honestly.
And you'd be completely, utterly wrong. I've seen anycast resulting some mind-numblingly stupid site selection choices, usually due to a local ISP's BGP policy - and when I say "stupid" I mean "all users of ISP X in New York City getting sent to a mirror in Sydney, Australia instead of the site downtown".
This might be OK for simple DNS queries, but for actual web sites it is a True Path To Pain.
Allowing customers to route their own IRR-allocated IP blocks is part and parcel for business-class ISPs like Verizon Business (some of you may remember them as UUNet). It's one of the many things that differentiate business network services from consumer services. And it's absolutely necessary if your business needs to be truly multihomed with the ability to add or remove providers at will.
Good news is, Verizon is more or less standing alone in this refusal; there are plenty of other business-class internet providers that would be happy to accept and route the submitter's/48 IPv6 prefix. I hope Verizon is forced by market pressure to abandon this policy and get in line with the rest of the world in this regard, and the sooner the better.
P.S. One of those blocks Verizon won't route - specifically, 2620:0000:1B00:/48 - is Apple's IPv6 allocation, which means MobileMe or iTunes (or hell, Apple Software Update) would be impossible to deploy over IPv6 today thanks to these clowns.
More specifically, they refuse to listen to any prefixes from peers that are smaller than a/32, which directly conflicts with ARIN policy regarding the intended routability of prefixes down to/48. This breaks multihoming badly - if you want to multihome (that is, connect to more than one provider via BGP), you'd have to qualify for your own/32 from your local IRR in order for Verizon to accept the prefix.
Some may remember back in the 90s/early 2000s, several providers, most notably Sprint and Verio, had similar policies against accepting IPv4 prefixes smaller than/20, with similar results that frustrated network administrators everywhere who were allocated/24 networks for multihoming. Eventually they were forced by market pressure to abandon those policies.
But who signs the developer's certificate? And what keeps malware publishers from signing their trojans??
IIRC the intent here is that any change in the binary - for example, an automatic updater - would have to be signed by the cert that's in the original package, and as such can validate that it's a "genuine" update, as opposed to the binary being changed by a remote exploit of any sort.
By itself, a local exploit, say, a privilege escalation exploit, is only dangerous if you don't trust your local users.
The real danger of a local exploit is that it allows a remote exploit, which normally can be contained by server process permissions, chroot jails, etc. to become more dangerous - if you can get a remotely-exploitable process to run local exploit code, you can own the box no matter what privilege restrictions the server with the remote attack vector is running with.
In other words, via a local exploit, "0wning apache" becomes "0wning the box" very easily.
In order to claim (in a legalistic sense) technical compliance with the spec in order to be able to sell Office to companies/governments who have adopted policies requiring this, while at the same time making it virtually impossible for those organizations to actually USE a competing office product.
One big flaw in this system - as I understand it, MAC addresses are not globally unique as IP addresses are. It's a 48-bit address, but the first 24 are the vendor's ID, leaving only 24 bits for a unique device ID (and these do get recycled). This is good enough in the scope of a local LAN, but Skyhook's system seems to depend on these being globally unique, which isn't the case.
More than likely the latter - there are a lot of unmanned exchange rooms were it's trivial to physically tap into landlines. Not to mention a lock on the door...I'll also bet he worked the overnight shifts, where there's a ton of downtime outside of maintenance windows.
Slashdot Mirror
Class action lawsuits are *never* for the benefit of the actual aggrieved parties. They're simply cash cows for tort lawyers. Bill Lerach actually got caught *paying* people to be plaintiffs in shareholder class action suits - he went to jail for that, but how many others didn't?
The "Milk compliment" would be Fireproof, a highly conservative movie which seemed to only go over big in Atlanta and Dallas.
Note that for Atlanta, "Fireproof" was most popular among the southern exurbs, confirming every rural stereotype held by the typical ITP* Atlantan.
* ITP = Inside The Perimeter, the local nickname for the I-285 bypass.
It very well might be that heat dissipation requirements deem that laptop batteries be more efficient (read: latest-generation designs, which invariably will cost more per kWh), where lawnmower batteries can get away with models that throw off more waste heat.
Vixie didn't justify it - he acknowledged that it was a design flaw with no practical airtight fix besides DNSSEC - but he was one of the main players that coordinated the patches to get source port randomization, the best possible fix easily deployable, out there before the bug became public knowledge.
BTW have you ever met the man? I have.
I suspect anycast would be a better method, honestly.
And you'd be completely, utterly wrong. I've seen anycast resulting some mind-numblingly stupid site selection choices, usually due to a local ISP's BGP policy - and when I say "stupid" I mean "all users of ISP X in New York City getting sent to a mirror in Sydney, Australia instead of the site downtown".
This might be OK for simple DNS queries, but for actual web sites it is a True Path To Pain.
Anyone know if this vulnerability is specific to Time Warner? That's the same model cable modem I have on my Comcast service.
Allowing customers to route their own IRR-allocated IP blocks is part and parcel for business-class ISPs like Verizon Business (some of you may remember them as UUNet). It's one of the many things that differentiate business network services from consumer services. And it's absolutely necessary if your business needs to be truly multihomed with the ability to add or remove providers at will.
Good news is, Verizon is more or less standing alone in this refusal; there are plenty of other business-class internet providers that would be happy to accept and route the submitter's /48 IPv6 prefix. I hope Verizon is forced by market pressure to abandon this policy and get in line with the rest of the world in this regard, and the sooner the better.
P.S. One of those blocks Verizon won't route - specifically, 2620:0000:1B00:/48 - is Apple's IPv6 allocation, which means MobileMe or iTunes (or hell, Apple Software Update) would be impossible to deploy over IPv6 today thanks to these clowns.
More specifically, they refuse to listen to any prefixes from peers that are smaller than a /32, which directly conflicts with ARIN policy regarding the intended routability of prefixes down to /48. This breaks multihoming badly - if you want to multihome (that is, connect to more than one provider via BGP), you'd have to qualify for your own /32 from your local IRR in order for Verizon to accept the prefix.
Some may remember back in the 90s/early 2000s, several providers, most notably Sprint and Verio, had similar policies against accepting IPv4 prefixes smaller than /20, with similar results that frustrated network administrators everywhere who were allocated /24 networks for multihoming. Eventually they were forced by market pressure to abandon those policies.
So, yep, looks like history is repeating itself.
But who signs the developer's certificate? And what keeps malware publishers from signing their trojans??
IIRC the intent here is that any change in the binary - for example, an automatic updater - would have to be signed by the cert that's in the original package, and as such can validate that it's a "genuine" update, as opposed to the binary being changed by a remote exploit of any sort.
By itself, a local exploit, say, a privilege escalation exploit, is only dangerous if you don't trust your local users.
The real danger of a local exploit is that it allows a remote exploit, which normally can be contained by server process permissions, chroot jails, etc. to become more dangerous - if you can get a remotely-exploitable process to run local exploit code, you can own the box no matter what privilege restrictions the server with the remote attack vector is running with.
In other words, via a local exploit, "0wning apache" becomes "0wning the box" very easily.
One has to wonder how Steve Jobs ever let Jon Rubinstein leave."
Simple - by forcing him to report to Steve Jobs.
I hope you get a good grade.
Nine more posts and he gets an A!
The version in 10.5.8 is still 9.4.3-P1. (9.4.3-P3 is the patched rev).
More to the point: http://www.angryflower.com/robotr.html
Don't worry, I'm sure this won't happen until 2083.
Ten bucks says they also use the encryption chip to lock down the OS itself to thwart the jailbreakers...
Interesting. Makes me wonder if the tongue-eating prostitute he encountered was a CoS set up...
In order to claim (in a legalistic sense) technical compliance with the spec in order to be able to sell Office to companies/governments who have adopted policies requiring this, while at the same time making it virtually impossible for those organizations to actually USE a competing office product.
while the prank was foolish and juvenile, I don't believe it was all that harmful.
The multiple people who got fired from their jobs once the responses were made public would argue that point...
So why can wikileaks keep up leaked information that was never intended to be published, but ED is held to a different standard?
Easy: ED is hosted in the US, and as such is subject to the DMCA. Wikileaks is in Sweden.
No video recording. Less space than a iPod Classic. Lame.
One big flaw in this system - as I understand it, MAC addresses are not globally unique as IP addresses are. It's a 48-bit address, but the first 24 are the vendor's ID, leaving only 24 bits for a unique device ID (and these do get recycled). This is good enough in the scope of a local LAN, but Skyhook's system seems to depend on these being globally unique, which isn't the case.
Anyone know how they deal with this?
More than likely the latter - there are a lot of unmanned exchange rooms were it's trivial to physically tap into landlines. Not to mention a lock on the door...I'll also bet he worked the overnight shifts, where there's a ton of downtime outside of maintenance windows.
They now have the names and addresses of the posters who responsed with DMCA counter-notices, and those individuals are now free to be "fair-gamed".
Don't forget he's talking about LiveCD boot times, not boot times from hard disk...