201–210 of 315 posts
> [...] plugins don't need to be signed. So the worst kind of threat is still there. Great job, Mozilla!
yup, and that's what i don't get. statistically, plugins like java and flash are a bigger security threat than addons. i don't even remember an addon going rogue.
It should still possible to fork Firefox and remove this requirement, right ?
Mozilla has said that this requirement is set by one flag at build time, so building a version without this requirement should not be any more difficult than just compiling Firefox I have never done that, but I think it's slightly non-trivial. The hardest part though would be distributing the fork though, so a Linux distribution like Debian mentioned this change as others have mentioned would be one way to build a po…
[1]: https://git.exherbo.org/desktop.git/tree/packages/net-www/fi...
[2]: https://git.exherbo.org/desktop.git/tree/exlibs/mozilla.exli...
Earlier quoted context omitted.
Because bad guys can just keep getting new certs when their old ones are revoked, unless you do identity validation (which costs money as it requires actual humans, so the certs can't be cheap or free).
Reviewing plugins costs somewhere around the same amount of human time/money, no?
Earlier quoted context omitted.
> There can be a decent turnaround lag (sometimes on the order of a few days) Actually, the link says > Files submitted for signing will go through an automated review process. If they pass this review, they are automatically signed and sent back to the developer. This process should normally take seconds You may be thinking of a different type of review process, the signing one sounds almost instantaneous.
That's for non-public add-ons. If you submit a public add-on, even a minor update, it has to go through the AMO bureaucracy. I currently have an update that was uploaded on July 10, 2015, and is at queue position of 64 of 137. There are no code changes; it's just being updated because Mozilla changed their build system. This seems to be part of Mozilla's effort to be more like the Apple and Google stores. Mozila AMO…
It's little more than a year ago that Brendan Eich was ousted from Mozilla by an ugly orchestrated cabal. When I read Mitchell Baker's vapid blog post [1] on the decision, filled with polite backstabbing and politically correct buzzwordery I understood that Mozilla has been taken over by politicians and that its decline is just a matter of time. [1] https://blog.mozilla.org/blog/2014/04/03/brendan-eich-steps-...
He quit, he wasn't fired. If you have evidence to the contrary, please post it.
Earlier quoted context omitted.
I'm mixed on the general issue – an option to turn it off is an option which is certain to be used to social engineer millions of people – but this is somewhat different from HSTS: HSTS allows a site owner to set a security policy for access their own servers. There's no downside to using it, it doesn't affect anyone else, and in any case if you choose to use a service you're subject to their security policies. The f…
I really, really disagree. If your data is on my computer I should have a say in what happens to it. If I want to tunnel your hsts connection through a proxy I should be able to do so. You can't imagine how frustrated I was when I found out that I couldn't use my proxy any more, because some guy somewhere decided that it'd bee too hard to hard to add the following lines to firefox: if (user_doesn't_want_hsts) { dont_…
You need to read more about how HSTS actually works:
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
It does nothing that a site could not do by having their webserver redirect all HTTP requests to HTTPS with the exception that it prevents the browser to never make an insecure request to prevent a man-in-the-middle attacker from tampering with it.
Of particular interest, note that it does not prevent you from using a proxy if you choose to configure one. The only thing it prevents is a transparent proxy intercepting all traffic on the network, which is a class of MITM attack, and a frequent source of security or privacy issues.
If you need to use a tampering SSL proxy you would, of course, need to configure it to generate certificates using a CA which you trust, which is a well-documented feature and something which has already been a requirement for many, many years.
> As for your 'no downside', as I said, perhaps not for normal users. But I most definitively am not. And I probably need to jump though a lot of hoops to tear this "feature" out of my own firefox build.
Or learn how to configure your proxy so that it works with the security mechanism rather than unnecessarily exposing you to attacks. Your argument is a perfect example of why this is a good move: most people will simply hit whatever button causes the page to load without thinking through the security implications.
This is deeply disappointing. Two details: the extensions need to be signed by Mozilla , and only US English speakers will be allowed to disable this requirement. The point of free software is that users, individually and collectively, are free to modify it as they wish, without requiring approval from third parties. (And of course to use, copy, and redistribute.) This is a sharp turn away from the free-software etho…
> Two details: the extensions need to be signed by Mozilla, and only US English speakers will be allowed to disable this requirement.
This is not what is written there. The addons need to be signed by mozilla. The process is automated.
The unbranded version of Firefox is distributed with the English locale. You can install other language packs.
Firefox Stable and Beta can't disable the signing requirement. Firefox DevEdition, Nightly and Unbranded can.
This is disappointing. Everything is becoming centralized, even Firefox extensions. I wish there was an opt out like "unknown sources" in android, but they keep saying we're not smart enough to make or own decisions. They won't even put one in about:config. This change well undoubtedly upset developers and other techy folk, exactly the kind of people you want working with your software. Fdroid is working on third par…
Have you read the article? In the FAQ section they explain which versions of Firefox you can use if you don't want this requirement to occur.
Earlier quoted context omitted.
Did you not read the blog post? You can use the dev edition or the special release and beta version that don't have this limitation. Nobody is forcing you to live with this limitation. If this was done as an about:config flag it could easily be changed by an add-on too.
I did read the blog post. It says I have to use a less stable (beta) or less customizable (dev edition) version of Firefox to avoid this burden.
This is disappointing. Everything is becoming centralized, even Firefox extensions. I wish there was an opt out like "unknown sources" in android, but they keep saying we're not smart enough to make or own decisions. They won't even put one in about:config. This change well undoubtedly upset developers and other techy folk, exactly the kind of people you want working with your software. Fdroid is working on third par…
If you allow a tick box to disable this, then how do you stop the junkware authors from simply checking that box on behalf of the user? Because that's what would happen, the user would click "next" on some random installer (which the junkware authors argue grants them expressed permission to install), and the junkware will claim they tick the unknown sources box to fix a "backwards compatibility issue."
What they're trying to do is make the option to disable the check SO niche that it really isn't a valid option for the junkware authors to use anyway (since most consumers won't have it, only corp. networks which are a hard target for junkware for other reasons).