Re: IETF privacy policy - update
On Jul 16, 2010, at 12:59 AM, Martin Rex wrote: is very likely (if not certain) that right now the IETF is operating in violation of the European Union's Data Protection Directive, nope, never while they're in the U.S. National data protection laws do not apply for someone operating entirely in a different country. Without trying to response to your scattershot of assertions and attacks, I'll just ask: Where is the IETF meeting in 10 days? And citizens of what continent are most likely be walk-in registrants? And you think that the IETF is not subject to the laws in Europe? Good luck with that ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
Paul, You appear to be concerned about exposing the IETF to risk by the adoption of a privacy policy (but apologies if I am misunderstanding the concern you expressed). The absence of a privacy policy, however, actually increases risk to the IETF in at least three ways: 1. As a general matter, many organizations that interact with lots of people (especially collecting financial information from them) use a broad range of written policies to reduce risk, by plainly stating a position on an issue so that employees have clear guidance about how to act or respond in a given situation. Policies could be particularly useful (for example) during a busy crush of new in-person registrations for an IETF meeting, when there are lots of interactions with personal data but senior management may not be immediately available in-person to give guidance if an unusual situation arises. Having written policies in that kind of situation reduces risk. 2. We have many examples of leading banks, stores, and others mishandling credit card and other records, so unless the IETF has come up with some secret security sauce to eliminate all possibility of a human or technical screwup with personal info, there is clear risk that the IETF could mishandle data and be at the wrong end of a litigation. The IETF would likely face liability risk with or without a privacy policy, but the fact that it could not even be bothered to have such a policy would certainly be used by the plaintiffs to argue for an increase in the damages that the IETF might have to pay. Having a written privacy policy would avoid this particular risk, and might even reduce the risk of a screwup in the first place. 3. And, although my legal expertise is limited to U.S. law, I think is very likely (if not certain) that right now the IETF is operating in violation of the European Union's Data Protection Directive, which requires that any entity that collects personal information must provide clear prior notice to affected individuals about the data collection. The EU is particularly sensitive when European citizens' data is collected by U.S. entities, which happens all of the time when European citizens register with the IETF's California-based administrative secretariat. (There is similar risk with regard to the California Online Privacy Protection Act, which specifically requires the posting of a privacy policy by entities that collect personal information online from California citizens - there is a good chance the law would not apply to the IETF, but there is some risk that it would.) Having a privacy policy would help the IETF comply with European law, which would reduce risk (and the uncertainly about the California law would be avoided). So if one's goal is to reduce risk to the IETF so the IETF is not harmed by legal liability, I think there are very strong arguments to have a privacy policy. Indeed, the legal-risk-related arguments in favor of a having a privacy policy are so strong that I believe the powers-that-be should move to promulgate such a policy even if there is not consensus in the broader IETF community (just like, I assume, the powers-that-be have purchased a range of standard business insurance policies without ever having consulted the IETF community). The draft of a proposed privacy policy was submitted as an I-D and circulated to the ietf@ietf.org mailing list simply because that was suggested to be the most appropriate way for individual members of the IETF community to raise this issue. A decision to adopt a privacy policy is not one, IMO, that should rise or fall on a community hum (although in the end, I think there been more +1s than -1s put forward on this list). John On Jul 15, 2010, at 4:26 PM, Paul Hoffman wrote: At 3:36 PM +0100 7/15/10, Alissa Cooper wrote: If you have specific ideas of other spots where the document over- promises, a list would be appreciated. I can take further clarifications back to the secretariat or whoever the responsible party is. For me, the biggest over-promise is that someone reading the document might think that there is some remedy if the I* fails to live up to it. The line between principles and promises in your document is quite unclear. Very specifically: I don't want the IETF to adopt your document if it opens up an avenue for an aggrieved participant (which, in the IETF, is anyone who knows how to subscribe to a mailing list, even this one) can cause damage to the IETF if the IETF doesn't meet the promise in that person's eyes. If you feel that it is valuable to list privacy principles for an organization like the IETF, great. If you want the IETF to promise something that would cost us money or, possibly worse, much lost time from the I*, please don't move this forwards. There are already many reasons why some people don't participate in
Re: IETF privacy policy - update
Sam, Paul, I did not mean to misrepresent your positions. I honestly understood them to be as I stated, but I was wrong. My apologies for that. And yes, I agree with Paul that privacy policies are generally not worth all that much -- indeed, my organization (as well as, for example, the U.S. Federal Trade Commission and others) argue that we need stronger laws/regulations in the U.S. because of the failure of the privacy policy approach. We want data collectors to be much more responsible (legally and otherwise) on privacy. But privacy policies reflect the barest minimum that any responsible organization should do. It is depressing, at least to me, that the dominant argument on this issue on this list - expressed by respected community members - is that the IETF should not expend the cycles to do even this barest minimum. John On Jul 7, 2010, at 5:58 PM, Sam Hartman wrote: "John" == John Morris writes: John> Paul, Sam, I understand your arguments to bascially be "we've John> never had an internal privacy problem here at the IETF, and as John> far as I know no one decides not to participate because of the John> lack of a privacy policy, so we have no need to follow basic John> standards of privacy hygiene." This is not an accurate characterization of my argument. I substantially agree with Paul's message in response. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
Paul, Sam, I understand your arguments to bascially be "we've never had an internal privacy problem here at the IETF, and as far as I know no one decides not to participate because of the lack of a privacy policy, so we have no need to follow basic standards of privacy hygiene." What would you say to a network operator who maintains an open mail relay, but says "we've never had any spam abuse on my open relay, and as far as I know I have never lost any business because of my relay, and so I have no need to follow basic standards of SMTP hygiene (as set out in RFCs 2505 and 5321)"? I would say to the network operator that (a) open mail relays create a risk of abuse, (b) industry best practices discourage such relays to help minimize that risk, and so (c) unless you have a really really good reason to maintain an open relay, you should not do so. And if the network operator were a prominent participant in the industry, I would add that maintaining an open relay sets a really bad example for other industry players and developers. In the IETF privacy context, as far as I know, we have not had any significant internal privacy problems at the IETF, probably because the powers-that-be are generally pretty thoughtful, careful people. And I have no idea whether anyone was so put off by the lack of a privacy policy as to reduce their participation IETF -- probably no one (but that is pretty unknowable). But there is a risk -- indeed, as we see going into the next two IETF meetings, there is a growing risk -- that the IETF will be collecting information that could be misused, in ways that none of us can foresee now. A privacy policy would not eliminate that risk, but it would help to guide future efforts to minimize privacy risk, and it would tell IETF site visitors how much they are tracked, etc., should they decide to use the site. So I, at least, would say to the IETF that (a) not having a privacy policy increases the risk of a privacy mistake, (b) online best practices encourage having a privacy policy, and so (c) unless you have a really really good reason not to have a privacy policy, you should have one. And because lots of developers look to the IETF for guidance in their work, I think the IETF's lack of a policy sets a bad example. And I think it is possible that having a clear, public, and well- thought-out set of principles and policies to guide the IETF's collection, retention, and use of data might even reduce or at least constrain the debates we have on this list every year or two about IETF data collection and retention Thus, spending what you view as wasted cycles now may well reduce wasted cycles later. But even if it does not, I think any organization that promulgates a series of documents named "Best Current Practices" (and hopes that people will pay attention to them) should itself be prepared to follow widely accepted "best current practices" for its operations, even if the participants of the organization find those practices to be outside of the core work of the group. John On Jul 7, 2010, at 3:59 PM, Paul Hoffman wrote: At 3:49 PM -0400 7/7/10, Sam Hartman wrote: Generally when I look for an idea of whether work is a good idea I look for a clear statement of benefit. I'll admit that I don't find privacy policies so valuable that I think everyone should have one. So, I'll ask how will or work be improved or what problem are we running into that a privacy policy will solve? If that cannot clearly we be answered, we should not engage in this activity. At 3:51 AM + 7/7/10, John Levine wrote: I think we all agree that having a privacy policy would be desirable, in the sense that we are in favor of good, and opposed to evil. But I don't know what it means to implement a privacy policy, and I don't think anyone else does either. A privacy policy is basically a set of assertions about what the IETF will do with your personal information. To invent a strawman, let's say that the privacy policy says that registration information will be kept in confidence, and some newly hired clerk who's a little unclear on the concept gives a list of registrants' e-mail addresses to a conference sponsor so they can e-mail everyone an offer for a free IETF tee shirt. Then what happens? Is a privacy policy a contract, and if it is, what remedies do IETF participants have for non-performance? And if it's not, and there aren't remedies, what's the point? Thank you, Sam and John. Do some people not come to IETF meetings because of the current null privacy policy? Do they say less than they would have if we had a typical non-null policy? If either of those two are answered yes, would those people contribute better knowing that the IETF had a policy but no real way to enforce it other than by apologizing when it failed to follow the policy? If having a privacy policy, eve
Re: IETF privacy policy - update
Well, as someone who believes that *all* websites and online-operating organizations should have a clear and accessible privacy policy, I think it is beyond embarrassing that the IETF does not have one. As an organization that tries pretty hard to be sensitive to the privacy impacts of the technologies it creates, it is disappointing that the IETF does not itself meet even the most basic of privacy "best practices," that is, having a privacy policy. But I appreciate that others may view privacy policies as navel gazing. In this case, however, the gazing could be fairly short and focused -- there is already a draft policy that is in a second version, with an author who has sought to work closely with the powers- that-be to understand the IETF's current practices (and who is willing to finish that work). The most important thing that needs to be decided is "what form should a policy take," and I think there were a number of good ideas on that point on the list. So I would urge us to gaze into our navels just a little bit more to make this happen. On Jul 7, 2010, at 10:42 AM, Iljitsch van Beijnum wrote: On 7 jul 2010, at 16:32, John Morris wrote: And, if you indeed think that something is missing, perhaps you could suggest some language to address your concern, rather than just dismiss the entire effort. I think it's completely legitimate to question whether efforts like this are worth the resources they soak up. The first time I went to an IETF meeting I was shocked by the amount of talk about the internals of the IETF itself that went on. We should really try to minimize this navel gazing and only indulge in it when clearly needed, something that hasn't been shown to be the case here. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
The draft, and the message that you responded to (but failed to quote fully), says: Meeting registration information other than credit card information is permanently retained (including cancelled registrations). Credit card processing records are retained for 18 months. This seems to address precisely what you claim is missing: "the stuff that gets asked for during registration and payment" What "stuff" does this not address? And, if you indeed think that something is missing, perhaps you could suggest some language to address your concern, rather than just dismiss the entire effort. On Jul 7, 2010, at 10:14 AM, Iljitsch van Beijnum wrote: On 7 jul 2010, at 14:02, Alissa Cooper wrote: Data retention is addressed explicitly in section 5: What's missing? What I said: the stuff that gets asked for during registration and payment. Apparently I didn't notice the link to the IETF trust. However, I don't see the point of having a document like this if it only provides a subset of all information, there shouldn't be a separate privacy policy for the trust. Or perhaps it's better to just forego this effort, as spends a lot of text kicking in open doors. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
+1 on having a privacy policy in the first place +1 on this possible approach on the procedural questions (although other approaches migth well be fine): On Jul 6, 2010, at 4:11 AM, Alissa Cooper wrote: With that said, laying out the core of the policy in an RFC and then having a speedier mechanism to publish changes (which can also be incorporated into the core policy when the RFC publication schedule allows) seems like a decent option. +1 on the actual substance of the draft policy (which folks should still consider even as the process discussions take place): http://www.ietf.org/id/draft-cooper-privacy-policy-01.txt As I understand the draft, it is attempting to document what is actually happening with data in people's interactions with the IETF today. This documentation should happen sooner rather than later, and should happen in a formal manner. If people want to debate what SHOULD the practice be with regard to x or y type of data (e.g., what happens to meeting registration info), that is also an important discussion to have, but that type of discussion need not delay a formal documentation of current practice (and any such documentation can change if the practice is later changed). The core idea of a privacy policy is to inform users of current practice, and that should happen soon even if we know there may be changes after further discussions. John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: What was the April's Fool this year?
http://www.rfc-editor.org/rfc/rfc5513.txt On Apr 11, 2009, at 9:49 AM, Alexandru Petrescu wrote: Sorry I missed it, but what was the April's Fool draft this year? (if tools.ietf.org had date search feature...) I'm asking because we wrote here a funny draft but decided not to submit because it seemed too risky on a second lecture... Thanks, Alex ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: About IETF communication skills
At 11:57 PM +0100 7/31/08, <[EMAIL PROTECTED]> wrote: Of course then there is the clarity of terminology, so lets define journalist as someone who is paid to write articles for a publication and who is at IETF to do their dayjob. Whether or not the journalist also has a blog is irrelevant. This definition does exclude people like me who are not currently paid to write and who only write on things like blogs and mailing lists. Aside from my view that it would be unwise and counterproductive to try to exclude any type of journalist, you propose an unworkable and unrealistic distinction. As much as you may not like it (and as much as some "traditional" or "real" journalists and the companies that employ them certainly do not like it), journalism is radically transforming, and "real" reporters are dwindling in number and Internet-age reporters are exploding. There are "real" reporters who work on a freelance basis and are not paid until they write a story and (if they are lucky) place it. Should they be excluded because they are not on someone's payroll? There are bloggers who work full time for a corporation with one employee (themselves), and are compensated from advertising revenue -- an arrangement that (except for the number of employees) is remarkably similar to reporters who work for the New York Times. Are they in or out? I think you would find it impossible to draw a rational, fair line that allows in the people you prefer and excludes the rest. A much better approach would be for the IETF to move into the Internet age (vis-a-vis journalists) and figure out how to work with all journalists, rather than cling to an outdated conception of that profession. If some journalists are not getting it, we all collectively need to do a better job of educating them. If a blogger gets it wrong, then we can all correct the error (either on the original blog or other blogs), and readers will begin to figure out that the blogger does not know what he/she is talking about (and perhaps then the blogger will listen more carefully the next time around). And isn't it likely that the blogger will get it more wrong if we exclude him/her in the first place? My 2 cents John Morris [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Transparency/Openness of the IAOC
FWIW, it seems likely that at least some commercial contracts (for hotels, etc.) will get negotiated on paper or by fax, and so an "all paper correspondence" approach could be problematic. Certainly as an attorney there have been times that I have chosen to negotiate only in hardcopy (making it easier for me to control the document, or at least harder for the other side to take control of a document). Also, I can imagine that some people may hesitate to communicate with the IAOC if they know that the presumption is that EVERYthing they send to IAOC is posted on the public web. Think carefully about the possibility that a vendor (such as a hotel) may want to keep some final contract terms confidential as a competitive matter. Although I strongly support openness, you could end up in a situation where, effectively, the contract for a conference/hotel costs X if it remains confidential, but X+Y if the contract is a public document (not that the document is likely to say that in so many words, but vendors may withhold their most aggressive contract terms if those terms will become public). If the IETF chooses to require that all contracts be public, it should be aware of this possibility. John At 1:23 PM -0500 12/8/04, Scott Bradner wrote: this makes full sense (that the IETF community should have full access to SOWs, contracts and addenda to contracts) - that is different than saying that ALL correspondence should be posted on a public web site so the wording needs to be carefully done Scott - Date: Wed, 8 Dec 2004 13:00:43 -0500 To: [EMAIL PROTECTED] (Scott Bradner) From: Margaret Wasserman <[EMAIL PROTECTED]> Subject: Re: Transparency/Openness of the IAOC Cc: [EMAIL PROTECTED] Hi Scott, At 12:36 PM -0500 12/8/04, Scott Bradner wrote: >> Actually, I think that the IAOC should post all correspondence 1/ I took "all correspondence" to mean "all correspondence" But, when I said "all correspondence", I didn't mean _all_ correspondence... :-) Okay, so this obviously needs to be cleaned up a bit. What I'm after is that I think the IETF community should be able to see the actual contracts that we make with our service organizations and partners (maybe with some financial details omitted if necessary). I also think that we should be able to see any official addenda to the contracts. And, that we should be able to see registered correspondence that is received from anyone who expresses a grievance against us an/or threatens legal action, along with any response that the IETF sends to those things. For instance, we were sent a budget that included a proposed RFC Editor cost of ~$800,000. This cost is based on a Statement of Work (SOW) that was negotiated between the IAB and the RFC Editor. Do we (the IETF community) have access to that SOW? (I don't actually know the answer to this question, but I couldn't find it on a quick perusal of the IAB and RFC Editor web pages). Personally, I think that we should have access to that SOW and other similar documents. Does that make sense? Margaret ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]). ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
draft-morris-policy-considerations-00.txt
Thanks to those who responded off list to my solicitation of feedback on this I-D a couple of weeks ago. This draft suggests public policy considerations that the IETF should consider in making design decisions. The draft would really benefit from broad input. The abstract and link are below. I would like to discuss the draft with anyone interested who might be in Vienna next week. Just to give a target time and place, I plan to grab some coffee/pastry/fruit and meet in Hall GH on the Blue Level from 8:00 to 8:30 a.m. on Wednesday, July 16, and I invite anyone who wants to discuss this draft to stop by. If you know you plan to come, let me know off list (in case there is a groundswell to change the time or place). I'd also be happy to talk about this in a more bar oriented "bar bof" some evening. John A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Public Policy Considerations for Internet Design Decisions Author(s) : J. Morris, A. Davidson Filename: draft-morris-policy-considerations-00.txt Pages : 21 Date: 2003-6-24 This document suggests public policy questions that the IETF should consider and possibly address when developing new standards and protocols, and modifying or enhancing old standards and protocols. This document contains questions to be considered, as opposed to guidelines or rules that should in all cases be followed. This first draft provides a framework for identifying and discussing questions of public policy concern, and invites members of the IETF community to contribute to the questions and discussions raised here. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-morris-policy-considerations-00.txt
Seeking feedback on I-D discussing "public policy considerations"
As some of you may have noticed, last week we submitted an Internet-Draft entitled "Public Policy Considerations for Internet Design Decisions." The abstract and link are below. The draft uses the same basic approach as was used by the IAB in RFC 3426 on "General Architectural and Policy Considerations" -- our draft suggests questions relating to public policy concerns that should be considered in working on protocols, without suggesting that any particular answer or result should flow from the questions. The draft also advances an argument about why the IETF should try to be aware of public policy issues in the first place. This draft is very much a "work in progress," and we welcome input, suggestions, criticism, etc. In particular, the draft would benefit from additional concrete examples of public policy issues that have cropped up in the past. Send feedback to [EMAIL PROTECTED] (or for the moment to the ietf list if it is a broader comment). If there is enough feedback and interest, we could set up a separate mailing list to discuss the draft. John also would be interested in getting together for a "bar bof" in Vienna with anyone interested in commenting on or contributing to the draft -- e-mail if interested. Thanks for looking at this draft. John Morris & Alan Davidson A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Public Policy Considerations for Internet Design Decisions Author(s) : J. Morris, A. Davidson Filename: draft-morris-policy-considerations-00.txt Pages : 21 Date: 2003-6-24 This document suggests public policy questions that the IETF should consider and possibly address when developing new standards and protocols, and modifying or enhancing old standards and protocols. This document contains questions to be considered, as opposed to guidelines or rules that should in all cases be followed. This first draft provides a framework for identifying and discussing questions of public policy concern, and invites members of the IETF community to contribute to the questions and discussions raised here. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-morris-policy-considerations-00.txt
Re: The utilitiy of IP is at stake here
At 10:19 PM +0200 5/29/03, Anthony Atkielski wrote: John writes: In the US, ISPs are not, and never have been viewed, as common carriers. I recall a case involving CompuServe in which it was treated at least partially as a common carrier, not responsible for the content of its network. The Compuserve case went the general way you suggest, and the Prodigy case went the other way. Both cases predate the passage of 47 U.S.C. Section 230, which was a part of the Communicaitons Decency Act, which in turn was a part of the Telecommuncations Act of 1996. Section 230 was enacted specifically to reverse the holding of the Stratton Oakmont v. Prodigy decision, which did impose liability on Prodigy. >(1) Treatment of publisher or speaker No provider or user of an interactive computer service [read, an ISP] shall be treated as the publisher or speaker of any information provided by another information content provider. How is this reconciled with the DMCA? The DMCA does not in general make ISPs liable for copyright infringement by their customers, but instead puts certain takedown obligations on ISPs. So there is no conflict. John
Re: The utilitiy of IP is at stake here
At 6:30 AM +0200 5/29/03, Anthony Atkielski wrote: Tony writes: Not if it simultaneously wants protection from liability for any content that the customer might be sending. Now that I can fully agree with, although it's not an engineering issue. ISPs that simultaneously want common-carrier protection from liability AND the ability to finely dictate what types of traffic they will accept need to choose one or the other. Either you screen and restrict the traffic on your network, but you take full responsibility for whatever is passing over it, or you just provide raw bandwidth and you are shielded from any claims of impropriety in the use thereof. You can't have it both ways, as companies like Prodigy have discovered. FWIW, and not to drag us too far into a legal discussion, but the above is not correct for the United States. In the US, ISPs are not, and never have been viewed, as common carriers. And, as one can see in the on-going arguments made about the possibility that cable ISPs might interfere with content, ISPs in general have strongly resisted being treated as common carriers. They do not want to take on the obligations that common carrier status would bring. Having said that, ISPs in the US do have common carrier-like protection from liability for content of their customers and others -- but this protection from liability is by statute, not as a result of any common carrier status. Section 230(c)(1) of chapter 47 of the U.S. Code states: (1) Treatment of publisher or speaker No provider or user of an interactive computer service [read, an ISP] shall be treated as the publisher or speaker of any information provided by another information content provider. This protection from liability is in no way dependent on what restrictions an ISP places on its traffic. Thus, for purposes of this thread, if an ISP wants to "finely dictate what types of traffic they will accept" they can do so without loss of liability protection. John
Re: Fwd: Re: IP: Microsoft breaks Mime specification
At 8:49 AM -0800 1/23/02, Kyle Lussier wrote: > >If I become a bad vendor, then people in an IETF >WG can move to yank my logo. There should be a process for >the "yanking" of the logo that is very fair, and arguably >should happen over a period of time, be pretty lenient >and give vendors more than ample time to "do the right thing." > Whether or not the idea is good or bad, it is not really workable within the IETF structure. IETF working groups close down after they finish their work. So if the xyz WG spends two years developing the XYZ protocol gets in into an RFC, the xyz WG usually then ceases to exist, and their may not be any other WG with a special focus on the XYZ protocol. So there will not be any WG or other group that would be appropriate to "police" the use of the XYZ protocol. It also would not work for WGs, after they complete their chartered work, to continue to exist just to adjudicate compliance with the relevant protocol. The IESG supervisory structure already has its hands full and could not supervise an ever growing list of WGs, and in any event 95% to 100% of the people who formed the core of a given WG would move on to other "active" working groups. So the idea is not something that could be easily grafted onto the IETF as it now exists. John Morris -- John Morris // CDT // http://www.cdt.org/standards --
Re: CDT Calls on Internet Activists to Urge Support for FeingoldAmendments to Anti-Terrorism Bills Date: 10 Oct 2001 19:22:27 -0400
FYI, the text of the Feingold amendments is at: http://www.cdt.org/security/011011s1510feingold.pdf and a fact sheet circulated by the Senator's office is at: http://www.cdt.org/security/011011feingoldfactsheet.shtml John Morris CDT At 12:11 AM -0400 10/11/01, William Allen Simpson wrote: >More I haven't seen the proposed amendments yet. But this is a >broader call than just our Internet Engineering groups. > > Original Message >Date: Wed, 10 Oct 2001 17:31:05 -0400 >From: Ari Schwartz <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: CDT Calls on Internet Activists to Urge Support for Feingold >Amendments to Anti-Terrorism Bills >Sender: [EMAIL PROTECTED] >Reply-To: Ari Schwartz <[EMAIL PROTECTED]> > > >CDT has sent out a message to Internet activists across the country asking >them to urge their Senators to support Senator Russell Feingold's (D-WI) >amendments to the Senate Anti-Terrorism Bill. > >Sen. Feingold is planning to offer amendments Thursday morning that will >address some of the privacy concerns raised by the pending bills, by >requiring government surveillance to be more focused and subject to >meaningful judicial controls. > >The message sent to CDT's lists of activists; is available below; and is >posted on the CDT site. > > >- > >Dear Activist: > >Things are moving very fast on Capitol Hill. Legislation to expand >government surveillance will be considered by the Senate (and maybe the >House) on Thursday, October 11. > >In the Senate, Sen. Russ Feingold is planning to offer amendments Thursday >morning that will address some of the privacy concerns raised by the pending >bills, by requiring government surveillance to be more focused and subject >to meaningful judicial controls. CDT supports the Feingold amendments. > >You can make a difference. Call your Senators in Washington right away and >let them know that you think civil liberties should be part of the balance >as we move forward to protect our country from terrorism. Urge them to >support the Feingold privacy amendments > >BACKGROUND > >Following the horrendous attacks of September 11, it is clear that US anti- >terrorism efforts need to be improved. Unfortunately, there has been little >time to develop a response that is effective and does not unnecessarily >infringe civil liberties. Legislation moving quickly through Congress >involves some fundamental changes in the surveillance laws. Most of the >changes are not limited to terrorism cases, but concern all crimes and all >intelligence investigations. > >Among other things, the bills would: > >* Allow FBI to seize any and all stored records (medical records, >educational records, stored e-mail) in intelligence cases without a search >warrant. > >* Allow computer system operators to authorize government surveillance >without a court order (the computer trespasser provision). > >* Authorize roving taps in intelligence cases without clear guidelines, >allowing government to monitor pay phones, library computers, cell phones >without first determining who is using the device. > >* Allow secret searches (searches without notice at the time of the search) >in all criminal cases. > >* Extend government surveillance under minimal standards to broad categories >of Internet data - all "routing, addressing and signaling information" (the >"pen register" provision). > >For full background the current civil liberties issues with the bill, please >see CDT's latest policy post -- > http://www.cdt.org/publications/pp_7.10.shtml > >Also, the New York Times on October 10 explained the current situation in >the Senate and Sen Feingold's concerns-- > http://www.nytimes.com/2001/10/10/national/10RIGH.html > > >WHAT YOU CAN DO--MAKE YOUR VOICE HEARD > >1. Call your your Senators > > - Sen. XXX at (202) 224-3121 > >Tell the person who answers the phone that you hope your Senator will >support the Feingold privacy amendment to the terrorism bill, so that it >adequately protects civil liberties when giving the government new >surveillance powers. > >Use these words if you feel tongue-tied: > >Staffer: Hello, Sen. XXX's office. > >You: Hello. I'm a constituent calling to urge the Senator to support the >Feingold privacy amendments to the anti-terrorism bill. Government needs to >fight terrorism, but the bill fails to protect privacy. I'm concerned about >the provisions on Internet surveillance and roving wiretaps. I support the >Feingold amendments setting clear limits on government surveillance. > >Staffer: I'll tell the Senator. Thanks, bye! > >2
