Re: [dev] [surf] [PATCH] cookie policy

From: Christoph Lohmann <>
Date: Thu, 30 Jan 2014 14:58:53 +0100


On Thu, 30 Jan 2014 14:58:53 +0100 Quentin Rameau <> wrote:
> Sorry, patches in previous mail were wrong, here are the good ones.
> On Wed, Jan 29, 2014 at 2:14 PM, Quentin Rameau <> wrote:
> > Hi, another version of the patches, with a command line option added.
> > I'll have a look on monday for implementing a whitelist.

Implementing the »list« part of that proposal is the interesting part,
because thinking further the »policy file« could inherit different de‐
fault modes for domains too, like the plugins, scripts, javascript etc..

Some further questions:
        Is premature optimisation needed for the growing Internet?
        Will things get slow is scaling to thousands of domains?
        Should premature optimisation include some kind of caching?
        Will the complex code of that caching upset people using surf?

I’d propose a modfile variable, which is NULL by default and so does not
inherit any filesystem access. When this variable is specified or the
‐m(mode) flag is given with a modefile, then this file is read.

Mode file syntax:

        A string which can be given to regcomp(..., hostregex, REG_EXTENDED).

        cookies + modestring

        [Aa_AT_] /* A: always, a: never, @: no third party */

        cgisvm /* as known */

Such a file should be easily managable using scripts. Match the given
domain name, surf would use and modify the given modestring. If no host‐
name was found, add it’s raw value. Users should modify or shorten this
on her/his own using their sanity.

Any comments?

About the modestring: The modestring is a given institution and
won’t be extended. If more than the alphabet is needed, something is re‐
ally going wrong in the web.


Christoph Lohmann
Received on Thu Jan 30 2014 - 14:58:53 CET

This archive was generated by hypermail 2.3.0 : Thu Jan 30 2014 - 15:24:06 CET