5 ms·

Running in the browser is no more (or less) untrusted than running a dedicated terminal client.

by emilfihlman 5y ago

tyingq 5y ago
That a terminal in the browser can't make ssh connections without a separate http or websocket bridge complicates that. Depends on that bridge and who/how/where it's running.
rbanffy 5y ago
When was the last case when a malicious website or script could capture content or keystrokes directed at another tab? Really curious, because it seems an obvious attack vector.
- amalcon 5y ago
  2018 at the earliest: https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit... It's not a browser vulnerability per se, but it's still mitigated by having a separate address space.
- colejohnson66 5y ago
  At least in the last decade, I don’t think that’s even possible on the “big” browsers. There were vulnerabilities involving <iframe>s, but I don’t know enough about those.
noergl 5y ago
I tend to disagree. The fact, that a browser engine and JS is involved raises the bar significantly during security audits. It brings additional third-party players into the chain you have to trust. Meanwhile I suggest to read https://xtermjs.org/docs/guides/security/ https://xtermjs.org/docs/guides/security/.
intc 5y ago
Of course it is. In most cases you do not have any sort of guarantees regarding the browser (which it self usually is more complex piece of software than all your operating system and it's accessories calculated together - difficult to audit - known to collect metrics etc etc). In addition one can sandbox their local terminal pretty effectively - With Tomoyo or some other MAC technology. It's not so bad idea to actually isolate your browser too (with Mandatory Access Control) - It usually has no business for a global view on your filesystem or local network resources.

5 ms·

Running in the browser is no more (or less) untrusted than running a dedicated terminal client.

by emilfihlman 5y ago

Running in the browser is no more (or less) untrusted than running a dedicated terminal client.

tyingq 5y ago
That a terminal in the browser can't make ssh connections without a separate http or websocket bridge complicates that. Depends on that bridge and who/how/where it's running.
rbanffy 5y ago
When was the last case when a malicious website or script could capture content or keystrokes directed at another tab? Really curious, because it seems an obvious attack vector.
- amalcon 5y ago
  2018 at the earliest: https://en.wikipedia.org/wiki/Spectre_(security_vulnerability) https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit... It's not a browser vulnerability per se, but it's still mitigated by having a separate address space.
- colejohnson66 5y ago
  At least in the last decade, I don’t think that’s even possible on the “big” browsers. There were vulnerabilities involving <iframe>s, but I don’t know enough about those.
noergl 5y ago
I tend to disagree. The fact, that a browser engine and JS is involved raises the bar significantly during security audits. It brings additional third-party players into the chain you have to trust. Meanwhile I suggest to read https://xtermjs.org/docs/guides/security/ https://xtermjs.org/docs/guides/security/.
intc 5y ago
Of course it is. In most cases you do not have any sort of guarantees regarding the browser (which it self usually is more complex piece of software than all your operating system and it's accessories calculated together - difficult to audit - known to collect metrics etc etc). In addition one can sandbox their local terminal pretty effectively - With Tomoyo or some other MAC technology. It's not so bad idea to actually isolate your browser too (with Mandatory Access Control) - It usually has no business for a global view on your filesystem or local network resources.