That's an interesting way to look at it. You could say it was stolen from who holds it, and infringing on who it refers to. It's not who it was stolen from who suffers the most. I like this concept.
Why is it such a concern that something as benign as a 10 digit number, plus information that can be found in the phone book, should be of such a concern? One reason is that armed with such a small amount of information, someone can do a tremendous amount of harm to people, and the companies those people do business with.
Someone can get a driver's license in your name, and build a bad driving record, or worse, in your name. And the state will insist it is you. The affected state will file this with your state, and your own state may cancel your driver's license because it looks like you moved to the other state. In extreme situations you could be arrested.
Someone can get a bank account in your name. Then with these checks that have your SSN and address on them, make a hundred fraudulent purchases totaling tens of thousands of dollars, on an account they probably stuck just $250 in to get it open. This will ruin your rating with banks, which is kept by a separate reporting agency not subject to the same reviews as the 3 big credit reporting agencies are.
There are many other kinds of examples, including opening credit accounts. The common problem in all of these is the assumption that by having certain information, the person with it must actually be you. Those of us familiar with security protocols already know that having the very information you give to someone else to show who you are, enables who you just gave it to to masquerade as you. Most people are honest but a slight few are dishonest. Theft of identity information has been happening for decades but it is only now becoming so widespread that politicians and lawmakers are no longer going to be able to hide their head under the carpet and pretend it doesn't exist in order to avoid the hard choices they will have to make.
And remember, this isidentity theft; it is notauthenticity theft. Identity only says who you are. We need to stop businesses and governments from assuming that identity is authenticity.
The bill does not require monitoring the traffic. It only requires whenever the ISP becomes aware of the possibility that it be reported to the police.
I suppose "becomes aware" could include any report by their customers. But what if a customer wants to report they did enounter some, and wants to remain anonymous and hence not give their customer ID. Perhaps the ISPs will take such reports anyway; afterall, they are now aware of the possibility, even though they haven't yet gotten the customer ID. How are they even going to know if it is a real customer or not? Then will they investigate this (and invoking a violation of another law prohibiting intentional access to child porn), or just report the raw possibility to the police? That could result in a huge flood of reports for the police (who would surely be exempt from the law prohibiting accessing child porn for investigation purposes) to look into. They could end up becoming massively backlogged. That would be terrible.
Ethics? In Australian ISPs? You've got to be kidding. Well, maybe in the small ones. But the likes of Comindico and others, no way. That was the first ISP I had to block totally at the border router for spam abuse (but not so much for the volume of spam, but for the attitude and cluelessness of the lead administrator there).
If re-syncing an existing file, the time should vary depending on factors like the amount of difference that exists, and the rsync blocksize in use. If that's one single massive 100 GB file, the default rsync blocksize might be a terrible choice just because rsync will end up spending a lot of time scanning for each block match. If the granularity of the database is still small (e.g. units of difference won't get matched with a larger blocksize) then rsync may not even be a very good choice.
If the file is being re-transferred in whole, rsync is a bad choice, even if the -W option is used.
Don't get me wrong... I love rsync. I use it all over the place. But it has limitations which can be stretched a good ways with careful choices. A single 100 GB file is probably a bit far. I hope they used the DB engine (I forget its name) that can store that on a RAID partition instead of in a filesystem.
If that's a location that does not permit UPS systems in racks in computer rooms, then get moving to somewhere else. They would be in the miniscule minority. I can't say such does not exist; I've seen some very dumb regulations in some places, mostly large cities like Chicago and New York. But California seems to have "distributed stupidity", so who knows what nonsense you can find there.
Sometimes regulations get misinterpreted. For example it is a common, and reasonable, regulation to prohibit lead-acid batteries like car batteries. UPS systems generally use gel-cell batteries, which are similar, but have the safety of a gel stabilized acid. But I've still encountered people that assume the two are alike. If someone says regulations prohibit something, find out what they are; which regulation and what specific section/part. Then start a talk on that.
But with a UPS, be sure you have a power loss warning system that will alert you when the mains power coming in is down, or for any reason the UPS is drawing down the batteries. I generally recommend a continuous online double conversion UPS.
Since I have no idea how much data is involved, I can't say if this is an expected performance level of rsync or not. But I have noted that over the years of using rsync, specific parameters can be adjusted depending on the given circumstances to optimize the performance of rsync. In many cases it depends on the data content format being understood. And sometimes preparing certain seed data ahead of time and optimize the transfer as well, given the way rsync works. One example was when I needed to transfer a CD ISO image of a bootable system across V.34 modem link. I already had most of the files that were on that ISO on the target system. I didn't have the tools handy to build the ISO directly on the target system, so what I did was just built a.tar file and set it up as the target file. Instead of 20 hours upload time, it went in about 25 minutes.
Careful decisions with parameters like -W and -B can do well to refine the performance. And if there is no data ready on the target at all, piping a compressed tarball across works faster than rsync.
Also, rsync can perform really bad with lots of files (millions) since it scans the file tree first, and does so on source and target without overlapping them in time (bad design there IMHO). In such cases, working with subdirectories separately can speed things up.
What browser are you using? The site lets the browser use its default background color. Most browsers let you set that yourself. For example in Netscape 4 go to "Edit" >> "Preferences" >> "Appearance" >> "Colors" and click on the box next to "Background" and choose whatever color you want.
Any idiot can make any OS insecure. Linux is more flexible, so that makes it a lot easier for any idiot to make it insecure. Linux includes source code, so any idiot can even remove the security parts and make it completely insecure. But it is a lot harder for any idiot to make Windows insecure. So that's why it has to be insecure by default. Else, Microsoft would have to supply the source code to any idiot that asked for it so they could make it insecure.
Except for the fact that it would not save the configuration change permanently when working with multiple instances. Fixing that was on my todo list somewhere. I guess it got pushed way down the stack. I'll get to that some day.
People should have a right to communicate with anyone, anywhere, provided the other party agrees to the communication, and provided the nature of the communication does not violate law. A provider that wants to call it an "internet service" must do this. Anything less is just some other kind of service.
Then there is the issue of whether their use of facilities that were in part paid for by the public, are owned by the public, or developed under monopoly grants by the public, should be used to drive other kinds of services. To that end, any facility that did grow under any form of monopoly franchise, be that telephone wire, cable wires, or even electric wires, but provide some form of equal access, even if that equal access is just at the IP layer (though frame layter access would be better).
You make a good point. This is in fact why I originally blocked "Referer". What I am looking at doing is making a hack to Squid to make the block conditional; let "Referer" pass only if it's the same hostname (or in a domain configured to allow it to pass).
If they want to put up a technical barrier, fine. Their site, their rules. In fact that is what I encourage them to do. It's the legal shit that has me offended. It's the fact that they don't bother to put up that technical barrier.
Actually, I hand edited the binary executable of Firefox to remove "Referer:" and "User-Agent:". Doing it via source would work as well. I've also done it in the Squid proxy.
If we start the campaign to depricate these headers, sure, there will still be plenty of browsers still using them for a long time. But, there will be fewer logged cases, and it will get smaller as the campaign progresses.
Look at the reasons these guys don't like deep linking. Basically they want to get you to look at their ads and special offers in the main page first, for the most part. They could easily implement technical measures to make deep linking ineffective... just redirect back to the main page. No cookie? Redirect to the main page to get one. Offsite referrer? Redirect to the main page to see the special offers. But instead of doing these things, they get lawyers into the act. It's this kind of management level stupidity that I want to fight against. What I suggested just helps hides these things from them.
We wouldn't have much of this problem if browsers didn't send the HTTP "Referer" header that gave away the URL that linked to them. So I say let's cut this header out. They don't need to be tracking where we have visited before, anyway. And besides, that header name is misspelled.
And while you're at it, cut out the HTTP "User-Agent" header. With web standards, there's no longer any need for this, either. That will stop the practice of favoring certain browsers.
Google can solve this easily enough. They hire some smart people, so this should be just the kind of thing for them to do. What they do is add semantics to the searches. With semantics, each search term has a "meaning space", and searches will list not only the exact terms, but also others that have overlapping "meaning space". The ad searches would be implemented just the same way. Then all an adword buyer needs to do is buy generic words, and pay extra for the "meaning space" option. So when someone enters a brand name for a certain kind of product, that pulls in information about that company, and their types of products, and makes the connection. Google should also provide a button or input keyword to allow people to opt out of the "meaning space" connection. But otherwise, this is the kind of "smart search" Google should be doing.
I would not call getting your email to work 100% again to be "suffering". You'll suffer more staying with MCI. Of course, if MCI was not blacklisted and blocked, you wouldn't have this incentive to leave MCI. No battle is needed. You simply hunt for a new ISP that has no history of supporting spam (suggestion: avoid telephone companies and cable companies), and sign up. Have your company lawyer write a notification to MCI that you are cancelling your contract due to their documented failure to provide full internet service. Send that to MCI along with a bill detailing your costs of making the switch (not that we would expect them to pay it... but it would serve as a notice that you have something to add on to a counter sue if they hassle you over this). Then switch your firewall and server addresses, including DNS changes. I've twice moved entire ISPs between upstream providers; it's not all that hard to do if you plan it.
As the internet is gradually dividing into 2 parts, guess which MCI will be stuck in.
I'd like to have the good ole days of the original UUNET, too. But alas, it's history. UUNET has been borged by an evil telephone company.
I take it that you are referring to 206.67.47.0/24.
So now it's time to quit using MCI/UUNET. A suitable alternative is to just quit paying them money. Or you could sue them for failure to provide 100% internet community peering acceptance. In any event, lots of us won't be crying over any "collateral damage" that affects you so long as MCI/UUNET supports the massive collateral damage of spam. It's rather obvious now that the act of staying an MCI/UUNET customer is an act of spam support, since it only encourages them to just keep on doing what they are doing now since they don't see any financial loses if you don't leave.
If it makes a difference whether I can run 200 instances of a program on a given hosted system because it is written in C, versus 40 instances in C++, then I will choose C for that reason. But in reality, the big reason I do choose C is because I am able to do things in C just as well. I have plenty of tools of my own that make C very viable. And since these tools are specific to what I need, and not generalized to the least common denominator, they work fine for me, and they don't add anywhere near as much RAM footprint as C++ does.
As far as moving up to an OO language (which C is not, although it does not preclude an OO design which I have sometimes done with C), I am already doing that... I just skipped over C++ in so doing (and skipped Java, too, I might add). Now I use Pike. Is Pike bloated? Sure it is; anything at this level certainly is. But for applications where the bloat doesn't matter, I sure don't need to go back down to a C/C++ type programming model. So in the end I have a full spectrum of capability in my language choices. I can write very sophisticated applications, or I can write screaming daemons that run circles around other stuff. And I mix the two where needed, too.
Slashdot Mirror
That's an interesting way to look at it. You could say it was stolen from who holds it, and infringing on who it refers to. It's not who it was stolen from who suffers the most. I like this concept.
Why is it such a concern that something as benign as a 10 digit number, plus information that can be found in the phone book, should be of such a concern? One reason is that armed with such a small amount of information, someone can do a tremendous amount of harm to people, and the companies those people do business with.
Someone can get a driver's license in your name, and build a bad driving record, or worse, in your name. And the state will insist it is you. The affected state will file this with your state, and your own state may cancel your driver's license because it looks like you moved to the other state. In extreme situations you could be arrested.
Someone can get a bank account in your name. Then with these checks that have your SSN and address on them, make a hundred fraudulent purchases totaling tens of thousands of dollars, on an account they probably stuck just $250 in to get it open. This will ruin your rating with banks, which is kept by a separate reporting agency not subject to the same reviews as the 3 big credit reporting agencies are.
There are many other kinds of examples, including opening credit accounts. The common problem in all of these is the assumption that by having certain information, the person with it must actually be you. Those of us familiar with security protocols already know that having the very information you give to someone else to show who you are, enables who you just gave it to to masquerade as you. Most people are honest but a slight few are dishonest. Theft of identity information has been happening for decades but it is only now becoming so widespread that politicians and lawmakers are no longer going to be able to hide their head under the carpet and pretend it doesn't exist in order to avoid the hard choices they will have to make.
And remember, this is identity theft; it is not authenticity theft. Identity only says who you are. We need to stop businesses and governments from assuming that identity is authenticity.
Learn more about Mark D. Hopkins. Also see his Findlaw profile.
Learn more about Savrick Schumann Johnson McGarr Kaminski & Shirley.
The bill does not require monitoring the traffic. It only requires whenever the ISP becomes aware of the possibility that it be reported to the police.
I suppose "becomes aware" could include any report by their customers. But what if a customer wants to report they did enounter some, and wants to remain anonymous and hence not give their customer ID. Perhaps the ISPs will take such reports anyway; afterall, they are now aware of the possibility, even though they haven't yet gotten the customer ID. How are they even going to know if it is a real customer or not? Then will they investigate this (and invoking a violation of another law prohibiting intentional access to child porn), or just report the raw possibility to the police? That could result in a huge flood of reports for the police (who would surely be exempt from the law prohibiting accessing child porn for investigation purposes) to look into. They could end up becoming massively backlogged. That would be terrible.
Ethics? In Australian ISPs? You've got to be kidding. Well, maybe in the small ones. But the likes of Comindico and others, no way. That was the first ISP I had to block totally at the border router for spam abuse (but not so much for the volume of spam, but for the attitude and cluelessness of the lead administrator there).
If re-syncing an existing file, the time should vary depending on factors like the amount of difference that exists, and the rsync blocksize in use. If that's one single massive 100 GB file, the default rsync blocksize might be a terrible choice just because rsync will end up spending a lot of time scanning for each block match. If the granularity of the database is still small (e.g. units of difference won't get matched with a larger blocksize) then rsync may not even be a very good choice.
If the file is being re-transferred in whole, rsync is a bad choice, even if the -W option is used.
Don't get me wrong ... I love rsync. I use it all over the place. But it has limitations which can be stretched a good ways with careful choices. A single 100 GB file is probably a bit far. I hope they used the DB engine (I forget its name) that can store that on a RAID partition instead of in a filesystem.
If that's a location that does not permit UPS systems in racks in computer rooms, then get moving to somewhere else. They would be in the miniscule minority. I can't say such does not exist; I've seen some very dumb regulations in some places, mostly large cities like Chicago and New York. But California seems to have "distributed stupidity", so who knows what nonsense you can find there.
Sometimes regulations get misinterpreted. For example it is a common, and reasonable, regulation to prohibit lead-acid batteries like car batteries. UPS systems generally use gel-cell batteries, which are similar, but have the safety of a gel stabilized acid. But I've still encountered people that assume the two are alike. If someone says regulations prohibit something, find out what they are; which regulation and what specific section/part. Then start a talk on that.
But with a UPS, be sure you have a power loss warning system that will alert you when the mains power coming in is down, or for any reason the UPS is drawing down the batteries. I generally recommend a continuous online double conversion UPS.
Since I have no idea how much data is involved, I can't say if this is an expected performance level of rsync or not. But I have noted that over the years of using rsync, specific parameters can be adjusted depending on the given circumstances to optimize the performance of rsync. In many cases it depends on the data content format being understood. And sometimes preparing certain seed data ahead of time and optimize the transfer as well, given the way rsync works. One example was when I needed to transfer a CD ISO image of a bootable system across V.34 modem link. I already had most of the files that were on that ISO on the target system. I didn't have the tools handy to build the ISO directly on the target system, so what I did was just built a .tar file and set it up as the target file. Instead of 20 hours upload time, it went in about 25 minutes.
Careful decisions with parameters like -W and -B can do well to refine the performance. And if there is no data ready on the target at all, piping a compressed tarball across works faster than rsync.
Also, rsync can perform really bad with lots of files (millions) since it scans the file tree first, and does so on source and target without overlapping them in time (bad design there IMHO). In such cases, working with subdirectories separately can speed things up.
What browser are you using? The site lets the browser use its default background color. Most browsers let you set that yourself. For example in Netscape 4 go to "Edit" >> "Preferences" >> "Appearance" >> "Colors" and click on the box next to "Background" and choose whatever color you want.
Daniel Tammet's web site is here and looks quite nicely done.
Any idiot can make any OS insecure. Linux is more flexible, so that makes it a lot easier for any idiot to make it insecure. Linux includes source code, so any idiot can even remove the security parts and make it completely insecure. But it is a lot harder for any idiot to make Windows insecure. So that's why it has to be insecure by default. Else, Microsoft would have to supply the source code to any idiot that asked for it so they could make it insecure.
Except for the fact that it would not save the configuration change permanently when working with multiple instances. Fixing that was on my todo list somewhere. I guess it got pushed way down the stack. I'll get to that some day.
People should have a right to communicate with anyone, anywhere, provided the other party agrees to the communication, and provided the nature of the communication does not violate law. A provider that wants to call it an "internet service" must do this. Anything less is just some other kind of service.
Then there is the issue of whether their use of facilities that were in part paid for by the public, are owned by the public, or developed under monopoly grants by the public, should be used to drive other kinds of services. To that end, any facility that did grow under any form of monopoly franchise, be that telephone wire, cable wires, or even electric wires, but provide some form of equal access, even if that equal access is just at the IP layer (though frame layter access would be better).
You make a good point. This is in fact why I originally blocked "Referer". What I am looking at doing is making a hack to Squid to make the block conditional; let "Referer" pass only if it's the same hostname (or in a domain configured to allow it to pass).
If they are going to go to the trouble of stopping deep linking, then I'd rather they give the work to a brother geek than to some slimey land shark.
If they want to put up a technical barrier, fine. Their site, their rules. In fact that is what I encourage them to do. It's the legal shit that has me offended. It's the fact that they don't bother to put up that technical barrier.
Bookmarks? That's so ... 20th century. This is now the 21st century. This is the age of ripping off content. Buy a diskdrive and download the article.
And don't get any ideas of ripping off this message to use as your signature.
Actually, I hand edited the binary executable of Firefox to remove "Referer:" and "User-Agent:". Doing it via source would work as well. I've also done it in the Squid proxy.
If we start the campaign to depricate these headers, sure, there will still be plenty of browsers still using them for a long time. But, there will be fewer logged cases, and it will get smaller as the campaign progresses.
Look at the reasons these guys don't like deep linking. Basically they want to get you to look at their ads and special offers in the main page first, for the most part. They could easily implement technical measures to make deep linking ineffective ... just redirect back to the main page. No cookie? Redirect to the main page to get one. Offsite referrer? Redirect to the main page to see the special offers. But instead of doing these things, they get lawyers into the act. It's this kind of management level stupidity that I want to fight against. What I suggested just helps hides these things from them.
We wouldn't have much of this problem if browsers didn't send the HTTP "Referer" header that gave away the URL that linked to them. So I say let's cut this header out. They don't need to be tracking where we have visited before, anyway. And besides, that header name is misspelled.
And while you're at it, cut out the HTTP "User-Agent" header. With web standards, there's no longer any need for this, either. That will stop the practice of favoring certain browsers.
How about a "nuclear winter"?
Google can solve this easily enough. They hire some smart people, so this should be just the kind of thing for them to do. What they do is add semantics to the searches. With semantics, each search term has a "meaning space", and searches will list not only the exact terms, but also others that have overlapping "meaning space". The ad searches would be implemented just the same way. Then all an adword buyer needs to do is buy generic words, and pay extra for the "meaning space" option. So when someone enters a brand name for a certain kind of product, that pulls in information about that company, and their types of products, and makes the connection. Google should also provide a button or input keyword to allow people to opt out of the "meaning space" connection. But otherwise, this is the kind of "smart search" Google should be doing.
I would not call getting your email to work 100% again to be "suffering". You'll suffer more staying with MCI. Of course, if MCI was not blacklisted and blocked, you wouldn't have this incentive to leave MCI. No battle is needed. You simply hunt for a new ISP that has no history of supporting spam (suggestion: avoid telephone companies and cable companies), and sign up. Have your company lawyer write a notification to MCI that you are cancelling your contract due to their documented failure to provide full internet service. Send that to MCI along with a bill detailing your costs of making the switch (not that we would expect them to pay it ... but it would serve as a notice that you have something to add on to a counter sue if they hassle you over this). Then switch your firewall and server addresses, including DNS changes. I've twice moved entire ISPs between upstream providers; it's not all that hard to do if you plan it.
As the internet is gradually dividing into 2 parts, guess which MCI will be stuck in.
I'd like to have the good ole days of the original UUNET, too. But alas, it's history. UUNET has been borged by an evil telephone company.
I take it that you are referring to 206.67.47.0/24.
So now it's time to quit using MCI/UUNET. A suitable alternative is to just quit paying them money. Or you could sue them for failure to provide 100% internet community peering acceptance. In any event, lots of us won't be crying over any "collateral damage" that affects you so long as MCI/UUNET supports the massive collateral damage of spam. It's rather obvious now that the act of staying an MCI/UUNET customer is an act of spam support, since it only encourages them to just keep on doing what they are doing now since they don't see any financial loses if you don't leave.
Getting rid of the spammers is easy. First, we shoot all the lawyers.
If it makes a difference whether I can run 200 instances of a program on a given hosted system because it is written in C, versus 40 instances in C++, then I will choose C for that reason. But in reality, the big reason I do choose C is because I am able to do things in C just as well. I have plenty of tools of my own that make C very viable. And since these tools are specific to what I need, and not generalized to the least common denominator, they work fine for me, and they don't add anywhere near as much RAM footprint as C++ does.
As far as moving up to an OO language (which C is not, although it does not preclude an OO design which I have sometimes done with C), I am already doing that ... I just skipped over C++ in so doing (and skipped Java, too, I might add). Now I use Pike. Is Pike bloated? Sure it is; anything at this level certainly is. But for applications where the bloat doesn't matter, I sure don't need to go back down to a C/C++ type programming model. So in the end I have a full spectrum of capability in my language choices. I can write very sophisticated applications, or I can write screaming daemons that run circles around other stuff. And I mix the two where needed, too.