Firefox is/was really lacking in WebRTC support for non-P2P use cases - bandwidth estimation support was sub-standard until recently, there is no support for simulcast (multiple video quality encodings) when using H.264, and no E2E encryption support (which is very new to the spec). There has been a lot of back and forth on the Firefox / Jitsi situation but it does seem that most of the time the ball has been sitting in Firefox's court.
The originating browser is responsible for encoding all the desired quality levels and sending them to the SFU to decide what to forward to the other participants - that is the difference between a SFU and a MCU, and why SFUs can scale. SVC-capable codecs are coming to WebRTC too, which makes this a lot more efficient for the browser to do.
Encryption keys are distributed out of band of the media, so it's the same as whatever the tradeoffs are for multi-party E2E-encrypted text chat there (I don't know what those are though!)
UK, more than 10 working days consecutively requires director approval according to the written policy, but I can't imagine it ever being denied or enforced (I have never had or heard of a holiday request being denied at all). We're not allowed to carry days over though, so people do not generally accrue large holiday allowances.
By that definition, analyzing compiled native code would be "un-obfuscating".
IMO, deobfuscation is a subset of reverse engineering - which at a push I would define as "taking a program from the form it is distributed into a preferred form for modification/understanding".
It is a shorthand method of casting to a boolean value - C didn't have a true bool type until "recently" (but did have the concept of truthiness, where true is `is not 0`), so many projects and libraries use `#define TRUE 1`, and #define FALSE 0` or some similar variant.
So rather than write `foo ? TRUE : FALSE` or being more explicit `(foo != 0) ? 1 : 0`, you can just do `!!foo`.
As the OP said, that is already in iOS - it is just that more and more captive portals are whitelisting the domains it hits to check for a captive portal.
> Scaling that up - if I'm not logged into Wikipedia, and simply searching and reading articles, why does that need to be served under HTTPS either?
Because a malicious MITM could modify the content you are reading (and thus affect your perception of a subject). A bit of misinformation here and there can go a long way.
