If you rely on hashing speed to hash passwords, you are doing it wrong.
If you rely only on hashing speed to protect your passwords, you're doing it wrong.
The problem with fast hashing is that it facilitates brute force password searches. Salt prevents rainbow table attacks, but targeted brute force attacks against a specific password can be quite feasible given typical user password selection. There are two solutions to this: Make users pick better passwords or find a way to slow down brute force search. The best approach is to do both; do what you can to make users pick good passwords (though there are definite limits to that approach), and use a parameterized hash algorithm that allows you to tune the computational effort.
The common way to slow down the hash is simple enough: iterate it. Then as computers in general get faster you can simply increase the number of iterations. In fact, you can periodically go through your password table and apply a few hundred more iterations to each of your stored password hashes. The goal is to keep password hashing as expensive as you can afford, since whatever your cost is, the cost to an attacker is several orders of magnitude higher (since the attacker has to search the password space). Oh, and it's also a good idea to try to keep attackers from getting hold of your password file. Layered defense.
As I understand it, that's why you salt the passwords AND use a user-specific string (based on username, email and/or similarly constant data)
User-specific strings are good too, as another layer to the defense, but you have to assume that an attacker who gets access to your password file probably gets that data as well.
to introduce more variation so that they can't use generic rainbow tables or even site-specific rainbow tables.
Salt is sufficient to eliminate rainbow table attacks.
I have a tablet - I don't want a second mini-tablet that won't fit in a regular jacket/shirt pocket
Have you actually tried putting any of the 5" phones in your pocket? I have a Galaxy Nexus and even though my first impression when I got it was "Damn, this thing is *huge*!", but I've yet to find a (men's) pocket it doesn't fit in quite nicely, and the extra screen real estate is very nice.
I prefer OS X as my main operating system, so having mobile devices with native and easy data sync to keep everything current is very important to me.
I'm also using OS X as my OS, but syncing is one of the reasons I prefer Android over iOS... because with iOS I have to muck about with syncing. With my Android phone and tablet everything syncs behind the scenes, wirelessly. It's much more convenient.
However, in the interest of full disclosure, I should mention that I'm very annoyed with Apple's lawsuit crap, to the degree that I'm also dumping OS X. My next laptop will be a Thinkpad running Ubuntu. Also, I work for Google. Just so you know what my biases are. My wife is going to be switching from iOS to Android in the next couple of months (she currently has my old iPhone 4), so it will be interesting to see if she reaches the same conclusion I did with respect to syncing (the iPhone will be handed down to my son).
When they go "wah wah wah" and have it taken down, pull the same thing - declare that it isn't.
You're recommending that the guy commit perjury. Now, it's likely he'll never get called on it, but he could, and "But they did it to me first!" isn't a valid defense.
Perhaps now, this will force Google to offer permanent positions and better salaries to some of its better contract programmers.
Huh? Google has no contract programmers to speak of. I hesitate to say the number is zero, because there's probably some obscure corner of the company that has one or two tucked away, but as far as I can see, zero is what it is (excluding interns -- many of whom become regular employees after graduation).
Google uses a lot of contractors for facilities, food services, recruiters and other supporting positions, but SWEs (Software Engineers) and SETs (Software Engineers in Test), are basically all regular employees, as are the vast majority of SREs (Site Reliability Engineers... basically Google's sysadmins).
Honestly, given the complexity and uniqueness of Google's infrastructure, it wouldn't make any sense for Google to hire contract programmers. It's pretty widely accepted internally that it takes a full year for a new Google engineer to become productive because of all of the technologies he or she needs to learn (this is also the reason Google interviews don't ask you about what tools/frameworks you've used in the past -- whatever it is, Google has built its own anyway so your knowledge is irrelevant). Since the company has to basically invest a full year up front, there's little value in hiring people for periods of time less than 2-3 years, but you can't hire a contractor for that long without the IRS viewing them as an employee anyway.
That's a rather strong claim, since it directly contradicts the statements the company has made since its inception, including the legally binding statements made in its IPO documentation. It's also hard to fathom why the people who control the company's voting stock (the founders) would care that much about becoming wealthier -- they already have more money than they could ever possibly spend. And because they control the voting stock, no one else is in a position to override them.
Hmm, the US is one of the first nations in history to elect their leaders. Do you think it's just possible that in the course of a couple centuries we've discovered additional safeguards that are fundamentally required for elections to actually serve their purpose?
Evidence and experience that they're a really good idea isn't the same as a Constitutional requirement. Not everything that's a good idea is required by the Constitution. If that were the case, why would we even need legislative bodies? All laws and regulations could be determined by analyzing best practices and scrutinizing the text of the Constitution.
Now, that's not to say that it might not be a good idea for this particular issue to be codified in the written Constitution. If it's so fundamental that it should be a guaranteed right -- and I agree that it is -- then we should amend the Constitution to say so. But just because we believe it's fundamental doesn't mean that the Constitution already says it's a right.
Personally, I have no Facebook account. I used to have one, but got rid of it the third time they changed my privacy settings without even telling me about it.
Just turn on their two-factor authentication protocol, then you can use a somewhat shorter password and still be confident that your account is safe.
What's that? You say they don't offer two-factor auth? Umm... what year is this? My gaming accounts offer two-factor, why in the world would anyone use an e-mail service -- given that your e-mail account tends to be the master key to all of your other on-line accounts via the "reset password" process -- which doesn't?
You basically just confirmed my argument, except that the implementation error lay in the choice of chip technology. Yes, old MIFARE sucked (and everyone always knew it, even when it wasn't old), but there are lots of other options, many of them very inexpensive, and for reusable cards the price doesn't really have to be that low anyway -- so what if the card costs 75 cents, or even a dollar or two? Raise fare prices by a tiny amount, then offer small discounts for loading reusable cards, and make the consumer buy the card. It's worked in many systems around the world.
As I said, there's nothing wrong with storing the balance on the card... you just have to do it right, which includes buying the right cards and using their capabilities -- and validating that you actually are.
Why on earth would anyone store the balance on the card you give to customers? Isn't that kind of an open invitation to exploitation not to mention customer service headaches from people losing/damaging their cards?
There are lots of reasons that you might want to store the balance on the card. Increased reliability in the face of network outages, improved performance by eliminating the need for a network round trip and a database query, the ability to deploy in environments without network access at all, the ability to cross incompatible system boundaries... and many more.
Further, if you do it right, there's no reason not to store the balance on the card. Smart card chips like those used in these fare cards are designed to provide a fairly high degree of security. They can perform cryptographic operations to authenticate the commands they're given, and they can make decisions about whether or not they're going to honor the commands based on authentication and on the content of the request and its context (to the degree that they're aware of context).
But building smart card systems is hard, and making them secure adds another layer of complexity and frustration when things just don't work because the damned card keeps rejecting your -- you believe -- properly authenticated and formatted commands. It's normal for the early stages of development to disable security for ease of development and testing... and it's unfortunately pretty common for security to be left off, or at least not thoroughly validated, for deployment. And it mostly works, because contactless smart card readers are relatively rare -- they're not expensive, mind you, haven't been for many years, but they have been uncommon. Except now there's one embedded in every one of an increasing number of high-end smartphone models.
This isn't a fundamental architectural flaw, it's either a detailed design flaw or (very likely) a straight up implementation error. Most likely caused by simple laziness and incompetence (granted that finding competent people in this area of technology isn't trivial, and self-education is a multi-year process).
They seem to believe that a url where you can see it online is as good as having it printed right in fromt of you. Were I one of those parents I would just hand then a piece of paper with a link to a picture of $180. Fair is fair.
Oh, I don't know... a printed image in a book has a pretty limited resolution. An on-line image can offer a lot more... take a look at the very high resolution imagery provided by http://googleartproject.com./ You can see the work as a whole or if you'd like to you can zoom in to see more detail than you could see if you were standing in front of the real piece.
OTOH, I have to agree that having the images the text is discussing right next to the images would be much more useful if you want to, for example, study art history.
All it's really done is eliminated the stories people tell about arriving at the airport 30 minutes before their flight and still getting on the plane. I haven't changed my arrival time _at all_ since 9/11. Because I always arrived with plenty of time to spare
So for people like you it hasn't cost anything. There are many, many other business travelers (like me) who in fact used to arrive 30-45 minutes before the flight, as a matter of habit -- and it saved a lot of time! My office was a very reliable 15 minutes from the airport, I parked where I could walk to the terminal, and had getting through security down to an art (and leveraged my frequent flyer status to use the short line). Maybe one flight in 20 I missed the plane because of some unanticipated delay, and the hour or two it cost me in those cases was far more than offset by all the time I didn't spend waiting the rest of the trips.
Now, of course, I arrive at the airport 90 minutes beforehand, or 60 minutes if I happen to know that it's a low-traffic time of day. Thankfully, ubiquitous Wifi has partially offset the time lost, but not completely.
Windows isn't used for high-performance computing, nor as a real-time OS, so it probably won't ever get this feature.
ORLY? (okok, only 2 of the top500, but it's not like it's NOT used. I'd be surprised if it's used anywhere that's not being paid by Microsoft to do it though.)
It should be pointed out that the adaptive tickless work has nothing to do with power savings. It's about reducing the CPU time the OS takes away from running tasks. By itself the time is insignificant, but when you factor in cache impact and critical sections it can cause non-trivial performance and latency impacts in high-performance and real-time workloads.
Windows isn't used for high-performance computing, nor as a real-time OS, so it probably won't ever get this feature.
The school my son went to didn't provide any housing for the teachers, and only a very basic benefits package. At their tuition rates ($3K per student per year -- well below what the state spent), there wasn't a lot of money to go around. Great school, though.
Purely secular private schools also tend to offer significantly lower salaries than public schools, and yet tend to attract better teachers. Why? Because there's a lot of bureaucratic crap that teachers have to deal with in the public school system, and a lot of students with parents who don't care. As one (admittedly anecdotal) example, my wife taught in the public schools for a few years, and during that time had at least one mother tell her about her very disruptive son "When he's at home, he's my problem, when he's here, he's yours. I don't want to hear about your problems." For my wife, at least, it was actually the bureaucracy that frustrated her.
I had my son in a non-religious private school for a few years, because the public school system was failing him. His teachers were uniformly amazing -- easily head and shoulders above the best we've seen in the public schools -- in spite of the fact that they made about 30% less than public school teachers of corresponding experience and education. When I asked them why they taught there, rather than making more in the public system, every one of them answered "Because here I can teach." Between small classes (8-12 students), zero bureaucratic overhead, a supportive administration and interested parents, the teachers felt empowered to do what they got into teaching for in the first place.
While the US legal system is such that entities can drag even blatantly bogus lawsuits out for years, so winning against individuals and smaller businesses just by attrition of legal costs, fine-tweaking the definition of bogusness wont have even the slightest effect.
I disagree.
In particular, if the courts were to adopt the proposed interpretation, the effect on patent trolls would be devastating. Defendants would be able to make a motion for summary dismissal on the grounds that the patent is a functional patent which under the 112(f) rule must be interpreted in reference to the details of the inventor's implementation, and since the inventor has no implementation there is no possibility of determining the boundaries of the patent and therefore the question is moot. And the motion would succeed. This would reduce such trials from years to weeks, because there would be no justification for a lengthy discover phase.
Even in non-troll cases, it would eliminate the need for most of the lengthy discovery that goes on now, because the defendant could easily argue that all of its internal documentation is simply irrelevant, since the case can be decided by examining the software implementations and determining if they're sufficiently similar. This would still result in trials dominated by detailed arguments from technical experts, so they'd still be expensive, but the cost would be a tiny fraction of what it is now, and it would take far, far less time without all of the extensive (and expensive) discovery.
Perhaps even better, it would encourage inventors (or their lawyers) to write patents which are very specific and narrow, specifically in order to avoid the sorts of broad functional claims which would invoke the author's interpretation of 112(f). Long-term, that would probably be the most important and most beneficial change to the status quo.
Would it be a panacea? Clearly not. But it would make the situation vastly better than it is now -- except from the perspective of patent plaintiffs pushing very broad patents.
If this gets enacted as case law the obvious next step is that Apple will patent the 'for' loop and Microsoft will licence the 'if' statement.
Wouldn't work, for at least two reasons.
First, the patent would have to cover use of an algorithm to accomplish a specific task, and patents that try to cover basic operations like "iteration" would be as successful as patents on "moving objects from one place to another" -- they would be too broad to be accepted (by courts, at least -- the PTO seems to accept everything).
Second, prior art for such basic algorithms as conditional branching is both plentiful and as old as you like -- at least back to the dawn of computer programming, and arguably far older than that.
What is the smallest/simplest functional thing that could constitute an algorithm?
Read the article (it's long, but I found it quite interesting). The author isn't proposing to allow algorithms to be patented -- that clearly isn't permitted at present, and shouldn't be, for a multitude of reasons. Instead, he's saying that under his interpretation of the current federal patent law, patents that say (or imply) something like "a computer programmed to do X" don't cover any software that can do X. Rather, they only cover the specific algorithms and processes the "inventor" used to do X. A competitor who creates a program to do X but who uses different algorithms is not infringing. To give a concrete example, if Samsung used a different algorithm for tracking the finger motion in its "swipe to unlock" implementation, then Apple's patent would be inapplicable. Apple's patent would still be valid, it just wouldn't apply.
This approach would be particularly devastating to patent trolls, because if the patent only covers the particular approach to implementation used by the inventor, but the inventor never actually implemented it, then clearly the patent covers nothing.
I think it's a very interesting idea. It depends entirely on the courts being willing to interpret some subtleties of the current federal law in a very particular way, and one which -- to my non-lawyerly eyes -- seems like a bit of a stretch, though. It will be interesting to see what other patent expert, and ultimately, judges, think of it, but it's certainly got merit. The result wouldn't be to invalidate software patents, but it would make it very, very easy for competitors to sidestep them. Maybe too easy. I haven't quite finished reading the author's section of possible objections to his theory; maybe he addresses that.
Slashdot Mirror
The reference to site-specific rainbow tables implies the same salt was used for all passwords.
That's not salt, that's just a modification of the hash algorithm -- basically a tagged hash. Salt is defined as a per-entry random value.
By "plants" the GP meant the green growing sort. That's why he/she said they only crack half the day.
If you rely on hashing speed to hash passwords, you are doing it wrong.
If you rely only on hashing speed to protect your passwords, you're doing it wrong.
The problem with fast hashing is that it facilitates brute force password searches. Salt prevents rainbow table attacks, but targeted brute force attacks against a specific password can be quite feasible given typical user password selection. There are two solutions to this: Make users pick better passwords or find a way to slow down brute force search. The best approach is to do both; do what you can to make users pick good passwords (though there are definite limits to that approach), and use a parameterized hash algorithm that allows you to tune the computational effort.
The common way to slow down the hash is simple enough: iterate it. Then as computers in general get faster you can simply increase the number of iterations. In fact, you can periodically go through your password table and apply a few hundred more iterations to each of your stored password hashes. The goal is to keep password hashing as expensive as you can afford, since whatever your cost is, the cost to an attacker is several orders of magnitude higher (since the attacker has to search the password space). Oh, and it's also a good idea to try to keep attackers from getting hold of your password file. Layered defense.
As I understand it, that's why you salt the passwords AND use a user-specific string (based on username, email and/or similarly constant data)
User-specific strings are good too, as another layer to the defense, but you have to assume that an attacker who gets access to your password file probably gets that data as well.
to introduce more variation so that they can't use generic rainbow tables or even site-specific rainbow tables.
Salt is sufficient to eliminate rainbow table attacks.
I have a tablet - I don't want a second mini-tablet that won't fit in a regular jacket/shirt pocket
Have you actually tried putting any of the 5" phones in your pocket? I have a Galaxy Nexus and even though my first impression when I got it was "Damn, this thing is *huge*!", but I've yet to find a (men's) pocket it doesn't fit in quite nicely, and the extra screen real estate is very nice.
I prefer OS X as my main operating system, so having mobile devices with native and easy data sync to keep everything current is very important to me.
I'm also using OS X as my OS, but syncing is one of the reasons I prefer Android over iOS... because with iOS I have to muck about with syncing. With my Android phone and tablet everything syncs behind the scenes, wirelessly. It's much more convenient.
However, in the interest of full disclosure, I should mention that I'm very annoyed with Apple's lawsuit crap, to the degree that I'm also dumping OS X. My next laptop will be a Thinkpad running Ubuntu. Also, I work for Google. Just so you know what my biases are. My wife is going to be switching from iOS to Android in the next couple of months (she currently has my old iPhone 4), so it will be interesting to see if she reaches the same conclusion I did with respect to syncing (the iPhone will be handed down to my son).
When they go "wah wah wah" and have it taken down, pull the same thing - declare that it isn't.
You're recommending that the guy commit perjury. Now, it's likely he'll never get called on it, but he could, and "But they did it to me first!" isn't a valid defense.
Bad advice.
Perhaps now, this will force Google to offer permanent positions and better salaries to some of its better contract programmers.
Huh? Google has no contract programmers to speak of. I hesitate to say the number is zero, because there's probably some obscure corner of the company that has one or two tucked away, but as far as I can see, zero is what it is (excluding interns -- many of whom become regular employees after graduation).
Google uses a lot of contractors for facilities, food services, recruiters and other supporting positions, but SWEs (Software Engineers) and SETs (Software Engineers in Test), are basically all regular employees, as are the vast majority of SREs (Site Reliability Engineers... basically Google's sysadmins).
Honestly, given the complexity and uniqueness of Google's infrastructure, it wouldn't make any sense for Google to hire contract programmers. It's pretty widely accepted internally that it takes a full year for a new Google engineer to become productive because of all of the technologies he or she needs to learn (this is also the reason Google interviews don't ask you about what tools/frameworks you've used in the past -- whatever it is, Google has built its own anyway so your knowledge is irrelevant). Since the company has to basically invest a full year up front, there's little value in hiring people for periods of time less than 2-3 years, but you can't hire a contractor for that long without the IRS viewing them as an employee anyway.
(I'm a SWE at Google.)
Google only wants one thing - more money.
That's a rather strong claim, since it directly contradicts the statements the company has made since its inception, including the legally binding statements made in its IPO documentation. It's also hard to fathom why the people who control the company's voting stock (the founders) would care that much about becoming wealthier -- they already have more money than they could ever possibly spend. And because they control the voting stock, no one else is in a position to override them.
Strong claims require strong evidence. Have any?
What does the military use helium for?
Hmm, the US is one of the first nations in history to elect their leaders. Do you think it's just possible that in the course of a couple centuries we've discovered additional safeguards that are fundamentally required for elections to actually serve their purpose?
Evidence and experience that they're a really good idea isn't the same as a Constitutional requirement. Not everything that's a good idea is required by the Constitution. If that were the case, why would we even need legislative bodies? All laws and regulations could be determined by analyzing best practices and scrutinizing the text of the Constitution.
Now, that's not to say that it might not be a good idea for this particular issue to be codified in the written Constitution. If it's so fundamental that it should be a guaranteed right -- and I agree that it is -- then we should amend the Constitution to say so. But just because we believe it's fundamental doesn't mean that the Constitution already says it's a right.
I have six accounts in all... I hate Facebook.
There seems to be a contradiction here.
Personally, I have no Facebook account. I used to have one, but got rid of it the third time they changed my privacy settings without even telling me about it.
Just turn on their two-factor authentication protocol, then you can use a somewhat shorter password and still be confident that your account is safe.
What's that? You say they don't offer two-factor auth? Umm... what year is this? My gaming accounts offer two-factor, why in the world would anyone use an e-mail service -- given that your e-mail account tends to be the master key to all of your other on-line accounts via the "reset password" process -- which doesn't?
You basically just confirmed my argument, except that the implementation error lay in the choice of chip technology. Yes, old MIFARE sucked (and everyone always knew it, even when it wasn't old), but there are lots of other options, many of them very inexpensive, and for reusable cards the price doesn't really have to be that low anyway -- so what if the card costs 75 cents, or even a dollar or two? Raise fare prices by a tiny amount, then offer small discounts for loading reusable cards, and make the consumer buy the card. It's worked in many systems around the world.
As I said, there's nothing wrong with storing the balance on the card... you just have to do it right, which includes buying the right cards and using their capabilities -- and validating that you actually are.
Why on earth would anyone store the balance on the card you give to customers? Isn't that kind of an open invitation to exploitation not to mention customer service headaches from people losing/damaging their cards?
There are lots of reasons that you might want to store the balance on the card. Increased reliability in the face of network outages, improved performance by eliminating the need for a network round trip and a database query, the ability to deploy in environments without network access at all, the ability to cross incompatible system boundaries... and many more.
Further, if you do it right, there's no reason not to store the balance on the card. Smart card chips like those used in these fare cards are designed to provide a fairly high degree of security. They can perform cryptographic operations to authenticate the commands they're given, and they can make decisions about whether or not they're going to honor the commands based on authentication and on the content of the request and its context (to the degree that they're aware of context).
But building smart card systems is hard, and making them secure adds another layer of complexity and frustration when things just don't work because the damned card keeps rejecting your -- you believe -- properly authenticated and formatted commands. It's normal for the early stages of development to disable security for ease of development and testing... and it's unfortunately pretty common for security to be left off, or at least not thoroughly validated, for deployment. And it mostly works, because contactless smart card readers are relatively rare -- they're not expensive, mind you, haven't been for many years, but they have been uncommon. Except now there's one embedded in every one of an increasing number of high-end smartphone models.
This isn't a fundamental architectural flaw, it's either a detailed design flaw or (very likely) a straight up implementation error. Most likely caused by simple laziness and incompetence (granted that finding competent people in this area of technology isn't trivial, and self-education is a multi-year process).
Yet, oddly enough, Google Maps can display an entire continent or an individual street... in the same window!
They seem to believe that a url where you can see it online is as good as having it printed right in fromt of you. Were I one of those parents I would just hand then a piece of paper with a link to a picture of $180. Fair is fair.
Oh, I don't know... a printed image in a book has a pretty limited resolution. An on-line image can offer a lot more... take a look at the very high resolution imagery provided by http://googleartproject.com./ You can see the work as a whole or if you'd like to you can zoom in to see more detail than you could see if you were standing in front of the real piece.
OTOH, I have to agree that having the images the text is discussing right next to the images would be much more useful if you want to, for example, study art history.
All it's really done is eliminated the stories people tell about arriving at the airport 30 minutes before their flight and still getting on the plane. I haven't changed my arrival time _at all_ since 9/11. Because I always arrived with plenty of time to spare
So for people like you it hasn't cost anything. There are many, many other business travelers (like me) who in fact used to arrive 30-45 minutes before the flight, as a matter of habit -- and it saved a lot of time! My office was a very reliable 15 minutes from the airport, I parked where I could walk to the terminal, and had getting through security down to an art (and leveraged my frequent flyer status to use the short line). Maybe one flight in 20 I missed the plane because of some unanticipated delay, and the hour or two it cost me in those cases was far more than offset by all the time I didn't spend waiting the rest of the trips.
Now, of course, I arrive at the airport 90 minutes beforehand, or 60 minutes if I happen to know that it's a low-traffic time of day. Thankfully, ubiquitous Wifi has partially offset the time lost, but not completely.
Windows isn't used for high-performance computing, nor as a real-time OS, so it probably won't ever get this feature.
O RLY? (okok, only 2 of the top500, but it's not like it's NOT used. I'd be surprised if it's used anywhere that's not being paid by Microsoft to do it though.)
As I said :-)
It should be pointed out that the adaptive tickless work has nothing to do with power savings. It's about reducing the CPU time the OS takes away from running tasks. By itself the time is insignificant, but when you factor in cache impact and critical sections it can cause non-trivial performance and latency impacts in high-performance and real-time workloads.
Windows isn't used for high-performance computing, nor as a real-time OS, so it probably won't ever get this feature.
What confusion? You obviously weren't confused, and as far as I can tell neither was anyone else.
The school my son went to didn't provide any housing for the teachers, and only a very basic benefits package. At their tuition rates ($3K per student per year -- well below what the state spent), there wasn't a lot of money to go around. Great school, though.
Purely secular private schools also tend to offer significantly lower salaries than public schools, and yet tend to attract better teachers. Why? Because there's a lot of bureaucratic crap that teachers have to deal with in the public school system, and a lot of students with parents who don't care. As one (admittedly anecdotal) example, my wife taught in the public schools for a few years, and during that time had at least one mother tell her about her very disruptive son "When he's at home, he's my problem, when he's here, he's yours. I don't want to hear about your problems." For my wife, at least, it was actually the bureaucracy that frustrated her.
I had my son in a non-religious private school for a few years, because the public school system was failing him. His teachers were uniformly amazing -- easily head and shoulders above the best we've seen in the public schools -- in spite of the fact that they made about 30% less than public school teachers of corresponding experience and education. When I asked them why they taught there, rather than making more in the public system, every one of them answered "Because here I can teach." Between small classes (8-12 students), zero bureaucratic overhead, a supportive administration and interested parents, the teachers felt empowered to do what they got into teaching for in the first place.
While the US legal system is such that entities can drag even blatantly bogus lawsuits out for years, so winning against individuals and smaller businesses just by attrition of legal costs, fine-tweaking the definition of bogusness wont have even the slightest effect.
I disagree.
In particular, if the courts were to adopt the proposed interpretation, the effect on patent trolls would be devastating. Defendants would be able to make a motion for summary dismissal on the grounds that the patent is a functional patent which under the 112(f) rule must be interpreted in reference to the details of the inventor's implementation, and since the inventor has no implementation there is no possibility of determining the boundaries of the patent and therefore the question is moot. And the motion would succeed. This would reduce such trials from years to weeks, because there would be no justification for a lengthy discover phase.
Even in non-troll cases, it would eliminate the need for most of the lengthy discovery that goes on now, because the defendant could easily argue that all of its internal documentation is simply irrelevant, since the case can be decided by examining the software implementations and determining if they're sufficiently similar. This would still result in trials dominated by detailed arguments from technical experts, so they'd still be expensive, but the cost would be a tiny fraction of what it is now, and it would take far, far less time without all of the extensive (and expensive) discovery.
Perhaps even better, it would encourage inventors (or their lawyers) to write patents which are very specific and narrow, specifically in order to avoid the sorts of broad functional claims which would invoke the author's interpretation of 112(f). Long-term, that would probably be the most important and most beneficial change to the status quo.
Would it be a panacea? Clearly not. But it would make the situation vastly better than it is now -- except from the perspective of patent plaintiffs pushing very broad patents.
If this gets enacted as case law the obvious next step is that Apple will patent the 'for' loop and Microsoft will licence the 'if' statement.
Wouldn't work, for at least two reasons.
First, the patent would have to cover use of an algorithm to accomplish a specific task, and patents that try to cover basic operations like "iteration" would be as successful as patents on "moving objects from one place to another" -- they would be too broad to be accepted (by courts, at least -- the PTO seems to accept everything).
Second, prior art for such basic algorithms as conditional branching is both plentiful and as old as you like -- at least back to the dawn of computer programming, and arguably far older than that.
What is the smallest/simplest functional thing that could constitute an algorithm?
Read the article (it's long, but I found it quite interesting). The author isn't proposing to allow algorithms to be patented -- that clearly isn't permitted at present, and shouldn't be, for a multitude of reasons. Instead, he's saying that under his interpretation of the current federal patent law, patents that say (or imply) something like "a computer programmed to do X" don't cover any software that can do X. Rather, they only cover the specific algorithms and processes the "inventor" used to do X. A competitor who creates a program to do X but who uses different algorithms is not infringing. To give a concrete example, if Samsung used a different algorithm for tracking the finger motion in its "swipe to unlock" implementation, then Apple's patent would be inapplicable. Apple's patent would still be valid, it just wouldn't apply.
This approach would be particularly devastating to patent trolls, because if the patent only covers the particular approach to implementation used by the inventor, but the inventor never actually implemented it, then clearly the patent covers nothing.
I think it's a very interesting idea. It depends entirely on the courts being willing to interpret some subtleties of the current federal law in a very particular way, and one which -- to my non-lawyerly eyes -- seems like a bit of a stretch, though. It will be interesting to see what other patent expert, and ultimately, judges, think of it, but it's certainly got merit. The result wouldn't be to invalidate software patents, but it would make it very, very easy for competitors to sidestep them. Maybe too easy. I haven't quite finished reading the author's section of possible objections to his theory; maybe he addresses that.
Full specifications are available. There is no security through obscurity here.
Doh, managed to delete the rest of my post before submitting. I guess I should actually look at the preview.
Anyway, the problem here isn't obscurity, it's just implementation errors. Granted that the systems should have been audited.