Please excuse my lack of clarity: I assumed from your support of Subversion that you were actually familiar with how it works on UNIX and Linux. Their subversion clients, by default, store all passwords in clear text in repository specific text files in the user's hoome directory. I mistyped the directory name: it stores them in $HOME/.subversion/auth/. This is entirely irrelevant to the protocol used: if svn+ssh is used, HTTP, or HTTPS, as long as the access is password based, it stores them, unless such storage is turned off in $HOME/.subversion/config or if you use a recent version of Subversion and specifically answer "no" to the question it asks before storing the password.
This means that anyone with access to your backup tapes or your home directory has access to any and all Subversion passwords you've ever used and stored, even ancient ones, even ones to other sites not part of your local network. If you couple this with the use of common passwords for both user logins and Subversion access, which may be forbidden but which can be nightmarish to support, you have complete access to that person's account. If you couple that with "sudo" access, as is common for non-administrative users in development or desktop environments, you have access to root accounts. If coupled with typical NFS home directory access, you have a complete disaster just waiting for anyone with a "live CD" to come in and shred your network.
That said, the idea that a small or large shop shouldn't bother to have a security policy until they can afford auditors is both insane, and not my point. The point was that the _admins_ were either unaware of the widely publicized issue, as you apparently were, or were actively blocked by their management from instituting the basic step of switching to svn+ssh and the very modest amount of time taken to stop storing passwords in cleartext.
There is simply no excuse for that level of carelessness. Whether you "trust the people you work with", any malicious or merely curious cracker can invade, manipulate, steal from and possibly destroy your systems if the people who follow these sorts of policy are like those who refuse to put down their cell phones in traffic. They cause accidents for themselves and for anyone nearby who gets caught in the pile-up.
Your response is cogent, but let's be clear. svn+ssh is _daemon_ access, not file-system access, to a locally operated svnserve daemon. Because the SSH connection starts up the daemon, that daemon has only the permissions of the svn+ssh target user, which is why a well-configured svn+ssh setup uses a common user, with URL's such as svn+ssh://svnuser@svnhost/svnparentdir/reponame. There is no direct filesystem access involved, which is why the svn+ssh user can be a common user for multiple SSH clients.
There is no good published tool, at least mentioned anywhere at svn.tigris.org or its related sites, to manage svn+ssh keys or such repositories. It's all manually done, and thus error prone, unless you write your own tools. This detracts terribly from the usefulness of the technique. Sourceforge has used it successfully for years, but they're switching to git wherever feasible, and with good reason.
Your concern with the legal consequences of log histories is one I've never even thought of. The idea that the central log history is critical to protecting your intellectual property, and that a stolen log history is dangerous in this sense, is a fascinating one I've not seen before and which deserves thought. Mind you, I hope you're very careful of the provenance of your Subversion backups, because it's frankly quite easy to modify Subversion logs if you've actually read the Subversion book or use a recent Subversion version. Or is it that you need the centralized log history? git can certainly be used this way, with a central 'master' which all developers are expected to refer to and from which signed tags are generated. The signing of tags could, in fact, be useful in such circumstances: Subversion has _no_ inherent way to verify the contents of a repository or tag as being the release version.
> You can say exactly the same about any form of password caching. You don't use Firefox because it can store your passwords?
No, I can't say exactly the same thing. Subversion, by default on UNIX and Linux, stores the passwords in cleartext. That is one of the stupidest things I've ever seen for allegedly "enterprise" class software. The only other source control I've seen do something that stupid is CVS, which is what Subversion is descended from.
"Configure in your dev environement" means that your dev environment has the configurations checked out, as a Subversion environment, not an export. This means that your dev environment has precisely the problems I mentioned, and your production environment cannot make _any_ recorded changes, not even local configuration changes, without routing them through the development environment. This is, in practice, insane, because it inserts a full testing and commit cycle to what should be a very modest in-place repair or a modification that belongs only in the production branches, not the development branches or environment.
Yes, I've had to deal with this. It is fundamentally an error to rely on pure 'svn export' for configuration management.
One powerful reason for the low Linux download rate is because the packaging for the NVidia Linux drivers is terrible. It doesn't upgrade properly, it replaces system provided OpenGL libraries with little warning, and it has lacked (the last time I looked) a way to detect if there is a more recent driver available. Instead, people install the freshrpms or atrpms or other repositories that report dependencies and available updates more reliably for RedHat based software,
I shouldn't have to compile a kernel module in order to install a software package: it should be published, or at least publishable, along with the updated kernel itself. But NVidia refuses to use licensing that would permit this, so they're going to continue to have people not only using alternative installation sources, but becoming quite angry when they update their kernels and their graphics drivers from NVidia stop working until they can be recompiled and a new kernel module built.
It's not that "hard". It's time-consuming. Building RPM's or.deb's to deploy a single configuration file change is time-consuming: the same time spent to build and configure and manage the arcaneries of dependencies for RPM's or deb's would often be better spent on a single management system. Setting up hostnames and enabling particular authentication configurations or X configuraitons or printer setups, for example, seems a bit misplaced in an actual software package.
I agree that package management is very, very useful for components over a certain size, or for which package management is already woven into the OS.
You're correct. svn+ssh doesn't store passwords. But it's the least supported, least documented, and most difficult way to set up Subversion. And I can understand the problem of revision history being stolen with git, but compared to the chronic risks of repository access and associated account access of most Subversion setups, I'd say it's a much smaller problem. In fact, revision history is a _useful_ component to have without having to contact the central repository every time you want to check logs or do a diff.
The back end structure you've described is very interesting. But it's not inherent to Subversion: that sophisticated of a backend can be integrated to almost any source management technology. It's an entire, enterprise class backend technology, that requires its own maintenance. You've already paid the price for that, in manpower and development time.
Oh, dear. "We trust the people we work with" to prevent people reading the unencrypted passwords in $HOME/.svn/auth/. Yes that trick works really well for root owned system configuration files. No one would _ever_ steal those or modify them behind your back, even when they put their write-authorized passwords in their NFS shared home directories, even when those passwords are also used for email and sudo, and even when those passwords can be used to alter root-owned system configuration files. This certainly wouldn't have occurred at _every single site_ I've ever seen Subversion used for configuration management at.
I'm up to 5 in a row now. Every single one has been shocked when I plugged in a Knoppix laptop and walked through the NFS home directories of their technical and development personnel to gather root access this way. Subversion is _bad_ this way.
And local system changes are particularly to record and provide logged changes for in development environments, where the changes need to be coordinated as a set to enable or disable particular features. That's what development environments are for; burdening the central repository with those changes, pre-release, is a tremendous source of instability.
"Auth token caching" is enabled by default, with no server or system to disable it. It's only disabled on a client by client basis: this is completely unacceptable in security terms and always has been. So unless you have direct control of the source code for Subversion for all the systems, then no, you can't "easily disable it".
'svn export' is fairly insane for most configuration environments, since it provides little single hint of what files have been altered or modified locally against the base repository's version, provides no access to the log history, does not report 'svn:ignore' properly to ignore or report differences as needed, and it does not provide any later hint of where the configuration files came from. One can _write_ a complex set of configurations and tools to try and provide that, but once you do this, you've once again gotten into more scripting than the original poster wants to deal with.
Don't blame subversion's poor excuse for a security model nor its mishandling of multiple simultaneous branches on my "lack of understanding". I understand it thoroughly, and these are unnecessary flaws when git is around.
What do you mean, git doesn't integrate with Apache? It works well as an Apache client, there's 'viewgit' if you need a bare web GUI. And for this purpose, locally recordable changes seems critical.
Now hire me 3 engineers to preserve and bundle all this arcane packaging, and to do the package management itself. If you've created something smart enough to compare and manage all the packages, you've simply transferred the scripting to the package management, with a net cost in engineering of all the time building all those packages.
There are several several tools I favor:
1: Checklists (to keep track of features needed or enabled for each machine) 2: Actual package management: installing Apache or Perl modules needs to be of a specific version with a well-defined release and configuration files, not just "install the one from CPAN" or "update it from the Subversion repository". 2: git, not Subversion, to store local configuration files. Changes can be recorded locally, then submitted centrally, which Subversion and CVS have never worked well to do.
Do _not_ use Subversion for this. Use git, even if you have to use gitsvn to point it to an upstream Subversion repository. Subversion's security models in UNIX and Linux are exceptionally poor, and typically wind up storing passwords in clear-text without properly notifying you. (Now it notifies you before storing it, but usex it automatically.) Subversion also has very poor handling of multiple upstream repositories, and there is no way to store local changes locally, for testing or branching purposes, and only submit them to the central repository when your changes are complete.
git is faster, lighterweight, and performs far better for distributed systems each of which may require local configurations.
It also means more likelihood of _detecting_ the photons with which to record and generate your data. The trade-off is not so obvious as you portray it, or actual film cameras with coarse grained film would produce superior pictures.
One underlying issue is the stability of the camera: without a large body, and without the intensity of a flash, the pixels need a longer temporal sample to record a reliable signal, one that won't be "smoothed out" by such averaging algorithms. Unfortunately, cameras tremble, with the trembling of ordinary muscles, with your pulse, with the swaying of our body that you do to stay upright. a finer resolution can make the wiggling more apparent. This is why tripods can be so helpful, and heavier cameras easier to keep focused than light ones.
The referendum is a basic tool of democracy in the US. There needs to be _some_ way to overrule bureaucrats or politicians who ignore the desires of their constituents, lest they simply vote themselves too much power. But it's uncommon: most people have too much to do to be bothered to edit the laws already passed. It usually requires a peition, signed by quite a large number of registered voters, to get a referendum on the voting ballots. And many bureaucracies and governments are extremely effective at delaying or quashing such referendums when it suits them: the referendums don't occur in a vacuum.
The people on this list are already denied enough rights. The odds of anyone on this list actually being on a trial jury, for example, are about zero because we're too educated.
And there's coordination with support providers: call centers need to retrain staff and write new support "scripts" for their personnel. And the manufacturers of other software, such as Microsoft Office need time to get the secret internal documentation of available libraries and toolkits so they can weave it into their releases. And third party hardware and software providers need a chance to test and integrate their components with Microsoft's release, or they may repeat what happened with Vista and ignore the release.
This was some years ago: what enforced this in my memory was the stunned reaction of more politically aware people to Brian's claim that we can trust Microsoft because if they screw up, the engineers will resign, not the details of the particular.NET security change that caused Brian to resign. The details of the added vulnerability, and it was an _added_ change, was one I simply don't remember enough about.NET to remember.
Well, Brian discussed it at a conference, explaining that we could have some confidence in the closed source of his new Palladium project (later renamed Trusted Computing) because if it were mishandled, engineers like him would resign, just as he had resigned from.NET due to mandated changes that would break its security. It took several of us quite some time to stop laughing at the naivety of this claim, because _of course_ Microsoft would abuse such a new security model and would not care much about disillusioning him, again.
So for me, it was Brian saying it to the conference. I'll see if I can find a direct reference to it.
Outsource the job to Pakistan: they've been selling off so much nuclear and missile technology for hte last 20 years, they may as well just deliver the complete package.
Oh, I think not. The "functionality" added is Windows specific. Websites _should not_ be OS specific. And Microsoft had _no business_ shoving their plug-in silently into Firefox. And most of all..NET is now a security nightmare: Brian LaMacchia, one of the authors of ".NET Framework Security", resigned from.NET development rather than continue with it. (LaMacchia's career is fascinating: if you'd like to follow a trail of an expert engineer getting involved in projects that are doomed for mishandling security, perhaps in spite of his best efforts, check out his career.)
No, it's not as bad as Microsoft Palladium, later renamed "Trusted Computing". Not only was every box supposed to be hardware identified by the CPU, but the keys and the central key-signing keys would be held by Microsoft, with no clear legal procedure for their release to the government or even the janitor, and with direct control over the features of your software and hardware. It was designed primarily for DRM, and could be used to block the BIOS from being able to load other operating systems.
He does understand: he understands that his job is to control intrusions and abuse, and anonymity makes it that much harder. Like many other security minded people, he has overruled the protection of social anonymity and free speech.
It's an extremely bad choice, because social anonymity is vital to the ability to depose dangerous people who have already attained power. But it's understandable.
This seems nonsensical when the annual corporate meetings are held with all employees, who may own stock or stock options. Even if you tell those employees "there is a trading freeze on, due to these business changes", this is why those VP's and more stock-playing employees have divested their shares to family members or business colleagues, with whom they regularly and quietly share insider information.
I think you're right about the point of the laws, I just find that they're often a sad joke in practice. There's nothing like being the trusted engineer called to recover the email from some pending purchaser, about whom you're supposed to know nothing but the boss is _really upset_ that they haven't gotten the email, and you're forced to read the email to verify that you found the right one, to realize just how much chicanery is going on.
It made it clear that the president was defrauding clients and our own investors: and I got out, ASAP, with other abuses logged with the staff I worked with to give me cover. I thought about reporting it, but after attorney consultation, found that I didn't have enough to force a prosecution and could profoundly damage my career by becoming an _unsuccessful_ whistleblower.
Whatever makes you think the FBI did any significant part of this investigation? Even when the FBI arrests someone, the case is often assembled by the victims, especially of fiscal fraud.
I'm afraid that insider trading is deeply, deeply frowned on by most companies, who put strong clauses in their confidentiality agreements, and at some larger companies provide "training" about how not to do it. I've attended such training several times, as part of corporate mergers, and it's striking how thee announced policy does not apply to VP's in practice: does not apply to "corporate partners": and does not apply to the people who have the most to trade with and the most to gain. It _does_ apply to the peons, the people with stock options who might want to trade them in at the right moment but whose activity might pre-announce and thus reduce the profitability of the corporate changes which are the direct knowledge of those most with the most to gain from insider trading.
Yes, I've become extremely cynical about this: I know VP's who really try to help their companies and improve their products, but I've been running into far too many since the Dotcom boom who simply studied how to make their bundle and get out with the last glowing quarter on their resume, and get out before the SEC or the market stomps their grandiose "big vision" plans into the dust.
Slashdot Mirror
Please excuse my lack of clarity: I assumed from your support of Subversion that you were actually familiar with how it works on UNIX and Linux. Their subversion clients, by default, store all passwords in clear text in repository specific text files in the user's hoome directory. I mistyped the directory name: it stores them in $HOME/.subversion/auth/. This is entirely irrelevant to the protocol used: if svn+ssh is used, HTTP, or HTTPS, as long as the access is password based, it stores them, unless such storage is turned off in $HOME/.subversion/config or if you use a recent version of Subversion and specifically answer "no" to the question it asks before storing the password.
This means that anyone with access to your backup tapes or your home directory has access to any and all Subversion passwords you've ever used and stored, even ancient ones, even ones to other sites not part of your local network. If you couple this with the use of common passwords for both user logins and Subversion access, which may be forbidden but which can be nightmarish to support, you have complete access to that person's account. If you couple that with "sudo" access, as is common for non-administrative users in development or desktop environments, you have access to root accounts. If coupled with typical NFS home directory access, you have a complete disaster just waiting for anyone with a "live CD" to come in and shred your network.
That said, the idea that a small or large shop shouldn't bother to have a security policy until they can afford auditors is both insane, and not my point. The point was that the _admins_ were either unaware of the widely publicized issue, as you apparently were, or were actively blocked by their management from instituting the basic step of switching to svn+ssh and the very modest amount of time taken to stop storing passwords in cleartext.
There is simply no excuse for that level of carelessness. Whether you "trust the people you work with", any malicious or merely curious cracker can invade, manipulate, steal from and possibly destroy your systems if the people who follow these sorts of policy are like those who refuse to put down their cell phones in traffic. They cause accidents for themselves and for anyone nearby who gets caught in the pile-up.
Your response is cogent, but let's be clear. svn+ssh is _daemon_ access, not file-system access, to a locally operated svnserve daemon. Because the SSH connection starts up the daemon, that daemon has only the permissions of the svn+ssh target user, which is why a well-configured svn+ssh setup uses a common user, with URL's such as svn+ssh://svnuser@svnhost/svnparentdir/reponame. There is no direct filesystem access involved, which is why the svn+ssh user can be a common user for multiple SSH clients.
There is no good published tool, at least mentioned anywhere at svn.tigris.org or its related sites, to manage svn+ssh keys or such repositories. It's all manually done, and thus error prone, unless you write your own tools. This detracts terribly from the usefulness of the technique. Sourceforge has used it successfully for years, but they're switching to git wherever feasible, and with good reason.
Your concern with the legal consequences of log histories is one I've never even thought of. The idea that the central log history is critical to protecting your intellectual property, and that a stolen log history is dangerous in this sense, is a fascinating one I've not seen before and which deserves thought. Mind you, I hope you're very careful of the provenance of your Subversion backups, because it's frankly quite easy to modify Subversion logs if you've actually read the Subversion book or use a recent Subversion version. Or is it that you need the centralized log history? git can certainly be used this way, with a central 'master' which all developers are expected to refer to and from which signed tags are generated. The signing of tags could, in fact, be useful in such circumstances: Subversion has _no_ inherent way to verify the contents of a repository or tag as being the release version.
You wrote:
> You can say exactly the same about any form of password caching. You don't use Firefox because it can store your passwords?
No, I can't say exactly the same thing. Subversion, by default on UNIX and Linux, stores the passwords in cleartext. That is one of the stupidest things I've ever seen for allegedly "enterprise" class software. The only other source control I've seen do something that stupid is CVS, which is what Subversion is descended from.
"Configure in your dev environement" means that your dev environment has the configurations checked out, as a Subversion environment, not an export. This means that your dev environment has precisely the problems I mentioned, and your production environment cannot make _any_ recorded changes, not even local configuration changes, without routing them through the development environment. This is, in practice, insane, because it inserts a full testing and commit cycle to what should be a very modest in-place repair or a modification that belongs only in the production branches, not the development branches or environment.
Yes, I've had to deal with this. It is fundamentally an error to rely on pure 'svn export' for configuration management.
They're replacing the OpenGL libraries with their own proprietary binaries. Those are roughly 20 Megabytes: the kernel module is tiny.
One powerful reason for the low Linux download rate is because the packaging for the NVidia Linux drivers is terrible. It doesn't upgrade properly, it replaces system provided OpenGL libraries with little warning, and it has lacked (the last time I looked) a way to detect if there is a more recent driver available. Instead, people install the freshrpms or atrpms or other repositories that report dependencies and available updates more reliably for RedHat based software,
I shouldn't have to compile a kernel module in order to install a software package: it should be published, or at least publishable, along with the updated kernel itself. But NVidia refuses to use licensing that would permit this, so they're going to continue to have people not only using alternative installation sources, but becoming quite angry when they update their kernels and their graphics drivers from NVidia stop working until they can be recompiled and a new kernel module built.
It's not that "hard". It's time-consuming. Building RPM's or .deb's to deploy a single configuration file change is time-consuming: the same time spent to build and configure and manage the arcaneries of dependencies for RPM's or deb's would often be better spent on a single management system. Setting up hostnames and enabling particular authentication configurations or X configuraitons or printer setups, for example, seems a bit misplaced in an actual software package.
I agree that package management is very, very useful for components over a certain size, or for which package management is already woven into the OS.
You're correct. svn+ssh doesn't store passwords. But it's the least supported, least documented, and most difficult way to set up Subversion. And I can understand the problem of revision history being stolen with git, but compared to the chronic risks of repository access and associated account access of most Subversion setups, I'd say it's a much smaller problem. In fact, revision history is a _useful_ component to have without having to contact the central repository every time you want to check logs or do a diff.
The back end structure you've described is very interesting. But it's not inherent to Subversion: that sophisticated of a backend can be integrated to almost any source management technology. It's an entire, enterprise class backend technology, that requires its own maintenance. You've already paid the price for that, in manpower and development time.
Oh, dear. "We trust the people we work with" to prevent people reading the unencrypted passwords in $HOME/.svn/auth/. Yes that trick works really well for root owned system configuration files. No one would _ever_ steal those or modify them behind your back, even when they put their write-authorized passwords in their NFS shared home directories, even when those passwords are also used for email and sudo, and even when those passwords can be used to alter root-owned system configuration files. This certainly wouldn't have occurred at _every single site_ I've ever seen Subversion used for configuration management at.
I'm up to 5 in a row now. Every single one has been shocked when I plugged in a Knoppix laptop and walked through the NFS home directories of their technical and development personnel to gather root access this way. Subversion is _bad_ this way.
And local system changes are particularly to record and provide logged changes for in development environments, where the changes need to be coordinated as a set to enable or disable particular features. That's what development environments are for; burdening the central repository with those changes, pre-release, is a tremendous source of instability.
"Auth token caching" is enabled by default, with no server or system to disable it. It's only disabled on a client by client basis: this is completely unacceptable in security terms and always has been. So unless you have direct control of the source code for Subversion for all the systems, then no, you can't "easily disable it".
'svn export' is fairly insane for most configuration environments, since it provides little single hint of what files have been altered or modified locally against the base repository's version, provides no access to the log history, does not report 'svn:ignore' properly to ignore or report differences as needed, and it does not provide any later hint of where the configuration files came from. One can _write_ a complex set of configurations and tools to try and provide that, but once you do this, you've once again gotten into more scripting than the original poster wants to deal with.
Don't blame subversion's poor excuse for a security model nor its mishandling of multiple simultaneous branches on my "lack of understanding". I understand it thoroughly, and these are unnecessary flaws when git is around.
What do you mean, git doesn't integrate with Apache? It works well as an Apache client, there's 'viewgit' if you need a bare web GUI. And for this purpose, locally recordable changes seems critical.
Now hire me 3 engineers to preserve and bundle all this arcane packaging, and to do the package management itself. If you've created something smart enough to compare and manage all the packages, you've simply transferred the scripting to the package management, with a net cost in engineering of all the time building all those packages.
There are several several tools I favor:
1: Checklists (to keep track of features needed or enabled for each machine)
2: Actual package management: installing Apache or Perl modules needs to be of a specific version with a well-defined release and configuration files, not just "install the one from CPAN" or "update it from the Subversion repository".
2: git, not Subversion, to store local configuration files. Changes can be recorded locally, then submitted centrally, which Subversion and CVS have never worked well to do.
Do _not_ use Subversion for this. Use git, even if you have to use gitsvn to point it to an upstream Subversion repository. Subversion's security models in UNIX and Linux are exceptionally poor, and typically wind up storing passwords in clear-text without properly notifying you. (Now it notifies you before storing it, but usex it automatically.) Subversion also has very poor handling of multiple upstream repositories, and there is no way to store local changes locally, for testing or branching purposes, and only submit them to the central repository when your changes are complete.
git is faster, lighterweight, and performs far better for distributed systems each of which may require local configurations.
It also means more likelihood of _detecting_ the photons with which to record and generate your data. The trade-off is not so obvious as you portray it, or actual film cameras with coarse grained film would produce superior pictures.
One underlying issue is the stability of the camera: without a large body, and without the intensity of a flash, the pixels need a longer temporal sample to record a reliable signal, one that won't be "smoothed out" by such averaging algorithms. Unfortunately, cameras tremble, with the trembling of ordinary muscles, with your pulse, with the swaying of our body that you do to stay upright. a finer resolution can make the wiggling more apparent. This is why tripods can be so helpful, and heavier cameras easier to keep focused than light ones.
The referendum is a basic tool of democracy in the US. There needs to be _some_ way to overrule bureaucrats or politicians who ignore the desires of their constituents, lest they simply vote themselves too much power. But it's uncommon: most people have too much to do to be bothered to edit the laws already passed. It usually requires a peition, signed by quite a large number of registered voters, to get a referendum on the voting ballots. And many bureaucracies and governments are extremely effective at delaying or quashing such referendums when it suits them: the referendums don't occur in a vacuum.
The people on this list are already denied enough rights. The odds of anyone on this list actually being on a trial jury, for example, are about zero because we're too educated.
And there's coordination with support providers: call centers need to retrain staff and write new support "scripts" for their personnel. And the manufacturers of other software, such as Microsoft Office need time to get the secret internal documentation of available libraries and toolkits so they can weave it into their releases. And third party hardware and software providers need a chance to test and integrate their components with Microsoft's release, or they may repeat what happened with Vista and ignore the release.
This was some years ago: what enforced this in my memory was the stunned reaction of more politically aware people to Brian's claim that we can trust Microsoft because if they screw up, the engineers will resign, not the details of the particular .NET security change that caused Brian to resign. The details of the added vulnerability, and it was an _added_ change, was one I simply don't remember enough about .NET to remember.
Well, Brian discussed it at a conference, explaining that we could have some confidence in the closed source of his new Palladium project (later renamed Trusted Computing) because if it were mishandled, engineers like him would resign, just as he had resigned from .NET due to mandated changes that would break its security. It took several of us quite some time to stop laughing at the naivety of this claim, because _of course_ Microsoft would abuse such a new security model and would not care much about disillusioning him, again.
So for me, it was Brian saying it to the conference. I'll see if I can find a direct reference to it.
Outsource the job to Pakistan: they've been selling off so much nuclear and missile technology for hte last 20 years, they may as well just deliver the complete package.
Oh, I think not. The "functionality" added is Windows specific. Websites _should not_ be OS specific. And Microsoft had _no business_ shoving their plug-in silently into Firefox. And most of all. .NET is now a security nightmare: Brian LaMacchia, one of the authors of ".NET Framework Security", resigned from .NET development rather than continue with it. (LaMacchia's career is fascinating: if you'd like to follow a trail of an expert engineer getting involved in projects that are doomed for mishandling security, perhaps in spite of his best efforts, check out his career.)
No, it's not as bad as Microsoft Palladium, later renamed "Trusted Computing". Not only was every box supposed to be hardware identified by the CPU, but the keys and the central key-signing keys would be held by Microsoft, with no clear legal procedure for their release to the government or even the janitor, and with direct control over the features of your software and hardware. It was designed primarily for DRM, and could be used to block the BIOS from being able to load other operating systems.
The list of built-in, abusible aspects of this is stunning. Check out http://epic.org/privacy/consumer/microsoft/palladium.html for details.
He does understand: he understands that his job is to control intrusions and abuse, and anonymity makes it that much harder. Like many other security minded people, he has overruled the protection of social anonymity and free speech.
It's an extremely bad choice, because social anonymity is vital to the ability to depose dangerous people who have already attained power. But it's understandable.
This seems nonsensical when the annual corporate meetings are held with all employees, who may own stock or stock options. Even if you tell those employees "there is a trading freeze on, due to these business changes", this is why those VP's and more stock-playing employees have divested their shares to family members or business colleagues, with whom they regularly and quietly share insider information.
I think you're right about the point of the laws, I just find that they're often a sad joke in practice. There's nothing like being the trusted engineer called to recover the email from some pending purchaser, about whom you're supposed to know nothing but the boss is _really upset_ that they haven't gotten the email, and you're forced to read the email to verify that you found the right one, to realize just how much chicanery is going on.
It made it clear that the president was defrauding clients and our own investors: and I got out, ASAP, with other abuses logged with the staff I worked with to give me cover. I thought about reporting it, but after attorney consultation, found that I didn't have enough to force a prosecution and could profoundly damage my career by becoming an _unsuccessful_ whistleblower.
Whatever makes you think the FBI did any significant part of this investigation? Even when the FBI arrests someone, the case is often assembled by the victims, especially of fiscal fraud.
I'm afraid that insider trading is deeply, deeply frowned on by most companies, who put strong clauses in their confidentiality agreements, and at some larger companies provide "training" about how not to do it. I've attended such training several times, as part of corporate mergers, and it's striking how thee announced policy does not apply to VP's in practice: does not apply to "corporate partners": and does not apply to the people who have the most to trade with and the most to gain. It _does_ apply to the peons, the people with stock options who might want to trade them in at the right moment but whose activity might pre-announce and thus reduce the profitability of the corporate changes which are the direct knowledge of those most with the most to gain from insider trading.
Yes, I've become extremely cynical about this: I know VP's who really try to help their companies and improve their products, but I've been running into far too many since the Dotcom boom who simply studied how to make their bundle and get out with the last glowing quarter on their resume, and get out before the SEC or the market stomps their grandiose "big vision" plans into the dust.
Because it's in my suitcase and I'm taking my mom to a movie after work?