... especially with the backing and quiet involvement of a couple of heads of police departments...
You gotta be kidding, right?
Police are the last people on earth who want users of personal computers to be able to detect intrusions. They are, specialy the newfangled "Father... err... Homeland Security" types, one the groups most eager to use trojans, keyloggers and the like in their pursuit of "criminals".
it should be fairly obvious which definition that a linux-based, free-software-backed distribution will go for, especially with the backing and quiet involvement of a couple of heads of police departments, and several professors from royal holloway.
Except of course that it is a red herring. The first definition is the only one on which all of the proposed mass-produced commercial TPM designs are based. Most of these designs also include select, castrated elements of the second definition, as a bone to throw the gullible public in exchange for corporations taking over control of the property their customers supposedly "own".
A Trusted Computing design which would fit into the second but not first category involves an ability of the owner of the system to extract/alter the master TPM keys in a secure manner (requiring local, physical access for example).
This is NOT going to happen!
Let me repeat: NO presently proposed TC design involves the owner of the computer having access to master TPM keys. NONE!
So please stop helping these assholes do their dirty work by being so naive.
You say this now, but I predict they'd be leaked sooner rather than later, and/or tpm modules reverse-engineered (tamper resistant is not tamper proof) and any embedded backdoors found, to reenable end-user control of the systems.
Sure, it will happen but it will (unless the TPM makers are total dolts) involve electron microscopes or some other wacky hardware which very, very few people have. We are talking about a hardware hack with a high level of difficulty, which could crimp our style for some while at least.
And pretty soon, practical quantum computation will come on-stream and render the basis crypto for TPM moot.
Only to be outpaced by some new mathematical formulae for even more convoluted and computationaly intensive encryption schemes. Quantum computing is fast, but it is not infinitely fast. All one has to do is come up with something which is convoluted enough to make even fastest theoretically possible quantum computer (which is a finite physical object) crunch numbers for a few millenia.
In the EU this would be illegal use of monopoly by MS (who would have to be involved). Also, many EU countries use Linux in significant amounts on the desktop, so there is no doubt it would be pursued. Given that the banks etc. would have to wait a long time to ensure that nearly all windows PCs had the hardware and software levels to support it, the EU would have plenty of time to act even if it was really slow.
I am not saying that they will succeed. I am telling you what the plan, and the purpose (as designed) of the whole Trusted Computing concept is.
The only thing which is certain that the Media Pigopolits, Microsoft and many other large corps will try hard to do this.
Many large banks and online retailers will get on the bandwagon as they positively despise the fact that they have to actually do work and support many different browsers on different platforms. Their dream is to make us use one, homogenous platform where we cannot control anything of importance and thus it is possible for them to deploy a cookie-cutter, one-size-fits-all, Lego-blocks style IIS/IE/TrustedActiveX "solution" everywhere without having to worry about compliance with any non-Microsoft standards or applications.
These sorts of propaganda pieces have only one purpose: to sneak one past us.
Trusted Computing (as presently defined by the corporate founders of the TC Consortium) has two major purposes which are deadly to all things "open":
To make sure that the computer can be trusted by a "contents owner" thus precluding the owner of the computer itself from being able to trust it
To allow for so-called "remote atestation" which has the effect of 3rd parties (banks and the like) to be able to trust the computer, again to the exclusion of its owner. The additional effect of this is that banks and other online entities will be able to ensure that only Windows systems, with "approved" apps are used. No spoofing of user-agent tags anymore, end of Linux use in most of the commercial Internet.
In short, this article aims to lure the unwary into gullible acceptance of TC with an illusion of completely deceitfully presented and impractical (no one except the mega-corps will ever get the access to the main TPM keys) applications.
Please keep in mind: I'm not arguing with the inferred strategy, but rather it's effectiveness.
Neither am I proposing that Air Force would, on its own, somehow win the day, merely that it is a very major element in such potential struggle, control of which is very desirable to some. How effective it would be in the end is far too complex a thing to predict, depending on myriad of factors such as the tactics and competence of commanders of both sides, logisitics, sequences of events etc etc all the way down to weather, and would be something for historians to piece together for decades afterwards.
Which would work so well, since airpower is the deciding factor in the current Iraq campaigns... oh, wait...
It all depends on how it is used. Air Force was definitely the decisive factor in completely eviscerating Saddam's army. In a civil war it would have a decisive role in reducing the other side to the status of militia/partisan/insurgent style resistance. What would happen past that point is up for debate. Note however that all of the current (barely effective) constraints on civilian casualties would likely be moot in a civil war where one side is on a "Mission from God" and has an ability to effect large scale aerial bombardment.
At this point, armed militias are worthless against the power of the US Army and its remaining allies. They have weapons that we may acquire, regardless of the numbers of individuals we have on our side, will be of no match to the powerful arsenal that the government has.
You assumed that all of the US Armed forces politicaly monolitic and would side with the government. In reality what would happen, as in any civil war, a portion would join the rebels. How large a portion? That's anyone's guess. But the resulting warfare would be far removed from "militias vs mechanized divisions".
In my view, that is precisely why various Fundamentalist Christian Dominionist movements are, for many years now, desperately attempting to take over the Air Force, for they see it as the key deciding factor in any future conflagration.
Support for them is already there though, and has been for some time. A monitor can be used to make a thread sleep until something it cares about happens. Of course since you never saw the code the NT kernel uses to implement them, you really can't say how much overhead they use. I'd think any modern OS is smart enough not to even bother with a process / thread if its waiting to be pulsed.
Well, that is the whole point of calling the kernel for process synchronization, that the scheduler can reusme threads suspended waiting for semaphores, mutexes, spinlocks and what not. The overhead is inherent in calling into the ring 0, in addition to the fact that in some cases the kernel must flush the CPU cache to get reliably at some control variables. That is why in many cases single threaded processes are more efficient then multi-threaded ones, and the primary reason for parallelization of them up is either logical clarity or better responsiveness (although not necessarily performance) and thus subjective user experience in interactive GUI applications.
Needless to say none of this has anything to do with security or DRM.
And yet using them in a DRM system seems like a perfectly reasonable thing to do, especially if you don't want code checking all the time the state of the system; instead, the system notifies interested parties when something changes, and the check is done then. If nothing is monitoring, nothing is notified.
Which is useless from the point of view of security and DRM in particular. That is because in addition to the fact that the attacker can easily manipulate code in the said threads as there is nothing to stop him from modifying it to his needs, he does not even have to bother with that, as the Holy Grail of anti-DRM activities, the decryption key itself (or the decrypted data) is not possible to be protected by semaphores, spinlocks, mutexes and all the other task synchronization mechanisms. They are simply not applicable to this whole different domain.
I explain how you could create such a system, and you claim its impossible. I don't think my coding skills are the ones that need to be questioned.
So far you've "explained" your conviction that semaphores are a security mechanism...
It only adds overhead when DRM is in use. Otherwise the audio drives (or video) continue to operate the same, whether or not DRM is in place.
Sigh. Even if semaphores were some sort of security solution, which they are not, insertion of multiple calls to the kernel and multiple if-then-else clauses into the code to activate them if needed would affect the performance, not to mention, again, piles of code dealing with encryption/decryption. And you stubbornly keep neglecting the fact that all of this is insufficient to stop an attacker from simply extacting what he needs from the system during playback.
That is why DRM must be a systemic entity, amongst other things ensuring that no one can compromise the environment in which these drivers function to get at the critical data. That is why the system must be in a "trusted" state all the time prior to the playback. Once compromised at any time prior to the playback, the game is over as the drivers (and all the other DRM components) become exposed to run-time manipulation and examination by the attacker.
Which of course means that DRM functions are operative continuously from the boot time on. There is no other feasible way to do it (and even that is insufficient in the long term - that is why DRM is a lost cause).
The typical response of trolls. Assert something is true, and never stop and think they could possibly be wrong.
There are limits to the depth of nonsense which I am willing to even dignify with a reply.
Judiciary is only to judge the accusations of non-compliance with the law in trials where the executive is the prosecuting (or defending) side. But they also have an ability to judge enforceabiliy and constitutionality of laws.
I think the names of the branches easily denotes their roles. Legislative creates the laws. Executive executes the laws (enforces) Judicial judges the laws. This may be oversimplification, but it pretty much is the gist of it.
You are on a right track but the actual thing goes like this: Legislative creates the laws, Executive implements the laws (by organizing things so that the laws come into effect and providing resources to ensure the laws remain in effect), Judicial enforces the laws (by prosecuting all those who violate the laws and sometimes judging if the laws themselves are feasible to be enforced).
I guess the concept I already posted about is too complex for you to understand, for if you understood semaphores or monitors you would be able to come up with the rest of the details yourself.
You are a complete moron. Semaphores and monitors (at least as that term is used in the same context as semaphores) are mechanisms used to synchronize threads and processes, with quite significant computational overhead may I add (particularly the monitors) as both involve deep calls into the kernel in modern multi-core/multi-CPU systems complicated by predictive branching, caching and multi-pipeline instruction execution (not to mention the whole rigmarole of wrapper code and access routines used in the monitor approach to concurrency).
Oh and they have absolutely nothing whatsoever to do with security or DRM.
No, stupid, it doesn't require constant checks unless something is being played back. One check is required when playback is started, and the next check would be when some relevent part of the state of the machine changes. Those changes can be signeled using semaphores or monitors.
I think you really believe this! Well then, you should really seek a job in one of those inane DRM software outfits which gave us Shift-key bypassable CD rootkits or Media Defender style "anti-piracy defense". With clowns like you around "contributing", our job to crack this stuff would be child's play. I am looking forward to you reinventing ROT-13 or XOR "encryption"!
Audio drives must be single threaded?
But of course! Listen up everyone! A breakthrough in Computer Science! Our resident Genius, plague3106, determined that splitting a task into multiple parallel threads magically reduces the overall computational requirements and memory footprint! All possible by Magical Overhead-Free Semaphores and Fairy-Tale Pixie-dust Monitors! The Nobel Prize cannot be far behind, surely?
They cannot send a message to another part of the system? Messages they are already likely sending?
Yes they are sending "messages" in the vain of "Hey! Did you hear? plague3106 is a complete nimrod!".
You're under the assumption that drivers already AREN'T reporting various status of some kind. Something external to the drives can then do the monitoring, and that external thing can be told to start or stop.
This is just too stupid for words. This idiot must have learned about concurrency in some book titled "Computing for Total Cretins" as the cure-all solution to all security problems, particularly DRM. Just you wait till he gets to a chapter wherein they describe memmap and shared memory...
Apparently it never crossed his mind, security genius that he is, that someone could just replace whatever process is he synchronizing with, using his cure-all semaphores, with a fake one doing the very same thing and the other process would not be any wiser. Never you mind that the actual objective of a cracker is to obtain the DRM decryption key rather then to mess around with multi-process synchronization, against which this whole "approach" does precisely didley squat, leaving the crown jewels out in the open by the front door while he is screwing around with multi-threading in the proverbial outhouse.
I've already explained (and you fail to understand)
I am afraid that I discovered the reason for this. One has to be under the influence of some rather potent mind altering substances to enter the rarefied state of mind you possess. Fortunately, I do not do drugs.
... how a system can be present and not affect performance when not in use. You just continue to claim its not possible. Oh well.
That is because of the nature of the system in question prevents you from doing that! DRM is not some sort of optional DLL one can delete without altering the
Erm, if Congress passed a law giving them oversight over the executive on domestic wiretapping, Bush could and probably would just veto it.
Congress has such powers by definition as oversight over the activities of the Executive Branch is one of the key roles of Congress as granted by the Constitution. That is why they have very broad investigative powers granted by the same Constitution for this very purpose.
And it would mean the end of the US as a Republic and an official beginning of the Empire.
Also note that in an effort to prevent such a scenario, all the armed forces take an oath to the Constitution, not to the President to make clear which has precedence over which.
AFAIK, Congress may not be able to legally legislate oversight into this program as doing so would violate national security...
Oh boy. It is up to the Legislative branch to determine what does, and what does not, "violate national security". Not anyone else. They, according to the Constitution, set all the rules. Not the Executive, not the Judicial, not the military or intelligence agencies. No one else. Legislative branch is the only one with these powers.
On top of which, if Congress just decided to write themselves into an oversight role...
Their oversight role is one of the key elements of the Constitution. They cannot "write themselves" in because that is their core function, they cannot "write themselves" out because that would require a Constitutional Ammendment.
That is because it is their role. In order to legislate, they have to be able to determine the facts to adjust the legislation accordingly. That is why they have very broad investigative powers. Also it is the role of Congress to oversee the Executive, and if necessary investigate it and even remove the President, if the investigation warrants it. Note that the Constitution provides no means for the Executive to remove Congress.
Isn't the US Constitution clear on the point of oversight, giving Congress the ability to investigate and even remove the president, but not the other way around?
Or is the US truly near its nadir and soon "el Presidente" will be running everything, unopposed.
Ya, right. I'm going to wipe up a quick code snippet on a complex DRM system.
I did not ask you for a "complex system". Just for an example of 2 lines of code without a call to a DRM check and 2 same lines with a call to DRM subroutine insterted between to demonstrate the utter impossibility of adding optional code without incurring cost in instruction cycles or memory. Oh but then I get it, this is too "complex" for you.
The concept is what's important.
That's right. The very concept I already explained ad nauseum and which zoomed at great velocity so far above your head that it might as well be in orbit.
I'll give you a hint; it would involve knowing the machine is in a drm "safe" state when playback starts.
Which requires copious amounts of code to check if the machine is in a DRM "safe" state, thus increasing complexity and decreasing performance. This check has to occur continuously with assistance of tamper-resistant hardware, prior to activation of the playback, otherwise it is completely useless from the point of view of ensuring DRM security, as without it an attacker can set the machine to a "safe" state via a multitude of spoofing mechanisms, such as virtualization, amongst many others. This understanding of the integrity of the security environment (of which you are apparently completely, blissfully, comically ignorant) is the cornerstone of all advanced DRM designs, and the very foundation behind the TPM which computes a running, real-time, encrypted, securely remotely verifiable checksum of all instuctions executed by the CPU (and other system activities) since a given reset point, long prior to entering the actual service routine (a video playback in this case) in a secure environment.
Devices in the loop will invoke a monitor if their state changes (line single changes, etc.). When that happens, another check will be performed and if the check fails, stop playback.
Your inane incompetence makes me laugh. "Devices in the loop" involve things such as the... audio adapter drivers, which would have to "monitor their state" (by magical means you neglected to describe) with every sound sample (which is a state change at 44,000 times a second in a typical 2-channel audio stream) and would have to be able to do so in the "DRM mode" and also not do so outside of it, that is on demand, the code for all this being of course embedded in the said drivers. This of course ignores, with blissful ignorance you are so fond of, multiple encryption/decryption stages, requirements for which are part of all DRM schemes. Not to mention that the critical elements of this have to be implemented by the 3rd party developers of drivers for hardware designed in Taiwan, so widely known for quality, highly efficient and well behaved code...
You never once presented any other reason for poorer system performance
I also failed to bring up a comparison chart between SAS and SATA hard drives and the migratory habits of Seagulls. Could it possibly be because I replied to a post claiming that DRM is one of those miraculously side-effect free achievments in the vain of "Have your cake and eat it too!" or "Build your own perpetual motion machine!" from someone who clearly has no idea what DRM systems entail?
Ahh, so because software runs on a chip, it can't possibly not run certain code. Interesting theory.
Yes indeed. The program cannot miraculously, via psychic powers, jump from instruction A to B whenever you wish it to happen or from A to C when you do not. There has to be some condition check, which is also an instruction somewhere after A and before B and C (or the second instruction is a variation on an indirect jump via a memory location to C or B, which has its own overheads and problems). In our case that condi
I am a programmer with decades of experience as well, and I thought out quite a few ways it could be done without a constant drain on resources.
Oh, for Pete's sake, name one. Show a code snippet, in any language of your choice, with and without DRM calls. Then explain how they are executed in the same number of machine instructions and how they occupy the same amount of memory.
Needles to say I am not holding by breath waiting for that Earth-shattering, space-time-continuum-defying demonstration.
You seem to be confusing physics with building software.
Sure, that is because software does not execute on physical objects such as... let me think... a CPU, no? And naturally we are not discussing observable physical phenomena such as... oh I don't know... comparative time between events, certainly?
You think that DRM is the only possible reason for a system to run more slowly?
Nice strawman. Now point me to a place where I claimed that DRM is the only reason for Vista being a hog.
I never once brought up MS PR, or attributed anything to that department. They aren't the ones claiming that DRM doesn't affect anything unless you're playing back protected content.
Let me refresh your memory:
Says you:
... what you said is contrary to how MS said they built the system...
You do realize that the stuff you are spouting can be recalled just by scrolling up? Next thing you will be saying that it is possible for anything to officially come out of Microsoft that is not approved by the PR spin-meisters...
I also never claimed SuperFetch worked (please, point out where I have).
Neither did I claim that you said that SuperFetch worked. I merely pointed out that you are listing it as a reason for Vista being slow, in direct contradiction to Microsoft who instist that SuperFetch is a "performance enhancing feature", and yet, in the same breath you are telling me how things are because Microsoft said so. That is the contradiction, although it appears that you are incapable of comprehending it.
Seeing, in this exchange, all of your reasoning powers, I sincerely hope that I never have the grave misfortune of using any code you wrote. And I pity all the poor sods who do.
I noticed you never actually have claimed to even have used Vista either.. interesting that someone can make claims such as you, seemingly, without having used it.
I already explained how it is not only possible, but quite ordinary to be in that position in regards to the main topic of this discussion.
Your argument is that you know exactly how such a system MUST have been built. Anything else in your mind is excluded automatically.
That is because, as a programmer with decades of experience, I do know, with absolute certainty, that it is how it must be built. I might not know the specific details (which are jealously guarded by MS) but the general principles are involatile and inescapable. Just like the laws of thermodynamics.
The truth is you're only guessing, what you said is contrary to how MS said they built the system, and you claim that is proof that you are absolutely correct.
Microsoft PR departament has claimed so many incorrect things over the years that it boggles one's mind. As to guessing, I am no more doing so then pointing out that 2+2=4. It is simply physically impossible to do what you (and the Microsoft PR flacks - if it is indeed what they are claiming, although I would think they would be much more vague and evasive then you are) claim has been done.
Its pretty easy to see the zealotry you are coming from; you paint the whole of MS with one brush, when the reality is that it is a large company, with many departments that actually DO have conflicting images. No different than saying "the government" is spying on you, when in fact the department of Forestry doesn't care about you at all unless you enter a national park, and even they, aren't spying on you.
As I already pointed out, my feelings on Microsoft are irrelevant to the fact that laws of physics prevent them from accomplishing miracles, such as insertion of large amount of any code into any computer program and not suffering the resulting consequences.
If Vista runs slower, its much more likely because its doing alot more than XP did.
Such as implementing DRM.
Bonus points for contradicting yourself within 3 posts.
Things that have nothing to do with DRM, such as Superfetch, the new indexing server, sync center and a host of other new services.
No one has claimed that those too do not impact performance.
Also, additional bonus points for contradicting yourself in claiming that Microsoft PR is to be trusted while listing the supposedly "performance enhancing" Superfetch as a cause of performance problems. Do you actually pause to think before spewing this crap?
I don't expect you to know this, I don't think you've ever even booted Vista.
My booting or not of Vista has nothing whatsoever do to with general principles of Computer Science. Nor it is a requirement for me to have first-hand experience when discussing an article based on large scale statistical reports of user experiences.
So simple logic and observation seem to you "extraordinary"? Now when you mention it, that would explain a lot of thigs...
You are; you need to prove your point, since its unlikely DRM affects you when you're not playing a movie.
As I pointed out already, if you insert piles of code into every subsystem involved in video and audio playback, it must affect complexity and with it performance to some degree. There is no escaping from this simple, logical fact, no matter how much do you wish it were otherwise.
Especially considering MS has said as much.
LOL! The dude is actually invoking Microsft as an objective, disinterested authority on accusations against Microsoft! Talk about uncritical, slavish adoration. Absolutely priceless!
So PROVE them wrong, or shut it.
I already did, quite conclusively. Just like one cannot squeeze blood from stone, one cannot add complicated code to critical system data pathways and not increase complexity, thus decreasing performance. Even if the code in question is intended to be "off" when not used. The very requirements for implementation of these subsystems by vendors of, for example, graphics adapter drivers will cause them to pepper their code with "if then else" clauses at the minimum and additional blocks of instructions dealing with encryption and key handling, all which require to be properly obfuscated and thus large in size, reducing the memory available for other tasks even in the most optimistic scenario, and thus reducing performance even if indirectly due to reducing caching. And this does not even begin to touch other of the many aspects of DRM.
Your arguments reek of some mad-man's defense of his "perpetual motion machine" invention, raving and raging against skeptics about how his miraculous device is producing "something out of nothing" and how they should go prove him wrong, despite everyone observing by naked eye that the thing is slowing down.... never you mind things like the laws of theromodynamics.
... which is that its DRM slowing the system down, EVEN WHEN NOTHING IS BEING PLAYED. So please, back up your claim.
See above. The only argument that is feasible is that of how much is the system slowed down. Not if.
Ahh, you mean daemons which sit there and literally do nothing until a movie start playing?
Are you insinuating that you know with any degree of assurance how Microsoft put together their secret-souce, non-disclosure agreement protected DRM system? Are you an employee in Microsoft's DRM division?
Or are you perheaps attempting to imply that Microsoft is widely known and praised for well behaved, frugal with resources and CPU time background processes?
Ok, you think you know how the system works. Please post a reference that backs up your post. Otherwise, STFU.
I never claimed to "know" how the system works, that is merely a strawman you contructed yourself. I only pointed out that there is a number of possibilities, some of them very likely due to the nature of such designs, which you are apparently due to some zealotry quite unwilling to consider out of hand. As to "backing up" my claims, isn't this whole discussion about empirically observable (in many ways by now) general user dissatisfaction with Vista, in major part because of performance problems?
Once again, until you play DRM content there's no DRM cycles used.
That is by no means a certainty. Many DRM system designs are in form of "windows services", i.e. daemons which continuously run in the background "monitoring" things or for "faster response" i.e. to save on load time and give the user an illusion of better interactivity at the expense of overall performance loss. Furthermore, the most recent DRM designs involve extensive and intrusive interactions with all the paths digital audio/video contents can take thus increasing radically the complexity, and thus performance of those subsystems even without DRM contents being played.
... is considered "easy to read" and "easy to maintain". Note the lovely formatting (as it appears in the actual file - less a few newlines as Slashcode wraps the crap) due to some inane Microsoft MMC GUI tool used to generate the thing. Also note the profuse commentary (that is assuming that you actually could ever properly comment this spew as comments are not allowed within tags, even ignoring the fact that the imbecilic MMC tool would simply remove them on the next use).
I will leave it as an excercise to the reader to conclude which one of us is operating based on delusional, emotional attachment to insanely misused formats and which one has an actual experience with configuration files in real life.
As to Semdmail, may I remind you that the so-called "config" file is an actual machine code of a state driven processor around which Sendmail itself was constructed. Apples and oranges. And no, it was no more easy or harder to read then any stream of machine instructions for any other machine to be directly executed by it. It was never meant to be easily human-readable and its syntax is driven by the extremely demanding resource limitations at the time when original Sendmail was developed. The fact that it proved a maintenance nightmare (despite of its extreme power and flexibility as compared to regular config files) was a leading impetus behind Sendmail losing to other MTAs as years went on and extreme frugality with resources became secondary to ease of maintenance.
Oh and your sanctimonious whining about "hopping into this century to drool at shiny but valueless stuff" does not help your cause either, as the basics of computer science remain unchanged since its very inception and they will remain firmly so even if our computers end up grown in vats out of quantum-mechanical nanomachines. And one of those fundamental, time-tested constants is the requirement for brevity, clarity and ability to comment extensively any configuration files, although untold numbers of misguided "innovators" have attempted to "improve" this in a countless number of ways, of which the XML insanity is but one of the later flops, standing atop of a heap of rotting carcasses of previous failures, which went by names such as "binary configuration databases" and "registry hives" and what not.
And so, long after your pet fad is gone, I am sure I will be having this same very conversation with some condescending accolyte of "Object Oriented Four Dimentional Cube, Buzzword Overloaded" config files or what not, who will snicker about how quaintly old-fashioned these fundamentals are, and that I should "get on with the times" to his new favourite, one-and-only, super-correct fad.
In short, your kind never learns.
I'll also note how you fail to mention any better alternatives in your inflammatory rant.
Quite a comedian you are. How about any other time-proven config file format used by just about any sane application? Bind, DHCP, SSH... and on and on and on.
Slashdot Mirror
Also I forgot to add:
You gotta be kidding, right?
Police are the last people on earth who want users of personal computers to be able to detect intrusions. They are, specialy the newfangled "Father ... err ... Homeland Security" types, one the groups most eager to use trojans, keyloggers and the like in their pursuit of "criminals".
Except of course that it is a red herring. The first definition is the only one on which all of the proposed mass-produced commercial TPM designs are based. Most of these designs also include select, castrated elements of the second definition, as a bone to throw the gullible public in exchange for corporations taking over control of the property their customers supposedly "own".
A Trusted Computing design which would fit into the second but not first category involves an ability of the owner of the system to extract/alter the master TPM keys in a secure manner (requiring local, physical access for example).
This is NOT going to happen!
Let me repeat: NO presently proposed TC design involves the owner of the computer having access to master TPM keys. NONE!
So please stop helping these assholes do their dirty work by being so naive.
Sure, it will happen but it will (unless the TPM makers are total dolts) involve electron microscopes or some other wacky hardware which very, very few people have. We are talking about a hardware hack with a high level of difficulty, which could crimp our style for some while at least.
Only to be outpaced by some new mathematical formulae for even more convoluted and computationaly intensive encryption schemes. Quantum computing is fast, but it is not infinitely fast. All one has to do is come up with something which is convoluted enough to make even fastest theoretically possible quantum computer (which is a finite physical object) crunch numbers for a few millenia.
I am not saying that they will succeed. I am telling you what the plan, and the purpose (as designed) of the whole Trusted Computing concept is.
The only thing which is certain that the Media Pigopolits, Microsoft and many other large corps will try hard to do this.
Many large banks and online retailers will get on the bandwagon as they positively despise the fact that they have to actually do work and support many different browsers on different platforms. Their dream is to make us use one, homogenous platform where we cannot control anything of importance and thus it is possible for them to deploy a cookie-cutter, one-size-fits-all, Lego-blocks style IIS/IE/TrustedActiveX "solution" everywhere without having to worry about compliance with any non-Microsoft standards or applications.
In short, this article aims to lure the unwary into gullible acceptance of TC with an illusion of completely deceitfully presented and impractical (no one except the mega-corps will ever get the access to the main TPM keys) applications.
Neither am I proposing that Air Force would, on its own, somehow win the day, merely that it is a very major element in such potential struggle, control of which is very desirable to some. How effective it would be in the end is far too complex a thing to predict, depending on myriad of factors such as the tactics and competence of commanders of both sides, logisitics, sequences of events etc etc all the way down to weather, and would be something for historians to piece together for decades afterwards.
It all depends on how it is used. Air Force was definitely the decisive factor in completely eviscerating Saddam's army. In a civil war it would have a decisive role in reducing the other side to the status of militia/partisan/insurgent style resistance. What would happen past that point is up for debate. Note however that all of the current (barely effective) constraints on civilian casualties would likely be moot in a civil war where one side is on a "Mission from God" and has an ability to effect large scale aerial bombardment.
You assumed that all of the US Armed forces politicaly monolitic and would side with the government. In reality what would happen, as in any civil war, a portion would join the rebels. How large a portion? That's anyone's guess. But the resulting warfare would be far removed from "militias vs mechanized divisions".
In my view, that is precisely why various Fundamentalist Christian Dominionist movements are, for many years now, desperately attempting to take over the Air Force, for they see it as the key deciding factor in any future conflagration.
Well, that is the whole point of calling the kernel for process synchronization, that the scheduler can reusme threads suspended waiting for semaphores, mutexes, spinlocks and what not. The overhead is inherent in calling into the ring 0, in addition to the fact that in some cases the kernel must flush the CPU cache to get reliably at some control variables. That is why in many cases single threaded processes are more efficient then multi-threaded ones, and the primary reason for parallelization of them up is either logical clarity or better responsiveness (although not necessarily performance) and thus subjective user experience in interactive GUI applications.
Needless to say none of this has anything to do with security or DRM.
Which is useless from the point of view of security and DRM in particular. That is because in addition to the fact that the attacker can easily manipulate code in the said threads as there is nothing to stop him from modifying it to his needs, he does not even have to bother with that, as the Holy Grail of anti-DRM activities, the decryption key itself (or the decrypted data) is not possible to be protected by semaphores, spinlocks, mutexes and all the other task synchronization mechanisms. They are simply not applicable to this whole different domain.
So far you've "explained" your conviction that semaphores are a security mechanism ...
Sigh. Even if semaphores were some sort of security solution, which they are not, insertion of multiple calls to the kernel and multiple if-then-else clauses into the code to activate them if needed would affect the performance, not to mention, again, piles of code dealing with encryption/decryption. And you stubbornly keep neglecting the fact that all of this is insufficient to stop an attacker from simply extacting what he needs from the system during playback.
That is why DRM must be a systemic entity, amongst other things ensuring that no one can compromise the environment in which these drivers function to get at the critical data. That is why the system must be in a "trusted" state all the time prior to the playback. Once compromised at any time prior to the playback, the game is over as the drivers (and all the other DRM components) become exposed to run-time manipulation and examination by the attacker.
Which of course means that DRM functions are operative continuously from the boot time on. There is no other feasible way to do it (and even that is insufficient in the long term - that is why DRM is a lost cause).
There are limits to the depth of nonsense which I am willing to even dignify with a reply.
You are right. I stand corrected.
Judiciary is only to judge the accusations of non-compliance with the law in trials where the executive is the prosecuting (or defending) side. But they also have an ability to judge enforceabiliy and constitutionality of laws.
You are on a right track but the actual thing goes like this: Legislative creates the laws, Executive implements the laws (by organizing things so that the laws come into effect and providing resources to ensure the laws remain in effect), Judicial enforces the laws (by prosecuting all those who violate the laws and sometimes judging if the laws themselves are feasible to be enforced).
You are a complete moron. Semaphores and monitors (at least as that term is used in the same context as semaphores) are mechanisms used to synchronize threads and processes, with quite significant computational overhead may I add (particularly the monitors) as both involve deep calls into the kernel in modern multi-core/multi-CPU systems complicated by predictive branching, caching and multi-pipeline instruction execution (not to mention the whole rigmarole of wrapper code and access routines used in the monitor approach to concurrency).
Oh and they have absolutely nothing whatsoever to do with security or DRM.
I think you really believe this! Well then, you should really seek a job in one of those inane DRM software outfits which gave us Shift-key bypassable CD rootkits or Media Defender style "anti-piracy defense". With clowns like you around "contributing", our job to crack this stuff would be child's play. I am looking forward to you reinventing ROT-13 or XOR "encryption"!
But of course! Listen up everyone! A breakthrough in Computer Science! Our resident Genius, plague3106, determined that splitting a task into multiple parallel threads magically reduces the overall computational requirements and memory footprint! All possible by Magical Overhead-Free Semaphores and Fairy-Tale Pixie-dust Monitors! The Nobel Prize cannot be far behind, surely?
Yes they are sending "messages" in the vain of "Hey! Did you hear? plague3106 is a complete nimrod!".
This is just too stupid for words. This idiot must have learned about concurrency in some book titled "Computing for Total Cretins" as the cure-all solution to all security problems, particularly DRM. Just you wait till he gets to a chapter wherein they describe memmap and shared memory...
Apparently it never crossed his mind, security genius that he is, that someone could just replace whatever process is he synchronizing with, using his cure-all semaphores, with a fake one doing the very same thing and the other process would not be any wiser. Never you mind that the actual objective of a cracker is to obtain the DRM decryption key rather then to mess around with multi-process synchronization, against which this whole "approach" does precisely didley squat, leaving the crown jewels out in the open by the front door while he is screwing around with multi-threading in the proverbial outhouse.
I am afraid that I discovered the reason for this. One has to be under the influence of some rather potent mind altering substances to enter the rarefied state of mind you possess. Fortunately, I do not do drugs.
That is because of the nature of the system in question prevents you from doing that! DRM is not some sort of optional DLL one can delete without altering the
Congress has such powers by definition as oversight over the activities of the Executive Branch is one of the key roles of Congress as granted by the Constitution. That is why they have very broad investigative powers granted by the same Constitution for this very purpose.
There is a term for this plan: coup d'état.
And it would mean the end of the US as a Republic and an official beginning of the Empire.
Also note that in an effort to prevent such a scenario, all the armed forces take an oath to the Constitution, not to the President to make clear which has precedence over which.
Oh boy. It is up to the Legislative branch to determine what does, and what does not, "violate national security". Not anyone else. They, according to the Constitution, set all the rules. Not the Executive, not the Judicial, not the military or intelligence agencies. No one else. Legislative branch is the only one with these powers.
Their oversight role is one of the key elements of the Constitution. They cannot "write themselves" in because that is their core function, they cannot "write themselves" out because that would require a Constitutional Ammendment.
That is because it is their role. In order to legislate, they have to be able to determine the facts to adjust the legislation accordingly. That is why they have very broad investigative powers. Also it is the role of Congress to oversee the Executive, and if necessary investigate it and even remove the President, if the investigation warrants it. Note that the Constitution provides no means for the Executive to remove Congress.
Isn't the US Constitution clear on the point of oversight, giving Congress the ability to investigate and even remove the president, but not the other way around?
Or is the US truly near its nadir and soon "el Presidente" will be running everything, unopposed.
I did not ask you for a "complex system". Just for an example of 2 lines of code without a call to a DRM check and 2 same lines with a call to DRM subroutine insterted between to demonstrate the utter impossibility of adding optional code without incurring cost in instruction cycles or memory. Oh but then I get it, this is too "complex" for you.
That's right. The very concept I already explained ad nauseum and which zoomed at great velocity so far above your head that it might as well be in orbit.
Which requires copious amounts of code to check if the machine is in a DRM "safe" state, thus increasing complexity and decreasing performance. This check has to occur continuously with assistance of tamper-resistant hardware, prior to activation of the playback, otherwise it is completely useless from the point of view of ensuring DRM security, as without it an attacker can set the machine to a "safe" state via a multitude of spoofing mechanisms, such as virtualization, amongst many others. This understanding of the integrity of the security environment (of which you are apparently completely, blissfully, comically ignorant) is the cornerstone of all advanced DRM designs, and the very foundation behind the TPM which computes a running, real-time, encrypted, securely remotely verifiable checksum of all instuctions executed by the CPU (and other system activities) since a given reset point, long prior to entering the actual service routine (a video playback in this case) in a secure environment.
Your inane incompetence makes me laugh. "Devices in the loop" involve things such as the ... audio adapter drivers, which would have to "monitor their state" (by magical means you neglected to describe) with every sound sample (which is a state change at 44,000 times a second in a typical 2-channel audio stream) and would have to be able to do so in the "DRM mode" and also not do so outside of it, that is on demand, the code for all this being of course embedded in the said drivers. This of course ignores, with blissful ignorance you are so fond of, multiple encryption/decryption stages, requirements for which are part of all DRM schemes. Not to mention that the critical elements of this have to be implemented by the 3rd party developers of drivers for hardware designed in Taiwan, so widely known for quality, highly efficient and well behaved code...
I also failed to bring up a comparison chart between SAS and SATA hard drives and the migratory habits of Seagulls. Could it possibly be because I replied to a post claiming that DRM is one of those miraculously side-effect free achievments in the vain of "Have your cake and eat it too!" or "Build your own perpetual motion machine!" from someone who clearly has no idea what DRM systems entail?
Yes indeed. The program cannot miraculously, via psychic powers, jump from instruction A to B whenever you wish it to happen or from A to C when you do not. There has to be some condition check, which is also an instruction somewhere after A and before B and C (or the second instruction is a variation on an indirect jump via a memory location to C or B, which has its own overheads and problems). In our case that condi
Oh, for Pete's sake, name one. Show a code snippet, in any language of your choice, with and without DRM calls. Then explain how they are executed in the same number of machine instructions and how they occupy the same amount of memory.
Needles to say I am not holding by breath waiting for that Earth-shattering, space-time-continuum-defying demonstration.
Sure, that is because software does not execute on physical objects such as ... let me think ... a CPU, no? And naturally we are not discussing observable physical phenomena such as ... oh I don't know ... comparative time between events, certainly?
Nice strawman. Now point me to a place where I claimed that DRM is the only reason for Vista being a hog.
Let me refresh your memory:
Says you:
You do realize that the stuff you are spouting can be recalled just by scrolling up? Next thing you will be saying that it is possible for anything to officially come out of Microsoft that is not approved by the PR spin-meisters...
Neither did I claim that you said that SuperFetch worked. I merely pointed out that you are listing it as a reason for Vista being slow, in direct contradiction to Microsoft who instist that SuperFetch is a "performance enhancing feature", and yet, in the same breath you are telling me how things are because Microsoft said so. That is the contradiction, although it appears that you are incapable of comprehending it.
Seeing, in this exchange, all of your reasoning powers, I sincerely hope that I never have the grave misfortune of using any code you wrote. And I pity all the poor sods who do.
I already explained how it is not only possible, but quite ordinary to be in that position in regards to the main topic of this discussion.
That is because, as a programmer with decades of experience, I do know, with absolute certainty, that it is how it must be built. I might not know the specific details (which are jealously guarded by MS) but the general principles are involatile and inescapable. Just like the laws of thermodynamics.
Microsoft PR departament has claimed so many incorrect things over the years that it boggles one's mind. As to guessing, I am no more doing so then pointing out that 2+2=4. It is simply physically impossible to do what you (and the Microsoft PR flacks - if it is indeed what they are claiming, although I would think they would be much more vague and evasive then you are) claim has been done.
As I already pointed out, my feelings on Microsoft are irrelevant to the fact that laws of physics prevent them from accomplishing miracles, such as insertion of large amount of any code into any computer program and not suffering the resulting consequences.
Such as implementing DRM.
Bonus points for contradicting yourself within 3 posts.
No one has claimed that those too do not impact performance.
Also, additional bonus points for contradicting yourself in claiming that Microsoft PR is to be trusted while listing the supposedly "performance enhancing" Superfetch as a cause of performance problems. Do you actually pause to think before spewing this crap?
My booting or not of Vista has nothing whatsoever do to with general principles of Computer Science. Nor it is a requirement for me to have first-hand experience when discussing an article based on large scale statistical reports of user experiences.
So simple logic and observation seem to you "extraordinary"? Now when you mention it, that would explain a lot of thigs...
As I pointed out already, if you insert piles of code into every subsystem involved in video and audio playback, it must affect complexity and with it performance to some degree. There is no escaping from this simple, logical fact, no matter how much do you wish it were otherwise.
LOL! The dude is actually invoking Microsft as an objective, disinterested authority on accusations against Microsoft! Talk about uncritical, slavish adoration. Absolutely priceless!
I already did, quite conclusively. Just like one cannot squeeze blood from stone, one cannot add complicated code to critical system data pathways and not increase complexity, thus decreasing performance. Even if the code in question is intended to be "off" when not used. The very requirements for implementation of these subsystems by vendors of, for example, graphics adapter drivers will cause them to pepper their code with "if then else" clauses at the minimum and additional blocks of instructions dealing with encryption and key handling, all which require to be properly obfuscated and thus large in size, reducing the memory available for other tasks even in the most optimistic scenario, and thus reducing performance even if indirectly due to reducing caching. And this does not even begin to touch other of the many aspects of DRM.
Your arguments reek of some mad-man's defense of his "perpetual motion machine" invention, raving and raging against skeptics about how his miraculous device is producing "something out of nothing" and how they should go prove him wrong, despite everyone observing by naked eye that the thing is slowing down .... never you mind things like the laws of theromodynamics.
See above. The only argument that is feasible is that of how much is the system slowed down. Not if.
Are you insinuating that you know with any degree of assurance how Microsoft put together their secret-souce, non-disclosure agreement protected DRM system? Are you an employee in Microsoft's DRM division?
Or are you perheaps attempting to imply that Microsoft is widely known and praised for well behaved, frugal with resources and CPU time background processes?
I never claimed to "know" how the system works, that is merely a strawman you contructed yourself. I only pointed out that there is a number of possibilities, some of them very likely due to the nature of such designs, which you are apparently due to some zealotry quite unwilling to consider out of hand. As to "backing up" my claims, isn't this whole discussion about empirically observable (in many ways by now) general user dissatisfaction with Vista, in major part because of performance problems?
Well, if everyone has an aimbot, that simply changes the tactics one has to employ while playing, possibly producing whole new game styles...
That is by no means a certainty. Many DRM system designs are in form of "windows services", i.e. daemons which continuously run in the background "monitoring" things or for "faster response" i.e. to save on load time and give the user an illusion of better interactivity at the expense of overall performance loss. Furthermore, the most recent DRM designs involve extensive and intrusive interactions with all the paths digital audio/video contents can take thus increasing radically the complexity, and thus performance of those subsystems even without DRM contents being played.
I am starting to believe that you XML turkeys operate in some alternative Universe where diarrhea like this:
... is considered "easy to read" and "easy to maintain". Note the lovely formatting (as it appears in the actual file - less a few newlines as Slashcode wraps the crap) due to some inane Microsoft MMC GUI tool used to generate the thing. Also note the profuse commentary (that is assuming that you actually could ever properly comment this spew as comments are not allowed within tags, even ignoring the fact that the imbecilic MMC tool would simply remove them on the next use).
I will leave it as an excercise to the reader to conclude which one of us is operating based on delusional, emotional attachment to insanely misused formats and which one has an actual experience with configuration files in real life.
As to Semdmail, may I remind you that the so-called "config" file is an actual machine code of a state driven processor around which Sendmail itself was constructed. Apples and oranges. And no, it was no more easy or harder to read then any stream of machine instructions for any other machine to be directly executed by it. It was never meant to be easily human-readable and its syntax is driven by the extremely demanding resource limitations at the time when original Sendmail was developed. The fact that it proved a maintenance nightmare (despite of its extreme power and flexibility as compared to regular config files) was a leading impetus behind Sendmail losing to other MTAs as years went on and extreme frugality with resources became secondary to ease of maintenance.
Oh and your sanctimonious whining about "hopping into this century to drool at shiny but valueless stuff" does not help your cause either, as the basics of computer science remain unchanged since its very inception and they will remain firmly so even if our computers end up grown in vats out of quantum-mechanical nanomachines. And one of those fundamental, time-tested constants is the requirement for brevity, clarity and ability to comment extensively any configuration files, although untold numbers of misguided "innovators" have attempted to "improve" this in a countless number of ways, of which the XML insanity is but one of the later flops, standing atop of a heap of rotting carcasses of previous failures, which went by names such as "binary configuration databases" and "registry hives" and what not.
And so, long after your pet fad is gone, I am sure I will be having this same very conversation with some condescending accolyte of "Object Oriented Four Dimentional Cube, Buzzword Overloaded" config files or what not, who will snicker about how quaintly old-fashioned these fundamentals are, and that I should "get on with the times" to his new favourite, one-and-only, super-correct fad.
In short, your kind never learns.
Quite a comedian you are. How about any other time-proven config file format used by just about any sane application? Bind, DHCP, SSH ... and on and on and on.