5 ms·
Browsers need a "block all outgoing request from this page from now" button.
by Rexxar 3y ago
Browsers need a "block all outgoing request from this page from now" button.
- fauigerzigerk 3y agoNot just browsers. (Other) Native apps have the same problem. For some reason we have elaborate permissions for all sorts of things but nothing remotely user friendly for various kinds of network activity.
- least 3y agoLittle Snitch and Lulu on Mac are reasonably user friendly. I am pretty sure there are equivalents on Linux, though not entirely certain about Windows.
- fauigerzigerk 3y agoHaving to find and install separate firewall software is exactly what I mean by not remotely user friendly, regardless of how relatively user friendly any particular firewall may be. Why can I not simply disable network access in the app settings? Why am I not being asked to grant this permission just like I'm asked to grant access to my photos? Permissions systems on desktop platforms are mostly useless for regular users and only somewhat less useless on mobile.
- quaintdev 3y agoWe need this button!! Someone from Firefox team please make this happen.
- the_pwner224 3y agoAlt - F - K (menubar File => Work offline) It applies to the whole browser, not the current tab. But good enough.
- teruakohatu 3y agoDoes this absolutely prevent a page from saving information, eg local stiarge, and later transmitting it when you either visit the site or a Web page where it is iframed?
- tiagod 3y agoFor that you may use containers, private mode, the menu to delete site data, and auto-delete.
- jancsika 3y agoSo even here on HN, we've got a thread which: 1. starts by suggesting devTools, which is simple, elegant, and wrong. 2. improves by suggesting the "Work Offline" menu option of the File menu, which is hidden by default on both Windows and Linux, and also wrong. 3. improves to a state of minimal functionality with implicitly ordered steps to use Private Browsing, Offline Mode, and confidential file "upload." And, I guess, always remembering to close all private browsing windows upon completion? I'll rankly speculate f this ever caught on, 25% of users will forget to check offline mode until after they have finished editing their confidential document, 40% will leave a stray Private Browsing window open at all times, 10% will accidentally continue doing all their browsing in the same Private Browsing window, and 1% will somehow paste their private GPG keys in the query string of the URL.
- remram 3y agoThis far down the thread, we are all caught in the "how could we achieve this", but I think it's clear that it's not easy. Websites are not meant to not use the internet.
- lytedev 3y agoI doubt it, but I bet you can combine this with a private window and everything gets wiped from loca storage after it's closed.
- 3y ago
- deleted 3y ago[deleted]
- mikea1 3y agoYou can quickly go offline via dev tools. In Chrome, it's very simple[0]. [0] https://developer.chrome.com/docs/devtools/network/reference/#offline https://developer.chrome.com/docs/devtools/network/reference...
- pritambaral 3y agoWorkaround: 1. Install ServiceWorker. 2. Save data to LocalStorage/IndexedDB/ServiceWorker Cache/ServiceWorker Memory. 3. Wait for devtools to be closed, enabling internet access, send data from ServiceWorker.
- Zuiii 3y agoI'd create a fresh browser profile just for this, download it, then point it to use a http/socks proxy that will never exist. Work around that.
- pritambaral 3y ago> Work around that. Easy. I use HTTP/3. No, really, HTTP and SOCKS proxies cannot carry QUIC traffic, so browsers don't even try. They just send it right through. If you block UDP, I guess I can still try DNS for exfil. HTTP proxies don't support DNS, and browsers need to be explicitly configured to proxy DNS through SOCKS, if the SOCKS proxy even supports it. Chances are, DNS exfil will work. Now, if you were to do what I do to disable network access, then I'd have no chance: network namespace in a jail with zero network interfaces (not even loopback).
- remram 3y agoI'm going to need a bug tracker link for that, it seems to dumb to be true. Surely they would just not use HTTP/3 if they can't do it through the configured proxy. I wouldn't bet my life on it though, I have seen dumber bugs. edit: tested this the old-fashioned way with Firefox 116.0.3 on Ubuntu and nginx 1.25.1. Firefox does connect over HTTP 3 and CORRECTLY DOESN'T CONNECT AT ALL with a (bad) proxy configured. You are spreading FUD. My Chrome 115.0.5790.170 doesn't seem to use HTTP 3 at all.