Low risk xss. If the torrent contains a specially crafted title or file name, and the user starts the WebTorrent HTTP server via createServer(), and then the user visits the HTTP server index page (which lists the contents of the torrent), then the attacker can run JavaScript in this browser context.

The reason this seems relatively low risk is that the WebTorrent HTTP server only allows fetching data pieces from the torrent. It doesn't support any other control of the torrent client. So, attacker code could e.g. figure out what content the user is downloading and exfiltrate that to an external domain.

This commit mitigates the issue in two ways (either of which could have prevented this XSS on its own):

1. HTML-escape untrusted torrent metadata (name, path, file names, etc.)

2. Add the strictest possible CSP to prevent all connections, scripts, styles, plugins, frames. Every capability is denied.