[apatters]

I have no problem at all with websites using browser mining as an alternate monetization strategy to ads, as long as:

1) Permission is requested first

2) The UX is good (it stays out of my way and doesn't slow down my device)

3) The mining finishes when I leave the site

Most of the problems with the modern web stem from the failure of browser vendors to implement a good user-centric permissions model. They all hold an unquestioned belief that more power in the platform is always better, and they've all spent the past 15 years kowtowing to developers, advertisers, and profit-motivated corporations instead of protecting their users from the above.

I want a simple, limited, fast, secure, document-centric platform which allows the site to request the execution of additional functions. Publishers unsurprisingly abuse the freedom they currently enjoy to throw up popovers on every page, secretly steal CPU cycles, load-on-demand videos that follow me as I scroll, and track every move I make online. I don't want any of that to work by default.

A common, well-intentioned argument against my point of view in the last few years has been that the web platform needs to compete with native mobile apps. That argument carried a lot more weight when everyone was installing tons of native apps. But increasingly we're at the point where we're sick of native apps for all the same reasons we're sick of the web -- they too are bloated attention + data thieves.

We need a true user-first platform. I'll pay for sites or apps on that platform, or I'll let them use my CPU to mine crypto. I just want them to not suck.

Microsoft, Mozilla and Apple could all lead the way in shipping browsers that are pro-user. Mozilla's got the heart for it, Microsoft and Apple have little to lose. Leaders at all these companies have failed to lead and demonstrate vision, relegating themselves to playing second fiddle to Google on the web because they think shitty popup ads will be the final word in web history.

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