How to prevent downloading images and video files from my website? - html

How to prevent downloading images and video files from my website? Is it possible?
What would be the best way to do this?

No, it's not possible.
If you can see it, you can get it.

Don't post them to your site.
Otherwise it is not possible.

As the browser needs to transfer the content to display it (text, images, videos), the data is already on the client's computer when the website is displayed. The previous answers give little advice on how to make it harder for non-experienced users to grab the content. Here are some directions:
General
Overlay the respecitive contents with a transparent <DIV> or a
transparent image (as described in some answers to this question)
Open the website in a frameset, so saving may miss the frame content.
Open the website via window.open() to hide the menu bar.
Disable right-clicks via JavaScript (not recommended due to all the side-effects on usability)
Load the page's HTML code from another file (which may check for a specific referer or which may be ROT13) via JavaScript, so it's harder to access the source code.
Tell the browser that all content is display:none for the printer (something like #media print { body, div, p { display: none } })
Use JavaScript to hide the content before a client makes a screenshot (see Stop User from using “Print Scrn”)
Try to disable or overwrite the clipboard (see this post)
Images
Do not use the <img> tag for images but set the image as background for a <DIV>
Wrap images into SVGs or Flash movies to make them very hard to access in a usable format.
Disable caching for images (via <meta> tag or by setting the appropriate header on server delivery), so they are not stored in the browser cache (immeaditely accessible on the client's computer).
Cut an image into parts, so it takes some extra work to reconstruct the whole image
Add onmousedown events to images, e.g., display a copyright alert.
Deliver the image via server script (e.g., PHP) and check the referer.
Videos
Stream videos to prevent simple downloading via URL.
Wrap videos into a Flash movie.
Use some nasty format that supports DRM.
Texts
Make text unselectable (see How to make HTML Text unselectable)
Additionally to overlaying, wrap the text into JavaScript (e.g., after ROT13 or loaded dynamically from a second file), so the text is not directly available in the source code.
Convert texts to images (this may decrease display quality), SVGs or Flash
Again, I repeat that none of this will stop an experienced user from grabbing the content (e.g. by making a screenshot and - optionally - run OCR on it). Sometimes it's as easy as using the browser's developer tools or using the website without JavaScript. Yet, it will give inexperiences users a hard time, so they may look for some easier source to grab from.
Also keep in mind that the above techniques will affect search engines when reading the page's content (if you're interested in blocking them, start with a robots.txt).
Thank you for any other ideas to complement the above list!

Images must be downloaded in order to be viewed by the client. Videos are a similar case, in many scenarios. You can setup proxy scripts to serve the files out, but that doesn't really solve the issue of preventing the user from getting their own copy. For a more thorough discussion of this topic, see the question How can I prevent/make it hard to download my flash video?

If you are using PHP, the best way is to control it the .htaccess, you need to put your files, images and videos under consideration in a separate folder/directory, and create a new .htaccess file in this directory with the below:
RewriteEngine On
RewriteCond %{REQUEST_URI} \.(mp4|mp3|avi)$ [NC]
RewriteCond %{HTTP_REFERER} !^http://sample.com/.*$ [NC]
RewriteRule ^.* - [F,L]
The first line %{REQUEST_URI} will prevent getting the file through the web browser or through curl.
The second line %{HTTP_REFERER} will prevent accessing the image/video using HTML tags <img> or <video> from any website except the exception ! you provide instead of http://sample.com/ which usually should be your website itself.
You can also have a look at my question and the accepted answer here for more tricks on the browser side.

I'd like to add a more philosophical comment. The whole intent of the internet, particularly the World Wide Web, is to share data. If you don't want people to download a picture/video/document, don't put it on the web. It's really that simple. Too many people think they can impose their own rules on an existing design. Those who want to post content on the web, and control its distribution, are looking to have their cake and eat it too.

In short, no. If someone can view an image or video in their browser then they have, by definition, downloaded it. That's how the web works - it is client server based. Whatever you can view in your browser (client) has been transfered to your computer from the remote website (server).

In standard HTML, I don't know of anyway.
You didn't really say, but I'm guessing you are having problems with people deep linking into your content. If that's the case, and you are open to server side code, I believe this might work:
Create a page that accepts a numeric
id, maps it to a server file path,
opens that file, writes the binary
directly to the response stream.
On the page request, generate a
bunch of random ids, and map them to
the actual media urls, and store that
mapping object server side somewhere
(in session?) with a limited life.
Render your pages with your media
links pointing to the new media page
with the appropriate id as a query
string argument.
Clear the mapping object and generate
all new links on every postback.
This :
won't stop people from downloading
from within your page
definitely isn't as lightweight as standard
HTML
and has it's own set of issues.
But it's a general outline of a workable process which might help you prevent users from deep linking.

As many have said, you can't stop someone from downloading content. You just can't.
But you can make it harder.
You can overlay images with a transparent div, which will prevent people from right clicking on them (or, setting the background of a div to the image will have the same effect).
If you're worried about cross-linking (ie, other people linking to your images, you can check the HTTP referrer and redirect requests which come from a domain which isn't yours to "something else".

you can reduce the possibility but not eliminate it...

It also doesn't hurt to watermark your images with Photoshop or even in Lightroom 3 now. Make sure the watermark is clear and in a conspicuous place on your image. That way if it's downloaded, at least you get the advertising!

This is how I do it in case anyone in the future is wondering.
I put this in the .htaccess file on the root server:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http://(www\.)?domain.com/ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?domain.com.*$ [NC]
RewriteRule \.(mp4|avi)$ - [F]
This stops them from say going to domain.com/videos/myVid.mp4 and then saving it from there.

No it's not. You may block right-clicks and simillar stuff but if someone wants to download it, he will do so, trust me ;)

As soon as they view your page that includes the picture or video, the item is downloaded into the temporary folder of their browser. So if you don't want it downloaded, don't post it.

You can mark folders or files so that they don't have read access (any of the main web servers support this). This allows you to store them on the server without any level of access to the outside world. You may want to do this if you have a service that generates images for someone else to download later, or if you use your web account for FTP access, but don't want anyone to view the files. (i.e. upload a .bak file to the server for someone else to FTP down again).
However, as others have said, getting into copyright areas where people can view the image or video but not save them locally is not fully possibly, although there are tools to discourage illegal usage.

Put your image or video in flash format. Works great.

This is an old post, but for video you might want to consider using MPEG-DASH to obfuscate your files. Plus, it will provide a better streaming experience for your users without the need for a separate streaming server. More info in this post:
How to disable video/audio downloading in web pages?

I believe THEOplayer already provides this sort of solution as a paid service, but I'm not so sure about it.

Granted that any image the user can see will be able to be saved on the computer and there is nothing you can do about it. Now if you want to block access to other images that the user is not supposed to see, I am actually doing it that way:
Every link is to the "src" in your image tag is in fact a request
send to a controller on the server,
the server checks the access
rights of that specific user, and returns the image if the user is
supposed to have access to it,
all images are stored in a directory
that is not directly accessible from the browser.
Benefit:
The user will not have access to anything that you don't intent him/her to have access to
Drawback:
Those requests are slow.. especially is there are lots of images on the same page. I haven't found a good way to accelerate that in fact..

You can set the image to be background image and have a transparent foreground image.

I think the best way is:
STREAM THE VIDEO IN SEPARATED ENCRYPTED PARTS.
There are video hosting services such as vzaar that have this functionality.
As far as I know, that will make it really hard to download directly. At least for 95% of the people.
But of course, if the video plays on the screen people can just use a screen recorder and some simple software to record sound from the audio output (but he/she will have to play the ENTIRE thing to save it, totally inconvenient).

You can't stop image/video theft but you can make harder for normal users but you can't make it harder for the programmers like us (I mean thieves that know little web programming).
There are some tricks you can try:
1.) Using flash as YouTube and many others sites like http://www.funnenjoy.com does.
2.) Div overlaping or background pic setting (but users with little sense can easily save all resources by opening inspect element or other developer option).
3.) You can disable right click and specific keys like CTRL + S and others possibles with JavaScript but main drawback is that if user disable JavaScript our all tricks fail down.
4.) Save image in none online directories (if you have full access to web server) and read that files with server side languages like PHP every time when image / video is required and change image id time to time or create script that can automatically change ID after every access.
5.) Use .htaccess in apache to prevent linking of your images by others sites. you can use this site to automatically generate .htacess http://www.htaccesstools.com/hotlink-protection/

Insert a transparent gif 1px x 1px just inside the <body> tag:
<body><img src="route-to-images/blim.gif" class="blimover">
Then style it with this:
.blimover {
width: 100% !important;
height: 100% !important;
z-index: 1000 !important;
position: absolute !important;
top: 0 !important;
left: 0 !important;
}
This will remove any click functionality from a page, but it sure stops people stealing any content!
You can apply the same to a <div>, <section>, <article> etc, just name accordingly and prevent your copy and/or images being ripped.
Nothing stops a screengrab though ... ...

If you want only authorised users to get the content, both the client and the server need to use encryption.
For video and audio, a good solution is Azure Media Services, which has content protection and encryption. You embed the Azure media player in your browser and it streams the video from Azure.
For documents and email, you can look at Azure Rights Management, which uses a special client. It doesn't currently work in ordinary web browsers, unfortunately, except for one-off, single-use codes.
I'm not sure exactly how secure all this is, however. As others have pointed out, from a security point of view, once those downloaded bytes are in the "attacker's" RAM, they're as good as gone. No solution is 100% secure in this case (please correct me if I'm wrong). As with most security, the goal is to make it harder, so the 99% don't bother.

I think the best way is to prevent right clicking on your webpage, because that is the most convenient way a normal user try to download the content, and you can consider it as remark if u able to do this only as you are never gonna be able to stop a computer geek or hacker people from downloading it, because once the content is on the internet, it means it is in the public domain already...

Put the content on google drive and make it download protect. This way people can only see your documents, pictures but cannot download it.

DRM solutions are available today. It makes the video viewable but not downloadable.
What is DRM?
Digital Rights Management (DRM) solutions are software programs created to help people protect and control their valuable digital content, whether it's documents, videos, images, or audio files.
Check out this. Hope it's helpful.

Related

Can images from another website create cookies on my site?

I have a static website, it only contains html and css. No javascript, no php, no databases. On this site, I'm using images, which I get from image-hosting websites (like imgur).
I've noticed when I visit my website (on Google Chrome at least), if I click the information button next to the URL, it says there are cookies on this site. If I click on the cookies button, it says The following cookies were set when you viewed this page and has a list from cookies, including from those sites that I use for image-hosting.
If I delete them, they come back after a while, but not immediately. I'm trying to avoid cookies as the site is very simple. Are they considered part of my site? If so, is there anything I can do, except hosting the images myself?
I always though that if you link to an image directly (as in a link ending in .png for example) it would be the same as if you were hosting the image yourself, and there would be no javascript being run (to save cookies).
Are they considered part of my site?
That depends on your perspective.
The browser doesn't consider them to be part of your site. Cookies are stored on a per-domain basis, so a cookie received in response to a request for an image from http://example.com will belong to http://example.com and not to your site.
However, for the purpose of privacy laws (such as GDPR) then they are considered part of your site and, if they are used by the third party to track personally identifiable information, you are required to jump through the usual GDPR hoops.
If so, is there anything I can do, except hosting the images myself?
Not really.
I always though that if you link to an image directly (as in a link ending in .png for example) it would be the same as if you were hosting the image yourself, and there would be no javascript being run (to save cookies).
Cookies are generally set with HTTP response headers, not with JavaScript.
Whenever a browser requests a file from a server it automatically forwards any cookie data along with the request. Image Hosting services may use that for different purposes.
I always though that if you link to an image directly (as in a link ending in .png for example) it would be the same as if you were hosting the image yourself, and there would be no javascript being run (to save cookies).
So the question is, how to they set these cookies?
Let's say, you use a simple img tag to load an image from a hoster.
<img src="imageHoster.tld/123xyz.png">
The site imageHoster.tld can handle that request by redirecting all requests to e.g. requestHandler.php and that file can set the cookie before sending the image with a simple
<?
setcookie("cookieName", "whateverValue", time()+3600);
header('content-type: image/png');
...
?>
What happens there is actually the same as if you would set the image source like that:
<img src="imageHoster.tld/requestHandler.php?img=123xyz">
Are they considered part of my site?
Since these so called third party cookies are set when visiting your site one could consider them as part of your site. To be on the safe side I would at least mention the use of third party services in the data privacy statement.
If so, is there anything I can do, except hosting the images myself?
Third party cookies can be disabled in the clients browser. But you can't disable them for the visitors of your site. So no, to avoid third parties setting cookies on client browsers visiting your site you can only avoid using their services.

How to prevent viewing website code

I have a website that has a lot of data and that is sensitive to the website so I made a code that prevents right clicks but if you are using Safari it is easy to see the data I need to hide the info also so safari cant view it ether.
Client side, you cannot secure your code from view. Firebug will still show the code. You should have sensitive data on the Server.
You can't.
If the data is sufficiently sensitive that people shouldn't be able to view it, don't put it on a web site.
I m not sure if there is a completely safe solution.
if its images, use flash to load them dynamically.
yet people who knows swf-bin specs can decompile your swf files and find out the real image path.
if its data & text.
as much I can do is to
1: use pure js to render all views.
use XMLHttpRequest/ActiveXObject to load data and import these ajax js code # runtime.
compress your js/css code before deploy
here is one of my mockups
2: on the server side
check the request header to drop command line request.
exchange cookie/session key for each time.
BUT, this will make google-bots don't know how to inspect your site.
so DON'T do that on your landing page.

Download from URL (PATH) - iPhone

I got a little Question.
I'm working on an App, and for that I have to download an HTML File with the including CSS and Images.
And Yeah, there's an API for that (ASIHTTPRequest), but I wan't to publish my App to the App Store and I don't want to use 3rd party API's.
And Parsing the HTML code is a bit hard :(
And It would also work for me, if I could download the whole path of a URL.
For example:
I have this URL: http://example.org/smthg/.
At this path I have:
-index.html
-logo.png
-style.css
And I want to download all this files AUTOMATICALLY, and not every single file.
But I don't think, that you can find out which files are on the server, right? (without BruteForce).
I hope you know what I mean :)
You can use a UIWebView to download the content at the location and hold on to the WebView. You could also use NSURLConnection to download content at a URL if you want to save it unformatted and you have the URL's to the resources.
There's nothing wrong with using 3rd party frameworks, as long as they're good quality frameworks and you use them right. ; ) Apple just gives you the starting blocks to make an app, after all, and using open-source code can really speed up your project.
With that said, ASIHTTPRequest is a bit outdated and not well maintained. Instead, I'd recommend AFNetworking, which supports asynchronous downloads, background downloads, and blocks. See https://github.com/AFNetworking/AFNetworking .
Regarding your specific issue on downloading certain files, however, you might try creating a plist(s) on the server (if its yours that is, or else, bundled within the app perhaps) that would list all of the needed files and their download locations.
However, the issue you're liking going to quickly face- even if your app has all needed files downloaded, it still has to understand what to do with them. If its just HTML content, styles, etc, perhaps you can display it in a UIWebView ? However, be sure that your app is adding some useful functionality besides just being a web browser... (unless, of course, you're making an enhanced web browser... ;)
Good luck!

Flash/HTML Architecture: SEO Implications?

A client of mine has a full-Flash site and an HTML site (wordpress). Currently, the HTML site lives at http://www.domain.com, while the Flash site lives at http://www.domain.com/flash (swfobject detection at http://www.domain.com redirects flash users to the flash URL). The client isn't entirely pleased with this arrangement in terms of SEO, as links to their site sometimes point to http://www.domain.com and sometimes to http://www.domain.com/flash.
In a few weeks, the client will be rolling out a new version of their Flash site, which features deeplinking, among other things. Instead of living in its own folder off of the domain, the full-Flash site will be a "progressively enhanced" version of the HTML site, so if a user supports Flash, all HTML content will be replaced by Flash content.
Once the new site is launched, each page/URL in the Flash site will have a corresponding HTML page/URL; for example, the Flash content at http://www.domain.com/#/about/clients corresponds to the HTML content at http://www.domain.com/about/clients.
We're going to implement a 301 redirect so the old /flash path points to the domain itself, but we're not sure how to proceed in terms of redirects between the HTML and Flash versions of the site. One possibility would be to simply do client-side detection of capabilities and redirect the user to the appropriate version; under that scenario, a non-Flash-capable client that attempts to visit http://www.domain.com/#/about/clients would be JS-redirected to http://www.domain.com/about/clients, and a Flash-capable client visiting http://www.domain.com/about/clients would be JS-redirected to http://www.domain.com/#/about/clients.
Is this a reasonable approach? Are there any potential SEO red flags that we should be aware of before proceeding?
Thanks for your consideration!
The redirect from /#/about/clients to /about/clients sounds reasonable, but applying the reverse could cause problems - if your Flash detection doesn't work correctly (perhaps Flash is blocked etc.) then you may send the user into an infinite redirect loop.
Personally, I would recommend that non-hash links always load their content as expected, in a static manner. If the user then navigates, you may either end up with a URL like /about/clients#/ (if they went to the home page) (this shouldn't be an issue as crawlers will never end up visiting them this way) or you can have them redirect to / next time they navigate.
IMHO, I'd say that a pure JavaScript solution to the hash problem would be easier to manage as there are already many good examples of this.
Also consider using #! instead of # - this 'hash-bang' technique is being pushed by Google as a way of identifying to search engines that your hash is important and that its contents differ from what you would see without the hash part. Google can already point to specific parts of a page using # and if you follow the hash-bang technique on the client and server-side, it will be able to index your AJAX/Flash links just like regular links (see the implementation details and the requirements you need to fulfill).

Sourcecode in the url

normally you go on a website and by right click you can choose to see the source code. Or you just use firebug and select an element you want to analyse. Is it possible to write the source code in the URL so that it wouldn't be shown by right click + choosing or selecting an element?
I'm asking because I've already seen this phenomenon once by using an iphone simulator in safari.
Any ideas or hints what I'm exactly looking for? Your help would be great.
Edit: Based on wrong information. You can see the sourcecode by rightclicking. But the url still contains all information about the site. I'll get back to you as soon as I got more information to write them down clearly. Sorry for all the confusion.
Edit: This is the code in the url containing information about the site.
data:text/html;charset=utf-8;base64,PCFET0NUWVBFIGh0bWw%2BDQo8aHRtbCBtYW5pZmVzdD0naHR0cDovL25vdm93ZWIubWZ1c2UuY29tL3dlYmFwcC9TcG9ydGluZ2JldC9wb3J0YWwvc3BvcnRpbmdiZXRQb3J0YWwubWFuaWZlc3QnPg0KPGhlYWQ%2BPHRpdGxlPlNwb3J0aW5nYmV0PC90aXRsZT4NCiAgICA8bWV0YSBodHRwLWVxdWl2PSdjb250ZW50LXR5cGUnIGNvbnRlbnQ9J3RleHQvaHRtbDsgY2hhcnNldD11dGYtOCc%2BDQoJPG1ldGEgbmFtZT0ndmlld3BvcnQnIGNvbnRlbnQ9J21heGltdW0tc2NhbGU9MSwgd2lkdGg9ZGV2aWNlLXdpZHRoLCBoZWlnaHQ9ZGV2aWNlLWhlaWdodCwgdXNlci1zY2FsYWJsZT1ubywgbWluaW11bS1zY2FsZT0xLjAnPg0KICAgIDxtZXRhIG5hbWU9J2FwcGxlLW1vYmlsZS13ZWItYXBwLWNhcGFibGUnIGNvbnRlbnQ9J1lFUyc%2BDQogICAgPG1ldGEgbmFtZT0nYXBwbGUtbW9iaWxlLXdlYi1hcHAtc3RhdHVzLWJhci1zdHlsZScgY29udGVudD0nYmxhY2snPg0KICAgIDxzY3JpcHQgdHlwZT0ndGV4dC9qYXZhc2NyaXB0JyBsYW5ndWFnZT0namF2YXNjcmlwdCc%2BDQogIGlmIChkb2N1bWVudC5yZWZlcnJlciA9PSAnJykNCiAgew0KICAgd2luZG93LmxvY2F0aW9uPSdkYXRhOnRleHQvaHRtbDtjaGFyc2V0PXV0Zi04O2Jhc2U2NCxQR2gwYld3JTJCUEdobFlXUSUyQlBHMWxkR0VnYm1GdFpUMG5kbWxsZDNCdmNuUW5JR052Ym5SbGJuUTlKMjFoZUdsdGRXMHRjMk5oYkdVOU1Td2dkMmxrZEdnOVpHVjJhV05sTFhkcFpIUm9MQ0IxYzJWeUxYTmpZV3hoWW14bFBXNXZMQ0J0YVc1cGJYVnRMWE5qWVd4bFBURXVNQ2MlMkJQRzFsZEdFZ2JtRnRaVDBuWVhCd2JHVXRiVzlpYVd4bExYZGxZaTFoY0hBdFkyRndZV0pzWlNjZ1kyOXVkR1Z1ZEQwbldVVlRKejQ4YldWMFlTQnVZVzFsUFNkaGNIQnNaUzF0YjJKcGJHVXRkMlZpTFdGd2NDMXpkR0YwZFhNdFltRnlMWE4wZVd4bEp5QmpiMjUwWlc1MFBTZGliR0ZqYXljJTJCUEUxRlZFRWdhSFIwY0MxbGNYVnBkajBuY21WbWNtVnphQ2NnWTI5dWRHVnVkRDBuTVR0VlVrdzlhSFIwY0hNNkx5OTNaV0poY0hBdWJXWjFjMlV1WTI5dEwxTndiM0owYVc1blltVjBMMmx3YUc5dVpTOXBibVJsZUMxbGJsOUhRaTVvZEcxc1AybGtQVFUzTkRVME1qa3lNRUUwTURRMk1UVXdNVE01TUVaRFFUTTRNREJFTkRnNEpteHZZMkZzWlQxbGJsOUhRaVpoWm1acGJHbGhkR1ZKUkQwblBqd3ZhR1ZoWkQ0OGMzUjViR1UlMkJZbTlrZVh0aVlXTnJaM0p2ZFc1a0xXTnZiRzl5T2lNd01EQTdkR1Y0ZEMxaGJHbG5ianBqWlc1MFpYSTdZMjlzYjNJNkkwWkdSanRtYjI1MExXWmhiV2xzZVRwQmNtbGhiQ3dnU0dWc2RtVjBhV05oTENCellXNXpMWE5sY21sbU8yWnZiblF0YzJsNlpUb3lNSEI0TzMwOEwzTjBlV3hsUGp4aWIyUjVQanh3UG14dllXUnBibWN1TGk0OEwzQSUyQlBDOWliMlI1UGp3dmFIUnRiRDQ9Jw0KCSB9DQogICAgPC9zY3JpcHQ%2BDQogICAgPGxpbmsgcmVsPSdhcHBsZS10b3VjaC1pY29uLXByZWNvbXBvc2VkJyBocmVmPSdodHRwOi8vbm92b3dlYi5tZnVzZS5jb20vd2ViYXBwL1Nwb3J0aW5nYmV0L3BvcnRhbC9JbWFnZXMvV2ViQ2xpcEljb24tZW5fR0IucG5nJz4NCiAgICA8bGluayByZWw9J3N0eWxlc2hlZXQnIHR5cGU9J3RleHQvY3NzJyBocmVmPSdodHRwOi8vbm92b3dlYi5tZnVzZS5jb20vd2ViYXBwL1Nwb3J0aW5nYmV0L3BvcnRhbC9jc3MvbWFpbi1lbl9HQi5jc3MnPg0KICAgIDxsaW5rIHJlbD0nc3R5bGVzaGVldCcgdHlwZT0ndGV4dC9jc3MnIGhyZWY9J2h0dHA6Ly9ub3Zvd2ViLm1mdXNlLmNvbS93ZWJhcHAvU3BvcnRpbmdiZXQvcG9ydGFsL2Nzcy9UcmFuc2l0aW9ucy5jc3MnPg0KCTxzY3JpcHQgdHlwZT0ndGV4dC9qYXZhc2NyaXB0JyBzcmM9J2h0dHA6Ly9ub3Zvd2ViLm1mdXNlLmNvbS93ZWJhcHAvU3BvcnRpbmdiZXQvcG9ydGFsL1BhcnRzL3V0aWxpdGllcy5qcycgY2hhcnNldD0ndXRmLTgnPjwvc2NyaXB0Pg0KICAgIDxzY3JpcHQgdHlwZT0ndGV4dC9qYXZhc2NyaXB0JyBzcmM9J2h0dHA6Ly9ub3Zvd2ViLm1mdXNlLmNvbS93ZWJhcHAvU3BvcnRpbmdiZXQvcG9ydGFsL1BhcnRzL3NldHVwLWVuX0dCLmpzJyBjaGFyc2V0PSd1dGYtOCc%2BPC9zY3JpcHQ%2BDQogICAgPHNjcmlwdCB0eXBlPSd0ZXh0L2phdmFzY3JpcHQnIHNyYz0naHR0cDovL25vdm93ZWIubWZ1c2UuY29tL3dlYmFwcC9TcG9ydGluZ2JldC9wb3J0YWwvbWFpbi5qcycgY2hhcnNldD0ndXRmLTgnPjwvc2NyaXB0Pg0KICAgIDxzY3JpcHQgdHlwZT0ndGV4dC9qYXZhc2NyaXB0JyBzcmM9J2h0dHA6Ly9ub3Zvd2ViLm1mdXNlLmNvbS93ZWJhcHAvU3BvcnRpbmdiZXQvcG9ydGFsL1BhcnRzL1RleHQuanMnIGNoYXJzZXQ9J3V0Zi04Jz48L3NjcmlwdD4NCiAgICA8c2NyaXB0IHR5cGU9J3RleHQvamF2YXNjcmlwdCcgc3JjPSdodHRwOi8vbm92b3dlYi5tZnVzZS5jb20vd2ViYXBwL1Nwb3J0aW5nYmV0L3BvcnRhbC9QYXJ0cy9QdXNoQnV0dG9uLmpzJyBjaGFyc2V0PSd1dGYtOCc%2BPC9zY3JpcHQ%2BDQogICAgPHNjcmlwdCB0eXBlPSd0ZXh0L2phdmFzY3JpcHQnIHNyYz0naHR0cDovL25vdm93ZWIubWZ1c2UuY29tL3dlYmFwcC9TcG9ydGluZ2JldC9wb3J0YWwvUGFydHMvQnV0dG9uSGFuZGxlci5qcycgY2hhcnNldD0ndXRmLTgnPjwvc2NyaXB0Pg0KICAgIDxzY3JpcHQgdHlwZT0ndGV4dC9qYXZhc2NyaXB0JyBzcmM9J2h0dHA6Ly9ub3Zvd2ViLm1mdXNlLmNvbS93ZWJhcHAvU3BvcnRpbmdiZXQvcG9ydGFsL1BhcnRzL1RyYW5zaXRpb25zLmpzJyBjaGFyc2V0PSd1dGYtOCc%2BPC9zY3JpcHQ%2BDQogICAgPHNjcmlwdCB0eXBlPSd0ZXh0L2phdmFzY3JpcHQnIHNyYz0naHR0cDovL25vdm93ZWIubWZ1c2UuY29tL3dlYmFwcC9TcG9ydGluZ2JldC9wb3J0YWwvUGFydHMvU3RhY2tMYXlvdXQuanMnIGNoYXJzZXQ9J3V0Zi04Jz48L3NjcmlwdD4NCjwvaGVhZD4NCjxib2R5IG9uTG9hZD0nbG9hZCgpOyc%2BDQogICAgPGRpdiBpZD0nc3RhY2tMYXlvdXQnPjxkaXYgaWQ9J3NlbGVjdGlvbi1wYWdlJz4NCiAgICAgICAgICAgIDxkaXYgaWQ9J2xhbmRpbmdwYWdlJz4NCiAgICAgICAgICAgICAgICA8ZGl2IGlkPSdjZW50cmVUb3BCRyc%2BPC9kaXY%2BPGRpdiBpZD0nY2VudHJlQm90dG9tQkcnPjwvZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXYgaWQ9J2xvZ28nPjwvZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXYgaWQ9J2ljb24nPjwvZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXYgaWQ9J2Rpc3BhbHlib3gnPg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDEnPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDInPjwvZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9J3ZpZXcyJyBpZD0naXBob25lJz48L2Rpdj4NCiAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSd2aWV3MicgaWQ9J2Nhc2lubyc%2BPC9kaXY%2BDQogICAgICAgICAgICAgICAgPGRpdiBpZD0nZGlzcGFseWJveDMnPg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDUnPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDYnPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDcnPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDgnPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDknPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDEwJz48L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgPGRpdiBpZD0ndGV4dHAxMSc%2BPC9kaXY%2BDQogICAgICAgICAgICAgICAgICAgIDxkaXYgaWQ9J3RleHRwMTInPjwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGlkPSd0ZXh0cDEzJz48L2Rpdj4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICA8L2Rpdj48ZGl2IGlkPSdpbnN0YWxsLWFwcC1wYWdlJz4NCiAgICAgICAgICAgIDxkaXYgaWQ9J2luc3RhbGwnPg0KICAgICAgICAgICAgICAgIDxkaXYgaWQ9J2NlbnRyZVRvcEJHMSc%2BPC9kaXY%2BPGRpdiBpZD0nY2VudHJlQm90dG9tQkcxJz48L2Rpdj4NCiAgICAgICAgICAgICAgICA8ZGl2IGlkPSdkaXNwYWx5Ym94MSc%2BDQogICAgICAgICAgICAgICAgICAgIDxkaXYgaWQ9J3RleHRwMyc%2BPC9kaXY%2BDQogICAgICAgICAgICAgICAgICAgIDxkaXYgaWQ9J3RleHRwNCc%2BPC9kaXY%2BDQogICAgICAgICAgICAgICAgPC9kaXY%2BDQogICAgICAgICAgICAgICAgPGRpdiBpZD0naWNvbjEnPjwvZGl2Pg0KICAgICAgICAgICAgICAgIDxkaXYgaWQ9J2xvZ28xJz48L2Rpdj4NCiAgICAgICAgICAgICAgICA8ZGl2IGlkPSdidXR0b24yJz48L2Rpdj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICA8L2Rpdj48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4=
No, it's not possible to hide a website's source code. The reason for that is simply that the browser needs that code to display the website, so whenever you see a website, you'll always be able to see as much code as is needed to make the website look like that.
You can mangle the code a bit, but as you have said yourself, things like Firebug are able to display the current state of a website, so you'll also be able to see the correct code.
edit
Just a note: Just because Safari with an iPhone user agent isn't able to display the source code, it doesn't mean that the code is not there or somehow encrypted into the URL. If you can see the website, the code is there.
I guess it's a bug (or a feature?) that Safari isn't able to display it in iPhone mode (maybe because the iPhone itself isn't able to display the code either).
edit 2
Okay, it indeed set the URL to the following for me:
data:text/html;charset=utf-8;base64,PGh0bWw%2BPGhlYWQ%2BPG1ldGEgbmFtZT0ndmlld3BvcnQnIGNvbnRlbnQ9J21heGltdW0tc2NhbGU9MSwgd2lkdGg9ZGV2aWNlLXdpZHRoLCB1c2VyLXNjYWxhYmxlPW5vLCBtaW5pbXVtLXNjYWxlPTEuMCc%2BPG1ldGEgbmFtZT0nYXBwbGUtbW9iaWxlLXdlYi1hcHAtY2FwYWJsZScgY29udGVudD0nWUVTJz48bWV0YSBuYW1lPSdhcHBsZS1tb2JpbGUtd2ViLWFwcC1zdGF0dXMtYmFyLXN0eWxlJyBjb250ZW50PSdibGFjayc%2BPE1FVEEgaHR0cC1lcXVpdj0ncmVmcmVzaCcgY29udGVudD0nMTtVUkw9aHR0cHM6Ly93ZWJhcHAubWZ1c2UuY29tL1Nwb3J0aW5nYmV0L2lwaG9uZS9pbmRleC1lbl9HQi5odG1sP2lkPTU4NjIwNEE2MEE0MDQ2MTUwMTM5MEZDQTFBQTdGNDFBJmxvY2FsZT1lbl9HQiZhZmZpbGlhdGVJRD0nPjwvaGVhZD48c3R5bGU%2BYm9keXtiYWNrZ3JvdW5kLWNvbG9yOiMwMDA7dGV4dC1hbGlnbjpjZW50ZXI7Y29sb3I6I0ZGRjtmb250LWZhbWlseTpBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmO2ZvbnQtc2l6ZToyMHB4O308L3N0eWxlPjxib2R5PjxwPmxvYWRpbmcuLi48L3A%2BPC9ib2R5PjwvaHRtbD4=
This however just encodes to a loading & redirect page that itself redirects to a different webpage with a special session-like parameter. I guess they didn't want to create real server side sessions for this and just put the parameter into the redirect page and encoded the whole junk using the data: URI to not create a custom page for it. This however does neither help the browser (in terms of speed or anything else) nor does it hide the source code, as you can just decode it again to see the original source code.
What you're referring to is the data URI scheme, which allows base64 encoded data to be included locally (within a request), where normally http/etc URLs are used to initiate new requests.
The data URI scheme is a URI scheme
that provides a way to include data
in-line in web pages as if they were
external resources. It tends to be
simpler than other inclusion methods,
such as MIME with cid or mid URIs.
Read the Wikipedia page for more details: http://en.wikipedia.org/wiki/Data_URI_scheme
i don't know what you're trying to achive, but if you want to hide the source code because of "anybody can steal my code": that isn't possible. the sourcecode has to get to the browser in any way, so the browser can display it - and if the code is on the client-machine (in the browser) there will always be a possibility to grab it.
Even if you restrict right clicking, or viewing the source, it is impossible to hide it from everybody. Also, placing it in the URL would be bad, very bad (I can't even imagine it).
the html is needed for the browser to render the UI. You can't hide it.
You could compress and obfuscate the javascript though, to make it difficult to read and understand. But that's evil :)
Internet Explorer has a character limit of 2048 characters, so you would have to compress the content and pray it will fit in the url after it's been base64 encoded. Then you can use javascript to decode it. It will also be extremely difficult to update your pages or allow for bookmarking. It could also result in users exploiting the system.
Chances are nobody will want your sauce code anyway, and if they did, it wouldn't affect you one little bit. Facebook shows it's sauce, I don't see it's popularity dropping. So just stick with serving your pages the normal way.
1. The length of an URL is limited, so that you couldn't write a whole page into it even if it were possible.
2. Once a thing has been displayed at a client machine the code cannot be protected.
(well, using javascript right-click disabling could repell a few noobs, but it is still fairly easy to grab the code)