So you’re planning on sourcing your own kiosk from somewhere and running data gathering on that? Do I understand that right?

No. But for answering my physics question it would not matter either way whether I own the kiosk.

My question is also general. There are different kiosks for different purposes by different companies.

Did you check whether you can just directly address the same API that a kiosk would talk to?

I do not control any of the kiosks that have the data of interest. And even if I did they would likely be running closed-source software. I also do not control the network that any of the kiosks are attached to, so no chance of probing the traffic to discover their API calls.

The APIs that the kiosks use could potentially be the same undisclosed/opaque API that their website uses -- we can only guess. But there are prejudices involved. The kiosks likely get different treatment for a number of reasons, based on their IP address, user-agent string, authentication creds, etc. I have never seen anti-bot junk on the kiosks that sell travel tickets. If I were to discover how to masquerade as a kiosk on some particular network, that’s a lot of work for a solution that would then only work on one particular vendor’s kiosk. It would be too specific to work on kiosks by other suppliers. Having a machine use the kiosk human UI would easily adapt to any kiosk.

I use SingleFile quite often. But it does not exactly provide the functionality I described.

It would be useful to tag a bookmarked page for offline access. That should simply be a toggle. The bookmark page would then be the UI for organising and controlling the offline content. From there, if I want a page to be organised in my file structure where it would then be reachable by other browsers, it would be useful to SingleFile offline pages while offline.

I just did a slightly more reliable test: disabled js in the FF settings (about:config→javascript.enabled=false). And the PDF was fetched and rendered with some delay.

It is clear from wget that the server is at least willing to push html,js,garbage that masquerades as a “pdf”. But I believe you are correct; that w/this sample URL, Mozilla is getting a true PDF based on some opaque judgment by the server.

So that URL turns out to be a bad example. I see this all the time though. I will have to start collecting more PDF URLs that push shenanigans until one reproduces Mozilla’s anti-user behavior.

It’s not a block page. It’s a file with a PDF extension but with HTML+js contents. This is a shitty trend that’s becoming a plague. If you do all your browsing with a GUI browser you will never notice it because both Firefox and Chromium are happy to execute whatever JavaScript they encounter.

The bug report is a year old so it’s possible cafevanbommel.nl changed. For me, the sample URL in that report fetches nothing at all. It gets ERROR 415: Unsupported Media Type. with that URL.

Try this:

$ wget 'https://www.lachambre.be/kvvcr/pdf_sections/pri/fiche/fr_12_00.pdf'
$ file fr_12_00.pdf
fr_12_00.pdf: HTML document, ASCII text, with very long lines (31237), with CRLF, LF line terminators

This fucks people up if they use a script to grab PDFs. I run a getpdf script that essentially does this:

$ torsocks wget --xattr "$url"
$ exiftool -config ~/tools/conf/ExifTool_config -xmp-xmp:srcurl='$url' "$filename"

That is a very useful way to fetch PDFs because it adds the URL of the PDF to the file’s metadata (redundantly, because --xattr info can be lost in some operations). So later if I want to recall where a PDF came from, such as to share the link with someone, I can just do: getfattr -d "$pdf".

So these motherfuckers who push fake PDFs force me to use a GUI to run their shitty surreptitious download management application just to simply get a PDF, which is loaded by pdf.js. Then I need to point, click, save the file. Then on the command line I have to go to whatever directory the file was saved in and manually run the metadata tools and copy-paste the URL.

The assholes have no idea what hassle this causes. But there are so few users smart enough to save metadata in the PDF that they can easily be marginalised. It’s yet another case where sophisticated users get burnt by enshitifying web admins who know they can nanny the unwitting masses.

ah; thanks for the explanation!

I appreciate the tip. It was alienating at first but after some fiddling it seems like a good option. My findings--

Pros

• It’s able to save a page as a single file which can be opened in both Firefox and Chromium browsers (rare!)
• It’s able to faithfully save a Github issue page that correctly renders when re-opened. (All other tools fail on a GH issue)
• The URL is embedded on the 3rd line of the file (rare.. no other tool does this)

Cons

• No control over where it saves the file
• Forced GUI, no commandline (though I’m not sure if it can be hacked to run automatically in a headless Firefox or something)
• No icon appears in the plugin tray. And cannot be added using the Firefox custom toolbar tool.
• Default keystroke is control-shift-y (which clashes with the stock keystroke for reaching about:downloads)
• There is no menu item for it

I was only able to get it to work by re-assigning a custom keystroke which I will forget and have to visit the addon manager to recall.