Bugzilla

> It is in our long-term interest to make it easy for developers to test Firefox release - the same browser that the aforementioned million users have.

I fully understand where you're coming from; I don't necessarily agree with you letting every user sit on a ticking time bomb in favor of making sure that "websites can test (release) Firefox in an automated way". There's an obvious elephant in the room here, though:
**Why don't you leverage your extension APIs to make this possible?** That way _only_ those that _need_ this functionality will have it when they install the extensions to suit their needs for testing -- and others won't have this inherent risk of an always-built and one switch/bug/configuration-mistake away from being enabled remote control tool to contend with.

Aside from that, I still think you're restricting your view on the potential for abuse here. As much as you want me to take into account the wildly different interpretations of "normal" operations, you're at the same time not willing to take into account the wildly different interpretations of a "default Firefox installation" which will be just as varied by definition. Try to look at this from a big picture perspective, not just "virgin OS with a newly installed clean Firefox on a new profile with no external configuration for the endpoint" as the scope boundaries for considering "flaws".

> As I understand it, you're using a forked, self-compiled version of Firefox and I believe Henrik will be able to give you a pointer where you can flip a compile-time define to disable this functionality. Which will hopefully satisfy your risk profile.

You don't understand my situation. I do not use a "self-compiled version of Firefox". I don't use Firefox at all. Any mozconfig build flag to disable webdriver will not apply to _my_ use case.
This bug was also not filed because of some self-serving perception that would directly affect my independent browser. It was filed because the basic idea of having full remote control features built into a web browser _by default_ is a massive red flag for anyone who has some idea about networking/computing security, and needed to be brought up. This is to make **your** browser safer to use for **your* users.
Maybe I shouldn't have bothered trying to do the right thing... :/

> It is in our long-term interest to make it easy for developers to test Firefox release - the same browser that the aforementioned million users have.

I fully understand where you're coming from; I don't necessarily agree with you letting every user sit on a ticking time bomb in favor of making sure that "websites can test (release) Firefox in an automated way". There's an obvious elephant in the room here, though:
**Why don't you leverage your extension APIs to make this possible?** That way _only_ those that _need_ this functionality will have it when they install the extensions to suit their needs for testing -- and others won't have this inherent risk of an always-built and one switch/bug/configuration-mistake away from being enabled remote control tool to contend with.

Aside from that, I still think you're restricting your view on the potential for abuse here. As much as you want me to take into account the wildly different interpretations of "normal" operations, you're at the same time not willing to take into account the wildly different interpretations of a "default Firefox installation" which will be just as varied by definition. Try to look at this from a big picture perspective, not just "virgin OS with a newly installed clean Firefox on a new profile with no external configuration for the endpoint" as the scope boundaries for considering "flaws".

> As I understand it, you're using a forked, self-compiled version of Firefox and I believe Henrik will be able to give you a pointer where you can flip a compile-time define to disable this functionality. Which will hopefully satisfy your risk profile.

You don't understand my situation. I do not use a "self-compiled version of Firefox". I don't use Firefox at all. Any mozconfig build flag to disable webdriver will not apply to _my_ use case.
This bug was also not filed because of some self-serving perception that would directly affect my independent browser. It was filed because the basic idea of having full remote control features built into a web browser _by default_ is a massive red flag for anyone who has some idea about networking/computing security, and needed to be brought up. This is to make **your** browser safer to use for **your** users.
Maybe I shouldn't have bothered trying to do the right thing... :/