Open Bug 341636 Opened 18 years ago Updated 2 years ago

Error page for port blocking should include ways to fix

Categories

(Core :: DOM: Navigation, enhancement)

Product:
Core
Component:
DOM: Navigation
Type:
enhancement

Tracking

()

People

(Reporter: mozilla, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: helpwanted)

Attachments

(4 obsolete files)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060406 Firefox/1.5.0.4 (Debian-1.5.dfsg+1.5.0.4-1) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060406 Firefox/1.5.0.4 (Debian-1.5.dfsg+1.5.0.4-1) RFC2616 says: 3.2.2 http URL The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax and semantics for http URLs. http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] If the port is empty or not given, port 80 is assumed. Yet accessing a legitimate RFC specified url: http://my_samba_server:601/ gives an error. I know why. There are idiots out there. Fine. However, I'm a big boy now and I don't need M$ IE style hand-holding. Firefox is used by grownups to operate all kinds of web enabled systems (development, sysadmin, testing...) that don't use port 80. Please implement and include instructions on overriding this in the help message. Eg: This address is restricted This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection. If you know what you are doing then go to Preferences->Advanced->Security and tick "Allow connections to non-standard ports" to enable this capability. Sorry for the inconvenience. I have read that for now the correct workaround is adding a new string value to about:config called network.security.ports.banned.override Then enter a comma-separated list of port numbers to allow. Sorry - that is not good enough to be a long term solution :) Reproducible: Always Steps to Reproduce: 1. Go to any http://server:601/ Actual Results: Firefox behaves like a Microsoft product and the overbearing hand holding gets in the way of correct behaviour: This address is restricted This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection. Expected Results: A web page delivered over a non-standard port.
example url: http://www.statcan.ca:8096/bsolc/francais/bsolc?catno=84-601-X WFM on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 ID:2006050817 It's debian's build specific, from http://ftp.ch.debian.org/debian/pool/main/f/firefox/firefox_1.5.dfsg+1.5.0.4-1.diff.gz: + * debian/README.Debian: Document that firefox doesn't allow connections + on certain ports. Thanks W. Borgert. (Closes: #362785) -> INVALID
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
This is the port blocking as specified at http://www.mozilla.org/projects/netlib/PortBanning.html
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
This is request to provide details on the error page for port blocking on how to unblock the port. At the least a link to the page detailing port blocking would seem sensible.
URL: http://www.mozilla.org/projects/netli...
Severity: major → enhancement
Status: UNCONFIRMED → NEW
Component: General → Embedding: Docshell
Ever confirmed: true
OS: Linux → All
Product: Firefox → Core
QA Contact: general → docshell
Hardware: PC → All
Summary: deniedPortAccess ("This address is restricted" error message) cannot be switched off → Error page for port blocking should include ways to fix
Version: unspecified → Trunk
(In reply to comment #3) > This is request to provide details on the error page for port blocking on how > to unblock the port. At the least a link to the page detailing port blocking > would seem sensible. All my apologies I wasn't aware of this feature. I should have found an URL on port 601 before doing anything.
Attached patch patch proposal (obsolete) — — Splinter Review
Here is a proposal. Will attach a screenshot of the result.
Attached image screenshot showing the result (obsolete) —
Well, I feel a bit stupid for using port 601 for SWAT when I meant 901 (especially when 901 is actually allowed). So big apologies for that :) Here's a patch to say: The requested address specified a port (e.g. mozilla.org:80 for port 80 on mozilla.org) normally used for purposes other than Web browsing. This has been used for security exploits in the past so the browser has cancelled the request for your protection and security. If you need to access this port then you can list the ports you need to access in the network.security.ports.banned option in about:config. See this page[http://www.mozilla.org/projects/netlib/PortBanning.html] for more details. (It also fixes a typo : 'canceled') --- netError.dtd 2006-06-15 18:04:48.538609432 +0100 +++ netError.dtd.new 2006-06-15 18:05:22.216663594 +0100 @@ -7,7 +7,7 @@ <!ENTITY connectionFailure.longDesc "<p>Though the site seems valid, the browser was unable to establish a connection.</p><ul><li>Could the site be temporarily unavailable? Try again later.</li><li>Are you unable to browse other sites? Check the computer's network connection.</li><li>Is your computer or network protected by a firewall or proxy? Incorrect settings can interfere with Web browsing.</li></ul>"> <!ENTITY deniedPortAccess.title "Port Restricted for Security Reasons"> -<!ENTITY deniedPortAccess.longDesc "<p>The requested address specified a port (e.g. <q>mozilla.org:80</q> for port 80 on mozilla.org) normally used for purposes <em>other</em> than Web browsing. The browser has canceled the request for your protection and security.</p>"> +<!ENTITY deniedPortAccess.longDesc "<p>The requested address specified a port (e.g. <q>mozilla.org:80</q> for port 80 on mozilla.org) normally used for purposes <em>other</em> than Web browsing. This has been used for security exploits in the past so the browser has cancelled the request for your protection and security.</p><p>If you need to access this port then you can list the ports you need to access in the <em>network.security.ports.banned</em> option in <a href='about:config'> <em>about:config</em></a>.</p><p>See <a href='http://www.mozilla.org/projects/netlib/PortBanning.html'>this page</a> for more details.</p>"> <!ENTITY dnsNotFound.title "Address Not Found"> <!ENTITY dnsNotFound.longDesc "<p>The browser could not find the host server for the provided address.</p><ul><li>Did you make a mistake when typing the domain? (e.g. <q><strong>ww</strong>.mozilla.org</q> instead of <q><strong>www</strong>.mozilla.org</q>)</li><li>Are you certain this domain address exists? Its registration may have expired.</li><li>Are you unable to browse other sites? Check your network connection and DNS server settings.</li><li>Is your computer or network protected by a firewall or proxy? Incorrect settings can interfere with Web browsing.</li></ul>">
Attached patch patch proposal (about:config) (obsolete) — — Splinter Review
hand edited version of Regis Caspar's patch
(In reply to comment #7) > Created an attachment (id=225713) [edit] > screenshot showing the result > When I originally wrote this I would have liked to see: Preferences->Advanced->Security have a tick box to "Allow connections to non-standard ports" to enable this capability. However that feature isn't in Preferences->Advanced->Security yet so the text should probably just refer to about:config until that feature is developed. I edited your patch to reflect this but I don't have a dev environment for firefox to provide a screenshot.
Comment on attachment 225712 [details] [diff] [review] patch proposal you can't reference specific UI elements in this file.
Attachment #225712 - Flags: review-
You can't refer to "Preferences->Advanced->Security" or "about:config" in this file -- those don't necessarily exist in all Gecko apps, and this code is part of Gecko. You _can_ change the firefox-specific netError.dtd or you can change the generic one in ways that are not firefox-specific. Or both, of course.
Attached patch patch proposal v2 (obsolete) — — Splinter Review
Updated version with no reference to product specific things: "Connection to specific ports can be enabled or blocked through the addition of preferences (see <a href='http://www.mozilla.org/projects/netlib/PortBanning.html'>Mozilla Port Blocking</a> for more information)."
Attachment #225712 - Attachment is obsolete: true
Attachment #225713 - Attachment is obsolete: true
Attachment #225722 - Attachment is obsolete: true
I'd really rather not get into the habit of putting links directly into these error messages. The message should be aimed at the user who just needs to know why they're not seeing content. If they want more details, there should be a way to get at them, but the proposed text is far too technical. We should really have a button on these pages that reads "Learn More" or "More ..." which either opens the help documentation for this error or links to some online help resource (that's totally mconnor's baby).
(In reply to comment #14) > I'd really rather not get into the habit of putting links directly into these > error messages. The message should be aimed at the user who just needs to know > why they're not seeing content. If they want more details, there should be a > way to get at them, but the proposed text is far too technical. OK > We should really have a button on these pages that reads "Learn More" or "More > ..." which either opens the help documentation for this error or links to some > online help resource (that's totally mconnor's baby). That sounds better for sure. Thanks :)
Comment on attachment 225733 [details] [diff] [review] patch proposal v2 see comment #14
Attachment #225733 - Attachment is obsolete: true
I totally agree with comment 0. Disallowing the browser to visit atypical ports doesn't protect the browser user. It merely restricts the usefulness of the browser. This is WAY too heavy handed. Let me put it another way: If mozilla clients are going to be this much of a "big brother" to the user, then they absolutely MUST NOT allow the user to override error in SSL certificates. The RISK to the user of overriding certificate errors is MUCH MUCH greater than any risk of letting the user access ports other than 80. I say: remove this port limitation. It just drives me to use other products. At the minimum, give me a pref to disable big brother.
I think we are planning to disable overriding most certificate errors...
> doesn't protect the browser user Correct. It's not designed to. It's designed to protect intranet servers from attacks by the browser. Or put another way, it's designed to prevent random web pages from tricking a used on the inside of a firewall into sending data to a random port of some other machine on the inside of the same firewall (port 25 comes to mind).
The error page says: "The requested address specified a port (e.g. mozilla.org:80 for port 80 on mozilla.org) normally used for purposes other than Web browsing. The browser has canceled the request for your protection and security." That's a lie. It's not for the user's protection and security. I need to turn this off right now, today. Any way for me to do it?
Of course. It's clearly documented in the page that the URL field of this bug links to.
The product is banning ports not listed on that page. It's also banning ports in the 99x range (e.g. IMAPS, SPOP). I don't want to have to specify all banned ports, one by one. I want to disable port banning alltogether. When users have troubles with certs on IMAP and SPOP servers, I frequently have them LOOK at the certs by using a URL such as https://pop.myisp.com:993/ Now that doesn't work. :(
> The product is banning ports not listed on that page. Looks like the page was not updated to reflect the fix for bug 301762. > I want to disable port banning alltogether. You can't. Feel free to propose an alternate security model that works.
An alternate security model that works is one that considers the source of the request, and chooses the policy based on the source. There's a big difference in URLs that come from the user, via the address bar, and URLs that come from web pages. You want to block web page authors from probing the intranet. You do NOT want to stop users themselves from doing so via the address bar.
> There's a big difference in URLs that come from the user Some would disagree, esp. given copy/paste. But yes, that would be a possible approach. Unfortunately, that requires source tracking, which requires no one writing code that loads URIs to ever screw up.... So it's a very fragile security model.
well that's not quite true. you could use the current code if you don't know the real origin as a safe default.
Every open must be closed. Every malloc must be freed. Yeah, programming requires exactitude. Source tracking is no different. Users should be able to copy-n-paste URLs. When the user directly initiates the action, with his own hand (as it were), we should not deny it on the basis that "if an automaton was doing what you're trying to do, it would be bad." Block automatons on that basis, not users.
> When the user directly initiates the action, with his own hand (as it were) Actually, we have no way to tell that this is the case in many cases. This is especially true for URIs passed to our app on the command line.
I ran into this problem today, and boy, I was surprised yet again to see Firefox deciding to hold my hand and protect me from myself even when I knew better. The browser that presents itelf as the one giving users a choice spends an awful lot of time removing choice from users. In any case, if this blocking stuff can't be disabled, then how about a warning page that can be clicked through to the requested page? Would that be an acceptable solution?
Why not perform some kind of sanity checking on the server to determine whether it really speaks HTTP? If the server gives a reasonable response to, say, a "HEAD / HTTP/1.1" (or for that matter, gives a HTTP-looking error for something like "GOOBER foo HTTP/1.0"), then it is almost certainly not a mail or news server. Performing an extra request like this seems much less obtrusive than yelling at the user when the target is in fact an httpd and it can be easily identified as such. (This check may fail for pre-HTTP 1.0 servers, or ones with an incomplete or buggy implementation/error handling, but should be a lot better than nothing.) On an unrelated note, it would make more sense to allow the user to specify allowable server:port tuples rather than just unblacklisting ports entirely; just because they use one web server on port 25 doesn't mean that they should have to open themselves up to exploitation from this. This could be similar to the handling of pop-up blocking, for example. Of course, this wouldn't be nearly as necessary with some kind of sanity check implemented, as per above.
I wrote a huge rant on how insane I think this "feature" is, but realised it would just make me look like a nut (and stupid, if I was missing something), so... can someone please point out the list traffic or whatever discussion it was that made this snake-oil look like a good idea? 'Cause I just ain't seeing it. Firefox cannot protect poorly setup intranets, and shouldn't try to. This only reduces Firefox's utility as a tool. Where's the argument otherwise? I would like to see the port-blocking removed entirely or at the least, to have a "discoverable" check-box somewhere for turning it off (eg, in connection settings, security or whatever). Oh, and for those wanting a decent workaround, the config setting accepts port ranges, so setting network.security.ports.banned.override to "1-65535" works a charm . :-) http://www.purple.dropbear.id.au/node/139
Port blocking in Firefox is an insanely bad idea. Several companies I have worked for internally use non standard ports for various web based services for many legitimate reasons. It's not feasible for companies to train their employees and consultants on how to configure Firefox to allow something that should just work by default. With this feature, I think the community will begin seeing users trade their more secure Firefox installations for less secure Internet Explorer which just works. Sacrificing ease of use for a minimal security advantage which has the potential to drive people away is not a good decision IMHO.
I agree with Erik R. Jensen. Firefox is used by advanced users and the only reason is that it is more flexible than IE. But if IE blocks something it at least allows to add site to Trusted Sites. In case of this "feature" of Firefox, you can bounce a head against wall if you are not lucky to find somewhere on internet this setting network.security.ports.banned.override to "1-65535". I had very unpleasant situation because of this "feature", I needed to test connection to port 563 running secure web service and it was in real-time, so because of Firefox I could not do this fast. OK, IE forever rescued me, but I am very angry on Firefox developers now!
What a stupid way to try and enforce security - i move our clients away from IE for a better browsing experience and everyone is happy. Then firefox pulls a boner like this and gives me a massive increase in workload just to sort out their over-zealouness to protect a problem that isnt even part of their remit. The developers obviously think all users of their software are totally stupid and have no idea what they are doing and cannot be trusted to make decisions themselves - this is a bug as far as i can see, and the only sensible solution would be to add a warning with a bypass button, or at least an option to turn it off in the settings. Funny, but isn't that what everyone else has been asking, but all i see is pig-headedness from the developers who dont seem interested to address this issue in any shape or form. Perhaps they will see sense one day, who knows, and maybe pigs will fly.
Just to clarify a few things: 1) It's not clear who's remit the problem would be in. There's no reasonable way for intranet services to really detect an attack of this sort. 2) Not all users are totally stupid. However, most users have a very vague idea of the security implications of their actions. I'm sure you know the pros and cons of allowing the web at large to talk to arbitrary ports of arbitrary machines on your intranet. But unless your clients are very atypical users, they probably don't know them. And don't want to, in fact. 3) A warning with a bypass button will just mean that users will click the bypass button in many cases. The best-case scenario, based on extensive studies of security UI over the last few years, is that about half will click the "allow" button, and half won't. The worst-case one is that they will all click the "allow" button. Depends on how much they think the UI is keeping them from the task they're focused on. 4) There is an existing setting to allow bypassing this restriction for people who _do_ know what theyre doing. 5) No one's claiming the current solution is perfect. Far from it. It's just that no one's come up with a better approach. See the "helpwanted" keyword on the bug. 6) I hate to say this, but "Patches accepted if you make this better."
Humble pie eaten and actually quite tasty - well put. I still dont agree that it should even be a "feature" of firefox at all. This is a security implication, that only affects companies/indiviudals who are running their own servers behind a firewall - and even then its only a small risk. My point is, that an up to date firewall with decent content vulnerability checking could pick this up and block it anyway at the perimeter, so why give me the headache of having to fix something that didnt need fixing for many hundreds of users over many different sites/companies that i have to support. Its the manageability side of things i have an issue with, now if there was an easy way i could push these changes to all these users then i wouldnt be complaining - but as it stands all i can say to them is if Firefox blocks you, then use IE...... i dont like to do it, but this is business and clients want an IMMEDIATE fix, time is money as always. They dont want any disruption, they dont want you having to go onto their machines and muck about with settings, and here comes the biggie......the typical client response "well why did you make us all use Firefox in the first place when it doesnt work properly, you've just wasted xxx hours of our time and xxx of our money." As for point 3 above, i have to say thats totally irrelevant - i couldnt give a monkeys whether half will click on it or half wont, this just comes down to the competence level of the individual, and thats what we are here to advise them to do. I think its safe to say that most of the people commenting on here are all corporate users, those same users you are trying to protect are the same ones you have up in arms over this - the vulnerability doesnt even affect the home user, who is also unlikely to want to use non-standard ports anyway. My only suggestion to all of this would be to have an area in the settings either hidden or not that could be centrally managed by an Administrator. Dont get me wrong, i appreciate all the hard work that goes into this project but i'm no programmer either so i cannot really contribute - all i can do is try and explain that an idea that sounds good in the development lab is not necessarily a good idea to implement in the real world, and i think more thought should have gone into the practical implications before creating a headache for everyone needlessly.
This madness had me back using IE7 for a while. I finally came to my senses, looked up the problem and turned the stupid thing off. I use all sorts of crazy ports, mostly for server and router admin where use of port 80 is impossible (and silly). I'm not going to embroil myself in the discussion; there are plenty of intelligent people here making intelligent suggestions. I just wanted to say that it needs to be either removed or made easily turn-offable, with information about how to do this in the message. The Try again button is just infuriating.
This "feature" just caught me too... I can understand why it's not a good idea to go into too much detail on the error page - it'll just cause confusion. However, I don't understand why it isn't possible to word a reference to "about:config" that includes something like "your browser may support..." and perhaps link to the Mozillazine FAQ page About:Config_Entries. May I also suggest that the "Firefox has cancelled the request for your protection" message is a little over-officious? Even if it was true (it's actually protecting servers that I may have access to from my stupidity, rather than protecting me) couldn't it be worded a little better? How about "Firefox has cancelled the request to prevent potential problems with the server"?
Gotta love it when FireFox gives every user a one-click override for bad certificate errors, which really can hurt users, but does not give the user any override for this "error" which never hurt any user.
You can't use insecure/bad UI in one place to justify insecure/bad UI in another. Especially since we're planning to fix the certificate thing in bug 327181.
Jesse, The bad cert dialogs protect the user from harm. The port banning feature does not protect the USER from harm. It potentially protects other servers on the user's network from harm. There is no harm TO THE USER if he chooses to visit a URL on any port. This port banning feature is NOT intended to stop A USER from visiting strange ports, but rather to protect a remote server from malicious scripts. Frankly, the feature should stop scripts, but not URLs typed by the user in the address bar, but our present browser design does not let us discern between the two. So, it makes good sense to let THE USER say to the browser, "I am not a script. You do not need to guard against me. Let me do as I please." Again, it is IRONIC that we allow the user to harm himself with trivial overrides to bad cert dialogs, (which admittedly has some chance of being fixed, although I do not consider that a foregone conclusion yet), but we stop the user cold from activities that WILL NOT HARM THE USER, and do not lessen THE USER's security.
I completely agree with Nelson's comment, though I don't think it goes far enough. It's not enough, I think, just to see if it's not a script calling for the access; the user should always be able to acknowledge Firefox's concerns and move forward anyway. To build on Nelson's comment, the feature is to protect against malicious scripts, but not all scripts accessing these ports are malicious. Sometimes there are good reasons to do it. Yes, these cases are rare, but they do exist. Frankly, this "nanny browser" mentality disgusts me, and some comments in bug 327181 just reinforce this feeling.
Chris, I'm in favor of taking appropriate strong measures to protect THE USER. But this "port banning" feature does not protect the user, and never has.
Why do you think that servers near the user, potential recipients of spam, and the reputation of the user's IP address do not deserve as much protection as the user's computer?
(In reply to comment #42) > Jesse, The bad cert dialogs protect the user from harm. > The port banning feature does not protect the USER from harm. I think being fired for executing an attack on one of the company servers (or even being prosecuted for it) is harm in my book. > Frankly, the feature should stop scripts, but not URLs typed > by the user in the address bar, but our present browser design does not > let us discern between the two. Actually, it does. But then you wouldn't be able to use links on the resulting page to other pages on the same port. The real solution (which we need anyway) is to disallow "external" servers from accessing "internal" ones. That will take arch work, though. > So, it makes good sense to let THE USER say to the browser, "I am not a > script. Yes, that's what this bug is about. And there are patches in it. So I really don't see what the deal with all the advocacy comments is, other than generating bugspam. Please stop, ok?
Boris, all the patches attached to this bug are obsolete and over a year old. Let's discuss "the right way" to fix this, which isn't advocacy. It seems to me that all actions undertaken by the browser can be divided into groups of: - actions directly initiated by the user (e.g. type URL into address bar, or clicked on an anchor-tag link) - actions initiated by a script (even if that script was initiated by the user, through an onclick() or other means). It seems we should protect the user from unintended actions (initiated by a script, without the user's knowledge and consent), but NOT from the actions the user intended to initiate. I have discussed this idea at times in the past, and have always gotten the message that this change of differentiating user-initiated actions from script-initiated actions would be a huge major architectural change to the browser. Do you think that is true? or not? It sounds like perhaps we already have a start on that, given that you said the browser can discern between user-typed URLs and others.
There is no difference between clicking on a link and a window.location load via an onclick handler. In both cases the user has no idea what they're loading. Basically, for URI loading purposes, anything that is not typed into the URL bar (or dragged to the browser from outside the browser, or loaded in the browser by some other application) is in the same bucket. You can see that in the way we apply security policies now (see CheckLoadURI calls). > It seems we should protect the user from unintended actions Agreed. That includes everything except loads from the URL bar. Is excepting just loads from the URL bar from port blocking (but enforcing it for all other loads) useful in terms of solving the problem this bug is about? My instinct is "no", but I could be wrong. > Do you think that is true? or not? It really depends on how you define "user-initiated". For popup blocking purposes, we can tell them apart easily, but we treat an onclick handler as being user-initiated (the user clicked, after all). Here we clearly need a different definition of user-initiated. The only one that makes sense to me in this context is the one I describe above.
Boris, what about bookmarks? Are they considered similar to typing into the URL bar? I think they should be. > Is excepting just loads from the URL bar from port blocking (but enforcing > it for all other loads) useful in terms of solving the problem this bug is > about? For my purposes, yes it would be. I can't speak for others to this issue.
Yes, bookmarks are equivalent to the URL bar. Basically, any time the URI to load doesn't come from inside a web page.
I'm another corporate user who would like to see this fixed. This bug is costing people money and driving users away. The fix is simple, you don't need to change the wording or filter the source of the URL, you can just remove the feature and let the browser work as expected.
There no any messages in case script was blocked by this rule. It's very bad, because of there is some good scripts, that simply not work in some installations, and it's very hard to troubleshoot this case. Any warning about dropped connection need if it occuret not for address-bar entered url, but by script.
At the very least, please remove the "Try Again" button from this error page. Its existence implies that, if the user waits long enough and clicks often enough, the circumstances which blocked access to that port might eventually change and he'll be let through.
See bug 318648 for removing the "Try Again" button when it is useless.
How do I vote for this bug? I don't see the button. This is terrible and needs to go away immediately. Trying to connect to CUPS and I'm getting some whining and unhelpfulness? Here is how it works: I type an address and you go there. End.
Blocks: 479922
The case for permitting Firefox on user desktops in a coporate environment generally revolves around it NOT randomly preventing users from getting their work done, which IE is prone to do. Requiring administrators to make an about:config change on EVERY firefox install in a large deployment, just so they can reach an in-house app, is criminal. This feature might be useful in some environments, but it has no business being a default setting. There should be an easily accessible preference setting to enable/disable it, and the default should be "disabled". That's just common sense (and accepted best practice) when adding a feature that breaks compatability.
I use firefox to get away from this kind of stupidity. The feature needs to be off by default. This kind of thing will make me start looking for a new favorite browser.
I now use Chrome to get away from this kind of stupidity :) Sorry for the bugspam; it's not like this is getting fixed anyway...
WTF IS WRONG WITH YOU ? ARE YOU **** RETARDED ??? GOD THIS IS THE STUPIDEST THING I HAVE EVER SEEN !!!! I REALLY CAN'T BELIEVE IT!!
Speaking as a computer scientist with many years of professional work behind me, two things stand out about this bug and much of the anger it has generated. 1. It is sad (impressive actually) that this problem was reported so long ago (4 years!) and is still not fixed. The developers priorities are not aligned properly for generating good user experiences. 2. The fundamental purpose of any GUI is to act as a GUIDE and both teach as well as lead a user to a good solution for a problem they are experiencing or goal they need to achieve. If the GUI is incapable of doing so, as is the case in this situation, then the GUI is broke. PERIOD. This specific bug has exposed a far more serious and fundamental design flaw behind the current architecture of Firefox. Hiding preference settings behind a hidden and internally undiscoverable command (for most users), such as "about:config" and then having further undiscoverable and unlearnable configuration parameters such as "network.security.ports.banned.override", is about as user unfriendly of a design as you could possibly make it. If is very arrogant of the designers to assume that they can second guess the needs of their users, and categorize these parameters so as to differentiate between simple and advance needs, then hide the advance ones. What is worse is that the purpose of many of these configuration parameters, and the models behind them, is also undiscoverable. Users wish to advance their knowledge on how to use any given tool, and if you do not provide a learn-able and discoverable path for them, you have failed to meet a critical requirement of good designs. That applies to this as well as all tools. This WHOLE area of Firefox is desperately in need of a redesign with a focus on better usability, discoverability, and intuitive models. There are lots of books around about user interface designs, generating use cases, object oriented models, etc., and I suggest the developers read a few.
Blocks: 85601
I just got bitten by this bug while wanting to test a certificate installation on an imaps server. However, the workaround (fortunately) is not quite as "undiscoverable" as many people think it is: indeed, just copy-paste the error message in google, and up pops the about:config setting. Other error message goofs are worse, such as the many where one error message is replaced by a different error message that is totally believable, but false, sending you into the wrong direction (see bug #637619)
Bit me today with a link to https on an exotic port. Thanks.
Huge source of an exotic ports is a development and test envirounnment, and lot of administration interfaces. Fact you not see it in your life not mean they not around.
it' not even present in about.config until you add it e.g. to C:\Users\me\AppData\Roaming\Mozilla\Firefox\Profiles\xyz.default\prefs.js as user_pref("network.security.ports.banned.override", "465"); I need it to have users control the certificate SHA256 for example of https://smtp.gmail.com:465/ if they can't do openssl s_client -connect smtp.gmail.com:465smtp.gmail.com:465 | openssl x509 -noout -fingerprint -sha256 It would really be great to have a "temporarily override for port xyz" button on the error page that has the same effect as the above user_pref() for the current session!
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: