that's the whole point I'm trying to make! goddamit stop working on assumption and hypothetical thinking I'm a lunatic, this is a real issue and the actual way firefox works, how do you think all password manager work?
> I can think of several ways to drastically improve the privacy of web extensions by providing audit logging or more fine-grained control over permissions.
You were talking about API surface though. Neither of these things are API surface in itself. They are after the fact, informing the user what it can do and what it did with those APIs.
> It's just pointless to have the most advanced content blocking mechanisms when you allow browser extensions to circumvent them all.
I don't think so. It's not pointless. It just means you need to trust more than mozilla, you ALSO need to trust the extensions, just like you need to trust many other things in your system. The error here is assuming that everything should be reducible or can be reduced to a single source of trust.
> There are countless studies that show most non-expert users don't know what is happening with their data and are not able to judge the risks they're taking when installing software like browser extensions.
Perhaps. But if you follow that argument then you end up with a locked-down system with little flexibility, which I was referring to as apple-style walled garden. Some people may value such a thing, but I wouldn't use or recommend firefox if it became something like that. I would flee in terror.
> I really wish Firefox would make the UI more stable and make user chrome mods some kind of plugin system where I can pick and choose how to deeply customize the interface.
Firefox extensions before Mozilla decided to kill XUL had the capability to radically alter the UI. This is what made FF extensions so powerful.
There were arguably good reasons for them to remove XUL[1], but it created a void of functionality that previously existed. I still think that a more secure version of XUL could offer a better user experience, but unfortunately we're forced to settle on the severely limited WebExtensions standard nobody is happy with except browser developers.
> Besides — if your private extension isn't malware, why not just upload it
Because it's private. Because I don't want to register and
maintain a Mozilla account. Because I can't trust my current
network environment. Because I just don't want to deal with that
code-signing shit[1]. Why should I even need an internet connection
in order to run my own scripts in my browser.
Assuming private means malware or illegality isn't very creative.
[1]: I specifically listed the Windows version of Firefox because
generally I have no problem with that procedure at all. But on
Windows they even removed the about:config-flag to disable it.
That's very rude.
But more importantly understand that this probably isn't for everybody. I think it's a fair guess to say they just want a small population, not something in the millions.
> However, moderation is all this gains, because anyone who is preinstalling Firefox on a computer could still install a modified executable instead.
Well, apparently that is a line that vendors are not prepared to cross.
> There is also a known risk of the user's security or privacy being compromised by visiting malicious websites that exploit weaknesses or vulnerabilities in Firefox.
When it comes to actual weaknesses or vulnerabilities, it seems clear to me that Mozilla should not rely on add-ons for patching those. But yes, blocker extensions still provide value; luckily, they are also still allowed.
> as I and others have explained, there are tried and tested ways they could do so that are no more vulnerable than the current approach yet would not suddenly remove all protection offered by addons against the latter threat without warning in the middle of a browsing session. The current heavy-handed approach is like building a secure home by making a concrete bunker with no doors and windows: the efforts to secure the addon system ultimately rendered the entire system useless.
You've said this before, so to prevent getting into a loop, I won't repeat my response :)
> Worse than that, though, the current strategy violates the basic principles that attract some users to Firefox in the first place, specifically its extensibility through addons and its relative respect for users' privacy and control of their own systems.
This I understand, and I wish it wasn't necessary too. I do think Mozilla has not shown little understanding - they've repeatedly explained how they are caught between a rock and hard place, and reached a different conclusion than you did, after weighing the pros and cons. That does not mean a lack of understanding of the cons, but merely that they did not outweigh the cons of the alternatives in their view.
This might simply be the result of different valuations of the pros and cons between you and Mozilla; given the amount of data and insight Mozilla has on the use of Firefox, I would also suggest to be open to the idea that there might be a lack of understanding on our side about the scale of the problem of malicious extensions.
For real. I understand the security argument, but that poster and Mozilla in general seem to be making the argument that "no, you're wrong, you don't know what you want, we're going to tell you what you want, and it's a less feature-rich Firefox."
Well, I use Firefox, and I evangelize Firefox to everyone I know, on the basis, essentially of the extensions, and most of the popular Firefox extensions would have never come into existence with the new extension model. Mozilla is developing APIs to grandfather some of them in, but they're still reducing the possibility space from "anything" to "what we expose through these APIs", so new extensions that change everything will no longer come into being.
And aside from that, they don't even cover everything; I've already been notified by the developers of two extensions I use that they either can't or won't be switching over.
I really do have to agree with the people who are saying Mozilla has totally lost the plot. I've disabled automatic updates until I can figure out what I'm going to do.
> the better approach would obviously be to work with FF developers to add the extra extension APIs they need; I can only assume they took that path but got rejected. If you're a Firefox user, ie someone who inherently places their trust in the security and privacy decisions of Mozilla, that's probably a red flag.
Hi, I'm an engineer at Mozilla working on the address bar of Firefox. We recently released a rewrite of the address bar with the explicit goal of making it easier to extend and experiment with the address bar: https://bugzilla.mozilla.org/show_bug.cgi?id=quantumbar
> I doubt firefox will ever focus on security. The security mechanisms we are talking about require breaking compatibility or performance. This isn't the stuff one rearranges deck chairs for.
This is just wrong. For example, major changes have been made to the internal architecture over the last couple of years to support process-per-site "site isolation". See https://bug1523072.bmoattachments.org/attachment.cgi?id=9061... for the new architecture.
It's true that Firefox is still behind Chrome in this area, but there is a lot of effort going into it.
> On the other hand, it does make sense. It's a tricky one.
All attempts by Mozilla to bake-in addon-like behavior so we don't have to install 'yet another damn addon' is welcoming, but as with any of these features, they come with caveats already present in the addons.
For example, Firefox's HTTPS-Only mode (that is basically the HTTPS-Everywhere addon) breaks some sites, and also their anti-tracking feature will break some sites too. But then again: if a site is serving HTTP only then they're doing it wrong (with the exception of captive portals). As for the anti-tracking feature: I rarely see sites asking me to disable my AD-Blocker, and when I do I never give-in, no matter how desperate I am to see hidden content.
It's developed by Mozilla, Google's controlled opposition. I submitted a link[0] on ads coming to Firefox but HN shadowed it almost immediately (present on /newest when logged in, nowhere to be found when logged out).
>But I admit, that also makes firefox hostile to corporate environments. If only firefox obeyed windows system/gpo/registry settings like chrome. I have never seen a non-tech company even permit firefox in their IT policy for these and other reasons anyways.
Perhaps I'm missing your point, but Firefox does (and I use it in my own AD forest) provide Group Policy[0] management support.
>Which is silly, IMO. What did this addon actually do, besides be installed without user consent?
1) Demonstrated that Mozilla has the ability to silently push addons without any kind of notification to the user that their browser behavior has been patched.
2) Demonstrated (allegedly) that there are privacy and security related preferences in Firefox that are reverting themselves to less-safe defaults without user interaction, aka Microsoft preferences.
3) Demonstrated Mozilla's marketing department lacks the good sense to respect these capabilities for the loaded gun they are
It's not about what they did, it's about what they could do. Mozilla doesn't need these tools, and these tools are dangerous. Why did they make them? Why shouldn't we ask Mozilla to remove them?
>The reason the login form is delivered as web content is to increase development speed and agility
You saved some sprints but invalidated the purpose of the project. Very agile.
>Ultimately I think we can have web content from accounts.firefox.com be just as trustworthy as, say, a Mozilla-developed addon which might ship in the browser by default, which is a pretty high bar. We're not there yet, but it seems worth pursuing to try to get the best of both worlds.
The safety of the default installation is crowdsourced across all users and can't be targeted. The safety of the JS I load from Mozilla is not and I would have to verify its safety every time. Unless I'm misunderstanding something it can never be as trustworthy.
> So, the best solution is to disallow other sources by default
No, it's not. It's the best solution you can come up with at the time, and one that likely presents the least amount of effort. Doesn't mean it's not a piss-poor solution. It also doesn't mean it's not going to cause additional problems.
Now if we want to distribute a plugin, we effectively have to bow to the whim of Google. And when I read stories like this: http://news.ycombinator.com/item?id=4092080, I'm not comforted.
> I'm also surprised Firefox hasn't proposed something similar
Maybe because this isn't the only solution?
Let me put this in simple terms: this is the easy way out. The simple way out. This is the low hanging fruit. It's a solution that is, in effect, the worst possible solution. It's the lazy solution. If you can't admit to that much, you're blind.
Preface: I am not a Mozilla employee -- I'm a volunteer and don't speak for Mozilla. I also haven't ever written a Firefox addon, though I have contributed to Firefox in the past and roughly understand how addons work.
> I'm not sure how credible random tweets are, but just as a light example, I got someone (from mozilla security) to admit it's a mistake
Yeah, dveditz is calling it a mistake (and I have great respect for his opinions -- he's very frank about them and is very thorough when it comes to security matters). I believe he is calling the original design of addons (years ago) to be the mistake, though.
I personally wouldn't call it a mistake though. Not exactly. There are many options, and each would cause significant backlash. The blog post talks of the sandboxing that Chrome and Safari provide; but Chrome's extension API is very limited (I've used it). It's basically a userscript API with a small number of hooks.
A large chunk of Firefox's user base uses Firefox just because of the power of addons. There are many addons that would just not be possible in other browsers. Restricting the addon API would irreplacably break all these addons and many users would leave because their favorite addon just isn't possible anymore.
A proper permission based sandbox that exposes all the original features sounds easy, but isn't. The blog post seems to oversimplify things. The original API was to simply expose all the browser internals to the addons (with a bunch of extra utility methods). Creating a well-structured, sandboxed addon API with the same capabilities is a really, really hard problem. We can't just selectively expose functions -- browser internals were not designed to be secure in such usage, so we need to provide a whole new shim over the internals and take a lot of security things into consideration. This is a lot of work, and cannot be done in a reasonable timeframe. In the meantime, people are getting their browsers hijacked by rogue addons, which is much worse.
Same thing goes for transparency. You need a proper shim to get that, otherwise you need to turn on logging for the whole of the browser -- there's no way to tell if a request originated from a method call by a browser internal, or a method call by an addon (except for a direct request). There might not even always be a clear distinction!
The review experience could be improved; but Mozilla has limited resources and with reviewers mostly being volunteers, this is also very nontrivial.
Sideloading will always be possible unless addons are encrypted with the user's master password. Firefox's source code is public, so the format of the user data dir is public, so anyone can add stuff. Master password encryption for the full data dir is an interesting idea (it might already happen actually; never tried it), but I don't think it will fix the bulk of the problem which has to do with non-security-aware people getting their browsers filled with crap.
Making code signing optional -- It's a tossup here. I was quite annoyed when Chrome did that for their addons since it made it hard for me to share userscripts. But the sad thing is that people will just write instructions to flick that switch. I personally think that we should draw the line there, really[1] -- if we can't stop users from clicking through warningy warnings it's mostly a lost cause. Besides, attacks can always be through direct exe downloads in that case. I personally hope that Mozilla adds the option to bypass this in the future like Chrome did, but I don't think that's going to really solve the larger problem.
I think the best way to handle this would be to use signing as a stopgap measure, and slowly roll out a permission-based sandbox API that has limited functionality but doesn't need signing. It can start out with a Chrome-like API with the most commonly used features, and expand a bit into more APIs until eventually mostly everything is covered. I do believe that it was a mistake to not plan to do this, however note that this solution is still possible.
But overall I find it to be a case of "you can't please everyone" here.
> yes extension signing is great of course, just not when only Mozilla has the power to do so imo
FWIW the reviewers are volunteers, so it's not as closed a situation as it's made out to be. Still not perfect though.
> My comment is just that I hope that servo/browser.html doesn't make the same "mistake"
We don't plan to. No idea about browser.html, but Servo plans to have proper sandboxing and other things. See [2] for a library Patrick wrote to help for this (i nfact its use cases in Servo extend beyond plugin sandboxing). Plugins are on our mind, and sometimes come up during meetings/discussions, though we haven't done anything about them yet (no immediate plans either). Too many other priorities :)
Of course, servo plugins would be for stuff like Flash (ick) which need to interface with the browser engine itself. I'm not sure how browser.html plugins could pan out. It should be possible to provide a sandboxed API via the mozbrowser extensions, but I'm not sure.
> And funny that you mentioned servo-shell by glennw, I actually remembered that when writing my previous comment and had a tab open on it! See my screenshot, top left! :p
> That's just a huge gaping security hole
> If that is indeed how Firefox is designed
that's the whole point I'm trying to make! goddamit stop working on assumption and hypothetical thinking I'm a lunatic, this is a real issue and the actual way firefox works, how do you think all password manager work?
here look yourself https://support.mozilla.org/en-US/kb/permission-request-mess...
and guess what permission the language extension need?
https://addons.mozilla.org/en-US/firefox/addon/automatic-spe...
reply