Hiya,
On 12/16/2013 09:50 PM, Andrew Sullivan wrote:
I don't think I've made my point, so let me try again.
On Mon, Dec 16, 2013 at 09:32:29PM +0000, Stephen Farrell wrote:
And don't forget that we are not here saying that all IETF
protocols MUST be proof against pervasive monitoring - email
for example isn't and we're not going to stop sending mail.
Right, but the very same technical acts against an email stream are
either an attack or a service, depending on the stuation from the POV
of the users.
For instance, many businesses scan all mail that comes and goes
through the corporate servers in order to ensure certain legal
compliance requirements are satisfied.
The same style of scanning can be applied in an effort to look for
"terrorists" or whatever.
I claim that the first of these is not one of the forms of "attack",
as long as the users affected know that this is happening (because,
for example, the existence of the tool is disclosed as part of the
corporate policies). When governments or $bigprovider or whoever does
it without the user knowing, then it's an attack. But as written, the
draft currently classifies the first of these cases as an attack also.
I think that strains even the constrained meaning of "attack" as used
in this draft. (I could equally be persuaded that the document just
needs to embrace this odd consequence of the definition, and call it
out.)
Ah, now I'm getting your point. Sorry for being slow:-)
Yes, we could count your corporate mail scanning example as
something that fits the definition but also fits under the
"tension" statement and live with that. I think that's quite
tenable.
Or in the corporate case above you could reasonably say that
it doesn't fit the "very widespread" part of the definition
whereas the $bigprovider mail service is probably fairly
considered very widespread.
But even if you think both of the above approaches are wrong,
I don't think consent is the angle to take here for the reasons
stated.
As for Google analytics, I'm not familiar enough with how it
really works to say. (I'm in the 0.x% minority who run noscript
and ghostery, etc.:-)
*But*, all of the above is really thinking about specific
deployments. For us, as the IETF, the questions are more about
the protocols, which will probably be the same in numerous
deployments. So I think our WGs probably do need to think
about the topic in general and how to mitigate it. While
there may be use-case specific things done in some WGs,
those are relatively uncommon. (Or maybe I'm getting the
wrong end of your stick again:-)
S.