Re: [dev] surf vertical and horizontal same-origin policy patch (updated, with profiling mitigation)

From: <>
Date: Sat, 24 Jan 2015 10:10:27 -0800

Thanks for the reply, Christoph,

= profiling =

I view panopticlick as a theoretical demonstration of how many bits of entropy can leak, not a robust implementation that can properly test defenses against sophisticated profiling. 

The panopticlick site cannot measure the noise-based approach. Or rather its only measure would be of 100% success, so there would need to be another measure. It is effectively equal to a digest-based approach, so defeating that approach is a measurable first step. Then I believe a more advanced suite that parses values out of the headers would need to be the next step. 

The main point I want to make is that, in the real world, the entropy of the browser is added to other identifiers, like IP address and/or other network inspection data. Even a little entropy goes a long way there, and the successful injection of noise into the signal affects all other sources, so I am not sure why the experts do not want to recommend the approach of adding noise. I suspect that the people involved are outside their knowledge domain, and just don't want to recommend something that they don't fully understand. 

= the prompt =

I expected that the HTML based prompt would never be accepted. It was the quickest path for me to actually test the theory. 

For surf, I want to take your advice and keep things simple. I am thinking to just pop up a dmenu whenever the origin is about to change, and have the full URL as a single option, and users can either:
1. Select the full URL input.
2. Edit it to remove the tracking identifiers before continuing (pressing tab would complete the URL for edit). 
3. Select nothing to abort.

Basically, it would be like control-g were triggered, but where the new origin's URL is the single option.  Would that fit the surf philosophy? I may be able to reuse the SETPROP macro already used for control-g. 

With keyboard navigation, I believe the extra burden would just be an additional need to press either:
1. Right-arrow and Return after verifying input. 
2. Shift-Return after verifying the input.

That is far better than the HTML prompt already, except that there is no method to trust the relationship and skip the prompt the next time. Do you have any desire in such a feature? 

I would also like to demonstrate how it could work in a conventional browser, where finely-grained permissions are common. That is where the GtkMenu and/or HTML interface comes in. Of course, that would be a separate branch not intended for surf users, but developers of other browsers. However, I realize now that the dmenu approach is similar to just altering the contents of the location bar to be the unverified link, and pre-selecting the questionable query string part of the URL so that it can be easily edited. 

I appreciate the comment to not over optimize. I often need to be reminded that. The issue I have is that the solution I am proposing is not just a feature, but an idea that approaches identity as a device resource, so I often get way ahead of the implementation. This idea is actually a response to a discussion with a Mozilla developer, and my experience working with ad exchange traffic, and real products in that market. 

Mozilla has been wavering on origin isolation since 2010, and they seem to be leaning toward a blacklist approach, while I am trying to demonstrate what a proper whitelist approach would look like. I don't think they have fully considered practical options for a more transparent approach. 

Thanks again for the feedback,

  Original Message  
From: Christoph Lohmann
Sent: Friday, January 23, 2015 11:57 PM
To: dev mail list
Reply To: dev mail list
Subject: Re: [dev] surf vertical and horizontal same-origin policy patch (updated, with profiling mitigation)


On Sat, 24 Jan 2015 08:49:50 +0100 Ben Woolley <> 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‐

> 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.


Christoph Lohmann

Received on Sat Jan 24 2015 - 19:10:27 CET

This archive was generated by hypermail 2.3.0 : Sat Jan 24 2015 - 19:12:08 CET