Hacker News Reader

Comment by cheald | Hacker News Reader

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.

View on HN

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.

> 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.

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.

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.

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

Should documents be Turing complete?

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

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 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-...

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.

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.

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