Url on akky@サイボウズラボ・ブログ

Secret Rickroll - 「リックロール」偽装URLを作るwebサービス

Wed, 16 Mar 2022 00:00:00 +0000

Secret Rickroll は、Rickroll とわかりにくいURLで Rickroll を見せるための単機能サービスです。

リックロール (Rickroll) とは、リック・アストリーの1987年の楽曲「ギヴ・ユー・アップ」のミュージック・ビデオへの釣りリンクをクリックし、この動画を観て感銘を受けることをいう。

リックロール - Wikipedia

Wikipedia の説明までなんかおかしくなってますが(そのうち直されそう)、2007-2008年頃から爆発的に流行してインターネット・ミームとなったRickroll、落ち着きつつも今でも油断すると連れていかれる息の長いミームです。

ジェネレータ上で、ニセのタイトルやページの説明、プレビュー画像やページ名などを入力すると、OGPでそれらを表示しつつ、実際には Rickroll を流すページを生成してくれます。

一つ作ってみたサンプルのURLがこれ。

https://www.tomorrowtides.com/how-to-say-hello-in-japan.html

チャットなどプレビューができる場所で投稿すると、こんな風にまったく関係のない別のページへのリンクに見えます。

生成されたURLのドメインが作るたびに違うものが出てくるので、ドメイン名から簡単に身破られないようにもなっていますね。ドメインをいくつ使ってるかわかりませんがぜったいRickrollさせるぞ、という執念を感じます。

作られたページは、72時間後には消えるそうです。

サイトのソースコードもGitHubで公開されています。類似の釣りページ作成サービスを作れますね。

via reddit

Hacker News のリンクに "1" をつけることでOGPやTwitter Card を良さげにする転送サービス

Wed, 09 Mar 2022 00:00:00 +0000

statico/ycombinator1.com は、英語圏の有名IT掲示板 Hacker News の URL に対し、SNS で共有した際に表示されるプレビュー情報を拡張する、という単機能のサービスです。

Hacker News 掲示版の各スレッドの URL は “news.ycombinator.com” というドメインで提供されていますが、“news.ycombinator1.com” と1を追加すると、Hacker News の運営とはまったく関係ないこの方のサービスにつながります。そこで行われることはというと

OGP や Twitter Card などプレビューで使われる情報を増やした html を返す
訪問者が一般のブラウザなら、オリジナルの Hackre News のスレッドへ転送する

リンクを見に行った人間のユーザーは、これまで通りの Hacker News に行けますが、twitter や Facebook などのSNS、Slack や Skype などのメッセンジャーなどでリンクを貼られた際は、拡張されたプレビューが表示される、というわけです。

ツイッターで、オリジナルのURLを貼った場合にはプレビューは出ませんが、1つきのURLにすると記事のタイトル、votes や comments の数などの情報が出ます。

Slack でも同様。1をつけてURLを貼ると、チャット相手はリンクを開かなくても少し詳しい情報を得ることができます。

GitHub Pages で static な短縮URLサイト作成

Tue, 17 Nov 2020 00:00:00 +0000

nelsontky/gh-pages-url-shortener は、GitHub の静的ファイル公開機能 GitHub Pages を使った、短縮URLホスティングです。

clone して自分でもホストしてみました。s.akimoto.jp の DNS が GitHub Pages を指すように設定します。

https://s.akimoto.jp/ (説明用の index.html が開きます)

そして、GitHub issues にタイトルがURLになる issue を投げる

と、 issue 番号⇒URL の転送が実施されます。

https://s.akimoto.jp/1 ( issue のタイトルに書いた別のアドレスへ転送されます)

その動作原理は

CNAME で gh-pages ブランチを指させる
(短縮URLのパス)すべては 404.html に渡される
GitHub issues から JSON API でURL転換情報を JavaScript が取得し、(それに従って)転送
役に立つ?

ということ。なるほど。GitHub issues を、転送用の lookup table として使っているわけですね。この後転送したい短縮URLを増やすのは、issue を発行すればよいということです。更新や削除も同様。面白い事考えるなあ。

# GitHub API の公開アクセスには60回/時間の制限が掛かっているので、実用的には使えないでしょう。

via Hacker News

Link to Text Fragment - Googleによるウェブページの任意の場所をリンクできるブラウザ拡張

Thu, 18 Jun 2020 00:00:00 +0000

新しいLink to Text Fragment Google社自身によってリリースされた、ウェブサイトの好きな箇所をURL化して共有できるChrome拡張です。

拡張をインストールした状態でページ上のテキストを選択し、右クリックメニューを出すと、Copy Link to Selected Text (選択されたテキストへのリンクをコピー)というメニューが増えています。

ここでクリップボードに取得されたURLを Chrome ブラウザ上で開いてみると、

先ほどリンクを作成したwebページが開かれた上で、選択していた部分が黄色くハイライトされ、ページもそのハイライトされた部分までスクロールした状態で開かれます。

選択するテキストが短すぎると、URLが作れない、というエラーが出ます。

利用シーン

これまで、他人が作ったウェブサイトのURLを他の人と共有することはできても「この特定の部分を見せたい」というのは難しかったと思います。やるとすればページを開いた後にページ内検索で"○○○“を探して、とかでしょうか。

最新のブラウザとこの拡張を使えば、ページの特定の箇所をはっきりと示して共有できるため、長いページのある特定の箇所を素早く見てもらいたい、といった作業が効率化されるでしょう。

受ける側はブラウザが最新のバージョンであればこの拡張は不要です。Chrome を随時アップデートしている相手なら問題ないでしょう。

仕組み

Chrome バージョン80 から使えるようになった、Text URL Fragments の機能を使ったものだそうです。

コピーされたURLの後ろに、選択した文字列を含む文字列が追加されていますね。

日頃、チャットツールや社内のグループウェアなどでネット上のウェブページを紹介することが多い人などにとって、紹介の質が上がる良いツールなのではないかと思いました。

via The Verge

JSONCrush - JSONをURIに圧縮して載せるためのライブラリ

Thu, 28 Nov 2019 00:00:00 +0000

KilledByAPixel/JSONCrush は、JSONをURLに載せやすい形に変換するライブラリです。

JSONCrushのデモサイト。JSON形式のデータを左上に入力すると、それをテキストとして圧縮し(↓)、さらにURIとして使える文字に縁故度しています(→)。

今回入れてみたJSONでは、そのままURIエンコードした場合に比べて52%、約半分のサイズとなりました。

URLにユーザーが入力した結果のJSONデータをなるべく小さくして載せるというのがライブラリの目的です。URLに再現のためのパラメータが全部載っていれば、結果をブックマークしてもらえばいつでも同じパラメータのページが再現できます。サーバーサイドでいろいろ面倒な処理をして覚えておく必要がありません。

そのままURLEncodeする手もあるけど、URLのサイズ上限(2000バイトちょっと)に引っ掛かるのは避けたい、と。HTTPパラメータとして個別に受け取ればもっとコンパクトにできるのでしょうけど、JSONのまま渡せるのは場合によっては楽なのでしょう。作り手側に楽という意味ですが。

使ってるJSCrush ライブラリが変換部分を担っていて、これは特定の文字列内でテキストをエンコードしてくれるもののようです。JSCrushのデモサイトはこちら。

JSCrush は minify したものしかないらしく、その動作を解析してる人がいました。この解説によれば、JSCrushライブラリは、1KbyteのJavaScriptで何ができるか、というコードゴルフコンテストの2012年の作品で使われたものだそうです。

via Hacker News

Google検索結果のアドレスを貼り付けると「一回前の検索ワード」が漏れる事がある

Fri, 30 Oct 2015 00:00:00 +0000

ジェレミー・ルービンさんがブログで、グーグル検索した結果を共有した際に一つ前に調べたキーワードが共有先に漏れる場合があると伝えています。

再現手順はこんな感じ。

ChromeやFirefoxブラウザのアドレスバーで「最初の検索」で検索
検索結果のページの検索ボックスで「次の検索」で検索
アドレスバーのURLの中に、「最初の検索」と「次の検索」の両方が入っている

検索キーワードが日本語などの場合は、URL中の表示はエンコードされてそのままでは日本語として読めない場合がありますが、これは変換して戻そうと思えば簡単にできます。

アドレスバーに、「最初の検索」が出ています。

簡単に確かめたいならアルファベットや数字だけで上記の再現手順を試してもいいでしょう。URLに出てきた一番目の検索ワードをそのまま目視できます。

このアドレスをメール等にコピー＆ペーストして送ってしまうと、「2番目の検索」で検索した結果を送ったつもりが、「最初の検索」という文字列もURLの中に含めて送ってしまうということです。

Internet Explorer でも、アドオンでアドレスバーの検索エンジンをGoogleにすると同じことになりますね。デフォルトのBing検索ではBingに行くので当然再現しませんが。

問題点と影響

ルービン氏の場合は、友人から送られてきた検索結果のアドレスを見てこれに気づいたようですが、その時にURLに含まれていた前の検索ワードは、その友人が文章中に書いているとても一般的な単語だったということ。その友人は、そのとても基本的な単語の意味を調べないとその文章が書けなかったのかもしれない、とルービン氏は推測し、このように関係のない検索ワードが他人に漏れてしまうのは恥ずかしい場合もあるだろう、と述べています。

簡単な単語の意味を調べてたぐらいならまだしも、検索してるのが人に知られたらもっと恥ずかしいキーワードというのもあるでしょうね。

あまりひどいものはご紹介できないのですが、これは2chから見つけたもの。

「金田一一」を検索した同じページで、続けて「金田一二三男」を検索し、それを掲示板に貼り付けたんですね。まあこのケースでは漏れたとしても害はありません。

これまでグーグル検索結果のページのURLを掲示板等に貼り付けたり、メールで他の人に送ったりした人は、もしわかるなら送ったURLに一つ前の検索ワードが含まれていないか、含まれていたとしたらバレて困るキーワードではないか、確認したほうがいいかもしれません。といっても、確認して困っても削除・撤回できない場合も多そうですけど。

完全ではないですが、たとえばGoogle検索で “www.google.co.jp/search?q=" を含めて検索すると、検索結果を貼り付けたページが見つかりますね。site: で限定すれば自分のブログを確認したりもできます。

検索結果を共有する機会、となると、ツイッターやFacebook の過去の書き込み、チャットサービスのログ、などもあるでしょう。

ルービン氏はこの問題についてグーグル社にも伝えたそうですが、「仕様です」「修正しません」という回答を受けたそうです。自分で気をつけないといけないようですね。

via Hacker News

Awesome Screenshot が閲覧したサイトのURLを収集している疑い

Fri, 22 Aug 2014 00:00:00 +0000

ブログ mig5.net のMiguel Jacqさんの記事によると、Chromeブラウザ用のスクリーンショット・ツールとして有名な Awesome Screenshot 拡張に、ユーザーの同意無しにユーザーがどのページに訪問したかをネットのどこかに送信する機能があるようです。

Jacq さんは、自分が管理するOSSECのサーバー上の Drupal の、ログインしないとアクセスできない管理画面の複数のURLに対して、“niki-bot"という名前のbotがアクセスしてくるのをアクセスログから発見しました。

外部から知りえないURLがアクセスされるからには、メンバーの誰かのクライアント側からURL情報が外部に漏れているのはと考えたチームは、内部で使われているブラウザ拡張を精査し、Diigo社のChrome拡張 Awesome Screenshot がURLをネットに対して送信していることを見つけた、ということです。

このAwesome Screenshot拡張、ブラウザ上で画面を画像として保存できる拡張機能で、日本語化もされています。メインの機能自体は使いやすいと評判が良いようで、日本語で推薦するブログ記事もいくつも見つかります。

しかし、この拡張をオンにしてウェブを閲覧していると、見ているページのURLが、Base64 エンコードを(なぜか2度)掛けて ld.crdui.com というドメインへ送られているというのです。

無関係なサーバに閲覧履歴を送る、なんてことをしているからには、当該部分のコードは、当然難読化されているのかと思いましたが、拡張のソースコードを見てみると tr.js というファイル中で送り先のURLや情報を送信するコードが隠されもせずに普通に読める形で書かれていますね。

SimilarWeb の元データ?

こちらのページでは、このAwesome Screenshot 拡張が7つもの外部のサーバにアクセスしていることを問題にしていますが、lb.crdui.com もこの7つのうちの1つで、webovernet.com にリダイレクトします。このwebovernet.com は SimilarWeb のサイトだと主張している人が複数います。

SimilarWeb は、「このサイトを見ている人はこちらのサイトも見ています」というのを調べたりできるwebサイトです。サイトのページビューや訪問者数などの推測データも出してくれる数少ないwebサービスですが、以前から、どうやって色々なサイトのアクセス数などをそこそこ正確に推測できているのか、不思議に思われていました。

もし、Awesome Screenshot などのブラウザ拡張が SimilarWeb にユーザーのアクセスしたURL情報を横流ししているとすれば、サイトのトラフィックを推測できるのも道理です。

冒頭のbot、niki-bot の使っていたIPアドレスが、以前にSimilarWeb.com の使っていたアドレスだったという証拠も出てきました。

以上から、niki-bot = crdui.com = SimilarWeb が同じ運営者によるものという可能性は高いでしょう。

スクリーンショットを撮るために、どうして訪問したサイトのURLを外部に送信しなければいけないのか、Awesome Screenshot のインストールページには説明がありませんし、このURL送信を止めるオプションも無いようです。

パスワードなどの認証ではなく、URLのアドレスをランダムで長い文字列にすることによって関係者にしか開かれないページを作ったり共有したりできるサービスも多いですが、こういった擬似的な秘密ページも、そのまま送られてしまっては秘密でなくなります。

AlexaのAPIを使う拡張などで、閲覧ページの情報を収集するようなものもありますが、ユーザーが把握していたり、前記のような秘密のURLの収集をしないように対策するなど、ある程度のセキュリティーへの配慮をしているものもあります。しかし、この Awesome Screenshot のように何も予告せずに勝手に集めるというのは問題でしょう。URL がわかると限定公開の意味がなくなってしまうようなサービスの訪問アドレスも区別無くすべて送っているとなれば、悪用される可能性もあります。

この拡張、URL以外のもの、例えばwebサイトで入力した内容までも送っているのでは、と言っている人もいますが、Jacq さんの調査ではURLしか送られていないようだということ。

アメリカ・メディアマップ - Twitterで共有される人気メディアとその地域性がわかるインタラクティブマップ

Fri, 04 Oct 2013 00:00:00 +0000

URL短縮サービスの大手 Bit.ly が公開したリアルタイム・メディア・マップ(Real-Time Media Map)は、アメリカ人がどんな新聞・雑誌・テレビ・オンラインメディアを読み、ツイッターなどで紹介しているかを一瞥できる、インタラクティブな可視化地図です。

オンラインニュース・ブログメディアの各州での一番人気を出したのが上の地図。地域により、一番読まれているメディアはバラバラですね。

現在最も読者が多いであろうハフィントンポストは、南部や中西部で強いですが、大都市圏ではあまり一番ではない様子。

起業やインターネットに強いTechCrunchは、シリコンバレーのあるカリフォルニアや、マイクロソフト、アマゾンなどが本社を持つワシントン州で強い。ライバルのMashableは、シカゴのあるイリノイやフロリダを押さえています。

首都周辺のバージニアやメリーランドでは政治系のニュースメディアPoliticoが一番。

エンターテインメント系のニュースの比率が多い印象のあるBuzfeedやTMZ、嘘のニュースで人気のThe Onion などは、田舎の州で強いようです。起業とかビジネスとかに興味のある人が割合的に少ないためなのでしょうね。

こちらはテレビ/ラジオ系サイトへの言及をまとめたもの。

南部で保守系のFoxが強いですね。ニューヨークやカリフォルニアではラジオ局NPRのニュースが多く言及されているようです。多くの田舎州で、イギリスのテレビ/ラジオ局であるBBCが一番話題にされているのは意外です。あと、ワシントン州でアルジャジーラが一位なのは何でしょうか。

元データが「Twitterユーザーでbit.lyでURLを短縮しているユーザーがつぶやくURL」に限定されているとはいえ、人気サービスですからそのツイート数は膨大なはずです。

「アメリカでは」といっても、地域によって人々に影響を与えるメディアは大きく違うのだなあというのがわかりますね。

via Maps Of The Most Popular News Outlets In Each State