At the City of Springfield, we share authoritative pdf maps, like regulatory zoning, with the pubic via our ArcGIS online Hub. Previous to today, February 29, 2024, the pdf behavior when in AGOL and the Hub, is that you have the choice to Open and then download a pdf document. Today, the pdf we uploaded can only be downloaded from the Hub and when in AGOL.
We would like people to be able to view the pdf and not have to download the pdf. Did something change with the February 2024 AGOL update? Is there a setting I need to consider?
Solved! Go to Solution.
Hi All,
This was an intentional change, and I'll tell you why.
In almost all web applications, PDFs are uploaded to the app by a trusted source. ArcGIS Online is different in that we allow our many users to upload their own PDFs and share them broadly. When PDFs are generated and uploaded by a trusted source (eg: the site owner), we can be reasonably assured that the PDF has not been changed with a text editor to introduce malicious JavaScript.
If an unsuspecting user opens a file containing malicious JS that is hosted on our ArcGIS.com domain while they are currently logged in, a browser's cross domain restrictions are effectively defeated. This leaves our users vulnerable to a, common, dangerous, easily exploited and typically severe type of attack called "stored cross-site scripting".
Adobe also recognizes this risk, and offers options to prevent JS execution in Acrobat. Browser plugins also have the ability to block JavaScript - but how effective is relying on an end user to enable this functionality?
We understand that this is an unpopular change.
We strive to achieve a risk aware balance between "security" and "usability". This style of attack is well known and has been thoroughly documented. This is not a hypothetical - it is a real, persistent threat that we are responding to.
We working to identify technologies that can identify and sanitize malicious scripts from PDFs and other files, but this is difficult challenge because PDF files are designed to use JavaScript code. We are also looking into PDF viewers that are either sandboxed or do not support JavaScript at all.
We appreciate your feedback regarding this change - it does not go unheard. We look forward to providing a better, more secure option to providing an in-line experience for serving PDFs in a future release.
Hi Randall,
I want to confirm my understanding of how this change will impact Experience Builder and the use of the Embed widget to access PDF documents. Are we no longer able to embed a PDF hosted in ArcGIS Online and have it open directly within Experience Builder?.
If this is the case, could someone please update the help esri help documentation at this link?
Thanks
JB
this is exactly what i just spent most of the day dealing with, thinking there must be something wrong w/ the pdf, etc. what an absolute nightmare this application gives me every time i'm unfortunately forced to use it
sidenote: my favorite bug is clicking a date in the calendar when adding an event, only to have it select the day prior to the date i selected. that's the most fun bug i've experienced until today's PDF disaster
@JoshThue on the issue with Hub Events selection - we are getting close to a major update for Hub events that will improve overall usability and will remove bugs like this.
Hi @CaseyWilson1 and @JoshThue,
Thanks for the feedback! It looks like this is a expected change, but I have passed your concerns on to the developers, so they are aware of your frustrations.
Rebecca
Hi All,
This was an intentional change, and I'll tell you why.
In almost all web applications, PDFs are uploaded to the app by a trusted source. ArcGIS Online is different in that we allow our many users to upload their own PDFs and share them broadly. When PDFs are generated and uploaded by a trusted source (eg: the site owner), we can be reasonably assured that the PDF has not been changed with a text editor to introduce malicious JavaScript.
If an unsuspecting user opens a file containing malicious JS that is hosted on our ArcGIS.com domain while they are currently logged in, a browser's cross domain restrictions are effectively defeated. This leaves our users vulnerable to a, common, dangerous, easily exploited and typically severe type of attack called "stored cross-site scripting".
Adobe also recognizes this risk, and offers options to prevent JS execution in Acrobat. Browser plugins also have the ability to block JavaScript - but how effective is relying on an end user to enable this functionality?
We understand that this is an unpopular change.
We strive to achieve a risk aware balance between "security" and "usability". This style of attack is well known and has been thoroughly documented. This is not a hypothetical - it is a real, persistent threat that we are responding to.
We working to identify technologies that can identify and sanitize malicious scripts from PDFs and other files, but this is difficult challenge because PDF files are designed to use JavaScript code. We are also looking into PDF viewers that are either sandboxed or do not support JavaScript at all.
We appreciate your feedback regarding this change - it does not go unheard. We look forward to providing a better, more secure option to providing an in-line experience for serving PDFs in a future release.
@RandallWilliams Thanks for the explanation. Look forward to your continued efforts at pdf viewers. It would have been helpful to have that documented, but now it is! Maybelike if I want to share a pdf with the public, I should post it on the Enterprise Portal and share it as a collaboration. I'll look into that.
Heard. Pinged support to provide a kB.
That could work - I haven't tested that behavior. If your ArcGIS Enterprise is public facing and the PDF is public anyway, you can just share the URL "by reference" instead of via collaboration, too.
I've noticed that Firefox gives me actions for how I want files to be used.
For me at least, Firefox downloads the file locally then opens the downloaded file. (eg: file:///C:/Users/user/Downloads/doc.pdf). That's cool and a lot less dangerous.
Chrome and Edge just download the file but don't open them. I haven't looked for an extension that will do it for those browsers. YMMV.
Well dang. That changes my whole plan for our website. I'm glad you understand this an unpopular change... wish we could have found an alternative solution other than breaking an established functionality with zero notice.