Subject: Re: [domainrep] What's in scope and what's not

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Sep 2010 21:32:24 +0100

On 31/08/10 23:05, Rolf E. Sonneveld wrote:
["that" = privacy below]
>> For a DNS based solution, that can be achieved to an acceptable
>> level for free or nearly free,
> 
> Can you elaborate?

DNS queries can mostly get resolved locally once they have a
reasonable TTL so the reputation provider doesn't get to see
all queries.

>> but for the large query/response
>> model, it can be a good bit of work. (And may be an example of
>> where the "large" protocol differs substantively from the "small"
>> one.)
> 
> Why would the large query/response be very different from the small one?
> After all, the 'unit of query' is a domain name (or uri), and not the
> small amount of data (small query) or large amount of data (large query)
> that will be returned for the domain/uri.

If e.g. a HTTP model isn't suited for cached responses, then all queries
go to the reputation provider which then gets to see everything and
can then aggregate all my queries. Including options in queries and/or
expecting "fresh" responses makes it hard to cache responses (or makes
cache hits unlikely). I suspect a "large" model would include such
options.

To get around this you have to do something like ask for a chunk of
reputation information that covers enough queries that you're happy
privacy hasn't been damaged. Can be done, but adds complexity.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Sep 2010 21:36:36 +0100

On 31/08/10 23:32, J.D. Falk wrote:
> On Aug 31, 2010, at 12:18 AM, Stephen Farrell wrote:
> 
>> This may have come up in the requirements thread (if so, sorry, I'm
>> catching up from vacation;-), but I think considerations related to
>> the requestor's privacy should be in scope. I guess the main
>> concern would be that the service provider (or someone else) should
>> not be easily able to track the list of domains of interest to a
>> requestor.
> 
> Interesting!  I hadn't considered this possibility, probably because it doesn't exist in any current reputation framework.  Which concern(s) does it solve?

Depends on the applications I guess. Probably not a concern
if an MTA is asking about mail sender/author/whatever related
reputations, but if an end-user is asking about healthcare
providers then there's a real privacy issue if the reputation
provider gets to see all the domains they go after, e.g. if a
browser or other client application automated making the request.

There've been a load of times people thought they were being
spied on due to the safe web browsing thing, even though that
does go to some trouble to do this right. (Client downloads
chunks of data and doesn't send the domain/URL itself.)

S.

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 2 Sep 2010 16:15:22 -0700

> browser or other client application automated making the request.

Ahh, yeah, that makes sense.  I wonder if there's a way to do this such that it's available for applications where it's appropriate, yet can be skipped for applications like email where query speed is (for most users) more important.

Or maybe we leave that to a lower layer?

---

From: Douglas Otis <[email-masked]>
Date: Thu, 02 Sep 2010 16:24:57 -0700

On 9/2/10 4:15 PM, J.D. Falk wrote:
> > Depends on the applications I guess. Probably not a concern if an
> > MTA is asking about mail sender/author/whatever related
>  Ahh, yeah, that makes sense.  I wonder if there's a way to do this
>  such that it's available for applications where it's appropriate, yet
>  can be skipped for applications like email where query speed is (for
>  most users) more important.
>

Why suggest email can't use the strategy taken in safe browsing?  Many 
of our larger customers insisted they wanted full transfers of 
reputation information rather than individually querying each source, in 
the interest of speed and network resources.  Safe browsing allows 
updates to bulk information to be in the order of importance, in a form 
that also protects the reputation service.

-Doug