Is this API going to have a permissions lock, like access to the video camera or microphone APIs do?
If it doesn't, I'm not looking forward to the future where every website I visit tries to pull a big chunk of my graphics card to mine cryptocurrencies without my explicit authorization.
It's already the case. Any web page can use WebGL1/2 for general computation. As the author said:
> Using GPUs for calculations of any kind is often called General-Purpose GPU or GPGPU, and WebGL 1 is not great at this. If you wanted to process arbitrary data on the GPU, you have to encode it as a texture, decode it in a shader, do your calculations and then re-encode the result as a texture. WebGL 2 made this a lot easier with Transform Feedback
I think the problem is presenting this to users in terms they’ll all understand. “This site wants to do a special kind of processing”? “Use more resources”? I can’t think of many good answers. Anything involving the term “GPU” is immediately going to confuse most.
That's a big red lever that disables all sites' ability to use WebGL also, isn't it? That kind of thing is the kind of thing I imagine one would want at site-by-site granularity.
While I understand why it's necessary, I feel that the UX of security needs a serious overhaul. It seems like an increasing share of the time I spend using technology involves jumping through hoops.
There is a push-and-pull because the ideal of how the web should work slammed head-on into the reality of how the worst actors will exploit the ideal.
Ideally, the web is a fabulous location-destroying architecture. The common protocol for both communications and content rendering really flattened the universe of data sources; doesn't matter if you're on CNN, Fox, Wikipedia, Google, or Hacker News, they all "feel" the same. Common top-level UX metaphor (underneath which customizations can be built), common language under-the-hood; the web really became a sort of global operating system for transactional communications.
In practice, letting arbitrary actors run arbitrary code on your machine at the speed of the web can be arbitrarily bad, so we tacked on a permissions architecture based on data source (delegating to the domain name service plus secret certificates to tell us who the data source is). And because the proper level of paranoia for strangers online is "zero trust by default," every domain you visit is a new trust relationship with its own security story to wrangle.
So these two features (flat experience where domain doesn't matter and zero-trust security model where domain matters a bunch) are directly at odds with each other. Sucks but it's the best we've got right now (how to improve? Hypothetically, we could add a meta-trust layer... "Here's an allow-list of sites that are trusted, so sayeth Goodsites.com". But nobody's written that spec yet).
GDPR-compliant cookies, as a concrete example, are a huge pain-in-the-ass because we retrofitted them onto site internal code itself instead of adding the concept of "required" vs "optional" cookies to the cookie jar design, which would have allowed user agents to put optional cookies behind a trust barrier like your microphone or video. But cookies are a legacy web feature and making changes to the implementation is hard (and, of course, there's the human element... I'm not 100% sure the people who hold the reigns of the W3C are on the same page with the people who hold the power to create and enforce the GDPR vis-a-vis goals).
You definitely could (and, indeed, I can imagine beneficial use cases for a "renice" feature in a browser like Chrome with its Task Manager).
But there's less of a significant need for it. Main CPU performance is too poor on hashing datasets to much benefit from salami-slicing user CPU at scale. That trick is much likelier to get you a solved block in the blockchain if you can tap user GPUs on a couple million users.
If it doesn't, I'm not looking forward to the future where every website I visit tries to pull a big chunk of my graphics card to mine cryptocurrencies without my explicit authorization.