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