Improve HTTP security headers and proxify external requests

[emanruse]

Currently invidio.us allows direct 3rd-party connections to (sub)domains of googlevideo.com. For improved privacy those can be proxified by making the backend part of invidio.us redirect the HTTP requests to the 3rd party host without exposing directly the viewer to Google. Then the user will connect only to invidio.us.

More details:

https://webbkoll.dataskydd.net/en/results?url=http%3A%2F%2Finvidio.us%2Fwatch%3Fv%3DC0DPdy98e4c

https://securityheaders.com/?q=https%3A%2F%2Finvidio.us%2Fwatch%3Fv%3DC0DPdy98e4c&hide=on&followRedirects=on

[Perflyst]

Just add &local=true or enable "Proxy Videos?" in settings.

…

On April 1, 2019 10:06:45 AM UTC, emanruse ***@***.***> wrote: Currently invidio.us allows direct 3rd-party connections to (sub)domains of googlevideo.com. For improved privacy those can be proxified by making the backend part of invidio.us redirect the HTTP requests to the 3rd party host without exposing directly the viewer to Google. Then the user will connect only to invidio.us. More details: https://webbkoll.dataskydd.net/en/results?url=http%3A%2F%2Finvidio.us%2Fwatch%3Fv%3DC0DPdy98e4c https://securityheaders.com/?q=https%3A%2F%2Finvidio.us%2Fwatch%3Fv%3DC0DPdy98e4c&hide=on&followRedirects=on -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #462

[emanruse]

In such case the issue is: Enforce &local=true as default. Then &local=false will be an option which turns it off.

[omarroth]

I believe this was mentioned in #34, but to re-iterate here: proxying /videoplayback URLs is more intensive for the site, so it's being rolled out more slowly to ensure there aren't any problems. I expect to change that to the default once I'm confident bandwidth won't be an issue.

[emanruse]

Bandwidth - OK, I understand you have to experiment. But don't forget the other issues in the tests :)

[omarroth]

Added CSP, STS, and Referrer-Policy with a1b3b47.

Important to note is that max-age for Strict-Transport-Security is set to 1 week in order to address any problems before enabling preload.

In future please consider providing recommend action in addition to linking to a static report so it's easier to address.

[emanruse]

Thanks. I didn't add recommendation because the tests do it. BTW there is still work to be done for the headers.

[omarroth]

https://invidio.us is now preloaded.

Work for CSP is still in progress, as inline styles (among other things) are refactored.

Currently, securityheaders.com caps the grade at an A, since Invidious does not implement Feature-Policy, which is currently unavailable or experimental in all major browsers. Once there is an official spec expect support for this to be added.

Unless there are any other specific recommendations I believe this can be closed.

[emanruse]

Rechecking the first link from the OP shows that CSP needs fixing and there are still 2 third-party requests (because the external requests are not proxified). So there are issues that still need fixing. Please also consider the related issue #463.

[Perflyst]

Of course there are third party requests while watching a video to googlevideo.com. You need to enable "proxy videos?" or add a &local=true to the uri to proxy the video through invidious.

[emanruse]

The point of this issue is to make "proxy videos" a default thing, not something that one must type or otherwise set explicitly. Privacy by default.

[Perflyst]

Selfhost and enable proxy by default. I do the same. If you want, do. If not, please wait until it is ready.

…

On May 13, 2019 1:02:34 PM UTC, emanruse ***@***.***> wrote: The point of this issue is to make "proxy videos" a default thing, not something that one must type or otherwise set explicitly. Privacy by default. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #462 (comment)

[omarroth]

I've already mentioned the reason for this above. The reason "proxy videos" is not enabled by default is because it's more bandwidth intensive for the site. "Proxy videos" is enabled by default for the official Tor instance, where privacy is more of a concern. You can enable it for your own instance with:

default_user_preferences:
  local: true

in config.yml.

CSP can be improved, but it doesn't need "fixing". As mentioned above refactoring inline styles and other assets will improve it.

Since no other recommendations for headers have been mentioned I'm going to close this.

[emanruse]

@Perflyst I am not looking for a workaround. I think that has already been made clear. I am raising an issue which shows that the default setting does not ensure the possible privacy. And of course - I am waiting. But now this has been closed, so I wonder what one should one wait for.

[emanruse]

@omar Roth

"Proxy videos" is enabled by default for the official Tor instance, where privacy is more of a concern.

There is difference between privacy (not sharing) and anonymity (not identifying). The current issue is about the former and it is technically possible to have it.

As mentioned above refactoring inline styles and other assets will improve it.

Why close the issue then?

Since no other recommendations with headers have been mentioned I'm going to close this.

There have been. Please: I don't mean to sound demanding. Just pointing out the obvious.

[emanruse]

@omarroth

"Proxy videos" is enabled by default for the official Tor instance

The Content-Security-Policy header is not different even for the Tor instance:

$ torsocks curl -I http://axqzx4s6s54s32yentfqojs3x5i7faxza6xo3ehd4bzzsg2ii4fv2iid.onion
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/html
X-Frame-Options: sameorigin
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src blob: data: 'self' http://axqzx4s6s54s32yentfqojs3x5i7faxza6xo3ehd4bzzsg2ii4fv2iid.onion:8081 'unsafe-inline' 'unsafe-eval'; media-src blob: 'self' http://axqzx4s6s54s32yentfqojs3x5i7faxza6xo3ehd4bzzsg2ii4fv2iid.onion:8081 https://*.googlevideo.com:443
Referrer-Policy: same-origin
Content-Length: 0

$ curl -I https://invidio.us
HTTP/1.1 200 OK
Content-Type: text/html
X-Frame-Options: sameorigin
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src blob: data: 'self' https://invidio.us 'unsafe-inline' 'unsafe-eval'; media-src blob: 'self' https://invidio.us https://*.googlevideo.com:443
Referrer-Policy: same-origin
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Length: 0

[omarroth]

The current issue is about the former and it is technically possible to have it.

It's absolutely technically possible if you're self-hosting and I've provided a configuration for it above. The reason why it's not enabled by default for the main instance is because it's impractical to provide for the current number of users. It is still provided as an option for users that would like to protect their privacy.

The Content-Security-Policy header is not different even for the Tor instance

My comment was in response to third-party requests. Watching videos through Tor will proxy them through the instance by default.

Since no other recommendations with headers have been mentioned I'm going to close this.

There have been.

I'm afraid you'll have to point them out to me. So far CSP and third-party requests have been mentioned and I believe have been addressed. If there is something else that falls under this issue then I'll be happy to reopen.

[emanruse]

It's absolutely technically possible if you're self-hosting and I've provided a configuration for it above.

I am using shared hosting for my sites and I have flawless HTTP headers. The hosting provider does not control my headers.

The reason why it's not enabled by default for the main instance is because it's impractical to provide for the current number of users. It is still provided as an option for users that would like to protect their privacy.

Why is it practical for Tor and impractical without Tor? Is it because Tor traffic users are far less than regular ones? Is it because you cannot afford to pay for traffic? Forgive me to keep asking but I don't quite understand the logic in which anyone's privacy is sacrificed by default unless they are advanced enough to use use Tor. This is confusing. The general user doesn't even know what proxy is.

I'm afraid you'll have to point them out to me.

Marked with red X's: https://webbkoll.dataskydd.net/en/results?url=http%3A%2F%2Finvidio.us%2Fwatch%3Fv%3DC0DPdy98e4c#csp Also right of the orange text: https://securityheaders.com/?q=https%3A%2F%2Finvidio.us%2Fwatch%3Fv%3DC0DPdy98e4c&hide=on&followRedirects=on