Dropbox wasn't hacked in the prior attack. Also, in a successful attack now you have two different products you have to find a security exploit on. Just throwing up your hands and saying 'everything can be hacked' isn't a security methodology.
The problem is that in the Dropbox company it was fine to just make a drop box account with some password that you reuse elsewhere. That is the fundamental problem. They don't have their employees use KeePass, or 1Password or something similar and generate random passwords that they change routinely, or any of these other security practices that would have prevented this attack without the two factor authentication.
Dropbox is a huge target and does not have the expertise to play in that league (evidenced by the fact that they needed outside help to figure out this attack). I think the two factor authentication is a good thing, but if they think "OK, problem solved" then it is not helping them. There is no replacement for good security practices, especially in a company with such a high profile.
Someone will hack them and will export the shared secret used for RFC 6238 TOTP: Time-Based One-Time Password Algorithm. Two factor authentication job is to protect the user, It doesn't make Dropbox security practices better, and they already demostrated are bad
Although I fundamentally agree that the underlying issue is their security practices (or lack thereof), this does address the specific recent hack (of an employee of theirs reusing the same password on Dropbox as on another account with another company that was compromised), and is a good idea regardless. I wish more sites did it.
You can get all the info on recovery.org for free. You would think the government could redirect their DNS name for a lot less $18 million. I'd do it for $18 for them.
Sure you'll have criminals trying to break into systems to steal money, and you'll have the same criminals trying to break into voting systems to rig elections, but the bottom line is that if you are going to develop a system that's electronic, follow a system that is alread working: the online banking model.
Online banking is not anonymous. All of the activity is directly traceable to your account, and you review it all the time. The results from a vote are anonymous, and doing it online is easily subject to fraud.
But you still have issues with *why...* Word is making the page/line/paragraph look like it does. It does me absolutely no good to see a borked format if I can't figure out why it is borked. Behaving as expected != correctly displaying WYSIWYG. Reveal Codes... a feature I still miss from good old WP5.1. (As an example, inserting/editting text just after some formatted text, say a subscript, is a pain...
Word has a little-known feature to show you exactly why text is a certain way. Press Shift-F1 and then click on the text. You get a pop-up. In 2003 you get a descriptive side-panel called "Reveal Formatting."
Besides the obvious civil liberties issues, the government does not have a good history of running networks. Just look at Amtrak.
The fundamental problem with Amtrak is that it doesn't run the network - it runs the service. If it ran the railroad tracks and train stations, and had private companies running the trains, things would probably be better.
A better example would be airports. The government runs the infrastructure, and private companies run the service (the airplanes themselves). Seems to work out ok. Only a pure Libritarian would think privatizing airports is necessary.
So if the government ran the cable, and private companies provided the ISP/Television/Telephone service, things would probably work out ok.
Since the community is a community of individuals, technically any member can file for the patent as a "small entity" in which fees are substantially reduced. Typical small entity fees are under 100 USD. (Note: there are countries with lower priced patenting than the USA and patenting in those countries would be just as advantageous.) And no, you don't need a lawyer to apply for a patent. You merely need to be willing to do all your own legwork. The lawyer legwork is the real cost of patent work.
Having been through the patent process once myself the above is only half true. You can write the patent yourself, but if you don't know what you are doing it will be much easier for someone to claim that the patent doesn't apply, and then what was the point (free or proprietary).
The small entity fee will keep the price down, but it will still get expensive, especially to keep the patent alive for the full 20 years. Fees can be found here.
If you don't file in the US, then the software could be proprietary in the US. If you don't file in the EU, same thing in the EU. Doing those two ought to do it. (If both markets are closed, there isn't much left to sell to). Still talking a couple of thousand USD at an absolute minimum, and that is assuming 11.5 years is enough (would be for most software patents).
Finally, patenting open-source software as a "defensive measure" to prevent it from being patented by someone else is not necessary... so long as it is published with a copyright notice (which isn't even required any more), you can prove prior art. That way, open-source developers do not need to waste resources on patent application.
Patents have a greater power than that. With copywrite you can only ensure no one copies and derives from the code. Patents prevent clean room implementations as well.
The advantage for advocates of the GPL is that a patent holder of an "open" patent could theoretically force all people who implement the patented idea to GPL their code, even if it was not derived from any other code, just by virtue of having filed the patent.
The problem is that patents, unlike copyright, cost money. To register, to write (typically takes a lawyer-type to write them) and to maintain (you have to keep paying - with higher fees the longer you extend the patent - to keep the patent current).
So to patent something for purpose of GPLing it would take either a foundation to act as an umbrella and pay for the fees from donations (and perhaps lawyer donated time), or a really true believer.
You are actually making an argument for case sensitivity. For one, the snippet you mentioned wouldn't even compile in Java unless someone defined both exception spellings as different classes, and if someone did that he doesn't deserve to call himself a programmer. Other than that, case sensitivity makes it easier to find bugs, and take it any way you wish, but if you actually programmed in any serious language you would have already known that.
That "someone" is the Java community process. Both class names are exception classes in J2EE. One is in javax.jms and the other in javax.transaction.
And one final note regarding the part with renaming the class. When you make modifications to someone else's code it is good practice (and common sense, I might add) to follow that person's conventions whether you like them or not. So you shouldn't start renaming things in the entire source just because you didn't like their casing.
It doesn't need to be someone else's code. What is wrong with it is that it breaks the convention of the project. Each programmer on a project is not free to make up their own conventions, typically, and when they do make a mistake (inevitable really) once in a while, it is nice to correct it. Case sensitivity makes it harder to follow the convention in that case, because it forces errors to compound.
Granted, I am assuming a project where programmer care about the convention. If they don't care, then case sensitivity helps the lack of caring, a little.
A lot of responses to this miss the point entirely. Case sensitivity has a serious cost: Bugs. And most notably, debugging time. Countless hours of programmer time have been wasted due to case sensitivity. It makes very hard to find bugs.
And yet you see TransactionRolledBackException propagating to a higher level. You have looked at the code and swear you are catching it. Oops, missed that upper case B.
Arguments that you can do something like this:
Object object = new Object();
are irrelevant. This is also perfectly legal in java:
Object Object = new Object();
Case sensitivity does nothing to enforce preferred conventions, and actually enforces unreadable code.
Would I like to read code that says System.arrayCopy(...), or Color.BLACK ? Sure I would, but that wouldn't compile. Case sensitivity enforces the wrong thing (literal consistency) rather than convention (conceptual consistency).
Would I like to rename that class which someone called subProductPanel to SubProductPanel? Sure I would, but that would involve changing the 15 classes that reference it, not to mention the file name, which would confuse CVS on windows clients terribly.
So I am stuck with my subProductPanel class name without more effort that it is worth to fix, because of case sensitivity. If everything was case insensitive, then I would be able to change it easily.
As for portability, case sensitive and case insensitive are incompatible and equally create portability problems. Windows having a case insensitive file system causes limitations in Java's portability because Java considers MyClass and myClass to be two separate names needing two separate files. Windows will not support that. So Java code that runs on Linux will not work on Windows, and vice-versa (think about code which reads from the file system).
Bottom line:
Case sensitivity creates an environment condusive to hard-to-find bugs because people aren't case sensitive. They may notice case when it is out of place, but not normally.(sOMEtHINgouToFplACE vs. somethingOutOfPlace will be noticed. Not, however someThingOutOfPlace or SomethingOutOfPlace and only programmers consider SOMETHINGOUTOFPLACE different).
A case sensitive environment enforces only the non-use of conventions. A case insensitive environment lets you use the convention even if the author of the API forgot to.
As for BasicSend vs. BasicsEnd, that is an argument to use something other than case to differentiate words, not just hoping that people notice the difference. Wouldn't Basic_Send and Basics_End be much better?
As for differences in how languages handle case insensitivity, String.toLowerCase() figures it out, so would the computer language. You establish rules and stick to them. Will a language which targets the English speaking get all other languages right (the way most speakers of that language would intuit)? Probably not. That doesn't mean that the target audience has to spend thousands of hours chasing down unnecessarily hard to find bugs.
Slashdot Mirror
Dropbox wasn't hacked in the prior attack. Also, in a successful attack now you have two different products you have to find a security exploit on. Just throwing up your hands and saying 'everything can be hacked' isn't a security methodology.
The problem is that in the Dropbox company it was fine to just make a drop box account with some password that you reuse elsewhere. That is the fundamental problem. They don't have their employees use KeePass, or 1Password or something similar and generate random passwords that they change routinely, or any of these other security practices that would have prevented this attack without the two factor authentication. Dropbox is a huge target and does not have the expertise to play in that league (evidenced by the fact that they needed outside help to figure out this attack). I think the two factor authentication is a good thing, but if they think "OK, problem solved" then it is not helping them. There is no replacement for good security practices, especially in a company with such a high profile.
Someone will hack them and will export the shared secret used for RFC 6238 TOTP: Time-Based One-Time Password Algorithm. Two factor authentication job is to protect the user, It doesn't make Dropbox security practices better, and they already demostrated are bad
Although I fundamentally agree that the underlying issue is their security practices (or lack thereof), this does address the specific recent hack (of an employee of theirs reusing the same password on Dropbox as on another account with another company that was compromised), and is a good idea regardless. I wish more sites did it.
You can get all the info on recovery.org for free. You would think the government could redirect their DNS name for a lot less $18 million. I'd do it for $18 for them.
Online banking is not anonymous. All of the activity is directly traceable to your account, and you review it all the time. The results from a vote are anonymous, and doing it online is easily subject to fraud.
Word has a little-known feature to show you exactly why text is a certain way. Press Shift-F1 and then click on the text. You get a pop-up. In 2003 you get a descriptive side-panel called "Reveal Formatting."
The fundamental problem with Amtrak is that it doesn't run the network - it runs the service. If it ran the railroad tracks and train stations, and had private companies running the trains, things would probably be better.
A better example would be airports. The government runs the infrastructure, and private companies run the service (the airplanes themselves). Seems to work out ok. Only a pure Libritarian would think privatizing airports is necessary.
So if the government ran the cable, and private companies provided the ISP/Television/Telephone service, things would probably work out ok.
Having been through the patent process once myself the above is only half true. You can write the patent yourself, but if you don't know what you are doing it will be much easier for someone to claim that the patent doesn't apply, and then what was the point (free or proprietary).
The small entity fee will keep the price down, but it will still get expensive, especially to keep the patent alive for the full 20 years. Fees can be found here.
If you don't file in the US, then the software could be proprietary in the US. If you don't file in the EU, same thing in the EU. Doing those two ought to do it. (If both markets are closed, there isn't much left to sell to). Still talking a couple of thousand USD at an absolute minimum, and that is assuming 11.5 years is enough (would be for most software patents).
Patents have a greater power than that. With copywrite you can only ensure no one copies and derives from the code. Patents prevent clean room implementations as well.
The advantage for advocates of the GPL is that a patent holder of an "open" patent could theoretically force all people who implement the patented idea to GPL their code, even if it was not derived from any other code, just by virtue of having filed the patent.
The problem is that patents, unlike copyright, cost money. To register, to write (typically takes a lawyer-type to write them) and to maintain (you have to keep paying - with higher fees the longer you extend the patent - to keep the patent current).
So to patent something for purpose of GPLing it would take either a foundation to act as an umbrella and pay for the fees from donations (and perhaps lawyer donated time), or a really true believer.
That "someone" is the Java community process. Both class names are exception classes in J2EE. One is in javax.jms and the other in javax.transaction.
And one final note regarding the part with renaming the class. When you make modifications to someone else's code it is good practice (and common sense, I might add) to follow that person's conventions whether you like them or not. So you shouldn't start renaming things in the entire source just because you didn't like their casing.
It doesn't need to be someone else's code. What is wrong with it is that it breaks the convention of the project. Each programmer on a project is not free to make up their own conventions, typically, and when they do make a mistake (inevitable really) once in a while, it is nice to correct it. Case sensitivity makes it harder to follow the convention in that case, because it forces errors to compound.
Granted, I am assuming a project where programmer care about the convention. If they don't care, then case sensitivity helps the lack of caring, a little.
Consider this snippet of java code:
And yet you see TransactionRolledBackException propagating to a higher level. You have looked at the code and swear you are catching it. Oops, missed that upper case B.Arguments that you can do something like this:
are irrelevant. This is also perfectly legal in java:Case sensitivity does nothing to enforce preferred conventions, and actually enforces unreadable code.Would I like to read code that says System.arrayCopy(...), or Color.BLACK ? Sure I would, but that wouldn't compile. Case sensitivity enforces the wrong thing (literal consistency) rather than convention (conceptual consistency).
Would I like to rename that class which someone called subProductPanel to SubProductPanel? Sure I would, but that would involve changing the 15 classes that reference it, not to mention the file name, which would confuse CVS on windows clients terribly.
So I am stuck with my subProductPanel class name without more effort that it is worth to fix, because of case sensitivity. If everything was case insensitive, then I would be able to change it easily.
As for portability, case sensitive and case insensitive are incompatible and equally create portability problems. Windows having a case insensitive file system causes limitations in Java's portability because Java considers MyClass and myClass to be two separate names needing two separate files. Windows will not support that. So Java code that runs on Linux will not work on Windows, and vice-versa (think about code which reads from the file system).
Bottom line:
Case sensitivity creates an environment condusive to hard-to-find bugs because people aren't case sensitive. They may notice case when it is out of place, but not normally.(sOMEtHINgouToFplACE vs. somethingOutOfPlace will be noticed. Not, however someThingOutOfPlace or SomethingOutOfPlace and only programmers consider SOMETHINGOUTOFPLACE different).
A case sensitive environment enforces only the non-use of conventions. A case insensitive environment lets you use the convention even if the author of the API forgot to.
As for BasicSend vs. BasicsEnd, that is an argument to use something other than case to differentiate words, not just hoping that people notice the difference. Wouldn't Basic_Send and Basics_End be much better?
As for differences in how languages handle case insensitivity, String.toLowerCase() figures it out, so would the computer language. You establish rules and stick to them. Will a language which targets the English speaking get all other languages right (the way most speakers of that language would intuit)? Probably not. That doesn't mean that the target audience has to spend thousands of hours chasing down unnecessarily hard to find bugs.