Show HN: Use any text as a domain name
github.com
github.com
> Bind searches to domain names, eg "food in chicago" => f02970848a63988965aa40cd368ffcf9046209ca.com
This IMO is bad, and goes in completely wrong direction. We've invented search engines to have such phrases not bound to a particular domain. Who would handle the "#://food in chicago" domain? Would it be Google? Bing? Yelp? Local restaurant chain? Or maybe some scammers? And who would maintain the completely different website "#://food in Chicago", and why "#://Food in Chicago" wants to silently install me some malware?
The reason searching for such phrases makes sense, while having them as domains does not, is that things like "food in chicago" are poorly defined, fuzzy concepts. It would feel weird to change one letter in a query, or replace word "food" with, eg. "something to eat", and see completely different website. Moreover, major search engines are more or less egalitarian wrt. buisnesses. Yes, there's the whole SEO thing, but you can't get full control of what food joints are listed near your location just because you've managed to get the register first. I can (and do) trust listings from Google; they have both incentives and track record of being fair. I will never trust listings from random-autogenerated-squat-scam-business-site.
Which brings me to the second point,
> Good domain names are pretty scarce. It's a source of frustration for anyone who has ever tried to buy a domain.
Yes, they are, and the primary source of frustration is that they are mostly taken by various squatters and other scums of the Internet. What will happen is that, the moment there's any real possibility such hash-domain scheme is introduced, all those evil people and companies will take all the domains like "#://microsoft", "#://android" and "#://insert any popular keyword or phrase here" in order to sell them back to real businesses for boatloads of money. And then we'll be back to square one, with maybe a little bigger domain space than we have right now. Bad people win, good people loose and nothing changed.
So, again, the concepts behind this idea elude me.
You receive a phrase, then get its hash, enter that hash and geta hashed url?
"Scums of the Internet"? Oh please.
Where are you getting this all from exactly? You've just decided that since you weren't able to buy a domain [1] that you wanted at a price that you could afford to pay that all domains "are mostly taken by various squatters and other scum of the Internet".
I mean "scum"? How unfair that something that you want isn't available at a price YOU can pay. And if that price was affordable that someone else wouldn't have beaten you to buying it (which is already what happened, right?). I mean it would just be sitting there because nobody else ever thought of using or buying, say "hackernews.com" until PG decided to start Hacker news.
Or perhaps you think that domains are a "public trust" and that there should be some official board designated that decides who is worthy of a particular domain and whether they are "using" that particular domain "the right way". You know to make things fair.
Is that it? Further you are talking about .com because in general and with maybe a few exceptions, you can find many names in other TLD's (you just don't want them) or make a slight modification and have the domain you want in .com.
By the way are you aware that google owns duck.com and refuses to sell it [2] at any price at all? (And has turned down $500,000 for it iim.) Of course they aren't "using it" [3] and only have it because they bought the company that previously owned it
At least if it was owned by a person such as you refer to it would be available for sale at some price.
[1] Or perhaps that wasn't even the case maybe you have just read about other people or know someone that this was the "aggrieved" party?
[2] I was involved in trying to do this. And I communicated and had back and forth with high level people at google who in the end simply said "sorry not interested at any price". And this isn't the first time this has happened with a company either.
[3] It redirects to google.com as if they need that traffic.
Creating nothing useful is in the definition of "Investment Banker".
In that sense, investment banker is still a useful and necessary job, unlike domain squatter.
As far as "squatting on my company name" the majority of the vitriol on HN regarding domain names is not directed at "squatting on my company name" (to which there are clearly defined rules and procedures for recovering a domain (UDRP)) but just at the general idea of someone getting a domain and holding it to sell at a later date.
As far as "to either buy from them or change the company/product name" we are talking the year 2014 here. If you are starting a new company you should be taking into account whether the domain name you want is available. People don't, I know this for multiple reasons. One is that I get assignments to buy domains for startups that have already branded (which they shouldn't have done) and then come and say "I need this domain what can you do for me?" (in so many words).
Now if you are an established company and all the sudden woke up in 2014 and want your domain well then I guess that's to bad. Even back 10 years ago big corporations had this problem because the people they hired didn't know enough to lock up their domains. Either because they were inept or because they didn't feel it was important to have (so what can you say about that?)
Basically, from the same places that the manufacturer gets their money from in order to pay dividends to the investors.
Investment banking is _a_ lubricant of industry, not _the_ lubricant, certainly not the fuel.
Do you think that crowdfunding has replaced needing to raise capital through the legacy process of initial public offerings and also that companies that use investment bankers to not seek out a merger or acquisition of another company don't serve a purpose?
What do you think you just need millions to expand and walk into the bank or go to kickstarter?
Oh, and that goes against Australian domain regulations, but auDA refuse to do anything about it, sigh. Oh well, they can own a useless (to them) domain if they want to. I just think its silly.
It's different because the squatter is essentially leeching off of everyone else. If it wasn't for them the people who wanted the domains could have gotten it for free or at least less. They add nothing of value at all.
One could argue the same for people who squat other scarce natural resources that they paid nothing for.
If there is a case of someone just inflating the price and adding literally no value at all then I would say that is just as bad.
Who is worthy of the domain? At least the one actually intend on using it is more worthy than the one intending to sit on it to ask for rip-off money.
Squatter are scums.
Solutions? I'd like to see something like a tax proportionate to asking price on domains, analogous to a land value tax, to discourage claiming domains that you're not actually using.
But like individuals who buy empty lots from the Forest Service to resell at a premium, can't you understand why this seems like an inefficient market outcome? Sure, it may be desirable/profitable, but not ideal?
Squatting may be a result of our domain registration system, but is it really desirable? to me it seems like a negative externality, that over-uses free domain names and which sells them for 100x times the price from a registrar, despite their non-use.
Why is a squatter adding any value? Should all domains be bought by one person who uses none for his one purposes, and sells each for 1k?
"Why is a squatter adding any value?"
Value? What is the value of gambling at the casino or horse racing? Is value the demarcation point of economic activity that is acceptable?
What value does anyone provide who has enough knowledge (and or capital) to be able to buy something in advance anticipating that someone else might find it of value at a later date? We aren't talking about cornering the market on insulin here are we? Am I allowed to buy high volume scanners on craigslist and then sell them on ebay and make money? Am I providing "value"?
"Should all domains be bought by one person who uses none for his one purposes, and sells each for 1k?"
Well what prevents you from doing this to make money? Is it that you a) don't have the capital or b) don't have the knowledge to determine what would sell at a later date or c) you just find it objectionable and desire to not be in that business. (Like porn for example..)
If "c" then can you understand that it's a valid business model, is not illegal and in a sense is about as "fair" as someone buying real estate years ago in a hot area and now expecting to make a profit off that real estate? After all there is a risk in using your capital "a" to take this chance, right? You certainly don't believe that buying a bunch of domains that you think might go up in value is guaranteed do you?
Or AFLAC.
(characters used, length, common sub-strings ...)
http://en.wikipedia.org/wiki/RealNames
RealNames was a company founded in 1997 by Keith Teare. Its goal was to create a multilingual keyword-based naming system for the Internet that would translate keywords typed into the address bar of Microsoft's Internet Explorer web browser to Uniform Resource Identifiers, based on the existing Domain Name System, that would access the page registered by the owner of the RealNames keyword.
I'm certainly glad they stopped treating + as a search operator so we could get that feature in return.
The name for this is Direct Connect, and they announced it in 2011. http://googleblog.blogspot.com/2011/11/google-pages-connect-...
Hash based domain names would be even worse. You have no idea what site is lurking behind some big string of hex digits. You could argue that a person should just compare the hash to some known set of hashes, but that's a. cumbersome and b. unrealistic. If it's done by humans, it's error prone (a malicious site could spoof the first few chars to point to their site), and if it's done by computers, what's the point? You've now effectively created a really shitty replacement for DNS.
So, you suggest that non english speakers should just "learn it" to use DNS?
It seems that generally a subset of sufficiently distinct characters should mostly suffice. I don't think e.g. Latin, Hebrew and Chinese have much visual overlap.
[1] http://www.chromium.org/developers/design-documents/idn-in-g...
[2] http://www.mozilla.org/en-US/about/governance/policies/secur...
e.g.
I buy 'apple.com' and while if I want to leave it as this, fine. However, I should also have 'apple.com.us' and 'apple.com.ru' so that I can handle these appropriately. It's not perfect, but it at least gives my users a chance to say "hey, I probably prefer (english|russian), so please give me that page."
Of course, this is also a bit lazy and somewhat of a non-solution, as this only addresses the issue for English speakers. A russian speaker using the .ru namespace is already willing to "play by the ascii rules."
People going to 'apple.com' really expect to go to the webpage of the American electronics company. One could assume this by the TLD. Users sending a request to 'apple.рф' would be doing something somewhat strange (user sends english base label, followed by a cyrillic tld). This isn't that absurd though, as english company names become loanwords (at least in russian -- see "xerox" or even ask a russian if he owns a 'yabloko makkniga pro' or an 'apple macbook pro' for example). Should the presence of a non-unicode TLD trigger country-specific mode in browsers for the sake of security? How do we handle loanwords (spoiler to above: russians say 'apple' when referring to the brand, even though it shadows the actual Russian word for apple) with non-ascii TLDs?
Should the Cherokee syllabary be permitted in .us domains? If so, you are still open to homograph spoofing against the Latin character set(e.g. Ꭹ for y or Ꭲ for T). If not, isn't it a trifle rude to declare that writing system "unamerican"?
What about immigrant languages other than English? Why are Latin-charset language users more American than e.g. Hebrew ones like the long-standing and well-known Yiddish population of New York?
You could ban mixing of code ranges in domains. That might help, but how do you sensibly restrict a code range? Turkish is a Latin charset language, but contains a few extra characters that pose a homograph risk. How do you work out whether a domain is Turkish (and allowed to contain ı) or not Turkish? Also, what if you wanted to differentiate the website for your California-based Yiddish-named restaurant from a similarly named competitor in New York?
Should the governments of Morocco and Algeria be empowered to blanket-refuse Tifinagh domain names? What about when Georgia was part of Russia?
Well, seeing as that "huge chunk" is a large majority, then the solution isn't "learn english because I'm used to typing URLs _this_ way."
I understand that English is the current lingua franca, but it's aggressive to expect everyone to deal with it just to use the internet.
Why not use our country tlds? It might mean that ICANN has to actually do some work, but I think that the uppermost tld for countries should actually be reserved for suffixes.
e.g.
apple.us #should have never been sold apple.com.us #there, none of that scary unicode apple.com.ru #same unicode problem abound (but at least it addresses the first issue)
Note that you can't just type it in because kto.p? is not the right letters and that last one is obviously not on your keyboard. But cut and paste should work fine.
Using phone number doesn't require you to "learn" Math.
Is it impossible to overcome the flaws you pointed out? Is there a way to abstract away the risk from the end user? Are there other applications for this where trust is not an issue? At risk of sounding like an idiot, could some sort of distributed proof-of-work/proof-of-stake protocol alleviate some of the trust problem?
As for the apple site, there are other (better) systems in place for supplying identity information than just the url.
Unicode or not, if you type in apple.com on your English keyboard, you will go to the website of Apple, Inc. (Unless your DNS cache has been poisoned.)
Except in the case of a carefully selected unicode domain, the address bar will say 'www.paypal.com', not 'www.paypallolimstealingyourlogin.com'.
In short; instead of merely mapping to [hash].com the extension could map to [hash].com, [hash].se , [hash].ly, [hash].is, [hash].ch and then use a quorum consensus of whatever answer 3 or more of those names agree on. Effectively each TLD registry (and each of your registrars), along with their regulatory environment, would lose the ability to take down your name without international agreement.
For certain niches, such a feature might be a good enough value proposition to ordinary users to convince them to install an extension.
Other observation; 36-ary is probably a better encoding for the hash data than hex. DNS isn't great with lengthy answers and every byte is worth conserving. But it's cool to see something interesting like this in the form of a browser extension.
This makes me wonder how important domains are at all. My mum never even thinks about the domains for the websites she visits, she just types in 'ebay' and Google does everything for her.
The only time I think about URLs (outside of coding) is when I have to share a link with someone, but I wonder if even that could be replaced with a sufficiently advanced search engine.
Perhaps the browser extension could be set so that whenever a search term is entered, it submits Google searches for both the raw text and its hash. If Google has indexed a domain that is a hash, and that exact hash is submitted as a query, you would get the right result as #1 every time.
As it stands, someone typing in:
food in Chicago
will get a different URL than:
food in Chicago
And the same goes for: Chicago food, chicago food, food near Chicago, etc.
Every one, with a single character difference (extra space, different word order, capitalization difference, regional spelling like theatre vs theater, etc) will result in a different hash.
You've now made 'humanized URLs' into 'no one will guess your domain'.
It's an interesting approach to avoiding search engines, but it doesn't solve the problem that search engines do solve: multiple similar but different entries resulting in the same "appropriate"/top website result.
With this approach, not even face book, Facebook, and facebook would result in the same .com (and please don't suggest just purchasing a billion domains and redirecting them all).
>food in Chicago
>will get a different URL than:
>food in Chicago
Why?
Also, since these strings would be typed, I'm not sure the homograph attack applies. Why would someone slip in a Cyrillic letter or something while typing the URL themselves? If extended to clickable links that displayed the pre-hash text, I could see the issue, but pudquick specifically said "someone typing in" the two URLs.
- Remove duplicate spaces and punctuation - lowercase entire query (just like DNS) - Detect and normalize homographs (is this a impossible problem, or are there solutions out there already?)
Why?
But on second thought, the real problem is that we (the web technology community) have assumed domain names are even a remotely suitable proxy for trust. I don't think most common web users actually get this point. That's why phishing is so easy (except for the part about getting a phishing email past spam filters).
Do you think most people really know (or notice) the difference between webaccess.bankofamerica.com and webaccess.bankofamerica.x8.co? I doubt it.
So the real fix for this situation is creating a true trust system that most actual end users can understand and rely on.
Then, it seems only natural for something like this to be the future. UUIDs will act as the underlying addressing technology with "whatever you want" as your display name.
And as a bonus, it will really cut down on the cybersquatters' profitability.
You could use something something like base64 instead.. might work better but it would remove the ability to use files as domain names.
@ TXT "v=sha1reverse; food in chicago"
Domain names are still useful, for a start they provide some level of authentication when mixed with cryptography. (If you visit https://news.ycombinator.com, you can be relatively sure there is no MITM with certain conditions present).
It would be interesting to see how this system can be adapted to work with our current Internet infrastructure.
--2014-01-01 16:45:59-- https://news.ycombinator.com/
Resolving news.ycombinator.com (news.ycombinator.com)... 198.41.191.47, 198.41.190.47
Connecting to news.ycombinator.com (news.ycombinator.com)|198.41.191.47|:443... connected.
ERROR: The certificate of `news.ycombinator.com' is not trusted.
ERROR: The certificate of `news.ycombinator.com' hasn't got a known issuer.So for example with current shorteners you have:
http://shorturl.com/{algorithm for unique URL goes here}
In the above case using a browser plug in can also eliminate any server side resolution of domains.
With this proof of concept:
http://{algorithm for unique URL goes here}.com
... Except the implementation costs $ if it is to be accepted... And to be accepted it needs to have a benefit that isn't solved by URL shorteners.
Perhaps allow 'scheme#' (where naked '#' implies 'http#'), or move the convention entirely to the domain-name area rather than scheme area. ('#food in chicago' -> 'http://#food in chicago' -> 'http://f02970848a63988965aa40cd368ffcf9046209ca.com')
Perhaps enabling spaces in domain names is possible? Since spaces in filenames are allowed I don't see why spaces in names shouldn't be allowed. And then you could have a default root domain for natural language names - .nlp, for instance, and then just assume that name when someone types in a natural language URI with no tld.
We could use something like NameCoin for this TLD to avoid collisions.
So, decided to write my first Chrome extension, modelled loosely on your domain name hashing, and here it is: https://github.com/jennielees/jump
It's entirely a personal itch-scratcher, but thank you for the inspiration!
"food in chicago.com" becomes "food⋅in⋅chicago.com" becomes "xn--foodinchicago-lj4hc.com"
[1] https://en.wikipedia.org/wiki/Internationalized_domain_name
The concept is that if it were accepted by browsers, devs wont have to struggle with squatters for domain names. So instead we register the hash for a word or phrase we want to use and us that as the domain.
BUT. nothing stops the squatters doing the same thing on this new concept. the squatters will just register the hash leaving you in the same problem as before
hxxp://food in chicago.com/ encodes to hxxp://food--in--chicago.com
Pros: * Domains can now have spaces
Cons: * Domains are now case sensitive * You visit a domain and it isn't reversible * The google-juice assigned to domain names is gone
Still, the implementation approach is interesting.
I would add less strict spelling, ie. spelling correction for existing domains, and for domains that are not recognized, go straight to search engine search (ie. google).
Really cool idea, though.
One of my favorite analogies for SHA collisions: http://stackoverflow.com/a/4014407/690258
/s
Personally, I like the idea and i'm going to use it. However, it relies on people downloading the extension. If there are enough people using it (which is definitely possible) then it would be successful.
Why are domain names bad? That should be obvious.
The main symptom of domain names' inherent brokenness is that the law must patch it so that an unknown squatter cannot kidnap some domain, e.g. register "france.com" and ransom it to the people who are most qualified to claim it. This is ridiculous: the squatter should not have had the opportunity to squat this (I know it doesn't apply for "France" but it applies for many other names). Nowhere in the world we see kids grab the seat in front of the fireplace and not let their grandma have it.
Moreover, what if a single ascii string refers to two different things equally claimable by two groups of people? E.g. what about "francfort.com"? Which city would it refer to? A contrieved case: If Chinese people chose a translitteration scheme for their language so that "google" would mean China, wouldn't they have some rights over google.com?
This level of brokenness is not even because of a leaky abstraction, this is a sunken boat everyone has to use to cross the river.
On a more philosophical stance, domain names are wrong because they build a kind of universal language out of nowhere, grounded on nothing, whitout any kind of democratic digestion and acceptance by human beings. We could have a universal language shared by all humans, but it would be a very long process of slow acceptance, with a percolation through all societies all over the world. In this way, there would be many adjustments, reverts, and eventually we would come up with a set of names that is good enough, but right now domain names are just a musical chairs game that is ridiculous and must be stopped.
So I think using a string's hash is a nice step, because it starts blurring the domain name.
However, I think a much better scheme should be to use the hash of the page content as the domain name. In this case, once the hash is determined, who cares where it is, who care which domain it has? It would just be way to download the content. And the job of search engines would be to point us to these hashes.
And dynamic content you tell? Which dynamic content? Does one really care about changes in wiki pages? And for the twitter feed, each tweek is a fixed content snippet, and the javascript fetching them is also fixed, or could be a browser extension. And an up-to-date search engine would have the latest hash for a keyword such as "twitter" or "The Guradian".
A nice side-effect would be that domain name based censorship would become ineffective. And downloading content could be just some p2p checkouts.
People can already register domains like "food-in-chicago.com" or "for-sale-baby-clothes.com".
Your contrived example about "Google" meaning "China" in Chinese, is irrelevant. The .CN registrar can enforce whatever rules they want. The US .COM registrar can have its own rules. There's no issue there.
In fact, most non-technical users I know go to the sites they visit daily by clicking the first result of the corresponding Google search.
But talking about hash-n-slash why it is bad. Just like domains have the issue of being kidnapped so would be the keywords. For example with the hash-n-slash you would never know where you will end up being when you search for "france". By giving search engine the liberty to direct me to a site I lose the ability to manually choose france.com when some SEO guy has made sure that #://france would lead of francegiggly.com
Same goes with every other keyword, we already have a keyword battle on search engines and it would be better limiting that battle to search engines only. If we push that to browser itself it would be just be chaotic and misleading to people who don't really understand domain authority.
Imagine this being done for pushing phishing website when trying to go to your bank's login page. I get it most bookmark it but many don't and new account holders?
Its just a proof of concept and in reality it has many constraints, the search engine and domain world isn't that broken yet that we need an alternate solution.
As much as its difficult to get relevant domain names its still not impossible to settle for something similar to what you wanted.
I care about new versions of wiki pages. If you write a page about good French restaurants in Beijing, I would read it. If I want to go back to the same page (= same hash) later, I will get the same page.
However, if there is an updated page, how will I know for sure? In the absence of domain names, a search engine might return some newer pages, but how can it rank them if there are multiple ones with the same title (and claiming the same hash as their predecessor)?
Maybe your server can return something in the HTTP header (like the hash of _your_ updated page)?
I wonder about memfrob based domain names.