Tim Berners-Lee on the Web 224
notmyopinion writes "In a wide-ranging interview with the British Computer Society, Sir Tim Berners-Lee criticizes software patents, speaks out on US and ICANN control of the Internet, proposes browser security changes, and says he got domain names backwards in web addresses all those years ago."
A true Brit. (Score:5, Informative)
So the idea that he started off having trouble with the Berkeley naming convention doesn't surprise me at all.
(I'd prefer a more heirarchical system, myself, where an organization can ONLY have one domain name and have all their actual addresses inside of that. It would make the namespace a lot less cluttered and would reduce trademark abuses. On the other hand, names would be a lot longer. However, if you're using a search engine, a portal or bookmarks most of the time anyway, that's no big deal.)
Re:'Duh' Browser security (Score:2, Informative)
Re:'Duh' Browser security (Score:2, Informative)
Re:'Duh' Browser security (Score:3, Informative)
We made a mistake back in the day.
We made many mistakes, but this wasn't one of them.
Certificates are serving two purposes: One is to encrypt the data, one is to verify identity.
Those two purposes are the *same* purpose. There is a distinction here, but you're drawing it in the wrong place.
SSL-sytle secure connections do two things: Encrypt data and authenticate data. After establishing session keys, the data that is sent both directions is encrypted and has cryptographic authentication codes (MACs) attached. Those two things are different, and the two parties communicating may each require one or both.
If either side is sending sensitive data that should not be revealed to others, then that data should be encrypted. But if the data is sensitive and should not be revealed to others, why would you send it to a random stranger? Verification of the recipient's identity is crucial. If the client is sending the sensitive data, this verification is generally accomplished via SSL validation of the server certificate. If the server is sending it, it's usually provided by performing a username/password authentication within the SSL tunnel, though it can (and more often should!) be done with client side digital certificates.
If either side is sending important data that doesn't necessarily need to be encrypted, but does need to be authenticated, then that data should be MACed. SSL does that, as well as encryption. But if the data is important and its provenance must be verified, then the identity of the sender must be identified. For the identity verification needed for data authentication, we use the same verification mechanisms: cert to identify the server when it's the sender, and username/password to identify the client when it's the sender.
There is no point in encrypting data to strangers, or authenticating data from strangers. Identify verification is absolutely essential to all of it.
There is some point in separating encryption from data authentication, because sometimes you need the latter but not the former. Even in those cases, though, encryption never hurts (especially since IP communications are all point-to-point anyway, since multicast doesn't work), and encrypting unnecessarily doesn't cost anything, so it's simpler just to do both.
*With* identity verification. Keeping in mind that DNS does not provide any identity verification, and that even if it did, the multi-hop routing of IP packets means there are plenty of opportunities for men in the midddle [wikipedia.org].
ISO8601 date format! (Score:2, Informative)
I find 2006-03-26 to be most useful
Good, because it's ISO8601 [wikipedia.org], a great universal worldwide standard. Get all the blogs, bulletin boards, web pages, etc. you use to standardize on it, so many of them are still stupidly trying to localize a WorldWide-Web with "26/3", "03-26-06" or other abominations.