Punishing the software developer when the server operator hasn't installed HTTPS
Seems that Mozilla intend to create a situation where all new features will only operate if the webserver the browser connects to is using an SSL/HTTPS connection.
The upshot is that on non-SSL servers, all new features of HTML or css added after the current Firefox release (57 as I write) are liable to malfunction. This could for example lead to the layout of a page being trashed through a css issue, with one paragraph overlying another or suchlike. Or, of video failing to play.
The reasoning behind this seems to be to force the use of SSL, which Mozilla seem to regard as vital for Web security. I've already gone into the issues behind this push-to-encrypt on another post, so need to repeat here.
I've expressed my doubts as to whether SSL deployed in this particular way is even effective as a security measure, nevertheless Mozilla have the right to declare that a product of theirs such as the Firefox browser may not be used without it. It is their product, and therefore their right make that restriction if they wish. (and if the public decide they don't want to use a browser with such a restriction, well then there are always alternatives..)
The software coder doesn't have that luxury of choice, though. Products need to work in all browsers.
If the browser were to shut down or display a warning on a non-SSL website, then at least the nature of the situation would be clear to the end user, namely that the browser has been designed to forbid this mode of use.
However, this is not what's involved here. Instead, if Firefox is used with an unencrypted connection, certain specific features of the webpage itself are liable to malfunction. It seems unlikely that the end user would be aware of why this is happening. Instead, it would seem that the HTML or other code of the website itself was faulty.
Where a lack of needed SSL arises, that omission lies with whoever is operating the webserver. It has nothing whatsoever to do with the software developer or the application code. The server operator is the only person who can rectify the situation.
Yet, from the way this is described, the malfunction the end user sees would appear to be the fault of the application developer, in writing bad code. Thus, the end user will likely conclude that the developer's work is junk, and reject it.
As I've pointed out in a bug report, this is a case of a misdirected punitive action. The application developer is being punished for an omission made by a webserver operator somewhere else in the world, and over whom he has no authority or control.
Furthermore, it is common practice to test Web software on inhouse servers. Since these servers are not public, there is no specific need for encryption, and indeed the operator may not have gone through the lengthy process of setting up SSL purely for inhouse use. In such a situation the evaluation of the software is likely to end in a failure and the product rejected at that point. Even if after successful evaluation, it would have been deployed on an SSL server.
This may lead to a loss of business and damage to the developer's reputation, all for no good reason.
I really think that Mozilla should have a careful reconsideration of this policy.
If they insist on implementing it, then the consequence will be the opposite of what they are aiming for. Developers such as myself will restrict ourselves to only using unaffected code. This will be necessitated, in order to ensure that our products do not malfunction on certain specific platforms. Which in practice will mean eschewing the use of any features added post Firefox 57.
Realistically, it will mandate that we do all testing on non-SSL webspace. That way, we shall be immediately be aware if we've used affected code, and can remove it immediately. The alternative, of developing in SSL mode and then testing in plain mode to ensure everything it still works, could leave us with too many gotchas and too much recoding to work around them. No thanks.