phkamp

Because no words are without context.

You mean: "In 2001 we reinvented XP/Agile because we couldn't be bothered to read the old literature to see if somebody else had done something like that before" ?

I wonder if you bothered to check who wrote that article, before you started speculating about things you could have found out with a few google searches ?

You seem to assume that cathedrals are "slow-moving, centralized, big up-front" designs, where did you get that idea ?

Ever looked into how USA put a man on the moon ?

Maybe you should. Also: Read Brooks book, if you can.

... but evolution will also quite happily run you over a cliff which you have been avoided if intelligence were applied.

Not to mention the fact that the bazaar is never going to put a man on the moon.

And yes, I wrote that piece.

Cleaner for who ? Easier for who ?

That kind of cookie usage just makes it Somebody Else's Problem instead of your problem.

Uhm, isn't that how it works today ? Do you care about how many metric shitloads of storage your cookies take up on client's disks ? Shouldn't you ?

Putting the cost of storage where the decision to store is made is sound economic practics.

They are not wrong because I say so, they are wrong because they are wrong.

When it gets to the point where EU regulates something, the way they did with cookies, it should be painfully obvious to even the most casual observer, that there is something horribly wrong with it.

As for the cost of your HA session-storage ? Cry me a river! You're the one making the money, you're the one who should carry the cost.

Store it on the server: The user-agent gives you a session-id to use as key.

It may be that session-keys should tell if they are anonymous or if they represent (locally) authenticated users, but that's a very complex subject I won't claim to have a clear opinion of yet.

No, servers should hold _all the state_ and clients none. If I add something to my shopping basket from my mobile phone, I want to be able to add more from my browser, rather than have two shopping baskets.

Servers storing stuff on the clients is just plain wrong, and it is wrong from every single angle you can view it: Its wrong from a privacy point of view, it's wrong from a cost-allocation point of view, it's wrong from an architecture point of view and it's wrong from a protocol point of view.

But it was a quick hack to add to HTTP in a hurry back in the dotcom days.

It must die now.

No, they are not. For one thing you have to terminate all your SSL on your loadbalancer in order to distribute the traffic. That makes SPDY a no-go for web-hotels/web-hosting where each customer has their own certificate.

Second, there are perfectly valid legally mandated circumstances which forbid end-to-end privacy, from children in schools to inmates in jail and patients in psych. hospitals, not to mention corporate firewalls and the monster that looks out for classified docs not leaking out of CIA.

You do know that when IPv6 roll-out was initially contemplated, it would happen on IPv4-convertible addresses only, until everybody had converted. That would have allowed seamless IPv6/IPv4 interop and made migration a breeze. Lacking any "must have" features, nobody could see a reason to bother. Now we have to do the migration without the benefit of seamless conversion.

(probably pressing wrong reply link here ?)

Cookies are almost never mentioned in Vary: so all caches have to assume that the precense of cookies means non-cacheable.

The client/user-agent gets to control what session-id gets sent to which sites.

That makes it possible for a UI design where the user can press a button and say "don't surf this site anonymously" with the default being a new random session-id for all other sites.

That will make tracking and correlation of webusage much harder, which I really don't see a downside to.

Deflate is bad on its own, it is a DoS amplifier and it makes the job of load-balancers much more resource intensive, because they have to retain compression state for all connections and spend CPU and memory on the inflation.

The server is perfectly justified in customizing content, and we have a header for saying that is the case: Cache-Control.

The problem with cookies is that they disable caching of everything on the site, including favicon.ico and there is nothing the server can do about it, because the cookies are sent on all requests.

Javascript will also have access to the session-id.

No. Ipv6 is Ipv4 with bigger addresses, it didn't try to solve any of the other problems of IPv4 (or attempts to solve them were killed by ISPs).

One example was multihoming (having more than one ISP) serveral smart proposals were floated (anycast, nearcast etc) but they were killed by ISP's who protected a lucrative business.

If Ipv6 had made multi-ISP multihoming possible without all the trouble of BGP, business would have killed to get it back in the late 1990ies.

Cookies only disappear from the wire, they are trivial to simulate on your server (see my other reply here).

I agree that anybody with sufficient clue can and will use cookies as id only.

Unfortunately such people are evidently few and far between.

Banning cookies and having the client offer a session identifier instead solves many problems.

For starters, it stores the data where it belongs: On the server, putting the cost of storage and protection where it belongs too.

This is a win for privacy, as you will know if you have ever taken the time to actually examine the cookies on your own machine.

Second, it allows the client+user to decide if it will issue anonymous (ie: ever-changing) session identifiers, as a public PC in a library should do, or issue a stable user-specific session-id, to get the convenience of being recognized by the server without constant re-authorization.

Today users don't have that choice, since they have no realistic way of knowing which cookies belongs to a particular website due to 3rd-party cookies and image-domain splitting etc.

Network-wise, we eliminate a lot of bytes to send and receive.

One of the major improvements SPDY has shown is getting the entire request into one packet (by deflating all the headers).

But the only reason HTTP requests don't fit in a single packet to begin with is cookies, get rid of cookies, and almost all requests fit inside the first MTU.

Finally, eliminating cookies improve caching opportunities, which will help both client and server side get a better web experience.

As for breaking the world: It won't happen.

It is trivial to write a module for apache which simulates cookies for old HTTP/1 web-apps: Simply store/look up the cookies in a local database table, indexed by the session-id the client provided.

I'm sure sysadmins will have concerns about the size of that table, but that is an improvement, today the cost is borne by the web-users.

This is more a reflection on where you got your advise in 2003, than what was considered best-practice.

Salting became best-practice in the 1980ies, but the "lost generation" of dot-com wizards never bothered reading "all that old stuff", so they are doomed to repeat the mistakes.

I think you're setting the bar too high for tech journalists, lets aim for them knowing the difference between "md5" and "md5crypt" first.

But no, I don't think it is at all obvious why LinkedIn used unsalted SHA1.

LinkedIn went through an IPO, which implies that a number of companies have audited them from head to tail several times along the way.

If the commodity you buy is millions of user accounts, shouldn't you, as investor, at least check that there was a lock on the door to the warehouse ?

... and since you are not danish, you don't realize that base64 emits the danish word "badeanstalts" and therefore fall to even the most trivial dictionary attack.

I've been offline for some hours, and just wish to add a few concluding thoughts here:

No, I'm obviously not proposing that people do something stupid with crypto, we've had enough of that in recent days already.

But I am trying to provoke one or more card-carrying cryptographers to realize, that while password protection may be a problem we have good and strong theoretical solution for, those solutions will not protect any passwords until somebody turn them into Open Source code we can use.

I only wrote md5crypt because nobody else had done so, and nobody else wanted to do so at the time, and FreeBSD needed an ITAR exportable password scrambler.

If more cryptographers wrote more code under liberal Open Source licenses, instead of bitchy complaints against the people who do write code, then the world might gradually become a better place

I have been dreading this announcement for a couple of years, knowing full well that the majority of the world can't tell MD5 from md5crypt.

It is a credit to hackernews that you could, much appreciated.

Collision resitance is not really a worry for a password scrambler, until the probability gets into the 1e-6 range or above.

I reinforces my belief in humanity that it did happen, I have been pondering for a long time how to do a "People of Earth, your attention please..." which would reach the necessary audience.

MD5 is not vulnerable as used in md5crypt.

Such a toolkit would probably be a good idea.

Tie a card-carrying cryptographer to a chair until he delivers it ?

Yes, of course. I have clarified the text now on this point.

The reason why struct packing would be a win is probably not performance, but code readability and less bugs.

Making be/le/native conversion a job for the programmer is not only error-prone and a waste of time.

The compiler could safely optimize the byte-swizzles away on non-arithmetic operations, whereas most programmers tend to covert everything before they start working on it.

Provided you were prevented from linking objects together which were compiled with different C versions, that would be both better and safer.

The problem with ISO-C's approach is that the chances of having both "#include <stdbool.h>" and "#define bool char" in a codebase of a few million lines are almost unity, and causes bugs which are near-impossible to find, unless you happen to know the intricacies of hacks like this.

In general, optional features in a standard are a bad thing. ISO-C seems to think they are the solution to everything they cannot agree to do properly.

Last time I wrote inline ASM was 2 days ago. I'm a kernel programmer, remember ?

I doubt any language will replace C ever, given the penetration it has, but maybe we could get a better C2X than the crap C1X seems to be. It would require a significant fraction of programmers to agree with me that C1X is crap in the first place.

You're probably right about that, ANSI did a couple of good things, but I'm not sure I think they came out in the black in the end.

ISO on the other hand, seems like a total disaster.

I'm not sure I have a coherent proposal. Clearly ISO-C is a cul-de-sac by now, and will have to be ditched. What we should replace it with is not clear to me.

It is a big problem that so many standards, requirements and tools (from EMACS to Coverity over lint) have their fingers in the C-syntax. The autocrap abomination is a further complication.

So I guess a good place to start is to swear that we will never touch or use the botched ISO-C thread API, and beat some sense into the WG14, by whatever means are available.