[pdkl95]

> Most of the problems with the modern web stem from the failure of browser vendors to implement a good user-centric permissions model.

I suggest that such creating a proper permission model isn't possible, because it isn't possible to determine the behavior of Turing complete programs without running them[1]. Browsers are currently chasing the impossible[2] goal of trying to enumerate badness - often only the known types of badness that fit their permission model.

> I want a simple, limited, fast, secure, document-centric platform

We had that: HTML, before Javascript. Allowing any Turing complete code to run at all will always be risky[3].

[1] halting problem

[2] http://www.ranum.com/security/computer_security/editorials/d...

[3] https://news.ycombinator.com/item?id=15708099

[fauigerzigerk]

There are things that could be done in spite of Turing. For instance, web pages could be granted CPU and memory quotas.

If they want to run JavaScript that uses more than say 5% CPU or more than 300 MB of memory (both on average over 30 seconds) they must ask for permission.

[dragonwriter]

> I suggest that such creating a proper permission model isn't possible, because it isn't possible to determine the behavior of Turing complete programs without running them.

You don't need to solve the halting problem to have a good user-centric permission model; permissions are about resources, not computation, the halting problem doesn't address use of resources. Whitelisting APIs, firewall-like control of access to external network resources, and possibly CPU usage limits would be sufficient, with he right UI.

[Chris2048]

So have predefined, approved functions that achieve 90% of required functionality, who's composition may not be TC.

Anything custom requires permission.

Also, don't crypto-miners need to pass their results back? That's one point of attack - restrictions on what data can be passed back.

[pdkl95]

> So have predefined, approved functions that achieve 90% of required functionality, who's composition may not be TC.

Aka declarative configuration, which we have already: HTML.

Define new tags for if necessary.

> Anything custom requires permission.

You generate that server side.

[Chris2048]

> which we have already: HTML

HTML cannot perform 90% of what JS is used for, otherwise the js wouldn't be needed. "Define new tags" might be one way, ala Angular directives, but it would still require notions of safety attached to those directives/functions.

> You generate that server side.

A server-side crypto miner? Websites/apps are increasingly client-side intensive/heavy. Perhaps there is no need for non-generic/safe client side code, but I'm not so sure. In any case, requiring permission to run anything custom would be a reasonable restriction I think.

[pdkl95]

> HTML cannot perform 90% of what JS is used for

Yes, that's the goal.

> Angular ... directives/functions

HTML is a document format, not an application framework. My entire point is that complexity cannot be made safe. Repackaging the Turing completeness into different forms only moves the problem around. The only way to reduce the attack surface back to something that is decidable is to remove complexity (aka features).

> A server-side crypto miner?

You can do whatever you want on the server. However, I was replying to the desire for "anything custom".

> Websites/apps are increasingly client-side intensive/heavy.

Yes, that's the problem.

> but I'm not so sure

Server-side apps worked fine before Javascript existed, just like they did on the IBM 3270 which was the model for HTML+forms.

> requiring permission to run anything custom would be a reasonable restriction I think.

That only re-creates the current situation on phones where apps ask for everything and refuse to run if you don't grant them permission. That hasn't worked in practice, because it's easy to social engineer people that do not have the necessary engineering background to understand what that permission really means.

[Chris2048]

> packaging the Turing completeness into different forms only moves the problem around

The solution I proposed doesn't require TC, except in code that needs explicit permission to run.

> reduce the attack surface back to something that is decidable

You don't need decidability, just trust. A function checked manually and signed by a reputable source is enough. Are internet browsers formally checked? The only aspect that needs to be decidable is composition of signed functions, not the functions themselves, as safety is represented by the signature.

building functionality into HTML might be similar, except I'd assume would be more bogged down by consortia. Add the ability to sign JS functions and verify their composition, and you can decide who's signatures to trust.

> Server-side apps worked fine before Javascript existed

Sure, but did they scale as well?

> That only re-creates the current situation on phones where apps ask for everything and refuse to run if you don't grant them permission

Maybe, it depends how you design it. I think that should change too. But those environments are currently restricted in ways the internet is not.

I'm also far happier for a website to indicate to me that they aren't worth my time by this kind of access refusal. Same thing happening with pay-walled news sites - I'll happily blacklist them.