ICANNWatch
 
  Inside ICANNWatch  
Submit Story
Home
Lost Password
Preferences
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
ICANNWatch FAQ
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)


     
    Privacy ENUM: Bad For Privacy, or Very Bad For Privacy?
    posted by michael on Monday February 24 2003, @12:03PM

    There's a lot happening with ENUM fairly quickly, and it's hard to keep track of half of it. Alas, one thing about ENUM seems pretty clear: as currently specified, ENUM's intersection with the DNS creates a major privacy problem for the average person. ENUM partisans tend to admit this in person, often even before being cornered. The trouble is, they keep pressing on trying to write standards without dealing with the problem. (All the more reason why WHOIS privacy issues matter so much!) Here -- I think -- is not just one case in point, but two, both of which dropped into my mailbox today: Internet-drafts for " Registration for enumservices voice and video" and for "IFAX service of ENUM". The two documents also provide an interesting stylistic contrast in methods of flagging the issue.



    Let's start with "Registration for enumservices voice and video." The Abstract says
    This document registers a group of 'enumservices' [2] to be used to indicate that the associated resources are capable of interactive media stream exchange.

    Specifically, the "enumservices" registered with this document are 'voice' and 'video' using the URI schemes 'sip:', 'h323:' and 'tel:'.

    For each service we're told
    "Security Considerations:
    There are no specific security issues with this 'enumservice'.
    However, the general considerations of section 6 apply.
    What, one wonders, are those "general considerations"? Well, it turns out there are a lot of them.
    6. Security Considerations

    DNS, as used by ENUM, is a global, distributed database. Thus any information stored there is visible to anyone anonymously. Whilst this is not qualitatively different from publication in a Telephone Directory, it does open the data subject to having "their" information collected automatically without any indication that this has been done or by whom.

    Such data harvesting by third parties is often used to generate lists of targets for unrequested information; in short, they are used to address "spam". Anyone who uses a Web-archived mailing list is aware that the volume of "spam" email they are sent increases when they post to the mailing list; publication of a telephone number in ENUM is no different, and may be used to send "junk faxes" or "junk SMS" for example.

    Many mailing list users have more than one email address and use "sacrificial" email accounts when posting to such lists to help filter out unrequested emails sent to them. This is not so easy with published telephone numbers; the PSTN E.164 number assignment process is much more involved and usually a single E.164 number (or a fixed range of numbers) is associated with each PSTN access. Thus providing a "sacrificial" phone number in any publication is not possible.

    Due to the implications of publishing data on a globally accessible database, as a principle the data subject MUST give their explicit informed consent to data being published in ENUM.

    In addition, they should be made aware that, due to storage of such data during harvesting by third parties, removal of the data from publication will not remove any copies that have been taken; in effect, any publication may be permanent.

    However, regulations in many regions will require that the data subject can at any time request that the data is removed from publication, and that their consent for its publication is explicitly confirmed at regular intervals.

    When placing a voice or video call via the PSTN or sending a message via the Public Land Mobile Network, the sender may be charged for this action. In both kinds of network, calling or messaging to some numbers is more expensive than sending to others; both networks have "premium rate" services that can charge considerably more than a "normal" call or message destination. As such, it is important that the end user be asked to confirm sending the message, and that the destination number be presented to them. It is the originating user's choice on whether or not to place a call to this destination number, but they SHOULD be shown the destination number so that they can make this decision

    Where voice or video terminals are configured to accept incoming calls, there SHOULD be an indication presented to the user that an incoming call is being offered. Particularly with some video systems, the terminal may be configured to "auto-accept" the call. In this case there MUST be an obvious indication presented to the calling user that this has been done.

    Systems configured to auto-accept audio/video calls that are sent to a number published in a global public directory may be used by unexpected individuals to check for the presence or otherwise of people for with a view to stealing property or other unwelcome acts. Whilst "security through obscurity" may have seemed acceptable when the access address was known to only a few, publication within ENUM removes the obscurity, so leaving (for example) a "WebCam" switched on after such publication is even less wise than in other situations.

    In addition to the specific security considerations given above, all security considerations given in RFC2916bis apply.

    Contrast all this with the far more cursory treatment in "IFAX service of ENUM":
    Security Consideration
    The Security Considerations section of [RFC2305] and [RFC2532] applies to this document. In addition, note that DNS records are public. Therefore the mapping between a telephone number and a specific email address is public.
    Even the short form ought to make you sit up and take notice.

     
      ICANNWatch Login  
    Nickname:

    Password:

    [ Don't have an account yet? Please create one. It's not required, but as a registered user you can customize the site, post comments with your name, and accumulate reputation points ("karma") that will make your comments more visible. ]

     
      Related Links  
  • ICANNWatch.org
  • IETF
  • RFC2916bis
  • RFC2305
  • RFC2532
  • ENUM
  • WHOIS privacy issues matter
  • Registration for enumservices voice and video
  • IFAX service of ENUM
  • More on Privacy
  • Also by michael
  •  
    This discussion has been archived. No new comments can be posted.
    ENUM: Bad For Privacy, or Very Bad For Privacy? | Log in/Create an Account | Top | 2 comments | Search Discussion
    Click this button to post a comment to this story
    The options below will change how the comments display
    Threshold:
    Check box to change your default comment view
    The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
    enumservice
    by Anonymous on Monday February 24 2003, @03:22PM (#11235)
    I notice the following domains are taken: enumservice.com, enumservices.com.
    [ Reply to This | Parent ]
    do-not-call
    by RFassett on Tuesday February 25 2003, @08:26AM (#11238)
    User #3226 Info | http://www.enum.info
    I thought I saw the other day a news highlight that that this (link below) is going to become an effort at the federal level by this summer...people will be able to opt-in to this "registry" at no charge:

    http://www.puc.state.tx.us/ocp/telephone/donotcall .cfm

    does not the solve the e-mail spam or potential sms abuse, but looks to address the PSTN portion (in the US), I think, relative to ENUM implementation?
    [ Reply to This | Parent ]


    Search ICANNWatch.org:


    Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
    You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com