Hacker News Reader

Comment by meaty | Hacker News Reader

Looking at the holes and crocks of shit we see every damn day related to HTTP, HTML, JavaScript and the whole programming model that surrounds them, it's about time someone just shot it all and started again putting security and privacy first rather than playing whack-a-mole all the time.

Unfortunately I fear this is not possible based on the sheer momentum that this ball of sticky tape and string has.

I think the sheer number of articles that paper HN all the time over browser and protocol vulnerabilities, leaks and problems back up my assertion.

EDIT: just to add, my frustrations are based on having to spend 5 hours porting some JS code so it works properly on all browsers.

View on HN

If 20 years ago some clairvoyant genius had foreseen what web applications would become, and decided to create a sane and secure alternative, and by some miracle had managed to pull it off without falling into numerous tarpits owing to an unsinkable combination of intelligence, persistence and vision, it still never would have taken off because it would be too complicated to gain traction compared to the simplicity of HTML.

The key thing you need to wrap your head around is that software ecosystems are not designed; they accrete and evolve organically, and no one has any power to change that.

It is called the desktop.

No. The desktop is not cross-platform, cross-media and installation free. Your flippant dismissal of the real advances that the web brought to common computing renders your opinion moot.

Neither is the web.

As consultant, part of my job is to do web applications when the customers demand it, and web development is everything but cross-platform.

The amount of hacks one has to write to have CSS, JavaScript and HTML working flawlessly across all desired operating systems, browser versions and handsets renders the cross-platform argument moot.

As for installation free, the same is possible with the desktop applications as well.

There's never been anything in the history of computing that is 10% as cross-platform and cross-media as the web. Your head is firmly embedded in the sand my friend.

> Your head is firmly embedded in the sand my friend.

I could say the same...

You mean you could make a statement about my ignorance in isolation, but you obviously can't make a statement that supports that opinion. If you want to make outrageous claims like desktop programming is cross-platform and cross-media then you need evidence, you can't just proclaim things like "desktop programming can be installation-free". You need evidence. Especially since you were responding to my post and going off on a bizarre unrelated tangent.

> desktop programming can be installation-free

Just provide the software in a zip package with all its required dependencies.

No installation required.

There are lots of ways to write multi-platform desktop software. I have been doing it since the early 90's.

Maybe the web is the only way for script kiddies to develop applications...

Obviously you have no idea what installation-free and cross-platform mean.

My accountant seems to be pretty happy with my ideas...

What does that have to do with anything?

It's an Internet Explorer vulnerability. Shell level IE exploits are one of the reasons Firefox and Chrome have done so well, because they're more secure. Don't paint every browser with the same brush.

An interesting statement, which would be more interesting if backed up by facts. All brothers are basically virtual machines running remote code, how could they be secure?

Yes I know but the sheer number of articles aggregated across all browsers point to the architecture of the web being completely flawed.

Consequentially, they're all as bad as each other.

"More secure" is subjective i.e. it's more secure to us public but who the hell knows there aren't 100 zero day's out there in the wild changing hands for thousands of dollars.

I think you're being needlessly dismissive of how hard a problem it is. There are legitimate use cases for capturing mouse position. You could certainly make a secure browser, but you're also going to strip it of much of the functionality that we enjoy today.

The problem doesn't exist because people just aren't paying attention to security, or because the entire architecture of the web is flawed. The problem exists because it's a damn hard problem to deliver arbitrary executable code to clients on demand and let them run it and do useful things with it without compromising security and privacy. The browser vendors have really stepped it up in the last few years, and it takes a very narrow view of the web to see otherwise.

Not really. It's not a hard problem to solve if you start at the right end of it rather than retrospectively apply it.

Capturing the mouse position is perhaps legitimate for an "application" but not necessarily a "document". The web conveniently has turned from an information medium into a catch all for pretty much every hack that is imaginable. That's where it's all fallen over. "documents" are now "applications". This has lead to all of the crocks of shit out there. Office VBA and programmable documents are in a similar state.

I firmly believe we need to make the distinction between a document and an application and have appropriate sandboxes and/or virtualization for each.

Documents deliver information.

Applications deliver means of interaction.

Apparently there is a need to deliver documents with interaction. A browser is an application that delivers information, which delivers interaction... It's a mess, real world is never clean. And it's always changing...

Back in the old days they wrote software which wrote documents (in fact the company I work for actually does this) and wrote software which parsed documents. If you need to interact with a document, you write an application which processes it and creates another document!

That neatly assumes that documents are data and not code.

Except that any "software which parses documents" is essentially an interpreter that runs code which it calls "documents".

Should documents be Turing complete?

They don't need to be in order to have weaknesses; just look at all the security problems coming from Adobe's PDF reader, which afaik can't execute code, but where the input (PDF documents), if cleverly crafted, can create buffer overflows allowing for arbitrary code execution.

PDF files are code. They are a variant of postscript which is a Turing complete language. People have written web servers in postscript I understand.

The issue you state is a property of three things:

1. The underlying language/vm allows code and data to be interchanged (c++).

2. The underlying vm allows memory to be overwritten and buffer lengths to be exceeded to start with.

3. Pdf allows arbitrary code to execute on your computer.

My point demonstrated.

PDF is a very small subset of PostScript as a programming language, centered around objects that are usually in a compressed stream. Pages, text, images, drawings, etc. are all objects and appropriately linked¹. The language itself cannot really do more than creating objects and dictionaries; no programming is left.

Embedded JavaScript is another matter, but it's not needed to be executed for parsing the document.

_____________

¹ This gives rise to interesting applications, e.g. you can remove pages or images by just removing a link in the PDF. Yet the object would then still be there. There are some PDFs out there where sensitive information is buried in unlinked objects that still exist within the file. But that's obviously besides the point.

PDF files actually can execute code [1]. In fact, there are not one but two JavaScript engines inside Adobe Reader!

[1]: http://stackoverflow.com/questions/9219807/using-javascript-...

The PDF document format is incredibly complex. It can incorporate JavaScript actions !

They are not needed to parse the file. PDFs can also contain Flash content or movies or 3D models or any number of other objects. It's just a blob in the file, same as OLE. Few applications beyond Adobe Reader care about implementing those parts, though.

No, but even if we switched tomorrow, there are millions of legacy documents in Turing-complete formats that users want to access.

postscript is turing complete: http://www.tjhsst.edu/~edanaher/pslife/

And as the complexity of the documents increased the likelihood that some bug was written in to the interpreter increased geometrically.
The thing is we had all the things you say are great, and in spite of this we have created the browser as an application environment. Evidently people don't want a document web.

Adobe PDF and Word are evidence that document readers attempt to become web browsers with time anyway.

> I firmly believe we need to make the distinction between a document and an application and have appropriate sandboxes and/or virtualization for each.

You can go back to 1993 and turn your web application platform (a.k.a browser) into simple document reader by disabling javascript (+ plugins, whoever keeps them enabled anyway). Good luck with that.

Oddly enough IE is the browser that seems to keep the option of disabling Javascript buried the deepest within their context menus. In Firefox it's just Preferences -> Content -> uncheck "Enable Javascript" (I do this to avoid NYTimes' paywall, lol) but in IE you have to scroll through an exceedingly long list of checkboxes that's a couple levels deep into their menus to find "Disable active scripting" because they still refuse to call it Javascript. I always forget where it is and have to hunt for it every time. Obnoxious.

You are suppose to set the security level of the Internet zone to "High" (the default on Windows Server), or add the sites needed to the "Restricted Sites" zone.

You might enjoy elinks.

elinks supports JavaScript via SpiderMonkey so no.

Interesting - would this vulnerability exist when running IE rendering engine through, say IETab or via other browser shells, a la Maxthon?

Do you know how hard that would be?

It's not momentum, the browser is essentially a universal OS, the holes would still be there if you started again from scratch.

Yes I do know how hard that would be. I didn't say it would be easy.

Actually the browser is a non-universal OS which has several vendor extensions and incompatibilities which poke you in the eye day after day.

It's like the UNIX fragmentation in the 90's (OSF/1=Firefox, HPUX=Chrome, Solaris=IE, UNICOS=Opera).

It's possible to build something without holes. You just have to hire the right people and actually think about it before adding shitty features.

> OSF/1=Firefox, HPUX=Chrome, Solaris=IE, UNICOS=Opera

Oh, this is fun:

Xenix=lynx, BSD=Konqueror, Plan 9=Uzbl

http://uzbl.org/

Stop being naive.

> It's possible to build something without holes. You just have to...

bozo bit: flipped

>It's possible to build something without holes.

http://www.schneier.com/blog/archives/2009/10/proving_a_comp...

I'm guessing you're planning on releasing your document viewer/OS sometime around the head death of the universe.

While I respect Schneier for his views, this is not one I share.

I've worked in the defence industry. The cost of mistakes is very high. In my case I designed communication systems. I have one in the field which was verified mathematically and no defect, vulnerability or bug has been found in 18 years despite counter attacks. This covers the hardware and software portions of the design.

As for my OS or document viewer, 5-8 years is enough time.

In which time your program don't exist because your OS/Word processor business doesn't survive on the taxpayer teat.

The problem is for businesses, most customers pay lot for features and new shiny and give a lot of lip service to the security part.

The problem for open source is, most developers spend their time on features and new shiny, and the security ramifications are an afterthought.

How many downvoters really think that making bug-free software is effectively impossible? (I suppose we must leave some meta-uncertainty about the truth of math.) Sure, many programmers would be out of work if they no longer had a large bug database to work on, but there are numerous areas in hardware and software design that have incredibly low (or 0) bugs. NASA's work is usually brought up in these conversations, for instance. Does everything need to be designed and constructed so carefully? Probably not. But I would love it if a standard web browser was, given how important the browser is.

That's a really important observation that bears repeating: the browser used to be a novelty application among peers, but it's increasingly become the platform upon which those applications are built. It's become a mission critical process, much like the kernel code.

I would be amazed if there was anything out there with 0 bugs.

All you can really do is test the hell out of something until your chance of encountering a bug during actual use becomes vanishingly small.

You might be able to engineer a browser in this way but it would just be so ludicrously far behind all of the buggy insecure browsers in terms of functionality that it's security benefit would be close to zero because nobody actually used it.

It's not so much effectively impossible as it is not possible to win with it in the market.

NASA has been able to produce high-quality code, but even their stuff is not 100% bug free. Even if you consider it to be close enough, their cost is incredibly high for the amount of functionality, perhaps 10-100x the usual. So while you're slowly building a nearly-bug-free system NASA-style, you get beaten to market by another guy with a buggier system that gains popularity and becomes entrenched before you even ship.

Yes, NASA uses formal methods to exhaustively test every possible state the system could enter during execution. This type of testing can cost several hundred dollars per line of code. And it still doesn't prove that the code is 100% bug free because the absence of bugs is not empirically provable.

But on the other hand, as others have pointed out, browsers are now an important enough application platform that they probably should be tested to a similar standard as an OS kernel is.

Personally, having been warned time and time again over the years that IE is one of the least secure browsers available, I just won't use it anymore (except for work-related purposes in a corporate environment where I'm forced to use IE). IE's reputation is terrible for a reason, and I think we're seeing that the buggier, more popular/entrenched system that burns its users over and over again will eventually fall out of favor.

Certainly there's something in between the extremes of Microsoft and NASA in terms of testing and debugging standards.

Are you suggesting that there is something uniquely vulnerable about web technologies? Problems occur at every level of the stack from the OS on the client up to the server software. The big advantage of that programming model is how different elements can be loosely coupled. You can fix a problem by swapping individual parts of the stack without changing the experience.

Yes, the data has code in it...

Once that one is out, you're screwed.

That applies to most of computer science ironically.

I don't think that's unique to the web.

Word and Excel documents have code in them. So do PDFs and PostScript files. At this point, other than plain text everything seems to have code in it.

I did state in another reply that office VBA suffers the same problems. PostScript as well as you state. All these have been notoriously problematic formats with respect to security.

If you think there is a clear and fundamental difference between data and code, you do not understand security.

Actually I do, to the point I have been appointed a couple of security positions in the past in the defence industry.

Code is executable.

Data is not. There should be no level of turing completeness.

Taking C as an example, loading a char* with data that contains code and jumping to it or letting it overwrite the code segment is precisely where it breaks down. The same is true when your json payload contains a function or your css contains an expression.

The main problem at the moment is that technologies freely interchange the two concepts. Code should be entirely immutable once compiled and data should not be executable.

How do you implement an interactive page under that model?

Maybe we should think about moving away from interactive pages. What does all that interaction get us, really?

Agree. To be honest I'm not sure we should have gone past that point originally.

Can't tell if being facetious or just totally disconnected from reality.

an idealist. There's nothing wrong with wanting to improve the status quo.

You're not really talking about improving the status quo. You're talking about a temporal paradox in which you rewrite history.

>Actually I do, to the point I have been appointed a couple of security positions in the past in the defence industry.

>Code is executable.

>Data is not. There should be no level of turing completeness.

I'm sorry for the defence industry.

Why? They make shit that works with huge investment when the rest of the world makes do with shit that doesn't work properly for very little investment.

But the pragmatic approach is to assume that data may become executable due to vulnerabilities and design around that fact. Assuming that you can control everything is fanciful and dangerous. Assuming that you control nothing, and everything can and will break is a much safer approach.

The pragmatic approach is to use a toolchain which prevents data being executable. Most high level languages without pointers and direct memory access (excluding dynamic languages) perform this feat quite well.

I disclaim the use of hacks like non executable segments here in certain CPU architectures (x86 LDT/GDT controlled access bits) as they are an afterthought.

So you just have to force every piece of code on your computer to use that tool chain. "Dear Mr Zuckerberg, please make Facebook available in a form that allows me access without needing to rely on dynamic languages and uses a strictly defined toolchain (of my choosing)". Good luck with that.

Just removing javascript from a browser would cure most ills these days, and not all of them security issues.

Likewise, disabling the internet would do wonders for computer security.

Three guidelines for computer security:

1) Don't have a computer

2) Don't turn one on

3) For goodness' sake, don't connect one to a network.

Number 3 is easily bypassed, I saw it down by Tom Cruise once in a movie where he simply abseiled into the room. True story.

I see that to other responses have taken the sarcastic route, and I was strongly tempted to join them. Instead, I'm going to control myself and respond to this as if it was serious.

The simple fact is that there is a high demand for interactive applications. One of the best ways to distribute these applications is the web using JavaScript. If, for some reason, this distribution channel were removed (let's say it was removed by law) the demand would still be there, and the 'older' channel still remains - native apps. If the average person uses, say, 20 webapps heavily and a few hundred glancingly, and let's say that 10% of these survive the transition (probably a high figure) that's still a good handful of new native apps, each of them with their own security issues.

It was serious apart from the fact that I know it would never happen and will see little support here due to this website's infatuation with JS.

Every website that I see using JS these days would work much better with some GET or POST requests. Some examples:

* Using JS to load the next page for instance. That should be a simple request to the server for a /page2/.

* Using JS to change sort orders. Again a simple request for a new page should be made to the server.

* Pages not loading a full list in one go but making several requests for more entries via JS. The server should just return one long page.

* Searches not being sent to the server but using the browser to search which does a new search for every character.

* The same searches above hijacking the back button so that I can go back one key from round -> roun -> rou -> ro ->r -> no search -> at last, back one page!

* Images being hidden behind a javascript link when it should be a simple hyperlink to the image.

As for every website writing their own native software, at least some that I can think of could be substituted for old ones. Think ftp (or better yet sftp) for uploading files.

This is a tempting option in so many situations, not just software. But it never works because you can never wipe the slate truly clean. The state of the world is dependent on the previous state of the world.

Yes, reminds me of this essay from Joel Spolsky: http://www.joelonsoftware.com/articles/fog0000000069.html

The problem is not the technology, it's human nature. There are a certain number of scumbags out there, who will lie, cheat, spy, eavesdrop, backstab, whatever it takes to get something for themselves. This has been going on since we've existed as a species and I see no reason to expect it to ever stop.

And that's more of a reason not to execute code from them isn't it?

The world is a lovely, messy place.

Anything you replace it with will have tons of vulnerabilities as well. Formal verification might help, but that's entirely orthogonal to the programming model.

Sure, it sucks to develop for. But it's not fundamentally impossible to make it secure and private.

> Looking at the holes and crocks of shit we see every damn day related to HTTP, HTML, JavaScript

Many "browser vulnerabilities" (esp. non-IE) are actually vulnerabilities of Flash, an entirely different [and dying] platform.

> EDIT: just to add, my frustrations are based on having to spend 5 hours porting some JS code so it works properly on all browsers.

Tells nothing more than someone has written shitty code in the beginning.

Well yes its shitty code that has to work on numerous old shitty browsers.

The limited nature of the environment actually makes it much more secure and I'd guess that IE is not written in JavaScript. =)

> it's about time someone just shot it all and started again putting security and privacy first rather than playing whack-a-mole all the time.

I agree fully. So do the people working on Algol-68, PL/I, Multics, the Canon Cat, Plan 9, and, perhaps most relevant to this, Project Xanadu.

(Esperanto probably deserves a mention here, but it's duking it out somewhere with Volapük, Ido, Interlingua, Loglan, and Lojban.)

I think only the Plan 9 people have got the idea so far.

The problem that has shot us as a race is that in the 1990s, technology became suddenly ubiquitous and whatever was lying around was glued together to fill a niche which took off before people had a chance to think about it and engineer something sound. An analogy perhaps:

http://megaswf.com/s/2529389/

Good point. A valid counterexample would be the well though out text book examples of minix (and gnu hurd) vs Linux.

Sometimes paralysis by analysis is a bigger problem than bugs and bad architecture. And often the alternative to "usable" isn't "perfect" but "never shipped".

Good counterexample.

As a biologist, I've got to point out that our entire existence is based on evolution gluing together whatever was around to fill a niche, without thinking about proper engineering. Which is why, to give just one example, the nerves in our eyes run in front of the light sensitive cells, necessitating a blind spot where the nerve leaves the eye.

More seriously, I think we as humans benefit much more from getting technological developments quickly, than we would by waiting years or decades for them to be soundly engineered first. I doubt we can even foresee all the possible problems until we start using things at a large scale.

Yeah and biology killed a lot of things in the process. On a microscopic timescale we want to avoid doing that with our software.

Because inventing something from scratch is a fool-proof way to have bug and exploit free code.

What are you even doing these days that requires "porting JS code"? I haven't had to do that for ages and it was on poorly written JS to begin with.

Changing the fundamentals at the core is what I'd like to see.

This code has to work right down to ie6.

That's more a problem with having to support IE6.

If you redesigned a whole new ecosystem from scratch, you will still have IE6 users who don't support it so you'll have to provide a "fallback mode" anyway.

And you're complaining about crappy browser security and you're then supporting IE6? Why support such an outdated browser when you know it has numerous well documented and unpatched vulnerabilities?

Yes, yes, I know, the powers that be need this support for some explainable support even though worldwide IE6 usage is <1% etc etc. Whatever, it's just not worth the hassle. Show them a message and tell them to upgrade or use an alternate browser. I refuse to take any work on (I was freelance until recently) which requires IE6 support, and is a specific question I ask at interview time.

Those statistics are meaningless when a big chunk of the world is a darknet. Our client has 3,000 windows 2000/ie6 workstations still. None of these ever see the world wide web.

The numbers are entirely irrelevant. 28% of our client base is on ie6.

My point is that it shouldn't be an issue to start with.

Reply on news.ycombinator.com