Jump to content

Are PDF docs any more secure than Word docs if they do not have a password?


Recommended Posts

Posted

Our LA has told all my schools that any public facing documents need to be converted to PDF. Now we do not have Adobe software so we would be using Word or Google to open the doc and save as a PDF.

 

I am a little confused about the logic as the LA have said we do not need the PDFs to have a password.

 

Currently all the website docs are actually in Google Drive where we can control things like read only etc already and the way I look at it, anyone can open a PDF in Word and edit it anyway.

 

Is there any reason you can think of that we need to be converting hundreds of docs to PDF, that I am not aware of?

Posted
it will be because word docs need word (or similar software)to be useful pdf files are more easily viewed on a range of devices(yes you need acrobat or similar but viewers are free and often as not preinstalled on devices). They are also harder for people to edit
Posted

All our public docs are PDF just to make it easier for people to access but not as a security thing.

 

Did they specify why they have issued this advice?

  • Thanks 1
Posted
I can only see this as being for compatibility reasons. You can open any PDF with Word anyway and it will attempt to convert it to an editable document. Ruins the formatting a lot of the time but it works.
Posted
I would say PDFs are more useful as mentioned they work natively on more devices than a .docx, however, your LA's reasoning regarding security is ridiculous. I would start by ensuring any new documents are uploaded as PDFs and replace the older documents with PDFs as they come up for renewal.
Posted

A PDF will always look exactly the same regardless of what it's viewed on, unlike a Word doc.

Providing your documents through Google Docs is arguably a little out of the ordinary for end users (a so less straightforward).

Posted (edited)

But our files are in Google and open without any software being needed, even adobe reader.

 

EDIT - The document (regardless of type) opens in a preview browser. We can choose if its printable, downloadable etc.

Edited by TwistedHelixis
Posted
I guess it's easier for the LA to just stipulate "use PDFs" rather than say "you can host them as Google Docs if you want" and risk having school foul up the sharing settings.
Posted (edited)
Currently all the website docs are actually in Google Drive where we can control things like read only etc already and the way I look at it, anyone can open a PDF in Word and edit it anyway.

Google Docs can convert to PDF or DOCX on the fly. All you need to do is modify the link slightly (see image below).

 

I do this on our school website so that visitors can download the Google Docs in several different formats. This way the original document stays in Google Docs format. :)

 

https://learninginhand.com/blog/google-document-url-tricks

 

Other file types also work. Instead of using pdf in URL, try png, jpg, pptx, xlsx, docx, html, or txt.

 

TPlvIc.png

Edited by Arthur
  • Thanks 1
Posted
Is a Google login needed to view the files? If so that's a barrier to accessing that information?

 

If that is the case then I see no issue here, like I said you might want to start making any new documents PDFs but as for going over 100s of old Word docs just seems pointless and a waste of time.

Posted
Did they specify why they have issued this advice?

 

I got these requests via emails from each school. This is part of one email - to ensure all reports and policies are only issued in a protected PDF form in the highly unlikely event someone might make a change to a word document.

Posted
I got these requests via emails from each school. This is part of one email - to ensure all reports and policies are only issued in a protected PDF form in the highly unlikely event someone might make a change to a word document.

As others have said, editing a PDF is not hard, meaning their stance is uninformed.

Posted (edited)
A PDF will always look exactly the same regardless of what it's viewed on, unlike a Word doc.

Providing your documents through Google Docs is arguably a little out of the ordinary for end users (a so less straightforward).

@jthompson slight hijack here.

One of the things we publish is meeting minutes. I asked for input from a few folks and just got a shrug saying do what ever is easier.

The old website had a list of links

October 2018

September 2018

etc

 

The new website I shared a google docs folder with sub folders to each academic year.

I convert the minutes to pdf and drop it in the appropriate folder. No faffing with uploading and creating an individual link for every month.

 

Do you think providing the PDFs like this is out of the ordinary or not straight forward for end users?

 

The only downside I can think of the new method is website stats / analytics won't report the downloads.

 

On topic:

Should we all be adding passwords to published PDFs?

Edited by ADMaster
Posted

Using Drive in the way you've described there seems reasonable for a collection of documents that is being continually updated or added to. For more static stuff (e.g. policies) a direct PDF download seems neater.

 

I'm not sure why you'd need to password protect published documents though. If it's published, that presumably means it's intended for public view. What people do with it once they've downloaded a copy is not really of concern.

  • Thanks 1
Posted

I meant password protect in the manner of preventing copying / editing not opening. I know I've come across PDFs that don't allow for copying / printing etc. I used to think PDF was a more secure way of publishing as it was not easily edited. That changed with word 2013. None of my PDFs are protected in this way, I'm just curious.

 

A couple examples, I have a PDF copy of lease agreements / receipts. What if I altered those and said no this is what I signed.

 

In a school setting the student handbook / code of conduct is published in PDF, what if a student edits a copy.

 

It of course is wrong to do these things, I'm just wondering if this is where the OP was going with PDF security. I'd like to think common sense would prevail but who knows these days.

Posted

If you don't digitally sign a file to cryptographically prove you're the owner of the private key then you assume someone could have edited it, simple.

 

PDFs only look the same if the embed the fonts btw, assuming all renders are 100% correct.

Posted
I meant password protect in the manner of preventing copying / editing not opening. I know I've come across PDFs that don't allow for copying / printing etc. I used to think PDF was a more secure way of publishing as it was not easily edited. That changed with word 2013. None of my PDFs are protected in this way, I'm just curious.

 

A couple examples, I have a PDF copy of lease agreements / receipts. What if I altered those and said no this is what I signed.

 

In a school setting the student handbook / code of conduct is published in PDF, what if a student edits a copy.

 

It of course is wrong to do these things, I'm just wondering if this is where the OP was going with PDF security. I'd like to think common sense would prevail but who knows these days.

 

Our MAT has a policy of every public facing document being pdf for ease of access. Entirely my fault as I got fed up with wrestling with .docx, .xls, etc when reviewing governor papers on my tablet (I converted them to pdf for easy annotation). As more and more people started using something other than a windows machine the pressure grew and it happened.

 

The minutes you speak of are undoubtedly for governance. They are in the public domain in that anyone has the right to see them. I can’t see a problem with your structure. The Clerk will always hold the master copy so anyone trying to fiddle with them to claim they said something else will soon come unstuck.

Posted
Our MAT has a policy of every public facing document being pdf for ease of access.

Aren't PDFs meant to be bad for people with disabilities? :confused:

 

www.gov.uk/guidance/how-to-publish-on-gov-uk/accessible-pdfs

 

Documents published on GOV.UK or other public sector websites must meet accessibility standards. This is so they can be used by as many people as possible, including those with disabilities.

 

www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps

 

In the UK, 1 in 5 people have a disability.

 

Why it’s important

People may not have a choice when using a public sector website or app, so it’s important they work for everyone. The people who need them the most are often the people who find them hardest to use.

 

Accessible websites are better for everyone. For example, they are faster and easier to use, and appear higher in search engines.

 

You may also be breaking the law if your public sector website or app doesn’t meet accessibility standards.

 

https://gds.blog.gov.uk/2018/07/16/why-gov-uk-content-should-be-published-in-html-and-not-pdf

 

GOV.UK exists to make government services and information as easy as possible to find and use.

 

For that reason, we're not huge fans of PDFs on GOV.UK.

 

Compared with HTML content, information published in a PDF is harder to find, use and maintain. More importantly, unless created with sufficient care PDFs can often be bad for accessibility and rarely comply with open standards.

 

The default should be to create all content in HTML. If you can’t avoid publishing a PDF, ideally it should be in addition to an HTML version and the PDF must meet accessibility standards and archiving standards. We hope this post will help publishers explain the problems with PDFs to their colleagues and support moving towards an HTML-first culture

 

Problems with PDFs

 

They do not change size to fit the browser

On a responsive website like GOV.UK, content and page elements shift around to suit the size of the user’s device and browser. However, PDFs are not designed to be flexible in their layout. They generally require a lot of zooming in and out, and scrolling both vertically and horizontally. This is especially troublesome with long documents and on small devices like mobile phones.

 

They’re not designed for reading on screens

People read differently on the web, so it’s really important to create content that is clear, concise, structured appropriately and focused on meeting the user need. A PDF document that was created for offline use will not suit the context of the web and is likely to result in a poor user experience.

 

It’s harder to track their use

We cannot get as much information from analytics about how people are using PDFs. We can get data on how many times a PDF has been downloaded from GOV.UK, but we cannot measure views of the file offline.

 

In addition, we cannot get data about how users have interacted with a PDF – for example how long they’ve viewed it for or what links they’ve followed. This makes it harder to identify issues or find ways to make improvements.

 

They cause difficulties for navigation and orientation

Depending on the user’s device and browser, PDFs might open in a new browser window, new tab or a separate app. Sometimes they automatically download to the user's device. Whatever happens, the user is taken away from the website when they open a PDF. This means they lose the context of the website and its navigation, making it harder for them to go back if they need to.

 

This is even more of an issue if the user goes directly to the PDF from a search engine. Without the context of the site the PDF is hosted on, they can’t easily browse to related content or search the website.

 

It’s also worth remembering that although many devices and browsers have PDF viewers built-in - and they are freely available to download - there are still users who do not have them, or cannot download them.

 

They can be hard for some users to access

The accessibility of a PDF depends on how it was created. For example, it needs to have a logical structure based on tags and headings, meaningful document properties, readable body text, good colour contrast and text alternatives for images. It takes time to do this properly.

 

Even if this work is done according to best practice, there’s still no guarantee that PDF content will meet the accessibility needs of users and their technology. Operating systems, browsers and devices all work slightly differently and so do the wide variety of assistive technologies such as screen readers, magnifiers and literacy software.

 

Some users need to change browser settings such as colours and text size to make web content easier to read. It’s difficult to do this for content in PDFs. You can magnify the file, but the words might not wrap and the font might pixelate, making for a poor user experience. Locking content into a PDF limits the ability for people to make these kind of accessibility customisations.

 

It’s our responsibility to ensure that our users can access the information we publish. Plus, publishing content in HTML will also reduce the need to supply alternative formats on demand to users who can’t access a PDF.

 

They’re less likely to be kept up to date

Compared with HTML, it’s harder to update a PDF once it’s been created and published. PDFs are also less likely to be actively maintained, which can lead to broken links and users getting the wrong information. This can be especially problematic if a document has been published in multiple formats. Any changes need to be made to all the versions, meaning more work and more opportunities for error.

 

In addition, users are more likely to download a PDF and continue to refer to it and share it offline. They may not expect the content in the PDF to change and might not check the website to get the latest information. HTML documents encourage people to refer to the website for the latest version.

 

They’re hard to reuse

It can be very difficult to reuse content from a PDF by copy and pasting it. The design and layout of the PDF can produce unexpected results, particularly if it has multiple columns, hasn’t been structured correctly, or uses incompatible fonts.

 

We’re also working on tools to extend the use of our web content - such as a new content API and ways to measure the quality of content. These tools will not work with PDFs. Publishing content in HTML means it will work with new developments like these - and for whatever platforms we might use in the future.

 

Similarly, users cannot use browser extensions and add-ons such as Google translate on PDF content.

  • Thanks 1
Posted
I wasn't thinking disabilities, may be I should have used the word use. Yes, accessibility adds a whole other layer to publicly facing documents
  • Thanks 1
Posted

In fact, to cover all the issues that have been raised in previous posts above, actually using a Google Doc makes even more sense than using a PDF file as,

 

-Fully GDPR compliant system, everything is logged and date stamped to do with the file, for example, who last edited the file, what they edited. the ability to jump back to any edit since the doc was created.

-The ability to add comments to the file, which are also logged.

-You can make the file 'read only' without needing the user to enter a password.

-Anyone can view the document on any system and without any software, provided they have a browser. (not everyone has Word or Adobe Reader)

-You can block downloading or even printing of the file.

  • Thanks 1
Posted

Some interesting thoughts on accessibility. The biggest issue I have with PDFs are those that scan them in as an image. Those PDFs are not accessible at all.

A proper PDF vs google docs is a tossup on accessibility for me. Neither one are as easy as HTML but not too many extra steps either.

It will be a chore to convert all existing governor minutes to HTML

I’ve made an effort to have our new website meet all accessibility guidelines. I considered the PDFs accessible because they are not an image and you can get at them with a reader.

They are all word docx converted to PDF.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...