- From: Robert Flack <notifications@github.com>
- Date: Thu, 08 Apr 2021 08:52:39 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/1189/815937824@github.com>
> Once we've added a port to the blocklist we never know if it's safe to remove it again, so in practice it will only grow. Every time we add something to the blocklist we break people's applications, so it's desirable if we can stop doing that. Would this mean that the allowlist couldn't be expanded since we could similarly never know if it's safe to allow any currently blocked port? I'm worried about the myriad of servers which run web interfaces on non-standard ports so as not to conflict with a webserver running on the same machine, e.g. cups 631, goma 8088, plex 32400, tools like [code-server](https://github.com/cdr/code-server) (defaults to 8080) or [cloud9](https://github.com/c9) (defaults to 8181) specifically need to avoid dev web server ports as well since they're often used for working on that dev web content, etc. It's common to configure routers with a non-standard port for remote web configuration for the same reason. I suspect some IoT devices may use non-standard configuration ports. Would a devtools configured exception be possible to use while not keeping devtools open (i.e. similar to adding an exception to your firewall)? I've seen many cases where the presence of devtools significantly slows down the site, and it's awkward to lose that screen real estate when you're not working on the site. Alternately, could we get the same benefit without some of the pain by not restricting the main navigation port, but only restricting sub-resource requests (explicitly allowing them to the ip:port used for the main navigation)? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/1189#issuecomment-815937824
Received on Thursday, 8 April 2021 15:52:52 UTC