Notices by Demi Marie Obenour (alwayscurious@infosec.exchange)

@whitequark Ah, that sounds like a job for a script or a premade VM that is ready to go.

@whitequark eepy?

@whitequark I’m a bit suprised you aren’t doing this in a VM.

@dalias I think such functionality should be available in most cases, unless redaction is required for some reason.

Whether it should be the default view I am less certain about. People do make embarrassing typos.

@nazokiyoubinbou @dalias 100% agree for stuff like infotainment firmware. For stuff that is safety critical there is an argument that the general public (and any passengers and subsequent owners) have the right to count on safety features not being defeated. I’m not sure where the line should be drawn there.

@dalias @lispi314 @theearthisapringle @swordgeek @hayley People want to run games. How should they do it? “Don’t do it” is not an answer.

If you limit the browser too much, people will just run desktop applications instead, and for stuff that isn’t fully trusted that is a security regression.

@dalias @lispi314 @theearthisapringle @swordgeek @hayley If you are wanting to get performance that is anything close to what the hardware can actually do, you aren’t doing most of the work on the CPU. You are dong it on the GPU, and that is a nightmare of its own security-wise. Oh, and I highly doubt you will ever able to run an interpreter there with performance that is remotely reasonable due to how the hardware works.

@dalias @lispi314 @theearthisapringle @swordgeek @hayley What kind of performance can one get from a type-1 only JIT? If one only compiles to a bytecode then performance is limited to that of an interpreter, and my understanding is that even threaded code is still quite a bit slower than native code (due to CPU branch predictor limitations I think?). On the other hand, compiling to a safe low-level IR (such as WebAssembly or a typed assembly language) and generating machine code from that could get great performance, but that requires trusting the assembler (which, while probably much simpler than a full JS engine, isn’t trivial either).

@hayley @dalias @theearthisapringle @swordgeek @lispi314 JS is a very badly designed language from a performance perspective: every property access is semantically a dictionary lookup, and the JS engine must do heroic optimizations to get rid of that lookup. It’s much easier to write a Scheme or Common Lisp compiler because record type accessors are strictly typed, so they will either access something with a known offset or raise a type error.

@lispi314 @dalias @theearthisapringle @swordgeek @hayley Yup! Duck typing is absolutely horrible from a performance perspective, unless compile-time monomorphization gets rid of it.

@dalias @lanodan @theearthisapringle @swordgeek Hard disagree on SSO, which (combined with SCIM) really is the right way to authenticate to things in an enterprise or government environment. For instance, many U.S. government websites use https://login.gov as the SSO provider, and that really is an improvement over them all managing authentication separately.

@dalias @swordgeek @theearthisapringle For web compat postMessage() still needs to work for PayPal, as does ??? for Google. Might make sense to just hard-code those services as special-cases for legacy reasons, though.

@dalias @swordgeek @theearthisapringle I think the HP Sure Click Secure Browser comes close to that. It’s sadly the only viable model with present browsing engines.

A partial solution is to use a mainstream browser (like up-to-date Chromium) for work that needs to be secure (like managing web hosting) and something else in a VM (ideally Tor) for general browsing.

@dalias @swordgeek @theearthisapringle that’s why you have different VMs for different websites 🙂.

@dalias @swordgeek @theearthisapringle In that case the safest option is to run the browser in a tightly sandboxed VM, so a browser exploit is not game over. That’s what Qubes OS does.

@dalias @swordgeek @theearthisapringle A lot of browser vulnerabilities are JS engine bugs, and those are much harder to mitigate unless one disables JS altogether.

@dalias @swordgeek @theearthisapringle The problem is the security patch gap. If one diverges too far from upstream then one risks not being able to release security patches in time.

@swordgeek @theearthisapringle @dalias I’d avoid downstream forks of browsers unless they have a record of pulling updates from upstream within days of upstream updates.

@dalias 5 requests per 10 seconds seems like something that a human could easily be hit by accident when looking through commit logs.

@dalias Are you thinking of specific functionality or just overall priorities?