Hi Christoph,
I have attached a patch against master that uses dmenu instead of an
HTML prompt. I added a prompt argument to SETPROP that passes to dmenu
-p.
There is some prompt language that would need to be translated, but it
is all in the config file.
Basically, when a new window opens, if it needs a prompt, instead of
loading the URL first, it triggers the SETPROP that control-g would
have done, but prompts with details of the crossing.
dmenu works nicely here because you just need to glance at the URL and
press enter. Otherwise, you can press tab and edit the tracking stuff
right out of it.
I made it so that if visual content is never loaded, like in a series
of redirects, then the window will automatically be closed. This means
that no blank windows are left around after a complicated single
sign-on, or even just a simple example.com to www.example.com
redirect.
I also added a sophisticated download prompt. It uses dmenu to ask
which folder to download it to, with a sensible default, and then asks
which filename to save it as, with a sensible default. Also, the 5
second pause is removed for a `read` that waits for Enter. This is
just one chunk, so I can break that out separately and submit it alone
easily.
I also set some webkit properties that disabled some features. Pleast
let me know if you would like any of those to have config knobs, and I
will patckage that up as a separate patch.
Please let me know what you think. I can break out things into
separate patches as needed.
Thank you,
Ben
On 1/24/15, tautolog_AT_gmail.com <tautolog_AT_gmail.com> wrote:
> 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,
>
> Ben
> 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)
>
> 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 Wed Jan 28 2015 - 21:01:24 CET