Archiving Sensitive Data by Bram Luyten, Tom Desair
Unfortunately not all repository is equally open – different risks and considerations.
Have set up metadata-based access control. DSpace authorisation works okay for dozens of groups, but doesn’t scale well to an entire country where each person is an authorisation group – as they needed. Needed an exact match between a social security number/email address on the eperson and on the item metadata.
- Advantages: Scales up massively – no identifiable limits on number of ePeople/items, no identifiable effect on performance. Can be managed outside of DSpace so both people and items can be sourced externally.
- Disadvantages: your metadata becomes even more sensitive. And the rights to modify metadata also gives you the rights to edit authorisations.
Strategies for dealing with sensitive data:
- Consider probability and impact of each risk eg
- Data breach
- Impact – higher if you’re dealing with sensitive data
- Probability – lower if it’s harder for people to access your system and security updates are frequent
- Losing all data
- Impact – high if dealing with data that only exists in one place
- Probability – depends on how you define “losing” and “all”. Different scenarios have different probabilities
- Data breach
Code on https://github.com/milieuinfo/dspace54-atmire/ (but documentation in Dutch)
(In Q&A: DSpace used basically as back-end, users would only access it through another front-end.)
Full integration of Piwik analytics platform into DSpace by Jozef Misutka
User statistics really important if defined reasonably and interpreted correctly. Difference between lines in your access logs, item views, bitstream views (which includes community logos), excluding bots, identifying repeat visitors.
DSpace stats
- internal based on logs
- SOLR (time, ip, useragent, epersonid, (isBot), geo, etc etc) – specifics for workflow events and search queries; visits vs views confusion
- ElasticSearch time, ip, user agent, geo, (isBot), dso) deprecated in v6
- Google Analytics, plugins
DSpace are good for local purposes but for seeing user behaviour lacks a lot of functionality
Had various requirements – reasonable, comparable statistics; separate stats for machine interfaces; ability to analyse user behaviour, search engine reports; export and display for 3rd parties; custom reports for specific time/user slices.
Used Piwik Open Analytics Platform (similar to Google Analytics but you own it – of course means one more web app to maintain). Integrate via DSpace REST API or via lindat piwik proxy. Users can sign up to monthly reports (but needs more work, and users need to understand the definitions more.)
In DSpace, when user visits a webpage, java code is executed on the server, which triggers a statistics update. But with Piwik, the java code is executed and returns html with images/javascript and when that’s executed it triggers statistics update – potentially including a lot more information; this excludes most bots who don’t execute js or view images.
If you change how you count stats, include a transition period where you report both the old method and the new method.
Beyond simple usage of handles – PIDs in Dspace by Ondřej Košarko
Handles often used as a metadata field for the reader to use to refer back to the item, or for relations between items. But while a human can click on the handle link, but a machine doesn’t know what it’s for or what’s on the other end of it.
Ideally a PID is all you need: You can ask ‘the authority’ for information of not just where to go but what’s on the other end.
Handles can do more things:
- split up the id and location of a resource
- content negotiation – different resource representation based on Accept header (which is passed by hdl.handle.net proxy)
- template/parts handles – register one base handle but use it with extensions eg http://hdl.handle.net/11372/LRT-22822@XML or http://hdl.handle.net/11372/LRT-22822@format=cmdi – can refer to different bitstreams, or to different points in audio/video
- get metadata based on handle without going right to the landing page – eg to get info in json, or generate citations, or show a generated landing page on error, or…
Trying to keep IR as close to 100% full-text as possible; DSPace 5 XMLUI, Mirage 2, now fed from CRIS Elements.
Request a copy button designed to give researchers an alternative way to access restricted (eg embargoed) content. Reader clicks button, initiates request to author; if author grants request, files are emailed to requester. Idea is that authors sharing work on one-to-one is covered by a) tradition of sharing and b) fair dealing under copyright.
Why? Embargoes auto-lift but no indication showing when that’d happen. Working on indicating auto-lift date but wanted to embrace other ways. Did need to make some tweaks to default functionality.
Out-of-the-box two variants: a) request author directly (but all submissions from Elements!) or b) email to admin who can review and overwrite author email address and and and … They used this latter ‘helpdesk’ variant but cuts out steps (and copies in admins).
So admins can use local knowledge of who to contact, intercept spam requests, aren’t responsible for granting access (to avoid legal issues).
Other tweaks: to show file release date; wording tweaks; some behaviour tweaks (don’t ask if they want all files if there’s only 1; don’t ask the author to make the file OA because in our case the embargo can’t be overridden).
Went live – and lots of very dodgy requests – even for items that didn’t exist. So put in tweaks to cut down on spam requests to ensure requests actually come via the form, not a crawler. Respond appropriately to nonsense requests (for non-existing/deleting files); avoid oversharing eg files of withdrawn items or files not in the ORIGINAL bundle.
Went live-live. Informed of requests as made and approved, and added counts to admin statistics (requests made/approved/rejected).
Live a year
- 9% of publications (49 items) have the button
- 18 requests made – mostly local subject matter, majority from personal e-mail addresses
- 8 approved, 0 denied (presumably ignored – though once author misread email and manually sent the item) – seemed like personal messages may have had a higher chance of success. One item was requested twice
So hasn’t revolutionised service but food for thought.
- Add reminders for outstanding requests
- Find out why authors didn’t grant access, maybe redesign email
- Extend feature to facilitate control over sensitive items
- Extend to restricted theses (currently completely hidden)
One good comment from academics “great service, really useful”.
(ANU also implemented – some love it, some hate it – if hate it change email address to repository admin.)
(Haven’t yet added it to metadata-only files – as it’d mean the author would have to find the file. OTOH would be a great prompt ‘Oh I should find the file’. Another uni has done this but had to disable for some types due to a flood of requests.)