Unable to Open PDF in AGOL only Download- New as of Feb 29, 2024

3042
24
Jump to solution
02-29-2024 12:13 PM
CaseyWilson1
New Contributor II

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? 

Tags (3)
1 Solution

Accepted Solutions
RandallWilliams
Esri Regular Contributor

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. 

 

 

 

 

View solution in original post

24 Replies
JoshThue
New Contributor II

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
New Contributor II
RebeccaRichman
Esri Contributor

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

RandallWilliams
Esri Regular Contributor

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. 

 

 

 

 

CaseyWilson1
New Contributor II

@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.

RandallWilliams
Esri Regular Contributor

Heard. Pinged support to provide a kB. 

0 Kudos
RandallWilliams
Esri Regular Contributor

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.

2024-02-29_20-19-16.png

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.

 

JamesBurton1
Occasional Contributor

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. 

JamesBurton1
Occasional Contributor

I'm moving all my PDFs to google cloud where they do open instead of download. A pretty simple work-around. 

0 Kudos