▲ 592 ▼ After three months on Linux, I don’t miss Windows at all (www.theverge.com) submitted 4 months ago by cm0002@lemy.lol to c/linux@programming.dev 157 comments fedilink hide all child comments
[+] marxismtomorrow@lemmy.today 2 points 4 months ago (20 children) [deleted] permalink fedilink source parent hideshow 20 child comments replies: [–] BlackLaZoR@lemmy.world 4 points 4 months ago (3 children) Really not how most of the software works. I install ton of apps locally like games, Libre office, ect. Running all in browser is a pipe dream. Also extremely memory and CPU inefficient permalink fedilink source parent hideshow 3 child comments replies: [–] marxismtomorrow@lemmy.today 1 point 4 months ago (2 children) It really is. WebASM is miles beyond what you're probably thinking of in terms of browser based performance, and most companies these days do not have local applications installed for their office workers. Office 365 is by far the most popular version of office, and it's entirely browser based. Most in-house corporate IT work from the last decade is electron wrappers of internal company websites acting as simple interfaces for actual heavy lifting. While there's definitely some apps that are a bit too heavy for WebASM (or just javascript/.net for the above examples) this list is vanishingly short these days. I'd say blender and other 3d rendering would be inefficient just because WebASM has weird interactions with anything other than OpenGL and Vulkan, But even Unreal 5 can export to WebASM and do it fairly well (as well as OpenGL can perform, that poor outdated thing). Heck just go to itch.io or any website that has ported over games to WebGL/WebASM. You can run Half-life directly on your browser these days. Half Life of all games. That's more demanding than anything not 3d that you'd run in an office. permalink fedilink source parent hideshow 2 child comments replies: [–] BlackLaZoR@lemmy.world 3 points 4 months ago I know what web assembly is. It's not a golden one-for-all solution you try to paint it to be. There's a reason why you won't see any modern AAA games in Wasm except ancient stuff like half life or Quake 3. It's just not fast enough and not memory efficient enough. While there’s definitely some apps that are a bit too heavy for WebASM (or just javascript/.net for the above examples) this list is vanishingly short these days. Jesus no. It's obvious you don't play games. Unreal engine can export to Wasm but noone does this. Everyone develops games natively with DirectX 12 api in mind (and very rarely Vulkan like in case of Doom or Red dead redemption 2) You're just blatantly wrong with this. What's web assembly is good for is what's in the God damn name: Web apps. You can squeeze in office into it, because office is ultra lightweight use case, that back in the day ran on 486dx4 with 16Megs of ram. It now runs on 3ghz CPU and requires hundreds of megs of ram, this is insanely wasteful. We can afford these resources, but it's still wasteful as hell. permalink fedilink source parent [–] Tempy@programming.dev 2 points 4 months ago* Office 365 also refers to the desktop apps as well as the web versions, has done for many years now. Though I suppose it's all copilot 365 now. Source: Am office worker where we use office 365, and we all use the native system software, with the browser versions as for quick editing when elsewhere. permalink fedilink source parent [–] tux0r@snac.rosaelefanten.org -2 points 4 months ago (15 children) Counter-example: secure encryption. You can't do that in a browser. permalink fedilink source parent hideshow 15 child comments replies: [–] bearboiblake@pawb.social 4 points 4 months ago (12 children) You're all over this thread posting bad takes. Of course you can do secure encryption in a browser. There's absolutely nothing stopping you from using any encryption algorithms within a browser whatsoever. I don't even understand what you could possibly mean. There are so many ways to achieve it. permalink fedilink source parent hideshow 12 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (11 children) There are numerous ways to place decryption backdoors into a website's JavaScript. How would you make sure that there is no MITM when trying to safely encrypt (e.g.) an e-mail in your browser? Of course you can do secure encryption in a browser. Talking about "bad takes", aren't we? There is no way to ensure that your end-to-end encryption is not decrypted on the fly when done by a website (= a potential attacker). permalink fedilink source parent hideshow 11 child comments replies: [–] bearboiblake@pawb.social 5 points 4 months ago* (10 children) Who said anything about a website? You said browser. You can run fully-local resources in a browser, such as browser extensions, locally hosted tools, even just running in a .html file on your local disk somewhere. Javascript also isn't the only option available to solve this problem. permalink fedilink source parent hideshow 10 child comments replies: [–] tux0r@snac.rosaelefanten.org -4 points 4 months ago (9 children) Not sure if you're just trolling at this point. You said: Of course you can do secure encryption in a browser. No, you can't. I explained why. permalink fedilink source parent hideshow 9 child comments replies: [–] bearboiblake@pawb.social 5 points 4 months ago (8 children) ...and I just explained to you how you can? permalink fedilink source parent hideshow 8 child comments replies: [–] tux0r@snac.rosaelefanten.org -2 points 4 months ago (7 children) Ok, I'll bite: You can run fully-local resources in a browser, such as browser extensions, locally hosted tools, even just running in a .html file on your local disk somewhere. How would you do that without violating essential security measurements? permalink fedilink source parent hideshow 7 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago (6 children) Create or download an implementation of your preferred encryption algorithm for Javascript (or use some WebAssembly alternative). e.g. https://github.com/ricmoo/aes-js Run the implementation on your local computer and open it in a browser. Hope this helps. permalink fedilink source parent hideshow 6 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago (5 children) You are aware that WASM requires JS, right? I mean, yes, running the application itself would be secure, but that's not in the browser. You cannot trust your browser. Ever. permalink fedilink source parent hideshow 5 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (4 children) You are aware that WASM requires JS, right? I think you're mistaken, there. WASM is often used alongside Javascript, but beyond the one-liner to fetch and load it, there's actually nothing which inherently requires JS beyond that. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? permalink fedilink source parent hideshow 4 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (last edited 4 months ago) (3 children) WASM is often used alongside Javascript, but there’s actually nothing which inherently requires it. There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? A web browser is the most vulnerable software on your computer. To stick with the one example I brought, namely GnuPG encrypted e-mails: Running GnuPG locally on my machine to encrypt/decrypt/verify an e-mail before pasting the result into (e.g.) my e-mail client is reasonably secure. GnuPG has been audited thoroughly enough, so it's (relatively) safe to assume that no bad actor will read and/or modify the e-mail on the way. I am not aware of any JavaScript alternative with a similar security record. I think we're derailing a bit though. My original comment was: You can’t do that (= secure encryption) in a browser. Locally and in a browser are, in real life, mostly different things and I assume you know that. GnuPG in webmail software without having used it locally first, which is what I was hinting at, just isn't secure. edit: Bed time, might continue this tomorrow after work if I'll find some Lemmy time... good night for now! permalink fedilink source parent hideshow 3 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (2 children) There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. I thought you meant like you had to use Javascript to marshal between the WASM module and the user interaction. What you really meant is that you're objecting to, basically, a load call. One line of Javascript code to load and run the WASM module. What possible security risk could that pose? And again, I've not heard an adequate explanation as to how locally-running JavaScript encryption code would be any less secure than, for example, running a Python script in the terminal. Locally and in a browser are, in real life, mostly different things and I assume you know that. I think you're basically admitting that you meant that verifiably secure encryption using a website is impossible (other than e.g. TLS), which I would agree with, but that's not what you wrote. Browser extensions are used all the time to handle all sorts of secure encryption in high risk scenarios, such as for password managers. That is a perfectly valid example of encryption within a browser - and it was the first one I mentioned. Please just admit you were wrong, or that you meant to say "website" rather than "browser". It's okay, trust me, people respect you more when you can admit that sort of thing, it makes you look strong and capable of taking criticism. permalink fedilink source parent hideshow 2 child comments replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago (1 child) I might, indeed, have miscommunicated my assumptions. Thank you for pointing it out. permalink fedilink source parent hideshow 1 child comment replies: [–] bearboiblake@pawb.social 1 point 4 months ago No worries! Take care, and sleep well <3 permalink fedilink source parent [+] marxismtomorrow@lemmy.today 1 point 4 months ago (1 child) [deleted] permalink fedilink source parent hideshow 1 child comment replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago That's a very loose definition indeed. "Close enough to a browser" isn't a browser. GnuPG in a browser just won't work and most other encryption facilities aren't quite as secure (and transparent). permalink fedilink source parent
[–] BlackLaZoR@lemmy.world 4 points 4 months ago (3 children) Really not how most of the software works. I install ton of apps locally like games, Libre office, ect. Running all in browser is a pipe dream. Also extremely memory and CPU inefficient permalink fedilink source parent hideshow 3 child comments replies: [–] marxismtomorrow@lemmy.today 1 point 4 months ago (2 children) It really is. WebASM is miles beyond what you're probably thinking of in terms of browser based performance, and most companies these days do not have local applications installed for their office workers. Office 365 is by far the most popular version of office, and it's entirely browser based. Most in-house corporate IT work from the last decade is electron wrappers of internal company websites acting as simple interfaces for actual heavy lifting. While there's definitely some apps that are a bit too heavy for WebASM (or just javascript/.net for the above examples) this list is vanishingly short these days. I'd say blender and other 3d rendering would be inefficient just because WebASM has weird interactions with anything other than OpenGL and Vulkan, But even Unreal 5 can export to WebASM and do it fairly well (as well as OpenGL can perform, that poor outdated thing). Heck just go to itch.io or any website that has ported over games to WebGL/WebASM. You can run Half-life directly on your browser these days. Half Life of all games. That's more demanding than anything not 3d that you'd run in an office. permalink fedilink source parent hideshow 2 child comments replies: [–] BlackLaZoR@lemmy.world 3 points 4 months ago I know what web assembly is. It's not a golden one-for-all solution you try to paint it to be. There's a reason why you won't see any modern AAA games in Wasm except ancient stuff like half life or Quake 3. It's just not fast enough and not memory efficient enough. While there’s definitely some apps that are a bit too heavy for WebASM (or just javascript/.net for the above examples) this list is vanishingly short these days. Jesus no. It's obvious you don't play games. Unreal engine can export to Wasm but noone does this. Everyone develops games natively with DirectX 12 api in mind (and very rarely Vulkan like in case of Doom or Red dead redemption 2) You're just blatantly wrong with this. What's web assembly is good for is what's in the God damn name: Web apps. You can squeeze in office into it, because office is ultra lightweight use case, that back in the day ran on 486dx4 with 16Megs of ram. It now runs on 3ghz CPU and requires hundreds of megs of ram, this is insanely wasteful. We can afford these resources, but it's still wasteful as hell. permalink fedilink source parent [–] Tempy@programming.dev 2 points 4 months ago* Office 365 also refers to the desktop apps as well as the web versions, has done for many years now. Though I suppose it's all copilot 365 now. Source: Am office worker where we use office 365, and we all use the native system software, with the browser versions as for quick editing when elsewhere. permalink fedilink source parent
[–] marxismtomorrow@lemmy.today 1 point 4 months ago (2 children) It really is. WebASM is miles beyond what you're probably thinking of in terms of browser based performance, and most companies these days do not have local applications installed for their office workers. Office 365 is by far the most popular version of office, and it's entirely browser based. Most in-house corporate IT work from the last decade is electron wrappers of internal company websites acting as simple interfaces for actual heavy lifting. While there's definitely some apps that are a bit too heavy for WebASM (or just javascript/.net for the above examples) this list is vanishingly short these days. I'd say blender and other 3d rendering would be inefficient just because WebASM has weird interactions with anything other than OpenGL and Vulkan, But even Unreal 5 can export to WebASM and do it fairly well (as well as OpenGL can perform, that poor outdated thing). Heck just go to itch.io or any website that has ported over games to WebGL/WebASM. You can run Half-life directly on your browser these days. Half Life of all games. That's more demanding than anything not 3d that you'd run in an office. permalink fedilink source parent hideshow 2 child comments replies: [–] BlackLaZoR@lemmy.world 3 points 4 months ago I know what web assembly is. It's not a golden one-for-all solution you try to paint it to be. There's a reason why you won't see any modern AAA games in Wasm except ancient stuff like half life or Quake 3. It's just not fast enough and not memory efficient enough. While there’s definitely some apps that are a bit too heavy for WebASM (or just javascript/.net for the above examples) this list is vanishingly short these days. Jesus no. It's obvious you don't play games. Unreal engine can export to Wasm but noone does this. Everyone develops games natively with DirectX 12 api in mind (and very rarely Vulkan like in case of Doom or Red dead redemption 2) You're just blatantly wrong with this. What's web assembly is good for is what's in the God damn name: Web apps. You can squeeze in office into it, because office is ultra lightweight use case, that back in the day ran on 486dx4 with 16Megs of ram. It now runs on 3ghz CPU and requires hundreds of megs of ram, this is insanely wasteful. We can afford these resources, but it's still wasteful as hell. permalink fedilink source parent [–] Tempy@programming.dev 2 points 4 months ago* Office 365 also refers to the desktop apps as well as the web versions, has done for many years now. Though I suppose it's all copilot 365 now. Source: Am office worker where we use office 365, and we all use the native system software, with the browser versions as for quick editing when elsewhere. permalink fedilink source parent
[–] BlackLaZoR@lemmy.world 3 points 4 months ago I know what web assembly is. It's not a golden one-for-all solution you try to paint it to be. There's a reason why you won't see any modern AAA games in Wasm except ancient stuff like half life or Quake 3. It's just not fast enough and not memory efficient enough. While there’s definitely some apps that are a bit too heavy for WebASM (or just javascript/.net for the above examples) this list is vanishingly short these days. Jesus no. It's obvious you don't play games. Unreal engine can export to Wasm but noone does this. Everyone develops games natively with DirectX 12 api in mind (and very rarely Vulkan like in case of Doom or Red dead redemption 2) You're just blatantly wrong with this. What's web assembly is good for is what's in the God damn name: Web apps. You can squeeze in office into it, because office is ultra lightweight use case, that back in the day ran on 486dx4 with 16Megs of ram. It now runs on 3ghz CPU and requires hundreds of megs of ram, this is insanely wasteful. We can afford these resources, but it's still wasteful as hell. permalink fedilink source parent
[–] Tempy@programming.dev 2 points 4 months ago* Office 365 also refers to the desktop apps as well as the web versions, has done for many years now. Though I suppose it's all copilot 365 now. Source: Am office worker where we use office 365, and we all use the native system software, with the browser versions as for quick editing when elsewhere. permalink fedilink source parent
[–] tux0r@snac.rosaelefanten.org -2 points 4 months ago (15 children) Counter-example: secure encryption. You can't do that in a browser. permalink fedilink source parent hideshow 15 child comments replies: [–] bearboiblake@pawb.social 4 points 4 months ago (12 children) You're all over this thread posting bad takes. Of course you can do secure encryption in a browser. There's absolutely nothing stopping you from using any encryption algorithms within a browser whatsoever. I don't even understand what you could possibly mean. There are so many ways to achieve it. permalink fedilink source parent hideshow 12 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (11 children) There are numerous ways to place decryption backdoors into a website's JavaScript. How would you make sure that there is no MITM when trying to safely encrypt (e.g.) an e-mail in your browser? Of course you can do secure encryption in a browser. Talking about "bad takes", aren't we? There is no way to ensure that your end-to-end encryption is not decrypted on the fly when done by a website (= a potential attacker). permalink fedilink source parent hideshow 11 child comments replies: [–] bearboiblake@pawb.social 5 points 4 months ago* (10 children) Who said anything about a website? You said browser. You can run fully-local resources in a browser, such as browser extensions, locally hosted tools, even just running in a .html file on your local disk somewhere. Javascript also isn't the only option available to solve this problem. permalink fedilink source parent hideshow 10 child comments replies: [–] tux0r@snac.rosaelefanten.org -4 points 4 months ago (9 children) Not sure if you're just trolling at this point. You said: Of course you can do secure encryption in a browser. No, you can't. I explained why. permalink fedilink source parent hideshow 9 child comments replies: [–] bearboiblake@pawb.social 5 points 4 months ago (8 children) ...and I just explained to you how you can? permalink fedilink source parent hideshow 8 child comments replies: [–] tux0r@snac.rosaelefanten.org -2 points 4 months ago (7 children) Ok, I'll bite: You can run fully-local resources in a browser, such as browser extensions, locally hosted tools, even just running in a .html file on your local disk somewhere. How would you do that without violating essential security measurements? permalink fedilink source parent hideshow 7 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago (6 children) Create or download an implementation of your preferred encryption algorithm for Javascript (or use some WebAssembly alternative). e.g. https://github.com/ricmoo/aes-js Run the implementation on your local computer and open it in a browser. Hope this helps. permalink fedilink source parent hideshow 6 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago (5 children) You are aware that WASM requires JS, right? I mean, yes, running the application itself would be secure, but that's not in the browser. You cannot trust your browser. Ever. permalink fedilink source parent hideshow 5 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (4 children) You are aware that WASM requires JS, right? I think you're mistaken, there. WASM is often used alongside Javascript, but beyond the one-liner to fetch and load it, there's actually nothing which inherently requires JS beyond that. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? permalink fedilink source parent hideshow 4 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (last edited 4 months ago) (3 children) WASM is often used alongside Javascript, but there’s actually nothing which inherently requires it. There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? A web browser is the most vulnerable software on your computer. To stick with the one example I brought, namely GnuPG encrypted e-mails: Running GnuPG locally on my machine to encrypt/decrypt/verify an e-mail before pasting the result into (e.g.) my e-mail client is reasonably secure. GnuPG has been audited thoroughly enough, so it's (relatively) safe to assume that no bad actor will read and/or modify the e-mail on the way. I am not aware of any JavaScript alternative with a similar security record. I think we're derailing a bit though. My original comment was: You can’t do that (= secure encryption) in a browser. Locally and in a browser are, in real life, mostly different things and I assume you know that. GnuPG in webmail software without having used it locally first, which is what I was hinting at, just isn't secure. edit: Bed time, might continue this tomorrow after work if I'll find some Lemmy time... good night for now! permalink fedilink source parent hideshow 3 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (2 children) There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. I thought you meant like you had to use Javascript to marshal between the WASM module and the user interaction. What you really meant is that you're objecting to, basically, a load call. One line of Javascript code to load and run the WASM module. What possible security risk could that pose? And again, I've not heard an adequate explanation as to how locally-running JavaScript encryption code would be any less secure than, for example, running a Python script in the terminal. Locally and in a browser are, in real life, mostly different things and I assume you know that. I think you're basically admitting that you meant that verifiably secure encryption using a website is impossible (other than e.g. TLS), which I would agree with, but that's not what you wrote. Browser extensions are used all the time to handle all sorts of secure encryption in high risk scenarios, such as for password managers. That is a perfectly valid example of encryption within a browser - and it was the first one I mentioned. Please just admit you were wrong, or that you meant to say "website" rather than "browser". It's okay, trust me, people respect you more when you can admit that sort of thing, it makes you look strong and capable of taking criticism. permalink fedilink source parent hideshow 2 child comments replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago (1 child) I might, indeed, have miscommunicated my assumptions. Thank you for pointing it out. permalink fedilink source parent hideshow 1 child comment replies: [–] bearboiblake@pawb.social 1 point 4 months ago No worries! Take care, and sleep well <3 permalink fedilink source parent [+] marxismtomorrow@lemmy.today 1 point 4 months ago (1 child) [deleted] permalink fedilink source parent hideshow 1 child comment replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago That's a very loose definition indeed. "Close enough to a browser" isn't a browser. GnuPG in a browser just won't work and most other encryption facilities aren't quite as secure (and transparent). permalink fedilink source parent
[–] bearboiblake@pawb.social 4 points 4 months ago (12 children) You're all over this thread posting bad takes. Of course you can do secure encryption in a browser. There's absolutely nothing stopping you from using any encryption algorithms within a browser whatsoever. I don't even understand what you could possibly mean. There are so many ways to achieve it. permalink fedilink source parent hideshow 12 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (11 children) There are numerous ways to place decryption backdoors into a website's JavaScript. How would you make sure that there is no MITM when trying to safely encrypt (e.g.) an e-mail in your browser? Of course you can do secure encryption in a browser. Talking about "bad takes", aren't we? There is no way to ensure that your end-to-end encryption is not decrypted on the fly when done by a website (= a potential attacker). permalink fedilink source parent hideshow 11 child comments replies: [–] bearboiblake@pawb.social 5 points 4 months ago* (10 children) Who said anything about a website? You said browser. You can run fully-local resources in a browser, such as browser extensions, locally hosted tools, even just running in a .html file on your local disk somewhere. Javascript also isn't the only option available to solve this problem. permalink fedilink source parent hideshow 10 child comments replies: [–] tux0r@snac.rosaelefanten.org -4 points 4 months ago (9 children) Not sure if you're just trolling at this point. You said: Of course you can do secure encryption in a browser. No, you can't. I explained why. permalink fedilink source parent hideshow 9 child comments replies: [–] bearboiblake@pawb.social 5 points 4 months ago (8 children) ...and I just explained to you how you can? permalink fedilink source parent hideshow 8 child comments replies: [–] tux0r@snac.rosaelefanten.org -2 points 4 months ago (7 children) Ok, I'll bite: You can run fully-local resources in a browser, such as browser extensions, locally hosted tools, even just running in a .html file on your local disk somewhere. How would you do that without violating essential security measurements? permalink fedilink source parent hideshow 7 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago (6 children) Create or download an implementation of your preferred encryption algorithm for Javascript (or use some WebAssembly alternative). e.g. https://github.com/ricmoo/aes-js Run the implementation on your local computer and open it in a browser. Hope this helps. permalink fedilink source parent hideshow 6 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago (5 children) You are aware that WASM requires JS, right? I mean, yes, running the application itself would be secure, but that's not in the browser. You cannot trust your browser. Ever. permalink fedilink source parent hideshow 5 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (4 children) You are aware that WASM requires JS, right? I think you're mistaken, there. WASM is often used alongside Javascript, but beyond the one-liner to fetch and load it, there's actually nothing which inherently requires JS beyond that. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? permalink fedilink source parent hideshow 4 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (last edited 4 months ago) (3 children) WASM is often used alongside Javascript, but there’s actually nothing which inherently requires it. There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? A web browser is the most vulnerable software on your computer. To stick with the one example I brought, namely GnuPG encrypted e-mails: Running GnuPG locally on my machine to encrypt/decrypt/verify an e-mail before pasting the result into (e.g.) my e-mail client is reasonably secure. GnuPG has been audited thoroughly enough, so it's (relatively) safe to assume that no bad actor will read and/or modify the e-mail on the way. I am not aware of any JavaScript alternative with a similar security record. I think we're derailing a bit though. My original comment was: You can’t do that (= secure encryption) in a browser. Locally and in a browser are, in real life, mostly different things and I assume you know that. GnuPG in webmail software without having used it locally first, which is what I was hinting at, just isn't secure. edit: Bed time, might continue this tomorrow after work if I'll find some Lemmy time... good night for now! permalink fedilink source parent hideshow 3 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (2 children) There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. I thought you meant like you had to use Javascript to marshal between the WASM module and the user interaction. What you really meant is that you're objecting to, basically, a load call. One line of Javascript code to load and run the WASM module. What possible security risk could that pose? And again, I've not heard an adequate explanation as to how locally-running JavaScript encryption code would be any less secure than, for example, running a Python script in the terminal. Locally and in a browser are, in real life, mostly different things and I assume you know that. I think you're basically admitting that you meant that verifiably secure encryption using a website is impossible (other than e.g. TLS), which I would agree with, but that's not what you wrote. Browser extensions are used all the time to handle all sorts of secure encryption in high risk scenarios, such as for password managers. That is a perfectly valid example of encryption within a browser - and it was the first one I mentioned. Please just admit you were wrong, or that you meant to say "website" rather than "browser". It's okay, trust me, people respect you more when you can admit that sort of thing, it makes you look strong and capable of taking criticism. permalink fedilink source parent hideshow 2 child comments replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago (1 child) I might, indeed, have miscommunicated my assumptions. Thank you for pointing it out. permalink fedilink source parent hideshow 1 child comment replies: [–] bearboiblake@pawb.social 1 point 4 months ago No worries! Take care, and sleep well <3 permalink fedilink source parent
[–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (11 children) There are numerous ways to place decryption backdoors into a website's JavaScript. How would you make sure that there is no MITM when trying to safely encrypt (e.g.) an e-mail in your browser? Of course you can do secure encryption in a browser. Talking about "bad takes", aren't we? There is no way to ensure that your end-to-end encryption is not decrypted on the fly when done by a website (= a potential attacker). permalink fedilink source parent hideshow 11 child comments replies: [–] bearboiblake@pawb.social 5 points 4 months ago* (10 children) Who said anything about a website? You said browser. You can run fully-local resources in a browser, such as browser extensions, locally hosted tools, even just running in a .html file on your local disk somewhere. Javascript also isn't the only option available to solve this problem. permalink fedilink source parent hideshow 10 child comments replies: [–] tux0r@snac.rosaelefanten.org -4 points 4 months ago (9 children) Not sure if you're just trolling at this point. You said: Of course you can do secure encryption in a browser. No, you can't. I explained why. permalink fedilink source parent hideshow 9 child comments replies: [–] bearboiblake@pawb.social 5 points 4 months ago (8 children) ...and I just explained to you how you can? permalink fedilink source parent hideshow 8 child comments replies: [–] tux0r@snac.rosaelefanten.org -2 points 4 months ago (7 children) Ok, I'll bite: You can run fully-local resources in a browser, such as browser extensions, locally hosted tools, even just running in a .html file on your local disk somewhere. How would you do that without violating essential security measurements? permalink fedilink source parent hideshow 7 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago (6 children) Create or download an implementation of your preferred encryption algorithm for Javascript (or use some WebAssembly alternative). e.g. https://github.com/ricmoo/aes-js Run the implementation on your local computer and open it in a browser. Hope this helps. permalink fedilink source parent hideshow 6 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago (5 children) You are aware that WASM requires JS, right? I mean, yes, running the application itself would be secure, but that's not in the browser. You cannot trust your browser. Ever. permalink fedilink source parent hideshow 5 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (4 children) You are aware that WASM requires JS, right? I think you're mistaken, there. WASM is often used alongside Javascript, but beyond the one-liner to fetch and load it, there's actually nothing which inherently requires JS beyond that. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? permalink fedilink source parent hideshow 4 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (last edited 4 months ago) (3 children) WASM is often used alongside Javascript, but there’s actually nothing which inherently requires it. There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? A web browser is the most vulnerable software on your computer. To stick with the one example I brought, namely GnuPG encrypted e-mails: Running GnuPG locally on my machine to encrypt/decrypt/verify an e-mail before pasting the result into (e.g.) my e-mail client is reasonably secure. GnuPG has been audited thoroughly enough, so it's (relatively) safe to assume that no bad actor will read and/or modify the e-mail on the way. I am not aware of any JavaScript alternative with a similar security record. I think we're derailing a bit though. My original comment was: You can’t do that (= secure encryption) in a browser. Locally and in a browser are, in real life, mostly different things and I assume you know that. GnuPG in webmail software without having used it locally first, which is what I was hinting at, just isn't secure. edit: Bed time, might continue this tomorrow after work if I'll find some Lemmy time... good night for now! permalink fedilink source parent hideshow 3 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (2 children) There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. I thought you meant like you had to use Javascript to marshal between the WASM module and the user interaction. What you really meant is that you're objecting to, basically, a load call. One line of Javascript code to load and run the WASM module. What possible security risk could that pose? And again, I've not heard an adequate explanation as to how locally-running JavaScript encryption code would be any less secure than, for example, running a Python script in the terminal. Locally and in a browser are, in real life, mostly different things and I assume you know that. I think you're basically admitting that you meant that verifiably secure encryption using a website is impossible (other than e.g. TLS), which I would agree with, but that's not what you wrote. Browser extensions are used all the time to handle all sorts of secure encryption in high risk scenarios, such as for password managers. That is a perfectly valid example of encryption within a browser - and it was the first one I mentioned. Please just admit you were wrong, or that you meant to say "website" rather than "browser". It's okay, trust me, people respect you more when you can admit that sort of thing, it makes you look strong and capable of taking criticism. permalink fedilink source parent hideshow 2 child comments replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago (1 child) I might, indeed, have miscommunicated my assumptions. Thank you for pointing it out. permalink fedilink source parent hideshow 1 child comment replies: [–] bearboiblake@pawb.social 1 point 4 months ago No worries! Take care, and sleep well <3 permalink fedilink source parent
[–] bearboiblake@pawb.social 5 points 4 months ago* (10 children) Who said anything about a website? You said browser. You can run fully-local resources in a browser, such as browser extensions, locally hosted tools, even just running in a .html file on your local disk somewhere. Javascript also isn't the only option available to solve this problem. permalink fedilink source parent hideshow 10 child comments replies: [–] tux0r@snac.rosaelefanten.org -4 points 4 months ago (9 children) Not sure if you're just trolling at this point. You said: Of course you can do secure encryption in a browser. No, you can't. I explained why. permalink fedilink source parent hideshow 9 child comments replies: [–] bearboiblake@pawb.social 5 points 4 months ago (8 children) ...and I just explained to you how you can? permalink fedilink source parent hideshow 8 child comments replies: [–] tux0r@snac.rosaelefanten.org -2 points 4 months ago (7 children) Ok, I'll bite: You can run fully-local resources in a browser, such as browser extensions, locally hosted tools, even just running in a .html file on your local disk somewhere. How would you do that without violating essential security measurements? permalink fedilink source parent hideshow 7 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago (6 children) Create or download an implementation of your preferred encryption algorithm for Javascript (or use some WebAssembly alternative). e.g. https://github.com/ricmoo/aes-js Run the implementation on your local computer and open it in a browser. Hope this helps. permalink fedilink source parent hideshow 6 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago (5 children) You are aware that WASM requires JS, right? I mean, yes, running the application itself would be secure, but that's not in the browser. You cannot trust your browser. Ever. permalink fedilink source parent hideshow 5 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (4 children) You are aware that WASM requires JS, right? I think you're mistaken, there. WASM is often used alongside Javascript, but beyond the one-liner to fetch and load it, there's actually nothing which inherently requires JS beyond that. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? permalink fedilink source parent hideshow 4 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (last edited 4 months ago) (3 children) WASM is often used alongside Javascript, but there’s actually nothing which inherently requires it. There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? A web browser is the most vulnerable software on your computer. To stick with the one example I brought, namely GnuPG encrypted e-mails: Running GnuPG locally on my machine to encrypt/decrypt/verify an e-mail before pasting the result into (e.g.) my e-mail client is reasonably secure. GnuPG has been audited thoroughly enough, so it's (relatively) safe to assume that no bad actor will read and/or modify the e-mail on the way. I am not aware of any JavaScript alternative with a similar security record. I think we're derailing a bit though. My original comment was: You can’t do that (= secure encryption) in a browser. Locally and in a browser are, in real life, mostly different things and I assume you know that. GnuPG in webmail software without having used it locally first, which is what I was hinting at, just isn't secure. edit: Bed time, might continue this tomorrow after work if I'll find some Lemmy time... good night for now! permalink fedilink source parent hideshow 3 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (2 children) There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. I thought you meant like you had to use Javascript to marshal between the WASM module and the user interaction. What you really meant is that you're objecting to, basically, a load call. One line of Javascript code to load and run the WASM module. What possible security risk could that pose? And again, I've not heard an adequate explanation as to how locally-running JavaScript encryption code would be any less secure than, for example, running a Python script in the terminal. Locally and in a browser are, in real life, mostly different things and I assume you know that. I think you're basically admitting that you meant that verifiably secure encryption using a website is impossible (other than e.g. TLS), which I would agree with, but that's not what you wrote. Browser extensions are used all the time to handle all sorts of secure encryption in high risk scenarios, such as for password managers. That is a perfectly valid example of encryption within a browser - and it was the first one I mentioned. Please just admit you were wrong, or that you meant to say "website" rather than "browser". It's okay, trust me, people respect you more when you can admit that sort of thing, it makes you look strong and capable of taking criticism. permalink fedilink source parent hideshow 2 child comments replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago (1 child) I might, indeed, have miscommunicated my assumptions. Thank you for pointing it out. permalink fedilink source parent hideshow 1 child comment replies: [–] bearboiblake@pawb.social 1 point 4 months ago No worries! Take care, and sleep well <3 permalink fedilink source parent
[–] tux0r@snac.rosaelefanten.org -4 points 4 months ago (9 children) Not sure if you're just trolling at this point. You said: Of course you can do secure encryption in a browser. No, you can't. I explained why. permalink fedilink source parent hideshow 9 child comments replies: [–] bearboiblake@pawb.social 5 points 4 months ago (8 children) ...and I just explained to you how you can? permalink fedilink source parent hideshow 8 child comments replies: [–] tux0r@snac.rosaelefanten.org -2 points 4 months ago (7 children) Ok, I'll bite: You can run fully-local resources in a browser, such as browser extensions, locally hosted tools, even just running in a .html file on your local disk somewhere. How would you do that without violating essential security measurements? permalink fedilink source parent hideshow 7 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago (6 children) Create or download an implementation of your preferred encryption algorithm for Javascript (or use some WebAssembly alternative). e.g. https://github.com/ricmoo/aes-js Run the implementation on your local computer and open it in a browser. Hope this helps. permalink fedilink source parent hideshow 6 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago (5 children) You are aware that WASM requires JS, right? I mean, yes, running the application itself would be secure, but that's not in the browser. You cannot trust your browser. Ever. permalink fedilink source parent hideshow 5 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (4 children) You are aware that WASM requires JS, right? I think you're mistaken, there. WASM is often used alongside Javascript, but beyond the one-liner to fetch and load it, there's actually nothing which inherently requires JS beyond that. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? permalink fedilink source parent hideshow 4 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (last edited 4 months ago) (3 children) WASM is often used alongside Javascript, but there’s actually nothing which inherently requires it. There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? A web browser is the most vulnerable software on your computer. To stick with the one example I brought, namely GnuPG encrypted e-mails: Running GnuPG locally on my machine to encrypt/decrypt/verify an e-mail before pasting the result into (e.g.) my e-mail client is reasonably secure. GnuPG has been audited thoroughly enough, so it's (relatively) safe to assume that no bad actor will read and/or modify the e-mail on the way. I am not aware of any JavaScript alternative with a similar security record. I think we're derailing a bit though. My original comment was: You can’t do that (= secure encryption) in a browser. Locally and in a browser are, in real life, mostly different things and I assume you know that. GnuPG in webmail software without having used it locally first, which is what I was hinting at, just isn't secure. edit: Bed time, might continue this tomorrow after work if I'll find some Lemmy time... good night for now! permalink fedilink source parent hideshow 3 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (2 children) There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. I thought you meant like you had to use Javascript to marshal between the WASM module and the user interaction. What you really meant is that you're objecting to, basically, a load call. One line of Javascript code to load and run the WASM module. What possible security risk could that pose? And again, I've not heard an adequate explanation as to how locally-running JavaScript encryption code would be any less secure than, for example, running a Python script in the terminal. Locally and in a browser are, in real life, mostly different things and I assume you know that. I think you're basically admitting that you meant that verifiably secure encryption using a website is impossible (other than e.g. TLS), which I would agree with, but that's not what you wrote. Browser extensions are used all the time to handle all sorts of secure encryption in high risk scenarios, such as for password managers. That is a perfectly valid example of encryption within a browser - and it was the first one I mentioned. Please just admit you were wrong, or that you meant to say "website" rather than "browser". It's okay, trust me, people respect you more when you can admit that sort of thing, it makes you look strong and capable of taking criticism. permalink fedilink source parent hideshow 2 child comments replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago (1 child) I might, indeed, have miscommunicated my assumptions. Thank you for pointing it out. permalink fedilink source parent hideshow 1 child comment replies: [–] bearboiblake@pawb.social 1 point 4 months ago No worries! Take care, and sleep well <3 permalink fedilink source parent
[–] bearboiblake@pawb.social 5 points 4 months ago (8 children) ...and I just explained to you how you can? permalink fedilink source parent hideshow 8 child comments replies: [–] tux0r@snac.rosaelefanten.org -2 points 4 months ago (7 children) Ok, I'll bite: You can run fully-local resources in a browser, such as browser extensions, locally hosted tools, even just running in a .html file on your local disk somewhere. How would you do that without violating essential security measurements? permalink fedilink source parent hideshow 7 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago (6 children) Create or download an implementation of your preferred encryption algorithm for Javascript (or use some WebAssembly alternative). e.g. https://github.com/ricmoo/aes-js Run the implementation on your local computer and open it in a browser. Hope this helps. permalink fedilink source parent hideshow 6 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago (5 children) You are aware that WASM requires JS, right? I mean, yes, running the application itself would be secure, but that's not in the browser. You cannot trust your browser. Ever. permalink fedilink source parent hideshow 5 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (4 children) You are aware that WASM requires JS, right? I think you're mistaken, there. WASM is often used alongside Javascript, but beyond the one-liner to fetch and load it, there's actually nothing which inherently requires JS beyond that. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? permalink fedilink source parent hideshow 4 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (last edited 4 months ago) (3 children) WASM is often used alongside Javascript, but there’s actually nothing which inherently requires it. There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? A web browser is the most vulnerable software on your computer. To stick with the one example I brought, namely GnuPG encrypted e-mails: Running GnuPG locally on my machine to encrypt/decrypt/verify an e-mail before pasting the result into (e.g.) my e-mail client is reasonably secure. GnuPG has been audited thoroughly enough, so it's (relatively) safe to assume that no bad actor will read and/or modify the e-mail on the way. I am not aware of any JavaScript alternative with a similar security record. I think we're derailing a bit though. My original comment was: You can’t do that (= secure encryption) in a browser. Locally and in a browser are, in real life, mostly different things and I assume you know that. GnuPG in webmail software without having used it locally first, which is what I was hinting at, just isn't secure. edit: Bed time, might continue this tomorrow after work if I'll find some Lemmy time... good night for now! permalink fedilink source parent hideshow 3 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (2 children) There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. I thought you meant like you had to use Javascript to marshal between the WASM module and the user interaction. What you really meant is that you're objecting to, basically, a load call. One line of Javascript code to load and run the WASM module. What possible security risk could that pose? And again, I've not heard an adequate explanation as to how locally-running JavaScript encryption code would be any less secure than, for example, running a Python script in the terminal. Locally and in a browser are, in real life, mostly different things and I assume you know that. I think you're basically admitting that you meant that verifiably secure encryption using a website is impossible (other than e.g. TLS), which I would agree with, but that's not what you wrote. Browser extensions are used all the time to handle all sorts of secure encryption in high risk scenarios, such as for password managers. That is a perfectly valid example of encryption within a browser - and it was the first one I mentioned. Please just admit you were wrong, or that you meant to say "website" rather than "browser". It's okay, trust me, people respect you more when you can admit that sort of thing, it makes you look strong and capable of taking criticism. permalink fedilink source parent hideshow 2 child comments replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago (1 child) I might, indeed, have miscommunicated my assumptions. Thank you for pointing it out. permalink fedilink source parent hideshow 1 child comment replies: [–] bearboiblake@pawb.social 1 point 4 months ago No worries! Take care, and sleep well <3 permalink fedilink source parent
[–] tux0r@snac.rosaelefanten.org -2 points 4 months ago (7 children) Ok, I'll bite: You can run fully-local resources in a browser, such as browser extensions, locally hosted tools, even just running in a .html file on your local disk somewhere. How would you do that without violating essential security measurements? permalink fedilink source parent hideshow 7 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago (6 children) Create or download an implementation of your preferred encryption algorithm for Javascript (or use some WebAssembly alternative). e.g. https://github.com/ricmoo/aes-js Run the implementation on your local computer and open it in a browser. Hope this helps. permalink fedilink source parent hideshow 6 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago (5 children) You are aware that WASM requires JS, right? I mean, yes, running the application itself would be secure, but that's not in the browser. You cannot trust your browser. Ever. permalink fedilink source parent hideshow 5 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (4 children) You are aware that WASM requires JS, right? I think you're mistaken, there. WASM is often used alongside Javascript, but beyond the one-liner to fetch and load it, there's actually nothing which inherently requires JS beyond that. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? permalink fedilink source parent hideshow 4 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (last edited 4 months ago) (3 children) WASM is often used alongside Javascript, but there’s actually nothing which inherently requires it. There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? A web browser is the most vulnerable software on your computer. To stick with the one example I brought, namely GnuPG encrypted e-mails: Running GnuPG locally on my machine to encrypt/decrypt/verify an e-mail before pasting the result into (e.g.) my e-mail client is reasonably secure. GnuPG has been audited thoroughly enough, so it's (relatively) safe to assume that no bad actor will read and/or modify the e-mail on the way. I am not aware of any JavaScript alternative with a similar security record. I think we're derailing a bit though. My original comment was: You can’t do that (= secure encryption) in a browser. Locally and in a browser are, in real life, mostly different things and I assume you know that. GnuPG in webmail software without having used it locally first, which is what I was hinting at, just isn't secure. edit: Bed time, might continue this tomorrow after work if I'll find some Lemmy time... good night for now! permalink fedilink source parent hideshow 3 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (2 children) There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. I thought you meant like you had to use Javascript to marshal between the WASM module and the user interaction. What you really meant is that you're objecting to, basically, a load call. One line of Javascript code to load and run the WASM module. What possible security risk could that pose? And again, I've not heard an adequate explanation as to how locally-running JavaScript encryption code would be any less secure than, for example, running a Python script in the terminal. Locally and in a browser are, in real life, mostly different things and I assume you know that. I think you're basically admitting that you meant that verifiably secure encryption using a website is impossible (other than e.g. TLS), which I would agree with, but that's not what you wrote. Browser extensions are used all the time to handle all sorts of secure encryption in high risk scenarios, such as for password managers. That is a perfectly valid example of encryption within a browser - and it was the first one I mentioned. Please just admit you were wrong, or that you meant to say "website" rather than "browser". It's okay, trust me, people respect you more when you can admit that sort of thing, it makes you look strong and capable of taking criticism. permalink fedilink source parent hideshow 2 child comments replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago (1 child) I might, indeed, have miscommunicated my assumptions. Thank you for pointing it out. permalink fedilink source parent hideshow 1 child comment replies: [–] bearboiblake@pawb.social 1 point 4 months ago No worries! Take care, and sleep well <3 permalink fedilink source parent
[–] bearboiblake@pawb.social 3 points 4 months ago (6 children) Create or download an implementation of your preferred encryption algorithm for Javascript (or use some WebAssembly alternative). e.g. https://github.com/ricmoo/aes-js Run the implementation on your local computer and open it in a browser. Hope this helps. permalink fedilink source parent hideshow 6 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago (5 children) You are aware that WASM requires JS, right? I mean, yes, running the application itself would be secure, but that's not in the browser. You cannot trust your browser. Ever. permalink fedilink source parent hideshow 5 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (4 children) You are aware that WASM requires JS, right? I think you're mistaken, there. WASM is often used alongside Javascript, but beyond the one-liner to fetch and load it, there's actually nothing which inherently requires JS beyond that. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? permalink fedilink source parent hideshow 4 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (last edited 4 months ago) (3 children) WASM is often used alongside Javascript, but there’s actually nothing which inherently requires it. There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? A web browser is the most vulnerable software on your computer. To stick with the one example I brought, namely GnuPG encrypted e-mails: Running GnuPG locally on my machine to encrypt/decrypt/verify an e-mail before pasting the result into (e.g.) my e-mail client is reasonably secure. GnuPG has been audited thoroughly enough, so it's (relatively) safe to assume that no bad actor will read and/or modify the e-mail on the way. I am not aware of any JavaScript alternative with a similar security record. I think we're derailing a bit though. My original comment was: You can’t do that (= secure encryption) in a browser. Locally and in a browser are, in real life, mostly different things and I assume you know that. GnuPG in webmail software without having used it locally first, which is what I was hinting at, just isn't secure. edit: Bed time, might continue this tomorrow after work if I'll find some Lemmy time... good night for now! permalink fedilink source parent hideshow 3 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (2 children) There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. I thought you meant like you had to use Javascript to marshal between the WASM module and the user interaction. What you really meant is that you're objecting to, basically, a load call. One line of Javascript code to load and run the WASM module. What possible security risk could that pose? And again, I've not heard an adequate explanation as to how locally-running JavaScript encryption code would be any less secure than, for example, running a Python script in the terminal. Locally and in a browser are, in real life, mostly different things and I assume you know that. I think you're basically admitting that you meant that verifiably secure encryption using a website is impossible (other than e.g. TLS), which I would agree with, but that's not what you wrote. Browser extensions are used all the time to handle all sorts of secure encryption in high risk scenarios, such as for password managers. That is a perfectly valid example of encryption within a browser - and it was the first one I mentioned. Please just admit you were wrong, or that you meant to say "website" rather than "browser". It's okay, trust me, people respect you more when you can admit that sort of thing, it makes you look strong and capable of taking criticism. permalink fedilink source parent hideshow 2 child comments replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago (1 child) I might, indeed, have miscommunicated my assumptions. Thank you for pointing it out. permalink fedilink source parent hideshow 1 child comment replies: [–] bearboiblake@pawb.social 1 point 4 months ago No worries! Take care, and sleep well <3 permalink fedilink source parent
[–] tux0r@snac.rosaelefanten.org -1 points 4 months ago (5 children) You are aware that WASM requires JS, right? I mean, yes, running the application itself would be secure, but that's not in the browser. You cannot trust your browser. Ever. permalink fedilink source parent hideshow 5 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (4 children) You are aware that WASM requires JS, right? I think you're mistaken, there. WASM is often used alongside Javascript, but beyond the one-liner to fetch and load it, there's actually nothing which inherently requires JS beyond that. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? permalink fedilink source parent hideshow 4 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (last edited 4 months ago) (3 children) WASM is often used alongside Javascript, but there’s actually nothing which inherently requires it. There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? A web browser is the most vulnerable software on your computer. To stick with the one example I brought, namely GnuPG encrypted e-mails: Running GnuPG locally on my machine to encrypt/decrypt/verify an e-mail before pasting the result into (e.g.) my e-mail client is reasonably secure. GnuPG has been audited thoroughly enough, so it's (relatively) safe to assume that no bad actor will read and/or modify the e-mail on the way. I am not aware of any JavaScript alternative with a similar security record. I think we're derailing a bit though. My original comment was: You can’t do that (= secure encryption) in a browser. Locally and in a browser are, in real life, mostly different things and I assume you know that. GnuPG in webmail software without having used it locally first, which is what I was hinting at, just isn't secure. edit: Bed time, might continue this tomorrow after work if I'll find some Lemmy time... good night for now! permalink fedilink source parent hideshow 3 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (2 children) There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. I thought you meant like you had to use Javascript to marshal between the WASM module and the user interaction. What you really meant is that you're objecting to, basically, a load call. One line of Javascript code to load and run the WASM module. What possible security risk could that pose? And again, I've not heard an adequate explanation as to how locally-running JavaScript encryption code would be any less secure than, for example, running a Python script in the terminal. Locally and in a browser are, in real life, mostly different things and I assume you know that. I think you're basically admitting that you meant that verifiably secure encryption using a website is impossible (other than e.g. TLS), which I would agree with, but that's not what you wrote. Browser extensions are used all the time to handle all sorts of secure encryption in high risk scenarios, such as for password managers. That is a perfectly valid example of encryption within a browser - and it was the first one I mentioned. Please just admit you were wrong, or that you meant to say "website" rather than "browser". It's okay, trust me, people respect you more when you can admit that sort of thing, it makes you look strong and capable of taking criticism. permalink fedilink source parent hideshow 2 child comments replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago (1 child) I might, indeed, have miscommunicated my assumptions. Thank you for pointing it out. permalink fedilink source parent hideshow 1 child comment replies: [–] bearboiblake@pawb.social 1 point 4 months ago No worries! Take care, and sleep well <3 permalink fedilink source parent
[–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (4 children) You are aware that WASM requires JS, right? I think you're mistaken, there. WASM is often used alongside Javascript, but beyond the one-liner to fetch and load it, there's actually nothing which inherently requires JS beyond that. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? permalink fedilink source parent hideshow 4 child comments replies: [–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (last edited 4 months ago) (3 children) WASM is often used alongside Javascript, but there’s actually nothing which inherently requires it. There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? A web browser is the most vulnerable software on your computer. To stick with the one example I brought, namely GnuPG encrypted e-mails: Running GnuPG locally on my machine to encrypt/decrypt/verify an e-mail before pasting the result into (e.g.) my e-mail client is reasonably secure. GnuPG has been audited thoroughly enough, so it's (relatively) safe to assume that no bad actor will read and/or modify the e-mail on the way. I am not aware of any JavaScript alternative with a similar security record. I think we're derailing a bit though. My original comment was: You can’t do that (= secure encryption) in a browser. Locally and in a browser are, in real life, mostly different things and I assume you know that. GnuPG in webmail software without having used it locally first, which is what I was hinting at, just isn't secure. edit: Bed time, might continue this tomorrow after work if I'll find some Lemmy time... good night for now! permalink fedilink source parent hideshow 3 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (2 children) There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. I thought you meant like you had to use Javascript to marshal between the WASM module and the user interaction. What you really meant is that you're objecting to, basically, a load call. One line of Javascript code to load and run the WASM module. What possible security risk could that pose? And again, I've not heard an adequate explanation as to how locally-running JavaScript encryption code would be any less secure than, for example, running a Python script in the terminal. Locally and in a browser are, in real life, mostly different things and I assume you know that. I think you're basically admitting that you meant that verifiably secure encryption using a website is impossible (other than e.g. TLS), which I would agree with, but that's not what you wrote. Browser extensions are used all the time to handle all sorts of secure encryption in high risk scenarios, such as for password managers. That is a perfectly valid example of encryption within a browser - and it was the first one I mentioned. Please just admit you were wrong, or that you meant to say "website" rather than "browser". It's okay, trust me, people respect you more when you can admit that sort of thing, it makes you look strong and capable of taking criticism. permalink fedilink source parent hideshow 2 child comments replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago (1 child) I might, indeed, have miscommunicated my assumptions. Thank you for pointing it out. permalink fedilink source parent hideshow 1 child comment replies: [–] bearboiblake@pawb.social 1 point 4 months ago No worries! Take care, and sleep well <3 permalink fedilink source parent
[–] tux0r@snac.rosaelefanten.org -1 points 4 months ago* (last edited 4 months ago) (3 children) WASM is often used alongside Javascript, but there’s actually nothing which inherently requires it. There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. Can you explain why you feel that locally running Javascript is more insecure than using, say, locally running Python code, for encryption? A web browser is the most vulnerable software on your computer. To stick with the one example I brought, namely GnuPG encrypted e-mails: Running GnuPG locally on my machine to encrypt/decrypt/verify an e-mail before pasting the result into (e.g.) my e-mail client is reasonably secure. GnuPG has been audited thoroughly enough, so it's (relatively) safe to assume that no bad actor will read and/or modify the e-mail on the way. I am not aware of any JavaScript alternative with a similar security record. I think we're derailing a bit though. My original comment was: You can’t do that (= secure encryption) in a browser. Locally and in a browser are, in real life, mostly different things and I assume you know that. GnuPG in webmail software without having used it locally first, which is what I was hinting at, just isn't secure. edit: Bed time, might continue this tomorrow after work if I'll find some Lemmy time... good night for now! permalink fedilink source parent hideshow 3 child comments replies: [–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (2 children) There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. I thought you meant like you had to use Javascript to marshal between the WASM module and the user interaction. What you really meant is that you're objecting to, basically, a load call. One line of Javascript code to load and run the WASM module. What possible security risk could that pose? And again, I've not heard an adequate explanation as to how locally-running JavaScript encryption code would be any less secure than, for example, running a Python script in the terminal. Locally and in a browser are, in real life, mostly different things and I assume you know that. I think you're basically admitting that you meant that verifiably secure encryption using a website is impossible (other than e.g. TLS), which I would agree with, but that's not what you wrote. Browser extensions are used all the time to handle all sorts of secure encryption in high risk scenarios, such as for password managers. That is a perfectly valid example of encryption within a browser - and it was the first one I mentioned. Please just admit you were wrong, or that you meant to say "website" rather than "browser". It's okay, trust me, people respect you more when you can admit that sort of thing, it makes you look strong and capable of taking criticism. permalink fedilink source parent hideshow 2 child comments replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago (1 child) I might, indeed, have miscommunicated my assumptions. Thank you for pointing it out. permalink fedilink source parent hideshow 1 child comment replies: [–] bearboiblake@pawb.social 1 point 4 months ago No worries! Take care, and sleep well <3 permalink fedilink source parent
[–] bearboiblake@pawb.social 3 points 4 months ago* (last edited 4 months ago) (2 children) There is no established way to load WASM in your browser without JavaScript code that does it for you, so there actually is. I thought you meant like you had to use Javascript to marshal between the WASM module and the user interaction. What you really meant is that you're objecting to, basically, a load call. One line of Javascript code to load and run the WASM module. What possible security risk could that pose? And again, I've not heard an adequate explanation as to how locally-running JavaScript encryption code would be any less secure than, for example, running a Python script in the terminal. Locally and in a browser are, in real life, mostly different things and I assume you know that. I think you're basically admitting that you meant that verifiably secure encryption using a website is impossible (other than e.g. TLS), which I would agree with, but that's not what you wrote. Browser extensions are used all the time to handle all sorts of secure encryption in high risk scenarios, such as for password managers. That is a perfectly valid example of encryption within a browser - and it was the first one I mentioned. Please just admit you were wrong, or that you meant to say "website" rather than "browser". It's okay, trust me, people respect you more when you can admit that sort of thing, it makes you look strong and capable of taking criticism. permalink fedilink source parent hideshow 2 child comments replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago (1 child) I might, indeed, have miscommunicated my assumptions. Thank you for pointing it out. permalink fedilink source parent hideshow 1 child comment replies: [–] bearboiblake@pawb.social 1 point 4 months ago No worries! Take care, and sleep well <3 permalink fedilink source parent
[–] tux0r@snac.rosaelefanten.org 1 point 4 months ago (1 child) I might, indeed, have miscommunicated my assumptions. Thank you for pointing it out. permalink fedilink source parent hideshow 1 child comment replies: [–] bearboiblake@pawb.social 1 point 4 months ago No worries! Take care, and sleep well <3 permalink fedilink source parent
[–] bearboiblake@pawb.social 1 point 4 months ago No worries! Take care, and sleep well <3 permalink fedilink source parent
[+] marxismtomorrow@lemmy.today 1 point 4 months ago (1 child) [deleted] permalink fedilink source parent hideshow 1 child comment replies: [–] tux0r@snac.rosaelefanten.org 1 point 4 months ago That's a very loose definition indeed. "Close enough to a browser" isn't a browser. GnuPG in a browser just won't work and most other encryption facilities aren't quite as secure (and transparent). permalink fedilink source parent
[–] tux0r@snac.rosaelefanten.org 1 point 4 months ago That's a very loose definition indeed. "Close enough to a browser" isn't a browser. GnuPG in a browser just won't work and most other encryption facilities aren't quite as secure (and transparent). permalink fedilink source parent