Brave-browser: [Desktop] Don't cache etag and related caching information on small requests

[pes10k]

Web trackers sometimes use eTags or HTTP caching values as unique identifiers for cross-site tracking

As a stop gap solution until Blink has full partitioned HTTP caching, Brave should ignore caching information on small requests (<5k). This will both i) target the kinds of resources most frequently used to fetch / retrieve tracking tags, and ii) still keep caching tags on the kinds of resources most likely to be useful to the user (i.e. on large responses).

[pes10k]

re @bridiver
```diff --git a/net/http/http_cache_transaction.cc b/net/http/http_cache_transaction.cc
index ad6e626898d1f51fe51d4bc38ad660ce8d8022e1..23138f022cf096b5b25a630fddc9380b39d31888 100644
--- a/net/http/http_cache_transaction.cc
+++ b/net/http/http_cache_transaction.cc
@@ -2834,6 +2834,11 @@ bool HttpCache::Transaction::ConditionalizeRequest() {
} else {
custom_request_->extra_headers.SetHeader(
HttpRequestHeaders::kIfNoneMatch, etag_value);

• size_t cache_size = entry_->EstimateMemoryUsage();
• if (cache_size == 0 && entry_->disk_entry != nullptr)
• cache_size = entry_->disk_entry->GetDataSize(kResponseContentIndex);
• if (cache_size <= 1000)
• custom_request_->extra_headers.RemoveHeader(HttpRequestHeaders::kIfNoneMatch);
  }
  // For byte-range requests, make sure that we use only one way to validate
  // the request.

[Peacock365]

May I suggest this as a better approach:

https://gitlab.com/KevinRoebert/ClearUrls/-/blob/master/core_js/eTagFilter.js

Making this dependent on the size of the request doesn't seem like a good idea, rather, you should filter the eTag header out. The solution used by ClearURLs is what the extension eTag Stoppa for Firefox uses, as well. I recommend the same for Brave.

[pes10k]

Hello @Peacock365 , thanks you again for the link. I don't think we'd be comfortable removing etags all togehter, as that will have a significant performance impact on users (I just ran some measurements last week on this, and the size of responses to etag'd values is pretty evenly distributed).

Some things we are considering though (no decisions made) are:

• Stripping out etags on small responses, where there is little-to-no perf cost
• Trying to list build lists of folks using etags for privacy violations
• Removing etag's for 3p requests

The "correct" solution here though will be to partition etag's under the 1p though. This work is going on upstream in chromium (we've very excited for it), though depending on how long that will take up stream, we might consider a shorter term solution too.

Thanks again for the suggestion!

[Peacock365]

Yeah, so I didn't feel any performance impact here, my hardware isn't great (measly MacBook Pro 13" from 2015) and neither is my Internet connection, with or without ClearURLs doesn't seem to make a difference here, and yes, the extension is filtering out eTag headers like crazy. If Chromium upstream is tackling this, I suppose you should wait for what comes out of that, though.

[Peacock365]

I do realize though that my setup is nowhere near a scientific test or so, haha. :-D