the mis-use of information will most likely result in a marked tightening of privacy law.
In America? Good luck with that. Databases of personal information are considered business assets. A number of very large organizations (phone companies, cable companies, google, microsoft, etc) have these databases. If you make those illegal or heavily restrict them it will be taken as a huge hit to the value of those assets. This will be noted on the earnings statements of every one of them, and will likely cause a number of these companies to lose stock value. No politician in their right mind wants to be the one known for wiping scads of dollars off the stock market.
It'll never happen. The best we can hope for at this point is a law making the consequences for screwing up much higher.
One problem: you can't copyright facts. You can copyright specific collections of facts (eg: phone books), but you can't copyright the underlying fact itself. For example, telling people your phone number does not violate Verizon's copyright on the phone book, since you're just sharing a fact. If you scanned the entire phone book & sent it to someone, that would violate Verizon's copyright on the phone book.
So, is your personal data a copyright-able expression of an idea, or is it a set of facts? If it's a set of facts, you can't copyright it.
No, they were ordered to log the IP addresses of their users. TorrentSpy tried to argue that they didn't have the logs, and that the IPs only existed in RAM, so logging them wasn't possible. They then got caught showing that they did have user's IPs, and they could have provided them.
In short, TorrentSpy lied to a judge, and they got caught. That was remarkably stupid, and they're being punished for it.
1) It requires that all systems on your network support your chosen discovery protocol...including guests, contractors, appliances, etc. Good luck with that.
1a) The biggest OS out there (Windows) doesn't support discovery this way. This mandates DHCP for the vast majority of the desktop networks right out of the gate.
2) DNS servers aren't going to move around much anyway, so you really don't lose anything by hard-coding them in DHCP records.
3) Why would you want to add a whole layer of complexity (auto-discovery) for something that doesn't need it? It makes the troubleshooting of desktop connectivity much harder. If they're not moving around (see point 2), why rely on fragile auto-discovery systems, when you can hard-code the address & avoid a whole class of support calls?
side-note: Many organizations want the data in the DHCP server records. Losing that information makes the jobs of tracking back a particular host post-facto much harder. For example, if I get a complaint about a given IP, I can find a bunch of info about that machine from the DHCP records, including (and especially) where that host is now. That task becomes much harder with stateless autoconf.
Why would they prefer stateless autoconf to DHCPv6? You have to assume that some of these systems are going to want to use DNS...at which point they need DHCPv6.
Do you really believe that any real desktop network is going to use automatic addressing? 'cause, as someone who helps run one, I can tell you that stateless autoconf is just not happening.
The sad fact is, stateless autoconf is insufficient for network use, and will require DHCPv6 to set some critical parameters (DNS servers being the single biggest one). However, once you have DHCPv6, you don't need stateless autoconf, since you can just have DHCPv6 set the address, as well. Also, if you set addresses with DHCPv6, you can keep logs of which address you assigned to a given host, which many groups make use of (and is a bit of information that's lost with stateless autoconf).
We burn through a couple/8's every few *months*. There was a recent discussion of opening up part of the experimental section of IP space, freeing a/4 for global use. The consensus was that it would only buy us about a year./8's are going far faster than you think. Re-allocating/8's would only postpone things by a factor of a couple months, which is likely longer than it would take to actually do the shuffling.
There is no technical reason, but there are some *very* strongly-held philosophical ones. Many of the designers of IPv6 felt that NAT is bad (approaching evil), and have steadfastly resisted anything that might resemble NAT in IPv6. Whether the market will overrule them or not remains to be seen.
A few comments (as someone who's pretty familiar with both IPv6 and gov't work):
Grades: I'm almost certain that none of IPv6's security enhancements will help the Agency's grades in the slightest. They're not graded on whether they're hacked or not...they're graded on how well or how badly they're keeping up and managing security. It is entirely possible (and quite probable) that the Feds will still manage security badly, even if they're on IPv6.
Automatic configuration: no one is going to run stateless autoconf. I'm sorry to say it, but realistically, everyone on a desktop user network is going to need DHCP (DNS servers are pretty important, and I can't get them automatically assigned with stateless autoconf). Once it's decided that you have to have DHCP, there's really no point to using stateless autoconf (yes, you can use them together, but why bother?). It was a nice idea, but the desktop networks won't use it (DHCP) and the server networks won't use it (static addressing)...and I don't see any other networks crying out for it.
script kiddies (I assume you're talking about huge networks making scans take insanely long times): honestly, the hackers have mostly moved on anyway...phishing and DNS attacks are the thing these days. Worms really aren't hammering networks the way they used to 3 or 4 years ago. While it'll be nice to make network scanning take impossibly long times, the biggest loser there won't be the script kiddies: it'll be the internal auditing groups, who won't be able to find their own stuff, either.
Given all this, there really isn't that much of a gain for the Feds...in some cases (self-scanning & discovery of unauthorized systems), there's even a loss.
NASA doesn't have a choice. HSPD12 (which is causing this) is a Presidential Directive (hence the "PD" in HSPD12). All Executive Branch agencies are required to comply.
Now, whether HSPD12 itself is f'ing stupid is a whole other ball of wax.
Actually, it's very suspicious to the credit card companies.
When a card is stolen, the thief will often follow a predictable pattern: a small, relatively anonymous purchase (like gas), to confirm that the card works, followed shortly by a large transaction (like, in your case, furniture). Gas stations are the perfect place for that first transaction: if the card is cancelled, no one's at the pump to call the card company or rat them out.
When the credit card companies see transactions that fit that pattern, they'll nuke the card first & ask questions later. (After all, your maximum liability is $50, but the merchant and CC bank then have to fight out who eats the rest of the loss if the card's stolen.)
Sucks that you got caught in it, but there is a logical reason why they did it.
Almost all legislation is morality. (Taxes are about the only thing that aren't about morality.)
"Murder = bad" is moral declaration. Same with "stealing = bad." Almost all of our laws come from variants of these (hurting people = bad leads to laws on assault. Stealing = bad leads to straight theft laws, fraud laws, etc).
The problem with this legislation isn't that it's legislating morality. It's that it's legislating from a moral code that you disagree with.
According to the earlier post, removal of an app is as simple as deleting a folder, and addition is as simple as dropping a set of files into a folder. The only way to satisfy this is to have a bunch of API hooks that run when you move files around, which is truly ugly.
Also, I don't think I want applications specifying their own patch sources. Large organizations *certainly* *don't* want their applications specifying their own patch sources.
In the end, this is about control of software installation: where does it reside? For folks that just use their systems in a home, you want the end user to have that control. For people trying to manage hundreds of them at a time (which I do), you really don't want the end user to have that control - you want it centrally managed. Apple has come down squarely on the home user side, and Ubuntu is trying to walk the tightrope between the two. What's "better" depends on where you sit.
There's one problem with this: Patches. One of the truly lovely things about a package manager is that it becomes your one-stop place for patches to all applications on the system. Once you leave the package manager, and have users dumping.app files randomly onto their system, you have no good way of getting patches for those apps. This dramatically weakens the security of your system.
I can see wanting a way for little userland apps (that are unlikely to ever get patches anyway) to install in for just one user. But for big, system-wide things (like a browser, or OOo) a free-for-all/Application directory is a really bad idea.
Except that GPL V3 has so many holes, I'm not sure it even accomplishes it's stated goals.
Off the top of my head:
1) Tivoisation is totally okay in certain arenas...like products not intended for use in the home. Example: Cisco just moved the ASA firewall to Linux in version ASA version 8...since ASA's are not devices intended for use in the home, Cisco can include, and Tivo-ise, as much GPLv3 software as they like.
2) Patent deals a la Novell/MS are totally fine in the GPLv3, as long as the group you're making the deal with isn't in the business of publishing software. So, patent deals with Patent troll companies are totally fine under GPLv3. Patent deals only become a problem if the deal is between people who publish software. If you do nothing but handle patents, that clause doesn't apply to you.
From my understanding of the discussions leading up to GPLv3, these holes are intentional (due to requests from various parties), but they're still holes. v3 is not the bullet-proof fix that it's supporters seem to think. It was intentionally hobbled in some areas, which I think greatly weakens it.
Think about it: through the lawsuit against MS, Linspire has the legal right to distribute various codecs for MP3, WMF, etc. To add insult to injury, they are giving the other linuxes the ability to legally download various codecs, too...codecs which would otherwise be illegal in the US. Buy & shut Linspire, and you can again move the Linux desktop into territory where their users either break the law, or have a poor experience.
I would be *very* surprised if the banks voluntarily accepted liability for any part of this chain. They face none now...they'll need a very strong reason to take any risk. The banks like the present system because they face no liability...if the merchant didn't do the right thing, or faces a chargeback, it's all on the merchant. (and it's on the merchant for liability if they're hacked)
Personally, I think L5 is a far better place for a station than the Moon. L5 is gravitationally stable, but with a very shallow well, so getting back off of it takes far less fuel; there's no dust to tear up your machinery (the damage caused by the lunar dust was one of the big surprises of the Apollo missions); you don't have the wide temperature variations as you go into & out of shadow (nor do you have to deal with losing sunlight to your solar panels for 15 days per month); and since it's still basically open space, you don't need to build landers to bring supplies or people.
I can think of a couple, mostly around the idea of a lunar transport, which would dock with the station:
* A lunar transport ship should never need to re-enter the atmosphere. Why would you want to drag re-entry heat shields all the way out to the moon?
* A lunar transport ship would save each supply launch the cost of building (and then discarding) another system to soft-land on the moon.
* Scheduling the docking of a lunar transport with shuttle/progress rocket lifts would be very difficult. If you could, instead, stage the supplies at a station, that would make the scheduling of the lunar transport runs and the supply launches more (not completely) independent.
* If you eventually end up with more than one destination (L5? Please?), you don't have to have separate launches to supply each, just launch one set of supplies and split them up in orbit for each destination.
Slashdot Mirror
In America? Good luck with that. Databases of personal information are considered business assets. A number of very large organizations (phone companies, cable companies, google, microsoft, etc) have these databases. If you make those illegal or heavily restrict them it will be taken as a huge hit to the value of those assets. This will be noted on the earnings statements of every one of them, and will likely cause a number of these companies to lose stock value. No politician in their right mind wants to be the one known for wiping scads of dollars off the stock market.
It'll never happen. The best we can hope for at this point is a law making the consequences for screwing up much higher.
One problem: you can't copyright facts. You can copyright specific collections of facts (eg: phone books), but you can't copyright the underlying fact itself. For example, telling people your phone number does not violate Verizon's copyright on the phone book, since you're just sharing a fact. If you scanned the entire phone book & sent it to someone, that would violate Verizon's copyright on the phone book.
So, is your personal data a copyright-able expression of an idea, or is it a set of facts? If it's a set of facts, you can't copyright it.
No, they were ordered to log the IP addresses of their users. TorrentSpy tried to argue that they didn't have the logs, and that the IPs only existed in RAM, so logging them wasn't possible. They then got caught showing that they did have user's IPs, and they could have provided them.
In short, TorrentSpy lied to a judge, and they got caught. That was remarkably stupid, and they're being punished for it.
Several reasons:
1) It requires that all systems on your network support your chosen discovery protocol...including guests, contractors, appliances, etc. Good luck with that.
1a) The biggest OS out there (Windows) doesn't support discovery this way. This mandates DHCP for the vast majority of the desktop networks right out of the gate.
2) DNS servers aren't going to move around much anyway, so you really don't lose anything by hard-coding them in DHCP records.
3) Why would you want to add a whole layer of complexity (auto-discovery) for something that doesn't need it? It makes the troubleshooting of desktop connectivity much harder. If they're not moving around (see point 2), why rely on fragile auto-discovery systems, when you can hard-code the address & avoid a whole class of support calls?
side-note: Many organizations want the data in the DHCP server records. Losing that information makes the jobs of tracking back a particular host post-facto much harder. For example, if I get a complaint about a given IP, I can find a bunch of info about that machine from the DHCP records, including (and especially) where that host is now. That task becomes much harder with stateless autoconf.
Why would they prefer stateless autoconf to DHCPv6? You have to assume that some of these systems are going to want to use DNS...at which point they need DHCPv6.
Do you really believe that any real desktop network is going to use automatic addressing? 'cause, as someone who helps run one, I can tell you that stateless autoconf is just not happening.
The sad fact is, stateless autoconf is insufficient for network use, and will require DHCPv6 to set some critical parameters (DNS servers being the single biggest one). However, once you have DHCPv6, you don't need stateless autoconf, since you can just have DHCPv6 set the address, as well. Also, if you set addresses with DHCPv6, you can keep logs of which address you assigned to a given host, which many groups make use of (and is a bit of information that's lost with stateless autoconf).
We burn through a couple /8's every few *months*. There was a recent discussion of opening up part of the experimental section of IP space, freeing a /4 for global use. The consensus was that it would only buy us about a year. /8's are going far faster than you think. Re-allocating /8's would only postpone things by a factor of a couple months, which is likely longer than it would take to actually do the shuffling.
There is no technical reason, but there are some *very* strongly-held philosophical ones. Many of the designers of IPv6 felt that NAT is bad (approaching evil), and have steadfastly resisted anything that might resemble NAT in IPv6. Whether the market will overrule them or not remains to be seen.
A few comments (as someone who's pretty familiar with both IPv6 and gov't work):
Grades: I'm almost certain that none of IPv6's security enhancements will help the Agency's grades in the slightest. They're not graded on whether they're hacked or not...they're graded on how well or how badly they're keeping up and managing security. It is entirely possible (and quite probable) that the Feds will still manage security badly, even if they're on IPv6.
Automatic configuration: no one is going to run stateless autoconf. I'm sorry to say it, but realistically, everyone on a desktop user network is going to need DHCP (DNS servers are pretty important, and I can't get them automatically assigned with stateless autoconf). Once it's decided that you have to have DHCP, there's really no point to using stateless autoconf (yes, you can use them together, but why bother?). It was a nice idea, but the desktop networks won't use it (DHCP) and the server networks won't use it (static addressing)...and I don't see any other networks crying out for it.
script kiddies (I assume you're talking about huge networks making scans take insanely long times): honestly, the hackers have mostly moved on anyway...phishing and DNS attacks are the thing these days. Worms really aren't hammering networks the way they used to 3 or 4 years ago. While it'll be nice to make network scanning take impossibly long times, the biggest loser there won't be the script kiddies: it'll be the internal auditing groups, who won't be able to find their own stuff, either.
Given all this, there really isn't that much of a gain for the Feds...in some cases (self-scanning & discovery of unauthorized systems), there's even a loss.
NASA doesn't have a choice. HSPD12 (which is causing this) is a Presidential Directive (hence the "PD" in HSPD12). All Executive Branch agencies are required to comply.
Now, whether HSPD12 itself is f'ing stupid is a whole other ball of wax.
These guys seem to think it's 100km/sec.
Actually, it's very suspicious to the credit card companies.
When a card is stolen, the thief will often follow a predictable pattern: a small, relatively anonymous purchase (like gas), to confirm that the card works, followed shortly by a large transaction (like, in your case, furniture). Gas stations are the perfect place for that first transaction: if the card is cancelled, no one's at the pump to call the card company or rat them out.
When the credit card companies see transactions that fit that pattern, they'll nuke the card first & ask questions later. (After all, your maximum liability is $50, but the merchant and CC bank then have to fight out who eats the rest of the loss if the card's stolen.)
Sucks that you got caught in it, but there is a logical reason why they did it.
Almost all legislation is morality. (Taxes are about the only thing that aren't about morality.)
"Murder = bad" is moral declaration. Same with "stealing = bad." Almost all of our laws come from variants of these (hurting people = bad leads to laws on assault. Stealing = bad leads to straight theft laws, fraud laws, etc).
The problem with this legislation isn't that it's legislating morality. It's that it's legislating from a moral code that you disagree with.
Yeah, 'cause watching grown men sweat a lot and scratch themselves for *free* is so much better...
According to the earlier post, removal of an app is as simple as deleting a folder, and addition is as simple as dropping a set of files into a folder. The only way to satisfy this is to have a bunch of API hooks that run when you move files around, which is truly ugly.
Also, I don't think I want applications specifying their own patch sources. Large organizations *certainly* *don't* want their applications specifying their own patch sources.
In the end, this is about control of software installation: where does it reside? For folks that just use their systems in a home, you want the end user to have that control. For people trying to manage hundreds of them at a time (which I do), you really don't want the end user to have that control - you want it centrally managed. Apple has come down squarely on the home user side, and Ubuntu is trying to walk the tightrope between the two. What's "better" depends on where you sit.
There's one problem with this: Patches. One of the truly lovely things about a package manager is that it becomes your one-stop place for patches to all applications on the system. Once you leave the package manager, and have users dumping .app files randomly onto their system, you have no good way of getting patches for those apps. This dramatically weakens the security of your system.
/Application directory is a really bad idea.
I can see wanting a way for little userland apps (that are unlikely to ever get patches anyway) to install in for just one user. But for big, system-wide things (like a browser, or OOo) a free-for-all
Except that GPL V3 has so many holes, I'm not sure it even accomplishes it's stated goals.
Off the top of my head:
1) Tivoisation is totally okay in certain arenas...like products not intended for use in the home. Example: Cisco just moved the ASA firewall to Linux in version ASA version 8...since ASA's are not devices intended for use in the home, Cisco can include, and Tivo-ise, as much GPLv3 software as they like.
2) Patent deals a la Novell/MS are totally fine in the GPLv3, as long as the group you're making the deal with isn't in the business of publishing software. So, patent deals with Patent troll companies are totally fine under GPLv3. Patent deals only become a problem if the deal is between people who publish software. If you do nothing but handle patents, that clause doesn't apply to you.
From my understanding of the discussions leading up to GPLv3, these holes are intentional (due to requests from various parties), but they're still holes. v3 is not the bullet-proof fix that it's supporters seem to think. It was intentionally hobbled in some areas, which I think greatly weakens it.
...And some of us are apparently not terribly well-evolved to see the problem with ad-hominem attacks, either.
Think about it: through the lawsuit against MS, Linspire has the legal right to distribute various codecs for MP3, WMF, etc. To add insult to injury, they are giving the other linuxes the ability to legally download various codecs, too...codecs which would otherwise be illegal in the US. Buy & shut Linspire, and you can again move the Linux desktop into territory where their users either break the law, or have a poor experience.
My money's on Linspire as the acquisition target.
News flash: groups of people with similar interests or knowledge will develop jargon. It exists to speed communication.
I would be *very* surprised if the banks voluntarily accepted liability for any part of this chain. They face none now...they'll need a very strong reason to take any risk. The banks like the present system because they face no liability...if the merchant didn't do the right thing, or faces a chargeback, it's all on the merchant. (and it's on the merchant for liability if they're hacked)
Personally, I think L5 is a far better place for a station than the Moon. L5 is gravitationally stable, but with a very shallow well, so getting back off of it takes far less fuel; there's no dust to tear up your machinery (the damage caused by the lunar dust was one of the big surprises of the Apollo missions); you don't have the wide temperature variations as you go into & out of shadow (nor do you have to deal with losing sunlight to your solar panels for 15 days per month); and since it's still basically open space, you don't need to build landers to bring supplies or people.
I can think of a couple, mostly around the idea of a lunar transport, which would dock with the station:
* A lunar transport ship should never need to re-enter the atmosphere. Why would you want to drag re-entry heat shields all the way out to the moon?
* A lunar transport ship would save each supply launch the cost of building (and then discarding) another system to soft-land on the moon.
* Scheduling the docking of a lunar transport with shuttle/progress rocket lifts would be very difficult. If you could, instead, stage the supplies at a station, that would make the scheduling of the lunar transport runs and the supply launches more (not completely) independent.
* If you eventually end up with more than one destination (L5? Please?), you don't have to have separate launches to supply each, just launch one set of supplies and split them up in orbit for each destination.
Crow isn't very nutritious.