There is no standardization of DRM going on. What is being standardized is just a plugin scheme, like the one allowing Flash to be embedded inside web browsers. Once hackers crack, say, Google's "SecurChrome browser", sites will be able switch to Adobe's "Bolt plugin" or Apple's "iLockedDown platform", or just require customers to upgrade to "SecurChrome 2.1 SP3" which will be using a new encryption method or will implement a new kind of surveillance.
The same thing could be said for the whole internet. Why put "art" on a separate plane? Everything that you can access on the internet has value. Books, news articles, scientific papers, software applications. Yet the internet has been developed to be open, and it was a success.
People who want closed communication channels can already build them, and the onus is on them to specifiy and maintain them outside the open web.
EME will not give "people that prefer to pay for exclusive non-corporate art a standard way to get that", because it doesn't specify a real encryption method. It's just a standard hook allowing portions of web pages to be decrypted by non-standard binary plugins. In fact, besides Google and Apple, it's being proposed by Adobe. They don't want us to get rid of flash, they want, respectively, one more reason to put "works only with Chrome" banners, a way to put the lockdown of flash into iPhones without having to implement the whole plugin, and a way to keep selling binary plugins without having the burden of having to maintain a presentation layer that with the advent of HTML5 has become less attractive.
Not only it's going to close the web, it's going to both close it AND fragment it. EME will bring us in a worse situation than "Netscape vs Internet Explorer" in the 90s, because EME is NOT a fully-specified standard, but rather an open-ended framework allowing the browser to load incompatible, binary-only plugins able to decrypt arbitrary fragments of web pages (not only videos). So for instance you'll have sites that work with Chrome, and others that require Adobe's decryption plugin. And this incompatibility hell will not be solved by open source, as Firefox and WebKit did the last time the web was broken, because DRM by definition can NOT be implemented by open source software.
Yeah, the Cuban government could plant a few Mickey Mouse cartoons inside those USB sticks, wait for them to spread, then call some USA corporation and have them arrest, extradite and sue the owners for hundreds of thousands of dollars or the equivalent in jail-time.
Propaganda is meant for the masses, not for the elite. Moreover there are different dialects of the Arab language, and sometimes even in officially Arab-speaking countries the less cultured have little love for Modern Standard Arabic.
About Latin in the Catholic Church: until the use of Latin for the liturgy was abolished in the 60s, regular people living in catholic countries knew Latin just as much as was needed to memorise utterances and prayers, and would never dream (nor be able) to watch a TV program in Latin.
Can you explain your point a bit better? I mean, in which of those countries can I have a better expectation not to get killed? Which country is better for me if I am a woman? Which one is better if I want to set up an enterprise? The country where I have the best chances to get cured should I fall ill? Where can I expect my kids to get a better education? The one where it's less probable to step on a mine while traveling?
Didn't the USA degrade GPS' quality for civilian use, for very similar reasons, until the 2000s? I suppose that using "highly sensitive" GPS devices, i.e. those able to make use of the not degraded signal, was illegal in the USA as well back then. Of course as a consumer of GPS-based services I much prefer the latter position of the USA government over the subject, but I find nothing ridicule in the fact that the Chinese government haven't changed their mind yet, so I don't understand the sarcastic tone used in the article.
Remember when the US generals officially threatend to "shoot down" the EU's Galileo satellites if the system was made to work on US soil without giving the US government the ability to render it unusable? Now that was a perplexing statement, since I remember that a GPS expert explained here on slashdot that "shooting down" a GPS satellite isn't even feasible with current technology.
People always say this, but they never give any reasonable examples.
The first examples that come into my mind?
Connect an Android device to the USB port of a Mac and see that it doesn't recognise its network interface because it's based on RNDIS which is a Microsoft protocol.
Make a change to the Darwin kernel using the source code released by Apple and see that it's impossible to obtain a really bootable image out of it.
You are aware that a Mac is still a general purpose computing device, right? It has a CPU, RAM, storage.
Yes but if you install Linux or Windows on it I no longer count it as a Mac!
Perhaps you have to fight with the security model at times, but that's true in Linux too.
True, and if the beautiful day can be seen by its morning, it will only get worse in Linux in the years to come...
Some people don't feel the need for freedom as long as they're not bitten by the lack of it, that's why many people actually don't dislike living under dictatorships of varying kind and degree.
On Linux, things are somewhat easy when you walk on the paved road, then they can become somewhat troublesome when you step out of it.
On the Mac, things are very easy when you do what the OS designers planned you to do, but then they can become impossible when you want to do something else.
Oh and by the way, speaking of children and unicorns, certain tools one might buy at a computer shop could really have been built by underage workers being exploited in sweatshops. With globalization, it happens (at least Apple take measures when they find that it happened to their products).
I recommend you learning the difference between personal data and anonymized statistical information. Hint, if you don't see someone's name, government identification number(ssn/etc), email address, home address, etc, then it is not personal information.
That's a very narrow definition of "personal information". By your logic, if I took your personal mail, blanketed away your "name, government identification number(ssn/etc), email address, home address" and posted it all on the internet, I wouldn't be violating your privacy.
Streetview affair? Unless I'm missing something, they collected public information, no different that collecting public records and compiling the information in an easy to use way.
You're missing something. They stored fragments of private wifi traffic, and lied - in good faith - when asked about what they were doing, and whether they had destroyed the accidentally collected data.
We may share aggregated, non-personally identifiable information publicly and with our partners – like publishers, advertisers or connected sites. For example, we may share information publicly to show trends about the general use of our services.
So the key is what they consider "non-personally identifiable information":
This is information that is recorded about users so that it no longer reflects or references an individually identifiable user.
I found that I did want google maps and google navigation to remember the last locations I had searched.
Then *your phone* should keep a history of your latest searches. Which could be even stored on a cloud server, in encrypted form. There's no need for Google/Facebook/Bing/Whatnot and their customers to know your data in order for you to get that convenience.
But the branding and design of the Play Store leads me to believe that I buy apps from Google, not from the application developer. When I buy a package in a shop, I don't give my full name and street address to the manufacturer of that package, I give them to the shop owner, so it's reasonable for the average user to assume that the same would happen in a virtual shop.
When I buy from the Play Store, I implicitly trust Google, not "H4ckerJo3 development ltd". At the very least Google should tell me, when I buy, that they're transfering extremely personal information to an obscure developer that I might have no way to know, let alone trust. They probably did state that in some EULA written in legalese that many people couldn't understand even if they tried to - so from a legal standpoint they're certainly safe. But from an ethical point of view, it's debatable.
As some economists often do, you're assuming that evolution leads to the survival of the best. It doesn't, it leads to the survival of the fittest. For instance, physically strong people who are very stupid but also very prolific might prove to be more successfull from an evolutionary standpoint than very intelligent individuals with a weak constitution who leave scarce or no offspring.
Re:still supports 32-bit Intel binaries
on
Linux 3.8 Released
·
· Score: 4, Informative
Isn't it normal for any processor to have errata? There are currently 95 bugs listed for Ivy Bridge on Intel's site. There are 120 for Sandy Bridge.
Citation? How about looking at the crop yields from the Iowa farm my great-grandfather homesteaded. The citation is my brother's income tax return, he manages the farm now. Or the yields being produced by the tenants on my father-in-law's Minnesota farm. Next question?
How about some statistics instead of anecdotal experience? In order to show how GM crops improve yelds, Monsanto themselves provide statistics on their own web site; we can be certain that the ones they've chosen aren't biased against GM seeds. Still, for GM corn, they only tout a 5% average increase in 10 years in developed countries "except Australia" (however, in that case they don't quantify the negative yeld impact, who knows why).
For me, being completely ignorant about agriculture, hearing "GM seeds improve yelds a lot" is a kind of information. Hearing "GM seeds improved corn yelds in developed countries by about 0.5% per year, except in Australia where they had a negative impact over yelds", and reading that on the very web site of Monsanto, is a richer information.
I agree. Like most words in Oldspeak, “dangerous” has a precise meaning and the author is redefining it.
Users who actively enable do not track know what it is and how it works. If they don’t know, then they’re not more in “danger” than if they did, because the only actualisation of that danger, i.e. getting spied by Google et al, lies still there unchanged whether do not track is offered and enabled or not.
Would the author claim that, say, air bags give a false sense of security to drivers and therefore should be abolished?
This standard merely describes a plugin system that incompatible, binary-only, third-party plugins (CDM) will hook into. In fact, besides other champions such as Google and Apple, this standard is being pushed by Adobe, the developers of Flash.
So not much will change from the mosaic of "shitty proprietary standards" that we have today. It's just that the developers of those plugins don't want to handle media presentation anymore, and with this standard they can only care about data encryption and user surveillance. I'm afraid we can't even dream of seeing CDM plugins on Linux.
and our browsers might be a bit more stable because we'll have more competent people getting the edges of the DRM right
You'll still need binary plugins to interface with your browser, because this draft specification deliberately only covers the "glue", not the DRM mechanism itself. DRM can't be implemented in open source. You'll have to download and install different, incompatible binary plugins from (say) Google or Adobe in order to view the media offered by Google sites or Adobe sites. Of course, you'll have to be running on one of the platforms supported by the plugins, otherwise no content for you.
I, for one, will start with the boycott of any browser coming from one of the companies involved in this poisoning of the Web - on my computers and on those that people trust me to maintain.
Lets focus on the specifics of EME. "DRM Bad" is a gross oversimplification.
Interesting, let's see.
I think we can all agree that HTTPS is a good idea - it lets us securely communicate with our bank etc.
Indeed, that's because HTTPS has nothing to do with DRM, besides the fact that both use encryption. HTTPS serves the user, and the user has full control over it.
What if our bank wants to send us a video message, or we want to watch one of our home videos we've stored on a cloud server? Well, we could use HTTPS for that. But HTTPS requires the server to encrypt the content as we're streaming it... that's probably OK for those scenarios, since there won't be more than one person downloading the same video at once.
Exactly. So far, no uses for DRM. Let's hear further.
Now suppose a video store offers to sell us a video. Of course we'd use HTTPS to send our credit card details to prevent them getting intercepted by hackers. The video store might let us download or stream the video over HTTPS. But HTTPS requires the server to encrypt the content as we're streaming it, and if lots of people are streaming the same video the server will be very busy. What's more, since the server has to send differently-encrypted data to different people, they can't use a CDN to spread the load (unless they load their private key into all the CDN boxes, which would be insecure). The solution is EME with the "Clear Key" encryption: the store encrypts the video file once, and tells us to stream the encrypted video file over plain HTTP from their CDN. They then send us the key over HTTPS. The browser uses that key to decrypt the file. Note that there's no "DRM" anti-consumer stuff here - the consumer's web browser has both the key and the encrypted data, and could save those if they wanted to. It's just protecting the data as it flows over the network, like HTTPS does.
What you described is no DRM. The server is giving the user full access to the media, by giving the key to him. They could as well store the media inside a password-protected zip file, serve it over plain HTTP, then send the password for that file to the user. It would have achieved the same level of security. The point is that no media company will use such a model for distribution, because a single user could give away his password to all the other users, making the system ineffective. In fact, no user's right is restricted by this model, there's no "black box" software or hardware involved, there are no encryption keys ureachable to the user, there's no personal information of the user stored inside the media. This is not DRM and this is not what people are afraid of.
Now, EME does also have hooks for a full DRM system. It doesn't specify a full DRM system - it's just hooks so your browser could include a DRM system if it wanted to. Rather than getting the clear key over HTTPS, the browser can get some encrypted data that's passed to the DRM system. The DRM system then does it's thing and decrypts the video, presumably applying copy protection as it does.
So after you've talked so much about completely irrelevant topics, you dismiss the actual problem with three lines and no argumentation. You're actually worsening my concerns, because not only you're telling us that EME will force all content consumers on the web to implement DRM and pay for its implementation and its computational overhead, but also you're giving us reason to believe that the specification will be incomplete, and every content publisher will be free to implement or license a different digital restriction management system based on those "hooks", forcing the users to choose what content they want to access, or to implement or license all of the competing systems, as is already happening with DRM systems for digital television broadcasting.
Slashdot Mirror
There is no standardization of DRM going on. What is being standardized is just a plugin scheme, like the one allowing Flash to be embedded inside web browsers. Once hackers crack, say, Google's "SecurChrome browser", sites will be able switch to Adobe's "Bolt plugin" or Apple's "iLockedDown platform", or just require customers to upgrade to "SecurChrome 2.1 SP3" which will be using a new encryption method or will implement a new kind of surveillance.
People who want closed communication channels can already build them, and the onus is on them to specifiy and maintain them outside the open web.
EME will not give "people that prefer to pay for exclusive non-corporate art a standard way to get that", because it doesn't specify a real encryption method. It's just a standard hook allowing portions of web pages to be decrypted by non-standard binary plugins. In fact, besides Google and Apple, it's being proposed by Adobe. They don't want us to get rid of flash, they want, respectively, one more reason to put "works only with Chrome" banners, a way to put the lockdown of flash into iPhones without having to implement the whole plugin, and a way to keep selling binary plugins without having the burden of having to maintain a presentation layer that with the advent of HTML5 has become less attractive.
Not only it's going to close the web, it's going to both close it AND fragment it. EME will bring us in a worse situation than "Netscape vs Internet Explorer" in the 90s, because EME is NOT a fully-specified standard, but rather an open-ended framework allowing the browser to load incompatible, binary-only plugins able to decrypt arbitrary fragments of web pages (not only videos). So for instance you'll have sites that work with Chrome, and others that require Adobe's decryption plugin. And this incompatibility hell will not be solved by open source, as Firefox and WebKit did the last time the web was broken, because DRM by definition can NOT be implemented by open source software.
Yeah, the Cuban government could plant a few Mickey Mouse cartoons inside those USB sticks, wait for them to spread, then call some USA corporation and have them arrest, extradite and sue the owners for hundreds of thousands of dollars or the equivalent in jail-time.
About Latin in the Catholic Church: until the use of Latin for the liturgy was abolished in the 60s, regular people living in catholic countries knew Latin just as much as was needed to memorise utterances and prayers, and would never dream (nor be able) to watch a TV program in Latin.
Can you explain your point a bit better? I mean, in which of those countries can I have a better expectation not to get killed? Which country is better for me if I am a woman? Which one is better if I want to set up an enterprise? The country where I have the best chances to get cured should I fall ill? Where can I expect my kids to get a better education? The one where it's less probable to step on a mine while traveling?
Remember when the US generals officially threatend to "shoot down" the EU's Galileo satellites if the system was made to work on US soil without giving the US government the ability to render it unusable? Now that was a perplexing statement, since I remember that a GPS expert explained here on slashdot that "shooting down" a GPS satellite isn't even feasible with current technology.
People always say this, but they never give any reasonable examples.
The first examples that come into my mind?
Connect an Android device to the USB port of a Mac and see that it doesn't recognise its network interface because it's based on RNDIS which is a Microsoft protocol.
Make a change to the Darwin kernel using the source code released by Apple and see that it's impossible to obtain a really bootable image out of it.
You are aware that a Mac is still a general purpose computing device, right? It has a CPU, RAM, storage.
Yes but if you install Linux or Windows on it I no longer count it as a Mac!
Perhaps you have to fight with the security model at times, but that's true in Linux too.
True, and if the beautiful day can be seen by its morning, it will only get worse in Linux in the years to come...
On Linux, things are somewhat easy when you walk on the paved road, then they can become somewhat troublesome when you step out of it.
On the Mac, things are very easy when you do what the OS designers planned you to do, but then they can become impossible when you want to do something else.
Oh and by the way, speaking of children and unicorns, certain tools one might buy at a computer shop could really have been built by underage workers being exploited in sweatshops. With globalization, it happens (at least Apple take measures when they find that it happened to their products).
I recommend you learning the difference between personal data and anonymized statistical information. Hint, if you don't see someone's name, government identification number(ssn/etc), email address, home address, etc, then it is not personal information.
That's a very narrow definition of "personal information". By your logic, if I took your personal mail, blanketed away your "name, government identification number(ssn/etc), email address, home address" and posted it all on the internet, I wouldn't be violating your privacy.
Streetview affair? Unless I'm missing something, they collected public information, no different that collecting public records and compiling the information in an easy to use way.
You're missing something. They stored fragments of private wifi traffic, and lied - in good faith - when asked about what they were doing, and whether they had destroyed the accidentally collected data.
So the key is what they consider "non-personally identifiable information":
Yes, and they shouldn't have the key.
I found that I did want google maps and google navigation to remember the last locations I had searched.
Then *your phone* should keep a history of your latest searches. Which could be even stored on a cloud server, in encrypted form. There's no need for Google/Facebook/Bing/Whatnot and their customers to know your data in order for you to get that convenience.
When I buy from the Play Store, I implicitly trust Google, not "H4ckerJo3 development ltd". At the very least Google should tell me, when I buy, that they're transfering extremely personal information to an obscure developer that I might have no way to know, let alone trust. They probably did state that in some EULA written in legalese that many people couldn't understand even if they tried to - so from a legal standpoint they're certainly safe. But from an ethical point of view, it's debatable.
Google does not sell personal information to third parties *ever*. They use that information to show targeted ads + search results. Period.
Are you sure?
http://www.google.com/analytics
And they have been pretty honest about that.
Their sincerity isn't to take for granted after the streetview affaire.
No, they also sell your information, in an anonymized form.
Yes, it was just an example I arbitrarily made up to be put against the class of the "smarter ones" as imagined upstream in the thread.
As some economists often do, you're assuming that evolution leads to the survival of the best. It doesn't, it leads to the survival of the fittest. For instance, physically strong people who are very stupid but also very prolific might prove to be more successfull from an evolutionary standpoint than very intelligent individuals with a weak constitution who leave scarce or no offspring.
Isn't it normal for any processor to have errata? There are currently 95 bugs listed for Ivy Bridge on Intel's site. There are 120 for Sandy Bridge.
How about some statistics instead of anecdotal experience? In order to show how GM crops improve yelds, Monsanto themselves provide statistics on their own web site; we can be certain that the ones they've chosen aren't biased against GM seeds. Still, for GM corn, they only tout a 5% average increase in 10 years in developed countries "except Australia" (however, in that case they don't quantify the negative yeld impact, who knows why).
For me, being completely ignorant about agriculture, hearing "GM seeds improve yelds a lot" is a kind of information. Hearing "GM seeds improved corn yelds in developed countries by about 0.5% per year, except in Australia where they had a negative impact over yelds", and reading that on the very web site of Monsanto, is a richer information.
Users who actively enable do not track know what it is and how it works. If they don’t know, then they’re not more in “danger” than if they did, because the only actualisation of that danger, i.e. getting spied by Google et al, lies still there unchanged whether do not track is offered and enabled or not.
Would the author claim that, say, air bags give a false sense of security to drivers and therefore should be abolished?
So not much will change from the mosaic of "shitty proprietary standards" that we have today. It's just that the developers of those plugins don't want to handle media presentation anymore, and with this standard they can only care about data encryption and user surveillance. I'm afraid we can't even dream of seeing CDM plugins on Linux.
Read for example the concerns of this person from Mozilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944
and our browsers might be a bit more stable because we'll have more competent people getting the edges of the DRM right
You'll still need binary plugins to interface with your browser, because this draft specification deliberately only covers the "glue", not the DRM mechanism itself. DRM can't be implemented in open source. You'll have to download and install different, incompatible binary plugins from (say) Google or Adobe in order to view the media offered by Google sites or Adobe sites. Of course, you'll have to be running on one of the platforms supported by the plugins, otherwise no content for you.
I, for one, will start with the boycott of any browser coming from one of the companies involved in this poisoning of the Web - on my computers and on those that people trust me to maintain.
Lets focus on the specifics of EME. "DRM Bad" is a gross oversimplification.
Interesting, let's see.
I think we can all agree that HTTPS is a good idea - it lets us securely communicate with our bank etc.
Indeed, that's because HTTPS has nothing to do with DRM, besides the fact that both use encryption. HTTPS serves the user, and the user has full control over it.
What if our bank wants to send us a video message, or we want to watch one of our home videos we've stored on a cloud server? Well, we could use HTTPS for that. But HTTPS requires the server to encrypt the content as we're streaming it... that's probably OK for those scenarios, since there won't be more than one person downloading the same video at once.
Exactly. So far, no uses for DRM. Let's hear further.
Now suppose a video store offers to sell us a video. Of course we'd use HTTPS to send our credit card details to prevent them getting intercepted by hackers. The video store might let us download or stream the video over HTTPS. But HTTPS requires the server to encrypt the content as we're streaming it, and if lots of people are streaming the same video the server will be very busy. What's more, since the server has to send differently-encrypted data to different people, they can't use a CDN to spread the load (unless they load their private key into all the CDN boxes, which would be insecure). The solution is EME with the "Clear Key" encryption: the store encrypts the video file once, and tells us to stream the encrypted video file over plain HTTP from their CDN. They then send us the key over HTTPS. The browser uses that key to decrypt the file. Note that there's no "DRM" anti-consumer stuff here - the consumer's web browser has both the key and the encrypted data, and could save those if they wanted to. It's just protecting the data as it flows over the network, like HTTPS does.
What you described is no DRM. The server is giving the user full access to the media, by giving the key to him. They could as well store the media inside a password-protected zip file, serve it over plain HTTP, then send the password for that file to the user. It would have achieved the same level of security. The point is that no media company will use such a model for distribution, because a single user could give away his password to all the other users, making the system ineffective. In fact, no user's right is restricted by this model, there's no "black box" software or hardware involved, there are no encryption keys ureachable to the user, there's no personal information of the user stored inside the media. This is not DRM and this is not what people are afraid of.
Now, EME does also have hooks for a full DRM system. It doesn't specify a full DRM system - it's just hooks so your browser could include a DRM system if it wanted to. Rather than getting the clear key over HTTPS, the browser can get some encrypted data that's passed to the DRM system. The DRM system then does it's thing and decrypts the video, presumably applying copy protection as it does.
So after you've talked so much about completely irrelevant topics, you dismiss the actual problem with three lines and no argumentation. You're actually worsening my concerns, because not only you're telling us that EME will force all content consumers on the web to implement DRM and pay for its implementation and its computational overhead, but also you're giving us reason to believe that the specification will be incomplete, and every content publisher will be free to implement or license a different digital restriction management system based on those "hooks", forcing the users to choose what content they want to access, or to implement or license all of the competing systems, as is already happening with DRM systems for digital television broadcasting.
The sort of companies who are going