Surf-isolated is just my personal branch. It is not official in any way. I am not a surf developer myself, other than having a few trivial commits make it into the official surf. I have no commit access, and I am not the maintainer. However, I answered your question because I am familiar with these aspects with respect to surf.
In my branch, each process only deals with one origin domain, and that is meant to isolate at a process memory space level. Also, each origin domain gets its own browser profile, so cache data on disk is also isolated, but not by chroot or anything special. I just prefix the paths.
The difference between my branch and the main branch is just a set of commits that implement the privacy features I am experimenting with. It is not productized beyond making the git repo public. My purpose is a proof of concept of an approach. It is less about what happens to the code. For me, it started from a discussion in the firefox bugzilla, and I found surf, and spent a couple weeks getting a proof of concept going.
People here are very helpful when the question is explicit. Show the build error, and you will likely get pointers. Are you having issues building my branch or the official branch?
I am not really sure about Tor, as I don't use it. I suppose what you are doing there is fine.
By tracking within a site, I mean that my design is just meant to isolate data between origin domains, to properly implement the "same-origin policy" in a browser. So with my design, your behavior within an origin domain is still fully exposed. For example, wikipedia is a very large site. You can still be tracked going from page to page, and having a profile built from that, but if your IP is obscured, it may be difficult for that wikipedia profile to be tracked back to something else more meaningful. I don't try to separate each request from the next, although that is another level of isolation that may be desirable for some people. I just don't want anyone expecting too much. My concern is more to deal with advertising/dragnet style tracking, not the one-off targeting that might be done against an activist. I know about ad tech, not sigint, so I can't really say much there.
Ben
Original Message
From: Pickfire
Sent: Monday, July 6, 2015 11:03 PM
To: dev_AT_suckless.org
Reply To: dev mail list
Subject: Re: [dev] [surf] Firefox's tracking protection
Does they share the same memory with same process but isolated?
And what is the difference between surf and surf-isolated.
I had opened the code, it really is minimal but I don't understand it
fully as I am still a **novice** in C.
I tried to compile surf with musl-gcc. But it doesn't work, I hope you
can explain more about this and the difference on using it with cc.
I think that the ip address could be hidden by tor. I am using tor with
polipo to sockstify all outgoing network including surf. Is that
correct?
>You still get ads, but they are less targeted. Cookies still work, but
>third party cookies are stored per origin domain. For example, each
>website you go to will get a separate google cookie. You can still be
>tracked *within* a site through cookies.
What do you mean by that?
Thanks for answering my question.
On Mon, Jul 06, 2015 at 11:24:47AM -0700, Ben Woolley wrote:
>Hi Pickfire,
>
>No, nothing like that. Surf's code is small and simple enough that
>even a novice C programmer could add such a feature. It is trivial to
>filter content in surf at the code level. 99% of it would be
>configuration. I encourage you to try to implement the feature. Surf
>is minimal enough that a developer can *configure* it through *code*.
>In that sense, it supports whatever feature you want. If you implement
>the feature, you can post the patch to the website as a possible
>configuration. This keeps the core surf minimal.
>
>--
>
>If you are interested, I have an experimental branch for tracking
>issues. My strategy is to properly implement the same-origin policy,
>by implementing both vertical and horizontal origin isolation -- that
>is, each origin domain gets its own browser profile, and warning
>prompts are issued when crossing origins, preventing data from from
>being shared between origin domains within the browser. This actually
>disables the mechanism exploited by resource-keyed tracking.
>
>How it works is: each browser process is constrained to a single
>origin. Any navigation away from the process-constant origin gets a
>new browser process. The design of surf made it straightforward to
>implement, since it already behaved 90% the way I needed.
>
>You still get ads, but they are less targeted. Cookies still work, but
>third party cookies are stored per origin domain. For example, each
>website you go to will get a separate google cookie. You can still be
>tracked *within* a site through cookies.
>
>You will want to obscure your IP address, too. I consider that a separate issue.
>
>There are some issues remaining:
> 1. POST data that crosses origins isn't preserved, so many
>authentication systems don't work.
> 2. You may need to symlink some profiles together to get, for
>example, google's SSO to work. The profiles for gmail.com and
>accounts.google.com need to be symlinked to log into gmail.
> 3. The header scrambling has some known issues worked out on this
>mailing list.
>
>My experimental branch is here:
>https://github.com/legitparty/surf-isolated
>
>In that branch, use the -O flag to enable the feature. I use `surf -g
>-p -O -D example.com`
>
>--
>
>Take a look at my commits, and it might be clear to you where and how
>to do filtering. If not, just ask, and I will explain, but I encourage
>you to first just dive into the code. In fact, just opening surf.c
>from the official git repo could have told you the answer to your
>question in very little time. It really is *minimal*.
>
>Cheers,
>
>Ben
>
>On 7/6/15, Pickfire <pickfire_AT_riseup.net> wrote:
>> Hi, does surf implement tracking protection which disables sites from
>> tracking using cookies and it is said that it could improve performance in
>> Firefox for
>> up to 44%.
>>
>> Thanks.
Received on Tue Jul 07 2015 - 10:11:09 CEST