> Or toggle "javascript.enabled" to false in "about:config" - no > extensions required.
the assumption being that you would use, trust firefox. A well-documented, XML-based open source kind of proxy/gateway through which all requests are sent and received would work with any browser. ~ I think, given the options, the suggested idea not to install networking at all (one of the install options with Linux) wins the prize; then: b) an exposed "inet" user for the session should be defined with a RAM drive as its home directory; c) for whom -exclusively- the network card's device driver should be installed (is here a hack to install a device driver entirely from user space? probably, a Debian HURD kind of thing on which the basic hook for the networking service is exposed and a user space program would take it from there?); d) then all access to the Internet go through a client proxy run by "inet"; e) acting as a squid-like application proxy; e.1) parsing all text/html content coming in, first cleansing it into well-fomed xhtml with some HTML parser, then using XPath, java Nasshorn, the principles of the Burp Suite + wireshark + page Reader + ...; e.1.1) sanitzing the page into alpha-offset format; e.1.2) not the received, but a sanitzed, topical, content centric page with all the distracting "attentional" nonsense removed will be displayed to the user (page reader on steroids); e.1.3) it maintain a local cache of the accessed data (videos, pdf files, ...) and adjusts all links on the flight to the local paths (storage space is very cheap, anyway); e.1.4) using XPaths of the sanitized page, you would be able to exactly authorize the java script that you want to let through and blanket "yeah, sure!" the rest of it, including those bsing "we care about your privacy" (isn't that the very definition of not having privacy that other people "care" about it?), "user agreements" authorization of cookies, right on the proxy ebfore it reaches your field of view/consciousness with the option of sending bogus information actively, passively or by request, per site, section of the page ...; e.1.5) cookies, user agent, ... will be managed by the proxy, so little as possible will be exposed; f) based on the request headers the proxy would create a new folder/jail each time a new domain is accessed (probably even the option to run macchanger?); g) based on the critical XPaths a "processing signature" will be kept for pages, domains, URL paths frequented; h) inet had no access to the PATH or any other local variables or files, it would only know of its own jail; i) many/most/all? applications assume/demand Internet access. All such access attempts should be logged with traceable information so that you can inspect what it is "that application was attempting to do which it shouldn't be doing" (tm); j) while shutting down "inet" will permanently save the cookies and such which matter, the rest will be physically "hasta la vista, babied" since it was kept in RAM anyway; k) that proxy could be used as password jar and could as well work as agent regularly checking if you've got new or certain kinds of email ... These is nothing really "new" in that spec. All the pieces either exist or their functional requirements can be achieved with configuration changes. It is assembling of all pieces which matters and may be problematic. Do you know of such previous "paranoid" art? Any Linux/debian friendly network firmware you would recommend to make that project easier? Any ideas come to mind? Any hints or death threats you would share? lbrtchx
