 |
 |
We took the third approach when building Turning the Pages with the BL. All files are encrypted and then decrypted on the fly in the app, so even if you poke around in the cache and could figure out that a .ttp file is just an alias for another format, you'd never get the whole file. Not so hard. We thought it was a basic decision on who you're trying to protect files from - casual digital pickpockets or determined "thieves". There's been some interesting discussion on this over at the MCN list regarding the commercial loss of any stolen images, which in turn raises the whole licensing debate. Which I know almost nothing about... Hope this helps. Michael ========================= Michael Stocking Managing Director Armadillo Systems 300 Kensal Road London W10 5BE +44 (0)20 8960 8600 [log in to unmask] www.armadillosystems.com www.turningthepages.com http://digitalcultureonline.blogspot.com/ On 23 Sep 2009, at 10:58, Cristiano Bianchi | Keepthinking wrote: > Dan, Frankie, thanks for your suggestions. > > A few things come to mind: > > - Dan, of course you are right: anything that is on a screen is out > for grabbing - the issue is how easy you make it to grab. I think > any of our client would be prepared to give the images away to > 'thieves' who patiently reconstruct them screen grab after screen > grab. > - To increase security if I had to do a custom designed tool, I'd > probably put the file names for the tiles in a database, rather than > relying on a naming convention, which, however clever, can be > decoded - so a tool to automatically grab the images could be > developed by someone with the right skills. Even Silverlight grabs > images over an open connection - as Firebug will testify. > - Another approach may be to encrypt the images and decrypt them on > the fly, so that whoever gets to the encrypted files won't be able > to use them, but to be honest we never seriously looked into this > and I'm not sure it can be done - it would require a fair amount of > effort in any case. > > So is the bottom line: if you don't want people to steal them do not > publish them...? > > Best, Cristiano > > > > On 23 Sep 2009, at 09:56, Frankie Roberto wrote: > >> James is right - the wikipedia case used an automated tool (you'd >> have to be >> pretty patient to assemble the images from screengrabs). However, any >> systems that displays high-res images by splitting them into tiles >> is going >> to be vulnerable to this kind of exploitation - stitching tiles back >> together again automatically is fairly trivial, so long as you can >> figure >> out the naming scheme. >> >> As an example, here's a particularly fetching bit of shoulder from >> *Christ >> in the House of His Parents*: >> http://www.bbc.co.uk/desperateromantics/paintings/assets/zif/e50f7643ffea2bb8f12bb8b8708c6211-christ452895102/1/tile.4-5.jpg >> >> It should be remembered, though, that the main reason for splitting >> high-res >> images into tiles is for usability/performance reasons (it'd take >> ages to >> download the whole image in high multiple zoom factors, and would >> probably >> run really slowly in most browsers, eating up system memory). The >> security-by-obscurity is just a side effect (you wouldn't do this >> with >> text!). >> >> The main reason I gave -1 for using Flash over javascript though is >> that, >> whilst nearly all desktop browsers have some version of the Flash >> plugin >> (and the latest version of Firefox helpfully encourages people to >> upgrade), >> some devices like the iPhone, small netbooks, and the One Laptop >> Per Child >> 'xo' (of which over 1 million have been distributed to children in >> poor >> areas) aren't Flash capable. >> >> As for javascript-based solutions, there are a few around, and I >> think there >> was a discussion on this list about them only a few months back. >> The one >> I'm most familiar with is OpenLayers (http://openlayers.org/), >> which is >> designed for map tiles, but works equally well with photo tiles >> (and is free >> and open source). It's also pretty stable and well documented, and >> has a >> full javascript API - however there's a bit of a learning curve. >> >> Anyway, well done to the BBC (and their museum collaborators) for >> making >> such a nice, high-production-values site. I'm not normally a fan of >> old oil >> paintings, but the website (and the TV show) got me interested. It >> seems >> that fiction (and dramatised history) loves to use museums and >> galleries as >> a setting (I'm thinking also of the Da Vinci Code, which is also >> used as an >> example of linked data at http://www.freebase.com/). I wonder if >> there are >> ways that museums and galleries could exploit this interest more >> (the Louvre >> does a nice line in Da Vinci Code tours: http://bit.ly/Y5s3e)? >> >> Frankie >> >> 2009/9/23 James Morley <[log in to unmask]> >> >>> From what I understand in the NPG case it was all accomplished >>> using an >>> established, readily available, and totally automated tool to >>> reconstruct >>> high-res images from Zoomify tiles, all using data that is visible >>> in the >>> source code, and files in a named directory structure (and one I >>> don't think >>> you can change). >>> >>> But if you did a more bespoke tool and/or hid your urls more >>> cleverly then >>> that would have to be a major deterrent. Even though technically >>> someone >>> would be able to grab them (either underlying files or screen >>> grab), the >>> thought of manually doing this should be daunting enough to most >>> potential >>> 'thieves', surely? >>> >>> >>> ---------------------------------------------------------------------- >>> James Morley [log in to unmask] >>> Website Manager Tel. +44 (0)20 8332 5759 >>> Royal Botanic Gardens, Kew www.kew.org >>> ----------------------------------------------------------------------- >>> ________________________________________ >>> From: Museums Computer Group [[log in to unmask]] On Behalf Of Dan >>> Zambonini [[log in to unmask]] >>> Sent: 23 September 2009 08:55 >>> To: [log in to unmask] >>> Subject: Re: BBC Desperate Romantics paintings >>> >>>> As a side issue, you rate it 10 for not using Silverlight and -1 >>>> for >>>> using Flash over JS. >>>> But have you (or anyone) found a good JS solution for doing similar >>>> things (progressive zoom)? >>> >>> The (bespoke) JS zoom tool we built for the National Gallery does >>> progressive zoom, and is also fairly accessible (has keyboard >>> shortcuts, >>> degrades gracefully): >>> >>> http://www.nationalgallery.org.uk/paintings/vincent-van-gogh-sunflowers >>> >>>> My guess is that any tool of this kind will need access to a folder >>>> where the images are - which are in this case open to exploitation, >>>> unless they were stored as binaries objects in a DB. >>> >>> There is NO way of stopping the exploitation; if you have to >>> display the >>> individual tiles to the end user, then they can screen-grab them and >>> re-assemble them into the larger file (like in the Wikipedia case, >>> as far >>> as >>> I understand it), no matter how they are stored/transmitted/ >>> displayed. >>> Putting any attempts at preventative measures into these tools, >>> which might >>> aversely affect performance or usability for the vast majority of >>> 'legal' >>> users, seems (to me) to be a bad idea. >>> >>> Just my 2p. >>> >>> Dan >>> >>> ---------------------------------------- >>> Dan Zambonini >>> Box UK >>> Internet Development and Consultancy >>> >>> t: +44 (0)29 2022 8822 >>> f: +44 (0)29 2022 8820 >>> e: [log in to unmask] >>> w: http://www.boxuk.com >>> ---------------------------------------- >>> >>> We are welcoming a new decade of growth and innovation at Box UK. >>> Visit our >>> website and read the Annual Report (http://www.boxuk.com/annual-report >>> ) to >>> learn more. >>> >>> Registered Office Address: 6a Poland Street, London, W1F 8PT. >>> Registered in >>> England and Wales No. 3606919. >>> >>> Important Information: This message may contain confidential, >>> proprietary >>> or >>> privileged information. If you are not the intended recipient, >>> please >>> notify >>> the sender immediately and delete the message from your system. >>> You should >>> not copy or use it for any purpose, nor disclose its contents to >>> any other >>> person. >>> >>> **************************************************************** >>> For mcg information visit the mcg website at >>> http://www.museumscomputergroup.org.uk >>> To manage your subscription to this email list visit >>> http://www.museumscomputergroup.org.uk/email.shtml >>> **************************************************************** >>> **************************************************************** >>> For mcg information visit the mcg website at >>> http://www.museumscomputergroup.org.uk >>> To manage your subscription to this email list visit >>> http://www.museumscomputergroup.org.uk/email.shtml >>> **************************************************************** >>> >> >> >> >> -- >> Frankie Roberto >> Experience Designer, Rattle >> 0114 2706977 >> http://www.rattlecentral.com >> >> **************************************************************** >> For mcg information visit the mcg website at >> http://www.museumscomputergroup.org.uk >> To manage your subscription to this email list visit >> http://www.museumscomputergroup.org.uk/email.shtml >> **************************************************************** > > > > -- > > Cristiano Bianchi > Keepthinking > > Bull Inn Court > 15 Maiden Lane > London WC2E 7NG > > t. +44 20 7240 8014 > f. +44 20 7240 8015 > m. +44 7939 041169 (uk) > m. +39 329 533 4469 (it) > > NEW: Bologna +39 051 0547918 > > [log in to unmask] > > > > > **************************************************************** > For mcg information visit the mcg website at > http://www.museumscomputergroup.org.uk > To manage your subscription to this email list visit > http://www.museumscomputergroup.org.uk/email.shtml > **************************************************************** **************************************************************** For mcg information visit the mcg website at http://www.museumscomputergroup.org.uk To manage your subscription to this email list visit http://www.museumscomputergroup.org.uk/email.shtml ****************************************************************