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

From: sekret <sekret_AT_posteo.se>
Date: Thu, 26 Mar 2015 00:10:35 +0100

Am 25. März 2015 05:43:48 MEZ, schrieb Ben Woolley <tautolog_AT_gmail.com>:
>Hi list,
>
>I merged my big patch with the latest master, and finally got around
>to splitting up my big patch into 13 smaller patches in commit order
>(used git format patch). Each commit compiles and functions, and is
>separately integrated, so the progression is easier to see.
>
>A summary of what features these patches add:
>
>1. Universal Same-Origin policy. This keys all browser state (both
>memory and disk) by origin domain, so that cookie and cache tracking
>from site to site is blocked by isolation. Yet cookies and cache still
>fully function as long as the same-origin policy is acknowledged by
>the website design. Also, a link or redirect, or any navigation that
>crosses sites/origins gets a dmenu warning prompt. POSTs don't
>currently work. Basically, newwindow() needs to support non-GET
>methods. I am still designing the best way to do that with libsoup,
>basically serializing the request on disk and unserializing it in the
>new origin's process.
>
>2. User-Agent and Accept-Language headers have random entropy added to
>each request. This means that browser profiling that uses those
>headers without semantic parsing will get a random identifier each
>request, preventing linkability. This is designed to cause difficulty
>for naive browser profiling techniques that just hash a bunch of
>headers.
>
>3. dmenu-based Download Wizard. This allows you to see what file will
>be downloaded, and select which folder to download it to, and what
>filename to save it as, with reasonable defaults. May be a bit
>overkill for you guys, but I like it.
>
>4. Some default features of webkit that may cause a privacy issue are
>disabled. I have been browsing just fine without them.
>
>5. Refactoring necessary to get the one-origin-per-process constraint
>working, like moving the qualifying of the URI earlier, so that the
>origin can be immediately known. Also, keeping some additional loading
>state, and adding some navigation hooks into webkit that weren't
>previously needed.
>
>I usually call surf as `surf -g -p -O -D`. I disable geolocation (-g)
>and plugins (-p), and enable the same-origin policy (-O) and disk
>cache (-D). Not just the cookies, but the disk cache, and even html5
>local storage databases are per-origin on disk when you pass -O.
>
>I usually use tabbed to manage the per-origin windows well. I put the
>origin at the beginning of the window title so that it is clear which
>tab is which origin. It works out quite well for me.
>
>What has been working well for me is to run this mode by default, and
>I use something else (disable the mode, or run Firefox), if I need the
>compability. I have some issues logging into things like bank
>websites, I think because of the POST issue remaining, so I just use
>something else for that, and keep my "surfing" to surf. I have been
>able to pay some bills online using this mode.
>
>The way the login issue usually presents itself is for the auth
>redirects to get into an infinite loop (4 times is normal, but 10
>times means something is probably wrong). I am considering adding a
>feature to the prompt which lets you break the loop by linking the
>crossing origins together the way i do for www.gmail.com and
>accounts.google.com (symbolic link the origin folders).
>
>There are several things in here that could probably use command-line
>arguments, but I am not really sure which features warrant
>command-line arguments, and/or what they should be, but with the
>patches separated, that can be discussed better.
>
>Any comment and/or opinion is welcome. I tried to follow the suckless
>philosophy/style, but as I am not "native" to this community, I am not
>really sure where it stands in that respect, except that there are
>certainly parts that feel a bit sucky, so a pointer in the right
>direction would be appreciated. The main guideline I have seen
>regarding surf is that it is to be "a suckless interface to a sucky
>web".
>
>I tried to keep the refactoring as suckless as possible, since that is
>what depends on knowledge of how surf works, which requires some
>knowledge of webkit and its dependencies. It took me a couple weeks to
>get up to speed, so there is certainly a barrier there. The functions
>that actually implement the origin comparisons and the random entropy
>are a bit sucky, but they are isolated, and can be improved by anyone.
>I just wanted to get something out the door there.
>
>Thank you for your valuable time,
>
>Ben Woolley

One word:

Wow!
Received on Thu Mar 26 2015 - 00:10:35 CET