5 ms·
> And finally, arbitrary JavaScript execution will be questioned, as it should've been a long time ago. I run UMatrix and manually whitelist 3rd-party scripts,
by danShumway 7y ago
> And finally, arbitrary JavaScript execution will be questioned, as it should've been a long time ago.
I run UMatrix and manually whitelist 3rd-party scripts, I've blocked web features like WebGL and Canvas behind prompts, and I regularly disable JS on websites that I think don't need it (news sites in particular). At the moment, if you're really worried about tracking, it is a very good idea to think about blocking most Javascript and culling down the language features your browser supports.
However, I want to stress at the moment. The problem is that pervasive tracking and device fingerprinting will go wherever the app functionality is. Currently, even with all of the many, many problems on the web, it's still better to use apps like Facebook via a website than it is to download them as native apps to your phone. The web has better fingerprinting resistance than most native platforms.
Again, doesn't mean the web is great. It just means we need to think about where Google Maps is going to end up if it's not on the web. What I'm getting at is that blocking scripting isn't a long-term solution to fingerprinting in general. We could get rid of Javascript on the web, it might even be a good idea. We will still need to solve the same problem with native apps.
Forget the web for a second, what it comes down to is that we need a way to run a turing complete language that is incapable of fingerprinting the host environment. That language doesn't have to be Javascript, and it doesn't have to be on the web, but it does have to be something, somewhere.
It's a really hard problem -- vulnerabilities like Spectre and Meltdown have made it worse. Now we're asking questions like, "is it actually reasonable for applications to have access to high-resolution timers?" People look at the web and say, "oh, this is a web problem." It's an everything problem. If we really want to get rid of pervasive tracking, we now have to think about how high-resolution timers are going to work on desktops.
What the web promised was a VM where anybody (technical or not) could run almost anything, without validating that the code was safe, and the VM would just protect them. We're finding holes in this particular implementation, but I still eventually want that VM as promised.
- hollerith 7y agoThank you for your well-written comment. I don't want to deprive you of the VM as promised, but that seems very hard to implement, and I don't have time to help. I just want to solve the much easier problem of giving people some way to use the internet to read documents without getting tracked [1]. By "document" I mean a page of text, images, links to other documents and maybe some other easy-to-implement non-privacy-compromising things. The web is how almost all documents are made available on the public internet. Most document authors don't even consider or imagine any other way to do it. And the web is a privacy nightmare. That is the problem I'd like to solve. I felt the need to write this because past discussions on this site of the problem I want to solve have gotten derailed into a discussion of how finally to achieve the vision of "a VM where anybody (technical or not) could run almost anything", which, like I said, strikes me as a much harder nut to crack. [1]: and without the need for anything as demanding of the user's time or the user's technical skills as you described when you wrote, "I run UMatrix and manually whitelist 3rd-party scripts, I've blocked web features like WebGL and Canvas behind prompts".
- danShumway 7y agoWe already have all the of the technology we would need to build a document-only web now. The biggest unresolved problems are asset caching[0] and IP addresses[1]. But for the most part, nobody would even have to build a new browser, they could just distribute a custom build of Firefox that turned off Javascript and a few other features. It would be very fast, reasonably private, probably a lot nicer to use (at least where documents are concerned), and nobody would use it. I don't necessarily disagree with your goal -- it seems very reasonable to want a document distribution platform that isn't encumbered with JS. But given that news sites can already speed up their pages dramatically by removing JS, and they don't, why would they support this new browser or platform? And without them supporting it, why would users move to it? We've seen this play out with AMP. AMP is fundamentally flawed, but it did get one thing right: that news sites only care about search engine placement, and they do not care about user experience past that point. I would (very cautiously) suggest that it might actually be easier to implement a VM that safely runs arbitrary code, than it would be to convince publishers to move to a user-friendly platform that only distributed documents. The only success I've seen in getting publishers to abandon scripting is via platforms like Facebook and Medium -- maybe that's replicable with a new browser or distribution layer on top of the web[2]? I dunno; I think that also might just be a really, really hard problem. I'd be happy to be proven wrong, I would happily start using a ubiquitous, script-free platform for document distribution. --- [0]: We maybe need to just bite the bullet and get rid of asset caching, or at least give asset caches a very short expiration date (<1 day). I guess making them domain-specific could help too. [1]: IP addresses are a huge issue, and I don't think the tech community talks about them enough. TOR is not really scaling. The best solution for ordinary consumers is a VPN, and VPNs have a lot of pretty obvious problems. [2]: My guess would be, someone would need to make publishing much easier than building a website (ie, Medium), maybe by adopting the DAT protocol and just offering free hosting for everyone. That runs into the same IP address problems (DAT and IPFS are not privacy friendly), but there's progress being made in that area. Or someone would need to find a way to get users to en-mass abandon the web and move to the new platform.
- hollerith 7y ago>it might actually be easier to implement a VM that safely runs arbitrary code, than it would be to convince publishers to move to a user-friendly platform that only distributed documents. Would the VM that safely runs arbitrary code render existing web pages or would it be necessary to persuade publishers to adopt it?
- zzo38computer 7y agoSuch the VM is way too complicated, and has other problems. (Also, it is difficult to sufficiently control the features of JavaScript programs (not only HTML related stuff, but also Date and endianness), or to replace specific scripts.) But just if you want a Turing complete language that is incapable of fingerprinting the host environment, there is TeX, which might be incapable of fingerprinting if a bug it has is fixed, and the file I/O is made more restricted. Also, for internet stuff there are many other programs and protocols, so could be used, e.g. SMTP, NNTP, Gopher, Telnet/SSH, etc. (In many ways it will even work better. No need to deal with complex user interfaces that do not even work properly and which is not even the user's intentions.) There is also Glulx, and other VMs, and I also thought of idea to make up a VM for this purpose, too.
- justinmeiners 7y ago> What the web promised was a VM where anybody (technical or not) could run almost anything The web promised a place where we could read structured text documents with the occasional embedded piece of media. If it was known that it would be an app platform like today, decisions would have been made differently.
- tannhaeuser 7y ago> What the web promised was a VM where anybody (technical or not) could run almost anything I have to agree with hollerith here and say this is not at all what was promised. Instead, what was promised, IMHO, was that there are linked, passive pages with an expectation of UI transparency wrt when network accesses occur (in response to clicking on links or submitting forms), and this notion is even honored in the HTML 5 spec to some degree. A universal VM/runtime is desired by developers who want to sell services rather than sw, or don't want to bother with deployment procedures in app stores, or want portable code accross platforms, or for other plausible reasons, but is a non-priority next to the web's original purpose. OSs are far superior platforms for general-purpose apps, and turning browsers into platforms is only helping the (few) browser vendors left, but trampling by design on security, privacy, simplicity, and power efficiency.
- danShumway 7y agoSounds good -- but, if we move all of the web apps to be native apps, then I want a native environment that can safely run untrusted code. Currently, none exist that I'm aware of. Phones aren't doing well on that front, and we haven't finished moving to Wayland yet, so that mess still exists. X11 is heaven for anyone who wants to fingerprint a device. And we still have to figure out whether or not we're going to allow high-resolution timers or raw access to the GPU, which is itself a pretty big fingerprinting target. On mobile phones, the closest thing I have to a good adblocker is AFWall+, which doesn't work on iOS, and only blocks via the built-in IP-table, which isn't good enough to make me feel safe running apps like Facebook or Twitter. And most mainstream Linux distros (with a few exceptions like Qubes OS) are not shipping with the kind of process isolation that's necessary to guard against malware. I guess MacOS is making some progress in this area at least? But for the most part, none of our computer environments were designed to run untrusted code -- Linux in particular was primarily designed to protect you against other users. The prevailing advice was, "just don't download malware", which doesn't reflect how people today use computers. I want to stress -- there could be a solution to this. We could make a user-friendly native platform that replaced the web. But I don't think anyone has made one yet. I want to advocate that it's a good idea for us to solve that problem (or at least think about it) before we get rid of Javascript. I don't care what happens on the web, except that the web is currently the most user-friendly, widely-used VM that we have. I see a lot of people suggesting that we burn that down, but I'm not sure they've really thought about what's going to happen afterwards.
- ksec 7y ago>We could get rid of Javascript on the web, it might even be a good idea. We will first need to get 95% of the useful Javascript functionality within Browser first. I would be happy if I could have Rails's Stimulus and Turoblinks function without Javascript.
- gruez 7y ago>I've blocked web features like WebGL and Canvas behind prompts what extension does this? there's plenty that disables it outright, but is there one that shows a prompt?
- danShumway 7y agoFirefox settings. Fingerprint resistance (privacy.resistFingerprinting) will auto-reject the canvas and show a relatively non-intrusive icon in the address bar that lets you re-enable it for that website[0]. Since webGL requires you to use canvas, this should also block that attack, although I'm currently going a step farther and disabling webGL entirely (webgl.disabled), since I've seen a few sites (panopticlick for example) get around the prompt specifically with webGL, and I don't know how they're doing it. Firefox's fingerprint resistance efforts are showing a lot of promise, although you will have to put up with some quirks (like learning to read UTC time). [0]: https://support.mozilla.org/en-US/kb/firefox-protection-against-fingerprinting?as=u&utm_source=inproduct https://support.mozilla.org/en-US/kb/firefox-protection-agai...
- gruez 7y agoI know there's a prompt for canvas, but it doesn't seem to work for webgl. On a fresh install with fingerprint resistance enabled, webgl fingerprinting appears to work fine[1]. [1] https://browserleaks.com/webgl https://browserleaks.com/webgl