4 ms·

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

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 9y ago
> 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/dumb/ http://www.ranum.com/security/computer_security/editorials/d... [3] https://news.ycombinator.com/item?id=15708099 https://news.ycombinator.com/item?id=15708099
- fauigerzigerk 9y ago
  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.
- Chris2048 9y ago
  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 9y ago
    > 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 9y ago
      > 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 9y ago
        > 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.

pdkl95 9y ago

> 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/dumb/ http://www.ranum.com/security/computer_security/editorials/d... [3] https://news.ycombinator.com/item?id=15708099 https://news.ycombinator.com/item?id=15708099

fauigerzigerk 9y ago
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.
Chris2048 9y ago
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 9y ago
  > 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 9y ago
    > 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 9y ago
      > 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.