Sir Tim Berners-Lee defends decision not to bake security into www Sir Tim Berners-Lee has defended his decision not to build in security at the onset of the world wide web. It’s easy to be wise in hindsight, but Sir Tim explained that at the point he invented the world wide web 25 years ago, he wanted to create a platform that developers would find familiar and easy to use. Baking in …
Yes, HTML should just be markup.
HTTP should be private. HTTPS seems broken (man in middle attacks).
But POP3, SMTP, IMAP (and all email gateways/MX servers), FTP, Telnet, and HTML are massive fails. Email in particular is wrong in concept from the beginning.
1) There should have been no way to spoof the From/Reply to data
2) A sender only allowed one short query explaining who they are to get Whitelisted with recipient. All subsequent emails to bounce otherwise, including if whitelisting is revoked.
All protocols should have had extensible upgradeable encryption.
I've never been 100% clear if he invented HTML, or the Protocol or both. Non-Internet 'Hypertext' systems (not using HTML) existed much earlier, apart from vapourware such as Project Xanadu. Such as Hypercard on Apple and Futurenet Schematic Capture on DOS, both in 1980s
I was using Internet ages before WWW existed.
So did he invent both HTTP and HTML?.
Sites using multiple unrelated domains are a red flag to me. Even with baked in security that is a serious privacy issue created by the site developers. Sometimes deliberately and sometimes clueless. It seriously annoys me too when I discover a skin or theme I have installed on my own websites is using 3rd party site resources, even if innocently. Stupidity. Please put the JS and CSS dependencies in the the theme / skin files you bloody thicko morons! I don't want those 3rd parties slowing load times, slurping my users IPs and page accesses, later introducing malware on my site or going titsup and breaking it.
So problem isn't what Tim Berners-lee put in or left out but the moronic designers of skins, themes, websites and dammed evil site owners or advertising companies!
It was HTTP - effectively he invented the World Wide Web, which runs on the Internet. As for email, it did what it was designed to do AT THE TIME. How could anyone involved in creating the protocols know what the situation would be in 2014? Hindsight is much clearer that foresight.
I knew email security was broken in 1987 when I was using it. I was even able to use an email gateway in another country to send an official looking Telex to another country. Using a 300 baud modem, a server account, an X.25 account and CP/M.
UUCP was predecessor of email. Even then sensible people worried. The first trojans existed back in pre PC mainframe days.
By 1978 is was obvious to anyone that cared. This is a forty year old problem at least. Or over 100 years old if you include Telegraph spammers in Victorian London!
Mage: "email" <> SMTP/POP/IMAP
The point of the article is that sometimes a protocol becomes adopted because of its apparent simplicity and ease in use and implementation. And after setting up a couple of X400 gateways in the 90's I could see why (while not completely agreeing with it). And many secure mailers still use X400 based exchange.
Same story some might tell about IP vs IPX or even Microsoft vs OS2. While you can wish the world would wait and think before it acts on implementations, that doesn't mean the world will listen to that advice. The world doesn't revolve around finding "sound solutions" but more often about "who is first".
The whole concept of wide area networking security was a moot point when it came to early email systems. UUCP was the best that there was (UUCP is the UNIX to UNIX Copy Program, not just a mail system, although one of the most common uses was mail, and another was remote printing).
Everybody knew it was not secure, because it was a store-and-forward scheme, such that any of the intermediate systems had access to the content. That was just the way it worked, and everybody knew and accepted it.
If you look at basic UUCP, it ran over serial communication lines, often over analogue telephone lines using modem. The concept of it being secure was never even thought about. It was easy to tap a telephone line and feed the data captured through a modem, so it was obvious that there was no security. If you wanted to send something securely, you encrypted it and the uuencoded the result.
There was an encrypted UUCP system which used the UNIX crypt technology. I cannot remember the exact details or what it was called, but it was in the AT&T BNU, but it effectively meant that the data was not transmitted in the clear. But it was still vulnerable on the intermediate host systems.
Saying that it should have been secure is like saying early cars should have been built with roofs, windows and locks. But they weren't.
Anyway. The TELEX system was about as insecure as you can imagine, so that is not a particularly good example.
BTW. To all of the people saying that X.400 should have been the default mail system should remember that SMTP was defined in RFC 821 several years before the initial recommendations for X.400, and they expected to be running over X.25 transport systems, so were a bit weak on the security side as well.
I'm certain that Tim invented HTML (I was with him at CERN). I think he took a lot of inspiration from the publishing layout language SGML ( brief SGML history here)
Synopsis of the story there is an American lawyer named Charles used to plan Stig Blomqvist type car-Rally outings, he wrote these down in a structured way:
26. Left at light onto Jones Rd.
27. (Repeat instructions 20 - 26, substituting "left" for "right".)
28. Second right.
and he gives this wonderful quote Eventually a friend told me that my rally instructions looked like computer programs. I said "Really? What's a computer program?"...
Thanks Charles, Thanks Tim!
> I'm certain that Tim invented HTML (I was with him at CERN)
And I'm certain that Tim and Robert Cailliau invented HTML together (I worked at CERN too and knew them both well). At the time, CERN's "official" text formatting method was IBM's SGML/Bookmaster so we were all familiar with <angle/> brackets already. Tim was familiar with a markup language that Robert had designed some years earlier.
HTTP was mainly Tim, I believe (essentially it started as a fairly quick hack on top of Telnet).
See the book: How the Web was Born, James Gillies and Robert Cailliau, OUP, 2000.
Thanks for reminding me about Robert Cailliau. in fact - as I didn't work in DD but in the PS - I don't ever recall meeting Robert, though I'm sure I will have done at some point. I think everyone in DD (Data-handling Department?) helped in some way to the creation of the WWW - the amount of group-chatter on vxcrna for example was crucial to Tim working on RPC's.
CERN was fairly amazing in that around 7K scientifically-minded people were wandering around the main sites, I had coffee (double ristretto) with, and worked with, eminences such as Abdus Salaam, Victor Weisskopf [Manhattan Project theoretical leader], Russian dissidents - who always wanted a cold beam of pbars at 3am and just generally special ppl.
I'd be sitting at an IBM/VM/CMS terminal typing away some Fortran code for radio frequency simulations, then a quiet tap on the shoulder from a really nice guy "er, do you mind if I use this terminal" - (I was 'playing' whilst Simon van der Meer (Physics Nobel 1984) was patiently waiting to use our only terminal)
I recommend all youth reading El'Reg to do as much STEM studies as they can, then read http://cerncourier.com/cws/latest/cern and write them a letter asking for a job, I did & haven't looked back!
I’m not sure that I do agree with the idea of ‘always on’ security - that creates a two layer network, those who can afford to buy certificates, and those who can’t. Those who can’t may end up being marginalised and the only people who will benefit are Verisign, Thawte, GoDaddy and so forth.
Sure, security is required wherever personal details and banking information is involved - but everywhere else, not so much. If I just want to browse El Reg and have a chuckle at the articles, what benefit does a secure connection offer me?
"I’m not sure that I do agree with the idea of ‘always on’ security - that creates a two layer network, those who can afford to buy certificates, and those who can’t. Those who can’t may end up being marginalised and the only people who will benefit are Verisign, Thawte, GoDaddy and so forth...."
OK, try this simple substitution to see if you think everyone should be left vulnerable to burglars just because locks cost money:
I’m not sure that I do agree with the idea of door locks, that creates a two layer society, those who can afford to buy locks, and those who can’t. Those who can’t may end up being marginalised and the only people who will benefit are Yale (the padlock maker) and so forth.....
"OK, try this simple substitution to see if you think everyone should be left vulnerable to burglars just because locks cost money:"
OK, I'll bite. Locks can present a FALSE sense of security because a determined crook can defeat (kick the door down, pick the lock) or bypass the lock (go in through the window). Frankly, the only methods that would really be effective against a determined adversary...the average man can't afford.
"....Locks can present a FALSE sense of security because a determined crook can defeat (kick the door down, pick the lock) or bypass the lock (go in through the window)....." So if they deter, say, the 75% of burglars that do not have the knowledge to circumvent the security, the lock is still partially effective and better than nothing. The original argument was that no-one should have certificates due to a few not wanting to spend money on them, not their relative effectiveness (and the certificate system is definitely not 100% effective, not even close!). If I had a system of keeping at least 75% of burglars out of my house then I would consider that a good start.
@Matt Bryant
It’s a poor analogy because I own the house and its contents, and its my contents that I’m trying to protect.
A better analogy would be if I owned a park, and I want people to come and visit (for free, because I’m a generous and caring kind of chap). In the park I have various amenities. I have swings, and slides, a duck pond, grass for picnicing on, loos and storage for any bags that visitors don’t want to lug around all day. Does it make more sense for me to
a) provide locks for the loos and the storage (areas where security is required)?
or
b) in addition put locks on the swings, the slide, the duck pond and so forth as well?
In the case of a) my visitors benefit, and the cost to me is kept reasonable. In the case of b) the cost is astronomical and it’s a perfect bloody nuisance.
Security where security is required (and make it bloody tough). No security everywhere else.
Vint and Tim are both correct, I don't see a contrast between their statements. Security should have gone in at the transport or session layer and we could have avoided the shitness of secure sockets, which has only really succeeded at generating enormous personal wealth for a few lucky individuals who got in on the game early.
But as Tim noted, security is computationally-intensive, and recall what the top of the line was in 1990: the 80486, about as big a leap FROM the 6502 as it is TO today's tech. And if this was top end, imagine what else was still in use. Now imagine always-on security in such a world...
As for secure communications, you hit a snag when you have the competing needs of secure communications and efficient communications. Efficiency necessarily leaves telltale trails that can be analyzed (so it's easy to trace something like a video stream since it's time-sensitive) while secure communications necessarily introduces false trails or "chaff" that cost bandwidth and in turn electricity (that's one reason why Freenet's so slow). Plus there's still the matter of subverting endpoints outside the secure network, a practically-intractable problem as long as computers are available to the public. Furthermore, the average user can't be trusted to be perfectly vigilant, which leaves plenty of other openings and instances of being locked out.
No, I suspect the reality is Tim 'Nice but dim' Berners-Lee was simply (or maybe willfully) blinded by idealism to realise human nature made it inevitable that some people would 'do evil', and now he's backpedalling to try and hide his mistake. Given the number of prior security worries at the time of creation, you either have to think Tim forgot about security, or deliberately ignored the problem to ensure his simplified system was accepted faster. The former can be passed off as idealism, the second unfortunately implies he shafted the lot of us just to get his pet project going faster.
Or if he had baked in security:
1, he would have got it wrong - even experts get it wrong so the chance of a regular programmer inventing ssl and implementing it correctly is zero. So we would have had a built-in faulty standard.
2, It would have been too difficult for anyone else to use/implement so we would have no browsers/servers outside CERN.
3, Without an infrastructure of certifcate providers the only response would be to use something like existing "x." protocol family security. Which would have involved governments. So anyone copuld have had a website if the postoffice approved your licence request.
4, It would have hit export issues. No web browser/server software could have been copied from the USA. There would have to have been government level negotiations for a "munition" to be transferred from CERN to other institutions.
That model is daft and broken.
Of course you shouldn't have to buy certificates. It doesn't even work!
1) How often have you been told cert of MegaCorp site is invalid or expired?
2) How often have miscreants obtained certs?
3) HTTPS (which is what they are for) isn't even secure anyway. Evil SW on a Café or Hotel WiFi point, Or Government / Evil ISP on an ISP's router.
Trouble is, consumers get irritated no matter what you do. They get irritated with ads, they get irritated with pay gates. Hell, they get irritated just standing in line and losing a minute or two to something else they need to do. And different people get more irritated to different things, so you can't win, really.
Same goes for personal information. It's just like any other kind of information. Once it's passed to someone else, you can't safeguard it anymore. Which means if you MUST submit information in order to conduct business, you're hosed.
I have a little internet box from around turn-of-the-millennium. It supports 40 bit SSL. Only.
What came before? Nothing - it was a day when various governments freaked out over private citizens being able to encrypt stuff and they called such software "munitions".
Any secure protocol from back then would perhaps have had to work well on late-Z80, early x86 machines. An algorithm that runs fast enough not to be an impediment on an dual-digit MHz box would likely be something that a modern CPU+GPU combo can crack near realtime. (HTTP 0.9 dates from 1991, the then-current x86 chip was the i486DX clocking 25, 33, or 50MHz)
Look at WiFi. WEP? Compromised (easily). WPA/TKIP? Compromised. WPS? So laughably piss-poor that I wonder how it ever got accepted. WPA2/AES is our current "secure", but I wonder for how long that would remain true.
There was a messaging protocol developed that had security built in - X.400. But this proved too difficult for lazy and/or incompetent programmers to implement and test. An alternative was then developed to cater for these programmers, and it is called the Simple Message Transfer Protocol and runs on TCP port 25. Had the programmers taken a little effort, then we would be spared the deluge of spam and other types of fraud. An entire industry would not need to have been born.
So perhaps Sir Tim has a point.
In one of life's little ironies, X.400 is used in "Military Messaging" - however they call it ACP 123. If this had been used instead of SMTP then the insecurity agencies and secret police would have had a much harder time spying on us.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
