> Of course there are easier, more rational approaches that would nearly eradicate the drug epidemic No half intelligent person would dispute that fact.
If people had self discipline, as any half-intelligent person should, addiction and drug related crime wouldn't occur. Neither would child abuse or serial murder. And yet, they do. It takes a very small number of "half-unintelligent" people to create enormous problems with addiction, with drug abuse, and with crime resulting from it. Even for reasonable people, the deceit involved in various drug trades has been extremely dangerous. Please look at the economic and social history of tobacco, of alcohol, and even of non-physical addictions like gambling to see a history of rational attempts to control them, and the failure of rational policies.
Could it be done better? I agree, many US drug policies are outrageous and ineffective. Are there rational approaches that would almost eradicate it? I must disagree: It has roots in human physiology, in human weakness, in crime, and in politics that make it extremely difficult to eradicate. Many are _not_ driven by greed. Many are founded in erroneous ideology. The idea that the war on drugs is a monolithic policy that "fits every aspect of the government's agenda" suggests that it is a thought out plan. I'm afraid it is not. Different members, and different branches, of the Us government have different goals which combine to extend current policies.
I'm afraid it's not one problem, so it can't be defeated by a single logical analysis.
> Obviously there is no real threat, there hasn't been since invention of atomic weapons.
If Io may say, this is disingenuous. There was a real threat from Afghanistan, which was hosting the Taliban. which had just murdered thousands of the most powerful and wealthy US citizens. The next logical target was Pakistan, which had since been hosting the Taliban and which has been selling nuclear technologies around the world. I'd prefer not to discuss why the US targeted Iraq next: it's a long discussion.
But in terms of the drug trade: sir, I suspect you were not alive during the Vietnam era, when US servicemen were often returning to US soil with opioid addictions. I myself only met, but was not old enough to greet on their return, Korea veterans who returned with similar addictions. The Soviets encountered it in dangerous proliferation when they occupied Afghanistan, one of the world's greatest sources for opium: I'm seeing reports of it now with US troops returning from Afghanistan today. This occurs for _any_ nation that invades Afghanistan. The proliferation of opium dens was a critical part of the Sherlock Holmes stories and Dr. John Watson's return from Afghanistan.
> It may be anonymous *now*, but remember - every transaction lives on the blockchain FOREVER.
Even if they were individually protected from tracing, becaase for example they were built on rootkitted AWS servers or various worldwide rootkitted botnets: the owners of the various exchanges have _not_ proven trustworthy. It's very difficult to have confidence in people convicted of attempting to murder their business partners, as the arrest and convictions of the leader of the Silk Road Exchange has shown. And I'm afraid that their dalliance with money laundering and "hiding things from the government" encourages them to hide theft from their customers, as the raw embezzlement from Mt. Gox has demonstrated. Mt. Gox was the largest bitcoin exchange in the world: it had over 850,000 bitcoins stolen during their lifetime, half a billion US dollars in the valuation at the time of their shutdown.
The scale of the abuse and fraud was widespread, and was apparently at every level of the exchange. I've seen no evidence that any of the other bitcoin exchanges are more trustworthy or more cautious with their client's bitcoins: the insistence on being "edgy" and "outside the establishment" seems to lead directly to abuse from inside the companies and vulnerability to outside abuse. Dealing in secretive currencies for illegal transactions, which has remained a core use of bitcoin, is a corrupting influence for the people handling the exchnages.
> Now your typical enterprise may have third party security assessment and penetration testing - which is OK, but most of the time it's testing well-known exploits.
They're typically not allowed, by the company paying them, to probe for the most dangerous vulnerabilities. Passwords sent via github, VPN's that open full access to unencrypted services from poorly secured internal networks, permanent root credentials embedded in source code,and other issues abound.
I've recently been forced to cope with a software architect who insisted on a common OpenBSD policy, that if your local system is not secure, then there was never any point to having security, so they refused to have any on their local systems. The result is that they opened tunnels between the production network and their laptop, and opened SSH tunnels to and from their laptop into their home desktop, all tunnels open 24x7. These tunnels used private keys with no encryption, stored locally on all of these systems, and available on NFS and CIFS shares, and on publicly recoverable backups throughout the network.
Recovering from that was quite painful. I was compelled not to being up the issue formally in my project reports. I _may_ have been aware of someone inside their company to whom I presented a report on this, who _may_ have taken some private, internal steps to flood the channels. That brought it to the visible and official attention of their network group when the architect complained about poor performance of these channels. Unfortunately, this architect was in the habit of doing all their work on their laptop and never submitting their work to source control.
Before completing my designated tasks, I did hand over tools to take daily snapshots of the workspace on that exposed laptop, as a "proof of concept". I also hoped they could use that backup to reconstruct some of the work if that engineer quit or was let go.
Many of the Stackoverflow first answers are very poor, as are many followups from people who don't sanitize their inprts. The problem is aggravated for Java, where error reporting is often very poor and where programmers have been taught with object oriented principles to pay no attention to the rest of the system: it's considered outside the scope of their immediate task.
I do find Stackoverflow useful: there are often extremely useful hooks to start from, and it's well worth thanking the community by following up with my more detailed or robust answers, especially when the published answers did not quite work. That kind of feedback is critical to open source and free software projects.
As some of us can point out, updating root keys _cannot_ occur on a frequent basis. Lazy ISP's or not frequent mandated updates require customer collaboration. They also require the _designers_ of DNS capable applicances to be forward thinking enough to provide effective pathways for such updates.
> We could simply sum it up with "Radicals are people that resort to violence to solve disagreements".
That definition has some difficulty with its broadness. It includes the homeowner who shot down the drone over his private property. It also includes the Allied military freeing the Holocaust victims at Dachau. It also includes divorced people who murder their former spouses.
This is a _very_ common problem for systems that re-invent versioning for their projects, especially when they ignore the very robust GNU numbering scheme. That major.minor.trivial numbering scheme 's described well at https://en.wikipedia.org/wiki/....
It's been a large problem with older tools as well, and it is why industrial operating systems do _not_ upgrade core components to major new releases. It's been devastating to projects that say "just build the code when you need it", because components in the public repositories change incompatibly with other components in the public repositories. Every new modular software suite encounters this problem.
As an older programmer, I must admit I have no _time_ for the teething pains of extremely exciting new technologies. I'm afraid their extremely high performance or exciting early progress will be lost when they actually have to support sanitizing their input, or correctly handling lexical versus dynamic scoping. The errors are commonplace, and it's very easy to write a snippet of code that tests _really well_ on your local laptop and not actually use it under load or with real data. Building out the test suite is often left out and leads to some very expensive uses of bleeding edge technologies.
> Why do these little-used programming languages like Kotlin, Scala, Go, Rust, Clojure and TypeScript get so much attention?
Perhaps because their survey approach gets responses from young, eager programmers far more than from anyone with a few years of experience, and from those who have completed successful projects. I visit Slashdot for the occasional high interest story, and the occasional opportunity to share insights and experience. But I certainly don't spend my time on market surveys or ranking of software projects.
Your analysis is very reasonable. I'd mention another opportunity of an internal inquiry: to close off avenues of inquiry by discovering what witnesses to prevent from testifying, and what evidence to eliminate before subpoenas are issued and destruction of evidence becomes a criminal matter. I've seen this happen: a company expecting a lawsuit asked for, and got, my consulting help with expunging records that were no longer legally required but which might have been of interest to a an opposing litigant. They should have been flushed previously according to the company's document retention policy, but had not been.
> The SEC is sometimes slow to act. But when it has a plainly illegal situation, it acts.
As best I can tell, the SEC has been stripped of resources with which to investigate _anything_ in the last few decades. This lack of resources, and the enforced unwillingness to investigate complex cases or those against powerful interests, has profoundly reduced their ability to prosecute even the most blatant abuses when the fiscal or political cost of the investigation would be high.
The result is that they seem to only pursue high profile cases when ordered to for political reasons. Lower profile cases, with high return-on-investment, and above a quite high threshold to justify the investment at all, seem to be the only cases pursued by its reduced staff with their limited resources and political capital.
> trying to cash out before the fan went on high speed.
I'd expect to see a great deal of "I had no knowledge of this when I sold my stocks". It can certainly happen when someone needs money for family needs or a different investment. I admit I've been frustrated when selling off options myself due to unannounced stock freezes as business deals of which I'd been unaware.
Sadly, most web browser sophistication is not for the user. It's for the advertiser. And it's consuming network, CPU, and screen space resources better devoted to the web site's actual message and the consumer's interest.
Slashdot itself is a good example of how to _avoid_ this unnecessary, undesirablem, and destabilizing complexity.
>> would dissuade people from getting proper treatment > Except that there is no "proper treatment" besides performing the operation.
Please look into the variety of people, and of treatments that work for some, for gender dysphoria. The physical rebuilding of genitalia has profound medical risks, it is very expensive, and it requires lifelong medical support. There are as many effective "treatments" as there are varieties of transgender people. Sadly, there are also many ineffective treatments: their suicide rates remain high, whether or not they proceed with transsexual lifestyle or surgical alteration.
> A client server architecture is either necessary or not, and has nothing to do with methodology.
If I may differ, _of course_ it does. The communication protocol used among them may be multi-threaded, highly redundant and secure, and robust from single points of failure or short transmisson losses. Those may be critical where the methodology, and the management approach, foster extremely robust individual stages as part of a larger, high reliability structure where every component is considered critical to success. This leads to meticulous testing, thorough API design, and using well established technologies. It also tends to involve older languages and protocols for their proven track record and greater familiarity, and the age of the developers.
Conversely, the project management may be speed oriented. Time to market may be critical, and some methodologies do _much_ better at time to release. Those often tend towards freer technologies with non-standard "glue" inserted wherever a particular developer has an immediate need.and tends to have _far_ less unit testing or defined APIs. Some technologies _foster_ such approaches, and will tend to have younger developers excited at the latest exciting languages and tools.
The list goes on, and the correlations are fascinating.
> Thats bollocks. The development methodology has nothing to do with the used technology or architecture.
May I differ? Some methodologies are much larger on standardization and common practices. Others are sensitive to security concerns, others use sophisticated continuous integration techniques. Others are prone to excitement with the latest exciting technologies or bleeding edge approaches. Others are extremely sensitive to cost, and focus intently on the specific goal with no resources for out-of-band involvement whatsoever. Others are open source or freeware friendly and willing to use third party tools and publish their changes back to that community. All have effects on the particular technologies and architecture of large projects.
As I understood them, the keys were signed by and were being sold by Microsoft, much as they escrow the private keys and sell signatures for "Trusted Computing" keys. Is this not the case for DKIM? The descriptions I'm finding in a very short search are not clear about whether the keys can be self generated and universally accepted.
If they don't require or no longer require Microsoft as as third party signatory, then _good_. I do think think that it still interfered with the much simpler "SPF" standard. But
> Coordination is required. Cutting the red tape is required. Supervision is not.
A certain amount of supervision can be critical. I recently spent long chat with a developer walking through their need for exploring some complex issues that existed only in their theories, not in practice, and having to take away the hardware resources they wanted to use for research of why it didn't fail in the real world.
I've also just been reminded by some DNS work of the Microsoft extensions of SPF and their introduction of their proprietary "DKIM" records into the standard. SPF only requires DNS control and applies to a domain: DKIM requires signed keys from Microsoft.
It's the same company, and the same management at the top levels, so I suggest it's a valid comparison for _managerial_ encouraged or permitted abuse of API's.
For Windows specific API abuse by Microsoft, I'll mention the Active Directory "extensions" violating MIT Kerberos. (Workaround patches were published very quickly, but the extensions were problematic at the time.) CIFS extensions with new Windows releases and Microsoft patches have been incompatible with the existing API and caused problems for Samba at various times, again breaking open source software implementations of Samba until they could be patched. I've also personally noticed the Active Directory export of DNS zones as text files, which are subtly incompatible with RFC 1035 and cannot be directly imported as BIND zonefiles without some text editing.
Then I suspect that you paid little attention to the "OOXML" fiasco at IEEE. An API was published to allow Microsoft to claim compliance to a published API, an API which is defined to be inconsistent with itself and which evne Microsoft does not follow. The political reason was to allow Microsoft to claim compatibility with open standards for government software contracts.
The situation was handled in political, not technological fashion, to approve a standard over the direct objections of numerous technologically astute IEEE members. The result is that Microsoft continues _not_ to follow standards in its consistently re-proprietized software with every Microsoft Office release.
Microsoft is carefully avoiding "free software" where "free" means "free as in speech". They are corking extensively with "open source" software, where they can proprietize it by adding extensions or customizatoins for Windows and refusing to publish source code or to release patents under a "free" license.
They both have rights: the extent to which these rights are recognized depends on many factors, especially treaties with their nations of origin. They may not include all the rights of the Constitution, but even in military involvement they are covered by the "Code of the US Fighting Force". There are violations of these laws, these treaties, and these laws. The prison for untried and unconvicted "illegal enemy combatants" in the US base at Guantanamo Bay is an example of such violations of civil rights and of the Geneva Convention.
Slashdot Mirror
> Of course there are easier, more rational approaches that would nearly eradicate the drug epidemic No half intelligent person would dispute that fact.
If people had self discipline, as any half-intelligent person should, addiction and drug related crime wouldn't occur. Neither would child abuse or serial murder. And yet, they do. It takes a very small number of "half-unintelligent" people to create enormous problems with addiction, with drug abuse, and with crime resulting from it. Even for reasonable people, the deceit involved in various drug trades has been extremely dangerous. Please look at the economic and social history of tobacco, of alcohol, and even of non-physical addictions like gambling to see a history of rational attempts to control them, and the failure of rational policies.
Could it be done better? I agree, many US drug policies are outrageous and ineffective. Are there rational approaches that would almost eradicate it? I must disagree: It has roots in human physiology, in human weakness, in crime, and in politics that make it extremely difficult to eradicate. Many are _not_ driven by greed. Many are founded in erroneous ideology. The idea that the war on drugs is a monolithic policy that "fits every aspect of the government's agenda" suggests that it is a thought out plan. I'm afraid it is not. Different members, and different branches, of the Us government have different goals which combine to extend current policies.
I'm afraid it's not one problem, so it can't be defeated by a single logical analysis.
> Obviously there is no real threat, there hasn't been since invention of atomic weapons.
If Io may say, this is disingenuous. There was a real threat from Afghanistan, which was hosting the Taliban. which had just murdered thousands of the most powerful and wealthy US citizens. The next logical target was Pakistan, which had since been hosting the Taliban and which has been selling nuclear technologies around the world. I'd prefer not to discuss why the US targeted Iraq next: it's a long discussion.
But in terms of the drug trade: sir, I suspect you were not alive during the Vietnam era, when US servicemen were often returning to US soil with opioid addictions. I myself only met, but was not old enough to greet on their return, Korea veterans who returned with similar addictions. The Soviets encountered it in dangerous proliferation when they occupied Afghanistan, one of the world's greatest sources for opium: I'm seeing reports of it now with US troops returning from Afghanistan today. This occurs for _any_ nation that invades Afghanistan. The proliferation of opium dens was a critical part of the Sherlock Holmes stories and Dr. John Watson's return from Afghanistan.
There is a time and a place for "steganography" Border crossings are one of those.
> It may be anonymous *now*, but remember - every transaction lives on the blockchain FOREVER.
Even if they were individually protected from tracing, becaase for example they were built on rootkitted AWS servers or various worldwide rootkitted botnets: the owners of the various exchanges have _not_ proven trustworthy. It's very difficult to have confidence in people convicted of attempting to murder their business partners, as the arrest and convictions of the leader of the Silk Road Exchange has shown. And I'm afraid that their dalliance with money laundering and "hiding things from the government" encourages them to hide theft from their customers, as the raw embezzlement from Mt. Gox has demonstrated. Mt. Gox was the largest bitcoin exchange in the world: it had over 850,000 bitcoins stolen during their lifetime, half a billion US dollars in the valuation at the time of their shutdown.
The scale of the abuse and fraud was widespread, and was apparently at every level of the exchange. I've seen no evidence that any of the other bitcoin exchanges are more trustworthy or more cautious with their client's bitcoins: the insistence on being "edgy" and "outside the establishment" seems to lead directly to abuse from inside the companies and vulnerability to outside abuse. Dealing in secretive currencies for illegal transactions, which has remained a core use of bitcoin, is a corrupting influence for the people handling the exchnages.
> Now your typical enterprise may have third party security assessment and penetration testing - which is OK, but most of the time it's testing well-known exploits.
They're typically not allowed, by the company paying them, to probe for the most dangerous vulnerabilities. Passwords sent via github, VPN's that open full access to unencrypted services from poorly secured internal networks, permanent root credentials embedded in source code,and other issues abound.
I've recently been forced to cope with a software architect who insisted on a common OpenBSD policy, that if your local system is not secure, then there was never any point to having security, so they refused to have any on their local systems. The result is that they opened tunnels between the production network and their laptop, and opened SSH tunnels to and from their laptop into their home desktop, all tunnels open 24x7. These tunnels used private keys with no encryption, stored locally on all of these systems, and available on NFS and CIFS shares, and on publicly recoverable backups throughout the network.
Recovering from that was quite painful. I was compelled not to being up the issue formally in my project reports. I _may_ have been aware of someone inside their company to whom I presented a report on this, who _may_ have taken some private, internal steps to flood the channels. That brought it to the visible and official attention of their network group when the architect complained about poor performance of these channels. Unfortunately, this architect was in the habit of doing all their work on their laptop and never submitting their work to source control.
Before completing my designated tasks, I did hand over tools to take daily snapshots of the workspace on that exposed laptop, as a "proof of concept". I also hoped they could use that backup to reconstruct some of the work if that engineer quit or was let go.
Many of the Stackoverflow first answers are very poor, as are many followups from people who don't sanitize their inprts. The problem is aggravated for Java, where error reporting is often very poor and where programmers have been taught with object oriented principles to pay no attention to the rest of the system: it's considered outside the scope of their immediate task.
I do find Stackoverflow useful: there are often extremely useful hooks to start from, and it's well worth thanking the community by following up with my more detailed or robust answers, especially when the published answers did not quite work. That kind of feedback is critical to open source and free software projects.
My point was responding to your post.
> The theory goes that you can roll over your ZSK frequently
I'm afraid this is not going to happen.
I see your point. However, I was responding to this:
> The theory goes that you can roll over your ZSK frequently (and you should) without involving your parent zone.
The idea that the ZSK chain of authentication should be frequently rolled over is simply not going to happen.
As some of us can point out, updating root keys _cannot_ occur on a frequent basis. Lazy ISP's or not frequent mandated updates require customer collaboration. They also require the _designers_ of DNS capable applicances to be forward thinking enough to provide effective pathways for such updates.
> We could simply sum it up with "Radicals are people that resort to violence to solve disagreements".
That definition has some difficulty with its broadness. It includes the homeowner who shot down the drone over his private property. It also includes the Allied military freeing the Holocaust victims at Dachau. It also includes divorced people who murder their former spouses.
This is a _very_ common problem for systems that re-invent versioning for their projects, especially when they ignore the very robust GNU numbering scheme. That major.minor.trivial numbering scheme 's described well at https://en.wikipedia.org/wiki/....
It's been a large problem with older tools as well, and it is why industrial operating systems do _not_ upgrade core components to major new releases. It's been devastating to projects that say "just build the code when you need it", because components in the public repositories change incompatibly with other components in the public repositories. Every new modular software suite encounters this problem.
As an older programmer, I must admit I have no _time_ for the teething pains of extremely exciting new technologies. I'm afraid their extremely high performance or exciting early progress will be lost when they actually have to support sanitizing their input, or correctly handling lexical versus dynamic scoping. The errors are commonplace, and it's very easy to write a snippet of code that tests _really well_ on your local laptop and not actually use it under load or with real data. Building out the test suite is often left out and leads to some very expensive uses of bleeding edge technologies.
> Why do these little-used programming languages like Kotlin, Scala, Go, Rust, Clojure and TypeScript get so much attention?
Perhaps because their survey approach gets responses from young, eager programmers far more than from anyone with a few years of experience, and from those who have completed successful projects. I visit Slashdot for the occasional high interest story, and the occasional opportunity to share insights and experience. But I certainly don't spend my time on market surveys or ranking of software projects.
Your analysis is very reasonable. I'd mention another opportunity of an internal inquiry: to close off avenues of inquiry by discovering what witnesses to prevent from testifying, and what evidence to eliminate before subpoenas are issued and destruction of evidence becomes a criminal matter. I've seen this happen: a company expecting a lawsuit asked for, and got, my consulting help with expunging records that were no longer legally required but which might have been of interest to a an opposing litigant. They should have been flushed previously according to the company's document retention policy, but had not been.
> The SEC is sometimes slow to act. But when it has a plainly illegal situation, it acts.
As best I can tell, the SEC has been stripped of resources with which to investigate _anything_ in the last few decades. This lack of resources, and the enforced unwillingness to investigate complex cases or those against powerful interests, has profoundly reduced their ability to prosecute even the most blatant abuses when the fiscal or political cost of the investigation would be high.
The result is that they seem to only pursue high profile cases when ordered to for political reasons. Lower profile cases, with high return-on-investment, and above a quite high threshold to justify the investment at all, seem to be the only cases pursued by its reduced staff with their limited resources and political capital.
> trying to cash out before the fan went on high speed.
I'd expect to see a great deal of "I had no knowledge of this when I sold my stocks". It can certainly happen when someone needs money for family needs or a different investment. I admit I've been frustrated when selling off options myself due to unannounced stock freezes as business deals of which I'd been unaware.
Sadly, most web browser sophistication is not for the user. It's for the advertiser. And it's consuming network, CPU, and screen space resources better devoted to the web site's actual message and the consumer's interest.
Slashdot itself is a good example of how to _avoid_ this unnecessary, undesirablem, and destabilizing complexity.
>> would dissuade people from getting proper treatment
> Except that there is no "proper treatment" besides performing the operation.
Please look into the variety of people, and of treatments that work for some, for gender dysphoria. The physical rebuilding of genitalia has profound medical risks, it is very expensive, and it requires lifelong medical support. There are as many effective "treatments" as there are varieties of transgender people. Sadly, there are also many ineffective treatments: their suicide rates remain high, whether or not they proceed with transsexual lifestyle or surgical alteration.
> A client server architecture is either necessary or not, and has nothing to do with methodology.
If I may differ, _of course_ it does. The communication protocol used among them may be multi-threaded, highly redundant and secure, and robust from single points of failure or short transmisson losses. Those may be critical where the methodology, and the management approach, foster extremely robust individual stages as part of a larger, high reliability structure where every component is considered critical to success. This leads to meticulous testing, thorough API design, and using well established technologies. It also tends to involve older languages and protocols for their proven track record and greater familiarity, and the age of the developers.
Conversely, the project management may be speed oriented. Time to market may be critical, and some methodologies do _much_ better at time to release. Those often tend towards freer technologies with non-standard "glue" inserted wherever a particular developer has an immediate need.and tends to have _far_ less unit testing or defined APIs. Some technologies _foster_ such approaches, and will tend to have younger developers excited at the latest exciting languages and tools.
The list goes on, and the correlations are fascinating.
> Thats bollocks. The development methodology has nothing to do with the used technology or architecture.
May I differ? Some methodologies are much larger on standardization and common practices. Others are sensitive to security concerns, others use sophisticated continuous integration techniques. Others are prone to excitement with the latest exciting technologies or bleeding edge approaches. Others are extremely sensitive to cost, and focus intently on the specific goal with no resources for out-of-band involvement whatsoever. Others are open source or freeware friendly and willing to use third party tools and publish their changes back to that community. All have effects on the particular technologies and architecture of large projects.
As I understood them, the keys were signed by and were being sold by Microsoft, much as they escrow the private keys and sell signatures for "Trusted Computing" keys. Is this not the case for DKIM? The descriptions I'm finding in a very short search are not clear about whether the keys can be self generated and universally accepted.
If they don't require or no longer require Microsoft as as third party signatory, then _good_. I do think think that it still interfered with the much simpler "SPF" standard. But
> Coordination is required. Cutting the red tape is required. Supervision is not.
A certain amount of supervision can be critical. I recently spent long chat with a developer walking through their need for exploring some complex issues that existed only in their theories, not in practice, and having to take away the hardware resources they wanted to use for research of why it didn't fail in the real world.
I've also just been reminded by some DNS work of the Microsoft extensions of SPF and their introduction of their proprietary "DKIM" records into the standard. SPF only requires DNS control and applies to a domain: DKIM requires signed keys from Microsoft.
It's the same company, and the same management at the top levels, so I suggest it's a valid comparison for _managerial_ encouraged or permitted abuse of API's.
For Windows specific API abuse by Microsoft, I'll mention the Active Directory "extensions" violating MIT Kerberos. (Workaround patches were published very quickly, but the extensions were problematic at the time.) CIFS extensions with new Windows releases and Microsoft patches have been incompatible with the existing API and caused problems for Samba at various times, again breaking open source software implementations of Samba until they could be patched. I've also personally noticed the Active Directory export of DNS zones as text files, which are subtly incompatible with RFC 1035 and cannot be directly imported as BIND zonefiles without some text editing.
Virtual operating systems with encrypted disks can be helpful, but present other security issues.
Then I suspect that you paid little attention to the "OOXML" fiasco at IEEE. An API was published to allow Microsoft to claim compliance to a published API, an API which is defined to be inconsistent with itself and which evne Microsoft does not follow. The political reason was to allow Microsoft to claim compatibility with open standards for government software contracts.
The situation was handled in political, not technological fashion, to approve a standard over the direct objections of numerous technologically astute IEEE members. The result is that Microsoft continues _not_ to follow standards in its consistently re-proprietized software with every Microsoft Office release.
Microsoft is carefully avoiding "free software" where "free" means "free as in speech". They are corking extensively with "open source" software, where they can proprietize it by adding extensions or customizatoins for Windows and refusing to publish source code or to release patents under a "free" license.
They both have rights: the extent to which these rights are recognized depends on many factors, especially treaties with their nations of origin. They may not include all the rights of the Constitution, but even in military involvement they are covered by the "Code of the US Fighting Force". There are violations of these laws, these treaties, and these laws. The prison for untried and unconvicted "illegal enemy combatants" in the US base at Guantanamo Bay is an example of such violations of civil rights and of the Geneva Convention.