Reverse-engineering a travel 'app' back into the webpage it should've been

A developer bristled at being told to install a 43MB (eventually 124MB) Android app called Travelbound just to read a trip itinerary for a kids’ performing arts show. His objection: the app’s only distinguishing behaviors over a plain webpage were anti-features—reporting Google Account tracking data to the developers and pushing ads for the agency’s other trips, branded as ‘inspirations.’ A webpage, by contrast, would be searchable, printable, bookmarkable, more accessible, and usable on virtually any device.

To prove the point, he intercepted the app’s traffic using a rooted Android emulator and HTTP Toolkit, defeating certificate pinning by installing his own root CA. Within minutes he found the app simply hits a Vamoos API endpoint that embeds a shared group username and password directly in the URL and returns JSON containing the entire itinerary, the ad payload, and references to media files on S3 with short-lived signed URLs. That shared credential—one login for the whole tour group, transmitted in the path—hints at weak security thinking behind the app.

He then wrote a Ruby cron job to fetch the JSON, strip the ads and tracking, and generate a lightweight password-protected HTML page (0.05MB, plus optional images) that he shared with his group. The broader argument: much of ‘app culture’ is companies spending more money to ship HTML-over-HTTP content to fewer devices with fewer features and worse accessibility than a website would offer. Some tasks genuinely need a native app; delivering a static travel document is not one of them.