Archive for the 'dns' Category

Optimizing Autocomplete by Utilizing Browser Cache

Monday, March 29th, 2010

Say you have a snazzy AJAXified autocomplete field that gives instantaneous feedback to the user as she types — perhaps a username field on a signup form or something akin to Google Suggest. Except, it’s not performing as well as you thought it should. That round trip to the server for each character is taking too long.

The first thing you should do is to see if HTTP Keep-Alive is supported by your server.

Second, and this may seem obvious, but I’ve seen too many developers forget to leave a hint to the browser to cache the results. As a result, the page becomes sluggish due to a feature that’s meant to be responsive.

See what happens behind the scene when you sign up for a new Twitter account. Suppose you try to register the username “wil”, but it’s taken. For each character you type, the browser makes HTTP requests to check that the username in the input field to see if it’s available.

So that’s one for “w”, “wi”, “wil”. Then you find that all 3 are taken. Ok, perhaps time to add a numeric suffix? “wil1″ – nope, delete the “1″, and we’re back to “wil” again. Guess what? Another HTTP request is sent to Twitter for the same string “wil”!

Had Twitter set an “Expires” header to usernames that are taken, the browser wouldn’t have had to make that round trip!

Below are the headers sent by Twitter for the https://twitter.com/users/username_available URI (courtesy of Hurl):

In the case of signup forms, usernames are rather involatile pieces of data, so it’s a prime optimization target. As your namespace becomes more scarce, you’ll tend to have people trying more strange combinations, increasing the number of requests to your servers.

In my case, I’ve applied it to our TLD management platform. Domain names that are registered gets a 10 minute cache timeout value (which is heaps short but good enough to ensure a snappy UI operations). However, with domain names, it’s a lot more volatile but we’re not guaranteeing success at the point of registering a name so anywhere between 1-5 minutes is usually sufficient.

A simple view snippet in Django does the trick and goes a long way to making your users happy.

/ Blogging from a HSDPA connection

Why Internationalize?

Thursday, February 19th, 2009

Tower of Babel

Seth Godin‘s book Tribes: We Need You to Lead Us looks like a good read, especially for marketers, crowd-herders, and entrepreneurs. Along with the book, he also started an invitation-only triiibal network on Ning, and got the folks to write an ebook called The Tribes Casebook (free download).

There’s a particular essay in there written by Dr. Saleh AlShebil titled When Technology Fails: A Language gets Born in an Online Tribe. Dr. AlShebil wrote about how an ASCII-based language (that he calls Araby) was born due to the lack of Arabic language input support on early instant messaging networks. These are transliterations of Arabic into Latin alphabets, not unlike l33t but grew out of different motivations.

Here’s what it looks like (source):

Sound Arabic letter ASCII Example
/ħ/ (a heavy /h/-type sound) ح 7 wa7ed (one)
/ʕ/ (a tightening of the throat resembling a light gargle) ع 3 ba3ad (after)
/t’/ (the emphatic version of /t/) ط 6 6arrash (he sent)
/s’/ (the emphatic version of /s/) ص 9 a9lan (actually)
/ʔ/ (glottal stop) ء 2 so2al (question)

So, واحد (one) sounds roughly like “wahed”, and you’d write it as “wa7ed”.

Quoting Dr. AlShebil (emphases added):

Arabic language alphabet is comprised of 28 letters. Some of these letters do not have an equivalent “sound” in English. So what did our online tribe do? They began looking for numbers and other keystrokes that can somehow resemble what the real Arabic letter “looks” like. Let me explain…

For instance, the Arabic letter “ﻉ” is pronounced as A’aa when used in a word and it got replaced with the number “3” since “3” looks like an inverted “ﻉ”. So the word Arabic which is written “Araby” (in Arabic sounding English) and begins with “ﻉ” was then written as “3raby.”

…This new form of tribal net lingo began to spread like wildfire. It would probably be a safe assumption to say that any Arab who is online today (especially the youth) is pretty familiar with it. Using it was not limited to chat and instant messaging but has also swelled to include any form of writing in online communities and even in mobile text messaging (sms). The Arabic net lingo virus caught on to Arabic websites that even wanted their domain names to sound or “look” Arabic.

As mentioned above, this is similar to l33t-speak, and also the lesser-known ギャル文字 (Gyaru-Moji).

Now, I dig subcultures like these, but don’t you think there’s something wrong with the emergence of a new lingo that could potentially erode a language like Arabic just because technology couldn’t support it?

Is this serious enough to erode the Arabic language? Maybe I’m exaggerating but one can imagine youths forgetting how to spell correctly in Arabic script because they’re so used to using “Araby”.

This is the case for why internationalization is important for the Internet (and technology in general.) More importantly, it is the prime motivation behind Internationalized Domain Names, which is in turn a primary contributor to the need for new TLDs.

Internationalization is not for vanity or luxury, it’s a necessity to preserve culture.

Domain Tool for iPhone — whois on the move

Friday, October 3rd, 2008

Introducing DomainTool — an iPhone application for querying domain name whois information. I wrote this to learn iPhone programming (with a certain killer app in mind) as well as to scratch my own itch.

Occasionally, I find myself needing to think of a product name or domain name for a web site. Ideas can knock on my head at any time: at lunch, in the toilet or waiting in the queue. I could note it down on a generic note taker on the phone, or jot it down on a piece of paper, but nothing beats being able to instantly find out if the domain is available and keep track of it in a dedicated app. Hence, DomainTool was born.

As with any great app, it should be simple to use, and addresses a focused need. Thus, you’ll find the following grand feature list:

  • Query WHOIS servers to find out if a domain name is taken. Similar to the command line whois tool
  • Bookmark a domain name, and query it again anytime
  • Supports all TLD that has a published WHOIS server: COM, NET, ORG, BIZ, INFO, CC, JP, CN, TW, KR, MY, SG, PR, DE, EU, and many more!
  • Supports Internationalized Domain Names (IDN)

Some screenshots:

By now, I suppose you’re dying to try it out on your iPhone, and I can certainly sympathize with that. It can be yours for USD0.99 (or the equivalent in your currency) — 70% of which goes to my coffee bank, and the rest goes to Mr. Jobs.

Get it here!

.test IDN TLD (For Real!)

Tuesday, August 28th, 2007

Tina Dam and I caught up during ICANN San Juan on the current state of IDN TLD work within ICANN and that was when I first found out that she was putting together a live IDN TLD test bed which includes translations of the string .test into eleven written languages (Arabic, Chinese-simplified, Chinese-traditional, Greek, Hindi, Japanese, Korean, Persian, Russian, Tamil and Yiddish) and ten scripts (Arabic, Cyrillic, Devanagari, Greek, Han, Hangul, Hebrew, Hiragana, Katakana, Tamil).

I was very excited to hear that and wanted to blog about it but there was much to catch up at work so I let it slide.

Two days ago, an update from ICANN on this project:

ICANN today finalized the IDN .test Evaluation Plan and continued taking steps toward insertion of IDN strings in the root zone. Recent changes to the plan are based on comments received on the IDN public forum and also from consultations with ICANN Technical Advisory Committees. This last version was approved by the ICANN Board at their 14 August 2007 meeting. The resolution directs ICANN Staff to implement the IDN .test Evaluation Plan, and report back to the ICANN Board following the conclusion of the evaluation.

Specifically, the Board approved the delegation of eleven evaluative top-level domains representing the term ‘test’ translated into: Arabic, Persian, Chinese (simplified and traditional), Russian, Hindi, Greek, Korean, Yiddish, Japanese and Tamil. Following this ICANN Board approval, the delegation request will now go through standard IANA procedures for insertion of top-level domains into the root zone. The technical evaluations of IDN TLDs and their usability in various applications will proceed following their delegation.

This is a major milestone in the IDN Program Plan and signals a significant step forward towards Internationalization of the DNS. It is currently anticipated that delegation of these TLDs and the evaluations, as described in the plan, will commence in September 2007.

I would like to applaud ICANN (specifically Tina) on bringing the project this far. This is a major undertaking, and an important one too, for the following reasons:

  1. It works across the Internet — not just an isolated test that involved a couple of PCs running in a lab environment; they are going to insert these labels into the root zone! This is the only way to involve the most diverse mix of participants in the test bed. The fact that it requires no special setup (like tweaking of hint files) may lower the barrier for entities such as ISP’s, who are traditionally seldom interested in the development of IDN, to participate.
  2. As a result, it allows the most diverse array of test cases possible. Just imagine how an innocent domain name gets passed around applications, resolvers, recursive and authoritative DNS servers through a myriad of functions, API calls and networking protocols. It’s supposed to work but who knows for sure?
  3. It tests major scripts used by regions with an immediate need for IDN-TLDs (Latin would have induced yawns)

I’m sure there are skeptics and ICANN-haters out there who will dismiss this for time-wasting activity, etc. The truth is, no one has actually tested IDN TLD’s on Internet-wide scale before. And no, country-wide deployments will not suffice because the diversity of software environments and cultures simply isn’t there.

And if you’re a proponent of the Just-do-it school of thought, this should be seen as a move in the right direction. If no major problem was found during the live test, it will shut the mouths of those who are doubtful.

We should take advantage of this test to file bugs for your favourite software vendors and get them to support IDNs! When was the last time IANA inserted a test TLD to the root? Tell them that if IANA agreed to put these test strings in the freakin’ root, this is not a default ignorable technology alright!

So, help spread the word and test the Internationalized Internet!

नमस्ते

.BIZ Korean IDNs Just Launched

Monday, August 20th, 2007

The second piece of news following the localization of EchIDNA into Korean is that we have just launched Korean IDN registration in .BIZ three hours ago. I won’t divulge the numbers here but let’s just say that it far exceeded my expectations.

You may be wondering if there is any connection between our Korean launch and the localization of EchIDNA. Aside from yours truly being involved in both projects, it is purely coincidental. We have been preparing for the Korean launch for a few months, and in doing so have consulted with NIDA (National Internet Development Agency in Korea) and have adopted their language table (with 2,350 KS X 1001 Hangeul characters). The table is available here: http://www.neulevel.biz/idn/KR_Table.pdf and will be posted to the IANA Repository of TLD IDN Practices soon.

If you have a .BIZ Korean IDN and would like some free links, submit it to IDNSearch.net!

Domains are safe

Monday, April 2nd, 2007

Ever since I learned about the RegisterFly trouble, I’ve been frantically trying to transfer my domains out of that crook of a registrar.

Some of my domains registered with RegisterFly had Enom as the registrar of record because RegisterFly was an Enom reseller before “getting accredited” themselves. One of them was particularly problematic because the authorization code was not showing in RegisterFly’s control panel and I had to send a bunch of documentations to Enom to get the domain moved to an Enom account. I’ve been twisting my fingers for the past week and am relieved to finally have all my domains transferred to GoDaddy. The only thing I lost out on is some $15 worth of credit in the RegisterFly account, which I am dead sure will not see the light of day.

Now, as long as Bob Parson doesn’t start using the company funds to buy a private jet or some villa in the carribean I reckon I’ll be safe.

Few lessons learnt from this exercise:

  • Always keep your whois data up-to-date, particularly the email address
  • Renew early (at least 3 months before the expiry)
  • Select a reputable registrar – this one is hard as they all suck, just a question of which one sucks less, and a balance between price and reliability.

Registerfly Comes Crashing Down

Sunday, March 18th, 2007

All my domains are with Registerfly, which is in deep trouble. I won’t re-iterate all the details here because GoDaddy’s Bob Parson has summarized it very well in his post.

So, I’ve been busy trying to transfer my domains to GoDaddy. In case you think I’m some big-time cyber-squatter1, I have 17 domains in total – hardly any “portfolio”. Keeping my fingers crossed that all my domains including dready.org survives the transfer (it’s tricky because the expiry is near.)

1 aka “domainer”.

Browser-based mitigation of phishing attacks

Monday, January 22nd, 2007

The OpenID phishing issue is a hard one to solve, particularly because it aims to:

  1. be user-friendly, i.e. it should pass the mother-in-law test; and
  2. work on the web platform without special software or browser plugin

So, why is this suddenly a problem?

Not really, phishing is a perennial problem on the Internet that researchers and developers have been trying to solve for many years now. OpenID just accentuates it because RPs are unregulated. You don’t need any agreement with any OP, essentially anyone can set up a web site and put the OpenID login button. If OpenID takes off, RP sites will grow like ‘shrooms and user will get used to the idea that if they see the OpenID logo, they can type their URL to login. This only makes it harder for users to discern the good RPs from the bad ones.

This is really a social problem, and not a fault of the OpenID protocol. Users need only to trust their OP, and not the RPs that they interact with. If a rogue RP sends you to a page the poses as your OP but the URL doesn’t match your OP’s, you bail out. Doesn’t that sound simple? Well, the cold hard fact is that phishing works and there are research1 to prove that people get tricked very easily.

Numerous ideas to mitigate phishing attacks have been floating around the OpenID list and on the OpenID mini-blogsphere. Ben Laurie argues for a client-side solution:

Authentication on the web is broken, and has been for a long time. The OpenID fanboys want OpenID to work on any old platform using only standard software, and so therefore are doomed to live in the world of broken authentication. This is fine if what you protect with your OpenID is worthless, but it seems clear that these types of protocol are going to be used to authenticate for things of value.

This is the root of the problem: if you want to protect anything of value, you have to do better than existing Web solutions. You need better client-side software.

The picture is not so sunny, however, because most users:

  • won’t know / bother to install specialized plug-in or upgrade their browsers unless they’re forced to
  • won’t know the difference between citibank.com/signon and citibank.com-banking-foobar.com

And even if they installed those anti-phishing toolbars and what not, they still fall for it!

While I can’t decipher the wirings of the mums-and-dads who fall prey for phishing attacks, I know that I get lazy sometimes and just don’t bother. Then I remember this little trick that Firefox introduced to ensure that users get the warning before installing extensions — Introduce a delay in the dialog box before it can be dismissed. That sort of worked for me, at least for that 5 seconds I can’t click so I might as well read a little.

So, here’s an idea for a browser (or plug-in) implementation:

FUNCTION form.onsubmit()
  IF !form.contains-password-field()
    RETURN ok
  END IF

  IF form.action.domain IN trusted-domains
    RETURN ok
  END IF

  SHOW WARNING-DIALOG (delayed-dismissal=5 secs)

  IF continue-button.clicked
    ADD form.action.domain TO trusted-domains
    RETURN ok
  ELSE // cancel-button.clicked
    RETURN not-ok
  END IF
END FUNCTION

The idea is that you should only submit passwords to sites that you have previously added to the trusted-domains list. This idea is not new, and has been proposed by several on the OpenID list.

Where I think could really make a difference is the way in which WARNING-DIALOG is constructed. It should contain the following:

  • If the current page and the form target page are on different “effective domain”, emit warning. There are legitimate use cases for this, and we don’t want to overemphasize it, but it should raise suspicion.
  • Display the “effective domain” of the form prominently.
  • If the form target is not a HTTPS URL, emit warning.
  • Warn the user that the target is not known to the browser to be trusted, and that this could be a sign of phishing.
  • A continue button that is greyed out for 5 seconds to force the user to read the above information.
  • A cancel button that is focused by default so hitting enter will dismiss the dialog and cancel the request.

An “effective domain” as I call it is defined as the DNS name in the URL stripped of insignificant parts. This basically means that we can use Mozilla’s Effective TLD Service that I blogged about earlier to summarize a URL for display to the user so that us.rd.yahoo.com becomes just yahoo.com, and it will correctly work for things like www.netbank.com.au, which returns netbank.com.au instead of com.au.

A sample dialog might look like:

You are submitting a password to a site that may not be safe. Click “continue” to trust this site forever, or “cancel” to return to the current page.

Password will be sent to: xn--pypal-4ve.com
Password will be sent in the clear (unencrypted).

  

There are a few advantages to this proposal:

  • it works on all password forms, not just for OpenID
  • it forcefully disrupts the flow of the user and the delay may help the user to be more cautious

The downsides are:

  • it only works for password phishing, other information such as credit card numbers will go through without warning
  • phisher can replace the password input field with javascript / DHTML / flash to bypass the check

Even with these restrictions, I still think that it brings significant value in terms of mitigating password phishing attacks. This is of course very raw and there is much room for improvement. All comments and suggestions are welcome.

1 Thanks to Mike Beltzner for the links to these phishing research papers.

UPDATE: Kim Cameron’s latest blog post about Integrating OpenID and CardSpace has some nice pictures of the modal OpenID phishing attack scenario.

Security Restricted Domains Database

Monday, January 22nd, 2007

This was going to be a “Dear LazyWeb” request, but after some research I found what I wanted.

Recent discussions about security and phishing on the OpenID list got me thinking about the problem space.

DNS plays a critical role in the security of OpenID because

  1. URL is the identifier type used
  2. User should only trust the OP with which he/she has an account with.

The “Phishing and OpenID” discussions on the OpenID list actually hinges on point #2 above. Ben Laurie wrote about it here. In short, OpenID opens the door for a malicious RP to send a user to a spoofed OP-lookalike and collect his/her password.

Back to DNS. I have, on numerous occasions in the past, tried to look for a list of domains where registrations are open for public. This varies from TLD to TLD, e.g. .biz accepts registration directly on the second level, .us also does but delegates two-letter subdomains to US states, and .uk only accepts registrations on the third level after .co.uk, .ac.uk, etc.

Well, it turns out that the Mozilla folks needed this list in order to disallow web sites setting cookies for the entire .co.uk or similar domains. Currently, they block just the TLDs so example.com cannot set a cookie for .com, but 2nd level onwards domain cookies are allowed. This could easily cause cookies to be stolen by any site rooted in the same domain.

So, this advisory started this bugzilla entry at Mozilla and it eventually led to the creation of this API and this list (see attachment). They call it the “Effective TLD” list, which is really a misnomer because they are not necessary just TLDs. It was decided in the bug discussions that the term “effective TLD” is easier to digest that anything else, though I’d prefer to call it “Security Restricted Domains”. Whatever, as long as it gives me the content I want.

Many will probably criticize Mozilla for creating yet another list that gets stale the moment it is created. Indeed, TLDs get created and 2LDs within TLDs are introduced and deprecated so often that such a list will be hard to maintain. Moreover, many organizations assign names to registrants at a level that doesn’t involve the TLD registry. Examples include CentralNIC’s .<country-code>.com and *.blogspot.com, and countless others. Add to it the introduction of IDN TLD may well be in less than 2 years. Keeping a definitive list is not feasible. Nevertheless, I would argue that depending on your needs, this list could still be very valuable, as is the case with the cookie problem that they are trying to solve.

So, what has this got to do with OpenID? I shall leave that to a different post.

NeuStar Launches 5 New Languages for .BIZ

Thursday, November 2nd, 2006

We launched 5 new languages for IDN in .BIZ today. They are Danish (da), Icelandic (is), Norwegian (no), Spanish (es) and Swedish (sv). Prior to this, the only language available in .BIZ was German (de), launched in October 2004.

I’d like to take this opportunity to thank DK-Hostmaster, ISNIC, NORID, NIC-SE and Cary Karp of MuseDoma for their help and advice on these tables. The work on these tables really started 2 years ago when we first had the intention to launch additional languages, so I am very proud and relieved that they made it out!

Here’s a summary of the non-ASCII characters available for registration:

Code Point Character Language Codes
U+00E0 à no
U+00E1 á is,no,es
U+00E4 ä de,da,sv,no
U+00E5 å da,sv,no
U+00E6 æ da,is,no
U+00E7 ç no
U+00E8 è no
U+00E9 é da,sv,is,no,es
U+00EA ê no
U+00ED í is,es
U+00F0 ð is
U+00F1 ñ no,es
U+00F2 ò no
U+00F3 ó is,no,es
U+00F4 ô no
U+00F6 ö de,da,sv,is,no
U+00F8 ø da,no
U+00FA ú is,es
U+00FC ü de,da,sv,no,es
U+00FD ý is
U+00FE þ is
U+010D č no
U+0111 đ no
U+0144 ń no
U+014B ŋ no
U+0161 š no
U+0167 ŧ no
U+017E ž no

If you’re looking to register a Scandinavian or Spanish domain name, visit your favourite domain registrar to get yourself one.
When you’re done and made a web site out of it, don’t forget to submit it to IDNSearch.NET!