2026/07/11 17:21
あなたの「アプリ」がウェブページだったかもしれません（そのため、私が修正しました）
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
著者は、不必要にユーザーを追跡し、0.05MB のコンテンツのために 43MB のストレージを消費するディズニーの肥大化した「Travelbound」アプリを置き換えるための軽量で無料のウェブ代替案を開発しました。Android Studio 仮想デバイス、ルートアクセスツール、およびフェイク VPN を使用した HTTP Toolkit でトラフィックを傍受することで、このアプリが単に API を介して HTML ページを読み込んでいることが分かりました。具体的には、API がユーザー名とパスワードを URL に連結し、行程の区間、広告（「インスピレーション」）、画像アレイおよび PDF ファイルを含む JSON を返します。Cron によってスケジューリングされた Ruby スクリプトを使用することで、この新しいウェブページは侵入的な広告や Google の追跡を削除しながら最新のデータを直接取得します。高価なデプロイ戦略に依存し、コンテンツと共に 124MB に肥大化するオリジナルのモバイルアプリとは異なり、この解決策は既存のツアー認証情報を使用してパスワード保護付きで安全にホストされています。印刷、検索、ブックマークなど、重要な機能をすべて提供しつつ、ストレージコストやプライバシー侵害を伴うものではありません。結局のところ、このプロジェクトは複雑なモバイルアプリケーションはしばしばラップされたウェブサイトであるという事を示しています。主な教訓は、HTML 形式での標準 HTTP プロトコルを使用してコンテンツを配信することが業界標準となるべきであり、それによってユーザーが機密性と効率性を保ちながら重要な旅行情報にアクセスできるようにするというものです。
本文
アプリとは何か？「Travelbound」アプリの逆エンジニアリングと代替案
はじめに：なぜ「アプリ」でなければならないのか？
今年夏、子供たちの演劇学校が生徒たちをディズニーランドでショーのために歌わせ踊らせた。私たちも大興奮だったが、旅行計画や交通手段、宿泊情報が得られるために**「Travelbound」アプリのインストールが求められた**瞬間、私の期待は冷めた。
単なるウェブページで十分だった情報を、なぜまたしてもクソみたいなアプリをインストールしなければならないのか？
この「アプリ」は、文字通りテキスト、画像、PDF ファイルへのリンクを提供するだけであり、すべてがウェブを通じて配信されている。しかし、以下の特徴だけはウェブページにはない「悪機能」として検出された。
- 位置追跡データの送信: Google アカウントと関連付けられたデータを開発者に送信。
- 不要な広告の表示: 「インスピレーション」と名づけた代理店による他旅行案内の広告を表示。
全てがダメだ。ウェブページの方がずっと良かったはず。アプリに比べ、ウェブページは以下の特性を備えているためである。
- コピー＆ペースト可能
- 印刷可能
- ダウンロード・保存可能
- ブックマーク可能
- 検索可能
- ほぼあらゆるデバイスで利用可能
- （潜在的に）アクセシビリティが高い
私は怒りを抑えきれず、このアプリを独自に「修正（代替化）」することに決定した。
アプリトラフィックの傍受と解析
Android アプリのネットワークトラフィックから逆エンジニアリングを行うためのベストプラクティスを復習し、以下の手順で実施した。
1. Android エミュレーターの準備と Root 化
- Virtual Device Manager で新しい仮想デバイス（AVD）を作成。
が正常に動作することを確認。adb shell- デバイスを Root 化:
./rootAVD.sh system-images/android-33/google_apis_playstore/x86_64/ramdisk.img.2 - コールドブートを行い、Magisk を実行して設定を調整。どのアプリが
アクセスを要求しても自動で許可される状態にさせた。su
これで全てのアプリアプリフィックを自分に取り込める状態になった（Wireshark や TCPdump と同じ状態）。
2. HTTP Toolkit を介した傍受と解析
- HTTP Toolkitを実行し、AVD のトラフィックを傍受するように指示。ファイト的な VPN プロバイダーがインストールされ、スマホのトラフィックがプロキシ経由で流されるようになった。
- Play Store から「Travelbound」アプリをインストール。
- HTTP Toolkit を設定して、Travelbound アプリのトラフィックのみをプロキシするように調整（ノイズ削減のため）。
3. API エンドポイントの特定とデータ構造の解明
数分の試行錯誤で、アプリがユーザー名とパスワードを結合し、以下の形式の URL に使用していることを発見した。
https://travelbound.api.vamoos.com/api/itineraries/{username}-{password}
これによりJSON 形式のデータが返され、アプリが「表示する」すべてのコンテンツに対応することが判明した。具体的には以下の配列が含まれている。
- itinerary の各区間を含む配列
- 「インスピレーション」として提示される広告（他旅行案内）を含む配列
- その他セクションで参照されているファイル（画像など）を横断的にリスト化した配列
彼らは明らかに HTML コードを生成しているはずだ。なぜこれがウェブページではないのか？
少しの実験から、S3 上の画像 URL は比較的短い有効期限を持つことが明らかになったため、コンテンツが変わらなくてもJSON を定期的に再フェッチする必要があることがわかった。
より良いために転換：Ruby スクリプトによる HTML 生成
必要な情報すべてを手に入れた後、以下のスクリプトを Ruby で作成し、Cron スケジュールで稼働させて最新の JSON データを取得した。それに基づいて HTML ページを自動生成する。
コンテンツのフィルタリングと構成
「インスピレーション」（データスキーマ上の
overlayRows- itinerary の項目
- インスピレーションや itinerary で参照されていないすべてのファイル（PDF ダウンロードリンクの簡易的な集計）
当初はツアー参加者に渡されたパスワードを保護キーとして使用したが、使用する生 JSON データを
<details>結論：なぜ「アプリ文化」がダメなのか？
私の作成したウェブページは、情報源となったアプリほど「華やか」ではないかもしれないが、以下の点で圧倒的に優れた選択肢である。
- サイズ: アプリ（43MB）に対して、0.05MBの軽量さ。
- 注: オプションで画像を追加するとアプリ側は 124MB に膨れ上がるが、ウェブページは必要に応じて追加が可能（最大 35MB 追加可能）。
- 機能: コピー、印刷、ダウンロード、ブックマークなどの標準的なウェブ機能の恩恵を無料ですべて享受できる。
確かに一部の人は「アプリ」を好むのも……まあいいだろう。しかし、いくつかのアプリは本来ウェブページで十分だったはずだ。特に今回のように、すでに HTML で記述されたコンテンツを HTTP プロトコルを通じて配信しているものにおいては、それは間違いなくウェブページの領域のはずだ。
いかにして私たちはこのように「アプリ文化」に進化してしまったのか、理解に苦しむ。ソフトウェア企業は自らの生活を難しくし、コストを増大させる（大手アプリストアへのデプロイは無償ではない！）ことで、本来ならウェブ直接向けにした場合よりも少ない人数に対して、さらに機能の制限された HTML コンテンツを配信することに満足しているのだ。
「アプリ」という媒体が絶対的に適切でなければならないタスクも確かに存在する。Travelbound はその対象ではない。
少なくとも今では、私自身だけでなく、共有した残りのグループメンバーも、コンテンツへのアクセス方法を自分で選択できるようになった。
- 位置追跡と広告つき、124MB のアプリ
- 0.05MB のウェブページ（より多くの機能を持ち、より多くのデバイスに対応）
どちらを使うか迷うことはない。決断だ！