![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
> From: John Martin <jmartin at netapp.com> > There has been a lot of discussion about the problems associated with > so-called "interception proxies". This discussion is very much within the > charter of the WREC WG. In fact, we even have a current draft whose sole > purpose is to document such problems. > > The known problems draft is at: draft-ietf-wrec-known-prob-01.txt > > This is the first of two very useful documents being produced by WREC; the > first, a taxonomy of terminology is available as: > draft-ietf-wrec-taxonomy-03.txt; I would suggest you read this first. The problems draft is interesting and depressing. All of the problems listed are technical nits. If you assume that "traffic redirection" and an "interception proxy" are good things, then you might well worry about the "lack of HTTP/1.1 compliance for proxy caches" or whether "interception proxies break client cache directives." You will not question their desirability or even their long term utility in the face of actions by users to protect their privacy or defend against censorship. You won't even worry about what's going to hit the fan when the big advertisers realize that their wonderful ads are being filtered and overwritten with other people's ads by interception proxies. I don't know whether to be depressed, encouraged, or neutral that WREC seems to not be about port 25 traffic redirection and interception proxies, such as AOL's effort. That there is no mention of the problems that IP fragmentation can cause interception proxies is depressing. > To join WREC, use the following: > mailto:wrec-request at cs.utk.edu?Subject=subscribe > > ...or send a note to wrec-request at cs.utk.edu with "subscribe" in the subject. > > I suggest we move this particular discussion to WREC. Joining that mailing list would not be useful, prudent, or honest for people with sentiments like mine. Moving the question of the wisdom of such proxies to WREC would be equivalent to moving the question of the wisdom of wiretapping to the wiretapping working group. At best the group WG consensus can be predicted. At worst, the discussion would legitimately be considered disruptive and irrelevant. It appears that the WREC working group is doing exactly as someone lamented a day or two ago about working groups in general, and not considering the question of whether the mechanisms they are working are good ideas in the larger scheme of things. WREC is only concerned with making them as good as possible. (Yes, I checked recent months of the archives at ftp://cs.utk.edu/pub/wrec/) It is interesting, but consistent with that observation that the problems draft contains no mention of problems should clients use end to end encryption or even just authentication with message authentication codes that care about the current time or the particular client. I don't know what to think of the absence of the string "https" in all three drafts. The passing, convoluted reference to encryption and SSL in section 9.2.2 of the taxonomy draft confuses me. If I were optimistic, I would hope that the taxonomy document is the wrong location is the reason its privacy section is so shallow. Vernon Schryver vjs at rhyolite.com
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.