281–290 of 315 posts
How does this policy interact with greasemonkey, an extension that allows running random JavaScript on sites with access to the extension API. You could write your malware as a greasemonkey extension, convince a user to install a signed greasemonkey release, and then convince them to install your malicious extension.
Earlier quoted context omitted.
The PDF viewer is rather important if only for security.
I disagree. Having no PDF viewer is more secure than having a PDF viewer. I'd have no problem with Mozilla releasing a separate PDF viewer, either as an extension, a standalone application or even a Web site. I also have no problem with Mozilla setting Firefox's default PDF application as a stub which downloads their separate viewer. But it shouldn't be built in to Firefox. In any case, it is not the job of a Web bro…
No, because that means you still do have a PDF viewer, but it's whichever the user has installed, most likely Acrobat, which is vulnerability-ridden.
> But it shouldn't be built in to Firefox.
Why shouldn't it? Browsers aren't limited to HTML. They also support plaintext, SVG, many image formats, XML, and so on. What's wrong with supporting PDF?
Epic fail. Mozilla should be making the browser subsystems more secure, not saying 'Trust us, we'll ensure your add-ons are secure'. Will the add-ons source code be reviewed by a CISSP skilled in the languages used within the add-on? Will the add-on be tested with the top 1000 add-on combinations out there? If the add-on provides an API, will it be tested using fuzzing? The list of these questions, and the others to…
The law allows people to make mistakes. You clearly have no idea what you are talking about.
You're right about law, I know little - I am not a lawyer.
I suspect there will be someone who blames their corporate data breach on Mozilla's policy, if they can make even the flimsiest case. Mozilla might win, at the cost of money, time, and bad PR. I suspect it more likely that they'd settle out of court. I'd love to hear a lawyer weigh in.
I also love how I posted on here (I seldom do) about an issue I felt passionately about, in an area that I do know a bit about, and you responded with a personal attack.
Ask yourself this, what is it you hate so much about the world, yourself, me, or my post that compelled you to personally attack a complete stranger who was donating time and thought to the discussion? Did it make you feel better? Stronger? Isn't that the very behavior you've campaigned against, elsewhere on the web?
Earlier quoted context omitted.
I'm not jaded, and as to whether I'm obtuse, I have to let the other commenters judge. I agree that, yes, in theory , you legally have that freedom. But if Mozilla thought users were practically able to exercise that freedom, there would be no way for them to impose a change like this; all the users would switch to a fork. In practice, maintaining a fork of a major active software project is a huge amount of work and…
I apologize for the disparagement; I was miffed at your statement that "only US English speakers will be allowed to disable this requirement," which completely misrepresents the situation, followed by doubt about Firefox's status as F/OSS. Instead of ascribing that to malice, I should have assumed good intent and that the communications from our end were unclear. As to the English issue, we have absolutely no intent…
I have been using localized builds from https://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-c... for several years - are they not part of the Nightly builds?
Earlier quoted context omitted.
I'm not jaded, and as to whether I'm obtuse, I have to let the other commenters judge. I agree that, yes, in theory , you legally have that freedom. But if Mozilla thought users were practically able to exercise that freedom, there would be no way for them to impose a change like this; all the users would switch to a fork. In practice, maintaining a fork of a major active software project is a huge amount of work and…
I apologize for the disparagement; I was miffed at your statement that "only US English speakers will be allowed to disable this requirement," which completely misrepresents the situation, followed by doubt about Firefox's status as F/OSS. Instead of ascribing that to malice, I should have assumed good intent and that the communications from our end were unclear. As to the English issue, we have absolutely no intent…
Said parallel is imperfect. With APT, you can add custom signatures (say, if you run a private or organization-specific repo). AFAICT, Firefox offers no such capability.
Earlier quoted context omitted.
I'm not jaded, and as to whether I'm obtuse, I have to let the other commenters judge. I agree that, yes, in theory , you legally have that freedom. But if Mozilla thought users were practically able to exercise that freedom, there would be no way for them to impose a change like this; all the users would switch to a fork. In practice, maintaining a fork of a major active software project is a huge amount of work and…
I apologize for the disparagement; I was miffed at your statement that "only US English speakers will be allowed to disable this requirement," which completely misrepresents the situation, followed by doubt about Firefox's status as F/OSS. Instead of ascribing that to malice, I should have assumed good intent and that the communications from our end were unclear. As to the English issue, we have absolutely no intent…
I would have no problem with signature verification if, as with apt, users can decide which keys to trust. (And you don't have to download a whole new copy of apt to do it!) But the intent of this announcement seems to be that Mozilla will prevent users from doing that, on the theory that they will make bad choices. Well, some of them will!
But it's far more dangerous to take those choices away from them — that guarantees that they're trusting the wrong company.
Earlier quoted context omitted.
What is the rationale behind removing the configuration switch, though? Is there supposed to be some contingent of users who are not sufficiently tech-savvy to be trusted with choosing their own add-ons, but sufficiently tech-savvy to go and edit something in about:config, which really needs to be protected from their own stupidity? This sort of "mother knows best" approach is something I would expect from Apple, not…
Chrome tried that "configuration switch" before, and what happened was malware would find and flip that switch as one of the first things it did once installed. Then it would work like it used to (installing bullshit extensions, wrecking the browser overall, and being damn near impossible to remove)
In other words, if malware can open up the configuration of a separate program and alter it, then malicious browser addons are probably the least of your worries.
It's the "no override" part that concerns me. I created and maintain an extension that is used by visually-impaired people around the world (it has been translated by volunteers into Dutch and Chinese, for example). Occasionally a Firefox update breaks this extension. OK, fine, that's the cost of doing business. Of course, the automated compatibility report that Firefox creates is utterly useless; it almost never cat…
Hi, Mozilla developer here, speaking for only myself. I'm not sure why we don't make this clearer on the wiki page, but I think the reason there's no override is that any malware installation routine would simply activate it and continue on its merry way. (Disclaimer: I didn't work on this feature and am going by recollection and my own logic.) We see many copies of Firefox infested with rogue add-ons the user didn't…
And what's stopping said malware installation routine from patching my firefox.exe or /usr/bin/firefox or whatever to bypass the signature check? Or patching the running program in-memory? How would it even access that checkbox? This concern seems a bit far-fetched to me.
Earlier quoted context omitted.
See https://news.ycombinator.com/item?id=9558745 (and actually the rest of that submission also) Now, mind you, that was nearly 3 months ago. But the concerns there are still very relevant.
Those 3 months can make a world of difference. I'd like to see it in action before I decide whether it is a good or a bad thing. Also, I'd be very surprised if the numbers in this little test are more than anecdotal. Performance will depend heavily on the kind of content you're viewing and I'd wager that the IPC calls make up a very small minority of the runtime profile for a tab process. Also, not everything is so p…
Considering that a frame at 60fps is ~16.7ms, YES. That's 42% of your total frame budget!
And it's not just IPC calls, either. There are many things that are less efficient when you segment things between multiple processes.
Also, you're completely ignoring / missing the point of memory use. FF (or rather, Pale Moon) is currently using >1/4 of the RAM on my laptop. And swap is (really really really really really) slow.
Earlier quoted context omitted.
It's been a few months already, and Mozilla is still 'undecided' on what will happen to Enterprise add-ons. The only two options you are giving us are: 1) Either remain on 'ESR' branch, which is always outdated, OR, 2) Reveal private Enterprise source code to you to get it signed (it might even be illegal for employees to do that). Both of them could be unacceptable to many organizations.
There will also be automated, unbranded builds of Firefox Stable that allow you to disable the signing requirement, but are otherwise bit identical.
There is no way of doing this that both respects users freedoms and prevents malicious software.