URLに変わる新しい仕組みを模索するGoogle Chrome開発者ら 30
ストーリー by hylom
だからと言ってURLバーの表示変更はなあ 部門より
だからと言ってURLバーの表示変更はなあ 部門より
Googleは「URLのない世界」を目指しているとWIREDが主張している。
Google Chrome 69では「www」や「m」などのサブドメインが含まれたURLについて、URLバー内でURLのこれらのサブドメイン部分を非表示にするという変更が行われたが（窓の杜）、Googleの開発者らは現行のURLの表示方法に対し疑問を持っているそうだ。Chromeの開発者の1人は「いまのままのURLではだめ」と明確に語っており、現行のURLというシステムに対しては強い不満があることは確かのようだ。ただ、具体的にどうするのが良いのかはまだ検討中だという。
新たなInternet Explorer (スコア:2, 興味深い)
周りのコンセンサスを得ずにこういうことを考え実装までするから、
新たなInternet Explorerになりつつある [it.srad.jp]って言われるんでしょ
もしや (スコア:2, すばらしい洞察)
「直リンク」を根絶して導線をGoogle経由にしようと企んでないか？
Re: (スコア:0)
全てのURLにgoo.gl短縮アドレスを割り振って、URLには goo.gl/ナントカ しか出なくする、そんな未来が待っているの？
Re: (スコア:0)
goo.gl短縮サービスは廃止予定です
Re: (スコア:0)
でないに決まってる。
でなくても総ての通信はグーグル様のサーバーを経由するのだ。グーグルのサーバは「」となるのだ。
ttps://xxx.yyy.com/ は将来においては ttps://google.com/xxx.yyy.com/ と等価になるのだ。サブドメインの非表示はその布石。
# うんそれただの強制プロクシ
ディレクトリ型 (スコア:1)
一周回ってポータルサイト時代に
IPv6でいいんじゃね？ (スコア:1)
URLという文字列に意味を持たせないなら、アドレスはIPv6でいいよね。
問題になるのはアドレス指定に何を使うかではなくて、情報をどう扱うか。
最低限必要になるのは、アドレスに格納する情報を管理している組織・アカウントのネットにおける与信情報かな。
まず、ドメインみたいに時期によってオーナーが変わるみたいなことはあっちゃいけなくて、一度割り当てられたら永続的に使い続ける、あるいは使い捨てるものである必要がある。
その上で、企業や営利団体は信用度証明と健全性、できれば2値的な与信情報ではなく業種や実績、イデオロギーの方向性と一貫性、更新頻度といった複数のパラメータから総合的に判断できるようになっているのが望ましい。
この仕組みだと、新しく立ち上げる場合はanonymousと同じ扱いを受けるので、スタートアップからある程度信頼されるために、金を払って信用調査機関の審査を受けるみたいな仕組みも必要かな。
まあ、思想的にはたいがいビッグブラザーだと思うけど、それこそGoogleの目指すところだろうしね。
心の豊かさをHDDの中に求めれば、部屋なんて狭くても良い [srad.jp]
Re: (スコア:0)
ファイル1つ1つにまでユニークなアドレスを割り振るの？
Webページ作成時点ですんげえ大変そうなんだが。
作成時はパス指定で、コンパイルして(アドレスに変換して)アップするとか？
Re: (スコア:0)
THcomp？
Re: (スコア:0)
「アドレスに格納する情報を管理している組織・アカウント」の信頼度や「信用調査機関」の信頼度は人によって異なるので、
アクセスしようとしている人はそれらを確認できる必要があるよね。
できれば「アドレスに格納する情報を管理している組織・アカウント」は複数存在して利用者が選択できることが望ましい。
でも現状と何が違うのと言われるとそんなに違わないような気がする。
シンプルに行こう (スコア:0)
1. IPv4を駆逐する
2. DNSは無駄なので廃止
3. IP addressはUTF-128で表記する事を強制
Re: (スコア:0)
そうしよう
Re: (スコア:0)
3. IP addressはUTF-128で表記する事を強制
UTF-128ってRFCあるんですね [ietf.org]
# アニメじゃない
Re: (スコア:0)
1.2. Definitions
UTF-128
Short-name Tag
の後の
Emoji
Imoji
Amoji
Umoji
Omoji
ってのが気になるよ
Re: (スコア:0)
https://qiita.com/rana_kualu/items/2376eaedaaf4d15f70e2 [qiita.com]
文字コードとIPv6の諸問題を解決する次世代UNICODEの紹介
※2018年に公開されたRFC8369、Internationalizing IPv6 Using 128-Bit Unicodeの戸田奈津子訳
何が不満か分からない (スコア:0)
なので確認や解決のしようがない
Re: (スコア:0)
不満が社会全体にくすぶる前から、「もっと[いい/スマートな/シンプルな]やり方はないのか」と思いを巡らせるのがアレゲなのではないかと思う。
Re: (スコア:0)
たとえ現状に明確な問題点や不満があっても、現行以上に良い解決策があるとは限らないしね。
# 理想を追い求めるのは良いことだろうけど
# 具体的な対策なく現状を否定しても意味はない
Re: (スコア:0)
「Googleの開発者らは現行のURLの表示方法に対し疑問を持っているそうだ。Chromeの開発者の1人は「いまのままのURLではだめ」と明確に語っており、現行のURLというシステムに対しては強い不満があることは確かのようだ。」
対策どころか、疑問な点も分からない。
こんな話を気化されたこっちが、不満に思ってしまう。
Re: (スコア:0)
まぁ、「常識を疑え」というイノベーターなスタンスで、「URLに改良を施したいなあ」と言う意志をGoogle語で表現するとそうなるんだと思えばわからんでもないかも。
Re: (スコア:0)
コメント部分に反応するのは不粋かもしれませんが
># 理想を追い求めるのは良いことだろうけど
># 具体的な対策なく現状を否定しても意味はない
OSSのバグ報告にパッチが添付されてなければ意味はないの？
主にCPUなどのハードウェア製品のように、外部の人には対策することができない製品について、脆弱性などの欠陥を指摘することに意味はないの？
一般論として問題解決の第一歩は問題そのものの認識では？
Re: (スコア:0)
バグ報告の場合は、想定している正常な動作がまずあって、
それとは異なる動作をしているという報告なので具体性があります。
もちろん「落ちた！」とか「動かねえ！」とかいう曖昧すぎる報告は論外ですが、
「この機能でこうしたら、本来はこうなるはずがこうなった」などであれば十分でしょう。
件の話は「〇〇が使いづらいから改善しろ！」って言ってるだけ。
どう使いづらいのか、どう改善してほしいのかという具体性が全く無い意見。
Re: (スコア:0)
これを主導した若造に、何故OSIは全く普及せずTCP/IPが普及したか、こんこんと膝をつき合わせて教え込む必要があると思う
お前がちょっと考えたことは既に先人が十分に検討し尽くしてダメ出ししたことだ、ということを骨の髄まで知らしめねばならない
記事を読んで思った事 (スコア:0)
「URLと言う仕掛けそのものを変える話」と
「ブラウザ上でのURLの表現を変える話」が、
曖昧に混ざったまま話が進んでるように見える。
Chrome側の技術者が言ってるのは後者の話に見えるけど、記事は前者のニュアンスで話そうとしてるように見える。
そこ重要なんだからはっきりしろ
Re: (スコア:0)
自分が見ているのが見たいと思っていた物か確実に分かれば、方法はなんでも良いってことじゃないの
Re: (スコア:0)
うん、だから後者のニュアンスだよね。
でも前者の話に広げようとしてるように見える所に違和感あるなぁと。
Re: (スコア:0)
その２つの話が混ざってるのは、書いた人がURLやHTTP(S)についてきちんと理解してないので、切り分けが出来てないためだと思う。
URLにいたっては、「ドメイン名のようなもの」と誤解してる気がする。
URLスキームもHTTP(S)以外が有るとは思ってないんじゃないかな。
これでは、まともな話になるわけがない。
すぐに思い付くネタ (スコア:0)
どんなページにアクセスしても、example.comとしか表示されない設定のウェブサーバ。
m → 0
www → 1
として、's'なら、0x73(01110011b)だから、
https://example.com/s [example.com] → https://m.www.www.www.m.m.www.www.example.com/ [example.com]
とかこんな具合に。どんなページを表示させても、アドレス欄はhttps://example.comのまま。
ドメイン名の長さ制限であんまり長いのは無理か。
あとまあ、内部遷移を全部クッキーでやるというような既存の方法で、もっとちゃんとできるからネタとしても新鮮味がない。
Re: (スコア:0)
> 内部遷移を全部クッキーでやるというような既存の方法
はい？
Re: (スコア:0)
サーバではクッキーにサーバないパスが設定されていればそこを表示
リンクを踏まれたらクッキーに次のサーバ内パスを入れてリロード
これでURLバーは一定で中身は変わるページになるんじゃないですか