Defense Against the Dark Arts: Digital Security for Activists and Human Rights Defenders

(These resources were originally assembled for a presentation I gave at Swarthmore College on February 21, 2017 and were updated for a second presentation on April 4, 2017.)

Resources for Security

Swarthmore ITS Policies

Security Basics

Basic Software

Encrypted Communications

Private Browsing

Care and Feeding of Smartphones

Additional Resources for Survivors

Miscellaneous

Security Information

The Law

Privacy

SJ 34 – Congress votes to drop some online privacy protections

Staying Safe Online

These resources were mentioned in a presentation on Staying Safe Online that I delivered at the Swarthmore Public Library.

General resources

Software

Additional Resources for Survivors

Advanced Security Information for Activists, Human Rights Defenders, and Political Dissidents

Considerations for planning a digitization project

People who are not part of the libraries and archives world often ask us about digitizing things, as though all it entails is putting some documents on a scanner and clicking the scan button. I wanted to have a list of considerations for people outside of the profession so that they could think about whether a digitization project is feasible.

Much of this comes from resources I list at the end, but my focus was on writing a list for non-professionals, while many other resources are clearly meant for the people who will be designing the actual digitization plan.

  • Why digitize?  What are the expected outcomes and benefits of digitization?
  • How will records be selected?
    • Are any materials under copyright?
    • Are any materials fragile?
    • Are any materials confidential or considered high risk?
  • How do stakeholders expect the records to be digitized?
    • Who owns the project?
    • Who will manage the project?
    • What space and equipment will be used for the project?
    • Who will do the scanning?
    • Scanning accounts for approximately one-third of the labor involved in a digitization project.  The remaining two-thirds of the labor include:
      • Selecting materials for digitization (condition review, intellectual property review, security/confidentiality review)
      • Preparing materials for digitization (organizing files, removing staples, removing extraneous documents, etc.)
      • Training scanning staff
      • Supervising scanning
      • Creating metadata
      • Performing quality control of scans, filenames, and metadata
      • Preparing files for submission to delivery and repository systems
      • Depositing files and making them available in access systems
      • Creating and maintaining policies, procedures, standards, and documentation of the project so that standards are maintained over time
        • Staff turnover must be taken as an inevitability, and the project needs to be thoroughly documented so that turnover doesn’t end the project
  • How do stakeholders want to access the records? Are access restrictions required on certain records?
  • How will stakeholders transition to accessing object files digitally?
  • How will paper records be managed before, during, and after the scanning project?
  • How will future accruals be digitized?
    • What system will be in place so that all accruals are scanned before they are added to the paper files?
  • What are the long-range plans for the paper files and the digital surrogates?  Will they be going to the archives?  If so, the project will need to be done in accordance with the prevailing archival standards so that the project will not need to be repeated in the future.

Helpful resources:

New South Wales Digitisation checklist

ALCTS Minimum Digitization Capture Recommendations

New to RFPs?

In recent conversation with a few archivists, they mentioned they were not familiar with RFPs. It wasn’t something I learned about during graduate school either. I learned about them during my DAS courses through SAA, although I can’t recall off hand which course it was in.1

An RFP is a Request for Proposal.  Essentially, it is a document that outlines exactly what you want to purchase so that companies can make a bid on providing those products or services.  That sounds simple enough, but it can be one of the most important documents you write, particularly if you are purchasing a software system or a suite of services.

One of the reasons it is useful is that it forces you (and your organization) to decide up front what features and services you need.  When everyone signs off on the RFP and you send it out for bids, you will have a wonderful piece of paper you can use to fend off scope creep. If someone asks, “Could we add this thing to this service?”, you can say, “Sorry, we didn’t put that in the RFP.”

So, if you are completely new to RFPs, these are the resources  that were recommended in the DAS course.  They are brief and also very informative and helpful – so much so that I keep the references on hand for any time this topic comes up.

Weidenhammer, John. 2008. “ABCs for RFPs.” Government Procurement 16 (1): 22–23. (Also available through this site.)

Clegg, Helen, and Susan Montgomery. 2006. “How to Write an RFP for Information Products.” Information Outlook 10 (6).  (Also available here.)

Porter-Roth, Bud. 2006. “Writing a RIM Request for Proposal.” Information Management Journal 40 (5): 70–74.  (Also available here.)

 

Once you’ve read those, then you might want to see this example of a large and complex RFP:
OHIONET, State Library of Ohio. 2008. “Request for Proposal for an Open Source Software Statewide Resource Sharing System.” Available from OHIONET.

 

1. I can’t recall which course it was in when I went through the program, but there is now an entire course devoted to the topic, which is great: http://www2.archivists.org/prof-education/course-catalog/developing-specifications-and-rfps  

An Open Letter to Open Source projects for LAMs

To Whom It May Concern:

I am a fan of Open Source projects.  I strongly support all Open Culture, particularly in  Libraries, Archives, and Museums (LAMs). However, I must bring something to your attention.  All too often, I read announcements of some new open source software that is perfect for “institutions of all sizes”.  Your average reader, who is not completely inept with technology — but is not a software engineer — goes to the project site. The installation instructions go something like this:

1. We are not going to tell you which server architecture this works on because you clearly should be smart enough to figure that out.

2. Download this package.

3. Compile the package.

4. Obviously there are 300 dependencies, but we are not going to tell you what they are. Any decent institution would have them installed already.

5. Change system configurations to serve local needs.  We’re not going to tell you what that means or how to do it.

6. Use the API from your core system to feed in this data. If your current API doesn’t work, please write one according to the specs on some other project you’ve never heard of.  Note that the documentation of that other project hasn’t been updated in eleven years, but you’ll figure it out. What? Your system doesn’t have an API?!?!?!  You must be joking.  *Everyone* has an API.

7. Earn a PhD in computer science.

8. Change your entire server environment including reinstalling your core systems on some other platform, breaking everything and requiring tens of thousands of dollars in development work to put all the pieces back together again.

9. Type the following commands in the command line.  Note that they look like a SHA-256 hash, but they are actually really simple commands that *everyone* should know.

10. Spend nine weeks on Stack Overflow trying to figure out all the parts that we did not explain here.

11. Ask a question on Stack Overflow where the only respondent points you to the documentation online or a W3C standard. 1 

12. Voila!  It works!

13. Subscribe to updates from the project and receive an email the next morning saying that development on the project is suspended because the entire project is being moved to a different architecture.  Realize this means you will get to start over at step one.

Addendum: We didn’t write any documentation.  If you need to figure something out, just read the code.

Please, please do not say that this project is meant for “institutions of all sizes”.  Please do not advertise it as “easy” or “simple”.  Please tell it like it is – it’s raw, it’s meant for experts, and you don’t care if anyone else can get it to work.  I appreciate that you are trying to do something good, but your good will is meaningless when it stands against the disappointment of every reader who wanted to try out your project but was completely stonewalled by your “easy” installation instructions.

Just knock it off already.

j

 

1. With special thanks to @metageeky for number 11 in the list!