problemdomain

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.

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.

3. You're projecting.

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.

> propaganda about frivolous lawsuits?

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.

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.

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.

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.

That's the intersection of the following sets:

* Small companies.

* 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.

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?

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.

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.

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.

Things are hardly so absolute.

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.

> I'm looking from the user's side

From the user's side, proper password storage practices mean your passwords are far less likely to be compromised.

> Surely using your regular account

Uh, and what "regular account" would that be? You assume much, but know little.

> you disagree that there was any exaggeration in that initial statement?

Yes.

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.

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.

> 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.

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.

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?

> 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.

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.