The key distribution system can be secured, since it resides on the server side and the server is in the hands of someone trusted by the rights owner. The key itself cannot be secured, since it is needed on the end user's machine to unlock the content. It could be hidden within the client, but that could be cracked. This comes down to the fundamental problem of DRM: you cannot both let the end user have the content for the purpose of playing it and not have the content for the purpose of copying it.
But looking at it from a security point of view is the wrong approach: there is no direct harm from unauthorized people accessing the content; these are not secret documents. The harm comes from too many people deciding not to pay for it. The solution therefore is in influencing the decision to pay for the content.
The duplication equipment would be an additional expense and isolating and duplicating the marker DNA an additional skill set required for counterfeiting, so it is a deterrent even if it can be circumvented.
There is not enough information out there yet to say. I think a lot will depend on how well the client is written and how easy the payment procedure is.
Another question is whether they will insist on people using their client or open up the format for inclusion in third party media players etc.
When speaking of torrents, why download the "paywalled" version if the free one is right next to it?
I know I would opt for a paid version; albeit from a different channel. But I just don't see the current bunch of torrent users picking the paywalled version over a pirated. They're often (with exceptions naturally) people who don't care about the ethics and morality concerning intellectual property...
I don't think these bundles would be very popular on The Pirate Bay, but they could be distributed via the artist's own site or via a store/portal/search engine that only contains these bundles etc. Studies have shown that a lot of the big media consumers both pay and pirate. Of course there are people who will never pay for anything, but there are also a lot of people who will pay in the right circumstances.
In fact, some of them will go to great lengths defending their position by claiming it's really all just "data" and "information" which should be "free" to begin with, so the evil big corporations really should burn in hell for wanting money for it in the first place... ish.
A lot of people don't realize how much effort it takes to create something of decent quality, because they've never tried it themselves. As for opposing the megacorps, that sounds like an excuse to me. If you're really serious about undermining the power of the MPAA/RIAA, don't pirate their stuff, but buy from indies instead.
I welcome any initiative which has the potential to channel money to the artists. But this? I just don't see it.
I have no idea whether it will be successful. It does have some advantages: The peer-to-peer nature of BitTorrent means artists without a big budget can get their works distributed without having to pay for a lot of bandwidth. And if the unlocking works as I expect - buying a decryption key from a server - the reward for buying the content is immediately available, since the files are already on your harddisk.
True, but is that really a problem? DRM has, as far as I know, never been successful in preventing pirate versions from being posted. The goal should be that artists get paid, not to have zero piracy. Having an additional way to distribute content which includes payments to the artist will help, if it is convenient enough.
There is a cost to keeping the code in there, even if it's not supported. If interfaces change, the unsupported code can break the build. Finding things in the code, by reading or grep, becomes harder since there is more of it. Static code analysis might flag issues in the unsupported code. Bugs will probably be filed that they'll then have to close as WONTFIX.
Also the question is what purpose would be served by keeping unsupported code in the main repository. If it's not regularly updated and tested, it will be broken sooner or later. Canonical will have to maintain the code anyway, so there will be a separate repository somewhere that contains the working version of XMir support.
Canonical decided to write their own Mir display server instead of adopting the existing Wayland. They stated their reasons for doing so, but I'm not convinced they really had to start their own project instead of modifying Wayland.
It seems only fair to me that if Canonical wants to do their own thing, they'll have to put in the effort to maintain it. Because that is what this is about: Intel management decided that they're not going to pay their engineers to maintain code that benefits only Canonical.
It's not a dupe, it's a cognitive flexibility test. We're going to have a post like this once per day for two months and then they're going to analyze the trends in page views on the articles... Only to conclude that the number of people who even tries to read the article is statistically insignificant.
Had they bought code, knowing it was BSD this would never have been an issue.
But how do you know what is in the code if you don't examine it? It could still contain GPL-ed code, or code copied from a competitor by an industrial spy.
The outsourcing is what got them into trouble in the first place. They got both a binary and sources from their supplier and assumed that those two matched, without verifying that by doing the build themselves.
From a user interface perspective, I think it makes sense to pick as the default the value that most users would like it to be at. And while I have no research to back this up, I'm assuming most users would prefer not to be tracked.
I agree that it's inconsistent to complain about ads on unpaid content. However, advertising does not require tracking. The page that the ad is served on is in many cases already sufficient context to deliver a relevant ad.
I had relatively little problems burning even in those early days, but I had a SCSI burner, not an IDE or some proprietary sound card interface. The biggest challenge I faced was figuring out which brand of CD-R would be read by the largest range of CD-ROM drives. (Which was complicated by the fact that a lot of brands didn't actually manufacture their own CD-Rs and switched suppliers from time to time.)
The "Xbone" is a damaged brand at this point. The best case scenario Microsoft can hope for is roughly equal market share, if their damage control works wonders or if Sony makes mistakes as well. More likely, Xbox One will have a smaller market share than the PS4.
The hardware in the Xbox One and the PS4 is not all that different, and everything that is different seems to be to the advantage of the PS4 (faster RAM, more GPU stream units). While it would take some effort to support two different APIs, porting from Xbox One to PS4 would be relatively easy, as it wouldn't require changes to the content. Even if they have competition from cheaper indie games on the PS4, the extra sales are likely to outweigh the costs of porting.
Another reason to go exclusive is Microsoft paying the publishers for exclusivity. AAA game development is very expensive though and I doubt Microsoft will want to invest that kind of money on their third generation console. They could sell the first Xbox under cost to gain entry into a market, but the Xbox 360 did pretty well on its own merits (besides the red ring of death problems), so heavily sponsoring the Xbox One platform would be a step back. Also the announced price of $500 doesn't suggest Microsoft wants to subsidize the system.
So I don't see much incentive for publishers to make exclusive titles for the Xbox One.
That's the wrong question: instead of performing a dangerous operation only if the input doesn't look suspicious, you should not perform the dangerous operation at all. So if the input data is supposed to be an image, pass it to a function that can only process images. That way, if an attacker does manage to sneak in PHP code disguised as an image, it will just trigger an error condition instead of being executed.
Obviously you need to be pretty paranoid to believe that the NSA has corrupted the GNU toolchain in such a way that it inserts back doors in every OS kernel it compiles, that the debugger has code inserted in it to not display said OS code, etc, but it is technically possible.
If there was only one program that could display object files, it could be done. But any number of programs can display object files, including plain hex editors. If every single hex editor would have been compromised, we would have noticed by now. And a compiler that can detect "oh, this code is a hex editor, I'd better patch it to make it hide the nasty stuff when it's run" is way beyond what can currently be created, certainly not running fast enough on an ordinary PC to avoid detection.
Besides, it's not the question of whether the NSA can access your files if they consider it their highest priority. The problem is that if there is an easy, low-cost way to access your files, an individual rogue agent might do it and hand your files to your competitor (a favor for a friend or for a little extra cash) without the rest of the NSA even knowing about it, or finding out only after the fact.
If an encrypted file system is mounted, the key is somewhere in memory. If it's mounted in a VM and you have access to the host machine, you can easily create a snapshot of the VM's memory. I don't think it would be all that much work for a person familiar with the internals of the OS kernel in question to figure out where the key is stored in memory. Another thing they could do with a VM snapshot is patch the authentication functions, so any login is accepted. There are countless ways of gaining entry into a system if you can freely examine and change its memory.
You assume this would be too much work, but while the research to find a successful attack is non-trivial, repeating that attack is not that difficult and could be fully automated for popular OSes.
Handing over the key to the attacker and hoping it's well hidden enough that it won't be extracted is pretty much what DRM does. And this is not even as obfuscated as the average DRM, since most operating systems are either open source or at least offer their source code for inspection.
I think I would have been sleep deprived as well if I had had a portable computer or game console as a child. Without those to pass the time when I wasn't ready to sleep, I used to read books, but somehow reading a book doesn't make you less sleepy. I mean, if you're really into the story you can stay awake for just one more chapter, but it takes some effort. With computers, it's very easy to lose track of time. Maybe it's the light coming from the monitor or maybe it's the increased interaction, but there is a difference in my experience.
Assuming generic medium skilled German IT guy's fully burdened cost is $168,000 USD/yr and that this level of effort will require a staffing change (both very good assumptions)
Let's say this medium skilled IT guy gets a €3000/month salary, that's €36,000/year. There will be other costs, but it won't come anywhere near the number you assumed. Also, dealing with malware is a standard task when managing Windows desktop PCs, no matter whether you blame it on market share or on Microsoft. So if it requires a staffing change, then they didn't have the right staff to begin with.
Assume 44 usable weeks a year, or 220 useable days, that's roughly 1 machine a day.
An admin responsible for over 100 desktops should have set up an infrastructure for re-imaging so that it doesn't take 1 day per machine. It's not exactly zero effort like the GP said: you'll still have to warn people that anything they saved on the local hard disk will be lost, for example, but the required effort is in the order of days, not months.
I wonder where that huge cost estimate came from. Did they need justification to buy the new PCs that they wanted for a while but couldn't get the budget for? Was someone really not looking forward to cleaning the PCs and therefore inflated the cost of doing so? Was it just a made-up number that no-one looked at critically? Because it sounds unlikely to me that the actual costs would be that high.
Slashdot Mirror
The key distribution system can be secured, since it resides on the server side and the server is in the hands of someone trusted by the rights owner. The key itself cannot be secured, since it is needed on the end user's machine to unlock the content. It could be hidden within the client, but that could be cracked. This comes down to the fundamental problem of DRM: you cannot both let the end user have the content for the purpose of playing it and not have the content for the purpose of copying it.
But looking at it from a security point of view is the wrong approach: there is no direct harm from unauthorized people accessing the content; these are not secret documents. The harm comes from too many people deciding not to pay for it. The solution therefore is in influencing the decision to pay for the content.
The duplication equipment would be an additional expense and isolating and duplicating the marker DNA an additional skill set required for counterfeiting, so it is a deterrent even if it can be circumvented.
Question is: is it convenient enough?
There is not enough information out there yet to say. I think a lot will depend on how well the client is written and how easy the payment procedure is.
Another question is whether they will insist on people using their client or open up the format for inclusion in third party media players etc.
When speaking of torrents, why download the "paywalled" version if the free one is right next to it?
I know I would opt for a paid version; albeit from a different channel. But I just don't see the current bunch of torrent users picking the paywalled version over a pirated. They're often (with exceptions naturally) people who don't care about the ethics and morality concerning intellectual property...
I don't think these bundles would be very popular on The Pirate Bay, but they could be distributed via the artist's own site or via a store/portal/search engine that only contains these bundles etc. Studies have shown that a lot of the big media consumers both pay and pirate. Of course there are people who will never pay for anything, but there are also a lot of people who will pay in the right circumstances.
In fact, some of them will go to great lengths defending their position by claiming it's really all just "data" and "information" which should be "free" to begin with, so the evil big corporations really should burn in hell for wanting money for it in the first place ... ish.
A lot of people don't realize how much effort it takes to create something of decent quality, because they've never tried it themselves. As for opposing the megacorps, that sounds like an excuse to me. If you're really serious about undermining the power of the MPAA/RIAA, don't pirate their stuff, but buy from indies instead.
I welcome any initiative which has the potential to channel money to the artists. But this? I just don't see it.
I have no idea whether it will be successful. It does have some advantages: The peer-to-peer nature of BitTorrent means artists without a big budget can get their works distributed without having to pay for a lot of bandwidth. And if the unlocking works as I expect - buying a decryption key from a server - the reward for buying the content is immediately available, since the files are already on your harddisk.
True, but is that really a problem? DRM has, as far as I know, never been successful in preventing pirate versions from being posted. The goal should be that artists get paid, not to have zero piracy. Having an additional way to distribute content which includes payments to the artist will help, if it is convenient enough.
Looking at the logo on their home page, I think it's pronounced "bee hive".
The "evil bit" is from the mentioned RFC 3514.
There is a cost to keeping the code in there, even if it's not supported. If interfaces change, the unsupported code can break the build. Finding things in the code, by reading or grep, becomes harder since there is more of it. Static code analysis might flag issues in the unsupported code. Bugs will probably be filed that they'll then have to close as WONTFIX.
Also the question is what purpose would be served by keeping unsupported code in the main repository. If it's not regularly updated and tested, it will be broken sooner or later. Canonical will have to maintain the code anyway, so there will be a separate repository somewhere that contains the working version of XMir support.
Canonical decided to write their own Mir display server instead of adopting the existing Wayland. They stated their reasons for doing so, but I'm not convinced they really had to start their own project instead of modifying Wayland.
It seems only fair to me that if Canonical wants to do their own thing, they'll have to put in the effort to maintain it. Because that is what this is about: Intel management decided that they're not going to pay their engineers to maintain code that benefits only Canonical.
From FTA:
but it wrote to its narrowband customers in June explaining its decision to terminate the service
It's not a dupe, it's a cognitive flexibility test. We're going to have a post like this once per day for two months and then they're going to analyze the trends in page views on the articles... Only to conclude that the number of people who even tries to read the article is statistically insignificant.
He does have a governess for a companion; it all fits the pattern.
If your work browser is configured to accept certificates from the proxy server, SSL might not give you privacy.
Had they bought code, knowing it was BSD this would never have been an issue.
But how do you know what is in the code if you don't examine it? It could still contain GPL-ed code, or code copied from a competitor by an industrial spy.
The outsourcing is what got them into trouble in the first place. They got both a binary and sources from their supplier and assumed that those two matched, without verifying that by doing the build themselves.
From a user interface perspective, I think it makes sense to pick as the default the value that most users would like it to be at. And while I have no research to back this up, I'm assuming most users would prefer not to be tracked.
I agree that it's inconsistent to complain about ads on unpaid content. However, advertising does not require tracking. The page that the ad is served on is in many cases already sufficient context to deliver a relevant ad.
I had relatively little problems burning even in those early days, but I had a SCSI burner, not an IDE or some proprietary sound card interface. The biggest challenge I faced was figuring out which brand of CD-R would be read by the largest range of CD-ROM drives. (Which was complicated by the fact that a lot of brands didn't actually manufacture their own CD-Rs and switched suppliers from time to time.)
The "Xbone" is a damaged brand at this point. The best case scenario Microsoft can hope for is roughly equal market share, if their damage control works wonders or if Sony makes mistakes as well. More likely, Xbox One will have a smaller market share than the PS4.
The hardware in the Xbox One and the PS4 is not all that different, and everything that is different seems to be to the advantage of the PS4 (faster RAM, more GPU stream units). While it would take some effort to support two different APIs, porting from Xbox One to PS4 would be relatively easy, as it wouldn't require changes to the content. Even if they have competition from cheaper indie games on the PS4, the extra sales are likely to outweigh the costs of porting.
Another reason to go exclusive is Microsoft paying the publishers for exclusivity. AAA game development is very expensive though and I doubt Microsoft will want to invest that kind of money on their third generation console. They could sell the first Xbox under cost to gain entry into a market, but the Xbox 360 did pretty well on its own merits (besides the red ring of death problems), so heavily sponsoring the Xbox One platform would be a step back. Also the announced price of $500 doesn't suggest Microsoft wants to subsidize the system.
So I don't see much incentive for publishers to make exclusive titles for the Xbox One.
That's the wrong question: instead of performing a dangerous operation only if the input doesn't look suspicious, you should not perform the dangerous operation at all. So if the input data is supposed to be an image, pass it to a function that can only process images. That way, if an attacker does manage to sneak in PHP code disguised as an image, it will just trigger an error condition instead of being executed.
Obviously you need to be pretty paranoid to believe that the NSA has corrupted the GNU toolchain in such a way that it inserts back doors in every OS kernel it compiles, that the debugger has code inserted in it to not display said OS code, etc, but it is technically possible.
If there was only one program that could display object files, it could be done. But any number of programs can display object files, including plain hex editors. If every single hex editor would have been compromised, we would have noticed by now. And a compiler that can detect "oh, this code is a hex editor, I'd better patch it to make it hide the nasty stuff when it's run" is way beyond what can currently be created, certainly not running fast enough on an ordinary PC to avoid detection.
Besides, it's not the question of whether the NSA can access your files if they consider it their highest priority. The problem is that if there is an easy, low-cost way to access your files, an individual rogue agent might do it and hand your files to your competitor (a favor for a friend or for a little extra cash) without the rest of the NSA even knowing about it, or finding out only after the fact.
If an encrypted file system is mounted, the key is somewhere in memory. If it's mounted in a VM and you have access to the host machine, you can easily create a snapshot of the VM's memory. I don't think it would be all that much work for a person familiar with the internals of the OS kernel in question to figure out where the key is stored in memory. Another thing they could do with a VM snapshot is patch the authentication functions, so any login is accepted. There are countless ways of gaining entry into a system if you can freely examine and change its memory.
You assume this would be too much work, but while the research to find a successful attack is non-trivial, repeating that attack is not that difficult and could be fully automated for popular OSes.
Handing over the key to the attacker and hoping it's well hidden enough that it won't be extracted is pretty much what DRM does. And this is not even as obfuscated as the average DRM, since most operating systems are either open source or at least offer their source code for inspection.
I am curious why you would volunteer to step into the lion's den.
Now we know what Slashdot editors do all day ;)
Obviously it must be the parents' fault.
I think I would have been sleep deprived as well if I had had a portable computer or game console as a child. Without those to pass the time when I wasn't ready to sleep, I used to read books, but somehow reading a book doesn't make you less sleepy. I mean, if you're really into the story you can stay awake for just one more chapter, but it takes some effort. With computers, it's very easy to lose track of time. Maybe it's the light coming from the monitor or maybe it's the increased interaction, but there is a difference in my experience.
Assuming generic medium skilled German IT guy's fully burdened cost is $168,000 USD/yr and that this level of effort will require a staffing change (both very good assumptions)
Let's say this medium skilled IT guy gets a €3000/month salary, that's €36,000/year. There will be other costs, but it won't come anywhere near the number you assumed. Also, dealing with malware is a standard task when managing Windows desktop PCs, no matter whether you blame it on market share or on Microsoft. So if it requires a staffing change, then they didn't have the right staff to begin with.
Assume 44 usable weeks a year, or 220 useable days, that's roughly 1 machine a day.
An admin responsible for over 100 desktops should have set up an infrastructure for re-imaging so that it doesn't take 1 day per machine. It's not exactly zero effort like the GP said: you'll still have to warn people that anything they saved on the local hard disk will be lost, for example, but the required effort is in the order of days, not months.
I wonder where that huge cost estimate came from. Did they need justification to buy the new PCs that they wanted for a while but couldn't get the budget for? Was someone really not looking forward to cleaning the PCs and therefore inflated the cost of doing so? Was it just a made-up number that no-one looked at critically? Because it sounds unlikely to me that the actual costs would be that high.