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: 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).