アドレスバー

アドレスバー

[38] アドレスバーは、表示中の WebページURL利用者に提示したり、利用者URL を記入して navigate を指示したりできる Webブラウザー利用者インターフェイス部品です。

[39] ほとんどの Webブラウザーが何らかの形のアドレスバーを実装しています。 しかしその形態は様々です。 URL をそのまま表示するものもあれば、各部に分解して利用者にわかりやすく (と当該 Webブラウザー開発者が信じる形で) 表示するものもあります。 利用者からの指示には URL だけでなく、不完全な URL のようなものや、 検索エンジン用の検索キーワードを利用できるのも一般的です。

仕様書

URL の利用者への提示

[117] Webブラウザーアドレスバーにおける URL の表示は、利用者Webサイトの提供元を確認するための重要な情報と考えられています。

[116] Webブラウザーや任意の起源を表示できる埋め込みブラウザーなどでは、 URL を表示できないとしたらセキュリティー上の致命的な不具合であると考えられています。

[113] URL の利用者親和性の項も参照。

[115] スラッシュドット ジャパン | ユーザーの意識からURLが消滅する日は近い? <http://slashdot.jp/article.pl?sid=06/10/17/1950226&from=rss> (名無しさん 2006-10-20 00:27:03 +00:00)

service identity

[9] service identity, EV も参照。

利用者による navigate の指示

[11] 普通、アドレスバー利用者が編集可能で、利用者が入力して指示すると、 その入力に従い navigate が開始されます。

[12] 現在の多くの Webブラウザーは、 Enter を指示の手段として採用しています。 Webブラウザーによっては、別途移動を指示するボタンが用意されています。

[13] 多くの Webブラウザーは、入力と同時に自動補完候補が表示され、 そちらの選択によっても navigate が開始されます。

[29] 直接の入力だけでなく、 URLホストテキストとしてアドレスバードラッグアンドドロップしたり、 リンクアドレスバードラッグアンドドロップしたりすることでも、 navigate を開始できるかもしれません。

[42] クリップボードURL を使って navigate する手段を提供する Webブラウザーもあります。 クリップボードの値が URL でない時は検索エンジンのキーワードとして使えることもあります。

[14] 多くの Webブラウザーは、実装依存の方法により、入力を

... のいずれかと判断します。判断のために名前解決が成功するか調べたり、 履歴を探したりするものもあります。

[50] ホスト名:ポート のような文字列を与えると、 http:// を補うのが一般的です。

[15] これまでの Webブラウザーは、 URL scheme が省略された時、 http: URL と仮定していました。 (あるいはドメイン名ftp. から始まると ftp:、といったような推測を行っていました。) HTTPS 化が進む現状を鑑みると、これからはまず https: への接続を試み、失敗した場合に http: を試すのが良さそうです。

[16] 利用者を騙して悪意ある JavaScript コードを実行させる指示に利用者が従った場合に備えて、 javascript: など特定の URL の入力やコピペを制限する Webブラウザーもあります。

[17] アドレスバーからの navigate は、ハイパーリンクをたどる場合などとは異なり、 閲覧文脈で現在表示中のWebページとは独立に実行されるものですから、 Referer: などは送信されません。しかし現在表示中の Webページbeforeunload が実行されるなど、通常の navigate 発生時の処理は行われますから、まったく無関係というわけでもありません。

[19] 特に、新しい URL素片識別子を除いて現在の閲覧文脈活性文書URLと同じ場合には、 素片識別子へのnavigateとなります。 (Webブラウザーによっては、 そうではなく完全に新しい navigate となることもありますが。)

詳細は navigate を参照。

[18] 新しい URL が現在の閲覧文脈活性文書URLとまったく同じ場合には、 Webブラウザーにより、普通の navigate となることもあれば、 再読込相当の処理となることもあります。

navigate による更新

[20] 普通、 navigateアドレスバーは最新の URL へと更新されます。

[21] ただし、利用者アドレスバーを編集中の場合、 利用者の編集を破棄して新しい URL に変えてしまうと、 利用者は困るかもしれません。

[25] 特に Refreshlocation.href著者が勝手に navigate すると大変です。

[22] とはいえ、利用者が編集した後取り止めて放置してから、 何度 navigate しても表示が変わらないのでは、これもかえって利用者を困惑させるかもしれません。

[23]Webブラウザーはそれぞれ、利用者が変更した内容にまだ興味を持っているかを適当な基準で推定したり、 編集が入ったら表示を少し変更したりと、工夫しているようです。 それでも利用者が困惑することはたまにあります。

[24] 新しい URL に書き換わった場合でも、 Ctrl + Z などの元に戻す操作で、 編集中だった元の状態に戻せることがあります。

セキュリティーの表示

[32] Opportunistic Security for HTTP/2 により http: URLTLS を使って取得した場合であっても、 https: URL のような表示としてはなりません >>31

[33] Chrome は、 TLS により安全かどうかの表示の部分で、 chrome: のような特別な URL scheme のとき、 https: とも http: とも違う特別な表示を行います。

先読み

[34] 利用者が入力を進めるに応じて、あるいは自動補完候補の選択の兆しを見せるのに合わせて、 先読みを始める Webブラウザーもあります。

[35] Webページ上での指定における dns-prefetchprefetch に相当する動作と考えられます。

favicon

[40] アドレスバーfavicon を表示する Webブラウザーもあります。

favicon も参照。

busy indicator

[41] アドレスバー近辺に busy indicator を表示する Webブラウザーもあります。

busy indicator も参照。

歴史

[4]

Location Bar is a widget in a Web user agent's user interface which displays (and often allows input of) the textual location (entered as a URI) of the resource being requested (or displayed - after the response is received).

[1] Hacking for Christ: Location Bar Proposal (2007-02-17 12:04:48 +09:00 版) <http://weblogs.mozillazine.org/gerv/archives/2007/02/location_bar_proposal.html> (名無しさん 2007-02-17 03:07:22 +00:00)

[2] Taken SPC : 翻訳: ロケーションバーの提案 (2007-02-17 12:05:20 +09:00 版) <http://taken.s101.xrea.com/blog/article.php?id=722> (名無しさん 2007-02-17 03:13:16 +00:00)

[3] IT戦記 - ロケーションバーに直入力するとブクマを見に行って補完してくれるコンポーネント作った ( 版) <http://d.hatena.ne.jp/amachang/20070827/1188237639>

[5] Web Security Context: User Interface Guidelines ( 版) <http://www.w3.org/TR/wsc-ui/#IdentitySignal>

User agents MUST make information about the identity of the Web site that a user interacts with available. This [Definition: identity signal ] SHOULD be part of primary user interface during usage modes which entail the presence of signaling to the user beyond only presenting page content. Otherwise, it MUST be available through secondary user interface.

[6] EV SSL も参照。

[7] cURL - How To Use ( ()) <https://curl.haxx.se/docs/manpage.html>

If you specify URL without protocol:// prefix, curl will attempt to guess what protocol you might want. It will then default to HTTP but try other protocols based on often-used host name prefixes. For example, for host names starting with "ftp." curl will assume you want to speak FTP.

curl will do its best to use what you pass to it as a URL. It is not trying to validate it as a syntactically correct URL by any means but is instead very liberal with what it accepts.

[8] Chromeアドレスバーを無編集のまま Enter すると、 再読み込みとみなされるのか、 Cache-Control: max-age=0 が付くようです。

[10] Chromium Blog: Moving Towards a More Secure Web ( ()) <http://blog.chromium.org/2016/09/moving-towards-more-secure-web.html>

Historically, Chrome has not explicitly labelled HTTP connections as non-secure. Beginning in January 2017 (Chrome 56), we’ll mark HTTP sites that transmit passwords or credit cards as non-secure, as part of a long-term plan to mark all HTTP sites as non-secure. 

[26] Avoiding the Not Secure Warning in Chrome  |  Web  |  Google Developers () <https://developers.google.com/web/updates/2016/10/avoid-not-secure-warn>

[27] 産総研 RCIS: プロトコルの設計に関する詳細のFAQ () <https://www.rcis.aist.go.jp/special/MutualAuth/faq/detail-ja.html#chrome>

たしかに、2004 年ごろに流行したフィッシングの手口では、アドレスバーの上に枠のないウィンドウを乗せる手法により、偽サイト上でアドレスバーに本物サイトのアドレスを表示していました。しかし、これは、Windows XP SP1 (Service Pack 1) の Internet Explorer 6 SP1 を使用した場合に可能なことで、その後にリリースされた Windows XP SP2 や、Internet Explorer 6 SP2 では、そのような偽装ができないよう対策されています。

[28] Google Online Security Blog: Next Steps Toward More Connection Security () <https://security.googleblog.com/2017/04/next-steps-toward-more-connection.html>

[30] 909326 - [UX] Overhaul the site identity and connection information in the identity panel () <https://bugzilla.mozilla.org/show_bug.cgi?id=909326>

[36] 9月の月例更新でInternet Explorerの検索ボックスが復活 | スラド IT () <https://it.srad.jp/story/17/09/16/024245/>

[37] Internet Explorerのアドレスバーに入力した内容をWebページが読み取れるバグ | スラド セキュリティ () <https://security.srad.jp/story/17/09/30/1832253/>

[43] New in Chrome 62  |  Web  |  Google Developers () <https://developers.google.com/web/updates/2017/10/nic62>

[44] EV証明書を使用して既知の企業になりすませる可能性が指摘される | スラド セキュリティ () <https://security.srad.jp/story/17/12/15/2110233/>

[45] Release Notes for Safari Technology Preview 46 | WebKit () <https://webkit.org/blog/8042/release-notes-for-safari-technology-preview-46/>

[46] Firefox Focus Adds Quick Access Without Sacrificing Users’ Privacy - The Mozilla Blog () <https://blog.mozilla.org/blog/2017/12/13/firefox-focus-adds-quick-access-without-sacrificing-users-privacy/>

[47] Chromium Blog: A secure web is here to stay () <https://blog.chromium.org/2018/02/a-secure-web-is-here-to-stay.html>

Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as “not secure”.

[48] Proposal: FetchEvent.navigationLoadType · Issue #1167 · w3c/ServiceWorker () <https://github.com/w3c/ServiceWorker/issues/1167>

[49] Chromium Blog: Evolving Chrome's security indicators () <https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html>

[51] 881410 - Incorrect transforms when stripping subdomains - chromium - Monorail () <https://bugs.chromium.org/p/chromium/issues/detail?id=881410>

[52] やまざきkei5さんのツイート: "Chrome 69 のアドレスバーで、URLのホスト名部分の「www」や「m」が表示省略される件、いくつでも消えるし、間にあっても消えるのね。「http:// https://t.co/ENCotKKZmf」が「https://t.co/XNf4qCOXck」に見える。もしmやwwwというサブドメインが取れる状況があれば、なりすましに使えそう。" () <https://twitter.com/ymzkei5/status/1037961591461826561>