Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Brane215
    replied
    Originally posted by atomsymbol



    Are you aware that you (and everybody else) are running - on your machine locally - hundreds of thousands of lines of Javascript code in a sandbox VM every day when using the Internet? Javascript in PDF is also running in a sandbox VM.

    If a scientist publishes an article then Javascript in PDF will enable you - a 21st century reader - to play with various scenarios enabling you to grasp the content of the article more quickly and more profoundly. You can of course freely choose to remain a 20th century reader by disabling Javascript in all PDFs. Of course, it might take several decades for scientific articles to begin making a good use of interactivity in PDFs.
    PDF was meant as an electronic paper. Don't crap over it with JS.
    If we are to get rid of the paper, we need PDF as something that can conveniently replace it without nasty issues.

    As far as JS in VM goes, that is crap, too. Exploits that can breach it are used widely.

    Leave a comment:


  • kn00tcn
    replied
    Originally posted by tildearrow View Post
    Sure, with FTP you can manipulate files, but I would rather use SFTP instead...

    The demoscene will miss FTP...
    what WEB BROWSER let you manipulate files? did any have a local directory tree or functionality to batch/recursive download?? the demoscene has no relation to ftp in web browsers just because release pages contain mirror links that can easily open up a dedicated client set as the protocol handler... web browsers didnt exist when the demoscene started

    why is this thread full of people acting like the entirety of the ftp ecosystem is shutting down

    as for those claiming ftp let you view timestamps, that's a bit misleading since server time is still available on http files as seen by wget's default modified time of a downloaded file, or the web site can simply display a list of files with their times like a basic apache/nginx listing, or the web site could be nice & write in the times on the html page next to a file's download button

    but any ftp or http site can have incorrect or fake timestamps, so why would knowing them be that important, a sha256+ hash is more important


    Originally posted by TemplarGR View Post
    You can't be serious.... Embedding malicious code in various documents is one of the most popular ways of delivering malware. It is hilarious that you are mentioning MS-DOS, you have probably never used it or else you would have known this....
    you cant be serious... writing an absolutely counter-intuitive comment with a reference to ms-dos in 2021 is one of the most popular ways of delivering sarcasm, it's hilarious that you are reading it seriously, you have probably never seen comments on controversial topics or else you would have known this

    Leave a comment:


  • TemplarGR
    replied
    Originally posted by atomsymbol

    Why would it be a security issue? The days of unsecure operating environments like MS-DOS are over.
    You can't be serious.... Embedding malicious code in various documents is one of the most popular ways of delivering malware. It is hilarious that you are mentioning MS-DOS, you have probably never used it or else you would have known this....

    Leave a comment:


  • smitty3268
    replied
    Originally posted by tildearrow View Post

    Not yet, but here is the example.

    Blank document, and the pages are loaded after 1-2 seconds with a nice fade-in.
    Most PDF printers will print a blank document (before the JS kicks in), therefore hindering printing that document.

    Or even something more advanced, create a protected canvas upon loading that you cannot screenshot or record.
    Still may be bypassed by the analog medium, but becomes harder.
    Do publishers interested in DRM actually even use PDFs? I figured they'd just use epub or some proprietary format, rather than making it in PDF - just seems like you're asking for people to break it in that format.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by caligula View Post
    The main problem with pdf.js is its speed. It's ok for simple documents, but it becomes unbearably slow if you try to open some complex CAD documents, complex maps, etc.
    Honestly I thought pdf.js was the fastest (since it was built into Chromium)...

    Leave a comment:


  • Mathias
    replied
    Originally posted by tildearrow View Post
    What about the protected canvas method? Now that is impossible to bypass.
    Sure, if PDF specified a protected canvas that is better protected then DRM in Web browsers, sure then it is *impossible to bypass*. Which means it doesn't have an open source implementation and a mandated protected media path from the hardware decoder encrypted with the latest HDCP transfered to your monitor. I don't think Javascript is your problem then.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by Mathias View Post

    Sure that works. But it'll take like 5 minutes to modify *one* PDF reader (that supports JS) to wait 5 seconds before printing. PDF already has a no-print Password that is easily circumvented. Unless you have a security module like the browsers do, there is not much you can do to protect your documents - and even that one is not secure.
    5 minutes to find out about Chromium, 1 week to learn how to install Linux to build Chromium, 8 hours to build, 16GB RAM and 150GB disk space.
    Chromium takes forever to build...

    What about the protected canvas method? Now that is impossible to bypass.

    Leave a comment:


  • Mathias
    replied
    Originally posted by tildearrow View Post
    Not yet, but here is the example.
    Sure that works. But it'll take like 5 minutes to modify *one* PDF reader (that supports JS) to wait 5 seconds before printing. PDF already has a no-print Password that is easily circumvented. Unless you have a security module like the browsers do, there is not much you can do to protect your documents - and even that one is not secure.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by Mathias View Post
    Is it really used that way? Seems like a veeeery weak DRM.
    Not yet, but here is the example.

    Blank document, and the pages are loaded after 1-2 seconds with a nice fade-in.
    Most PDF printers will print a blank document (before the JS kicks in), therefore hindering printing that document.

    Or even something more advanced, create a protected canvas upon loading that you cannot screenshot or record.
    Still may be bypassed by the analog medium, but becomes harder.

    Leave a comment:


  • Mathias
    replied
    Originally posted by tildearrow View Post
    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...

    Leave a comment:

Working...
X