3 ms·

Recently chrome required COOP and COEP for shared memory access, which essentially restricts any access to anything besides the same origin. This basically kill

by Ralo 5y ago

Recently chrome required COOP and COEP for shared memory access, which essentially restricts any access to anything besides the same origin. This basically killed my project/motivation of 2~ years. Using Emscripten and threads, you require COOP & COEP headers to be sent via the main document. This is not common practice for static html hosting sites, thus requiring that you have access to a config file or .htaccess, and requires ALL assets to be hosted exclusively on that same server. Killing my project is a bit extreme, but killed my motivation. It's a web-based game with multiplayer that I was hoping people would modify and expand on, hosting themselves, uploading to places like Github. I've recently started modifying Emscripten's runtime library to try and treat each webworker as a separate instance that just communicates between each other. This has major overhead as each thread is a new memory instance. I've tried getting it to extract each function into it's own module for a webworker to load but that's a major task. Web apps want to act as desktop applications but they're so held back by security it's nearly impossible. We don't even have a proper local storage system. To quote Dilbert, "Security is more important than usability. In a perfect world, no one would be able to use anything."

Tepix 5y ago
Here's the Dilbert strip: https://dilbert.com/strip/2007-11-16 https://dilbert.com/strip/2007-11-16
_puk 5y ago
I may have misunderstood your requirements, but why do you say that most static hosts don't allow custom headers to be set? I know that Netlify does[0], and use it myself, so I would expect the other big names to support something as well. 0: https://docs.netlify.com/routing/headers/ https://docs.netlify.com/routing/headers/
- Ralo 5y ago
  I really wanted to give developers more control over their asset hosting. If they wanted to host their assets on a remote server for better performance, that's an option I'd want them to have. Relying on only X Y Z service will certainly work, but certainly not optimal. It didn't out right kill the project, It'll work under these specific conditions but reducing usability is not helpful.
wffurr 5y ago
I’m sorry your project was stalled by this. What static file hosting were you using? If it doesn’t support COOP/COEP headers yet, you can force it by using a service worker with this neat hack: https://stefnotch.github.io/web/COOP%20and%20COEP%20Service%20Worker/ https://stefnotch.github.io/web/COOP%20and%20COEP%20Service%... Firebase hosting would allow you to set headers with a .htaccess file. Cloudflare Workers can also set the headers. If your project was going to entail loading resources from other origins not under your control, well, that’s exactly the code injection scenario these headers are designed to prevent.
- Ralo 5y ago
  Sorry late reply, ended up going to bed. This article is actually very interesting, I'll have to dig deeper into this. Thanks.
rektide 5y ago
I'm quite saddened the web has had to rescind so many features (high-res timers, shared memory, memory profiling). It's worth noting that most of these high-end capabilities had just gotten outright disabled for a time, when Spectre/Meltdown hit. That they got turned on at all is a notable improvement. https://web.dev/why-coop-coep/ https://web.dev/why-coop-coep/ I don't like some of the candor of the article. Treating cross-origin activity as a mis-feature is a great mis-service to the web: it's not really much of a web, imo, if sites are restricted to talking to themselves. That the web standards crew is happy to shit on this range of capabilities, to write new standards that walk the web back: it's a harsh regression, by afraid leaders. There is a lot a lot a lot of trouble here, in these domains, but this desire to just cancel the feature & walk away, to make the web one where sites have to work & play only with themselves: it's a death knell, against the spirit of the thing, deeply. That it's so inconvenient & troublesome to standards authors, so difficult for browser engineers, that it (used to be) a hazard for sitemasters: I'm sorry for your suffering but good things & great powers have a price. You're wrong to want to shut this possibility out. Easier path that it may be.
datavirtue 5y ago
Have you looked at Electron? It brings a learning curve and other problems but you have a node.js backend that you can pass messages to and would have full access to the machine.

by Ralo 5y ago

Tepix 5y ago

Here's the Dilbert strip: https://dilbert.com/strip/2007-11-16 https://dilbert.com/strip/2007-11-16

_puk 5y ago

I may have misunderstood your requirements, but why do you say that most static hosts don't allow custom headers to be set? I know that Netlify does[0], and use it myself, so I would expect the other big names to support something as well. 0: https://docs.netlify.com/routing/headers/ https://docs.netlify.com/routing/headers/

Ralo 5y ago
I really wanted to give developers more control over their asset hosting. If they wanted to host their assets on a remote server for better performance, that's an option I'd want them to have. Relying on only X Y Z service will certainly work, but certainly not optimal. It didn't out right kill the project, It'll work under these specific conditions but reducing usability is not helpful.

wffurr 5y ago

I’m sorry your project was stalled by this. What static file hosting were you using? If it doesn’t support COOP/COEP headers yet, you can force it by using a service worker with this neat hack: https://stefnotch.github.io/web/COOP%20and%20COEP%20Service%20Worker/ https://stefnotch.github.io/web/COOP%20and%20COEP%20Service%... Firebase hosting would allow you to set headers with a .htaccess file. Cloudflare Workers can also set the headers. If your project was going to entail loading resources from other origins not under your control, well, that’s exactly the code injection scenario these headers are designed to prevent.

Ralo 5y ago
Sorry late reply, ended up going to bed. This article is actually very interesting, I'll have to dig deeper into this. Thanks.

rektide 5y ago

I'm quite saddened the web has had to rescind so many features (high-res timers, shared memory, memory profiling). It's worth noting that most of these high-end capabilities had just gotten outright disabled for a time, when Spectre/Meltdown hit. That they got turned on at all is a notable improvement. https://web.dev/why-coop-coep/ https://web.dev/why-coop-coep/ I don't like some of the candor of the article. Treating cross-origin activity as a mis-feature is a great mis-service to the web: it's not really much of a web, imo, if sites are restricted to talking to themselves. That the web standards crew is happy to shit on this range of capabilities, to write new standards that walk the web back: it's a harsh regression, by afraid leaders. There is a lot a lot a lot of trouble here, in these domains, but this desire to just cancel the feature & walk away, to make the web one where sites have to work & play only with themselves: it's a death knell, against the spirit of the thing, deeply. That it's so inconvenient & troublesome to standards authors, so difficult for browser engineers, that it (used to be) a hazard for sitemasters: I'm sorry for your suffering but good things & great powers have a price. You're wrong to want to shut this possibility out. Easier path that it may be.

datavirtue 5y ago

Have you looked at Electron? It brings a learning curve and other problems but you have a node.js backend that you can pass messages to and would have full access to the machine.