Reply to thread

Message

<blockquote data-quote="oldschool" data-source="post: 900617" data-attributes="member: 71262">Here is some recent info on native handling ETags&nbsp; <a href="https://github.com/brave/brave-browser/issues/10719" target="_blank">[Desktop] Don&#039;t cache etag and related caching information on small requests · Issue #10719 · brave/brave-browser</a>Maybe the pertinent section is this from a senior researcher at Brave:<a href="https://github.com/pes10k" target="_blank">pes10k</a> commented <a href="https://github.com/brave/brave-browser/issues/10719#issuecomment-674926750" target="_blank">2 days ago</a><table style='width: 100%'><tr><td>Hello <a href="https://github.com/Peacock365" target="_blank">@Peacock365</a> , thanks you again for the link. I don&#039;t think we&#039;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&#039;d values is pretty evenly distributed). 
Some things we are considering though (no decisions made) are: 
<ul>
<li data-xf-list-type="ul">Stripping out etags on small responses, where there is little-to-no perf cost</li>
<li data-xf-list-type="ul">Trying to list build lists of folks using etags for privacy violations</li>
<li data-xf-list-type="ul">Removing etag&#039;s for 3p requests</li>
</ul>
The &quot;correct&quot; solution here though will be to partition etag&#039;s under the 1p though. This work is going on upstream in chromium (we&#039;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! 
________________________________________ 
 
Brave will be moving closer to an extension-free browser for me if something along these lines is implemented. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite130" alt="(y)" title="Thumbs up&nbsp; &nbsp; (y)" loading="lazy" data-shortname="(y)" /><img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite116" alt=":D" title="Big grin&nbsp; &nbsp; :D" loading="lazy" data-shortname=":D" /></td></tr></table></blockquote>

[QUOTE="oldschool, post: 900617, member: 71262"] Here is some recent info on native handling ETags [URL='https://github.com/brave/brave-browser/issues/10719'][Desktop] Don't cache etag and related caching information on small requests · Issue #10719 · brave/brave-browser[/URL] Maybe the pertinent section is this from a senior researcher at Brave: [SIZE=4][B][URL='https://github.com/pes10k']pes10k[/URL] commented [URL='https://github.com/brave/brave-browser/issues/10719#issuecomment-674926750']2 days ago[/URL][/B][/SIZE] [TABLE] [TR] [TD]Hello [URL='https://github.com/Peacock365']@Peacock365[/URL] , 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). [I][B]Some things we are considering though (no decisions made) are:[/B][/I] [LIST] [*]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 [/LIST] 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! ________________________________________ Brave will be moving closer to an extension-free browser for me if something along these lines is implemented. (y):D[/TD] [/TR] [/TABLE] [/QUOTE]

Verification