Hacker News new | ask | show | jobs
by pdkl95 3055 days ago
The increased use of browser mining has made it a lot easier to convince people to globally disable Javascript (or install noscript/etc). Security concerns are rarely convincing, and tracking can be hard to explain, but paying for more electricity and worse UI response time are things people actually care about.
3 comments

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.

> 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

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.

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

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.

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

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

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

> The increased use of browser mining has made it a lot easier to convince people to globally disable Javascript (or install noscript/etc).

Has it though? Do you have any data to back up this assumption?

I can't find ANYONE who is tech illiterate who understands any of this stuff and those that I know are tech literate either don't notice or don't care about JavaScript. I've only ever met very, very few people who disable JavaScript and when they do it's always been piecemeal.

I haven't been able to find any statistics regarding who does and doesn't disable JavaScript, their group size, etc. It would be really interesting to know!

> Has it though?

I have personally succeeded in convincing more people to disable javascript in the last few months than I have since Javascript was introduced in Netscape Navigator 2.0.

> this assumption?

I'm offering personal experience, not an assumption.

I've disabled JS and only enable it in incognito when needed/when mandatory for a particular site. Tedious I know, but a habit I picked up when everyone started autoplaying videos.
Don't need javascript to autoplay videos.
On most sites you do. I do this everyday. I should know what I'm talking about.
> worse UI response time

The miner is run in a WebWorker so shouldn't affect the UI response time.

I never said it was the browser's UI.

Regardless of which UI, you do not know people are using their computer for, or how much free CPU they have available.

My friend's 1.2Ghz Core 2 Solo[1] laptop takes many seconds to reload locally hosted static HTML. Loading a youtube page takes >30s, sometimes far more. Anytime a webpage has CPU-bound Javascript - intentionally or not - the mouse becomes a lot harder to use. No, they are not buying a new laptop anytime soon; they live below the poverty line with student loans and medical expenses.

[1] https://en.wikipedia.org/wiki/List_of_Intel_Core_2_microproc...