1. 9
  1.  

  2. 5

    Don’t forget “Compile from source after force enabling ASLR”.

    1. 1

      How do you force enable it? I guess my gcc from Funtoo hardened takes care of this for me, but I’d like to know how to do it on other distributions.

      1. 1

        Use gcc from OpenBSD? :) Not something I have personally had to deal with.

    2. 4

      It seems that Firefox no longer lives up to its mission of putting users, not publishers, in charge.

      1. 5

        The vast majority of users just want to watch Netflix. A vocal minority is (rightly) opposed to EME. Mozilla was and still is too, but when it became evident that EME was going to go forward with or without Firefox, the choice was clear. Being stubborn and drawing a line in the sand meant alienating everyone who wants to watch Netflix on Firefox.

        I’d argue that supporting EME even though Mozilla didn’t want to, is a sign that we are putting users first.

        1. [Comment removed by author]

          1. 3

            Shame? Really? I don’t think Firefox is particularly at fault here. They’re in an ugly place where they just don’t have the leverage to do the right thing, and doing it anyway and losing all their users is almost certainly even worse.

            If you have to blame anyone, blame the US media industry. If anyone is responsible, they are.

            1. [Comment removed by author]

              1. 5

                Mozilla is not idealistic in the same sense that the FSF is. There are 10 values, one of which is:

                Commercial involvement in the development of the Internet brings many benefits; a balance between commercial profit and public benefit is critical.

                The alternative to supporting EME is losing users, losing influence and eventually dwindling to irrelevance. That is much worse for the open web.

                1. 5

                  FWIW, I have my issues with Firefox, but EME (or H264 before that) support is not one of them. I think users should have choices, and using nonfree extensions can be a choice.

                  Aren’t discussion threads fun when everyone wants something different, but assumes everybody wants exactly the same as they want? :)

                  1. 3

                    Also, I think I can coherently believe that EME is terrible, software patents would be cartoonish if they weren’t such an incredible drag on innovation and productivity, DRM is so anti-consumer that it ought to be illegal, and the addition of closed standards to the “open” web is a travesty—and still think that Firefox made the right decision to implement it. We don’t live in anything approaching a perfect world, and refusing to compromise on any of your principles will very shortly result in compromising on all of them.

                  2. [Comment removed by author]

                    1. 4

                      A vocal minority may be right or wrong, but if they’re a small fraction of users, they’re still a vocal minority. They don’t need to be ignored just because they’re a minority, but they don’t need to be heeded just because they’re vocal.

                      1. 3

                        First, we get no cash from EME. Second, the vast majority of internet users have never even heard of EME. Anyone who has an opinion on it one way or the other is part of the minority.

                  3. 1

                    I think the moral element comes from believing they are collaborators, and though @ahal describes it as involuntary that’s a fuzzy line to draw (if, indeed, one recognizes it at all).

              2. 3

                Care to explain how you cone to this conclusion from this list alone? Most of it turning off features that are web standards.

                1. 1

                  That something is a web standard says nothing about whether it benefits users or publishers. Who benefits from web sites accessing battery level?

                  1. 1

                    Users benefit. Apps that depend on those battery APIs were previously gated by the Google/Apple app stores. Now web apps depending on those APIs can be freely distributed without asking permission first.

                    Developers benefit. Many developers don’t want to develop 3+ versions of the same app, or use phonegap like software. Now they can just have a single mobile web app and install it everywhere.

                    p.s Yes I know Android can enable 3rd party sources. But it’s tucked away somewhere the average user won’t find.

                    1. 7

                      Oh really? If my battery is only 25%, the verge is going to stop showing me megabytes of ads? Or are they going to use the battery discharge rate as a permanent cookie to track me across sites?

                      1. 1

                        Yes, serving less on low battery is a very legit use case. But I do get your point that many WebAPIs make browser fingerprinting easier (though I’m not convinced discharge rate would be effective as that would be variable). It is a valid concern.

                        However I don’t find that argument terribly compelling. If “it could potentially be abused” was a reason to reject a new API, then the web would still be stuck in the 90s.

                        1. 3

                          So, for instance: http://www.wired.co.uk/news/archive/2015-08/04/privacy-hole-in-firefox

                          The alarming part of the standard is this:

                          “The information disclosed has minimal impact on privacy or fingerprinting, and therefore is exposed without permission grants.”

                          It’s not clear how much, if any, thought went into attacking this feature before making that statement.

                          I expect standards committees to make mistakes. Sometimes you don’t see things until you build them. But as a “security focused” vendor that is implementing them, I expect Firefox to notice and fix these mistakes before shipping. Unfortunately the attitude seems to be that if it’s a standard, it must be good, but that’s not true.

                          1. 2

                            My apologies, re-reading the thread I see I took the wrong meaning from your original comment. Your point was that just because something is a standard, doesn’t mean it is in the user’s best interest.

                            My point was that creating web standards for things that were previously restricted to native apps benefits users by circumventing gatekeepers. I believe you acknowledge that, but also point out that they can be used by publishers to abuse users. I’ll agree to that.

                            1. 4

                              I don’t know what these gatekeepers are. I’d rather run native software than poorly performing web junk with horribly inconsistent UI, constant privacy & security concerns, concern over stability with poor internet connections, and concern over the host (a gatekeeper?) going away or shutting me off.

                              If anything, the mountain of web standards has reduced my practical freedom w.r.t. web software (the client included) damn near to nothing. There’s too much of it, too much code for me to ever handle, and if I were to change things to my liking, then only I would be to blame when things break. Trying to exercise my freedom is like trying to reprogram a virtual machine emulator (like qemu) to make some operating system running in the said machine to one’s liking.

                              1. 1

                                That’s a valid point of view, but I’m not trying to start a web app vs native debate. The issue is two companies controlling what can and can’t get published is not great for innovation.

                          2. 1

                            Are there any examples? I’d imagine this only works where the website in question works for the user’s benefit, which is, almost never? If they would do that, they wouldn’t need the battery indicator to begin with.

                            If it would work users would just set the “always on 10% battery” toggle in about:config and enjoy a tracking free experience ;)

                            I guess a nice use case would be to send low quality video from YouTube when someone is running on battery (not just low battery), but not sure it would make much difference when using hardware decoding?

                2. 4

                  This list seems pretty misguided and under-informed, especially with things like disabling malware checks, completely unrelated properties like redirecting “View Source” to an external editor, disabling purely opt-in features like Sync, or disabling pure client-side features like Reader mode, crashed session restoration, caching, and download history. Take it with a grain of salt.

                  1. 2

                    Why is network.websocket.enabled = false used? Is there anything fundamental about WebSocket that harms browser privacy or is it used because of how common it is as a vector for info gathering re: analytics?

                    1. 4

                      I suspect this could be something along the lines of how WebRTC leaks real IP info even when used through a proxy (VPN, tor).

                      A cursory Google search doesn’t reveal the same issue as with WebRTC, and I know they’re different technologies, so that’s my best and rather unfounded guess :)

                    2. 1

                      Ahh it is a description of settings for Firefox to harden it. From the title I thought this was a change list for Firefox 46 and I got my hopes up about the added plugins :(
                      It would be nice if either the creator’s config file itself was in the repo or if a script to set/append to my own config was present.

                      1. 4

                        I made a PR to fix that, you can copy paste the prefs in user.js in your profile:

                        https://github.com/w00w/security/blob/78079d2c5d13300c1b0e7c6b448fdb211edecefa/firefox.md