Re: etags-evercookie patch

Honza Bambas <[email protected]>
Newsgroups gmane.comp.mozilla.devel.netlib
Message-ID <[email protected]>
Idea: for suspected resources we may try to send an anonymous 
non-conditinal request and watch for what etag we get.  It may be 
different while the content may be the same or while we get 304 on the 
current version of the etag.  It would tell us if that is used just for 
tracking and we may add that resource to some 'conditional request 
blacklist'.

-hb-

On 4/6/2012 6:50 PM, Camilo Viecco wrote:
> Hello List
>
> So while I waited for some reviews I wrote an initial patch to solve the
> etag tracking bug. https://bugzilla.mozilla.org/show_bug.cgi?id=231852.
> (I am working on general privacy bugs).
>
> My approach is to have a preference (disabled by default) that makes
> firefox never send validation headers.
>
> Why I think a pref to make them optional is good:
> -> It will only affect stale cache entries, if websites have bothered so
> set up expiration headers there will be no impact for users or websites.
> -> We can still use heuristics that avoid doing validation (ie the file
> was last modified 10 years ago therfore most likely it has not been
> modified in the last five minutes).
> -> this will be a big win for projects that want to enable very strong
> privacy protections without having them to have custom patchsets for
> firefox (see Tor browser bundle).
> -> the code change is minimal, only one line of logic code change (I am
> dicounting the getting the preference observer), so future maintenance
> should be minimal.
>
> Cons:
> -> there is more code to maintain.
> -> Only a small number of users would set it up (but these are very noisy)
>
> Christian Biesinger has also suggested that this would make browser with
> the setting on to be very slow.  I have tried it locally and it does not
> look so. However I would like to actually measure the impact of the
> preference on say the top 100 alexa sites. Any suggestions on how to do
> this?
>
> Maybe I am thinking on a wrong approach, suggestions for making this
> better are appreciated.
>
> Thank you all
>
> Camilo
>
> _______________________________________________
> dev-tech-network mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-network
>

_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.