Don't block audio/video on https sites under Medium Security
Right now "Medium Security" on the security slider blocks all audio and video using NoScript. But JavaScript is allowed for https sites. I would suggest also unblocking video and audio for https sites but keeping them blocked for http sites. This would increase usability for sites such as YouTube.
High Security would continue to block audio and video for both https and http sites.
Activity
Replying to arthuredelstein:
Right now "Medium Security" on the security slider blocks all audio and video using NoScript. But JavaScript is allowed for https sites. I would suggest also unblocking video and audio for https sites but keeping them blocked for http sites. This would increase usability for sites such as YouTube.
While it would increase usability for websites I am not sold we should do that yet. The analogy to our treatment of JavaScript is an interesting one but we should not forget that we allow only non-JITed JavaScript on HTTPS pages. The reason for not allowing JIT at all (i.e. irrespective of the transport) is the high amount of vulnerabilities in this part of the code. Exactly the same reason is behind blocking audio/video by default. But audio/video is more important than JIT, right (although not allowing the latter breaks sites as well!)? True. That's the reason behind making it easy to allow playing videos if wanted.
I think before seriously thinking about not blocking audio/video anymore for HTTPS pages we should investigate how complex the click-to-play thing is and whether we could simplify it to a point where that alone would be a sufficient usability improvement.
Replying to gk:
Replying to arthuredelstein:
I think before seriously thinking about not blocking audio/video anymore for HTTPS pages we should investigate how complex the click-to-play thing is and whether we could simplify it to a point where that alone would be a sufficient usability improvement.
I agree that would be a good idea and would at least partially address the underlying problem. I opened #22985 (moved) to investigate this issue.
My hope, though, is to make Medium Security more attractive so that more users will use it and have better protection. Because I think the threat both from JS and video/audio is much, much higher on non-https sites than on https sites, it seems appropriate to consider treating those two categories of sites differently at Medium Security (or possibly even Low Security!).
One other potentially useful comparison is the threat of exploits via content JS (non-JITed) vs the threat from video (and audio). Skimming through Firefox's list of historical vulnerabilities gives me the impression that the threat from scripts is higher than that from video. (Please correct me if I'm somehow getting the wrong impression.) A higher risk from scripts also appeals to my intuition, given that the C++ codebase exercised by Web APIs is pretty huge.
If it's true that scripts pose a greater threat than video, the benefit of blocking videos while allowing scripts seems not so compelling.
Trac:
Parent: N/A to #23150 (moved)To explain a little more, the idea here is to essentially make the security settings for HTTP and HTTPS independent. That results in three security levels:
Low: HTTP unprotected, HTTPS unprotected Medium: HTTP protected, HTTPS unprotected High: HTTP protected, HTTPS protected
This has usability benefits because it simplifies user's understanding of what protections are at each level. And on Medium Security, the usability has improved while still protecting against hostile injections on HTTP sites.
It also has fingerprinting benefits by making Medium and High Security look the same on HTTP sites and Low and Medium look the same on HTTPS sites.
Replying to cypherpunks:
It's worth considering that we're now just a few years before HTTPS usage gets to more than 90% by default, under this proposal this means that there would be only two security settings: Standard-Safe (basically indistinguishable for the average user) and Safest.
Agreed -- that step would further improve simplicity and provide better security at the default (lower security) setting.
mentioned in issue #26128 (moved)
