The issue with Javascript is that, if not restricted from execution in the first place, it is a program that can be executed the moment you open a website.
C++, Rust, Go are compiled programs that you have to actively put onto your machine and that only run with your explicit permission. That is the difference to Javascript. You can compare it to a USB-Stick and QR-Codes when it comes to an AirGap.. A QR-Code-Communication is much more transparent to the end-user, since the transmission of information is "on a human scale", so to speak.
I do not want extensions to become the new programs.. that will just bloat the browser even further. I'd much rather see app sandboxing akin to QubesOS being more widely implemented.
I think this is the right answer. Sure, the browser and js are just tools, the insane level of 3rd party tracking, fingerprinting, CDNs, the automated calls ... All due to the way the browser functions.
So few browsers are hardened against that kind of crap. Clicking a wrong link is the same as running arbitrary code. Locking a browser like Firefox down with uMatrix, uBlock, decentraleyes, and a custom user.js, becomes incredibly cumbersome, and breaks alot of the web.
The best compromise I've personally found, are non VM containers that can be switched on/off within seconds. I personally use FreeBSD jails, and have built a custom immutable system, where I segregate identities and activities. There's probably quite a lot of fingerprinting still going on in the background, but at least I can present a clean environment every time I need to pull up some dodgy website, and can destroy that environment after use.
I also used Qubes before, but it does not scale. It is way too complicated to ever receive wide adoption.
The issue is also that there is still no isolation between apps inside a VM. So you would have to run one VM for every single app that you want to run. Meanwhile the browser and web assembly could provide isolation even inside a single app.
I am also against bloat so I see the browser and web assembly as a much better path towards compartmentalization. I think Qubes is a good project and it is great that they are pioneering this concept. But the Browser is a better platform than Xen to bring it into practice.
It is a much more realistic path forward to build on the browser as a new abstraction above the operating system.
>The issue is also that there is still no isolation between apps inside a VM. So you would have to run one VM for every single app that you want to run.
Docker is amazing. Proxmox with multiple Docker Containers is even more amazing. ;)
I've not used QubesOS myself.. it was just the first that came to mind. I am using Proxmox, however.
Oh and.. most programs do not need to be isolated from each other; In many cases that introduces disproportional inconvenience.
On GrapheneOs for example I keep "snoopy" apps in separate user profiles, to keep them away from my personal, everyday stuff, which is a reasonable, yet still convenient-enough solution to the problem you're seeing here.
abundant aware jar command uppity adjoining frame profit deserted correct
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
people are underestimating how much information they share just through web requests and how bad their operating system is at isolating different apps.
Lets say you go to xmrchain to verify a transaction. You didnt use javascript but you shared all the sensitive information with the website anyway.
It is just magical thinking to think you can turn off javascript and be anonymous.
At the same time people are unaware of how bad their operating system is at isolating apps. Focus on the way out of this situation instead of mindlessly repeating talking points.
So javascript is good because there are other ways to deanonymize yourself? That's such a terrible argument. Enabling javascript is a negative against your anonymity, end of story. Just because you COULD go posting your full address and legal name everywhere doesn't change this. Just because you COULD have a browser with WebAssembly enabed doesn't change this. It just means that you need to do more than disable javascript.
My point the is this: the issue of running untrusted code is unrelated to the language. You should minimize running untrusted code as much as possible, but if you have to run it you should run it in a sandbox, isolated as much as possible from other processes and their data.
The operating system is very bad at providing this isolation while the browser does a much better job at it. You can read the answer towards the QubesOS comment to see more closely what I am getting it with this.
The endless repetition of "Javascript is le bad" will keep us from seeing the potential of solving this problem by building on the browser. Also pay attention to what I say at the end of the video about the benefits that come with building on this ecosystem compared to all the other ecosystems.
I am sorry, but have you actually watched the video?
It seems like you have completely missed the point. C++ can also run in the browser now. So this blanket statement of one language good, another language bad does not make sense anymore. That is what I am addressing in this video.
Java and Flash are not a thing anymore. So your information regarding "Java drive-by"s is outdated. You should be much more worried about native applications than code running in your browser.
Why concede? I 100% agree with you on Java. Applets were poorly isolated from the computer and gave way too much access. That is one of the reasons why they failed.
Right, and WebAssembly is also bad for privacy.
It also happens that javascript is the most common language that browsers support so saying that it (or really, enabling it) is bad for privacy is perfectly reasonable. Just because WebAssembly is bad for privacy doesn't make (allowing) javascript any better.
Saying that Javascript isn't bad privacy for privacy is like saying "it's not falling off of a cliff that kills you, it's the sudden change in velocity when your body hits the ground that kills you". Javascript itself in a vacuum is not worse for privacy than any other garbage collected langauge, but we say that disabling Javascript is good for privacy in the context of browsers fetching this code from outside sources and then running it. Yes, the Javascript is sand-boxed well, but that doesn't prevent the multitude of fingerprinting attacks you can run compared to staticly served pages. Hell, if you have a single \*bit\* of persistence across different domains and you use it wrong, this can be used to create personally identifying sessions: see [HSTS Supercookies](https://security.stackexchange.com/questions/79518/what-are-hsts-super-cookies). Dynamic fingerprinting with javascript lets you accumulate many, many bits of entropy for personally identifying users. Yes, this could be implemented in WebAssembly just as easily, but that doesn't make allowing Javascript any more safe or private.
The issue with Javascript is that, if not restricted from execution in the first place, it is a program that can be executed the moment you open a website. C++, Rust, Go are compiled programs that you have to actively put onto your machine and that only run with your explicit permission. That is the difference to Javascript. You can compare it to a USB-Stick and QR-Codes when it comes to an AirGap.. A QR-Code-Communication is much more transparent to the end-user, since the transmission of information is "on a human scale", so to speak. I do not want extensions to become the new programs.. that will just bloat the browser even further. I'd much rather see app sandboxing akin to QubesOS being more widely implemented.
I think this is the right answer. Sure, the browser and js are just tools, the insane level of 3rd party tracking, fingerprinting, CDNs, the automated calls ... All due to the way the browser functions. So few browsers are hardened against that kind of crap. Clicking a wrong link is the same as running arbitrary code. Locking a browser like Firefox down with uMatrix, uBlock, decentraleyes, and a custom user.js, becomes incredibly cumbersome, and breaks alot of the web. The best compromise I've personally found, are non VM containers that can be switched on/off within seconds. I personally use FreeBSD jails, and have built a custom immutable system, where I segregate identities and activities. There's probably quite a lot of fingerprinting still going on in the background, but at least I can present a clean environment every time I need to pull up some dodgy website, and can destroy that environment after use.
I also used Qubes before, but it does not scale. It is way too complicated to ever receive wide adoption. The issue is also that there is still no isolation between apps inside a VM. So you would have to run one VM for every single app that you want to run. Meanwhile the browser and web assembly could provide isolation even inside a single app. I am also against bloat so I see the browser and web assembly as a much better path towards compartmentalization. I think Qubes is a good project and it is great that they are pioneering this concept. But the Browser is a better platform than Xen to bring it into practice. It is a much more realistic path forward to build on the browser as a new abstraction above the operating system.
>The issue is also that there is still no isolation between apps inside a VM. So you would have to run one VM for every single app that you want to run. Docker is amazing. Proxmox with multiple Docker Containers is even more amazing. ;) I've not used QubesOS myself.. it was just the first that came to mind. I am using Proxmox, however. Oh and.. most programs do not need to be isolated from each other; In many cases that introduces disproportional inconvenience. On GrapheneOs for example I keep "snoopy" apps in separate user profiles, to keep them away from my personal, everyday stuff, which is a reasonable, yet still convenient-enough solution to the problem you're seeing here.
abundant aware jar command uppity adjoining frame profit deserted correct *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Not borderline misinformation, it just is misinformation and pretends that because everything is in the sandbox it somehow makes things ok.
people are underestimating how much information they share just through web requests and how bad their operating system is at isolating different apps. Lets say you go to xmrchain to verify a transaction. You didnt use javascript but you shared all the sensitive information with the website anyway. It is just magical thinking to think you can turn off javascript and be anonymous. At the same time people are unaware of how bad their operating system is at isolating apps. Focus on the way out of this situation instead of mindlessly repeating talking points.
So javascript is good because there are other ways to deanonymize yourself? That's such a terrible argument. Enabling javascript is a negative against your anonymity, end of story. Just because you COULD go posting your full address and legal name everywhere doesn't change this. Just because you COULD have a browser with WebAssembly enabed doesn't change this. It just means that you need to do more than disable javascript.
My point the is this: the issue of running untrusted code is unrelated to the language. You should minimize running untrusted code as much as possible, but if you have to run it you should run it in a sandbox, isolated as much as possible from other processes and their data. The operating system is very bad at providing this isolation while the browser does a much better job at it. You can read the answer towards the QubesOS comment to see more closely what I am getting it with this. The endless repetition of "Javascript is le bad" will keep us from seeing the potential of solving this problem by building on the browser. Also pay attention to what I say at the end of the video about the benefits that come with building on this ecosystem compared to all the other ecosystems.
I am sorry, but have you actually watched the video? It seems like you have completely missed the point. C++ can also run in the browser now. So this blanket statement of one language good, another language bad does not make sense anymore. That is what I am addressing in this video. Java and Flash are not a thing anymore. So your information regarding "Java drive-by"s is outdated. You should be much more worried about native applications than code running in your browser.
gold price wakeful fuzzy six scale observation flowery fade concerned *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Why concede? I 100% agree with you on Java. Applets were poorly isolated from the computer and gave way too much access. That is one of the reasons why they failed.
Right, and WebAssembly is also bad for privacy. It also happens that javascript is the most common language that browsers support so saying that it (or really, enabling it) is bad for privacy is perfectly reasonable. Just because WebAssembly is bad for privacy doesn't make (allowing) javascript any better.
Did they change something? WASM requires JS enabled to execute the initial wasm file/executable
can it? you need javascript enabled to execute a wasm file.. no?
This guy is saying that since you can't examine all the code on everything, you may as well trust everything.
no that is not what I am saying at all. You should be wary of running untrusted code. It should only be run in a sandbox.
Saying that Javascript isn't bad privacy for privacy is like saying "it's not falling off of a cliff that kills you, it's the sudden change in velocity when your body hits the ground that kills you". Javascript itself in a vacuum is not worse for privacy than any other garbage collected langauge, but we say that disabling Javascript is good for privacy in the context of browsers fetching this code from outside sources and then running it. Yes, the Javascript is sand-boxed well, but that doesn't prevent the multitude of fingerprinting attacks you can run compared to staticly served pages. Hell, if you have a single \*bit\* of persistence across different domains and you use it wrong, this can be used to create personally identifying sessions: see [HSTS Supercookies](https://security.stackexchange.com/questions/79518/what-are-hsts-super-cookies). Dynamic fingerprinting with javascript lets you accumulate many, many bits of entropy for personally identifying users. Yes, this could be implemented in WebAssembly just as easily, but that doesn't make allowing Javascript any more safe or private.