Opened 8 months ago

Last modified 7 weeks ago

#29705 new defect

Enable Brotli compression for .onion domains

Reported by: expyuzz4wqqyqhjn Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: cypherpunks Actual Points:
Parent ID: #21728 Points:
Reviewer: Sponsor: Sponsor27

Description

Tor Browser treats .onion as secure domains. Brotli compression is only enabled in Firefox on secure domains, but not for .onion domains.

Internally, Firefox controls these from the following settings:
network.http.accept-encoding
network.http.accept-encoding.secure

.onion is treated as the first instance (insecure) and only enable gzip and deflate. It should be handled as the second category and thus also enable Brotli compression.

Brotli compression will be beneficial to .onion service performance and reducing the data usage of Tor Browser.

PS: The requirement for Brotli to only be used on secure connections was a political decision by Google who wanted to use their new efficient compression method as a carrot to encourage HTTPS adoption.

Child Tickets

Change History (7)

comment:1 Changed 8 months ago by gk

Good idea. I wonder why this is not covered by my patches for https://bugzilla.mozilla.org/show_bug.cgi?id=1382359, though... But, yes, we should expand the "treat .onion as secure context pattern here".

comment:2 Changed 7 months ago by gk

Sponsor: Sponsor27

comment:3 in reply to:  1 Changed 7 months ago by cypherpunks

Replying to gk:

Good idea. I wonder why this is not covered by my patches for https://bugzilla.mozilla.org/show_bug.cgi?id=1382359, though...

Because your patches don't make them HTTPS? ;)

comment:4 Changed 7 months ago by gk

Parent ID: #21728

comment:5 Changed 7 months ago by cypherpunks

Cc: cypherpunks added

comment:6 Changed 7 weeks ago by willbarr

Aside from treating onion as a secure context, I think this needs to be fixed separately.

The reason google banned brotli from http seems 1) to promote https 2) poorly maintained http sites may broke.

Refer: https://hacks.mozilla.org/2015/11/better-than-gzip-compression-with-brotli/

I think the risks of enabling brotli over http and breaking onion sites is less important than it’s advantages when supported.

There are two ways to enable brotli support, 1) just enable it on all http requests including non-onions 2) creating a “potentialy trustworthy” context, put onion sites there and enable brotli there.

The first approach will be as simple as adding br here. https://gitweb.torproject.org/tor-browser.git/tree/modules/libpref/init/all.js#n1754

This is presumed to break certain legacy sites. However I haven’t had any problems when I tested this on various sites.

The second approach is rather hard, and it deviates a lot from upstream firefox code base. I’ve found an example implementation, which enables brotli on localhost by putting them into a “potentially trustworthy” context”.

https://bugzilla.mozilla.org/show_bug.cgi?id=1222541

https://bug1222541.bmoattachments.org/attachment.cgi?id=9040956

I’d like to hear devs opinion on this.

Version 0, edited 7 weeks ago by willbarr (next)

comment:7 in reply to:  6 Changed 7 weeks ago by gk

Replying to willbarr:

[snip]

The second approach is rather hard, and it deviates a lot from upstream firefox code base. I’ve found an example implementation, which enables brotli on localhost by putting them into a “potentially trustworthy” context”.

https://bugzilla.mozilla.org/show_bug.cgi?id=1222541

https://bug1222541.bmoattachments.org/attachment.cgi?id=9040956

Yes, we should use the "potentially trustworthy context" here. We got a patch for that into Firefox a while back and use IsPotentiallyTrustworthyOnion().

https://searchfox.org/mozilla-esr68/source/dom/security/nsMixedContentBlocker.cpp#389

Note: See TracTickets for help on using tickets.