Streaming a channel using high compression video and audio codec at CIF resolution will get the data rate down to about 500 Kb/s. Assuming that every bit is used for streaming, that will be 10 channels maximum to be shared between those among the 300 passengers who has the laptop/PDA/phone.
I can see it now, air rage over bandwidth hogs.:-)
From the viewpoint of someone who created the trust model for the MPEG IPMP framework, Dr. Felten comments are correct though he does not address the fundamental failure of DRM. The *AA of the world are trying to use technology to solve what is fundamentally social and economic failings.
As for DRM technologies, no technology can withstand attack indefinitely, Palladium not withstanding. The question really boils down to who is attacking, how much time are they willing to spend on it and what resources they have access to.
If the answer to the above question is professionals with lots of time and resources, any DRM system will be cracked.
While I agree with Dr. Spafford points to a certain extent, I would be very surprised if there are 10 organizations in the world who knows how to cross the abyss between specification and testing on an large scale in industry or government.
Academics loves formal methods and industry avoids it like a plague for the most part because there are no perceived benefit.
Grunt: I want to formally specify this program so we can do proof of correctness later". Manager: "Does this mean the program will be bug free and, by the way, how long will take do do this formal specification and all that proof stuff?"
And the discussion degenerates from there...
Formal specification is very hard for any non-trivial sized programs (say 250KLOC+) and if anyone says otherwise, they are full of BS. OpenSource projects by their nature do not lend themselves to formal specification and testing. Does that means they are more secure than close source or vice versa? No, of course not. It all comes down to the quality of:
the requirement
the design
implementation
the testing
For OpenSource projects, the middle 2 is usually done quite well (or someone else will redo it for you:-) but the requirements changes constantly as someone else enhance the S/W to do that other thing. Testing is uneven as normally there are no formal test plans.
6 years ago, in a different life, I started a project to close the gulf between specification and testing on real world sized programs. That work continues and may one day bear fruit. See http://www.ispras.ru/~RedVerst/ or the North American mirror at http://207.236.16.49/RedVerst/. The work is brutal both theoretically and practically and required far more brain cycles than what my poor little brain can generate. I am just glad I am not doing it.:-)
Slashdot Mirror
Streaming a channel using high compression video and audio codec at CIF resolution will get the data rate down to about 500 Kb/s. Assuming that every bit is used for streaming, that will be 10 channels maximum to be shared between those among the 300 passengers who has the laptop/PDA/phone.
:-)
I can see it now, air rage over bandwidth hogs.
From the viewpoint of someone who created the trust model for the MPEG IPMP framework, Dr. Felten comments are correct though he does not address the fundamental failure of DRM. The *AA of the world are trying to use technology to solve what is fundamentally social and economic failings.
As for DRM technologies, no technology can withstand attack indefinitely, Palladium not withstanding. The question really boils down to who is attacking, how much time are they willing to spend on it and what resources they have access to.
If the answer to the above question is professionals with lots of time and resources, any DRM system will be cracked.
Academics loves formal methods and industry avoids it like a plague for the most part because there are no perceived benefit.
Grunt: I want to formally specify this program so we can do proof of correctness later".
Manager: "Does this mean the program will be bug free and, by the way, how long will take do do this formal specification and all that proof stuff?"
And the discussion degenerates from there...
Formal specification is very hard for any non-trivial sized programs (say 250KLOC+) and if anyone says otherwise, they are full of BS. OpenSource projects by their nature do not lend themselves to formal specification and testing. Does that means they are more secure than close source or vice versa? No, of course not. It all comes down to the quality of:
the requirement
the design
implementation
the testing
:-) but the requirements changes constantly as someone else enhance the S/W to do that other thing. Testing is uneven as normally there are no formal test plans.
:-)
For OpenSource projects, the middle 2 is usually done quite well (or someone else will redo it for you
6 years ago, in a different life, I started a project to close the gulf between specification and testing on real world sized programs. That work continues and may one day bear fruit. See http://www.ispras.ru/~RedVerst/ or the North American mirror at http://207.236.16.49/RedVerst/. The work is brutal both theoretically and practically and required far more brain cycles than what my poor little brain can generate. I am just glad I am not doing it.
Socialist provincial goverment vs unbridled capitalism (which is what M$ is after and accustomed to)
C$ vs US$ - Would M$ employee be willing to be paid in C$ or would they demand to be paid in US$?
Different tax scheme (rates, rules, laws)
Getting 20K people to uproot their family
Immediate housing crunch in Vancouver and surroundings - Housing prices would soar and the other ridents of the area would rebel
Long arm of US Law
And what would M$ gain from all this?