Announcement

Collapse
No announcement yet.

Firefox 83 Released With Warp'ed JavaScript, HTTPS-Only Mode Option

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by treba View Post
    The biggest features "unlocked" by Webrender ...
    None of which work on my HTPC (Intel), AFAICT: every time I've tried forcing it on there, it's been either buggy, or MUCH slower, or both. Maybe that's just a matter of how far from ready it was at the time, and WHY I had to force it on - but it's HW with VAAPI support, which it supposedly worked on even back when I FIRST tried forcing it (which is, yknow, WHY I did. :P). And the second time, after a later announcement noting bugfixes and better / wider support. And the third time, after a similar claim months later still. Every time, it's been broken, buggy, or just plain slower - and the HTPC is exactly the sort of machine it was intended for.

    So at that point, I just gave up on it as 95% hype and 5% actual real-world use cases. It'll be interesting to see what happens in 84/85/etc, but I'm long since past caring about it at this point. If it works, great. If not, also great, since it hasn't delivered for years already at this point and I've managed just fine without it.

    I'm not stupid enough to be trying to drive a 4K display on an Intel IGP potato, but it was worse even on 720p, so meh. For the small but apparently non-zero number of machines it does actually work on, great: I've been on Linux more than long enough to remember when fullscreen video that worked *at all* was a pipe dream, and the memory of browsers running Flash for it still makes my skin crawl, so any progress in that area is nice to hear about regardless of how small the success rate is, whether it ever benefits me personally or not.

    Comment


    • #12
      Originally posted by dev_null View Post
      Yes I’m aware of Let’s encrypt and use it. however it anyway stinks a little bit: if I have a load balancer: to which server I should install certbot ? ... okay Google at least suggests their own https certificate for the case, but it smells by ‘good’ companies again
      In our stuff, we have the load balancer (or another machine in front of it) handle HTTPS.

      Comment


      • #13
        Originally posted by dev_null View Post
        Yes I’m aware of Let’s encrypt and use it. however it anyway stinks a little bit: if I have a load balancer: to which server I should install certbot ?
        To the load balancer. (If you mean a pass-through load balancer, not a server director)

        Comment


        • #14
          Originally posted by dev_null View Post
          I cannot see anything bad with http, it specially was created in text in order to be readable an debuggable. Https requires certificates which only ‘good’ companies can issue, CPU power, complicates debugging and code writing. And it’s amazing where it matters like privacy or money but why to enforce it everywhere ??
          Getting a cert for HTTPS / TLS is very easy and often automated these days. LetsEncrypt does it for free, not sure what you're on about with "only good companies". You can issue your own too, but if your service is meant to be available to the public, only certs with a valid root CA cert in their systems trust stores will be accepted. That's intentional for security benefit, otherwise it'd be much easier to spoof identity/trust of a domain being from who they claim to be.

          It doesn't have notable CPU overhead anymore, that was addressed long ago, in fact HTTPS when paired with HTTP/2 (pretty much a given these days) is often more efficient than plain HTTP as multiple requests can all utilize the same connection instead of separate ones being initiated. The largest overhead of HTTPS would be in a handshake that is barely anything, then your likely using HW accel AES or an efficient software based cipher like ChaCha20-Poly1305.

          Complications with debugging network traffic in what way? If you are the dev, you can debug over HTTP still, or use HTTPS with an RSA key exchange instead of DHE/ECDHE, you'll have no problem observing the encrypted traffic then (you shouldn't use RSA key exchange for your users though). What complicating with code writing? Some web features only work with secure contexts, those require HTTPS. Are you referring to self-signed certificates and browsers flagging them as insecure when developing? That can be avoided, or you can setup a local dev certificate (checkout mkcert or smallstep, Caddy will also automate this all for you).

          It's not just about privacy (encryption), but trust. If you don't have a secure connection to the server, you don't know if you're really talking to the real server, it could be a phishing web server that responds to the domain request due to your DNS being compromised. Your credentials in a login/payment form can be presented on an HTTPS site but sent over HTTP request on submission, that's not immediately apparent to the user but could be sniffed, knowing HTTPS will always be used and notify you of any attempts otherwise is useful at avoiding that problem.

          Additionally, while a website that just provides some information might seem harmless. Depending on context, a passive attacker might observe what webpages you view, monitoring your activity across various HTTP sites could glean insights about you, that could be leveraged such as health conditions or interests that you might otherwise not reveal / discuss. Doesn't even have to be malicious intent, an employer might notice you've carelessly been using their network to look at job listings for a new role during your break time (or work hours), or perhaps you've been having some financial trouble recently and your internet activity indicates this to an employer (whom you're working for remotely at home but need to connect via their VPN and don't have split DNS setup, so they get all your DNS history as well regardless of HTTPS), they could potentially leverage that to their advantage in certain situations to pressure or persuade you to their benefit.

          With HTTP, the content can be manipulated too in transit. If you were looking into political articles with an upcoming election, an ISP with a certain bias or motivation could notice particularly popular articles against their interests and modify them over HTTP to reduce their impact without raising too much suspicion, you'd be none the wiser. They can inject other content, be it tracking or ads (some airlines have done this when you connect to their free wifi).

          EDIT: Just realized someone already covered some of this with a link, I had recalled that information but couldn't seem to remember that very same link

          Comment


          • #15
            Originally posted by dev_null View Post
            Yes I’m aware of Let’s encrypt and use it. however it anyway stinks a little bit: if I have a load balancer: to which server I should install certbot ?
            Apple certs for apps btw is unrelated to HTTPS, but still the same intent of authentication to prove something is trustworthy (from who it claims to be).

            If you're using a load balancer, that would be the server that handles your HTTPS certs, if that's not something you control directly on your own server but via some service instead, then that service likely has HTTPS settings for you to configure.

            I've used nginx to serve web content, while also having another nginx instance as the reverse proxy that can handle load balancing, the latter one uses HTTPS for all my sites, while the web server instances can be handled over HTTP if not directly accessible to the public internet (eg all running on the same server machine or some VPN cluster). Caddy is also great at this and comes with HTTPS by default with LetsEncrypt all automated for you.

            What stinks about LetsEncrypt?

            Comment

            Working...
            X