Greetings.
On Sat, 24 Jan 2015 08:49:50 +0100 Ben Woolley <tautolog_AT_gmail.com> wrote:
> Hi all,
>
> I have attached an update.
Thanks for your hard work. I appreciate it.
> I read some papers on the profiling issue, and most seem to say that
> lowering the diversity is the key, effectively lowering the
> "bandwidth" of the "signal", and want to avoid randomizing anything.
> However:
> 1. If noise is added to this "signal", then noise reduction techniques
> must be used, and such techniques usually need an appropriate model or
> profile of the noise to discard it, and that is a fairly difficult
> thing to do at scale.
> 2. A valid concern is that semantics could suffer. But it is not
> difficult to add noise that is semantically valid. If a profiling
> method needed to rely on semantics, then the available bandwidth is
> limited even further. For example, the order of values may be
> semantically insignificant, but different orderings would be a
> profiling value in itself, because they would alter a digest of the
> header. By randomizing the order, the semantics would need to be
> understood, and would provide less signal entropy. Naive digests would
> be useless.
> 3. Digests are commonly used to share device identifiers in the
> tracking industry, and it is trivial for the industry to tool that
> same code to other headers, like User-Agent. By breaking naive digest
> methods, the tracking industry would need to use more sophisticated
> methods that returned less value.
Wouldn’t [0] be the best benchmark for your problem? If there is a
benchmark, then proposing changes is easier.
> Future plans:
> 1. I plan on doing more semantically valid randomization like what I
> did to the Accept-Language header.
> 2. I was thinking of using dmenu instead of the HTML prompt, by using
> a wrapper script that launched surf or aborted. This wrapper could
> then isolate by merely exporting a different $HOME to surf, for each
> origin. This would allow me to move a bunch of code out of surf.c and
> into a shell script. If I can get the changes to surf.c down to just a
> few lines, then, I can package up the wrapper separately, and make
> changes to it without affecting the surf build.
This is the main reason why I can’t include your patch in surf: This
HTML prompt. It doesn’t fit the suckless philosophy.
> 3. This also may make it easier to support other embeddable browsers,
> like dillo, since the per-origin $HOME would work there. The prompt
> could even map different browsers to different origins. A simple
> origin library with a standard interface could be used by various
> browsers, just calling out to it whenever navigation occurs.
Don’t add too much complexity. You are building a solution for a problem
which can be of no interest in some months. If you add too many abstrac‐
tion layers you are doing premature optimisation and noone’s going to
use your code. Keep it simple and straightforward.
> 4. I thought about using GtkMenu when you click a link, but dmenu is
> surf's conventional menu, and suits surf's keyboard-driven use cases.
Then add some »Incognito« mode to surf, which would trigger such a be‐
haviour. Standard users should be protected in a mean way with good de‐
faults.
> 5. I am thinking of using the stylesheet regex technique to map URLs
> to origins, so that grouped origins like google subdomains can be
> easier to set up. Currently, I use symbolic links to map origin
> folders together. The main benefit is that the configuration can all
> be in one place. Symbolic links are easy to create, but can be
> difficult to maintain. However, if I break the code out into a
> separate library, I would probably adopt thttpd's glob patterns ("*"
> selected anything in between delimiters, while "**" selected anything
> across delimiters).
As said above: Go the straight way. Don’t throw away the obvious way be‐
cause you need pretend to need some feature.
Sincerely,
Christoph Lohmann
[0]
https://panopticlick.eff.org/index.php?action=log&js=yes
Received on Sat Jan 24 2015 - 08:49:50 CET