10 Second Teleportation

Could it be a "read it later" type of article reader/storage service? I know of at least one that fits the bill in that it uploads locally-viewed HTML to a server which then renders that page in a headless Chrome instance for archival:

I've recently been wondering how Omnivore, unlike e.g. Pocket, is able to store paywalled content (for which I have a subscription) on iOS when saving it via the Omnivore app target in the share sheet, but not when directly pasting the target URL in the webapp or iOS app.

Turns out that sharing to an iOS app actually enables [1] the app to run JavaScript in the Safari web context of the displayed page, including cookies and everything!

If I'm skimming the client and server source code correctly, it does just that: It seems to serialize and upload the HTML of the page [2] and then invokes Puppeteer on the server [3]. Puppeteer is a scriptable/headless Chrome – that would fit the bill of "an outdated Chrome running in a data center"!

Omnivore can also be self-hosted since both client and server are open-source; that would explain you seeing multiple data center IPs.

[1] https://developer.apple.com/library/archive/documentation/Ge...

[2] https://github.com/omnivore-app/omnivore/blob/main/apple/Sou...

[3] https://github.com/omnivore-app/omnivore/blob/57aca545388904...

Ex-PANW here. It's almost certainly the firewall's URL Filtering feature (aka PAN-DB).

When someone makes an HTTP request, the firewall takes the host and path from the request and looks them up first in a local cache on the data plane, then in the cloud. (As you can imagine, bypassing the entire feature is therefore trivial for malware. You just open a connection to an arbitrary IP address and put, say, google.com in the host header. As far as the firewall can tell, you are in fact talking to google.com.)

When the URL isn't already known to the cloud, or hasn't been visited more recently than its TTL, it goes into a queue to be refreshed by the crawler, which will make its way there shortly thereafter to classify the page.

Palo Alto has other URL scanners, but none that would reliably visit the page after the user. URLs carved out of SMTP traffic, for example, would mostly be visited before the real user, not after.

iOS has supported Safari extensions since iOS 15 (late 2021). There are far fewer extensions for Safari than Chrome or Firefox; they've been steadily adding more as Safari gets closer to the same Web Extension standard used by other browsers, but most developers still shun iOS support since the extension has to be wrapped in an iOS app rather than being loaded from the web.

https://support.apple.com/guide/iphone/get-extensions-iphab0...

Would that explain getting past an auth wall though, i.e. loading the HTML page as if the user were logged in but without auth headers and cookies?

You may be slightly misreading the write-up. Note the following two bits:

> What we found were user agents purporting to be from a range of devices including mobile devices, all only ever loading a single page without any existing state like cookies.

> The behavior itself is also strange, how did it load these pages which were often behind an authwall without ever logging in or having auth cookies?

I don't think they mean to say that pages behind authentication were successfully loaded without authenticating. If cookies are required to load the page, you aren't loading it without them. So I read this as "The sessions weren't authenticated, so where on earth did they even find these URLs?"

The answer is that there's a real, authenticated user behind a firewall, and every unknown URL this user visits is getting queued up for the crawler to classify later, query string and all. So the crawler's behavior looks like the user's, but offset by a few seconds and without any state. Presumably the auth wall is doing its job and rejecting these requests.