Thanks all for the input. The main concern regarding access is meeting our legal obligation to rights holders, primarily for images of contemporary artwork. We will work with our copyright office to determine our risk strategy, but even with an open access model, we will need the ability to limit access to larger derivatives in certain cases.
Separating the publishable vs. non-publishable images into separate directories makes perfect sense, it is figuring out some automation and management of the process that will be key (as Jeremy's comments address). I've lurked around the IIIF community for years, but the setup time/technical particulars have been a barrier in the past--perhaps it's time to reconsider. If we go that route, I'll surely be in touch with relevant folks for further advice. Thanks again, Emily. On Fri, May 1, 2020 at 12:23 PM Stefano Cossu <stef...@cossu.cc> wrote: > 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/ > _______________________________________________ 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/
