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.