1432011 - Lack of SSL: Attacking the wrong guy?

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Ian Macdonald]

User Agent: Mozilla/5.0 (X11; Debian; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/57.0
Build ID: 20171016030418

Steps to reproduce:

Not yet implemented so cannot test. Detailed here: 

https://www.w3.org/TR/secure-contexts/

https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/


Actual results:

I read that in future, any new features, even down to new css formatting, will be disabled if SSL is not used. 

So, if a potential user of my open source code tests it on a non-SSL platform (which could be an inhouse server where no security issue arises anyway) then the impression the end user will get, is that my code is faulty. 

Divs might overlay other text, for example, if new css features malfunction. 

This would seem to case of punishing the creator of a product for the actions of a user of that product. Actions which the creator has no control over. 

If the features which are disabled have no need of SSL, then it could also be considered sabotage. 



Expected results:

If Mozilla regard use of Firefox to view non-SSL webpages a misuse of their product, then they are within their rights to deny that usage. This could be achieved by posting a warning message or closing the browser. 

However, creating a situation where code written by others will intentionally (and for no good reason) malfunction in that situation, is unethical and possibly illegal.

Comment 1

[Johann Hofmann [:johannh]]

Bugzilla is meant for reporting bugs or feature requests, not posting your opinion on Mozilla policies. Please take your concerns to the dev-platform or dev-security mailing lists, though I can ensure you we will not change our position on this.

Comment 2

[Jonathan Kingston [:jkt] he/him]

Looks like Johann beat me here to closing this. We already are limiting platform features to HTTPS only for example Service Workers. Also it is worth noting that we and other browser make "interventions" when pages don't behave well too with the likes of tracking protection and popup blockers.

Reducing the features of an insecure site mitigates the risks to users. If this then increases the adoption of HTTPS this really isn't sabotage it's preventing the web from sabotage from MitM.