3 ms·

Things have gotten so complex that it's difficult to reason about security (even for experts). This is especially true when we're talking about JS code that is

Things have gotten so complex that it's difficult to reason about security (even for experts). This is especially true when we're talking about JS code that is running on the client and accepting untrusted input from the global Internet. Is the origin right? Are all the security headers correctly set? Is it even possible to keep up with all the stuff that is published, today, to sort of try and secure a web app? I don't think so. My approach is... no JavaScript (script-src 'none'). Just don't do it.

megadal 2y ago
Your approach to sandboxing browser PDF rendering is to just not do it..? You realize this particular problem requires JS to solve, right? It's not just there arbitrarily. That's like saying your approach to web application hardening is to disable all inbound connections. You quite necessarily need those for a web application. I can't see how this would be pragmatic or productive, or maybe it's not meant to be.
- amluto 2y ago
  > You realize this particular problem requires JS to solve, right? It's not just there arbitrarily. Most of the time, you get better results by just serving up the PDF as Content-Disposition: inline. 90% of JavaScript PDF viewers are crap (although PDF.js is decent), but the browser on all dignified platforms still does better than any fancy JavaScript I’ve ever seen. Loads faster, too.
  - deleted 2y ago
    [deleted]
  - megadal 2y ago
    People don't usually use PDF.js just to render PDFs. You can also extract text to use within a web application, preview a PDF, have users sign PDFs and fill forms in the browser (where their authenticated context resides) and a host of other things. I don't think anyone but a bored hobbyist is implementing or using a JS PDF renderer solely for rendering and the people who are using it for the aforementioned reasons don't care about load times, the document has to be processed somehow by the user agent. The suggestion that JS is optional here is nonsense and that the built in browser PDF renderer (written in a lower level language than JS) is faster is common knowledge. Again, I don't see how this suggestion is pragmatic or productive, but still, maybe we're not trying to be here.
    - kevin_thibedeau 2y ago
      PDF forms don't require JS.
      - megadal 2y ago
        They do if your want to fill them out in the browser coupled with an authenticated context, which is usually pretty important for forms. Usually you don't just want random users filling out any data within your enterprise. You also can prepopulate the form with user input from previous webpages/the user account. This is how a lot of HRISes do it. Usually people want onboarding to be as frictionless as possible. Downloading the PDF and using some editor outside the website then coming back to upload it counts as friction. And this conversation is still far away from the point: you need JS for a JS based PDF renderer, and there are valid uses cases where one is required.
        amluto 2y ago
        > They do if your want to fill them out in the browser coupled with an authenticated context, which is usually pretty important for forms. Usually you don't just want random users filling out any data within your enterprise. > Usually people want onboarding to be as frictionless as possible. Downloading the PDF and using some editor outside the website then coming back to upload it counts as friction. Wait, are you saying there's a workflow for which the most frictionless solution is to have the user fill out a PDF, on an authenticated website and submit the PDF in the browser? As opposed to, say, <form>? Can you elaborate?
        megadal 2y ago
        Tax documents. I'm going to discontinue this conversation though.
        amluto 2y ago
        I once had the displeasure of submitting a Form W-9 on an authenticated website. It was an unmitigated disaster involving one time codes distributed over email via a team of apparent actual people outsourced outside the US, a website, PDFs POSTed to said website, and marked-up copies of said PDFs emailed back by said outsourced team asking inane questions. And, presumably since the whole mess wasn’t actually machine-readable, the form still got entered wrong and incorrect tax forms were issued. It would have worked much better as an emailed PDF, or a simpler form. Or an ordinary non-PDF form that would generate a filled-in PDF that the user could then sign. > I'm going to discontinue this conversation though. Oh, well.
  - bguebert 2y ago
    I mean firefox's built in pdf reader is PDF.js. Also the desktop version of adobe reader used to run javascript embedded in pdfs by default as a "feature". I'm not sure you can get away from it at this point, but it would be nice to have the option to just use a desktop pdf reader that doesn't even support javascript or running any code embedded in the pdf. Maybe my use case is limited but I don't see the point of it. If you want interactivity you can use a website so people can expect that sort of stuff.

megadal 2y ago

Your approach to sandboxing browser PDF rendering is to just not do it..? You realize this particular problem requires JS to solve, right? It's not just there arbitrarily. That's like saying your approach to web application hardening is to disable all inbound connections. You quite necessarily need those for a web application. I can't see how this would be pragmatic or productive, or maybe it's not meant to be.

amluto 2y ago
> You realize this particular problem requires JS to solve, right? It's not just there arbitrarily. Most of the time, you get better results by just serving up the PDF as Content-Disposition: inline. 90% of JavaScript PDF viewers are crap (although PDF.js is decent), but the browser on all dignified platforms still does better than any fancy JavaScript I’ve ever seen. Loads faster, too.
- deleted 2y ago
  [deleted]
- megadal 2y ago
  People don't usually use PDF.js just to render PDFs. You can also extract text to use within a web application, preview a PDF, have users sign PDFs and fill forms in the browser (where their authenticated context resides) and a host of other things. I don't think anyone but a bored hobbyist is implementing or using a JS PDF renderer solely for rendering and the people who are using it for the aforementioned reasons don't care about load times, the document has to be processed somehow by the user agent. The suggestion that JS is optional here is nonsense and that the built in browser PDF renderer (written in a lower level language than JS) is faster is common knowledge. Again, I don't see how this suggestion is pragmatic or productive, but still, maybe we're not trying to be here.
  - kevin_thibedeau 2y ago
    PDF forms don't require JS.
    - megadal 2y ago
      They do if your want to fill them out in the browser coupled with an authenticated context, which is usually pretty important for forms. Usually you don't just want random users filling out any data within your enterprise. You also can prepopulate the form with user input from previous webpages/the user account. This is how a lot of HRISes do it. Usually people want onboarding to be as frictionless as possible. Downloading the PDF and using some editor outside the website then coming back to upload it counts as friction. And this conversation is still far away from the point: you need JS for a JS based PDF renderer, and there are valid uses cases where one is required.
      - amluto 2y ago
        > They do if your want to fill them out in the browser coupled with an authenticated context, which is usually pretty important for forms. Usually you don't just want random users filling out any data within your enterprise. > Usually people want onboarding to be as frictionless as possible. Downloading the PDF and using some editor outside the website then coming back to upload it counts as friction. Wait, are you saying there's a workflow for which the most frictionless solution is to have the user fill out a PDF, on an authenticated website and submit the PDF in the browser? As opposed to, say, <form>? Can you elaborate?
        megadal 2y ago
        Tax documents. I'm going to discontinue this conversation though.
        amluto 2y ago
        I once had the displeasure of submitting a Form W-9 on an authenticated website. It was an unmitigated disaster involving one time codes distributed over email via a team of apparent actual people outsourced outside the US, a website, PDFs POSTed to said website, and marked-up copies of said PDFs emailed back by said outsourced team asking inane questions. And, presumably since the whole mess wasn’t actually machine-readable, the form still got entered wrong and incorrect tax forms were issued. It would have worked much better as an emailed PDF, or a simpler form. Or an ordinary non-PDF form that would generate a filled-in PDF that the user could then sign. > I'm going to discontinue this conversation though. Oh, well.
- bguebert 2y ago
  I mean firefox's built in pdf reader is PDF.js. Also the desktop version of adobe reader used to run javascript embedded in pdfs by default as a "feature". I'm not sure you can get away from it at this point, but it would be nice to have the option to just use a desktop pdf reader that doesn't even support javascript or running any code embedded in the pdf. Maybe my use case is limited but I don't see the point of it. If you want interactivity you can use a website so people can expect that sort of stuff.