Firefox 88 Released With FTP Support Disabled, Support For JavaScript In PDFs

[birdie]

Why they are removing support for FTP????

What's wrong with FTP????

The fact that Dropbox doesn't support FTP means that Dropbox should support it, not that we should drop it

FTP allows MITM. End of story. This protocol is good for LAN file delivery, for other use cases it's a huge unwarranted risk. I won't miss it.

Besides Firefox totally sucks as an FTP client - you cannot upload/delete/rename/edit files, you cannot select individual files to download. Use any dedicated FTP client instead.

[Mathias]

I don't think JS in PDF is a security issue [edit: in Firefox] if you download the file from the web, since that website executes far more JS anyways. IMO using JS in PDF forms to check validity is not a bad usecase. Any more interactivity and I'd switch to something called HTML5.

If you want researchers to publish interactive stuff, give them a website. Why should they be limited to Paper-sized stuff?

[bosjc]

According to this website: https://9to5linux.com/firefox-88-is-...ntel-amd-users the ball has been moved down the field in that direction.



But I can neither confirm nor deny these allegations.

Yeah, seems to be working on my all AMD system on KDE now. Also on my laptop using the official optimus support and intel GPU. Wonder when they will turn it on for nvidia only? I also wonder if they still have any more big performance stuff in the pipeline with servo kind of dead?

[tildearrow]

Why they are removing support for FTP????

What's wrong with FTP????

The fact that Dropbox doesn't support FTP means that Dropbox should support it, not that we should drop it

Applying encryption to FTP is a rather obscure thing (and passwords are still sent in plain-text).
The protocol itself is slow for initiating a file transfer (6-7 commands, versus HTTP which is 1 command).
Sure, with FTP you can manipulate files, but I would rather use SFTP instead...

The demoscene will miss FTP...

[tildearrow]

I don't think JS in PDF is a security issue if you download the file from the web, since that website executes far more JS anyways. IMO using JS in PDF forms to check validity is not a bad usecase. Any more interactivity and I'd switch to something called HTML5.

If you want researchers to publish interactive stuff, give them a website. Why should they be limited to Paper-sized stuff?

JavaScript in PDF means two things:
- Potentially unprintable documents (paper can't run code)
- You know how vulnerable PDF has been in the past with exploits here and there. Expect another exploit the next year.

[tildearrow]

There is a fair bit that is wrong with FTP. The inane binary/ascii distinction, the active mode or a RFC that is full of MAY and SHOULD, to name but a few.

Anyway, what is the point of it today when we have webdav, why would you want to use it?

Agreed. One day I struggled to download a driver over FTP because for some reason the file was corrupted.

[Mathias]

- Potentially unprintable documents (paper can't run code)

As long as it is just used to verify Form inputs, I see no problem there.

- You know how vulnerable PDF has been in the past with exploits here and there. Expect another exploit the next year.

I edited my comment, I meant only in the context of Firefox (or Chrome). I agree that ShitPDF Pro will probably be less secure if they support JS. So in general, supporting JS in PDF will result in less security for users of unsecure, not updated readers.

[tildearrow]

As long as it is just used to verify Form inputs, I see no problem there.

DRM to hinder book printing

I edited my comment, I meant only in the context of Firefox (or Chrome). I agree that ShitPDF Pro will probably be less secure if they support JS. So in general, supporting JS in PDF will result in less security for users of unsecure, not updated readers.

Sadly, ShitPDF Pro still being bundled on installers that come with hardware...
And what about Android, in where Chrome cannot expose its own PDF reader?
And what about iOS, in where PDF exploits were found to jailbreak or insert malware at root level?

[lucrus]

The JavaScript thing doesn't really make it any less secure since the browser already executes JavaScript on webpages.

The perceived security problem here is different. PDF files are commonly sent as email attachments, while webpages with JS code are not, because a webpage with JS code not being served directly by a webserver is almost useless.

Once the user opens a PDF attachment, its JS code runs in whatever PDF reader the user happens to have installed, and the security bounds aren't necessarily the same as those of the browser running JS code, potentially providing a new attack vector in the form of mail phishing + PDF attachments.

All that ovbiously has nothing to do with Firefox, but many commentors here didn't know JS code in PDF files already existed, so reading this article made them assume it was a Firefox invention opening up all sorts of zero day exploits.

The thing that renders the PDF is the JavaScript library pdf.js, so it is all JavaScript anyways.

Yes, but, on the other hand, that does not mean that the attack surface of a plain PDF file is the same as the attack surface of a scripted one.

[Mathias]

DRM to hinder book printing

Is it really used that way? Seems like a veeeery weak DRM.

Sadly, ShitPDF Pro still being bundled on installers that come with hardware...
And what about Android, in where Chrome cannot expose its own PDF reader?
And what about iOS, in where PDF exploits were found to jailbreak or insert malware at root level?

Like I said, my comment was meant in the context of browser based PDF readers. I agree that it can be a problem with everything else and thus it can be a problem.

I don't know much about JS in PDF, but I think one could define a well defined JS subset (maybe borrow from asm.js?) that is easy to parse and implement a pretty secure JS Interpreter (!), maybe in Rust that is tiny, secure and fast enough for form validation. But they probably defined full blown JS with all it's quirks handling...