That's an awful suggestion for this purpose. Linode is great, but charges a fortune for unusually large storage/transfer needs. Their biggest Linode at the moment has only 800G of space and 2T of transfer (and 20G of memory) for $800/month. That's going to be way overkill on the memory and huge underkill on the storage and transfer, and would already blow the budget.
Totally agree, once you get into this type of scale, you want to buy your own servers and colo them.
For a random example (not an endorsement, I've never used them before), Pair has 10U of space with 5 mbit bandwidth for only $400/month. Throw in a 2U server (~$3,000) with 12x 2T 7200 RPM drives (12x ~$150) in RAID 6 for 20T of usable space. Double the drive cost if you want "enterprise" drives. Shop around and I'm sure you can get better deals, these are just ballpark figures. I have no idea what kind of IOPS you need out of your storage, but it's easy (and much cheaper) to adjust your hardware to suit your needs when you own it.
The only situation where I wouldn't recommend managing your own servers is if you simply don't have the relevant domain knowledge AND you have the money to waste on managed hosting (ie, time is more valuable than money).
If Javascript were compiled into machine code before being sent to the client, it would be exactly 0% more useful for security related purposes.
Wrong; machine code is much harder to reverse-engineer than source code or minified code. Not impossible by any means, but it raises the bar; security-through-obscurity really does work, and is better than nothing at all, though it's obviously not something to be relied on if you can help it.
You're right, I should clarify. If Javascript were compiled into machine code before being sent to the client, it would be even worse for security most of the time, because a false sense of security (source code obfuscation in this case) is often worse than none at all. It lulls people into making bad choices that they may not have otherwise made... "Hey, nobody will ever figure out my Javascript code, therefore I can cut my workload in half by only doing the client side validation and skipping the server side validation! Great!", or "Hey, since nobody can read my Javascript, I'll just send down the whole database with every request, it'll be so much faster that way!"
I would also point out that in this particular case, reading the Javascript (regardless of how easy or difficult that is) is rarely going to be the preferred way of exploiting the system when you could simply peek at the network stream and see what happens when you push buttons.
In actuality, Javascript (ran in the client's browser) is far from useless for anything security related. Say you're implementing a login page. The naive approach would be to have a login and password field and send that over the wire back to the server in plain text.
Ok, I guess we need to start defining what we mean by "security". What you're describing is a situation in which the server implicitly trusts the client, but doesn't trust anyone that may be in the middle snooping on the communication. What I was talking about in the context of this copy-protection stuff is a situation where the server does not trust the client, and wants to limit how the client uses information the server sends it.
No, I'm describing a situation where the server does not need to trust the client and the client does not need to trust the server (in the ideal case). The client *proves* itself every step of the way and visa versa. It should go without saying that the actual format of the data still needs to be rigorously validated after it is received and before it is used.
The only way to limit the way the client uses information you send it is to limit the information that you send it.
* I was looking at free shopping cart software a while ago and found one that was implemented entirely in Javascript. It was fast as hell of course, and very nice-looking, but the problem was that, being Javascript, it was trivial for anyone to make up any order they wanted and send it to your server. You'd either have to implement a bunch of logic on the server to make sure your orders are legitimate, or be sure to catch them manually (easy if your volume is extremely low, not if it's higher). The whole thing just looked like a bad idea because it was trusting the client so much.
You have to implement a bunch of logic on the server to validate the order no matter how you send it to the server. Whether you construct the shopping cart one item at a time (dumb page with a bunch of buttons that all do separate posts) or all at once (fancy Javascript page) matters very little if at all with regards to the complexity of validating the order as a whole. The reason why it doesn't matter is that regardless of how you hope the data gets to your server (users clicking buttons on your page in a browser), it can also come from sources you may not be hoping for (nefarious users constructing their own requests directly).
What does impact the complexity of the validation is the design of the data that you choose to send back to t
Javascript is absolutely useless for anything security-related, because you're required to give the source code for your algorithm to the very people you're trying to hide that from.
Wrong. Javascript (ran in the client's browser) is absolutely useless for anything security related, because you're trusting the client. If your algorithm requires that the algorithm not be known to be secure, then it is not secure.
If Javascript were compiled into machine code before being sent to the client, it would be exactly 0% more useful for security related purposes. The client is still free to send whatever they want back to the server, regardless of whether it's through their browser or not.
In actuality, Javascript (ran in the client's browser) is far from useless for anything security related. Say you're implementing a login page. The naive approach would be to have a login and password field and send that over the wire back to the server in plain text. It works, but anyone is free to snoop the credentials while they're on the wire (or, particularly, when they're on the lack of wires). One option would be to encrypt the traffic with SSL, but this isn't perfect (forged SSL certificates and MITM attacks, for example). Instead, you could use a challenge-response mechanism similar to what SSH uses which never actually sends the credentials (encrypted or otherwise) over the wire, yet still proves to the server that the client is who they claim to be (and additionally proves to the client that the server is who they claim to be, or at least already knows their credentials). The algorithms for this are well known and can easily be implemented in Javascript, yet would provide a login page that is substantially more secure than the typical approach (with or without SSL).
These people just don't get it: software DRM simply doesn't work.
Hardware DRM doesn't work either. The fundamental problem with DRM is that you're giving a person a locked box and the key to that box, but then asking them (and rather rudely, in the case of DRM) to only use that key once. DRM cannot work as big content wishes it would, and anyone who tells you otherwise is a fool or a liar.
But this is exactly like that. The PC can run any number of operating systems.
Don't worry: 'Secure Boot' solves that problem.
Snide remarks aside, "Secure Boot" as implemented in EFI is not an effective DRM mechanism (moreso than most DRM, there are major technical problems with it). However, keep saying that and you'll end up with laws backing it up.
Exactly. You don't expect to buy a car and return the steering wheel do you?
No, I expect to buy a car and not find that every model from every brand comes with a dead body painstakingly sewn to the back seat as a mandatory option.
In fact, say I wanted to break into your house, I may have seen you use a physical key to open the front door and walk in and I may have even memorized the pattern of teeth on the key, but it does me no good if I don't have a key of my own to open the door with. There is certainly no obscurity in that security.
Once you have the pattern, you no longer need a key of your own - you just go and get one manufactured.
You contradict yourself. If you didn't need a key why would you go get one made? Furthermore, what ceases to be obscured through the process of taking your knowledge of the key's teeth and having a replica made? (Hint: nothing)
Rule #1: There is no such thing as 100% secure. Even 100% bug-free cannot be considered 100% secure.
There's also no such thing as 100% bug-free.
Rule #3: All security is ultimately "security through obscurity."
While in the strictest sense, this may not be untrue, to phrase it that way is extremely dishonest. An encryption algorithm that relies on the secrecy of the algorithm is totally worthless (security by obscurity), whereas an encryption algorithm that relies on the secrecy of the keys used for encryption is quite useful (not security by obscurity in the normal sense).
In fact, if you want to be pedantic about it, the relevant definition for obscure is...
not readily understood or clearly expressed; also : mysterious [1]
Which is about understanding and not so much about knowledge. I may understand that I need a username and password to log into your system, just because I don't know what the username or password is doesn't make it security by obscurity. In fact, say I wanted to break into your house, I may have seen you use a physical key to open the front door and walk in and I may have even memorized the pattern of teeth on the key, but it does me no good if I don't have a key of my own to open the door with. There is certainly no obscurity in that security.
If you're going to go ahead and say that all security is "security through obscurity", then you may as well make the next logical step of not implementing any of it.
Now as to practicality - you fit 5 family members, 3 tents, inflatable boat, cooler and 3 days worth of food and water for a camping trip, or bring an Ikea dining room set from the store in your sedan, I dare you.
Already brought the Ikea dining room set home in my compact sedan, thanks. 8 person table with 6 chairs. Need more room? Buy a minivan.
Bzzt! Sorry, death barges are many things, but practical isn't one of them. Unsafe, gas guzzling, underperforming, overweight and overpriced, yes, certainly. But practical? No.
Multiplayer games also benefit greatly from network effects. Nobody would play WoW if they were the only one on the server.
If you don't have a 9 figure marketing budget, you're probably struggling to get more players, and as mentioned already, most multiplayer games aren't fun without a lot of other players. So keeping that in mind, why would you go and shoot yourself in the foot by turning away 90% (or probably more) of your potential users by requiring payment up front?
For example, Game! is free to play and has been played by thousands of people, it also has a marketing budget of $0. I can only imagine if I'd required payment up front it'd probably have been played by dozens or maybe hundreds instead. That's a pretty big difference.
Unsurprisingly, people have been conditioned to expect things for free on the Internet. Making the jump from free to a penny is much larger than the jump from a penny to $10 or probably even $100. People will spend $5 on a latte every day and think nothing of it, because nobody is giving away free lattes, but ask them to spend $5 to access a website and they'll balk, after all, there's all those other websites that they can access for free.
It'd be fine if you could just order a foreign market car, while the US keeps its home market vehicles large, US-sized, powered and priced for the masses.
You realize that your own government is eviscerating the chances of "US-sized, powered and priced" cars ever coming back, right? See the new CAFE requirements for mileage.
PHP is like BASIC. In the right hands it can certainly produce just as readable and maintainable code as any other language, but the short learning curve to get to first base invites people with little or no discipline, or often enough, without any underpinnings at all, to write absolute garbage.
Would you you prefer that said people stumble their way through something more difficult like C, so that they can produce even worse code than they would have in PHP?
I had the opposite experience. When testing on some newer quad core servers (several years ago), I found that eaccelerator would cause segfaults in Apache that I couldn't pin down to anything in particular. It wasn't hardware either, because it happened on several machines equally. I ditched eaccelerator for APC and things have been peachy since.
On the other hand, there is certainly plenty of crap that they pay Oracle and Microsoft $$$ to run that doesn't serve anyone's needs very well, or integrate with anything else.
Like Sharepoint? It baffles me as to why anybody would buy that monstrosity... it doesn't do anything!
Although there are alternatives to Adobe Reader, none of them is good enough to gain significant market share.
Are you kidding me? Acrobat is such a steaming pile of crap that it has bred a completely misplaced hatred of PDF in most Windows users. Ever seen a Slashdot summary with a "(warning, PDF)" note after a link? Only Acrobat can manage to bog down a brand new system opening a 1 page PDF, every other PDF reader in the world will open it instantaneously.
If anything, Acrobat has single handedly painted PDF into the very niche corner that it's in now. PDF is a good format hobbled by a hopelessly lousy reference implementation.
If the horsepower and torque figures are still accurate, who cares? Heck, it might even be better. Compare the novelty of having a 500 HP V10 vs a 500 HP 4 cylinder.
At the core of the problem is that security is a tradeoff between convenience and security. Users like convenience and don't care about security. IT is tasked with (among other things) keeping things secure, and so users see them as making things less convenient. Making things even worse is that people ignorant of technology closer to the top of the organization are fond of instituting security theatre policies, which of course also fall upon IT to implement.
Yes and no, some drives have tripled in price while others have seen modest gains. Checking local stores, I see that the WD Caviar Green 2T drive that used to be on sale for $65 every week is now $180. However, the WD Caviar Green 3T drive that used to be in the $220 range is now... *drumroll*...$250. Now, I'm pretty sure the 2T drive was significantly less than $180 when it was released several years ago.
It doesn't make a lot of sense to me, but I guess people are still buying the 2T drives instead of the 3T drives, even though the latter actually is ~10% cheaper per gig now.
I have a sneaking suspicion that once drive prices start falling again they'll fall very slowly and may never reach the levels we saw just a few months ago.
Id at the time agreed to use some Creative sound technology in Doom 3 that they wouldn't have otherwise used in exchange for Creative not patent trolling Id over Carmack's Reverse being used in Doom 3.
Slashdot Mirror
That's an awful suggestion for this purpose. Linode is great, but charges a fortune for unusually large storage/transfer needs. Their biggest Linode at the moment has only 800G of space and 2T of transfer (and 20G of memory) for $800/month. That's going to be way overkill on the memory and huge underkill on the storage and transfer, and would already blow the budget.
Totally agree, once you get into this type of scale, you want to buy your own servers and colo them.
For a random example (not an endorsement, I've never used them before), Pair has 10U of space with 5 mbit bandwidth for only $400/month. Throw in a 2U server (~$3,000) with 12x 2T 7200 RPM drives (12x ~$150) in RAID 6 for 20T of usable space. Double the drive cost if you want "enterprise" drives. Shop around and I'm sure you can get better deals, these are just ballpark figures. I have no idea what kind of IOPS you need out of your storage, but it's easy (and much cheaper) to adjust your hardware to suit your needs when you own it.
The only situation where I wouldn't recommend managing your own servers is if you simply don't have the relevant domain knowledge AND you have the money to waste on managed hosting (ie, time is more valuable than money).
If Javascript were compiled into machine code before being sent to the client, it would be exactly 0% more useful for security related purposes.
Wrong; machine code is much harder to reverse-engineer than source code or minified code. Not impossible by any means, but it raises the bar; security-through-obscurity really does work, and is better than nothing at all, though it's obviously not something to be relied on if you can help it.
You're right, I should clarify. If Javascript were compiled into machine code before being sent to the client, it would be even worse for security most of the time, because a false sense of security (source code obfuscation in this case) is often worse than none at all. It lulls people into making bad choices that they may not have otherwise made... "Hey, nobody will ever figure out my Javascript code, therefore I can cut my workload in half by only doing the client side validation and skipping the server side validation! Great!", or "Hey, since nobody can read my Javascript, I'll just send down the whole database with every request, it'll be so much faster that way!"
I would also point out that in this particular case, reading the Javascript (regardless of how easy or difficult that is) is rarely going to be the preferred way of exploiting the system when you could simply peek at the network stream and see what happens when you push buttons.
In actuality, Javascript (ran in the client's browser) is far from useless for anything security related. Say you're implementing a login page. The naive approach would be to have a login and password field and send that over the wire back to the server in plain text.
Ok, I guess we need to start defining what we mean by "security". What you're describing is a situation in which the server implicitly trusts the client, but doesn't trust anyone that may be in the middle snooping on the communication. What I was talking about in the context of this copy-protection stuff is a situation where the server does not trust the client, and wants to limit how the client uses information the server sends it.
No, I'm describing a situation where the server does not need to trust the client and the client does not need to trust the server (in the ideal case). The client *proves* itself every step of the way and visa versa. It should go without saying that the actual format of the data still needs to be rigorously validated after it is received and before it is used.
The only way to limit the way the client uses information you send it is to limit the information that you send it.
* I was looking at free shopping cart software a while ago and found one that was implemented entirely in Javascript. It was fast as hell of course, and very nice-looking, but the problem was that, being Javascript, it was trivial for anyone to make up any order they wanted and send it to your server. You'd either have to implement a bunch of logic on the server to make sure your orders are legitimate, or be sure to catch them manually (easy if your volume is extremely low, not if it's higher). The whole thing just looked like a bad idea because it was trusting the client so much.
You have to implement a bunch of logic on the server to validate the order no matter how you send it to the server. Whether you construct the shopping cart one item at a time (dumb page with a bunch of buttons that all do separate posts) or all at once (fancy Javascript page) matters very little if at all with regards to the complexity of validating the order as a whole. The reason why it doesn't matter is that regardless of how you hope the data gets to your server (users clicking buttons on your page in a browser), it can also come from sources you may not be hoping for (nefarious users constructing their own requests directly).
What does impact the complexity of the validation is the design of the data that you choose to send back to t
Javascript is absolutely useless for anything security-related, because you're required to give the source code for your algorithm to the very people you're trying to hide that from.
Wrong. Javascript (ran in the client's browser) is absolutely useless for anything security related, because you're trusting the client. If your algorithm requires that the algorithm not be known to be secure, then it is not secure.
If Javascript were compiled into machine code before being sent to the client, it would be exactly 0% more useful for security related purposes. The client is still free to send whatever they want back to the server, regardless of whether it's through their browser or not.
In actuality, Javascript (ran in the client's browser) is far from useless for anything security related. Say you're implementing a login page. The naive approach would be to have a login and password field and send that over the wire back to the server in plain text. It works, but anyone is free to snoop the credentials while they're on the wire (or, particularly, when they're on the lack of wires). One option would be to encrypt the traffic with SSL, but this isn't perfect (forged SSL certificates and MITM attacks, for example). Instead, you could use a challenge-response mechanism similar to what SSH uses which never actually sends the credentials (encrypted or otherwise) over the wire, yet still proves to the server that the client is who they claim to be (and additionally proves to the client that the server is who they claim to be, or at least already knows their credentials). The algorithms for this are well known and can easily be implemented in Javascript, yet would provide a login page that is substantially more secure than the typical approach (with or without SSL).
These people just don't get it: software DRM simply doesn't work.
Hardware DRM doesn't work either. The fundamental problem with DRM is that you're giving a person a locked box and the key to that box, but then asking them (and rather rudely, in the case of DRM) to only use that key once. DRM cannot work as big content wishes it would, and anyone who tells you otherwise is a fool or a liar.
But this is exactly like that. The PC can run any number of operating systems.
Don't worry: 'Secure Boot' solves that problem.
Snide remarks aside, "Secure Boot" as implemented in EFI is not an effective DRM mechanism (moreso than most DRM, there are major technical problems with it). However, keep saying that and you'll end up with laws backing it up.
Don't believe me? http://www.youtube.com/watch?v=V2aq5M3Q76U
Exactly. You don't expect to buy a car and return the steering wheel do you?
No, I expect to buy a car and not find that every model from every brand comes with a dead body painstakingly sewn to the back seat as a mandatory option.
Your "contrary example" actually proves my point.
Once you have the pattern, you no longer need a key of your own - you just go and get one manufactured.
You contradict yourself. If you didn't need a key why would you go get one made? Furthermore, what ceases to be obscured through the process of taking your knowledge of the key's teeth and having a replica made? (Hint: nothing)
Your program didn't do what it was asked to. Why didn't it return an error code?
There's also no such thing as 100% bug-free.
While in the strictest sense, this may not be untrue, to phrase it that way is extremely dishonest. An encryption algorithm that relies on the secrecy of the algorithm is totally worthless (security by obscurity), whereas an encryption algorithm that relies on the secrecy of the keys used for encryption is quite useful (not security by obscurity in the normal sense).
In fact, if you want to be pedantic about it, the relevant definition for obscure is...
not readily understood or clearly expressed; also : mysterious [1]
Which is about understanding and not so much about knowledge. I may understand that I need a username and password to log into your system, just because I don't know what the username or password is doesn't make it security by obscurity. In fact, say I wanted to break into your house, I may have seen you use a physical key to open the front door and walk in and I may have even memorized the pattern of teeth on the key, but it does me no good if I don't have a key of my own to open the door with. There is certainly no obscurity in that security.
If you're going to go ahead and say that all security is "security through obscurity", then you may as well make the next logical step of not implementing any of it.
[1] http://www.merriam-webster.com/dictionary/obscure
Turns out it's better to avoid a crash than to get in one. Try this: http://www.gladwell.com/2004/2004_01_12_a_suv.html
Already brought the Ikea dining room set home in my compact sedan, thanks. 8 person table with 6 chairs. Need more room? Buy a minivan.
Bzzt! Sorry, death barges are many things, but practical isn't one of them. Unsafe, gas guzzling, underperforming, overweight and overpriced, yes, certainly. But practical? No.
Multiplayer games also benefit greatly from network effects. Nobody would play WoW if they were the only one on the server.
If you don't have a 9 figure marketing budget, you're probably struggling to get more players, and as mentioned already, most multiplayer games aren't fun without a lot of other players. So keeping that in mind, why would you go and shoot yourself in the foot by turning away 90% (or probably more) of your potential users by requiring payment up front?
For example, Game! is free to play and has been played by thousands of people, it also has a marketing budget of $0. I can only imagine if I'd required payment up front it'd probably have been played by dozens or maybe hundreds instead. That's a pretty big difference.
Unsurprisingly, people have been conditioned to expect things for free on the Internet. Making the jump from free to a penny is much larger than the jump from a penny to $10 or probably even $100. People will spend $5 on a latte every day and think nothing of it, because nobody is giving away free lattes, but ask them to spend $5 to access a website and they'll balk, after all, there's all those other websites that they can access for free.
What is a "real" ide and how does visual studio not qualify?
Vim, and it's not Vim, respectively.
It'd be fine if you could just order a foreign market car, while the US keeps its home market vehicles large, US-sized, powered and priced for the masses.
You realize that your own government is eviscerating the chances of "US-sized, powered and priced" cars ever coming back, right? See the new CAFE requirements for mileage.
Hard drives and motherboards don't have MAC addresses. Perhaps you're referring to the serial number.
PHP is like BASIC. In the right hands it can certainly produce just as readable and maintainable code as any other language, but the short learning curve to get to first base invites people with little or no discipline, or often enough, without any underpinnings at all, to write absolute garbage.
Would you you prefer that said people stumble their way through something more difficult like C, so that they can produce even worse code than they would have in PHP?
I had the opposite experience. When testing on some newer quad core servers (several years ago), I found that eaccelerator would cause segfaults in Apache that I couldn't pin down to anything in particular. It wasn't hardware either, because it happened on several machines equally. I ditched eaccelerator for APC and things have been peachy since.
On the other hand, there is certainly plenty of crap that they pay Oracle and Microsoft $$$ to run that doesn't serve anyone's needs very well, or integrate with anything else.
Like Sharepoint? It baffles me as to why anybody would buy that monstrosity... it doesn't do anything!
Although there are alternatives to Adobe Reader, none of them is good enough to gain significant market share.
Are you kidding me? Acrobat is such a steaming pile of crap that it has bred a completely misplaced hatred of PDF in most Windows users. Ever seen a Slashdot summary with a "(warning, PDF)" note after a link? Only Acrobat can manage to bog down a brand new system opening a 1 page PDF, every other PDF reader in the world will open it instantaneously.
If anything, Acrobat has single handedly painted PDF into the very niche corner that it's in now. PDF is a good format hobbled by a hopelessly lousy reference implementation.
Some people complain that they can't do everything on Linux that they can do with Windows, but apart from specific games (I love StarCraft)...
FYI, both SC1 and SC2 run flawlessly in Wine, I've been playing^Wtesting both for years.
If the horsepower and torque figures are still accurate, who cares? Heck, it might even be better. Compare the novelty of having a 500 HP V10 vs a 500 HP 4 cylinder.
At the core of the problem is that security is a tradeoff between convenience and security. Users like convenience and don't care about security. IT is tasked with (among other things) keeping things secure, and so users see them as making things less convenient. Making things even worse is that people ignorant of technology closer to the top of the organization are fond of instituting security theatre policies, which of course also fall upon IT to implement.
The what?
Yes and no, some drives have tripled in price while others have seen modest gains. Checking local stores, I see that the WD Caviar Green 2T drive that used to be on sale for $65 every week is now $180. However, the WD Caviar Green 3T drive that used to be in the $220 range is now... *drumroll* ...$250. Now, I'm pretty sure the 2T drive was significantly less than $180 when it was released several years ago.
It doesn't make a lot of sense to me, but I guess people are still buying the 2T drives instead of the 3T drives, even though the latter actually is ~10% cheaper per gig now.
I have a sneaking suspicion that once drive prices start falling again they'll fall very slowly and may never reach the levels we saw just a few months ago.
Id at the time agreed to use some Creative sound technology in Doom 3 that they wouldn't have otherwise used in exchange for Creative not patent trolling Id over Carmack's Reverse being used in Doom 3.