Your role, as a qualified member of the IT staff, is to make the higher-ups aware of the risks. Do your due-diligence, tell them the data isn't secure (in person, in e-mail, and maybe even on paper), and remind them from time-to-time (using creative new analogies whenever possible). That's it, you've done your job.
The fact of the matter is, regardless what the policy is, and regardless what they all "agree" on, they're going to put sensitive information on the Web. You'd have to take away their Internet access and portable devices to prevent it, and even then, they'd just go home and use that.
Accept that the best you can do is educate them and provide alternatives.
At some point, because of the failure to protect privacy, would not "identity" become meaningless, since there will be no reliable way to confirm it?
If identity theft becomes so rampant that credit card companies and banks are losing serious money, they'll remove credit options, meaning much, much lower lines of credit and/or fewer credit cards (as vendors get out of the business).
And when does "identity theft" become a preferable alternative for people that would otherwise declare bankruptcy? "No, that wasn't me that ran up that debt, it was someone that 'stole my identity'! Now please clear my record and let me be about my business."
People are stealing legal "identities" of new-borns, before any personal identity has developed. I'm sure there are/will be cases where the (adult) victim will discover that someone else has a long-established history with his/her identity. Then what?
No patent should be granted for any computer algorithm if the same or similar idea can "discovered" by an industry-selected board of programmers and architects.
Get the IEEE or ACM to appoint 50 computer engineers. One, two, or three engineers are assigned to each (non-obvious) software patent candidate that comes in. They receive only a desciption of the problem the invention addresses, but no details of the invention itself. They have 24 hours to propose as many solutions to the problem as they can. If one is identical or "reasonably" close to the patent candidate, the patent fails.
The problem with "marking" is that it does nothing to people that are faced with a problem and attempting to implement their own solution, but haven't actually used any existing solutions. They'll never see the markings!
Seems like the card isn't even necessary. Simply scan biometric information (fingerprint, retena, voice) and feed the scan to some central server, which simply replies "citizen" or "non-citizen".
Putting the credentials on the card itself allows forgery and tampering, which means we're right back where we started. If all that information is to be stored, it should be stored somewhere else.
If a national ID system is put in place, the *ONLY* thing it should allow someone to check is citizenship. All this medical history and other crap is bad, becuase someone, somehow, will eventually break into the system and misuse the information.
Tomas Greene's article is as much FUD as anything else.
Microsoft has to get their technology onto the chip before anything else happens. Do you really think Intel and AMD are looking to get rid of the Linux market? Do you think IBM is going to let Microsoft kill the Linux market?
Second, any DRM support would be built into the kernel (probably as a module) or a library. Applications would call the kernel or library functions to perform rights verification. So, only the kernel (or kernel module, or library) would need "certification", not each application.
Third, there is and always will be a huge need for custom software for in-house applications. There's no way anyone is going to be able to require every company in the world to certify every one of their in-house applications. Therefore, there will still have to be non-certified, unprotected (or differently protected) channels.
Digital rights management will primarily affect applications that specifically request rights verification from the OS. Applications that don't request verification won't use it and won't be affected by it. Plenty of applications and network services will be happy to communicate with each other without DRM.
If anything, strict (cumbersome) DRM may actually drive more people to open source software. When people are getting nickled-and-dimed by every piece of software they use and every piece of media they review, they'll look for other options.
I find that, when debugging code I write, I tend to try to verify that the code properly handles exceptions I've anticipated. But that's the problem with my process: if I've anticipated an exception, I've already handled; if I haven't anticipated an exception, I won't think to test for it.
Ultimately, I think a lot of software problems result from the assumption on the part of the coder that users will try to use the program properly, that users won't be lazy and sloppy, and that users will RTFM. That, and many programmers just don't think things through, don't consider all the possible combinations (especially true in parser code!).
It's important to have people that aren't familiar with the expected functional specifics test the code. And when testing, you have to deliberately try to break the program.
I'm really surprised I've never seen anyone mention this, but there is nothing to preclude the owner of an open source product from releasing the code under multiple licenses.
A commercial vendor interested in using open source software in a closed-source product can always request a separate license that does not require release under the GPL.
Even Microsoft doesn't have a one-size-fits-all license for their source code. Microsoft's EULA and the GPL are the default licenses, not the only possible license.
Suggestion for the EFF and/or FSF: help open source software writers negotiate and manage non-open source licenses for closed-source, commercial software.
Slashdot Mirror
Your role, as a qualified member of the IT staff, is to make the higher-ups aware of the risks. Do your due-diligence, tell them the data isn't secure (in person, in e-mail, and maybe even on paper), and remind them from time-to-time (using creative new analogies whenever possible). That's it, you've done your job.
The fact of the matter is, regardless what the policy is, and regardless what they all "agree" on, they're going to put sensitive information on the Web. You'd have to take away their Internet access and portable devices to prevent it, and even then, they'd just go home and use that.
Accept that the best you can do is educate them and provide alternatives.
At some point, because of the failure to protect privacy, would not "identity" become meaningless, since there will be no reliable way to confirm it?
If identity theft becomes so rampant that credit card companies and banks are losing serious money, they'll remove credit options, meaning much, much lower lines of credit and/or fewer credit cards (as vendors get out of the business).
And when does "identity theft" become a preferable alternative for people that would otherwise declare bankruptcy? "No, that wasn't me that ran up that debt, it was someone that 'stole my identity'! Now please clear my record and let me be about my business."
People are stealing legal "identities" of new-borns, before any personal identity has developed. I'm sure there are/will be cases where the (adult) victim will discover that someone else has a long-established history with his/her identity. Then what?
No patent should be granted for any computer algorithm if the same or similar idea can "discovered" by an industry-selected board of programmers and architects.
Get the IEEE or ACM to appoint 50 computer engineers. One, two, or three engineers are assigned to each (non-obvious) software patent candidate that comes in. They receive only a desciption of the problem the invention addresses, but no details of the invention itself. They have 24 hours to propose as many solutions to the problem as they can. If one is identical or "reasonably" close to the patent candidate, the patent fails.
The problem with "marking" is that it does nothing to people that are faced with a problem and attempting to implement their own solution, but haven't actually used any existing solutions. They'll never see the markings!
Seems like the card isn't even necessary. Simply scan biometric information (fingerprint, retena, voice) and feed the scan to some central server, which simply replies "citizen" or "non-citizen".
Putting the credentials on the card itself allows forgery and tampering, which means we're right back where we started. If all that information is to be stored, it should be stored somewhere else.
If a national ID system is put in place, the *ONLY* thing it should allow someone to check is citizenship. All this medical history and other crap is bad, becuase someone, somehow, will eventually break into the system and misuse the information.
Tomas Greene's article is as much FUD as anything else.
Microsoft has to get their technology onto the chip before anything else happens. Do you really think Intel and AMD are looking to get rid of the Linux market? Do you think IBM is going to let Microsoft kill the Linux market?
Second, any DRM support would be built into the kernel (probably as a module) or a library. Applications would call the kernel or library functions to perform rights verification. So, only the kernel (or kernel module, or library) would need "certification", not each application.
Third, there is and always will be a huge need for custom software for in-house applications. There's no way anyone is going to be able to require every company in the world to certify every one of their in-house applications. Therefore, there will still have to be non-certified, unprotected (or differently protected) channels.
Digital rights management will primarily affect applications that specifically request rights verification from the OS. Applications that don't request verification won't use it and won't be affected by it. Plenty of applications and network services will be happy to communicate with each other without DRM.
If anything, strict (cumbersome) DRM may actually drive more people to open source software. When people are getting nickled-and-dimed by every piece of software they use and every piece of media they review, they'll look for other options.
I find that, when debugging code I write, I tend to try to verify that the code properly handles exceptions I've anticipated. But that's the problem with my process: if I've anticipated an exception, I've already handled; if I haven't anticipated an exception, I won't think to test for it.
Ultimately, I think a lot of software problems result from the assumption on the part of the coder that users will try to use the program properly, that users won't be lazy and sloppy, and that users will RTFM. That, and many programmers just don't think things through, don't consider all the possible combinations (especially true in parser code!).
It's important to have people that aren't familiar with the expected functional specifics test the code. And when testing, you have to deliberately try to break the program.
A commercial vendor interested in using open source software in a closed-source product can always request a separate license that does not require release under the GPL.
Even Microsoft doesn't have a one-size-fits-all license for their source code. Microsoft's EULA and the GPL are the default licenses, not the only possible license.
Suggestion for the EFF and/or FSF: help open source software writers negotiate and manage non-open source licenses for closed-source, commercial software.