Re: Galeon 1.2.5 to 1.3.19 conveersion a couple of questions

on Mon, Feb 07, 2005 at 12:36:40PM +0000, Nix ([email protected]) wrote:
> On Sun, 6 Feb 2005, Karsten M. Self spake:
> > on Mon, Feb 07, 2005 at 12:27:49AM +0000, Nix ([email protected]) wrote:
> >> On Sun, 6 Feb 2005, Karsten M. Self wrote:
> >> > ...with an option being "allow cookie for session only".  It
> >> > effectively converts a persistant cookie to a session cookie.
> >> 
> >> That's, um, the `Cookies expire at the end of the session' option. :)
> > 
> > Correct me if I'm wrong[1], but that's a global setting, no?  Did you
> > look at the FFX dialog?
> 
> Oh. I didn't notice that. Hmm.

Please try reading with comprehension bit *on*.
 
> > Actually, with a password manager, cross-session password persistance
> > isn't _too_ massively useful....
> 
> Yeah, but some of us have persistent cookies for things like GNATS and
> bugzilla which store more than passwords. It's not common, perhaps...

What's that offer you?

 
> >> > 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.
> >> 
> >> URIBLs seem more useful things to query: they're *meant* to track
> >> malicious URIs/URLs, after all.
> > 
> > Well, yeah, but same difference.  The idea is that you're doing a
> > fast, cachable lookup on a common, external resource.
> 
> Yes, but it's a good idea to use a resource that's intended to track
> malicious URIs rather than one intended to track the sources of
> malicious email: the two are almost entirely divergent these days.

'DNSBL' is a generic term for "DNS-based (black|block)list".  The
block/black reference is itself arbitrary.

The listing policy of a particular BL can be pretty much anything
ranging from spam received to country to background color of a website.

The relevant point is (and this is the third time I've repeated myself,
I'm getting tired of this):

   - An externally managed list or lists.  A given tool might query an
     one or more such lists.  The lists might be public or private.

   - A DNS-based (or other rapid lookup) of data specific to the list.

   - Action taken based on list.  Could be a block.  Could be flagging
     of content.  Could be a logging action.   Could be selective
     disabiling of functionality (e.g.:  browser features likely to be
     abused/misused).

Listing criteria can differ.  Disposition of data or content based on
results can differ.  The common thread is being able to query based on
point of origin or content.


That said:  if you subscribe to the principle of Good Net Higeine[tm],
it's frequently the case that a particular netblock / netspace that
exercises good practices in one area typically does so in others, and
either doesn't allow, or quickly quashes, Bad Neighborly behavior.
Conversly, sites / netblocks which permit one level of abuse (spam, open
proxies, phishing sites) whether through incompetence or overt support,
often allow others.  

My tracking of spam for the past year by ASN source indicates that over
25% of spam comes from the top 4-5 ASNs.  There's a little bit of
migration through these, though representation from Kornet, several
Chinese ISPs, and major US broadband providers is pretty constant.
Kornet's held the top position with ~15% of *ALL* spam consistently.

 
Peace.

-- 
Karsten M. Self <[email protected]>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    Inconceivable!
    - Princess Bride

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

iD8DBQFCB/8XefG8443k044RAi94AJ9rg4DQ0yV58kBClXRt85ZbrECvpQCbBVBk
+bAaQ8RARN6EIe3t/cw5B1M=
=psvp
-----END PGP SIGNATURE-----