bct

"Must" doesn't have to imply legal force.

The key phrase being "In the long run". We won't get to that idealized reality if we make the wrong decisions in our current reality.

There was a big thread on the OAuth mailing list about this a couple of months ago. The official response seems to be "don't use native applications that you think might phish you", which isn't very satisfying.

I'm not sure what the alternative is, though, and OAuth is still a big improvement for the web app client use case.

I must not have been very clear, because I'm being pro-OAuth here :)

No, that's not what I meant. It's an analogy - if sites shouldn't store their own passwords in plaintext or reversibly encrypted (which everyone here agrees on - "use BCrypt", etc), then they shouldn't store other passwords in plaintext or reversibly encrypted. They should use something like OAuth instead.

I'm not sure why it matters either way; it's not like he's going to send goons to your house if you don't release your source.

There's a place for both approaches. I agree with kiba that with video games (and websites, and lots of other software for that matter), novelty is weighted much too heavily.

> A well-behaved app can have your password and do no harm.

Until someone steals its database.

You hash your user's passwords, right? Same thing - whether you're talking about your app's passwords, or some 3rd party app's passwords, keeping them around in plain text is a bad idea.

> You could get all the meaningful functionality of Oauth by letting apps request a single "permission key" when they login - with the user's password.

http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-1....

But he does not say "just a sandbox", or otherwise imply that a "coding sandbox" is less valuable than a non-profit organization. They're different things.

> 4. Condescension. "It's impressive for what it is" ... (but "what it is" is "just a sandbox")

You're jumping at shadows and putting words into his mouth. What he said was:

> Git is an impressive tool and github is awesome for what it is, but it's not a non-profit foundation and it won't replace one.

Which doesn't imply the same condescenscion as your "quote".

> ...create your own session script to start up the parts of Gnome that you want along with XMonad...

On Ubuntu at least I've had success with http://markhansen.co.nz/xmonad-ubuntu-oneiric/

(Having the launcher floating around is annoying though, and removing it from the gnome-session file had some unpleasant side-effect that I don't remember.)

That it's possible now with most hardware doesn't mean much. There are powerful entities that have been working for years to ensure that open source is only possible where & when it suits them.

New devices are much more locked down than they would have been a decade ago. That's not an accident or a fad.

Open source software is useless if the hardware only runs code that's been signed by the manufacturer. This is exactly what GPL3 is about.

Why does everything have to be a business opportunity? Prioritizing monetary value over other kinds of value is how we got into this mess in the first place.

Disappointing. "We can beg other powers to intervene" is not "we can fix it".

Or, to put it another way, there are two different kinds of semantics in play; the semantics of a document (this is a title, this is a paragraph, ...), and the semantics of the subject of a document (this is the price of the item, this is how many we have left in stock, ...).

The costs and benefits of enhancing one are different and separate from the costs and benefits of enhancing the other.

The conflation of "semantic HTML" with "the semantic web" has done immeasurable harm to both causes.

Yes, debating whether to mark up your forms using UL or OL or LABEL or SPAN or DIV or DL or TABLE or ... is a total waste of time. That doesn't tell us anything about the usefulness of machine-readable linked data, though. The two subjects have nothing in common except a relatively unusual adjective.

> Rolling release isn't quite the same, because you still get frequent updates to "core" software.

You don't have to install updated versions unless you want to.

Gentoo and Arch are the ones that come immediately to mind. The term to look for is "rolling release".

There always been distros that work like that. There's no such thing as the "Linux mentality" that you're talking about.

Software is only obsoleted by some other software getting adopted in its place. How well adopted a piece of software is is only vaguely related to how innovative it is, how technically sound it is, etc.

You're reducing a complex problem too far.

> The free software approach seems to assume that what a computer should be and do has already been decided and they just need to make free versions of everything.

That's really not the case.

> The most popular computers and electronics in the world are Apple products because Apple innovated.

That's part of it, but there were also huge quantities of marketing and money involved.

No technology wins on its own merits.

> But certainly the client needs to know something about the base resources

Yes, it needs to understand how they're represented, what types of links they might have to other resources, etc.

A good example is the Atom Publishing Protocol (RFC 5023). It's specified entirely in terms of representation formats, resource types, and the actions that can be performed upon those resources.

It's worth noting that this is not a new idea. In the late 60s there were at least a dozen research projects working on this.

http://en.wikipedia.org/wiki/Aramis_(personal_rapid_transit)

Maybe technological advances have made it more feasible. I guess we'll see.

> HTTP auth doesn't make backend authentication code easier to write.

It makes it easier to shove into a library or middleware.

Most of the issues you list are UI problems that could have been solved with a non-modal login prompt, a "remember this login" option, and a "stop sending the Authentication header" button.

My point isn't that existing HTTP auth schemes are great, because they're not (even if they weren't saddled with a terrible UI). It's that migrating from those mediocre schemes would have been easier than migrating from the mediocre schemes we're using now will be.

A decent UI on top of HTTP authentication would have been an improvement, and it's something that more sophisticated systems can be built on top of while maintaining compatibility.

How many username/password forms are there on the web? Millions? They function basically identically, but they all had to be written (or at least configured) independently. It's outrageous when you think about it, as if every language required you to write your own string library before you start coding.

The system smells; the problem is being solved in the wrong place.

The sad thing is that 15 years ago this could have been solved easily. Now any solution has an uphill struggle.

Zooko's triangle[1] in action:

A BrowserID (like an email address) is memorable and secure, but not decentralized (it's centralized in DNS).

A cryptographic key is decentralized and secure, but not memorable.

Systems that are memorable and decentralized, but not secure, don't address these use cases at all.

(And then there's Namecoin[2], which is a fascinating development, but not likely to see broad adoption in the near future.)

[1]: http://en.wikipedia.org/wiki/Zookos_triangle [2]: https://en.bitcoin.it/wiki/Namecoin

Google/Yahoo/etc. could have given you a memorable OpenID if they wanted.

It's a good point though, the fact that email addresses have to be somewhat memorable/human-readable by nature is a good thing for BrowserID.