A French bank appears to be the first major company to commence a permanent switch from a legacy TLD to a new dot-brand.
BNP Paribas, the fourth-largest bank in the world, is dumping its .fr and .net domains in favor of .bnpparibas for customers in its domestic market, where it serves close to eight million retail banking customers.
The new dot-brand site appears to be a fully functional online banking service, not just brochureware.
It’s the ninth most-visited new gTLD domain name, with an Alexa rank today of 6,005, climbing the ranks every day.
As it’s a redesigned web site, customers are able to switch back to the familiar .net site (Alexa rank: 2,543) if they wish.
The domain was registered in January and BNP Paribas began a transition campaign in April. The transition away from the .net and .fr domains appears to have started at some point over the last month, but there hasn’t been a great deal of media coverage.
The .com domain is still live, serving Anglophone customers.
The mabanque.bnpparibas site leaves little doubt about the reason for the transition (translated with Google’s assistance):
BIZARRE, THIS ADDRESS WITHOUT .FR OR .NET? IS IT SECURE?
YES, A 100% SECURE SITE!
Any address ending with .bnpparibas is managed by BNP Paribas and has an advanced security certificate. Even more reliable, this new extension now acts as a signature.
Of course the architecture https and the padlock are still on your URL bar, confirming that the connection is secure.
So you can browse and view your accounts in all serenity!
BNP Paribas is a bit of a big deal, the fourth-largest bank in the world, managing assets of $2.5 trillion.
It’s bigger than Barclays, which earlier this year said it intends to transition away from .com and .co.uk to .barclays. The .barclays and .barclaycard sites are still just brochureware, however, with no transactional features.
Other dot-brands have launched sites at their new gTLDs, but .bnpparibas is the first transfer of a fully transactional web site from a legacy TLD to a dot-brand I’ve seen.
The recently discovered security vulnerability in one of ICANN’s web sites revealed how much Donuts was willing to pay for contested gTLDs at auction.
This worrying claim emerged during a meeting between registries and the ICANN board of directors at ICANN 53 in Buenos Aires yesterday.
“We were probably the largest victim of the data breach,” Donuts veep Jon Nevett told the board. “We had our financial data reviewed numerous times, dozens of times. We had our relative net worth of our TLDs reviewed, so it was very damaging information.”
He was referring to the misconfiguration in the new gTLD applicants’ portal, which allowed any user to view confidential application attachments belonging to any applicant.
But it was not until late May that it emerged that only one person, dotBerlin CEO Dirk Krischenowski, was suspected by ICANN of having deliberately viewed data belonging to others.
Nevett said communication should have been faster.
“We were in the dark for a number of weeks about who saw the data,” he told the board. “That was troubling, as we were going to auctions in that interim period as well.”
Donuts, which applied for over 300 new gTLDs, is known to have taken a strictly numbers-driven approach to string selection and auction strategy.
If a rival in a contention set had known how much Donuts was prepared to pay for a string, it would have had a significant advantage in an auction.
In response to Nevett’s concerns, ICANN CEO Fadi Chehade said that ICANN had to do a thorough investigation before it could be sure who saw what when.
XYZ.com has added .security and .protection to its portfolio of new gTLDs under a private deal with security software maker Symantec.
Symantec originally applied for both as closed generics, but changed its plans when ICANN changed its tune about exclusive access gTLDs.
The company won .security in an auction against Donuts and Defender Security late last year; .protection was uncontested. It lost auctions for .cloud and .antivirus.
Symantec’s .symantec and .norton, both dot-brands, are currently in pre-delegation testing.
XYZ already owns .college, .rent and of course .xyz.
In other news, Afilias has acquired .promo, which was in PDT with applicant Play.Promo Oy, in a private auction.
UPDATE: A couple of hours after this post was published, XYZ announced it has also acquired .theatre, which will compete with Donuts’ .theater, from KBE gTLD Holding Inc.
dotBerlin CEO Dirk Krischenowski is suspected of using a bug in ICANN’s new gTLD portal to access hundreds of confidential documents, some containing sensitive financial planning data, belonging to competing gTLD applicants.
That’s according to ICANN documents sent by a source to DI today.
Krischenowski, who has through his lawyer “denied acting improperly or unlawfully”, seems to be the only person ICANN thinks abused its portal’s misconfigured search feature to deliberately access rivals’ secret data.
ICANN said last night that “over 60 searches, resulting in the unauthorized access of more than 200 records, were conducted using a limited set of user credentials”.
But ICANN, in private letters to victims, has been pinning all 60 searches and all 200 access incidents on Krischenowski’s user credentials.
Some of the incidents of unauthorized access were against applicants Krischenowski-run companies were competing against in new gTLD contention sets.
The search terms used to find the private documents included the name of the rival applicant on more than one occasion.
In more than once instance, the data accessed using his credentials was a confidential portion of a rival application explaining the applicant’s “worst case scenario” financial planning, the ICANN letters show.
I’ve reached out to Krischenowski for comment, but ICANN said in its letters to victims:
[Krischenowski] has responded through legal counsel and has denied acting improperly or unlawfully. The user has stated that he is unable to confirm whether he performed the searches or whether the user’s account was used by unauthorized person(s). The user stated that he did not record any information pertaining to other users and that he has not used and will not use the information for any purpose.
Krischenowski is a long-time proponent of the new gTLD program who founded dotBerlin in 2005, many years before it was possible to apply.
Since .berlin launched last year it has added 151,000 domains to its zone file, making it the seventh-largest new gTLD.
The bug in the ICANN portal was discovered in February.
The results on an audit completed last month showed that over the last two years, 19 users used the glitch to access data belonging to 96 applicants and 21 registry operators.
There were 330 incidents of unauthorized access in total, but ICANN seems to have dismissed the non-“Krischenowski” ones as inadvertent.
An ICANN spokesperson declined to confirm or deny Krischenowski is the prime suspect.
Its investigation continues…
A small number of new gTLD registries and/or applicants deliberately exploited ICANN’s new gTLD portal to obtain information on competitors.
That’s my take on ICANN’s latest update about the exploitation of an error in its portal that laid confidential financial and technical data bare for two years.
ICANN said last night:
Based on the information that ICANN has collected to date our investigation leads us to believe that over 60 searches, resulting in the unauthorized access of more than 200 records, were conducted using a limited set of user credentials.
The remaining user credentials, representing the majority of users who viewed data, were either used to:
Access information pertaining to another user through mere inadvertence and the users do not appear to have acted intentionally to obtain such information. Access information pertaining to another user through mere inadvertence and the users do not appear to have acted intentionally to obtain such information. These users have all confirmed that they either did not use or were not aware of having access to the information. Also, they have all confirmed that they will not use any such information for any purpose or convey it to any third party; or
Access information of an organization with which they were affiliated. At the time of the access, they may not have been designated by that organization as an authorized user to access the information.
We can infer from this that the 60 searches, exposing 200 records, were carried out deliberately.
I asked ICANN to put a number on “limited set of user credentials” but it declined.
The breach resulted from a misconfiguration in the portal that allowed new gTLD applicants to view attachments to applications that were not their own.
ICANN knows who exploited the bug — inadvertently or otherwise — and it has told the companies whose data was exposed, but it’s not yet public.
The information may come out in future, as ICANN says the investigation is not yet over.
Was your data exposed? Do you know who accessed it? You know what to do.