Re: Galeon 1.2.5 to 1.3.19 conveersion a couple of questions

on Sun, Feb 06, 2005 at 11:10:05AM +0000, Crispin Flowerday ([email protected]) wrote:
> On Sat, 2005-02-05 at 21:19 -0800, Karsten M. Self wrote:

> >   - Better memory performance.  1.2.x seemed to leak faster than 1.3,
> >     though 1.3.x is still leaking, and pretty badly at 1.3.19-1.
> 
> If anyone can track down these memory leaks, then please tell us, I have
> tried valgrind, but couldn't see anything major.

Could you point to some tips for how end-users could do this, and what a
useful format for a report would be?

What's the performance impact of valgrind?  Presumably you're running
Galeon from it, right?
 
> > 1.2 wins over 1.3 with:
> > 
> >   - Portal.  In 1.2, it was possible to open up subsections of the
> >     portal page.  I have enough bookmarks (1400+ at last check, several
> >     recovered sessions) that this is really useful.  Better would be a
> >     freestanding bookmark management tool interfaced through the
> >     browser, but stored independently and accessible cross-browser.
> 
> The My Portal in 1.3.19 should be on a par with the one in 1.2, I
> basically re-wrote it. If it is still missing things, let me know.

Indeed!  Looks nice, thanks!

 
> >   - FFX Better cookie handling.  Being able to specify session-only
> >     cookies is a major win.
> 
> I'm not quite sure what you mean be this, in 1.3.19 you can accept
> cookies always, always ask, always ask except for session cookies, or
> force all cookies to be session cookies, what more do you want ?

FFX cookie confirmation dialog reads:

    +--------------------------------------------------------+
    | The site <site> wants to set a cookie.                 |
    | [ ] Use my choice for all cookies from this site       |
    |                                                        |
    | [Show Details]    [Allow] [Allow for Session] [Deny]   |
    |         -          -                 -         -       |
    +--------------------------------------------------------+

    http://linuxmafia.com/~karsten/Images/ffx-cookie-confirm.png

...with an option being "allow cookie for session only".  It effectively
converts a persistant cookie to a session cookie.

I *really* like this.  It allows site functionality while addressing
privacy issues of long-term persistant cookies.

I'm composing a wishlist post separately, cookies are actually a hard
thing to specify.  There are a number of possible options, and I don't
mean to suggest all should be considered, though several should be:

  - Allow / deny third-party site cookies.

    Rationale:  third-party cookies are used for cross-site data
    sharing, and constitute a privacy violation issue.  They generally
    do _not_ affect site functionality and can generally be disabled
    without functionality impacts.

  - Allow / deny cookies to a domain|site.

    Rationale:  many domains (advertising sites, marketing sites,
    malware sites, spammer sites) don't have a user-benefitting interest
    in setting cookies.  User should be able to deny same.  Option of
    bulk-loading such domains from various lists or blocking on basis of
    a DNSBL query would also be useful.  Current cookie management tools
    are slow/cumbersome.

  - Allow / deny persistant cookies.

    Rationale:  many sites require cookies for session state tracking.
    Session cookies pose relatively little risk for privacy violation,
    and loss of state between session has low risk of usability impacts.
    Allowing (or defaulting to) session-only cookies for the bulk of
    cases would be a good privacy/functionality compromise.

  - Modify cookie expiration date:
    - Query session/peristant on per-cookie basis (user dialog).
    - Override persistance on all expirations past a certain duration
      (day|week|month|year...)

    Rationale:  In some cases, persistance is useful.  Most user
    behavior involves regular visits to specific sites.  Allowing
    persistance over a day - week period would probably be sufficient
    for most cases, while avoiding abuse of long-term persistance of
    cookies (why should a cookie persist until 2038?).  Setting a
    maximum allowed lifetime becomes a useful heuristic.  Allows some
    multi-session user tracking.

  - Wafers:  spoof cookie data (to selected servers).

    Rationale:  polluting servers with spoofed cookie data may impose
    "training" on sites to adopt saner cookie policies.  May result in
    functionality losses.  Has a karmic appeal, but probably not a
    net-beneficial general feature.  Cross-user sharing of cookie data
    is another idea, similar to exchanging of consumer tracking cards
    ("loyalty" shopping cards) in retail establishments.


I'd like to see options for persistance added, possibly maximum
persistance.  The cookie management dialog is currently *way*
cumbersome.  I'd like to be able to bulk load a list of sites for which
I will never allow cookies, e.g.:  from the commandline.  Instructions
on how to generate/load appropriate gconf settings would suffice.

Adding the ability to query DNSBLs for specific actions (cookies, site
loading, image loading) is another feature I see becoming more prevalent
over the next year or so.  With the increase in phishing and related
scams, being able to aggregate data on the trustworthiness of sites
would be useful.  *Especially* in corporate or educational environments.
This sort of behavior might allow or deny user override.  E.g.:

    Warning:  this site is blocked for (Phishing|Malware|Other) reasons

        Click for more information
        (Click to override warning | Your administrator denies access)

DNSBLs are useful for both aggregating information _and_ allowing rapid
access to same.  Tying DNSBLs to various actions is probably a good
topic for further discussion before implementation.  There are a number
of anti-phishing tools which already use similar schemes.  This somewhat
duplicates the function of existing filtering proxies, but is based on
reputation rather than content, per se.


Peace.

-- 
Karsten M. Self <[email protected]>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    Microsoft KB:  Cookies Lost After Upgrading to Windows XP.
    [Ed:  WONTFIX:  Feature]
    - http://support.microsoft.com/?kbid=282850

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCBrC+efG8443k044RAnkkAJ9zh3kqA7ZTfPJSoJiLLmJSXAh/qACfdeE2
HQ7IlRkiX1nEpwCejg2rie4=
=6D6J
-----END PGP SIGNATURE-----