ICANN participation

The Optical Network Terminal (ONT) is the piece of equipment at the end of the Fiber to the Home (FttH) network; the connection to the premises. From here the various services can be delivered to the end-users.

In Australia the FttH infrastructure company NBN Co is in favour of having the ONT on the outside of the premises, as that would be the cheapest option and would also allow for easier maintenance.

Only in multi-dwelling buildings the ONT will most probably be installed within each unit.

One of the more problematic issues here is how one goes about bringing electric power to the ONT. An interesting solution could include cooperation with the electricity company, which could arrange that and at the same time use it for its smart meter rollout.

But this might be the easiest problem to solve.

Providing access from the outside ONT to the interior of a dwelling represents a more serious problem. First of all there are the technical issues such as drilling through walls, but also issues relating to how one goes about powering and grounding the terminal equipment Recently this has become somewhat simplified, through the use of one of several IEEE Power over Ethernet (PoE) standards, assuming the provider and its vendor both support it.

But also this is still reasonably simple to resolve.

The real issue is who is going to do the job? Will it be DIY house-owners, regulated installers, the first telco to arrive on the scene, the utility to install a smart meter or the healthcare organisation that has a patient to monitor—or perhaps the council needs to be involved?

If this is not carefully thought through it could amount to opening a Pandora's box. There are legal issues, safety issues, security issues and, perhaps most importantly, financial issues.

The NBN is a national government infrastructure project and people will expect to be able to use that service. If it is placed outside the building for many people it might just as well have been installed in the next city—it is not going to provide access. There is no doubt that some users will be happy to pay for this; however most people will have major issues with it.

On the supply side, once the connection is inside it will be much easier for providers to offer their services. So will the first one to offer a service have to pay the total cost of bringing the connection inside? Again I can foresee many disputes.

People are beginning to understand the utility function of broadband. When one starts looking at how other access to such services is managed it quickly becomes evident that many solutions, in one way or another, involve a regulated connection charge, a council rate, a government tax or combinations of these.

These might be unpopular political issues to discuss but once you start moving in this direction these are the consequences and they need to be addressed upfront. If NBN Co has its way and the ONT is placed outside premises then the government will have to formulate a policy on how that connection gets inside the dwellings.

Written by Paul Budde, Managing Director of Paul Budde Communication

Follow CircleID on Twitter

More under: Access Providers, Broadband, Telecom

There has been a lot of talk about IDNs here and elsewhere but what does the reality look like for a plain user?

As a test, I randomly choose 28 domains from Alexa's top 100 Sites and tried to create a user account with the email address user@宫殿.com.

The bleak result: only wikipedia.org accepted the IDN - and later on failed to send a verification ping - all other rejected the email address.

IDN domains have standardized since March 2003 (RFC 3490) but as far as I know only one major email provider actually supports IDNs flawlessly…

The tested domains in alphabetic order were: adobe.com, amazon.com, bing.com, blogger.com, cnet.com, cnn.com, conduit.com, craigslist.org, dailymotion.com, deviantart.com, ebay.com, facebook.com, hi5.com, imageshack.us, imdb.com, linkedin.com, live.com, livejournal.com, mediafire.com, megaupload.com, mininova.org, myspace.com, nytimes.com, photobucket.com, twitter.com, wikipedia.org, wordpress.com, youtube.com

Written by Th. Kühne

Follow CircleID on Twitter

More under: DNS, Domain Names, Email, Multilinguism, Top-Level Domains

There has been a lot of talk about IDNs here and elsewhere but what does the reality look like for a plain user?

As a test, I randomly choose 28 domains from Alexa's top 100 Sites and tried to create a user account with the email address user@宫殿.com.

The bleak result: only wikipedia.org accepted the IDN - and later on failed to send a verification ping - all other rejected the email address.

IDN domains have standardized since March 2003 (RFC 3490) but as far as I know only one major email provider actually supports IDNs flawlessly…

The tested domains in alphabetic order were: adobe.com, amazon.com, bing.com, blogger.com, cnet.com, cnn.com, conduit.com, craigslist.org, dailymotion.com, deviantart.com, ebay.com, facebook.com, hi5.com, imageshack.us, imdb.com, linkedin.com, live.com, livejournal.com, mediafire.com, megaupload.com, mininova.org, myspace.com, nytimes.com, photobucket.com, twitter.com, wikipedia.org, wordpress.com, youtube.com

Written by Th. Kühne

Follow CircleID on Twitter

More under: DNS, Domain Names, Email, Multilinguism, Top-Level Domains

I tend to chuckle at every new proclamation that email is dead. Google Wave won't kill it. Twitter and Facebook aren't killing it; they're using it. RSS didn't kill it. Instant messaging didn't kill it. "Push media" (remember that?) didn't kill it. AOL and Compuserve and Prodigy didn't kill it; they joined it. And before that, usenet and email lived happily side-by-side.

Over the years the Coalition Against Unsolicited Commercial Email (CAUCE), the world's oldest and largest email advocacy organization, has also predicted the death of email. Some day, we've said, we will reach a tipping point where spam finally makes email unusable for regular people. And for any people who doesn't have good spam filters, that's already happened. Avoiding email's death by spam has given rise to the spam filtering & security industry, and the equally powerful mailbox hosting industry. It has elevated open source projects like SpamAssassin from curiosities to necessities. I've lost count of the number of hardcore geeks who've finally given up on running their own severs, and moved their personal mail to Gmail. Through these efforts, and these small personal concessions, email survives.

But it's not the same, and I'm left wondering if a part of email has died.

When CAUCE started up in the mid-nineties, we got some flak for being against unsolicited commercial email instead of all bulk email. We made that choice partly because we've always advocated for strong, intelligently crafted anti-spam laws, and legislators—particularly in the United States—are more willing to restrict commercial speech than non-commercial speech. But it's also because not all bulk email is spam; there are lots of non-commercial, non-spammy reasons to send the same message to a whole bunch of people.

We did that ourselves recently, alerting our members and supporters to the debate over Canada's proposed anti-spam bill, C-27. Some of the messages bounced because the email address was no longer valid, no surprise given how long it's been since there was anything exciting for us to tell them. Some—we don't know how much—was caught in spam filters, though few would argue that a message sent from a venerable anti-spam organization to our willing subscribers is spam.

Along with the filtering and hosting industries, another new field has sprung up in response to spam. They call their work "deliverability," and have developed tools which attempt to determine whether a message will be successfully delivered to the intended recipients. Some will go as far as sending a messages through popular spam filters to see if it'll get caught, or calling mailbox providers to beg for the mail to be allowed through. The old-time anti-spam community would've said this is the domain of spammers, but to many people and companies who are trying to send bulk non-spam mail today, it feels like a necessity.

(In the interests of transparency I should mention that CAUCE is sponsored in part by a company which offers deliverability-related products, and some of our board members work in that field.)

So we've got filters battling spam, and now deliverability wonks battling filters. But the deliverability industry is primarily only interested in delivering marketing email—in other words, solicited commercial bulk email. The Messaging Anti-Abuse Working Group (MAAWG) published a study this past summer which reminded us that, to actual humans, marketing is far from the most important kind of email. But there's no doubt that it's part of the email experience.

With that battle going on, bulk email—marketing and otherwise—may indeed on the verge of dying. Increasing spam leads to increasing filtering leads to increasing deliverability problems, but it's not the filters that created the problem. What's killing it, ironically, is that bulk email was never supposed to exist in the first place. At the most basic technical level, email is like traditional marriage: from one email address, to one email address. The author can include more than one recipient, but the underlying systems deliver the message to each recipient's mailbox as a new, separate transaction. In this way, the concept of "bulk email" is nearly identical to bulk postal mail—you may only be pressing the "send" button once, but the sending process happens multiple times, across many separate instances.

Other technologies are much, much better at disseminating information from one author to multiple willing recipients. RSS, which is really just another way to access content from the web, does it quite well. So do social networking sites like Facebook. And Twitter, with its culture of "re-tweeting" other peoples' messages to disseminate them further, is perfect.

Our experience with the C-27 effort was that email got the message out a little bit, with little visible effect—and if we'd wanted to, we could've spent countless hours tracking down deliverability issues. The CAUCE page on Facebook got some attention. Our Twitter follower count grew quickly without much effort on our part, and our messages there (to our surprise) were received directly by the offices of some of the Members of Parliament we were trying to reach.

What got the most attention wasn't even our doing. On Boing Boing, Cory Doctorow published a quote from Michael Geist's article about the copyright lobby's attempts to remove the anti-malware provisions of C-27, and that got picked up. In other words: what worked best was traditional, one-to-many news about an exciting and urgent topic—updated in format, but not in form.

While email between human beings lives on, it's possible that bulk email is dying, as older publishing paradigms—now supported by new technology—repeatedly prove themselves much more effective for broadcast communication.

(This article was originally published at cauce.org.)

Written by J.D. Falk, Director of Product Strategy at Return Path

Follow CircleID on Twitter

More under: Email, Spam

I tend to chuckle at every new proclamation that email is dead. Google Wave won't kill it. Twitter and Facebook aren't killing it; they're using it. RSS didn't kill it. Instant messaging didn't kill it. "Push media" (remember that?) didn't kill it. AOL and Compuserve and Prodigy didn't kill it; they joined it. And before that, usenet and email lived happily side-by-side.

Over the years the Coalition Against Unsolicited Commercial Email (CAUCE), the world's oldest and largest email advocacy organization, has also predicted the death of email. Some day, we've said, we will reach a tipping point where spam finally makes email unusable for regular people. And for any people who doesn't have good spam filters, that's already happened. Avoiding email's death by spam has given rise to the spam filtering & security industry, and the equally powerful mailbox hosting industry. It has elevated open source projects like SpamAssassin from curiosities to necessities. I've lost count of the number of hardcore geeks who've finally given up on running their own severs, and moved their personal mail to Gmail. Through these efforts, and these small personal concessions, email survives.

But it's not the same, and I'm left wondering if a part of email has died.

When CAUCE started up in the mid-nineties, we got some flak for being against unsolicited commercial email instead of all bulk email. We made that choice partly because we've always advocated for strong, intelligently crafted anti-spam laws, and legislators—particularly in the United States—are more willing to restrict commercial speech than non-commercial speech. But it's also because not all bulk email is spam; there are lots of non-commercial, non-spammy reasons to send the same message to a whole bunch of people.

We did that ourselves recently, alerting our members and supporters to the debate over Canada's proposed anti-spam bill, C-27. Some of the messages bounced because the email address was no longer valid, no surprise given how long it's been since there was anything exciting for us to tell them. Some—we don't know how much—was caught in spam filters, though few would argue that a message sent from a venerable anti-spam organization to our willing subscribers is spam.

Along with the filtering and hosting industries, another new field has sprung up in response to spam. They call their work "deliverability," and have developed tools which attempt to determine whether a message will be successfully delivered to the intended recipients. Some will go as far as sending a messages through popular spam filters to see if it'll get caught, or calling mailbox providers to beg for the mail to be allowed through. The old-time anti-spam community would've said this is the domain of spammers, but to many people and companies who are trying to send bulk non-spam mail today, it feels like a necessity.

(In the interests of transparency I should mention that CAUCE is sponsored in part by a company which offers deliverability-related products, and some of our board members work in that field.)

So we've got filters battling spam, and now deliverability wonks battling filters. But the deliverability industry is primarily only interested in delivering marketing email—in other words, solicited commercial bulk email. The Messaging Anti-Abuse Working Group (MAAWG) published a study this past summer which reminded us that, to actual humans, marketing is far from the most important kind of email. But there's no doubt that it's part of the email experience.

With that battle going on, bulk email—marketing and otherwise—may indeed on the verge of dying. Increasing spam leads to increasing filtering leads to increasing deliverability problems, but it's not the filters that created the problem. What's killing it, ironically, is that bulk email was never supposed to exist in the first place. At the most basic technical level, email is like traditional marriage: from one email address, to one email address. The author can include more than one recipient, but the underlying systems deliver the message to each recipient's mailbox as a new, separate transaction. In this way, the concept of "bulk email" is nearly identical to bulk postal mail—you may only be pressing the "send" button once, but the sending process happens multiple times, across many separate instances.

Other technologies are much, much better at disseminating information from one author to multiple willing recipients. RSS, which is really just another way to access content from the web, does it quite well. So do social networking sites like Facebook. And Twitter, with its culture of "re-tweeting" other peoples' messages to disseminate them further, is perfect.

Our experience with the C-27 effort was that email got the message out a little bit, with little visible effect—and if we'd wanted to, we could've spent countless hours tracking down deliverability issues. The CAUCE page on Facebook got some attention. Our Twitter follower count grew quickly without much effort on our part, and our messages there (to our surprise) were received directly by the offices of some of the Members of Parliament we were trying to reach.

What got the most attention wasn't even our doing. On Boing Boing, Cory Doctorow published a quote from Michael Geist's article about the copyright lobby's attempts to remove the anti-malware provisions of C-27, and that got picked up. In other words: what worked best was traditional, one-to-many news about an exciting and urgent topic—updated in format, but not in form.

While email between human beings lives on, it's possible that bulk email is dying, as older publishing paradigms—now supported by new technology—repeatedly prove themselves much more effective for broadcast communication.

(This article was originally published at cauce.org.)

Written by J.D. Falk, Director of Product Strategy at Return Path

Follow CircleID on Twitter

More under: Email, Spam

Google plans to upgrade its YouTube video streaming Web site to provide support for IPv6, a long-anticipated upgrade to the Internet's main communications protocol. Google already supports IPv6 with its Search, Alerts, Docs, Finance, Gmail, Health, iGoogle, News, Reader, Picasa, Maps and Wave products. Google's Chrome operating system—whose source code was released this week—supports IPv6, as does its Android platform for mobile devices.

Read full story: Network World

Follow CircleID on Twitter

More under: IPv6

Google plans to upgrade its YouTube video streaming Web site to provide support for IPv6, a long-anticipated upgrade to the Internet's main communications protocol. Google already supports IPv6 with its Search, Alerts, Docs, Finance, Gmail, Health, iGoogle, News, Reader, Picasa, Maps and Wave products. Google's Chrome operating system—whose source code was released this week—supports IPv6, as does its Android platform for mobile devices.

Read full story: Network World

Follow CircleID on Twitter

More under: IPv6

Some members of Congress have gotten extremely upset about peer-to-peer filesharing. Even the New York Times has editorialized about the issue. The problem of files leaking out is a real one, but the bills are misguided.

Fundamentally, the real issue is that files are being shared without the user intending that result. This is not a weakness unique to peer-to-peer software; more or less any mechanism for publishing files can do that. The real problem is that the targeted software—whatever it is; the news stories full of outrage haven't identified which package or packages are implicated—is bad software, either because they share files the user hadn't intended or because they make it too hard for the user to understand what will happen. Given the sub rosa nature of much peer-to-peer software, perhaps this is not surprising; developing good software is remarkably difficult. Perhaps Congress should instead decriminalize sharing of music and video…

I digress. The real issue I'm addressing is bad legislation. Quite apart from my general concerns, the bills are just poorly drafted.

The first bill, H.R. 1319, is in many ways more reasonable: it mandates notice to the user of what is happening, and bars software that is difficult to remove. However, it stumbles badly when trying to define peer-to-peer software:

the term `peer-to-peer file sharing program' means computer software that allows the computer on which such software is installed--

(A) to designate files available for transmission to another computer;

(B) to transmit files directly to another computer; and

(C) to request the transmission of files from another computer.

As best I can tell, any web browser is covered by that definition.

The newer bill, H.R. 4098, does a much better job on a workable definition, though it's fun to try to twist it into knots, too. I particularly like the way software "designed primarily to operate as a server that is accessible over the Internet using the Internet Domain Name system" is not covered; who would have thought that the DNS had such mystical shielding properties?

The problem with H.R. 4098 is that it bans the wrong thing. Yes, NASA's use of BitTorrent would be permitted because it is "instrumental in completing a particular task or project that directly supports the agency's overall mission", but NASA employees probably wouldn't be allowed to download such files on their home computers because the bill seeks to block "the download, installation, or use by Government employees and contractors of such software on home or personal computers as it relates to telework and remotely accessing Federal computers, computer systems, and networks". In other words, you can either view such files or you can save the government money by using your own computer to work from home.

I should add a personal disclaimer: I, like most professors in the sciences and engineering, receive substantial government grants and contracts; that technically makes me a government contractor, as best I can tell. Am I covered? My students who receive stipends from such grants?

For those who are wondering if this bill is really just another ploy by a paid shill for the content industry, campaign finance records do not seem to support the notion. According to OpenSecrets.org, while Rep. Towns (the introducer) did indeed receive considerable campaign funding from from PACs associated with content owners, he has also received a lot of money from PACs associated with companies like Verizon that have not been particularly sympathetic to the content industry's demands. I do not think that that claim is supported by the data.

Overall, what we have here is too much firepower being aimed in the wrong direction. If the incidents are taking place from home computers, the solution is to provide government employees with the government-owned equipment—and government-provided software, support, and system administration—to let them do their jobs properly. Using poorly managed or maintained machines carries many more security risks than just peer-to-peer software; I could make a very good case that such software is the least of the security problems. If the incidents have taken place on office computers, the issue is really a management problem: employees are making more than the normal and acceptable de minimus personal use of their employer's equipment. There is also likely a problem with the quality of systems administration in such organizations. Again, those issues pose many more risks. These are real problems; focusing on peer-to-peer software won't address them.

Written by Steven Bellovin, Professor of Computer Science at Columbia University

Follow CircleID on Twitter

More under: DNS, P2P, Policy & Regulation

Some members of Congress have gotten extremely upset about peer-to-peer filesharing. Even the New York Times has editorialized about the issue. The problem of files leaking out is a real one, but the bills are misguided.

Fundamentally, the real issue is that files are being shared without the user intending that result. This is not a weakness unique to peer-to-peer software; more or less any mechanism for publishing files can do that. The real problem is that the targeted software—whatever it is; the news stories full of outrage haven't identified which package or packages are implicated—is bad software, either because they share files the user hadn't intended or because they make it too hard for the user to understand what will happen. Given the sub rosa nature of much peer-to-peer software, perhaps this is not surprising; developing good software is remarkably difficult. Perhaps Congress should instead decriminalize sharing of music and video…

I digress. The real issue I'm addressing is bad legislation. Quite apart from my general concerns, the bills are just poorly drafted.

The first bill, H.R. 1319, is in many ways more reasonable: it mandates notice to the user of what is happening, and bars software that is difficult to remove. However, it stumbles badly when trying to define peer-to-peer software:

the term `peer-to-peer file sharing program' means computer software that allows the computer on which such software is installed--

(A) to designate files available for transmission to another computer;

(B) to transmit files directly to another computer; and

(C) to request the transmission of files from another computer.

As best I can tell, any web browser is covered by that definition.

The newer bill, H.R. 4098, does a much better job on a workable definition, though it's fun to try to twist it into knots, too. I particularly like the way software "designed primarily to operate as a server that is accessible over the Internet using the Internet Domain Name system" is not covered; who would have thought that the DNS had such mystical shielding properties?

The problem with H.R. 4098 is that it bans the wrong thing. Yes, NASA's use of BitTorrent would be permitted because it is "instrumental in completing a particular task or project that directly supports the agency's overall mission", but NASA employees probably wouldn't be allowed to download such files on their home computers because the bill seeks to block "the download, installation, or use by Government employees and contractors of such software on home or personal computers as it relates to telework and remotely accessing Federal computers, computer systems, and networks". In other words, you can either view such files or you can save the government money by using your own computer to work from home.

I should add a personal disclaimer: I, like most professors in the sciences and engineering, receive substantial government grants and contracts; that technically makes me a government contractor, as best I can tell. Am I covered? My students who receive stipends from such grants?

For those who are wondering if this bill is really just another ploy by a paid shill for the content industry, campaign finance records do not seem to support the notion. According to OpenSecrets.org, while Rep. Towns (the introducer) did indeed receive considerable campaign funding from from PACs associated with content owners, he has also received a lot of money from PACs associated with companies like Verizon that have not been particularly sympathetic to the content industry's demands. I do not think that that claim is supported by the data.

Overall, what we have here is too much firepower being aimed in the wrong direction. If the incidents are taking place from home computers, the solution is to provide government employees with the government-owned equipment—and government-provided software, support, and system administration—to let them do their jobs properly. Using poorly managed or maintained machines carries many more security risks than just peer-to-peer software; I could make a very good case that such software is the least of the security problems. If the incidents have taken place on office computers, the issue is really a management problem: employees are making more than the normal and acceptable de minimus personal use of their employer's equipment. There is also likely a problem with the quality of systems administration in such organizations. Again, those issues pose many more risks. These are real problems; focusing on peer-to-peer software won't address them.

Written by Steven Bellovin, Professor of Computer Science at Columbia University

Follow CircleID on Twitter

More under: DNS, P2P, Policy & Regulation

Some members of Congress have gotten extremely upset about peer-to-peer filesharing. Even the New York Times has editorialized about the issue. The problem of files leaking out is a real one, but the bills are misguided.

Fundamentally, the real issue is that files are being shared without the user intending that result. This is not a weakness unique to peer-to-peer software; more or less any mechanism for publishing files can do that. The real problem is that the targeted software—whatever it is; the news stories full of outrage haven't identified which package or packages are implicated—is bad software, either because they share files the user hadn't intended or because they make it too hard for the user to understand what will happen. Given the sub rosa nature of much peer-to-peer software, perhaps this is not surprising; developing good software is remarkably difficult. Perhaps Congress should instead decriminalize sharing of music and video…

I digress. The real issue I'm addressing is bad legislation. Quite apart from my general concerns, the bills are just poorly drafted.

The first bill, H.R. 1319, is in many ways more reasonable: it mandates notice to the user of what is happening, and bars software that is difficult to remove. However, it stumbles badly when trying to define peer-to-peer software:

the term `peer-to-peer file sharing program' means computer software that allows the computer on which such software is installed--

(A) to designate files available for transmission to another computer;

(B) to transmit files directly to another computer; and

(C) to request the transmission of files from another computer.

As best I can tell, any web browser is covered by that definition.

The newer bill, H.R. 4098, does a much better job on a workable definition, though it's fun to try to twist it into knots, too. I particularly like the way software "designed primarily to operate as a server that is accessible over the Internet using the Internet Domain Name system" is not covered; who would have thought that the DNS had such mystical shielding properties?

The problem with H.R. 4098 is that it bans the wrong thing. Yes, NASA's use of BitTorrent would be permitted because it is "instrumental in completing a particular task or project that directly supports the agency's overall mission", but NASA employees probably wouldn't be allowed to download such files on their home computers because the bill seeks to block "the download, installation, or use by Government employees and contractors of such software on home or personal computers as it relates to telework and remotely accessing Federal computers, computer systems, and networks". In other words, you can either view such files or you can save the government money by using your own computer to work from home.

I should add a personal disclaimer: I, like most professors in the sciences and engineering, receive substantial government grants and contracts; that technically makes me a government contractor, as best I can tell. Am I covered? My students who receive stipends from such grants?

For those who are wondering if this bill is really just another ploy by a paid shill for the content industry, campaign finance records do not seem to support the notion. According to OpenSecrets.org, while Rep. Towns (the introducer) did indeed receive considerable campaign funding from from PACs associated with content owners, he has also received a lot of money from PACs associated with companies like Verizon that have not been particularly sympathetic to the content industry's demands. I do not think that that claim is supported by the data.

Overall, what we have here is too much firepower being aimed in the wrong direction. If the incidents are taking place from home computers, the solution is to provide government employees with the government-owned equipment—and government-provided software, support, and system administration—to let them do their jobs properly. Using poorly managed or maintained machines carries many more security risks than just peer-to-peer software; I could make a very good case that such software is the least of the security problems. If the incidents have taken place on office computers, the issue is really a management problem: employees are making more than the normal and acceptable de minimus personal use of their employer's equipment. There is also likely a problem with the quality of systems administration in such organizations. Again, those issues pose many more risks. These are real problems; focusing on peer-to-peer software won't address them.

Written by Steven Bellovin, Professor of Computer Science at Columbia University

Follow CircleID on Twitter

More under: DNS, P2P, Policy & Regulation

Since 16th Nov 09 Applications Processing for IDN ccTLDs Fast Track has been started. The countries and territories who are using non-English Language (nationwide) for official documentation or for community, are eligible to apply for a new country code top level domain name (ccTLD) in their own Native Language through a designated manager. Designated Manager has to submit online application to M/s ICANN for the new name script. Name Script should be meaningful, minimum 2 letter and maximum 63 letters long.

Native Language Community will be able to register their domain names within the next 6 months.

In first round, maximum 50 IDN ccTLDs Applications are expected. However, Designated Manager has to decide the Name Script minimum characters which can serve the purpose. for example مصر، امارات، السعودیۃ do not have any short abbreviation to represent the name of their country. However like Pakistan, it has پاک. (.PAK) instead of using full name پاکستان. abbreviation may reduce the losses of about 1000 men hours daily.

Written by Imran Ahmed Shah, IT Consultant

Follow CircleID on Twitter

More under: Domain Names, Domain Registries, ICANN, Internet Governance, Multilinguism, Top-Level Domains

Since 16th Nov 09 Applications Processing for IDN ccTLDs Fast Track has been started. The countries and territories who are using non-English Language (nationwide) for official documentation or for community, are eligible to apply for a new country code top level domain name (ccTLD) in their own Native Language through a designated manager. Designated Manager has to submit online application to M/s ICANN for the new name script. Name Script should be meaningful, minimum 2 letter and maximum 63 letters long.

Native Language Community will be able to register their domain names within the next 6 months.

In first round, maximum 50 IDN ccTLDs Applications are expected. However, Designated Manager has to decide the Name Script minimum characters which can serve the purpose. for example مصر، امارات، السعودیۃ do not have any short abbreviation to represent the name of their country. However like Pakistan, it has پاک. (.PAK) instead of using full name پاکستان. abbreviation may reduce the losses of about 1000 men hours daily.

Written by Imran Ahmed Shah, IT Consultant

Follow CircleID on Twitter

More under: Domain Names, Domain Registries, ICANN, Internet Governance, Multilinguism, Top-Level Domains

Spam is not about who sent it, it's about who benefits from it. For a moment forget everything you know about filters, zombie PCs, firewalls, spoofing, viruses, beisyan algorithms, header forgery, botnets, or blacklists. These are all methods for sending spam or preventing spam delivery. None of these explain why spam is sent and for far too long all the attention has been paid to the effects and not the driving force. Under the endless onslaught of junk mail it is easy to feel that the goal of the game is send spam and annoy us all. But this isn't the goal. The goal of spam is a transaction. Motivation not method.

A transaction in this sense could be many things. It can refer to the traditional meaning of the word: someone voluntarily exchanging some kind of money for a product or service, like buying illicit products from shady. In terms of cybercrime it can also refer to the involuntary exchange of information, like the reveal of a password, credit card, or bank account information. It could mean that a virus was installed on your pc that opens it up to abuse. An email recipient could follow a link charges and advertising account, click-fraud. Or, a transaction could simply be that the recipient of the spam comes to believe that something is true and then acts on it. Examples of this being stock spam and urban legends. A consumer believes that a stock price will increase so they buy some. An email user believes a chain-hoax to be true so they forward it to more people. Sending spam is not a transaction, it's just an advertisement. The transaction only occurs when the spam recipient takes action or provides money, information, or access.

There are two broad categories of spam emails: ones that advertise a URL and ones that do not. Stock spam, degree mills, and advance fee scams (so-called 419 or Nigerian scams). For the purposes of this discussion we're focusing on the URL-based spam.

Transactions for products and services occur at websites. There is certainly a diversity of products advertised in spam but far and away the number one item: Drugs. Not heroin, cocaine or marijuana but illicit pharmaceuticals. This should not come as a surprise to anyone as Viagra has become synonymous with spam and vice-versa. But it's not just lifestyle drugs. Painkillers, psychotropics, anti-depressants, diabetics, and pretty much any drug that requires a prescription are being sold on domains sponsored by ICANN Accredited Registrars. The only problem here is that these drugs are being sold without a prescription. No, the drugs do not come from Canada. Even though "Canada" is a favorite term for these websites the pills come from Turkey, Serbia, Moldova, and India. The medicine may be real or it may not be, but anyone consuming them is risking their health as well as giving money to organized crime.

Spam offers everything from septic tanks to prostitution, but illicit prescriptions are most of the problem. Rogue pharmacy is now at least at $100 Billion illicit industry and the Internet is driving its growth with absolute impunity.

Criminals hire spammers to promote websites where drugs are sold illegally. Because spammed websites are quickly discovered and complained about they are often taken down soon after a spam campaign. To deal with this problem drug traffickers use multiple layers of linked and redirected domains that are not spammed, stay intact and endure. Spammers may in fact be the Registrars best customers. Whereas the ordinary business may buy one or two domain names, spammers buy thousands and then dump them. The Registrar can then resell the defunct domain names, so they get paid twice for the same item.

Some reading this may think that Registrars are the fall guy here as it is impossible to track the activity of the thousands of domain names they sponsor. Problem is, they have been specifically informed of which domains are conducting illegal activities multiple times. Some might wonder then who is KnujOn to tell a Registrar about fake pharmacy domains? Actually, our reports have been endorsed by the National Association of Boards of Pharmacy(NABP), The National Center on Addiction and Substance Abuse at Columbia University (CASA), The American Pharmacists Association (APhA), and the Partnership for Safe Medicines.

Regardless of our endorsements, if a Registrar receives information of an illicit pharmacy site sponsored by them from any consumer and does not investigate and terminate, that Registrar is now aiding criminals. If a Registrar continues to accept payment from the domain owner after being notified, they are then receiving money from organized crime.

Bottom line is that the Registrars have the authority and technical ability to terminate a domain, even though many claim they do not. Registrars have the power to stop rogue pharmacy domains. The illicit networks rely on stable domains just like any other business. However, until the Registrars are told to stop sponsoring illicit drug traffic they will continue to do so. It is a ridiculous dance that cannot go on much longer. This farce is going to come to an end. No more pointing fingers at the ISPs only, terminating a domain breaks the spam link and closes the transaction platform.

Written by Garth Bruen, Internet Fraud Analyst and Policy Developer

Follow CircleID on Twitter

More under: Cybercrime, Domain Names, Domain Registries, ICANN, Internet Governance, Law, Policy & Regulation, Spam, Top-Level Domains

Spam is not about who sent it, it's about who benefits from it. For a moment forget everything you know about filters, zombie PCs, firewalls, spoofing, viruses, beisyan algorithms, header forgery, botnets, or blacklists. These are all methods for sending spam or preventing spam delivery. None of these explain why spam is sent and for far too long all the attention has been paid to the effects and not the driving force. Under the endless onslaught of junk mail it is easy to feel that the goal of the game is send spam and annoy us all. But this isn't the goal. The goal of spam is a transaction. Motivation not method.

A transaction in this sense could be many things. It can refer to the traditional meaning of the word: someone voluntarily exchanging some kind of money for a product or service, like buying illicit products from shady. In terms of cybercrime it can also refer to the involuntary exchange of information, like the reveal of a password, credit card, or bank account information. It could mean that a virus was installed on your pc that opens it up to abuse. An email recipient could follow a link charges and advertising account, click-fraud. Or, a transaction could simply be that the recipient of the spam comes to believe that something is true and then acts on it. Examples of this being stock spam and urban legends. A consumer believes that a stock price will increase so they buy some. An email user believes a chain-hoax to be true so they forward it to more people. Sending spam is not a transaction, it's just an advertisement. The transaction only occurs when the spam recipient takes action or provides money, information, or access.

There are two broad categories of spam emails: ones that advertise a URL and ones that do not. Stock spam, degree mills, and advance fee scams (so-called 419 or Nigerian scams). For the purposes of this discussion we're focusing on the URL-based spam.

Transactions for products and services occur at websites. There is certainly a diversity of products advertised in spam but far and away the number one item: Drugs. Not heroin, cocaine or marijuana but illicit pharmaceuticals. This should not come as a surprise to anyone as Viagra has become synonymous with spam and vice-versa. But it's not just lifestyle drugs. Painkillers, psychotropics, anti-depressants, diabetics, and pretty much any drug that requires a prescription are being sold on domains sponsored by ICANN Accredited Registrars. The only problem here is that these drugs are being sold without a prescription. No, the drugs do not come from Canada. Even though "Canada" is a favorite term for these websites the pills come from Turkey, Serbia, Moldova, and India. The medicine may be real or it may not be, but anyone consuming them is risking their health as well as giving money to organized crime.

Spam offers everything from septic tanks to prostitution, but illicit prescriptions are most of the problem. Rogue pharmacy is now at least at $100 Billion illicit industry and the Internet is driving its growth with absolute impunity.

Criminals hire spammers to promote websites where drugs are sold illegally. Because spammed websites are quickly discovered and complained about they are often taken down soon after a spam campaign. To deal with this problem drug traffickers use multiple layers of linked and redirected domains that are not spammed, stay intact and endure. Spammers may in fact be the Registrars best customers. Whereas the ordinary business may buy one or two domain names, spammers buy thousands and then dump them. The Registrar can then resell the defunct domain names, so they get paid twice for the same item.

Some reading this may think that Registrars are the fall guy here as it is impossible to track the activity of the thousands of domain names they sponsor. Problem is, they have been specifically informed of which domains are conducting illegal activities multiple times. Some might wonder then who is KnujOn to tell a Registrar about fake pharmacy domains? Actually, our reports have been endorsed by the National Association of Boards of Pharmacy(NABP), The National Center on Addiction and Substance Abuse at Columbia University (CASA), The American Pharmacists Association (APhA), and the Partnership for Safe Medicines.

Regardless of our endorsements, if a Registrar receives information of an illicit pharmacy site sponsored by them from any consumer and does not investigate and terminate, that Registrar is now aiding criminals. If a Registrar continues to accept payment from the domain owner after being notified, they are then receiving money from organized crime.

Bottom line is that the Registrars have the authority and technical ability to terminate a domain, even though many claim they do not. Registrars have the power to stop rogue pharmacy domains. The illicit networks rely on stable domains just like any other business. However, until the Registrars are told to stop sponsoring illicit drug traffic they will continue to do so. It is a ridiculous dance that cannot go on much longer. This farce is going to come to an end. No more pointing fingers at the ISPs only, terminating a domain breaks the spam link and closes the transaction platform.

Written by Garth Bruen, Internet Fraud Analyst and Policy Developer

Follow CircleID on Twitter

More under: Cybercrime, Domain Names, Domain Registries, ICANN, Internet Governance, Law, Policy & Regulation, Spam, Top-Level Domains

On the final day of a four-day meeting, most government representatives expressed support for renewing the Internet Governance Forum's five-year mandate which ends next year. China did not. Chen Yin, the head of the Chinese delegation to the Internet Governance Forum, said yesterday that the IGF's mandate should not be continued without reforms. Below is the full text of his statement, taken from the official transcript here [PDF]. Video (with bad-quality audio in Chinese) can be found on YouTube here. I've added a few links so that the acronyms will make more sense to people who aren't professional Internet governance wonks:

Thank you, Mr. Chairman.

Thank you, Mr. Chairman.

Written by Rebecca MacKinnon, Assistant Professor, University of Hong Kong

Follow CircleID on Twitter

More under: Internet Governance

On the final day of a four-day meeting, most government representatives expressed support for renewing the Internet Governance Forum's five-year mandate which ends next year. China did not. Chen Yin, the head of the Chinese delegation to the Internet Governance Forum, said yesterday that the IGF's mandate should not be continued without reforms. Below is the full text of his statement, taken from the official transcript here [PDF]. Video (with bad-quality audio in Chinese) can be found on YouTube here. I've added a few links so that the acronyms will make more sense to people who aren't professional Internet governance wonks:

Thank you, Mr. Chairman.

Thank you, Mr. Chairman.

Written by Rebecca MacKinnon, Assistant Professor, University of Hong Kong

Follow CircleID on Twitter

More under: Internet Governance

ICANN has opened their new fast track process for "countries and territories that use languages based on scripts other than Latin" to get domain names that identify the country or territory in its own language. It's not clear to me what the policy is supposed to be for countries whose languages use extended Latin with accents and other marks that aren't in the ASCII set.

Any country that uses an extended Latin character set can use extended characters in 2LDs right now, and I can't offhand think of any whose current unaccented two-letter ccTLD isn't an adequate mnemonic for their name. But let's say that Serbia feels that .RS is kind of lame, so they apply for and get .Србија which is perfectly reasonable, since that's the Cyrillic character set.

Then Romania decides that .RO is too generic, so they ask for .România with the circumflex over the â, as it is properly spelled in Romanian. That's an IDN, so how can they say no?

Hey, say the Hungarians, they got their country names, we want .Magyar. Oh, no, that's ASCII, that will be $185,000 and a highly uncertain multi-year process. Really?

Written by John Levine, Author, Consultant & Speaker

Follow CircleID on Twitter

More under: Domain Names, ICANN, Multilinguism, Top-Level Domains

ICANN has opened their new fast track process for "countries and territories that use languages based on scripts other than Latin" to get domain names that identify the country or territory in its own language. It's not clear to me what the policy is supposed to be for countries whose languages use extended Latin with accents and other marks that aren't in the ASCII set.

Any country that uses an extended Latin character set can use extended characters in 2LDs right now, and I can't offhand think of any whose current unaccented two-letter ccTLD isn't an adequate mnemonic for their name. But let's say that Serbia feels that .RS is kind of lame, so they apply for and get .Србија which is perfectly reasonable, since that's the Cyrillic character set.

Then Romania decides that .RO is too generic, so they ask for .România with the circumflex over the â, as it is properly spelled in Romanian. That's an IDN, so how can they say no?

Hey, say the Hungarians, they got their country names, we want .Magyar. Oh, no, that's ASCII, that will be $185,000 and a highly uncertain multi-year process. Really?

Written by John Levine, Author, Consultant & Speaker

Follow CircleID on Twitter

More under: Domain Names, ICANN, Multilinguism, Top-Level Domains

ICANN has opened their new fast track process for "countries and territories that use languages based on scripts other than Latin" to get domain names that identify the country or territory in its own language. It's not clear to me what the policy is supposed to be for countries whose languages use extended Latin with accents and other marks that aren't in the ASCII set.

Any country that uses an extended Latin character set can use extended characters in 2LDs right now, and I can't offhand think of any whose current unaccented two-letter ccTLD isn't an adequate mnemonic for their name. But let's say that Serbia feels that .RS is kind of lame, so they apply for and get .Србија which is perfectly reasonable, since that's the Cyrillic character set.

Then Romania decides that .RO is too generic, so they ask for .România with the circumflex over the â, as it is properly spelled in Romanian. That's an IDN, so how can they say no?

Hey, say the Hungarians, they got their country names, we want .Magyar. Oh, no, that's ASCII, that will be $185,000 and a highly uncertain multi-year process. Really?

Written by John Levine, Author, Consultant & Speaker

Follow CircleID on Twitter

More under: Domain Names, ICANN, Multilinguism, Top-Level Domains

ICANN has opened their new fast track process for "countries and territories that use languages based on scripts other than Latin" to get domain names that identify the country or territory in its own language. It's not clear to me what the policy is supposed to be for countries whose languages use extended Latin with accents and other marks that aren't in the ASCII set.

Any country that uses an extended Latin character set can use extended characters in 2LDs right now, and I can't offhand think of any whose current unaccented two-letter ccTLD isn't an adequate mnemonic for their name. But let's say that Serbia feels that .RS is kind of lame, so they apply for and get .Србија which is perfectly reasonable, since that's the Cyrillic character set.

Then Romania decides that .RO is too generic, so they ask for .România with the circumflex over the â, as it is properly spelled in Romanian. That's an IDN, so how can they say no?

Hey, say the Hungarians, they got their country names, we want .Magyar. Oh, no, that's ASCII, that will be $185,000 and a highly uncertain multi-year process. Really?

Written by John Levine, Author, Consultant & Speaker

Follow CircleID on Twitter

More under: Domain Names, ICANN, Multilinguism, Top-Level Domains