I wouldn't want a jury of "patent specialists", I want an inquisitorial panel including professional judges, laypersons, and technical (not "patent") specialists with the power to actively seek truth out in the open, and I want it for all cases. The adversarial system has overstayed its welcome.
1. That's like saying a law against speeding is valid, so the defendant is probably guilty of speeding. That a patent is valid says absolutely nothing about whether a defendant is infringing it.
2. Sorry, all I can do is laugh. Do you actually follow the US legal system?
3. Again, whether a patent is bad or not has nothing to do with whether it's infringed in any particular case.
1. The numbers you're quoting sure are. Look at the chart and surrounding text again. And all you said was "Plaintiffs were only winning 20-40% of the time.". "Winning" in a patent case hinges on infringement. If you're not talking about infringement, what could you possibly be talking about?
2. That's not an answer to the question I asked, it's an irrelevant and evasive appeal to authority.
1. I was talking about validity. A hint to that effect was that my sentence explicitly talked about the burden of proof of patent validity. To win a patent case, you must have a valid patent and that patent must be infringed. The plaintiff enters the case with an advantage by law on the validity issue, which was the point of #1.
I dealt with why the plaintiff has an advantage on the infringement issue in point #2.
2. You asked: "Do you actually follow the US legal system?"
I answered: "Yes". Please explain how that is not an answer to the question you asked.
You've done nothing to explain how the presumption of validity implies the plaintiff will ultimately win, nor how my analogy to the validity of a law is wrong.
If the answer were really just "Yes", you shouldn't have felt it necessary to bring academic credentials into the discussion, instead of just leaving it at "Yes".
We know from history that extremely weak cases are filed all the time, usually hopes of attempting to force a settlement, and that there have been few effective barriers to such tactics. There were even fewer barriers during the era before the Federal Circuit came to be.
Your bald assertion about "weak" cases being weeded out is contradicted by real-world observations of both the distant past and more recent history.
In most cases I disapprove of flaunting academic credentials to strengthen an argument, since that is just appeal to authority. But in this case I feel it was relevant to your question.
In this case he wasn't arguing that people should give more weight to his answer because he went to law school. Rather, he was responding to someone that asked if he knew anything about the law. As a response to that specific question, giving a context for how much he understands based on his background seems valid.
You never know when the person you're bitching at on HN has a law degree. But now that it's clear that you don't: your objection is silly and the person you are objecting to knows more about this issue than you do.
> 2. Sorry, all I can do is laugh. Do you actually follow the US legal system?
Do you follow it deeper than the propaganda about frivolous lawsuits?
> 3. Again, whether a patent is bad or not has nothing to do with whether it's infringed in any particular case.
He's not talking about particular cases, he's talking about aggregate statistics. A system with a lot of weak patents, where people might independently come up with the same design because it's obvious, is going to have a lot more infringement than a system with only strong patents, where infringement is likely to come from only purposefully copying a design.
Oh please. This isn't about ambulance chasers, I'm not some right-wing nut who thinks corporations need to be protected from the unwashed masses. This is about things like patent and copyright trolls.
> He's not talking about particular cases, he's talking about aggregate statistics.
Justice is not decided based on aggregate statistics.
This annoyed me when dealing with net/http the other day. Really seems like the Go team hasn't spent much time thinking about problems on the client side of connections yet.
This isn't true. First net and net/http are great. Second, there are examples all over the ML (even within the last three days) that shows how to create an http client with a timeout-able Dial() function.
james4k just posted a link to the source where the comment by Brad Fitzpatrick actually says it's broken in the manner under discussion.
// TODO(bradfitz): the timeout should be pushed down into the
// net package's event loop, so on timeout to dead hosts we
// don't have a goroutine sticking around for the default of
// ~3 minutes.
* With some legal or contractual obligation preventing use of a public IRC server.
* But not preventing use of a third-party outside-the-firewall solution.
* And not having any criteria for the third-party, such as HIPAA compliance, warranties/guarantees, etc.
Seems a pretty small set...
Interestingly, grove doesn't seem to promise not to disclose the archives of your "private" server at all. Lots of ass-covering in their Terms of Service in favor of grove, and they have a privacy policy pertaining to their website, but nothing I could find about not telling the world whatever you happen to send their IRC servers.
It should take you 30-60 minutes to setup an IRC server depending on how familiar you are with, well, Unix. 0 minutes of maintenance per month. And once it's done, you can have dozens, hundreds, even thousands of users on it for a marginal cost rapidly approaching $0/user. In contrast, by the time you get to 50 users on Grove, it's $125/month.
I very much get the "pay someone else to worry about it" thing, but private IRC servers are so insanely simple, low-cost, and low-maintenance that grove's position seems abnormally tenuous.
Edit: There's something else very odd about their pricing. On their lowest plan, the nominal per-user cost is $2. On all the other plans, with the exact same features, just more users, it's $2.50. A price structure that directly incentivizes not upgrading, however slightly, is very backwards.
30-60 minutes to set up not only an irc server, but a persistent web client, archiving, and full-text search over channels and private chats? The value for me is seeing what happened after I'd left work yesterday, or finding a discussion/links that were posted a few days ago.
You've just done a better job of marketing grove in two sentences than grove has ever done itself. That's really the point. As it stands, grove.io markets itself as $10/month for 5 users to chat.
The first two words anyone is going to read on grove.io: "Hosted IRC".
Right about there, 80% of people are going to ask "What's IRC?". It's never explained.
"and so much more." Like what?
"plus additional features"... uh...?
"Why Grove is better". Better than what?
Oh look, a feature. Almost, if not completely on some screens, below the fold. "Archives and search"... of what?
Finally, "chat logs". Oh, it's something to do with chat. Well, I already have that!
If anyone even bothers to look at pricing, they're going to wonder why they want to pay somebody for all this.
Meanwhile, at least half the people who already know what IRC is are unimpressed. "IRC? Who uses that anymore? We have IM now. It's free. I even have logs.". Oops. Same problem.
Edit: Meanwhile, an experienced IRC user like me: I run irssi in screen on a reliable server. All my channels and private messages are logged, and I know how to use grep. What's grove for again?
This. Most IRC servers (ircd-seven, InspIRCd, UnrealIRCd, etc.) are rock solid and require very little maintenance if you're not doing more advanced things like linking to other servers, linking to services (ChanServ, NickServ), etc.
Throw ratbox and charybdis into the mix, too - very solid pieces of software!
It is very easy to get any of these running and if you read the docs (or the comments in the config files) there aren't many gotchas either. I wouldn't say they're zero maintenance, but they are fairly low - the majority of the maintenance you'd still have with a hosted server, as it's getting things working exactly how you like, and dealing with troublesome users!
One other point that springs to mind: if people want a free alternative to running their own server or using grove, there are lots of good IRC networks to choose from that will host your channel for free.
There's something else very odd about their pricing. On their lowest plan, the nominal per-user cost is $2. On all the other plans, with the exact same features, just more users, it's $2.50. A price structure that directly incentivizes not upgrading, however slightly, is very backwards.
That's where our nerdy brains go when confronted with pricing plans, but I'm not sure that the person actually buying this would see it the same way. Imagine that you're a business and you're paying for tools so your employees can actually get work done and make money. Do you really think that when you hire employee #6 (probably for an all-in cost of six figures), you're going to be scrutinizing the bump from $10 / month to $25 / month and trying to figure out what your per-employee cost is? Umm...no. You're going to hit upgrade and move onto something more productive. Or you're not going to be employing anyone for long.
I think they need to revamp their marketing speak and triple their pricing.
I disagree pretty strongly with your comment re: pricing model. For services like this, the incentive to upgrade is going to be there regardless of price, since there's a strong incentive to have your entire company / department using the same tools.
Atlassian is a great example of an extreme version of this. The cost for me to have 10 users (on-premise, but hosted is similar) is $10 ($1 per user). The cost to have 11 is $800 ($75 per user).
It's a smart, if unintuitive pricing model - you can demonstrate the value of your product to cash-strapped startups that are going to be extremely cost-conscious, and start charging more on value once the company has started to see success.
I've never setup that particular ircd, but regardless of what ircd you use, once you add separate services to the mix, you're making life unnecessarily difficult. Separate services daemons are not needed for private IRC servers.
Right, agreed. Services really were the hardest part of it, come to think of it. In this particular case, I was setting up the server for an intended non-private network.
A couple years ago I ran tests on an embedded Broadcom platform (7413, clocked at 400MHz IIRC) because I wasn't sure what was reasonable for SSL certificates when a box like that was involved.
I ended up using 2048 for both the client and server certificates. 4096 on the client would have taken several seconds to negotiate, and 4096 on the server was too expensive for the number of clients I wanted to pack onto a single server. (Also, I didn't have proper control of the entire client software stack, and the behavior of part of it with regard to session management and keepalive was extremely non-optimal.)
Based on that experience, I don't think I'd really want to use a 16384-bit key on a low-resource system anytime soon. Right now, 2048 ought to be plenty for any information that doesn't have to be kept secret over a very long time horizon (decades, at least), and anything over 4096 is getting pretty paranoid. 16384 seems obscene.
The United States Constitution is the highest law, and provides for different treatment of foreign and domestic matters, so your statement is obviously false even under the most broad interpretation of "the government".
The President/Executive (closest to what many other countries would consider "the government") is also limited in most matters by the laws passed by Congress, so even assuming domestic regulation of cryptography were Constitutional (and I don't personally believe it would be), if Congress has not passed a law giving the Executive the authority to regulate it, the Executive cannot do so.
It's hard to "take the time" to read a story behind a paywall when you have no desire to give money to the entity owning the wall.
Based on the publicly-available information, it's not clear that Google did any such thing. They might have refused, or Apple might not have liked their terms, or Tim Cook may have held a seance to get advice from the ghost of an angry Dijkstra, or a hundred other scenarios of varying plausibility. It's hard to say.
> I like this attitude that says because you can't find the source Gruber is quoting, some random counterfactual must be true.
I didn't say that at all, and you don't have the excuse of not having access to the entirety of my publicly-available comment. I don't consider it implausible that Google refused, I simply have no basis for believing that over other plausible scenarios.
My point is that that article is not available to me or the public at large. You can't expect to cite secret evidence and have us just believe everything you say. You're not Dick Cheney.
I'm done replying now, since you don't seem to be getting it.
By this logic, Taco Bell burritos aren't available to me or the public at large because they cost like 79¢. Yet somehow Taco Bell makes millions off these unavailable burritos. It's almost like you're not being reasonable here.
Just because something takes a modicum of effort to obtain doesn't mean it's "unavailable." You can either pay a modest sum for the Wall Street Journal or just go to a library and read it there. It is readily available. If you choose not to read it, you don't then get to pretend the evidence therein does not exist.
Google Maps was not rolled out to a hundred million preexisting devices in an abysmal state to replace a working solution, and for its entire existence has competed in a landscape where it has had major advantages over competitors, either on the basis of quality, or on the basis of price.
If I crafted a questionable replica of Windows 3.11 and went out and installed it on a hundred million computers that had been running Windows 7, would you defend me because Microsoft had to go through growing pains, too?
"Apple Maps" is late to the party, and forgot its clothes. Why be surprised at the response?
You're fundamentally misunderstanding the problem domain.
At the highest level, you're missing the issue of specialization and parallelization.
This misunderstanding is partly alluded to by your surprise at the power of GPUs to hash passwords. GPUs can have hundreds or even thousands of what you might think of as "cores", but they're very specialized cores that are only suited to certain kinds of operations. Those operations were originally intended for the problem domain of high-performance graphics, but as it happens, many of those same operations mesh very well with cryptographic hashes. In essence, we've all got specialized massively-parallel password-cracking supercomputers sitting on our desks.
Take this up a level, and you might see the most obvious implication: More $500 graphics cards, more passwords cracked in a given timeframe. Very naïvely speaking, 7,000 $500 graphics cards, $3.5 million. You've just gained the ability to hash every one of those 12-character strings in one year for the cost of a funding round. Oops.
Relatedly, you're talking about cracking a password. That's wrong. Nobody cares about cracking your password, or my password. They're going after passwords, in a massively plural sense.
Start with 100,000 md5 password hashes. Assume the passwords are all 12 characters (they're not) and they're randomly generated (again, not). You don't conduct a brute-force search for every hash, you conduct a brute force search for 100,000 hashes. 7,000 years divided by 100,000 hashes is 25.55 days. With a $500 graphics card, the crackers can brute-force a password every month.
Now, once you realize that the entropy in the average password is not even within an order of magnitude of 60^12, you might begin to see the problem. You'd be lucky to find a password that's 36^8.
That purported 7,000 years is starting to look a lot smaller, isn't it?
This is why we have things like bcrypt and PBKDF2.
>"7,000 years divided by 100,000 hashes is 25.55 days." //
This only works if hash reversal costs the same as hash calculation. I think you've made an error.
Brute force in hash terms doesn't mean a "search" it means you take a string, hash it and see if the hash matches. That's the brute part, no grace.
The 7000 years figure is clearly vastly inflated what's needed for passwords in the wild but I'm merely countering the contention that 'md5 is as good as plaintext'.
I note that despite it apparently only taking seconds to reverse my short string that no one has posted the plaintext yet. This doesn't look like it is as easy to read as plaintext.
I'm not at all claiming md5 is good security - just suggesting that the claim that md5 is equivalent to plaintext is hyperbole.
The easy way to show that I'm wrong is to post the plaintext of that hash.
> Brute force in hash terms doesn't mean a "search" it means you take a string, hash it and see if the hash matches.
A) That is a search, and B) I know this. You are still fundamentally misunderstanding the problem domain. We don't care about a hash. We care about 100,000 hashes. You don't need to brute force every single hash from scratch, you simply have to take a string, hash it, and see if that hash is present in the table of 100,000 hashes.
> I note that despite it apparently only taking seconds to reverse
No one claimed that, you inferred it based on a fundamental misunderstanding of the problem domain.
Ha ha. Not really. You're not searching for the plaintext that produces a hash. You're producing hashes irrespective of the result and then matching. IMO the term search would only truly apply if you were reversing the hash mathematically - you'd start with the hash and perform a non-complex operation to find the plaintext.
Instead one searches across hashes after compiling a correspondence table, not across plaintexts. I suppose it's a subtle distinction; largely irrelevant to my contention.
>you inferred it based on a fundamental misunderstanding of the problem domain //
I did not infer it. It was implied. For example,
emidln: "md5 passwords lists are plaintext for modern hardware"
So yes, I suppose adding on a few seconds for plaintext recovery was unfair of me, based on a comment like this I should have said "I note that despite just having to read it back almost as quickly as plaintext ...".
WRT the problem domain. You're discussing an entirely different issue to that which I raised. The start point is simply this:
>"MD5 is an utterly terrible password hash. It's just about as bad as plaintext." //
That is the pertinent problem domain for my comment. I even went to efforts to emphasise that beyond that atomic claim I was recognising the paucity of md5 for real world password hashing - I don't think one can have used Rainbow tables and not realised that point. Are you really contending still that md5 is almost equivalent to plaintext in terms of string discovery and that there is no exaggeration in that.
If the IEEE logs were released with md5 hashed passcodes then other than trivial recognisable cases like 2867-whatever-it-is then one at least has to do work to recover the plaintext.
Aside: I'm intrigued why you created a separate account just to press this position.
The question of password hashing does not concern a password, it concerns passwords. This is a textbook case of being unable to see the forest for the trees. I'm actually astounded by how closely the idiom matches this case.
A simple MD5 hash is "about as bad as plaintext" because the vast majority of passwords will be trivially cracked if it's used, not because any one password will be cracked in a trivial timeframe.
masklinn was speaking against this background. You've created a whole other background that just isn't relevant to the real world issue of password hashing.
> Aside: I'm intrigued why you created a separate account just to press this position.
I created an account so I'd have one to respond to your comment with. The choice of name does not mean it's specific to this discussion, it was simply inspired by it. Again, you focus on an individual detail to the detriment of the big picture.
>Again, you focus on an individual detail to the detriment of the big picture. //
Ostensibly the difference here is that you're looking from the administrative side (it appears) and I'm looking from the user's side.
As for "again". Surely using your regular account makes for a bigger picture as I could see where you're coming from, your general demeanour, your desire to argue incessantly around the point whilst not broaching the point itself, that sort of thing. From your side the choice of name as specific may well be "the big picture" but from anyone else reading the discussion you've removed a lot of out-of-band information that could be pertinent. Which to be honest makes me chuckle as you accuse me, probably rightly in this instance, of narrow focus.
>A simple MD5 hash is "about as bad as plaintext" because the vast majority of passwords will be trivially cracked if it's used //
With plaintext all passwords will be "cracked" in zero time. With MD5 good passwords will be expensive to crack. ROT-13 is about as bad as plaintext. MD5 IMO is better to a point that this claim was exaggeration.
So we'll go straight to the rub - you disagree that there was any exaggeration in that initial statement?
>proper password storage practices mean your passwords are far less likely to be compromised //
Indeed and considering I'm using 20 char mixed passkeys if they're hashed with md5 then they'll take zillions of times longer to reveal than plaintext ... oh wait, no they won't because plaintext is about as bad as plaintext - and you appear to believe that is from any perspective ...
So go on, 3 days must be plenty of time to read something that's about as bad as plaintext at remaining unread.
>You assume much, but know little. //
There is nothing certain, not even this. However pyrhonic absolutism gives sway to pragmatism in general conversation.
So, what, never post on HN, create a new account for each thread, enter comments direct to the db using a morse key ... what? I'd hardly call the assumption that you had an account that you used in the normal way to be massive.
