Opened 18 months ago

Last modified 8 months ago

#22981 new defect

Don't block audio/video on https sites under Medium Security

Reported by: arthuredelstein Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-usability, tbb-security-slider, ux-team
Cc: intrigeri, tseretni-rmd Actual Points:
Parent ID: #23150 Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (10)

comment:1 in reply to:  description ; Changed 18 months ago by gk

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.

comment:2 in reply to:  1 Changed 18 months ago by arthuredelstein

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 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!).

comment:3 Changed 18 months ago by arthuredelstein

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.

comment:4 Changed 18 months ago by linda

Parent ID: #23150

comment:5 Changed 18 months ago by cypherpunks

Last edited 16 months ago by cypherpunks (previous) (diff)

comment:6 Changed 11 months ago by intrigeri

Cc: intrigeri added

comment:7 Changed 9 months ago by arthuredelstein

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.

comment:8 Changed 9 months ago by tseretni-rmd

Cc: tseretni-rmd added

comment:9 Changed 8 months ago by 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.

comment:10 in reply to:  9 Changed 8 months ago by arthuredelstein

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.

Note: See TracTickets for help on using tickets.