10 ms·

This is certainly subverting the domain name system. I can't see the value or gain in security by this. (If you want to put focus on the domain, then display t

This is certainly subverting the domain name system. I can't see the value or gain in security by this. (If you want to put focus on the domain, then display the host-part with less contrast, i.e. grey, but don't hide any potentially vital information. Otherwise, put out a RFC, defining "www" as a substitute for "*", or a zero-value atom, in order to guarantee consistent behavior.) Edit: There are also legal concerns with catch-all domains in some countries. Blending the lines certainly doesn't help.

masswerk 8y ago
A proposal for better security with domain names: The domain name system has been around for decades and it's a clever and proven system. It can – and should be – taught in school and, arguably, knowledge of it is, while not difficult to obtain, essential in our times. Additional ambiguity in this is probably not what we want. Arguably, the most sincere problems arise from mixed alphabets with Unicode domains and look-alike characters/glyphs. This could be addressed by a) going back to codepages (Unicode subranges) and defining a valid subset for each range, and b) enforcing a domain name (hostname and domain) to be in a single codepage. Clients should derive the codepage by the Unicode range and generate a codepage-identifier, which may be displayed as a badge, identifying the respective range. And, of course, any mixed domains should be regarded illegal and invalid. (We may even want to make this codepage-identifier a mandatory particle of any URI, preceding the hostname.)
- deleted 8y ago
  [deleted]
- wongarsu 8y ago
  >enforcing a domain name (hostname and domain) to be in a single codepage this is essentially what is already implemented in most browsers. You can't mix characters from different scripts in a domain name, except for special cases (e.g. japanese and latin are frequently used together and have little potential for confusion)
  - masswerk 8y ago
    However, these are just "anti-phishing" heuristics. We really should apply a rule on this.
- UncleMeat 8y ago
  > Arguably, the most sincere problems arise from mixed alphabets with Unicode domains and look-alike characters/glyphs. No way. The most sincere problem is that hostnames do not enforce any binding to a real world identity that users can understand (nobody inspects certs) and that the most trustworthy component of a hostname is the second to the last section (right before ".com"). Humans tend to look at the front of the URL, making "www.bank.evil.com" a mind bogglingly effective phishing technique. Homoglyphs are almost always a sign of bad behavior and can just be banned to a large degree. The fact that "foo.com" or "foo.evil.com" are not necessarily owned by company foo is much worse.
  - masswerk 8y ago
    Regarding the parsing of URLs, this is a common, but mostly counterintuitive argument: Take for example names in most western countries, addresses (street-zip-city-country), etc. Most of our most important identifiers work this way. Regarding lacking binding of identity: On the other hand, this has been one of the most important features of the web, from the very beginning. Also, there is no way to setup a system, which will attribute to a single person in a readable and intuitive way. (E.g., names fail to do so.) Arguably, this should be left to (optional) extensions. I'd argue, the knowledge required to parse a URI safely may be conveyed in couple of minutes. Why not enforce this knowledge? Why not have a URL-parsing note on the start screen of any browser? Why dumb down the system and introduce ambiguity – and by this even more insecurity – instead of educating users? URL-parsing is a vital skill, which can be acquired in less time than memorizing a basic table of partial addition results. Why do we still try to teach addition, if we can't teach URLs?
    - deanCommie 8y ago
      Except this is already broken by multi-part TLDs. foo.com is owned by "foo" foo.evil.com is owned by "evil" foo.co.uk is NOT owned by "co"
  - masswerk 8y ago
    On a higher level, all those considerations are about a single question: Is the Web about communication (then it's probably OK as it is), or about a viable business platform with an entry-level as low as it can be? Who's without interest may throw the first stone, er, browser extension.
- pvorb 8y ago
  How about displaying an identicon, that is rendered from the domain, in the address bar? People might soon learn what the icons of their important sites look like and will easily detect if somebody is trying to phish their bank account.
  - masswerk 8y ago
    We might even call it "favicon", for the fun of it… :-)
    - kba 8y ago
      Any fake-Facebook website can copy Facebook's favicon, so that wouldn't add any security at all. An identicon is a hash value represented as an icon. "facebook.com", for instance, may hash to a red image with a yellow line through it. While you wouldn't remember the icon initially, over time you would – or at least your subconsious would. If you ever visisted a fake-Facebook, you'd immediately notice that something was wrong if the icon suddenly was green with a blue dot in it, for instance.
      - amygdyl 8y ago
        deliver the Favicon from a USPTO server, and I think you should nail the most amazing proportion of fraudsters, overnight.
    - mrec 8y ago
      Not sure if serious, but no. Anyone can copy a favicon; the point of an identicon is that it's generated from the domain name, so subverting it would require an attacker to find a hash collision with a visually similar domain.
      - masswerk 8y ago
        Sorry, I mistook "that is rendered from the domain" for "rendered from a resource from the domain". However, teach users to read domain names! If users do not grasp the general concept, e.g., if the supposed identity is just "example" (possibly with some decoration considered insignificant) and not "example.com", how are they supposed to survive? Domains have been around for more than a quarter of a century, the Internet is actually part of our lives… There is no excuse, and there is no sense in pretending that there was no harm in not understanding the basics. That said, there are real ambiguities that have to be addressed.
- Biqh1 8y ago
  do you have any examples of school class materials which teach stuff like this? I'd be really interested to read through them.
Donzo 8y ago
The reason why Google is doing this is because they are slowly trying to do away with URLs, as direct traffic is probably their greatest untapped segment. Google is trying to get users to go through their doorway pages, which is exactly the kind of thing for which they penalize publishers. Pay attention to when you enter direct addresses, let's say from a device/media subscription authorization page. The autosuggestion feature will often recommend Google searches, disguised as URLs, instead of helping you complete the very obvious URL. If they help you get to the site directly, the opportunity to acquire your page views diminishes. These behaviors are hostile toward users. I'd like to see further in their playbook to depreciate the URL as we know it.
- mehrdadn 8y ago
  Sorry, what? Could you expand on this? What do you mean by doing away with URLs?
  - jrowley 8y ago
    Many users never use the url bar. They just 'Google' for websites they want to access and follow the results.
    - vbezhenar 8y ago
      I'm occasionally doing that and especially suggest non-technical users to do exactly this thing. I can mistype URL. Google will correct me, if site is well-known. Otherwise I'm risking to go to phishing website.
      - hdkrgr 8y ago
        I just finished helping out a friend who did exactly this thing, clicked on an ad at the results page thinking it was Google's top result and was redirected to an ESTA scam site where they lost a bunch of money. What's easier to tell apart for nontechnical users? URL bar from Google search field or ads from Google results?
    - 8y ago
gumby 8y ago
> There are also legal concerns with catch-all domains in some countries. Wow, really? Could you expand a little? I tried to search but all I got was catch-all mail addresses and no legal issues. Thanks!
- masswerk 8y ago
  Here in Austria, we had a rather problematic court ruling regarding this. Following to this and to common recommendations catch-all domains were mostly disabled, at least, you run them at your own risk. What it was about: Say, there was a review or best-price-search site (here, "service.at"), using catch-all and mapping subdomain requests to product searches. So "acme.service.at" would be remapped to, say, "service.at/search?q=acme". Now Acme sued, claiming anything containing the name "acme" on the web ought to point to their site, including the subdomain "acme.search.at", since they were the owner of the name "Acme". To almost everybody's surprise the court decided that this was true, according to naming rights, and that a subdomain containing this name, even if just implemented virtually by a catch-all mechanism, was an infringement. This also implies that "acme.example.at", which is included in the set of "*.example.at", mapped to the very same as just "example.at" is a possible infringement. – Strange, but this is as it is. And, yes, it's particularly about search engines, like Google. (I really don't remember the particulars, since this has been some years ago by now, but we may assume that the results returned by the service weren't exactly favorable and that the particular search enjoyed a higher Page rank than the site of this vendor, or at least a rank, which brought it up near the site of the vendor in search results.)
  - gumby 8y ago
    Wow, that's particularly deranged if "service.at/search?q=acme" is considered acceptable (and if that's not, how could any search work?). Thanks for the explanation. I honestly would not have imagined anything like that.
    - sacado2 8y ago
      IANAL, and I'm just speculating here, but the law could have been termed as "copyright laws apply to domain names on the internet" (i.e you can't use the name of a brand you don't own in a domain name), and acme.service.at is a domain name, but service.at/search?q=acme is not.

masswerk 8y ago

A proposal for better security with domain names: The domain name system has been around for decades and it's a clever and proven system. It can – and should be – taught in school and, arguably, knowledge of it is, while not difficult to obtain, essential in our times. Additional ambiguity in this is probably not what we want. Arguably, the most sincere problems arise from mixed alphabets with Unicode domains and look-alike characters/glyphs. This could be addressed by a) going back to codepages (Unicode subranges) and defining a valid subset for each range, and b) enforcing a domain name (hostname and domain) to be in a single codepage. Clients should derive the codepage by the Unicode range and generate a codepage-identifier, which may be displayed as a badge, identifying the respective range. And, of course, any mixed domains should be regarded illegal and invalid. (We may even want to make this codepage-identifier a mandatory particle of any URI, preceding the hostname.)

deleted 8y ago
[deleted]
wongarsu 8y ago
>enforcing a domain name (hostname and domain) to be in a single codepage this is essentially what is already implemented in most browsers. You can't mix characters from different scripts in a domain name, except for special cases (e.g. japanese and latin are frequently used together and have little potential for confusion)
- masswerk 8y ago
  However, these are just "anti-phishing" heuristics. We really should apply a rule on this.
UncleMeat 8y ago
> Arguably, the most sincere problems arise from mixed alphabets with Unicode domains and look-alike characters/glyphs. No way. The most sincere problem is that hostnames do not enforce any binding to a real world identity that users can understand (nobody inspects certs) and that the most trustworthy component of a hostname is the second to the last section (right before ".com"). Humans tend to look at the front of the URL, making "www.bank.evil.com" a mind bogglingly effective phishing technique. Homoglyphs are almost always a sign of bad behavior and can just be banned to a large degree. The fact that "foo.com" or "foo.evil.com" are not necessarily owned by company foo is much worse.
- masswerk 8y ago
  Regarding the parsing of URLs, this is a common, but mostly counterintuitive argument: Take for example names in most western countries, addresses (street-zip-city-country), etc. Most of our most important identifiers work this way. Regarding lacking binding of identity: On the other hand, this has been one of the most important features of the web, from the very beginning. Also, there is no way to setup a system, which will attribute to a single person in a readable and intuitive way. (E.g., names fail to do so.) Arguably, this should be left to (optional) extensions. I'd argue, the knowledge required to parse a URI safely may be conveyed in couple of minutes. Why not enforce this knowledge? Why not have a URL-parsing note on the start screen of any browser? Why dumb down the system and introduce ambiguity – and by this even more insecurity – instead of educating users? URL-parsing is a vital skill, which can be acquired in less time than memorizing a basic table of partial addition results. Why do we still try to teach addition, if we can't teach URLs?
  - deanCommie 8y ago
    Except this is already broken by multi-part TLDs. foo.com is owned by "foo" foo.evil.com is owned by "evil" foo.co.uk is NOT owned by "co"
- masswerk 8y ago
  On a higher level, all those considerations are about a single question: Is the Web about communication (then it's probably OK as it is), or about a viable business platform with an entry-level as low as it can be? Who's without interest may throw the first stone, er, browser extension.
pvorb 8y ago
How about displaying an identicon, that is rendered from the domain, in the address bar? People might soon learn what the icons of their important sites look like and will easily detect if somebody is trying to phish their bank account.
- masswerk 8y ago
  We might even call it "favicon", for the fun of it… :-)
  - kba 8y ago
    Any fake-Facebook website can copy Facebook's favicon, so that wouldn't add any security at all. An identicon is a hash value represented as an icon. "facebook.com", for instance, may hash to a red image with a yellow line through it. While you wouldn't remember the icon initially, over time you would – or at least your subconsious would. If you ever visisted a fake-Facebook, you'd immediately notice that something was wrong if the icon suddenly was green with a blue dot in it, for instance.
    - amygdyl 8y ago
      deliver the Favicon from a USPTO server, and I think you should nail the most amazing proportion of fraudsters, overnight.
  - mrec 8y ago
    Not sure if serious, but no. Anyone can copy a favicon; the point of an identicon is that it's generated from the domain name, so subverting it would require an attacker to find a hash collision with a visually similar domain.
    - masswerk 8y ago
      Sorry, I mistook "that is rendered from the domain" for "rendered from a resource from the domain". However, teach users to read domain names! If users do not grasp the general concept, e.g., if the supposed identity is just "example" (possibly with some decoration considered insignificant) and not "example.com", how are they supposed to survive? Domains have been around for more than a quarter of a century, the Internet is actually part of our lives… There is no excuse, and there is no sense in pretending that there was no harm in not understanding the basics. That said, there are real ambiguities that have to be addressed.
Biqh1 8y ago
do you have any examples of school class materials which teach stuff like this? I'd be really interested to read through them.

Donzo 8y ago

The reason why Google is doing this is because they are slowly trying to do away with URLs, as direct traffic is probably their greatest untapped segment. Google is trying to get users to go through their doorway pages, which is exactly the kind of thing for which they penalize publishers. Pay attention to when you enter direct addresses, let's say from a device/media subscription authorization page. The autosuggestion feature will often recommend Google searches, disguised as URLs, instead of helping you complete the very obvious URL. If they help you get to the site directly, the opportunity to acquire your page views diminishes. These behaviors are hostile toward users. I'd like to see further in their playbook to depreciate the URL as we know it.

mehrdadn 8y ago
Sorry, what? Could you expand on this? What do you mean by doing away with URLs?
- jrowley 8y ago
  Many users never use the url bar. They just 'Google' for websites they want to access and follow the results.
  - vbezhenar 8y ago
    I'm occasionally doing that and especially suggest non-technical users to do exactly this thing. I can mistype URL. Google will correct me, if site is well-known. Otherwise I'm risking to go to phishing website.
    - hdkrgr 8y ago
      I just finished helping out a friend who did exactly this thing, clicked on an ad at the results page thinking it was Google's top result and was redirected to an ESTA scam site where they lost a bunch of money. What's easier to tell apart for nontechnical users? URL bar from Google search field or ads from Google results?
  - 8y ago

gumby 8y ago

> There are also legal concerns with catch-all domains in some countries. Wow, really? Could you expand a little? I tried to search but all I got was catch-all mail addresses and no legal issues. Thanks!

masswerk 8y ago
Here in Austria, we had a rather problematic court ruling regarding this. Following to this and to common recommendations catch-all domains were mostly disabled, at least, you run them at your own risk. What it was about: Say, there was a review or best-price-search site (here, "service.at"), using catch-all and mapping subdomain requests to product searches. So "acme.service.at" would be remapped to, say, "service.at/search?q=acme". Now Acme sued, claiming anything containing the name "acme" on the web ought to point to their site, including the subdomain "acme.search.at", since they were the owner of the name "Acme". To almost everybody's surprise the court decided that this was true, according to naming rights, and that a subdomain containing this name, even if just implemented virtually by a catch-all mechanism, was an infringement. This also implies that "acme.example.at", which is included in the set of "*.example.at", mapped to the very same as just "example.at" is a possible infringement. – Strange, but this is as it is. And, yes, it's particularly about search engines, like Google. (I really don't remember the particulars, since this has been some years ago by now, but we may assume that the results returned by the service weren't exactly favorable and that the particular search enjoyed a higher Page rank than the site of this vendor, or at least a rank, which brought it up near the site of the vendor in search results.)
- gumby 8y ago
  Wow, that's particularly deranged if "service.at/search?q=acme" is considered acceptable (and if that's not, how could any search work?). Thanks for the explanation. I honestly would not have imagined anything like that.
  - sacado2 8y ago
    IANAL, and I'm just speculating here, but the law could have been termed as "copyright laws apply to domain names on the internet" (i.e you can't use the name of a brand you don't own in a domain name), and acme.service.at is a domain name, but service.at/search?q=acme is not.