In 2007 I wrote an article entitled “Why I Embed My Images” that discussed how embedding images and other can provide greater security when you feel there is a risk someone might file a takedown notice. By separating your images from your server, should someone file a takedown notice over an image, your site will remain active and, with good backups, you can get your site back up more quickly.

It is a way to guard against misuse of the DMCA or fair use disputes.

However, since then I have backed away from that stance. Once I moved to my new VPS, I stopped hosting images remotely as I have a good relationship with my host and have no reasons to worry. That being said, in an effort to improve the efficiency of the site, I’ve also started toying with Amazon S3 to see if it can help improve the site’s speed (the images in this post will be hosted on S3 as part of the test).

It was at this point that I realized a problem. If I were malicious in my use of S3, or any similar service, it could be used as a method not to prevent complete site failure, but to avoid a DMCA altogether. It is possible, using these services, to trick users into filing complaints with the wrong hosts, delaying or even preventing anything from being done.

I immediately, using my own site as a test subject, began to seek a way around it and, fortunately, found a way to ensure that, no matter where a file is hosted, you’ll always be able to track down the host with reasonable accuracy.

The Nature of the Problem

If you right click on the images in this post and view their URL, you’ll see that they are hosted on a subdomain of Plagiarism Today named “files.plagiarismtoday.com”. This makes it appear, including to many automated tools, that the content is hosted on the same server as the rest of the site. The problem is that they are hosted on Amazon S3, clear across the country.

This trick is fairly trivial to do and only involves a minor tweak to DNS. There are many legitimate reasons for doing it, for example, hosting images on your domain while using a content delivery network to increase speed.

However, if a copyright holder decided one of these images were infringing, filing a DMCA notice would be difficult. The reason is that since the files are on a subdomain of plagiarismtoday.com most will assume it’s located on my server and act accordingly. This is due to a fluke in both the way we read URLs, where we routinely ignore subdomains, and the way networking tools routinely discard subdomain information.

Some copyright holders, especially those less familiar with DNS and networking, might not consider this and could inadvertently file a DMCA notice or other abuse complaint with the wrong host. This can result in a delay in getting a complaint resolved, in it being outright ignored or even causing it to be handled in a questionable way.

The good news is that there is a simple way around it and, as long as you are careful about how you gather your information, there is no need to make this mistake.

Dealing with Linked Files

When you’re dealing with an image file or any content that is linked into a Web page (not part of the actual HTML) it is important to make sure that you get the correct information about where that particular file is hosted, not just the page that it is on.

The solution is pretty simple:

1. Get the URL of the File: Rather than copying the URL of the page, right click the image or the link and copy the URL. Check and see if it is on the same site, a subdomain or another domain altogether.
2. Use Who Is Hosting This: Once you have the URL, delete the “http://” as well as everything including and after the first remaining “/” and process it through Who is Hosting This. Who Is Hosting This handles subdomains correctly, unlike Domain Tools, which strips out subdomain information in my testing.
3. Confirm the Results: You can then confirm the results by copying the IP address (you’ll have to actually copy the numbers on the site, not using the link) and then running it through Domain Tools. Once you’ve done that, you can then go forward and begin the work of finding the DMCA or abuse agent and contacting them.

Though this adds a few extra steps to the process, it is worth doing to ensure that you contact the correct party as doing so is the only way to guarantee the quickest and most reliable resolution.

Why This is Important

The reason that this is critical is because sending a DMCA notice to the wrong host, at the very least, will greatly slow down the process as the host has to research and figure out what is going on and then decide if they going to A) Disable the page anyway B) Forward the notice on or C) Do nothing.

Since the company that hosts the Web site does not host the image, their role under the DMCA is much less clear. Section 512(c), which usually deals with Web hosts and takedowns, only pertains to “the storage at the direction of a user of material that resides on a system or network controlled or operated by or for the service provider”. Since there is no storage, a regular DMCA notice doesn’t apply.

Section 512(d) does pertain to “information location tools” but in that case, it would be the site owner, not the host that is party for the notice. This section deals with sites, such as Google, that are “referring or linking users to an online location containing infringing material or infringing activity”. Since the host isn’t the one linking to the file, it is the user, the application of 512(d) doesn’t make as much sense.

This isn’t to say that hosts won’t deactivate sites or remove pages if the content is embedded or hyperlinked, especially if the site is spammy in nature or has other abuse issues, but the fastest way to secure removal of images or other media files is to go to the source.

It can be a bit tedious to do, but it is well worth the time.

Bottom Line

The simple truth is that the days of all of the content on a site being hosted on the same server have long since passed. Content embedding from photo sharing sites, video sites and elsewhere have made it much more difficult easily track down where a particular item is hosted.

Though sometimes, as with YouTube clips, where the content is hosted is obvious, other times, as with image hosts, it is much less clear.

Unless you are dealing with textual works, which are almost never embedded (unless you use a service such as Voxant Newsroom that embeds text via Flash and JavaScript), this is something you have to constantly watch out for.

Dealing with content theft issues is not difficult, but it does require a bit of detective work. However, knowing the challenges you face and the tools that can help you overcome them can keep the sleuthing required to a minimum.

Update 4/21/2010: Sadly it appears I spoke too soon. Flickr is still stripping EXIF data on resized images. Update coming.

Though the orphan works bill has been defeated for this year, there is still a tremendous amount of interest among visual artists about ensuring that their works carry their names and information with them. It is largely assumed that the bill will be reintroduced next year and that, at some point in the near future, that there will be a risk of their works becoming orphaned.

However, in the age of the Internet, photographers have also become more reliant on photo sharing services for hosting their work and their online portfolios. It has been an easy way to get their works online and find an audience.

Unfortunately, at least some of those services seem to be working against artists in keeping their works clearly marked. Though many routinely insert EXIF metadata into their images, at least two of the most popular image hosts, Flickr and Facebook, are routinely stripping that information out before posting the information online.

This could, should the orphan works bill passed, cause many photographers, including those that used due diligence in marking their work, to have their works become orphaned and used legally without their permission.

The worst part is that it is a simple fix on the host’s part, but also one that Flickr has been aware of for at least six months.

Background

Back in April, photographer James Duncan Davidson posted a blog entry detailing an error with Flickr that caused copyright and other metadata to be stripped from uploaded and resized images. He also posted his observations to Flickr’s feature request forums, where it became a popular suggestion.

However, even after over six months of activity, the post has not gotten a single response from the Flickr admins nor has the feature been implemented. So, I decided to conduct an experiment to see if Flickr had quietly instituted the fix and also see if a few other popular image hosts had similar problems.

The results were very surprising.

An Experiment

To conduct an experiment, I took one of my snapshots from my trip to Newcastle, UK and added some very basic copyright metadata to it. To do this, I used the open source application Reveal for the Mac.

After I added the metadata, this is what was shown in the photo information.

I then uploaded the image to some of the popular photo sharing sites and re-downloaded the image to see if the metadata remained intact. I started with Flickr.

After uploading and re-downloading the displayed copy of the image, I noticed that the file size was significantly bigger but, once I opened up the metadata in Reveal, this is what I saw.

The new photo had completely stripped out the pertinent copyright information, along with all of the other metadata that I could see.

After that, I decided to try Facebook. With over 10 billion photos hosted, Facebook is the largest image host in the world currently. I did the same process with Facebook and, when I re-opened the metadata in Reveal, I saw that, again the information had been stripped out.

It was immediately clear that both sites strip out all image metadata. Though Flickr does make a point of reading and parsing much of it, especially information pertaining to the camera, before posting it, none of it is displayed on the versions that are public-facing.

Two that Preserve it

After being disappointed with Flickr and Facebook, I decided to try two other image hosts to see how they handled the metatadata. First, I tried a host that I have used in the past on this site, Imageshack.

With Imageshack, I did two checks, first I uploaded the image without resizing and then with a reduction to a “Web-friendly” size. I downloaded both versions. In both cases, the metadata was preserved.

I then decided to try Photobucket, an image sharing service I continue to have many sharp disagreements with, taking a similar set of steps that I did with Imageshack. However, once again, both the raw and the version resized with their online software preserved the metadata perfectly.

While I have many other copyright-related concerns regarding Photobucket, it is nice to see that their system does handle this one issue correctly.

Still, for photographers, these results leave a lot of uneasy questions to be answered.

What Can Be Done

The problem with the results above is that neither Photobucket nor Imageshack are widely used by professional or even amateur artists. They are much more common as image hosts for blogs or social networking sites and host a lot of personal photos as well as more than a decent amount of copyrighted work.

However, there are a lot of photographers and artists putting their work on Flickr to share it or using Facebook as something of a personal resume. In those cases though, any metadata that they are adding is being stripped out before at least most of the images go online.

The onus, right now, is on these services to fix this problem but there seems to be very little push to do so. As such, the only way to ensure that your copyright information is carried with the works you submit through these services is to make it part of the image itself, most likely through some form of visual watermarking.

Until these issues are fixed, artists have to assume that any image posted on Flickr or Facebook will be passed around the Web with no identifying information, greatly increasing the probability that they could become orphan works should the bill pass.

Conclusions

Sadly, these aren’t the types of issues most image hosts think about when designing their product. They worry about providing a good user experience, giving enough space, having enough features and building a good business plan. Whether the metadata is preserved, is not a major issue from their standpoint.

However, to me, these are the types of small details that can have a big impact on artists and separate the great image hosts from the good.

Though Flickr has made a great reputation as a place for artists and photographers, it has shown a lot of disregard for their rights. From snafus with the API to confusing licensing terms, Flickr has been anything but an oasis for artists concerned about how their work is being used.

If the orphan works bill passes, these issues will go from being minor inconveniences to major concerns and all image services are going to have to address these problems, one way or another.

However, the time to start thinking about these things is now, before the law passes and a potential crisis is at hand. Waiting until the law does pass could be too late.

As of right now, the petition has gartered nearly 900 signatures and is growing at a very rapid pace. This is due almost exclusively to a huge push from the art community itself, specifically the efforts by several well-known deviantART member including lone-mono, budgie and dozens of others.

I have to say that I have been thoroughly overwhelmed by the response and I want to thank everyone that has posted the petition and the original article on their site. Without your help in getting the work out, this would not have been possible.

Right now my plan is to allow the petition to collect more signatures. Once it reaches over a thousand signatories, I plan to present it formally to the PhotoBucket staff. I will resubmit every time the petition crosses another 500 signatures until we receive a response.

I want to stress that there is a need for both unity and civility at this point. Though emotions understandably run high with this issue, cooler heads prevail in these types of disputes. I want to encourage everyone to give PhotoBucket a chance to address these issues and to not take any unilateral action that could hurt the cause. The next steps are being being planned already and everyone will be involved.

Finally, to all of the deviantART members who are new to this site, I would encourage you to take a look at the Ripped Art Task Force. They are a great deviantART group that deals with the issue of art infringement in a strong, professional manner.

They are a highly recommended resource for deviantART members.

Again, thank you all for your support and please, continue to help get the word out there. As the saying goes, this battle has just begun!

Update 1 PM CT: We are now one of the top ten most active petitions on PetitionOnline.com. See Image Below:

Update 4 PM CT: Rather than send the petition end at the tail end of a work day, I will send it in first thin the morning. I will post updates here and to the other entry after it has been sent off.