Re: [dev] [surf] [patch] 13 patches from my Universal Same-Origin Policy branch

From: <tautolog_AT_gmail.com>
Date: Wed, 25 Mar 2015 18:25:36 -0700

Thanks for the reply, Nick.

Re: patch 5, have you seen that behavior before? I saw something from an Ajax request from some advertising code, and made that change after debugging. 

Re: patch 7, ‎I want to do the user agent similar to how I do accept language, adding meaningless semantics that are ignored in a proper negotiation, but which retain the useful semantics that lead to a proper negotiation. 

There needs to be a significant amount of entropy because other stable sources of entropy may be combined. For example, if you just inject a tiny bit of entropy, then relating a naive hash with an IP address will provide a group of hashes which may be logically combined into one virtual hash that may be used even after the IP address changed. ‎I wanted to be one step ahead of that. 
‎
The next step for me is to reorder the parameters to protect against simple comparisons, like levenshtein distance. I want people to need to keep a list of valid tokens, and break the strings down to a set of tokens. That will lower the total bits of entropy possible in the profiling to a more reasonable number.

This entropy stuff is certainly experimental, but I wanted to get some code out in the wild so that it can be more easily conceptualized and discussed. The papers I have read on this haven't mentioned this kind of approach, and just recommend lowering entropy, even though combining it with other loosely-grained identifiers, like even a /16 network, easily defeats it. I think that adding noise to the signal could ultimately be more successful than just reducing the signal, because the process of filtering noise also lowers the bits of signal available. 

Re: patch 9, the race condition is only triggered by patch 13, so it only needs to be merged with patch 13, or any other future code with the same pattern. So it isn't a bug in surf, but it could prevent other future bugs, so I separated it. ‎
‎
Re: patch 10: this also isn't fixing a bug in surf, but allows me to simplify my own code. 

Ben
  Original Message  
From: Nick
Sent: Wednesday, March 25, 2015 5:03 PM
To: dev mail list
Reply To: dev mail list
Subject: Re: [dev] [surf] [patch] 13 patches from my Universal Same-Origin Policy branch

Hi Ben, interesting stuff indeed, thanks for sharing.

Some of these features should be merged into the main surf repo, I
think:

- [PATCH 04/13] Disable useless webkit features that could harm
privacy.

Sounds good to me.

- [PATCH 05/13] Do not trigger a download for subframes that webkit
cannot handle.

Presuming that would stop websites which use flash from causing surf
to download crap.swf, and similar annoyances, then yes, definitely.

- [PATCH 07/13] add random entropy to user-agent and accept-language
headers.

I definitely like the idea, but wonder whether the solution in the
patch is a bit overkill. After all, if we're basically just trying
to defeat hashing correlations, then one random byte at the end of ‎
each variable should be enough. Also, unless I'm misreading it, am I
correct in thinking the user-agent string is fully random? I'm
currently using one from an oldish firefox, to reduce
fingerprintability a bit, and I get annoying warnings on github and
a few other places as a result - isn't it better to use a common-ish
UA string with some random crap on the end, so most stupid websites
won't do something annoying?

- [PATCH 09/13] Need this to apparently prevent a race condition
when calling SETPROP() right after setatom().
- [PATCH 10/13] about:blank seems to not be needed for webkit, and
makes a distinction without a difference, causing mismatches in
URI comparison code.

As I read the commit messages for these they're fixing straight-up
bugs in surf.

I haven't tested these patches yet, but they look sensible.

Nick
Received on Thu Mar 26 2015 - 02:25:36 CET