Why not block images from API if right-click turned on?

darryl

Yes, we all know that right-clicking isn't true protection against downloading images.

But... if somebody is selecting it, isn't it reasonable to assume that they *don't* want somebody to download their images using RapidFetcher or WinDownload.

Couldn't (and shouldn't) the API return zero images for a gallery with right-click protection turned on?

This wouldn't break linking (although do people really right-click photos but leave linking on? That seems... odd.)

I just showed a friend who's a pro photog WinDownload, and she was mildly concerned that her photos could be so easily gotten. Not hugely so, since she only allows up to Medium and watermarks as well, but it surprised me too.

Thoughts?

pearsonartphoto

It's even worse, images often show up with external links disabled. At least, the medium images my program uses show up, I don't know about the larger ones... It's a tough balance between usability and protection...

darryl

In the context of the web, it's difficult to protect anything. Once somebody can see something in their browser, they can download it. SmugMug really has no control over that. (This is how people are able to bypass right-click and no external linking "protection", and why a determined person can always download the image they see in their browser.)

BUT, I'm talking about API calls that SmugMug has control over. In this case, it's a progam that's talking to SmugMug's API, and as such, SmugMug can reveal as little or as much information as they wish.

In this case, SmugMug could prevent the links to images in a right-click protected gallery from going back to the program making the API call for a gallery.

Dsweet

If you already have watermarks (web site address) on them, and they are small, and someone bulk-downloads them, aren’t you getting more exposure? I ask this sincerely. I am not a professional photographer. I want to understand your concerns.
It seems to me that you wanted the public to see the small, watermarked, pictures or you wouldn’t have exposed them. You can always add a site or album password if you don’t want the public involved. You want potential customers to see the samples and then buy it. How does downloading them change that as long as they can find your web site should they want to buy it?
Am I missing something? Am I naïve?
Downloading images when the owner doesn’t want it was not the intended purpose of the program.
One objective was to allow my friends, family and sports team mates to download multiple pictures or entire albums, or sets of albums, without clicking on them one at a time or having to make lots of CDs and distributing them.
The other objective was to be able to easily find and download my (the owners) originals for use in other applications (backup, slideshows, phones…).

darryl

Hi Dsweet. Hey, I really love WinDownload, and certainly don't think you're doing anything wrong. (In fact I used it to download 203 photos a friend took of my 40th birthday party, and it worked beautifully. So thanks, and sorry for calling you out specifically. It's just that your app works really really well. And when I demoed it for my friend, she asked about right-clicked photos, which I hadn't thought about. :-)

I agree that with watermarking and small-sized images, my friend really shouldn't worry about extra exposure (and she doesn't, really). But the point is that right-click protection implies that the person *doesn't* want people downloading their photos.

If SmugMug blocked right-click protected images from API calls, then your objective to allow friends, family and sports teammates (or owners) to easily download images would not be affected, right?

But for professionals, they might have some assurance that at least it's a little harder for people to download their whole portfolio, etc.

It's true that users should *not* be lulled into a false-sense of security since right-click protection can be worked around without much effort. But it doesn't make sense to me that the API wouldn't treat the same as "no download".

Basically, I'm asking what is the scenario where an owner would right-click protect his photos and then need to allow the API to have access to those photos to non-owners?

Dsweet

As you stated previously, in the html world there isn’t any difference between viewing a file and downloading it because a browser has to download it before you can view it in your browser. So, if you don’t allow programmers who use the api to download images from right-click protected albums then you are also preventing viewing by any and all 3rd party applications ever developed. I am not sure that is what all professionals will want, especially in light of the fact that right-click protection is not really protection anyway.
Should WinDownload skip right-click protected albums?... let me sleep on that.

darryl

Dsweet wrote: »

As you stated previously, in the html world there isn’t any difference between viewing a file and downloading it because a browser has to download it before you can view it in your browser. So, if you don’t allow programmers who use the api to download images from right-click protected albums then you are also preventing viewing by any and all 3rd party applications ever developed. I am not sure that is what all professionals will want, especially in light of the fact that right-click protection is not really protection anyway.
Should WinDownload skip right-click protected albums?... let me sleep on that.

You shouldn't change anything Dsweet. SmugMug should.

I just don't see any legitimate use case for 3rd party application to ever need to download right-click protected albums.

Thanks for thinking about it though, and helping me flesh out my points.

Dsweet

darryl wrote: »

You shouldn't change anything Dsweet. SmugMug should.

I just don't see any legitimate use case for 3rd party application to ever need to download right-click protected albums.

Thanks for thinking about it though, and helping me flesh out my points.

You are right about download, but it is not download (only). If you don't allow download, you don't allow viewing; they go together in the html world! I don't think one can state that no 3rd party application should be permitted to view those albums.

pearsonartphoto

I'll agree actually upon further thought that I don't think right protected albums can or should be protected from viewing. I put the protection on all of my albums, but I do want the ability to show my images on my phone, without a person needing to be logged in. I could, for instance, hand a person my phone with no worries that they will be able to do something with my images. But I still want the click protection in place. It's a tricky issue, as to what should be done...

darryl

To get more technical, I am *not* proposing that any images be blocked for API download. (Because technically the API doesn't even handle downloads.)

Instead, I propose that if you make a public (not logged in as owner) call to smugmug.images.get for a gallery that has right-click protection turned on, no image locations (download URLs) will be returned.

I hadn't thought about the iPad/iPhone app scenario though. Hm...

Dsweet

darryl wrote: »

To get more technical, I am *not* proposing that any images be blocked for API download. (Because technically the API doesn't even handle downloads.)

Instead, I propose that if you make a public (not logged in as owner) call to smugmug.images.get for a gallery that has right-click protection turned on, no image locations (download URLs) will be returned.

I hadn't thought about the iPad/iPhone app scenario though. Hm...

When a user makes an album public and sets the right-click-protection, they are declaring that the public can view my images, but I don’t want the public to download them.
The downside to your proposal is that if no image locations are returned then the public can’t view the image; contradicting what the owner has specified. Let’s not throw the baby out with the bath water.
I think the api is appropriate the way it is. If an owner declares an album is public then it should be public, SmugMug has taken steps to make it harder to download “protected” (Public-protected-oxymoron ) images through the SmugMug web interface , but they are still public. If an owner does not want the album to be public, then, as you know, SmugMug has provided many other ways to hide images and protect originals from the general public.

Dsweet

WinDownload - I have made the changes. If owners have specified "right click" (no download) protection, then WinDownload will repsect that.

darryl

Hey all -- I was trying to find some info about the iPad Photos API and came across a post regarding Flickr's API that directly relates to this topic:

http://www.revellphotography.com/blog/2010/06/is-my-ipad-stealing-your-photo/

Apparently on Flickr if you set the account-wide option for "Who can download your stuff?" to "Only You", then the API does not allow programs to access the full-sized original file.

Now SmugMug is a lot more flexible, in that allowing full-sized originals and blocking downloads are gallery-specific options, but it seems to me that with respect to full-sized downloads for APIs, maybe they should adopt Flickr's approach.

Also, it occurs to me that if the API only denies access of full-sized originals, than Pearson's worry about displaying photos on the phone (using an iPhone app, for instance) really shouldn't be an issue, because the iPhone app (if written by a sane person) would not be downloading the full-sized original, because it wouldn't need that high-resolution of an image.

Thoughts, anyone?

darryl

(Note that I really appreciate Dsweet modifying his app to behave as it should. But really it's SmugMug who should change their API.)

jfriend

darryl wrote: »

(Note that I really appreciate Dsweet modifying his app to behave as it should. But really it's SmugMug who should change their API.)

I disagree. Right-click is downright stupid protection. It's a very, very mild deterrent. It can be bypassed by almost any teenager in seconds. It can be bypassed at all times with a simple screenshot. If the API were crippled when right-click protection was enabled, then lots and lots of apps built on the Smugmug API would simply not work on any gallery that had right-click protection. That would be a significant problem and a huge support burden (why doesn't XX app work on my gallery). You put the images on the web. Those images are available to anyone who wants them. Right-click is not a legitimate form of protection. Anyone who is relying on it for any real protection is entirely misinformed.

If you want real protection, then limit the size of the gallery images that can be displayed on the web to something small and/or use watermarks. The Smugmug API respects both these settings as it should.

darryl

jfriend wrote: »

I disagree. Right-click is downright stupid protection. It's a very, very mild deterrent. It can be bypassed by almost any teenager in seconds. It can be bypassed at all times with a simple screenshot. If the API were crippled when right-click protection was enabled, then lots and lots of apps built on the Smugmug API would simply not work on any gallery that had right-click protection. That would be a significant problem and a huge support burden (why doesn't XX app work on my gallery). You put the images on the web. Those images are available to anyone who wants them. Right-click is not a legitimate form of protection. Anyone who is relying on it for any real protection is entirely misinformed.

If you want real protection, then limit the size of the gallery images that can be displayed on the web to something small and/or use watermarks. The Smugmug API respects both these settings as it should.

You are of course technically correct.

But for the average user "Allow downloads" or "Protected" means what it says: Don't let somebody download my images. They don't want to think about watermarking, max-size, etc.

Can you give me some examples of SmugMug apps that would be broken if *Originals* (not any other size) were disabled based on the "Protected" flag?

darryl

Also, what if the API "failed gracefully" (stayed backwards-compatible, deprecated... what's the word I'm looking for?) by instead of serving the full-sized original, only served up Large if "Protected" was enabled. (Although I still don't think this is in keeping with the spirit of the option.

jfriend

darryl wrote: »

Also, what if the API "failed gracefully" (stayed backwards-compatible, deprecated... what's the word I'm looking for?) by instead of serving the full-sized original, only served up Large if "Protected" was enabled. (Although I still don't think this is in keeping with the spirit of the option.

If you don't want originals available (which you presumably do not if you're using right-click protection), then just set the max size on the gallery to something like XL. The publicly available API that does not require account credentials will respect that gallery setting.

Anyone using right-click protection and allowing originals has messed up their settings. That is not a combination that makes sense. Either you want your originals to be available or you do not. Adding right-click protection does not protect your originals. Never has. Never will. I can get to them in under a second (the time that it takes to type a -O onto the end of URL).

For completeness here, I should mention that there are two forms of using the API, an unauthenticated session and an authenticated session. An unauthenticated session is available to any one as it does not require any account credentials and it can access anything that you have configured your gallery settings to allow. An authenticated session requires valid account credentials and it can access originals even if the gallery settings do not permit public access to originals. This is so that tools meant to be used by the account owner can be built and so that partners that you authorize to access your account can get access to your images via the authenticated sessions.

darryl

jfriend wrote: »

If you don't want originals available (which you presumably do not if you're using right-click protection), then just set the max size on the gallery to something like XL. The publicly available API that does not require account credentials will respect that gallery setting.

Anyone using right-click protection and allowing originals has messed up their settings. That is not a combination that makes sense. Either you want your originals to be available or you do not.

Huh, i'd not thought of that. You're right. Thay combination of settings seems nonsensical. So much so that it begs the question why Smugmug allows it at all?

Adding right-click protection does not protect your originals. Never has. Never will. I can get to them in under a second (the time that it takes to type a -O onto the end of URL).

For completeness here, I should mention that there are two forms of using the API, an unauthenticated session and an authenticated session. An unauthenticated session is available to any one as it does not require any account credentials and it can access anything that you have configured your gallery settings to allow. An authenticated session requires valid account credentials and it can access originals even if the gallery settings do not permit public access to originals. This is so that tools meant to be used by the account owner can be built and so that partners that you authorize to access your account can get access to your images via the authenticated sessions.

Yes. I'm only talking about unauthenticated sessions. I'd posit that most of the tools we're talking about (bulk downloaders) would be used by either Owners or friends/family of people explicitly trying to share originals.

It's not like AlbumFetcher or CLDownload are widely known outside of the SmugMug community.

Also, again, I'm talking about the API, not the website. While yes, you can add -O to get one original at a time, it's a whole other story when you're talking about enabling slurping up a full gallery of photos.

what other apps are you concerned that this would break?

jfriend

darryl wrote: »

Huh, i'd not thought of that. You're right. Thay combination of settings seems nonsensical. So much so that it begs the question why Smugmug allows it at all?

Agreed. There is no valid reason for that combination. It only means that the user is confused. Smugmug should at least tell the user to fix/change one or the other.

jfriend

darryl wrote: »

Huh, i'd not thought of that. You're right. Thay combination of settings seems nonsensical. So much so that it begs the question why Smugmug allows it at all?



Yes. I'm only talking about unauthenticated sessions. I'd posit that most of the tools we're talking about (bulk downloaders) would be used by either Owners or friends/family of people explicitly trying to share originals.

It's not like AlbumFetcher or CLDownload are widely known outside of the SmugMug community.

Also, again, I'm talking about the API, not the website. While yes, you can add -O to get one original at a time, it's a whole other story when you're talking about enabling slurping up a full gallery of photos.

what other apps are you concerned that this would break?

A full gallery of photos can be slurped without the API. If they're shown in a browser, they can be slurped by any script jockey. Closing down the API doesn't prevent this.

I think the API is good. I think it enables interesting third party things. For example, one can write a client side JS script (no user credentials required) to automatically show photos in a blog, etc... I don't follow the community of apps that are out there to know what good comes from it or what would break if it was changed.

I just think right-click protection is no real form of protection and not really a security setting at all. It only prevents one particular access in a browser and doesn't prevent any of the other forms of access. As such, it's a browser presentation setting, not a security setting and therefore it should not control or influence what the API does or doesn't allow.

The API is correctly following the real security settings for a gallery (password, largest size available, watermarks, etc...) which are observed for all unauthenticated forms of access.