Stories
Slash Boxes
Comments

SoylentNews is people

posted by Woods on Thursday May 01 2014, @07:37PM   Printer-friendly
from the now-all-those-URLs-I-memorized-are-worthless dept.

Yesterday, a Canary build of Google Chrome removed something kind of important from the browser: the URL. Basically, it only shows the domain and leaves the rest of the URL bar as a search field.

Allen Pike, a blogger who writes "about technology and crap like that" suggests burying the URL like this will probably have some usability and security benefits. From the article:

More recently, browsers started hiding the URL scheme. http:// was no more, as far as most users were concerned. In iOS 7, Mobile Safari went even further and hid everything about the URL except the domain. With the Chrome "origin chip" change, the URL will move out of the field entirely, to a tidy little button that many users will never even realize is clickable.

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Informative) by physicsmajor on Friday May 02 2014, @12:45AM

    by physicsmajor (1471) on Friday May 02 2014, @12:45AM (#38704)

    That sounds good until you realize that modern (and even not-so-modern) browsers are UTF-8 compliant.

    In the higher character codes there are many, many options which are almost visually indistinguishable from their Roman counterparts. Cyrillic is often used for this type of substitution attack. It's called an IDN Homograph, and nothing you do other than physically typing the URL using your own keyboard in a new tab will save you from it.

    http://en.wikipedia.org/wiki/IDN_homograph_attack [wikipedia.org]

    Starting Score:    1  point
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 1) by jasassin on Friday May 02 2014, @12:54AM

    by jasassin (3566) <jasassin@gmail.com> on Friday May 02 2014, @12:54AM (#38706) Homepage Journal

    This was enlightening. I never knew about this and it's scary. Please mod parent up.

    --
    jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
  • (Score: 2, Interesting) by Aiwendil on Friday May 02 2014, @08:50AM

    by Aiwendil (531) on Friday May 02 2014, @08:50AM (#38810) Journal

    This tells us that what really is needed is a "red little 8"-icon next to the "padlock"-icon's place in the adress-bar when visiting a domain with utf8-characters.

    And maybe also a little icon that shows a flag of which country the server one connects to are located in..

    And also - for developers - something that prefixes the domain with its ip-adress (prefixes it like how TFA showed the domain to be displayed would be handy).

    More data is needed, especially if it can be made glanceable and ignorable.

    • (Score: 2) by physicsmajor on Friday May 02 2014, @03:04PM

      by physicsmajor (1471) on Friday May 02 2014, @03:04PM (#38932)

      Doesn't work, because while that might be a relevant indicator for those of us in a Roman-character world, it's meaningless for the rest of the international character universe because it's always on.

      The flag isn't a bad idea, but you can find this anyway if you want through extensions (and it's often not what you think). Also, botnets etc. can easily obfuscate their addresses behind bit.ly or goo.gl links (always a terrible idea to click these) which resolve to IDN homographs reaching compromised machines in one's home country. Not very hard to do this based on the country of the requestor...

      If it's ignorable, it's useless (see: Vista user access control). I've yet to encounter a glanceable solution that actually increases security generally, for all users. The only solution is physically re-typing the exact address you think you see, using your own keyboard.

      • (Score: 1) by Aiwendil on Friday May 02 2014, @03:23PM

        by Aiwendil (531) on Friday May 02 2014, @03:23PM (#38940) Journal

        I live in a country (sweden) where the alphabet has three non-roman characters, so I'm aware it would cause lots of false positives - but it would at least give a heads up, in regions where utf8-domains are the norm it probably could be best solved simply by having a "language-specific whitelist" that warns if any character comes from outside this set - we still would have the 1/i/L-problem however, but it would reduce the number of things that easily gets past the radar.

        I was pondering about that, and yeah, having a split (diagnoally) flag probably would be better, with one half for the domain one is connected to, and the other half from where the most content is pulled/where the first non-redirect is located.

        Never used vista so I have no idea how its access control works. But in general the idea isn't security but rather to make things easier to spot (thereby nudging the bar ever so slighty higher)

        If your requirement is for all users pretty much nothing works. Just for kicks try to design a system that would work for the following three users: 1) a blind user 2) a deaf user 3) stephen hawkings

        But as stated - the point isn't security but rather to raise the bar slightly (pretty much the same as with all selfsigned and expired certs - no as safe as a current and verified cert, but a lot better than plaintext [as long as you remember that nothing is safe])

        • (Score: 0) by Anonymous Coward on Saturday May 03 2014, @12:31AM

          by Anonymous Coward on Saturday May 03 2014, @12:31AM (#39130)

          I don't think there is a need for a warning (in the web browser), if the domain registrars simply do not allow letters in domain names that look like other letters... in the swedish .se example the letters they allow are åäö and various accents, they also allow hebrew letters but they are not allowed in the same domain name as the latin characters so there is no risk of them being used to look like another character.

          (the web browsers do have a white list of domain registries that prevent IDN homograph attacks, showing punycode for others)

          • (Score: 1) by Aiwendil on Saturday May 03 2014, @12:32PM

            by Aiwendil (531) on Saturday May 03 2014, @12:32PM (#39216) Journal

            Interesting info about what .SE allows in their names - thanks.

            I used swedish as an exmaple of false positive with a utf8 warning.

            (For a thing I've stumbled over in japanese)
            A fun case where I would appreciate a warning for utf8 would be in the cases of dash/minus/ichi/hyphen , they are four different signs, and even when reducing "visually similar" we still have the problem with ichi (unless we plan on either banning japanese numerals or allowing equal-sings (ni)).
            This problem is compunded by the japanese habit of using arabic numerals instead of their own even when writing in kanji (so it makes sense to keep the minus/dash sign when writing in kanji, it also makes sense to keep the non-formal ichi-symbol, and it makes sense to keep them separate (and to just disallow the non-formal ichi would cause problems with 'ni' unless one plans to allow equal-signs, and then we have the question of how odd dash and equal would look next to 'san')).

            Then again, in this specific case it probably would be better to simply enough write utf8 and ascii in different colours - which probably is a better solution to being with.

            So, I retract my idea of having a 'red 8'-warning and replace it with an idea of simply showing utf8 and ascii-characters in different colors (or regular/bold).