We've senselessly bashed "Right Click Revenue" twice now...



  • ...so I thought I'd show you guys this little trinket:  http://www.flickr.com/photos/jezza_s/184559178/

    Try right-clicking on the image, and choosing 'Save Image As'.  It returns 'Spaceball.gif' in IE, which is a blank gif.  Even with NoScript, I can't save the image in Firefox.  I know a simple printscreen will resolve this problem, but I'm sure the Right Click Revenue guy is already trying to steal this 'technology'.  Bash away!



  • This is a nice exemple of when CSS should be used to protect an image and not Javascript.

     Thank you Albatross.
     



  • Yeah, it's pretty simple, they overlay a transparent gif over the image - you only get to right click on the top-most one!



  • Look at the source code of the page and find the url to the gif you want to download. That you you can browse to it and download it normally.



  • You can still get the image easily enough via the source code: http://farm1.static.flickr.com/74/184559178_f06853eae1.jpg?v=1154054842

     Course, RCR is still a POS.



  • @Albatross said:

    ...so I thought I'd show you guys this little trinket:  http://www.flickr.com/photos/jezza_s/184559178/

    Try right-clicking on the image, and choosing 'Save Image As'.  It returns 'Spaceball.gif' in IE, which is a blank gif.  Even with NoScript, I can't save the image in Firefox.  I know a simple printscreen will resolve this problem, but I'm sure the Right Click Revenue guy is already trying to steal this 'technology'.  Bash away!

    In Firefox:



  • I just use Nikhil Kothari's web development helper to do things like this...   Just turn on the HTTP trace option and watch as the toolwindow happily shows you all the files your web browser is downloading.  (There's even a neat preview feature built right in)

    http://projects.nikhilk.net/Projects/WebDevHelper.aspx



  • Even easier, but requires AdBlock:


    • Tools->AdBlock Plus.
    • Doubleclick on Add filter.
    • Type "spaceball.gif".
    • Hit Enter.
    • Click OK.


  • @Albatross said:

    ...so I thought I'd show you guys this little trinket:  http://www.flickr.com/photos/jezza_s/184559178/

    Try right-clicking on the image, and choosing 'Save Image As'.  It returns 'Spaceball.gif' in IE, which is a blank gif.  Even with NoScript, I can't save the image in Firefox.  I know a simple printscreen will resolve this problem, but I'm sure the Right Click Revenue guy is already trying to steal this 'technology'.  Bash away!


    Not hard to beat.  I just clicked the "User mode/author mode" in Opera to turn off the site's CSS, and saved the image to my desktop.



  • Or you could just disable CSS.

     

    No pretty formatting FTW! 



  • @RaspenJho said:

    I just use Nikhil Kothari's web development helper to do things like this...   Just turn on the HTTP trace option and watch as the toolwindow happily shows you all the files your web browser is downloading.  (There's even a neat preview feature built right in)

    http://projects.nikhilk.net/Projects/WebDevHelper.aspx

    Firebug is the firefox equivalent.  It does the same, and probably more.

    http://www.getfirebug.com/ 

    The "Inspect this element" feature, navigable DOM tree, javsacript debugger extensions, and ability to re-author any part of a page realtime are invaluable.



  • @mdk said:

    Even easier, but requires AdBlock:


    • Tools->AdBlock Plus.
    • Doubleclick on Add filter.
    • Type "spaceball.gif".
    • Hit Enter.
    • Click OK.

    My variation was "right-click image, select 'Adblock image...', click OK".



  • So what's the best way to actually protect an image?  There are ways to deliver streaming content to your computer that don't stay in memory, and use that annoying technology where the print-screen only captures a solid block image where that color defines where the media shows through.  Maybe all of your protected images should just be streamed from the server!



  • @durnurd said:

    So what's the best way to actually protect an image?  There are ways to deliver streaming content to your computer that don't stay in memory, and use that annoying technology where the print-screen only captures a solid block image where that color defines where the media shows through.  Maybe all of your protected images should just be streamed from the server!

     

    That "solid color technology" that you are talking about is actually an artifact of placing the video on your screen.  See the video renderer actually is a post renderer that happens on most video cards now.  The system paints the screen and puts a solid color of a certain hue on screen, the video renderer then replaces this hue with the video stream.  because of this, the OS only knows about the solid color so when you screen print it, the OS copies what it knows about and places it in the clipboard.  This results in you actually seeing the overlay color. 



  • The real image has a nice onload function. Gotta love the variable and function names - at least they're descriptive :)

    from the JS source:

    function show_notes_initially() {
    	if(window.should_I_ignore_stuff_because_of_button_action||window.should_I_ignore_stuff_because_of_editable_div_action) {return ;}
    	var A=_ge("photo_notes");
    	if(A&&A.p_id){
    		A.shown_initially=1;
    		A.style.visibility="visible";
    		if(!A.tried_to_show_before_shown_initially){
    			A.go_away_in_a_bit();
    		}
    	}
    }



  • @asuffield said:

    @mdk said:

    Even easier, but requires AdBlock:


    • Tools->AdBlock Plus.
    • Doubleclick on Add filter.
    • Type "spaceball.gif".
    • Hit Enter.
    • Click OK.

    My variation was "right-click image, select 'Adblock image...', click OK".

    Right-click -> "Remove this"

    Right-click -> "Save As"

    Firefox extensions are turning me into a lazy brainless man...


     



  • @durnurd said:

    So what's the best way to actually protect an image?  There are ways to deliver streaming content to your computer that don't stay in memory, and use that annoying technology where the print-screen only captures a solid block image where that color defines where the media shows through.

    Holy crap dude, you thought that was some sort of image-protection technology? I'm LOLing on the inside. (and all you have to do to "defeat" that is turn off video acceleration) 

    To answer your first question-- the only way to protect an image is to not put it on the internet. That's it. 



  • There is always flash?  Makes it slightly harder to get at them.



  • @durnurd said:

    So what's the best way to actually protect an image?

    Don't post it on the Web.

    Seriously. If you don't want people to have copies of your precious content, don't give it to them. Or if you do want people to be able to see it, give them copies. The IP-Maximalist's fantasy of being able to make content available to the public but restrict when/where/how they can access it is a pipe-dream that can't ever work, and is fundamentally contrary to what a computer is.



  • Easy way to deal with transparent overlays...

     Firefox extension Nuke Anything Enhanced

     Right-click and "remove this object" to delete the transparent image, then save the real one normally.
     



  • @shaunburdick said:

    There is always flash?  Makes it slightly harder to get at them.

    No more so than this mechanism that we've just shredded half a dozen different ways.

    Images, video, and sound are three things that are completely impossible to cripple to the point where reproduction is not easy, since their very nature is that of intended output. Anything that must inherently be presented to the user is like this. 



  • You guys are really missing the right way to do it; encode the image as a table full of 1x1 cells with different colored backgrounds.  You could make the page a bit smaller by using huffman encoding on consecutive cells and assigning them to entities.  Try saving that with your 'right mouse button', geniuses.  (And as a bonus, almost nobody will have the patience to wait long enough to load it and take a screenshot).



  • @arty said:

    You guys are really missing the right way to do it; encode the image as a table full of 1x1 cells with different colored backgrounds.  You could make the page a bit smaller by using huffman encoding on consecutive cells and assigning them to entities.  Try saving that with your 'right mouse button', geniuses.  (And as a bonus, almost nobody will have the patience to wait long enough to load it and take a screenshot).

    I like the way this guy thinks...

    lets write an xsl to convert his to a bit map...

    nah still to much work, but you only need one nutter.



  • even without after market add ons or fancy browsers that actually let you control what you see on a webpage, you could always just do "file -> save as..." and save the whole page on your desktop.  bam, folder full of files in 3 clicks.



  • @arty said:

    You guys are really missing the right way to do it; encode the image as a table full of 1x1 cells with different colored backgrounds.  You could make the page a bit smaller by using huffman encoding on consecutive cells and assigning them to entities.  Try saving that with your 'right mouse button', geniuses.  (And as a bonus, almost nobody will have the patience to wait long enough to load it and take a screenshot).

     So help me god. Tested; it works.

    <html>
        <head>
            <title>Image to Table</title>
        </head>
        <body>
            <form id="TheForm" action="imagetotable.php" method="get">
                <input type="text" name="fileLocation" />
                <input type="submit" name="Go" value="Go" />
            </form>
            <?php
                if ($_GET['fileLocation']) {
                    if (($h_image = imagecreatefromstring(file_get_contents($_GET['fileLocation']))) == false) {
                        echo 'Image could not be found, or not a valid image.';
                    } else {
                        if (!imageistruecolor($h_image)) {
                            $h_newImage = imagecreatetruecolor(imagesx($h_image), imagesy($h_image));
                            imagecopy($h_newImage, $h_image, 0, 0, 0, 0, imagesx($h_image), imagesy($h_image));
                            imagedestroy($h_image);
                            $h_image = $h_newImage;
                        }
                       
                        // Too lazy to look up the CSS for cell spacing and cell padding
                        echo '<table border="0" cellspacing="0" cellpadding="0">';
                        for ($y = 0; $y < imagesy($h_image); $y++) {
                            echo '<tr>';
                            for ($x = 0; $x < imagesx($h_image); $x++) {
                                echo '<td style="background-color: #' . str_pad(dechex(imagecolorat($h_image, $x, $y)), 6, '0', STR_PAD_LEFT) . '; width: 1px; height: 1px;"></td>';
                            }
                            echo '</tr>';
                        }
                        echo '</table>';
                    }
                }
            ?>
        </body>
    </html>



  • GD and Table abuse

    LOL, They can't right click it if their browser's locked up!  (It really does work, though.)



  • May I suggest another way .... split your pictures in about 10-30 other pictures, all having only a (random) subset of pixels, and the rest transparent. Then overlay the sub-pictures ... shows just the same, but you'd have a lot of right-clicking to do.

    But that falls for the printscreen trick.... 

     

     Hey, that might even make a good image compression ... make a red background, and a blue image with various transparency levels, and a green image, and a yellow image, and some others ... and only the sum of all gives the "real" picture.

     



  • You guys are really missing the right way to do it; encode the image as a table full of 1x1 cells with different colored backgrounds.  You could make the page a bit smaller by using huffman encoding on consecutive cells and assigning them to entities.  Try saving that with your 'right mouse button', geniuses.  (And as a bonus, almost nobody will have the patience to wait long enough to load it and take a screenshot).

    I had a similar idea, but you can still take a screenshot :P  So my additional idea was to make it 1 pixel video screens, but you can still screenshot if you turn off video acceleration :P



  • could you register a print screen press from javascript? Because then you could perhaps quickly enough replace the image.
    Of course this wouldn't stop people who make a screenshot without use of the print screen button.
     



  • @durnurd said:

    So what's the best way to actually protect an image?  There are ways to deliver streaming content to your computer that don't stay in memory, and use that annoying technology where the print-screen only captures a solid block image where that color defines where the media shows through.  Maybe all of your protected images should just be streamed from the server!

    Streaming won't help you either. There are lots of streaming recorders freely available on the web (or just use wireshark). You couldn't block them either because as with all things on the 'net, there is no reliable way to find out what client you are streaming to.

    @stratos said:


    could you register a print screen press from javascript? Because then you could perhaps quickly enough replace the image.
    Of course this wouldn't stop people who make a screenshot without use of the print screen button.

    There isn't and there shouldn't be. And even if there were, just turn off JS.

    I second the poster above, the only way to protect your images on the web is not to post them.
     



  •  So help me god. Tested; it works.
    Of course it does.

    (well, only in the editor in this forum)



  • @Zylon said:

    @durnurd said:

    So what's the best way to actually protect an image?  There are ways to deliver streaming content to your computer that don't stay in memory, and use that annoying technology where the print-screen only captures a solid block image where that color defines where the media shows through.

    Holy crap dude, you thought that was some sort of image-protection technology? I'm LOLing on the inside. (and all you have to do to "defeat" that is turn off video acceleration) 

    To answer your first question-- the only way to protect an image is to not put it on the internet. That's it. 

    Oops, I forgot the </sarcasm> which seems to be necessary in every post that contains it.

    No, I didn't think it was some sort of image protection.  I know all about what it is.  I'm just saying that it's another step that "most" people don't know about.  I was just trying to think of an overly-complicated method of trying to protect an image which I know wouldn't really work, because as everybody knows (and has stated) you can't protect an image as long as you can actually see it with your eyes, which is kind of the point of an image.  It is only another step that "pirates" would have to get around to steal the image, and wouldn't discourage any of the people who really wanted to steal it.  It's just funny (for me anyway) to think about somebody going to such lengths (Streaming a still image!?)



  • I wonder if you could develop an ActiveX control to display the pics and interrupt the screenshots...



  • @RaspenJho said:

    I wonder if you could develop an ActiveX control to display the pics and interrupt the screenshots...

    I like your style. 



  • @durnurd said:

    So what's the best way to actually protect an image?  There are ways to deliver streaming content to your computer that don't stay in memory, and use that annoying technology where the print-screen only captures a solid block image where that color defines where the media shows through.  Maybe all of your protected images should just be streamed from the server!

    You could hardcode the image data into the page...this would probably confuse 99.9% of people out there.

    To reverse it, they have to have a program to read base64. Of course the downside is that images have to be downloaded every time you load the page, so no caching...

    Edit: I should add that this has to be used in conjunction with a right-click blocking scheme...



  • @savar said:

    @durnurd said:

    So what's the best way to actually protect an image?  There are ways to deliver streaming content to your computer that don't stay in memory, and use that annoying technology where the print-screen only captures a solid block image where that color defines where the media shows through.  Maybe all of your protected images should just be streamed from the server!

    You could hardcode the image data into the page...this would probably confuse 99.9% of people out there.

    To reverse it, they have to have a program to read base64. Of course the downside is that images have to be downloaded every time you load the page, so no caching...

    Edit: I should add that this has to be used in conjunction with a right-click blocking scheme...

    The other downside of course is that you have to include the string "base64" into your uri to make it work - and that the second google search result for "base64" is a decoder...



  • @Albatross said:

    ...so I thought I'd show you guys this little trinket:  http://www.flickr.com/photos/jezza_s/184559178/

    Try right-clicking on the image, and choosing 'Save Image As'.  It returns 'Spaceball.gif' in IE, which is a blank gif.  Even with NoScript, I can't save the image in Firefox.  I know a simple printscreen will resolve this problem, but I'm sure the Right Click Revenue guy is already trying to steal this 'technology'.  Bash away!

    Right-click on the image, "Remove this object". Right-click on the image, "View image". (Or "Save Image As", if you really want to.)

    Iceweasel, with Nuke Anything installed.

    Next?

    (Ack, someone had posted it. Well, "Right click -> View page info -> Media -> select the image from the list -> Save as..." does the same thing, without NukeAnything...)



  • @savar said:

    @durnurd said:

    So what's the best way to actually protect an image?  There are ways to deliver streaming content to your computer that don't stay in memory, and use that annoying technology where the print-screen only captures a solid block image where that color defines where the media shows through.  Maybe all of your protected images should just be streamed from the server!

    You could hardcode the image data into the page...this would probably confuse 99.9% of people out there.

    To reverse it, they have to have a program to read base64. Of course the downside is that images have to be downloaded every time you load the page, so no caching...

    Edit: I should add that this has to be used in conjunction with a right-click blocking scheme...

    It would also confuse most of the browsers out there as well, but who cares?  You can still, in that case, just right-click and save it, as with any method discussed earlier.

     
    If you have the "data:" url for the image (view->source), you can just paste it into the address bar (in Firefox at least) to view the image alone, then just save it however you wish.



  • @KattMan said:

    @durnurd said:

    So what's the best way to actually protect an image?  There are ways to deliver streaming content to your computer that don't stay in memory, and use that annoying technology where the print-screen only captures a solid block image where that color defines where the media shows through.  Maybe all of your protected images should just be streamed from the server!

     

    That "solid color technology" that you are talking about is actually an artifact of placing the video on your screen.  See the video renderer actually is a post renderer that happens on most video cards now.  The system paints the screen and puts a solid color of a certain hue on screen, the video renderer then replaces this hue with the video stream.  because of this, the OS only knows about the solid color so when you screen print it, the OS copies what it knows about and places it in the clipboard.  This results in you actually seeing the overlay color. 

    Actually, it turns out that some of the newer high-end cards don't support video overlay anymore anyway; it really doesn't play well with Vista or stuff like Compiz/Beryl, so it's not worth including.



  • @arty said:

    encode the image as a table full of 1x1 cells with different colored backgrounds

    I've seen a conversion program that turns images into CSS by defining absolutely positioned elements. The first version converted into 1 by 1 elements, the next converted into individual rectangular blocks, and later an optimisation was added to overlay rectangles in proper Z-order so it would use fewer elements. The later versions worked well on GIF and other palettised formats, but weren't terribly helpful on JPEG images.

    The amusing part is that when the guy started examining network bandwidth, he found that gz compression by the web server sometimes made the CSS definitions smaller than the original image.



  • @CDarklock said:

    @arty said:

    encode the image as a table full of 1x1 cells with different colored backgrounds

    I've seen a conversion program that turns images into CSS by defining absolutely positioned elements. The first version converted into 1 by 1 elements, the next converted into individual rectangular blocks, and later an optimisation was added to overlay rectangles in proper Z-order so it would use fewer elements. The later versions worked well on GIF and other palettised formats, but weren't terribly helpful on JPEG images.

    The amusing part is that when the guy started examining network bandwidth, he found that gz compression by the web server sometimes made the CSS definitions smaller than the original image.

    This is not hugely surprising. Combining this representation with a linear duplicate-sequence-elimination algorithm like DEFLATE gives you what is actually a two-dimensional duplicate elimination mechanism. The fact that it works in two dimensions rather than one is precisely why jpeg compresses images significantly better than gif/png (when jpeg is used in lossless mode).



  • This is the most paranoid image protector I've ever seen. It secures even from PrintScreen, although you could probably find out where it's pulling it's images from anyway...



  • that ripple effect is overkill considering the images appear to be loaded externally into the Flash file which means you can see them in your internet cache directory, the one you linked to is called "EL_BG31_05_02_P_3.jpg", the direct link to it on their site is http://www.tattoofinder.com/content/EL_BG31_05_02_P_3.jpg



  • @asuffield said:

    This is not hugely surprising. Combining this representation with a linear duplicate-sequence-elimination algorithm like DEFLATE gives you what is actually a two-dimensional duplicate elimination mechanism. The fact that it works in two dimensions rather than one is precisely why jpeg compresses images significantly better than gif/png (when jpeg is used in lossless mode).

    Compression efficiency (that is, when expressed solely as filesize and not factoring in image quality) is extremely dependent on image content. One cannot say that either PNG, JPG or GIF always creates the smaller file. The only rule I've found is that  the noisier the image, the less advisable it is to use GIF. Both PNG and JPG are better at squeezing noise; GIF is extremely good at squashing large areas. JPG has trouble with intense colour fields: blue skies are easily mangled into squares, and red detailing often breaks down into 2x2 blocks even at relatively low compression. This may be an artifact of certain (de)compressors, though.

    PNG-8 is often larger than the equivalent GIF, but may in some cases be crushed beyond GIF. I haven't tested that properly. I used pngcrush to remove the GAMA chunk from various PNGs I made, in order have them display correctly in IE[6|7], and this sometimes made the file a few bytes larger. I blame that on my own inexperience with pngcrush.

    PNG-24/32 is usually the largest for any given image, but I've had one or two cases where it was smaller by a little bit than the 100% JPG. Using Photoshop's JPG quality scale*, a JPEG is often reduced by a factor of 8 just setting the quality from 100 to 90.

    The only steadfast conclusion that can be drawn from image compression is that BMP should be outlawed.
     

    *) Paint Shop "Pro", for example, does not allow 100% quality like PS, and also allows one to completely destroy any semblance of image content, using the 0% quality. Why is there no universal scale in which to measure jpg compression, so that software can implement it?



  • @dhromed said:

    JPG has trouble with intense colour fields: blue skies are easily mangled into squares, and red detailing often breaks down into 2x2 blocks even at relatively low compression. This may be an artifact of certain (de)compressors, though.

    jpeg decompression is deterministic (all correct implementations give the same output). jpeg compression itself is also primarily deterministic, but includes an optional phase where the compressing application can choose to discard some information, and that part is up to the application. It's sometimes mislabelled as a compression level, but it's really just a matter of downsampling the red and blue planes to lower resolution, and then throwing away the low-order bits of certain 8x8 blocks, and the application gets to pick how much (if any) downsampling to perform, and how many bits to discard from each block. Poor choices generate artifacts in the image.

    Unlike algorithms like DEFLATE, where the window size and choice of strings for the dictionary permits variation in the effort and quality of the compression phase, jpeg has no such features. The only possible variations are in the phase where information is discarded. 

     

    Why is there no universal scale in which to measure jpg compression, so that software can implement it?

    Precisely because it's a different algorithm in each application, and the choice of which blocks is far more important to the apparent image quality than anything else. Any bits discarded from a block containing a 1-pixel high-contrast line will ruin it, while most of the bits can be discarded from a block containing a plain colour or smooth gradient with no visible impact. Deciding what to do with a non-trivial block is a subjective problem. The actual compression ratio is almost completely unrelated to the resulting image quality.



  • @asuffield said:

    [stuff]

    Interesting stuff. 

    I was under the impression that decompression had plenty variablity: http://www.stereopsis.com/jpg/ (2001) (btw: prize for stable website changing more slowly than rock formations.)



  • @dhromed said:

    PNG-8 is often larger than the equivalent GIF, but may in some cases be crushed beyond GIF.
    The only case in which I've seen 8bit PNGs larger than the eqivalent GIF file was when using interlacing - PNG's (although visually superior) interlacing algorithm sucks size-wise when compared with GIF (interlaced and non-interlaced GIFs are usually almost the same size, interlaced PNGs are always much larger than non-interlaced ones).
    I haven't tested that properly. I used pngcrush to remove the GAMA chunk from various PNGs I made, in order have them display correctly in IE[6|7], and this sometimes made the file a few bytes larger. I blame that on my own inexperience with pngcrush.
    Hint: pngcrush is outdated. Use either advpngoptipng or pngout, they all produce better results (and advpng is extremely fast when compared to any of the others).

    Paint Shop "Pro", for example, does not allow 100% quality like PS, and also allows one to completely destroy any semblance of image content, using the 0% quality. Why is there no universal scale in which to measure jpg compression, so that software can implement it?
    There's no single scale for JPEG compression - the actual compression depends on the quantization tables, and different software uses different tables. If you're more interested in the subject, there was a long discussion about this recently on the GIMP developer mailing list (search for "jpeg quality factor" in the archives).



  • @Tann San said:

    that ripple effect is overkill considering the images appear to be loaded externally into the Flash file which means you can see them in your internet cache directory, the one you linked to is called "EL_BG31_05_02_P_3.jpg", the direct link to it on their site is http://www.tattoofinder.com/content/EL_BG31_05_02_P_3.jpg

    Less than an hour for somebody to break it. I love this site!



  • @dhromed said:

    I was under the impression that decompression had plenty variablity: http://www.stereopsis.com/jpg/ (2001)

    Some of that may be bugs, but I'm betting that almost all of it is postprocessing filters in the 'decompressors'. All too many such libraries do more than just decompress images; they also mangle them according to some preconceived notion of what images 'should' look like, with decidedly variable results when applied to unexpected images.



  • @dhromed said:

    The only steadfast conclusion that can be drawn from image compression is that BMP should be outlawed.


    RLE-compressed BMP makes for reasonably small images if the source has large areas of solid color.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.