Pref to Disable JavaScript During Web Import

EagleFiler
,
1

Michael,

I’m one of your approximately 18 EagleFiler customers still running Snowy. Given the lack of security updates for Snowy, (and soon for Lion, and so on), I’m VERY worried about web browsing with JavaScript enabled, outside of currently maintained browsers like Chrome and Firefox.

Given that no matter how one adjusts the esoteric prefs, “EagleFiler always enables JavaScript when importing Web pages.”, this obviously worries me VERY much when importing web pages via efwebtool.

I assume this is a genuine security risk under Snowy, and other unsupported OS’s, though I could well be wrong.

I already do the vast majority of my web browsing with JavaScript disabled, so I’ve got no problem with EagleFiler web imports doing the same.

About 90% of my EagleFiler workflow involves web capture of pages to PDF. The only workaround I can find for what (I assume) to be a security risk in using efwebtool on Snowy is to Print the web pages to EagleFiler. However, this has the minor disadvantage of losing the incredibly convenient Import Panel, and the MAJOR disadvantage of losing the URL field in the captured record, which I rely upon, and is not user editable.

So, my request is to consider adding an Esoteric Pref to disable JavaScript during web capture for us 18 Snowy customers, and for future customers with unsupported OS’s. (Also unsure if there is a security reason to disable web Plug-ins during web capture, but if so, that would be an appreciated Esoteric Pref too.)

I do understand this is an edge-edge-case, and understand why you might not want to do work for a tiny number of customers. But with the yearly OS release schedule, this could end up affecting more customers in the future.

If I’m wrong about the security risks, please let me know. And if not, please consider my request.

Thanks for the lovely software,
-Chucky

2

You should still be able to get the options panel if you hold down the Option key when printing the PDF to EagleFiler.

Noted, thanks.

Plug-ins are already disabled in efwebtool. I was seeing crashes from Java and Flash, and there didn’t seem to be any benefit to enabling them.

I don’t recall hearing about any JavaScript security risks, but it’s certainly possible given the highly optimized (read: less safe) way that modern JavaScript engines work.

3

Thanks. Did not know that. Unfortunately, that still doesn’t fill in the URL field, which is not user-editable, and which I rely upon.

Thank you VERY MUCH for considering this. I bet us 18 would even pay for the fix, though I know that’s not the way you tend to handle paid upgrades.

Huh. I thought that was the way phishing malware attacks tended to work. Send the user to a malicious site, where some known or 0-day JavaScript malicious exploit would plant the malware. But I could very well be wrong about that; my JavaScript fears with no-longer-supported browsers (or even up-to-date browsers in extreme cases) could indeed be far off the mark.

And again, thanks for the lovely software.
-Chucky

4

Right. Safari will only include the URL if you tell it to print it in-band in the page footer.

5

Yeah, I’m aware of that option of preserving the metadata, though using OmniWeb (!), not Safari. And I do employ it when I print to EagleFiler.

Unfortunately, my standard workflow is to save web pages to PDF, and then when I want to read them from EagleFiler, using Record -> Open Source URL to seamlessly open and read them in my browser. I’ve even bound the easy-access F1 keystroke to that menu selection, since I use it so frequently. Manually fishing out the URL from the PDF, and manually moving it back to the browser, while it does work, makes the whole workflow so cumbersome and time-consuming that I’ve drastically cut back on my EagleFiler use.

And yet again, perhaps I’m just being needlessly paranoid about JavaScript vulnerabilities in no-longer-supported browsers and web capture tools that rely on no-longer-supported frameworks. I’m nowhere near 100% certain of my suspicions here. But FWIW, quite a few of Apple’s various Security Updates include JavaScript fixes, not to mention the various chatter I read about in the press.

6

Send me an e-mail if you want to get on the beta list and test out JavaScript-free importing.

7

Sorry for the delay. Email sent.

8

EagleFiler 1.6.3 adds the EnableJavaScriptForWebTool esoteric preference.

9

Ugh. I’m a lousy beta tester when busy. (But I’m actually a very good beta tester when not busy.) Obviously, I’ve been busy of late.

Finally noticed the release, and downloaded 1.6.3. In some short usage, my suggested fix seems successfully implemented. Thank you. Thank you very much.

My only (very late beta tester) note would be that you at some point should correct the documentation of the EnableJavaScript esoteric preference, which still claims that EF always enables JS during web imports. Very minor point, but probably worth correcting in 1.6.4 anyway.

Otherwise, it’s a nice update. I’ve been using 1.5.4, since I’d been assuming most recent updates weren’t really concerned with Snowy. But there have been some nice changes anyway. Particularly appreciate that files now get stored in the Finder with the file name of my manually chosen title, rather than the default title, which I used to have to manually correct via AppleScript. Kudos, Michael.

10

Will do. Thanks.

There’s been a ton of changes since 1.5.4 that make things better on Snow Leopard. I recommend that everyone with an Intel-based Mac update.