Emily,
I think others gave very valid suggestion that I mostly agree with,
especially about separating internal-use images with public ones. These
should reside in separate servers with clear firewall rules assigned.
Most importantly, you should isolate your internal management system
from the WWW. Assume your institution *will* (not *could*) be attacked
by malicious actors at any time.
I support Jeremy's suggestion to look at IIIF. That takes some setup
time, as well as the need to produce specific derivatives. However, any
other image derivative is taken care of by the image server after that.
No need to manually generate thumbnail, web large/small/medium, etc.
However, a IIIF manifest cannot enforce access to an image, it only
provides hints for good citizens about which derivatives they should
request. You can tackle restricted access in the same pipeline that
generates your IIIF-ready derivatives, by setting up a reduced
derivative size, or no public derivative at all, for
copyright-restricted images. This way you will have one folder /
repository with internal-only access behind firewall, and one open to
the WWW or behind the image server.
This may sound like a lot to deal with, but in the long run it will
definitely save you a lot of management time, migration nightmares and
security loopholes.
Stefano
On 5/1/20 10:41 AM, Jeremy Ottevanger wrote:
Hi Emily,
I'm going to leave for another thread the question of whether or not
everything "should" be made available to the same degree - it's complex
and not really what you're asking. But clearly that will be one element
in people's assessment of whether the risk you're describing should be
an issue or not.
So, given that rights and licences are clearly important in your
situation, would I think it a risk to leave a door ajar for people to
take images you aren't meant to let them have? Well yes, it could be. Do
I think people are likely to take them and abuse them? It's possible, of
course, but perhaps it comes down the nature of the risks you want to
avoid. If you could get into trouble with a rights holder that's one
thing. But if you have an image licence sales team that is worried about
lost revenue, I wouldn't worry so much. I don't think any commercial
customer who is likely to have paid for a licence before is less likely
to do so just because they figure out how to nick the image without
paying. At the same time it can be a delicate political situation to get
as far as you have and release any high-res images, in which case it can
be canny politics to conspicuously avoid this risk. I've had to play
this game in the past, even if I wanted to go much faster towards more
open content, and in the end I believe it's really important to earn the
trust of your organisation - it makes you a more plausible advocate for
change anyway.
So if there is a risk, what can you do to mitigate it? The obvious thing
would be to put the images you want to publish into a separate directory
to the ones you don't. That probably means having a second copy of them
- that is surely the easiest solution. But if you can't do this for
reasons of space (I hope not!) or of managing the process, I can think
of a couple of other ways, although they could be equally tricky to
automate or have other drawbacks. If this is a Linux server you could
sim-link the published images to a location that you use for the web
directory. Or you could do something clever with file permissions so
that the web server (Apache or whatever) only has access to the
published images (or with .htaccess). Both of these solutions could be
automated, or semi-automated, for example by running a script over a
list of files you want to sim-link. This might be built into the
publication process.
Or you could have a think about a IIIF solution (https://iiif.io/). This
has so many things going for it that go beyond what we're talking about
here, but one salient point is that you aren't giving people direct
access to a file - only the IIIF service on your server has access to
the file, which it then does its magic on and sends out when requested.
There is a manifest file containing information about the image, and if
this isn't there then the IIIF service shouldn't return the image. I
hope someone will correct me if I have that wrong!
The downsides of IIIF would be that, firstly, you might not be
publishing TIFFs like this, off the top of my head I'm not sure if that
is supported by the spec or by any IIIF servers. And secondly, you'd
need a way to publish manifests for each image you published. But once
you did that you could have all the goodness that comes with IIIF and
viewers like Mirador (https://projectmirador.org/) or Universal Viewer
(https://universalviewer.io/)
Good luck with your project, it's good to hear of more high resolution
images being set free!
All the best,
Jeremy
-------------------------------------
Dr Jeremy Ottevanger
Director, Sesamoid Consulting Limited
t: +44(0)1787 475 487
m: +44(0)7865 887 887
e: jer...@ottevanger.co.uk
w: https://sesamoidconsulting.co.uk/
twitter: @jottevanger
LinkedIn: www.linkedin.com/in/jeremy-ottevanger
On 01/05/2020 16:21, Emily Beliveau wrote:
Hi all (and attn: DAM and IP SIG members particularly)
We are setting up a new media server that will allow us to provide
high-res
image downloads via our collections search site for the first time
(previously only small derivatives were web-accessible and our .tifs were
stored elsewhere). We can control the publish-to-web status of each level
of image derivative with our collections management system, but since all
the high-resolution files will be on the same server, the URLs for all
images (regardless of rights/publish status) will be guessable.
How is this commonly handled? For context, we do not have a DAMS and
manage
all our files in folders manually. We currently have ~80K image
assets. I'd
like to understand our options and whether the community views this as an
issue or not.
Thanks,
Emily.
*--*
*Emily Beliveau*
Collections Management Advisor (Humanities)
University of Alberta Museums
Ring House 1, University of Alberta
Edmonton, AB T6G 2E1
T: 780-492-0776
_______________________________________________
You are currently subscribed to mcn-l, the listserv of the Museum
Computer Network (http://www.mcn.edu)
To post to this list, send messages to: mcn-l@mcn.edu
To unsubscribe or change mcn-l delivery options visit:
http://mcn.edu/mailman/listinfo/mcn-l
The MCN-L archives can be found at:
http://www.mail-archive.com/mcn-l@mcn.edu/
_______________________________________________
You are currently subscribed to mcn-l, the listserv of the Museum
Computer Network (http://www.mcn.edu)
To post to this list, send messages to: mcn-l@mcn.edu
To unsubscribe or change mcn-l delivery options visit:
http://mcn.edu/mailman/listinfo/mcn-l
The MCN-L archives can be found at:
http://www.mail-archive.com/mcn-l@mcn.edu/
--
exitst .not
exeunt hoall.
http://stefano.cossu.cc
_______________________________________________
You are currently subscribed to mcn-l, the listserv of the Museum Computer
Network (http://www.mcn.edu)
To post to this list, send messages to: mcn-l@mcn.edu
To unsubscribe or change mcn-l delivery options visit:
http://mcn.edu/mailman/listinfo/mcn-l
The MCN-L archives can be found at:
http://www.mail-archive.com/mcn-l@mcn.edu/
