Google Drive

On 2012-04-27 03:16:40 -0700, me said:

On Thu, 26 Apr 2012 19:48:56 -0700, Savageduck
wrote:


For now, Google Drive does not have a URL shortening feature similar to
that found in Dropbox.
So having said all that, try this for size. These files are set for all
those with access to the URL & according to the set up, download not
permitted. (We shall see.)
https://docs.google.com/open?id=0BwB...GFHZ3hESjdlQm8
and
https://docs.google.com/open?id=0BwB...FFNU0JtSzc0eUU

Those seemed to be quite BIG, so I have resized them down to acceptable
SI levels:

https://docs.google.com/open?id=0BwB...DNOaDU5UmVIR1U
and
https://docs.google.com/open?id=0BwB...XQ1NG92ZkdOZzA


???

3485: 1600x1084 no exif @ 309KB vs 1200x813 with exif @ 279KB
4300: 1600x1073 no exif @ 294KB vs 1200x805 with exif @ 291KB

So given you first set is Google resampling what is shown to a smaller
size and not allowing access to the original?

OK! This is what I posted.
The first set:
3485: 3720x2520 with exif @ 5.9MB
4300: 1920x1288 with exif @ 851KB

The second set which I resized in CS5:
3485: 1200x813 with exif @ 286KB
4300: 1200x805 with exif @ 299KB

I set the Google Drive sharing options for each of the four URLs to
allow viewing access without "download permission" to all recipients of
the URL.
I guess the ability to right click remains intact, but Google is saving
itself bandwidth by resampling larger files viewed by recipients, and
not permitting "download" or "access" to the originals. With my larger
files that also included striping EXIF data.
As the file "owner" I see no differences in the files when I open the
URLs. I must assume at this point, that if I permitted unrestricted
sharing, or full collaborative editing rights, the recipient would have
unrestricted access to the original file.

So for now Google Drive is a little different to Dropbox, Pogoplug, and
even iDisc+FileChute(which dies on July 1, 2012.)
The conclusion I have come to is, this provides another file sharing
option, but users should be aware of the results and consequences of
any such file sharing. I continue my learning process

--
Regards,

Savageduck

Savageduck writes:

So having said all that, try this for size. These files are set for
all those with access to the URL & according to the set up, download
not permitted. (We shall see.)
https://docs.google.com/open?id=0BwB...GFHZ3hESjdlQm8

Access: ok. I get a page with menus, and the image. The "File" menu
does not contain a "Save" option.

However, right-clicking lets me save from the browser as usual. There's
really no way to display a photo on my monitor without sending me the
bits, and if you send me the bits, I can capture and save the bits.

(You could write a special browser plugin that made a special encrypted
connection, separately from the browser, to fetch data to display. It's
possible you could write it so that it prevents screen capture from
working, maybe (depends on the OS). And you can detect when you're
running in a virtual machine and refuse to do so (otherwise the bits are
sent again to the real display, where I can do screen capture on them).
And when you're done, nobody will install your plugin so nobody can see
your pictures :-). AND I could capture the stream, find the key, and
decrypt it anyway.)
--
David Dyer-Bennet, ; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

On 2012-04-27 07:22:33 -0700, David Dyer-Bennet said:

Savageduck writes:

So having said all that, try this for size. These files are set for
all those with access to the URL & according to the set up, download
not permitted. (We shall see.)
https://docs.google.com/open?id=0BwB...GFHZ3hESjdlQm8

Access: ok. I get a page with menus, and the image. The "File" menu
does not contain a "Save" option.

I know you are a G+ user and I am sure you were given a view as a
Google Docs file and the sharing restrictions and/or permissions are
similar to those found in Picasa and G+. So the "Save" or "Download"
option was not present.

However, right-clicking lets me save from the browser as usual. There's
really no way to display a photo on my monitor without sending me the
bits, and if you send me the bits, I can capture and save the bits.

I suspected as much hence my "(We shall see.)"

(You could write a special browser plugin that made a special encrypted
connection, separately from the browser, to fetch data to display. It's
possible you could write it so that it prevents screen capture from
working, maybe (depends on the OS). And you can detect when you're
running in a virtual machine and refuse to do so (otherwise the bits are
sent again to the real display, where I can do screen capture on them).
And when you're done, nobody will install your plugin so nobody can see
your pictures :-). AND I could capture the stream, find the key, and
decrypt it anyway.)

I have built various web galleries with Bridge and LR some in html and
some as Adobe Flash galleries with/without slideshow. It is possible to
inhibit downloads and capture using Flash. However that also inhibits
sharing due to widespread negativity towards Flash.
Fortunately I am a hobbyist, not depending on my photography for an
income, therefore I am not that anal over protecting any images I
choose to share. I currently hold to minimally protecting my ownership
rights and permitting sharing via Creative Commons, Noncommercial.
http://creativecommons.org/licenses/by-nc-sa/3.0/us/


--
Regards,

Savageduck

On Fri, 27 Apr 2012 09:22:33 -0500, David Dyer-Bennet wrote:

However, right-clicking lets me save from the browser as usual. There's
really no way to display a photo on my monitor without sending me the
bits, and if you send me the bits, I can capture and save the bits.

While true in essence, some do go out of their way to make it difficult.
In some countries with DMCA (or the legal equivalent) it could very
probably be argued that something as lame as a javascript override of the
context menu (to remove the save image option) would constitute a copy
protection technology that it is illegal to attempt to circumvent. I
don't know that that theory has ever been tested in court, though.

(You could write a special browser plugin that made a special encrypted
connection, separately from the browser, to fetch data to display. It's
possible you could write it so that it prevents screen capture from
working, maybe (depends on the OS). And you can detect when you're
running in a virtual machine and refuse to do so (otherwise the bits are
sent again to the real display, where I can do screen capture on them).
And when you're done, nobody will install your plugin so nobody can see
your pictures . AND I could capture the stream, find the key, and
decrypt it anyway.)

Making sure that it is possible to deliver "content" to "consumers" is
the whole point of the "secure computing initiative". (i.e., secured
*against* the computer's owner.) Already there are plenty of ways for
movie and audio content of various sorts to not play, even though you
posess the bits. Even the "analog hole" has had a few somewhat-effective
attempts to plug them.

Our best hope for sanity is that content producers will discover (just as
most downloadable music distribution has, and book publishers are
starting to discover) that the downsides of DRM outweigh the benefits.
Book sellers are starting to realize that the contracts that come with
DRM protection lock them into a monopolist distribution chain that isn't
necessarily to their best advantage.

Cheers,

--
Andrew