TheUberOverLord

One easy way if the device allows you to pull images using HTTP or HTTPS methods using a URL is to use methods like this. This working example accesses 14 cameras, at the same time and also allows you to access each of them individually, from any Internet browser capable device: http://107.170.59.150/foscam/FoscamUS.htm Note: The above works with any imaging devices that can provide images using a URL and HTTP or HTTPS access methods. Not just Foscam IP Camera models. Most Smart Phone plans have monthly limits on how many bytes per month can be used before additional charges are added. So methods like this can be helpful as just another tool in your toolbox of tools. To use as and when needed. This allows you to control FPS ("Frames Per Second") rates dynamically to those devices in real-time without actually changing or impacting the cameras actual FPS rates themselves and to be able to set the default image sizes displayed for those cameras on a device without actually changing their image sizes while also supporting zoom to increase those image sizes dynamically and in real-time. To reduce bandwidth usage by specific devices an make the cameras images more easily viewable on those devices and is compatible with any Internet browser capable devices without the need to download or install and/or pay for additional 3rd party software on those devices. To be able to access those same cameras, from those same devices. Using free methods instead. You can try the above working example from any Internet browser capable device. No solution is perfect for all cases and you may decide to use many different approaches for each device and situation. IMHO it's always best to have more than one working solution per device. Especially more so when you don't have access to your normal devices and need to access your cameras from other devices available at the moment or some 3rd party app suddenly has issues at the moment. It's always good and prudent, to have backup plans or secondary access solutions. Don

1. Please verify that your IP Camera has the most current firmware installed in it. It should be noted that while you may think since your IP Camera is working ok that it's OK to not upgrade to the most current firmware release for your IP Camera. Sadly. Nothing could be farther from the truth. Many IP Camera firmware releases include security vulnerability FIXES that have been fixed. So if you don't install the most current firmware releases for your IP Cameras you expose your IP Cameras to those that look and prey on IP Cameras still having those security vulnerabilities which have not been fixed. 2. If you access your IP Cameras from time to time over insecure Internet connections or display your IP Cameras in web pages you may wish to peek at what you could be exposing about your IP Camera, while doing do here: http://foscam.us/forum/showing-secure-methods-using-php-to-display-your-ip-cameras-t8721.html 3. If your IP camera has the ability to be accessed using HTTPS secure methods vs. HTTP unsecure methods. You may wish to think about NOT port forwarding your HTTP port for your IP Camera and instead only port forwarding your HTTPS port for your IP Camera. While technically you could still potentially be exposed to a man-in-the-middle attack over a unsecure Internet connection it's still much better to communicate with your IP Camera remotely using HTTPS access methods vs. HTTP access methods when possible. 4. Sadly. Many IP Camera owners never take the time to check, see and learn what information can be or is exposed, when accessing their IP Cameras remotely. While this may at first seem trivial and you may think if you ever notice any abuse of your IP Camera, by others. That you will simply at that time, change the password for your IP Camera and all will be back to normal. The bitter truth is. If you as an example exposed a Admin User Level Id and Password for that Admin User Level Id for your IP Cameras over a unsecure Internet connection while accessing your IP Camera remotely. It's possible that any Email and/or FTP User credentials stored in your IP Cameras configuration data can be accessed and exposed by others using that Admin Logon to your IP Camera. Potentially causing you to lose control of those accounts. Not simply your IP Camera. Issues like this apply to any device you may access remotely from unsecure Internet connections that may contain sensitive data in that devices configuration data. So this is not limited to IP Cameras. Don

Depending on what you are trying to do? This will work with any IP Camera brands and models or imaging devices, that support pulling images from the IP Camera or imaging device, using HTTP or HTTPS URL access methods from any Internet browser capable device without the need to first download/install anything. It can be customized as needed to add additional IP Camera controls and/or IP Camera configuration control settings and there are working live demos showing totally secure and unsecure examples. Meaning unsecure ("Accessing the IP Camera directly and exposing the IP Camera or imaging devices IP Address/DDNS, Port and potentially the IP Cameras User Credentials or totally secure ("Using a server as a front end proxy. Not exposing any information of any kind about the location or anything else about the IP Camera or imaging device. Making the IP Camera or imaging device totally Anonymous"). Your choice. There are a total of 19 live demo cameras here. Where you can see both the unsecure and secure versions as working examples in real-time: http://foscam.us/forum/showing-secure-methods-using-php-to-display-your-ip-cameras-t8721.html As you can see by the above working examples. You can customize which if any IP Camera controls you wish to allow and also easily support using a User Id and Password for access to the Interface that has nothing to do with the IP Cameras user credentials. What's important to note is that this Interface supports both HTTP and HTTPS access methods. Even for IP Cameras that do not natively support HTTPS access methods themselves. Because the Interface supports any Internet browser capable device, with or without using a server as a front-end proxy. It has no Operating System, Browser based limitations or dependencies on additional software that must be present or installed to use it. This becomes important especially more so when you wish to concurrently monitor different IP Camera brands and/or models at the same time from any Internet browser capable device and also be able to quickly access them individually as needed. As the Examples demonstrate. Don

IMHO, I think AC Timers should be used and virtually are a required accessory for IP Cameras that are in places that you won't be able to get to for hours/days/weeks. I say this because you can get AC Timers relatively cheap as low as $4.00 U.S. from Walmart and other places and they at least allow you to always know that your IP Camera will be forced to reboot at x intervals, when/if they ever get hung up and become inaccessible remotely. Of course the downside is that while the IP Camera is rebooting ("Powering down/up") it can't capture anything during those timer cycles you set. Curious what others think. After seeing this subject posted about here in the Forum many times. I wonder if others use or have thought about using AC Timers or currently use AC Timers to force reset their IP Cameras at locations they can't get to on a moments notice. When/if their IP Cameras become inaccessible remotely. For those camera owners that do use AC Timers with their IP Cameras. How often do you power cycle your IP Cameras? Don

Added Totally Secure Foscam H.264 Based IP Camera Display and Control Support. Even when using HTTP not just HTTPS. Prior to this release. Only Totally Secure Display was supported using HTTP or HTTPS not IP Camera Controls. All Foscam H.264 based IP Camera Models can be configured for the size display of your choice. For demonstration purposes. A width of 640 pixels is being used while keeping the aspect ratio for height. But you can configure any default size and use the Interfaces infinite zoom as needed. Here is an example of a FI9826W using the actual default Snapshot resolution of 1280x720 instead of 640. The FI9826W is capable of default 1280x960 resolution but this one is at 1280x720: http://107.170.59.150/foscam/SecureImageDisplayControl.htm You can also access the camera using HTTPS even if the camera is not using HTTPS for remote access. Access can be combined with your own unique login using the User Id and Password of your choice not connected with any User Id and/or Password for the camera itself. The optional logon can be used using HTTP or HTTPS. Try it here. Note: The HTTPS example is using a self-signed SSL certificate so you will see a warning when using the HTTPS link. User Id: admin Password: admin HTTP: http://107.170.59.150/foscam/SecureImageDisplayControlLogin.php HTTPS: https://107.170.59.150/foscam/SecureImageDisplayControlLogin.php You can directly access the camera without the Logon using HTTPS as well: https://107.170.59.150/foscam/SecureImageDisplayControl.htm Foscam H.264 based IP Camera Models FI9805W, FI9821W V1, FI9821W V2, FI9826W, FI9828W and FI9831W support using the Interfaces Infinite zoom feature. Which is configurable by your choice of zoom percentage per click or infinite zoom can be disabled. Foscam H.264 based IP Camera Models FI9821W V1, FI9821W V2, FI9826W, FI9828W and FI9831W now also support as many as 10 Presets and Vertical and Horizontal Cruises. Foscam H.264 based IP Cameras Models FI9826W and FI9828W now support using both the cameras actual zoom lens as well as the Interfaces Infinite zoom ability. They can also be used together. All these options are configurable and can be enabled/disabled individually. Simply click on any of the Foscam H.264 based IP Camera Models below to try a live demonstration for any of the IP Camera models: There is a Two Minute Limit For Demonstration Purposes Don

You can set the Snapshot refresh delay option to be any number of Milliseconds ("1,000 Milliseconds = 1 Second") Don

You maybe better off using something like FFmpeg for this and running it on a server and using its server features so that it can be doing the transcoding you need to meet whatever the Quicktime live streaming limitation are. It also then would only require one video stream connection to your camera. Feeding all video stream requests from it. It should be noted that many IP Cameras have a finite limit ("Which is very small 4 - 12 Maximum") of concurrent video streams directly from the IP Camera. So, even if you were to get this working? The number of concurrent web page visitors that could be using it at the same time. Most likely, would be far less than 20. Every direct video stream connection takes a ("HUGE") toll on any IP Camera CPU busy and memory resources. Because you are asking that IP Camera to concurrently feed full motion video to x number of requestors, at the same time. So, even if you don't reach the maximum limit before the IP Camera refuses another video stream connection. The IP Camera could get bogged down with the video streams it has open already. Making them far from 5-30 FPS per connection anyway. So what's the point then of using direct video stream connection to the IP Camera? Whereas, the Snapshot option, supports many more concurrent connections in virtually all cases. Depending on what your needs are. You may need to as stated above, create your own video feed on a server or use a video streaming hosting service. Which generally is far from cheap and based on concurrent connections and bandwidth. Sadly. Many people think about these issues ("Afterwards") wasting lots of effort before doing so. IMHO. If you want to save yourself hours, days and possibly weeks of wasted time. It would be very much worth it to as an example. To do this test first. Start as many copies of the Quicktime Media Player running and connected to your IP Camera video stream and see what the maximum number is before the IP Camera refuses to create another concurrent video stream connection. Even if you need more than one system to do this test, due to resource issues. This is a good test. Then once you find that finite direct video stream concurrent connection limit that your IP Camera can support. As well as what the average FPS rate to all the video streams is when there are x concurrent video streams being broadcast directly from the IP Camera. You can decide if there is any point on spending more time to use that method vs. wasting many man hours until you learn that hard truth. Don

The issue with the media Player is how many Internet browser capable devices have or can install the Quicktime Media Player? Just saying. I don't know why your focus is only on the Quicktime Media Player. But for sure that places a severe limitation of who can see what when they access this web page. As an analogy. It would be about as equal as deciding your career path is to be a foot doctor, go to medical school, but you only see patients that are between the ages of 40-45 and only for big toe problems on left feet Don

You are very welcome. Many Media players can be embedded in web pages to play "Files". Your first example is in fact playing a .mov file. Your second example is attempting to display a IP Cameras live video stream, in real-time. Not the same as playing a file and this is why it's failing. Instead of limiting yourself to one Media Player like Quicktime to embed IP Camera output in a web page. Why not use Snapshots instead from your IP Camera or from any imaging device which can serve Snapshots via HTTP or HTTPS? The are two major benefits of doing this: 1. All Internet browser capable devices that visit this web page will be able to instantly see your IP Camera with no delay or additional download/install of software to do so. 2. Much less resources and bandwidth are required. Please note. Generally unless your IP Cameras "frame of view" is very busy, 24/7/365? Then watching "Paint Dry" at 30 FPS is a lot more resource and bandwidth intensive then using controlled interval refreshed Snapshots in real-time. Here are methods to embed any URL for Snapshots from any IP Camera and/or Imaging device that allows pulling Snapshots via HTTP and/or HTTPS at the delay interval of your choice. Using 1 line of HTML in a webpage: http://foscam.us/forum/a-how-to-embed-any-foscam-ip-camera-in-webpage-using-1-line-t9113.html The above also has a live working real-time example. The method can be used as stated above for any IP Camera that supports pulling Snapshots via HTTP and/or HTTPS. Depending on your needs? You can/could also add the IP Camera controls of your choice. To allow IP Camera controls to be used by any web site visitors. Again instantly, by any Internet browser capable device that visits your webpage. Live working example: http://107.170.59.150/foscam/SecureImageDisplayFI9826WUS.htm You could also then be able to display as many IP Cameras as you need on the same webpage. Here is an example of 11 IP Cameras live in real-time, at the same time on the same web page. Try and display 11 IP Cameras on a Internet browser capable Phone or Tablet, at the same time, using Media Players, without a "Fire Extinguisher". Not any issue when using these methods. The images are small for demonstration purposes. But could be any sizes: http://107.170.59.150/foscam/FoscamUS.htm Note: The above two example have a two minute time limit and are totally secure not exposing ANY IP Camera information, such as DDNS, IP Address, IP Camera Port or IP Camera User credentials. They also work with any Internet browser capable device. Instantly, without any additional download/install of any software including Media Players. As do all the examples shown here. At least this way. Anyone who visits your web page can see your IP Camera(s), live and in real-time, while using any Internet browser capable device. From Computers to Tablets and Phones to TVs. Instantly and will never need to download/install anything to do so! Don

Still very confused on what you wish to do and why you can't use HTML/JavaScript/Code to do this. Outside of the cameras actual firmware. Here are two cameras with optical zoom lenses. If you click on the images below. You can see that the Interfaces presentation is at a 640 pixel width for each camera. Which is smaller then the actual default size. While keeping the aspect ratio of height. The examples allow using the cameras internal optical zoom lens, as well as the Interfaces internal infinite zoom option. Which is not using the cameras optical lens. You can use the Interfaces zoom features individually or combined zoom options can be used: The actual default image sizes for these cameras is 1280x720. The Interface is simply displaying them smaller in the above examples. Here is the same Interface using the actual default snapshot image size for the first camera shown above: http://107.170.59.150/foscam/SecureImageDisplayControl.htm While these examples are using refreshed snapshots. The same logic can be used and applied for video as well. It's also possible to zoom into the area clicked vs. simply zooming the entire image as is. However that logic is not included in these examples. So, why can't you implement something on the client side ("Outside of the cameras firmware") that does the same? Even if it requires you to use buttons on the joystick to pull it off. Assuming there are buttons on the joystick? Don

Yes. For close to a year now, as stated in my prior post here. All Foscam firmware updates for all Foscam IP Camera models, force the camera owner to change the default password. When the default User credentials are still being used. But since no firmware updates were applied to this camera, since it was purchased. That process never forced a change of the default password. Don

Two things. 1. The family in other articles, admitted that they did not realize that they needed to change the "Default" password to the camera. 2. The family also admitted in other articles, that they did not realize that new firmware versions had been available for their camera for some time. One of those articles: http://www.philly.com/philly/blogs/lifestyle/20140504_PopSugar_Until_We_Fix_Our_Connected_Homes__Hackers_Will_Keep_Screaming_at_Babies.html Notes: Older firmware versions, did not prompt the IP Camera owner to change the default password. All firmware versions now do that and have done that, for almost a year now. No new firmware versions were required to be released, because this specific case was not caused by a firmware vulnerability. As I am sure you must know as well. Any device which has Internet access, including IP Cameras, needs to be kept up to date with firmware/software changes when vulnerabilities are found. Virtually all IP Cameras have had some kind of vulnerabilities found at times. More here, showing some of them: http://www.openipcam.com/forum/index.php/topic,534.0.html So this "Myth" that Foscam IP Cameras are somehow more exposed to potential vulnerabilities then other IP Camera brands and models or that as required, new firmware versions are not being released by Foscam, when any vulnerability is found. Based on the facts, is a false one. Point being. That even Operating Systems, Browsers, Applications and Devices of all kinds that have Internet access will/do require that they be maintained with firmware/software fixes as needed. It's also important to note that Foscam.us does now send emails to new IP Cameras owners informing them that new firmware is available for their camera as well. Just in case a IP Camera owner does not occasionally check the firmware download page to see if new firmware is available for their IP Camera. Which is located here: http://www.foscam.com/down3.aspx As an example. One can't always blame Microsoft, Apple, and Linux Operating System suppliers for owners using their Operating Systems not being diligent about maintaining the devices that use them. Currently. To date. There is no single device worldwide, which is exposed to the Internet, that can be or should be considered a "Set It Up And Forget It" device. Technology is not there yet. Don

Sadly, there really is nothing out there for video streaming that supports all Internet browser capable devices. Also, even your solution has a monthly cost: http://ipcamlive.com/pricing Whereas things like this can be done for free and in many different ways as well and in fact are compatible with any Internet browser capable devices from Computers to Tablets and Phones to TVs. Also without any need to ever install anything first as well: http://foscam.us/forum/showing-secure-methods-using-php-to-display-your-ip-cameras-t8721.html Don

Sadly, there really is nothing out there for video streaming that supports all Internet browser capable devices. Also, even your solution has a monthly cost: http://ipcamlive.com/pricing Whereas things like this can be done for free and in many different ways as well and in fact are compatible with any Internet browser capable devices from Computers to Tablets and Phones to TVs. Also without any need to ever install anything first as well: http://foscam.us/forum/showing-secure-methods-using-php-to-display-your-ip-cameras-t8721.html Don

If you would like to hide the camera DDNS/IP Address and User Credentials when displaying images for your camera in web pages. Please see this: http://foscam.us/forum/showing-secure-methods-using-php-to-display-your-ip-cameras-t8721.html The above will work with any IP Camera or Imaging device that allows Snapshots/Images to be pulled using HTTP or HTTPS. IMHO. It's never a good idea to expose your IP Cameras information unless you are willing and able to deal with any abuse that can take place when doing so. Don

Here are live demos using Foscam demo cameras. So you can compare models if needed. Click on any of the Nine Foscam U.S. IP Demo Camera images below to view a specific IP Camera in Real-Time. If a demo IP Camera is offline you will not be able to view it individually. Live Demonstration Using All The Above Foscam U.S. Demo IP Cameras Using Automatic Refreshed Images At The Same Time. Note: Images are small for demonstration purposes: http://107.170.59.150/foscam/FoscamUS.htm Don

Once again, drocer has taken things "Out Of Context" as has been done in EVERY post here. IMHO. The original first post here in this Topic has always included ("Text") which of course when drocer has posted here, is never included with drocer's selected "Snippets" of the original first post content of this Topic, stating the following: 1. It's suggested to use a Visitor User Level Id for the IP Camera(s) when using the method. 2. To NEVER <- Which is and has always been In Capital letters "use an Admin User Level Id with the method" when it's being used insecurely. Not doubting usefulness, just the presentation that certain terrible security practices can be okay. There's no way anyone was suggesting using admin... It's common ("Nomenclature") even by manufactures ("See example below") who publish SDK manuals for their IP Cameras to use as an ("Example") the User Id of admin as a reference: From Foscam H.264 Based IP Camera CGI SDK Manufacturers Manual From: http://foscam.us/forum/cgi-sdk-for-hd-camera-t6045.html#p28979 Note: Yet the IP Cameras User Id privilege level required to execute the above is a visitor level, not an admin level. This is the EXACT command I reference here. Yet when I do it the same way as the manufacturer does above. drocer seems to require a change of underwear. drocer's initial post in this thread/topic ("In its entirety") was: I did not understand it when it was posted nor do I understand it today. Trying to pin down drocer's concerns in this thread has been for me at least like playing "Whac-A-Mole". drocer's posts here have swung wildly from one thing to another and the one posted below here shows that drocer feels/thinks that one should never use CGI commands for a IP camera as in ever in a public HTML file. Which also has nothing to do with the fact that this method can also be used with HTTPS methods if the IP Camera supports HTTPS access and privately as well and used and hosted from any Internet browser capable device without the need for the HTML to be hosted on any website period. Which shows and continues to show me that dorcer has not been able to grasp, all the ways this method can be used. That said. In case drocer's idiots/morons ("As he calls them") that drocer has been so protective of ("In his posts in this thread/topic") really exist and ("Stay") after drocer has left. I replaced "admin" where it was referenced by drocer's ("Snippet") of the original post content and replaced it with "UserId". I also made the word "NEVER" bold and underlined as well. Hopefully now. drocer's idiots/morons ("As he calls them") will no longer be able to hurt themselves or others when using this method if they decide to stay after drocer has left. As the original first post of this topic also has stated, since its creation. This method can be combined with secure methods as well. The original post, since its creation, has always had a link to those secure methods as well. Don

Thanks. I agree. I think it has even been shown here that IP Camera manufactures think the same and don't share the same level of paranoia that drocer has expressed and shown here. I think, when possible however people should think about using the secure method. Especially more so if you don't want people to have access to your video streams. Which they still could get to even when using a Visitor User Level Id for the method when it's being used insecurely. As well as if the camera is going to contain in the configuration Email and/or FTP User Id and Password information that could be exploited if the firmware updates were not being maintained for the IP Camera in question. I personally trust that as you say any camera owner who has a website and is going to use this method insecurely in a public HTML page. Hands-Down, knows the risk as they are typing their IP Cameras DDNS/IP Address, Port and User credentials. To suggest otherwise, is nothing but pure conjecture. IMHO. For private use. By those that don't have a website or don't wish to keep a copy of this method on their websites. Some may wish to simply store the HTML page on any Internet browser capable device they may have or store a copy of it as an Email attachment that can be accessed from anywhere and used from any Internet browser capable device at anytime. This also justifies the use of using this method insecurely on secure internet connections for private use. Since the same data would be exposed if you were to access a video stream or use the normal IP Camera Interface from a browser. It can also come in handy in an emergency when you at the moment don't have access to your normal devices yet someone you trust has Internet access on a device that has no app for your camera. Then you can at least access your Email use the stored copy of this method from that device to check on if your camera is operational even from their device. It should be noted that this same method can in fact be used using HTTPS from a website. If your camera also supports HTTPS. With NO modifications or changes. So, if you have a website and a SSL certificate you can use the insecure method securely on a secure Internet connection. I would worry about doing the same using a semi-private or public Internet connection because of potential man-in-the-middle exploits. All the examples used here are SMALL for demonstration purposes. They can be any size. Here is an example of HTTPS access using the secure method combined with this method. Please note the web server hosting this example is using a self-signed SSL certificate so you will get a warning. The camera being used in this example is a MJPEG based IP Camera which does not natively support HTTPS. But because the secure method is also being used as a proxy to the camera. HTTPS access can still take place: https://107.170.59.150/V31/EmbedIPCameraInWebPageOneLine.htm Note: You can review the HTML source for the above if needed. Even if a man-in-the-middle attack were to take place using the above link No exposure of any IP Camera data could ever take place. Since the secure method is acting as a proxy to the IP Camera in this example. The same concepts can be used insecurely or securely using the method shown here in this thread/topic as this example shows using any combination of IP Camera Brands and Models and Types. The below shows both MJPEG and H.264 based IP Camera models at the same time using this method combined with the secure method: https://107.170.59.150/foscam/FoscamUS.htm Four of the Nine IP Cameras shown above don't support HTTPS access methods natively but because the secure method is being combined with this method those cameras can in fact be accessible via HTTPS with the secure method acting as a HTTPS/HTTP bridge proxy to those IP Cameras which normally would not be accessible via HTTPS. Note: Again, please feel free to review the HTML source code for the above as needed. Don

This same type of example is shown on most IP camera manufacturer's sites, without any warnings whatsoever, at least he mentions the vulnerabilities of doing it that way! Wait until IPV6 gets traction, and all of those devices are exposed to the internet without even NAT as a basic safety net, that's going to be fun... Internet of Things botnet, here we come! Thanks. Honestly. I can't locate one true statement drocer has made in this entire thread. No joke. drocer won't and does not get that. Just the statement alone, that I should be "Banned" when drocer reported me. Even when I had included a link to secure methods ("In the same Font and Font size as ALL the other content in the same post") while I also stated in the same post that the example method shown was not secure and also stated that the working example shown in the post, was using those secure methods. Shows that. Much like drocer's misleading and false statement of my warning being a tiny one. drocer also makes another false statement and claim that the post was asking camera owners to "broadcast ROOT to the world" when the original post contents also suggests using a IP Cameras Visitor User Level Id. drocer also seems to not understand that ROOT is a Linux term and that generally there is not ROOT access from CGI commands to IP Cameras. While the serial interfaces, FTP and Telnet interfaces to IP Cameras in many cases can and do support ROOT Access. CGI ROOT access is generally not supported. It would seem that drocer seems to think that a Admin Level ("Visitor Level was suggested in the post") IP Camera User Id for IP Camera logon purposes = Root. Which it does not. drocer then continues on to make more false statements and claims "IP cameras are borderline linux boxes" When there is nothing boarderline about it. IP Cameras are Linux boxes: http://www.openipcam.com/forum/index.php/topic,473.0.html http://foscam.us/forum/fi9821w-constantly-rebooting-t4912-20.html#p30784 I know this because I help other Foscam IP Camera owners recover any and all of their Foscam IP Camera models, as needed, using the serial interfaces to their Foscam IP Camera model. Using ROOT Linux access methods. I also have done the same with other camera models for many years. drocer also needs to learn that anything connected to the Internet is an exploit waiting to happen. NOT just IP Cameras. There are ways and methods to keep your ears close to the ground to avoid most if not all of them. Which I also have used and share with others: http://www.openipcam.com/forum/index.php/topic,534.0.html According to drocer. The manufacturers of IP Cameras also are as drocer says "absolutely irresponsible to even show that at all" or that they must have found methods not yet known to mankind to keep idiots/morons ("Who drocer has a personal quest on protecting access to this information, from those KINDS of people") from reading the information contained in their publicly posted links. Hopefully in the near future, drocer will start some studying on how even the IP Camera manufacturers as you say, without any warnings whatsoever, show the use of these same methods. Some examples of many ("Several hundred actually"): http://foscam.us/forum/cgi-sdk-for-hd-camera-t6045.html#p28979 http://foscam.us/forum/cgi-api-sdk-for-mjpeg-h-264-camera-t2986.html#p13630 http://developer.samsungtechwin.com/sdk/sdk.asp http://www.hikvision.com/en/us/download_more.asp?id=957 Hopefully, at the same time, drocer will try to lean how the normal communication flows from generally all these IP Cameras when they are using a HTTP interface to a Browser. As I suggested in a prior post here. Most likely. That's wishful thinking. Sigh! I guess in the meantime IP Camera Manufacturers, IP Camera owners, Forum members and Forum visitors will all need to accept and live with and continue to remain in drocer's idiots/morons category and classification groups At the very least we can all be thankful that IP Camera manufactures seem to not have the same "Paranioa" that drocer has about the wrong ("Types of") people being exposed to actually seeing these same methods, without the ("Extra") drocer warnings requirements and causing harm to themselves and others while doing so. Don

He's showing ways to embed images into webpages, not exposing vulnerabilities. He's also taken the time to explain ways to increase security of those video feeds by obfuscating the IP and login information. He isn't explaining inurl: or other vulnerabilities, quite the opposite. However, a thorough dissection of vulnerabilities is usually the only way they get fixed, so that's not always a bad thing, security through obscurity is always a bad idea. +1 Hardwire @TheUberOverLord plz keep posting Thanks so much. Don

Since I can't FIX your attitude and/or altitude issue(s). I can only suggest that you read the "About Me" link in my signature and also suggest that you re-read my initial post here where it shows both unsecure and secure methods ("Using the same Font and Font size"). How camera owners choose to implement the method is their business not yours or mine. They have access to both methods and can do as they please. Point being, that they now have the methods. They may not care about using a camera insecurely and I have no need or desire to try and force them to do anything they don't wish to do. A fair warning was given in the post and the working example IS using the secure method and was stated to be doing so. A link was also provided to help implement the use of secure methods as well. If you wish to refer to those things clearly stated in the original post as a "tiny warning" that's also your choice. But, it's not a true and accurate assessment or statement of what content was and is included in the original post. I trust that people here can read and that the vast and overwhelming majority of readers here are not as you say "idiots/morons" and since the Font used in the entire post is the same Font and size. Nothing in the original post is smaller than anything else. Secondly. It would appear, based on your clear and accusatory statements made here. That your basic current comprehension/understanding of how the communications normally flow and takes place with the vast majority of IP Cameras which use a Browser to communicate with the IP Camera owner and that IP camera when using HTTP as the transport protocol and video stream protocols is flawed. Generally for most IP Camera brands and models. Even if the IP Camera in question is using some form of basic authorization when the IP Camera owners Browser is accessing the IP Camera. The same information ("Exposure of data") which you seem to be so very concerned about here. Is in fact ("Always") taking place ("Again with the vast majority of IP Cameras") with the normal and standard IP Camera/Browser communications that takes place and can just as easily be decrypted/decoded if need be. When the Browser and the IP Camera in question are using HTTP. So. It does not require that a IP Camera owner create special ("non-secure") requests to the IP Camera, like as one example of asking the IP Camera for a snapshot to create this data exposure or to expose this same data. This data exposure that you seem so concerned about, is generally ("Always") there when communicating with most IP Camera brands and models using a Browser and HTTP. This is well known fact and not fiction and can be easily verified using free tools such as Fiddler, Wireshark and many other tools. That allow packet level inspection of the communications protocol layers from the IP Camera and a Browser when using HTTP as the transport mechanism between the IP Camera and the Browser in question. This is why many newer IP Camera models have a HTTPS option. Which still does nothing to remove the potential of a man-in-the-middle exploit when using a public or semi-private Internet connection. Whereas, my secure methods use a Web Server as a Proxy between the IP Camera and any Browser to protect the IP Camera owner from this data exposure, these flaws and/or potential exploits. Even when the IP Camera owner uses a public or semi-private Internet connection. Those methods are totally secure as to being able to protect others from gaining access to any DDNS/IP Address, Port or User Credentials for a IP Camera when a Browser is using those methods with any IP Camera. Had you truly understood this to be fact and not fiction. Again as being generally the usual case for normal communications for most IP Cameras and a Browser using HTTP. Then your focus would not be or have been so narrowly focused on the use of this method also having the ability to also be used in a non-secure way. Since normal communications for most IP Cameras using HTTP is exposing the same data ("Even if someone needed to use a online tool to decrypt any basic authorization which is/was being used to get the IP Camera User and Password being used") and information. IMHO. If you take the time to educate yourself on how the normal communications flow takes place with most of these IP Cameras and a Browser when they are used by a IP Camera owner using HTTP. You would soon learn quickly, that generally this data exposure, which seems to be so "shocking" to you. Has been for many years and is today, constantly present and taking place with the vast majority of IP Camera brands and models which use HTTP as their standard camera interfaces. During typical and normal communications with the IP Camera when using a Browser and HTTP and video streaming protocols. Who knows? If you take the time to do the above. You might ask fewer people publicly to kill themselves, not have as much a need to report those you've asked publicly to kill themselves as often, worry less about idiots/morons and see tiny warnings as the sizes they really are Sounds like a win-win to me. You gain more knowledge, Moderators need less medication and your eyesight gets better. All in the same period of time! Don

He's showing ways to embed images into webpages, not exposing vulnerabilities. He's also taken the time to explain ways to increase security of those video feeds by obfuscating the IP and login information. He isn't explaining inurl: or other vulnerabilities, quite the opposite. However, a thorough dissection of vulnerabilities is usually the only way they get fixed, so that's not always a bad thing, security through obscurity is always a bad idea. Thanks. Yes. Actually. At the bottom of the post there is a link to totally secure methods that can be used as well with this method. Not simply obscured and/or obfuscating methods, but totally secure methods. In fact the working example presented here is also using those totally secure methods. You can use any tool you wish from things like Fiddler to Wireshark and others and you can see that the working example has nothing that can be found when/while using it as to where the DDNS/IP Address location or Port and or what User credentials were used for the working example to get the images from the originating IP Camera used in the working example. Sadly. It's obvious that "drocer" did not understand and/or comprehend the example or its abilities to be used both securely and not securely using 1 line of HTML code per IP Camera, imaging device or image vs. many or multiple lines of code, which is normally the case. Don

Reported for what? Showing an easy method to refresh IP Camera images and other images easily in the "IP/Megapixel Cameras and Software Solutions" forum area. Nice to meet you as well. Hope you have a better day, week, month, year and life. Don

1. Links are there and included when/if you view the demonstrations. For those that are interested enough to get more details. 2. Note: You brought this subject up. Not me. You were banned for 3 days in the Forum you reference because of the inappropriate name calling which you refused to stop doing. Even after several personal messages were sent to you, asking you to stop doing that. Moderators could tell that you never took to time to read any of those personal warning messages. Because all of those messages sent to you were never read. For over a week. Yet you continued posting new posts in the Forum, using the same inappropriate name calling, during that same time. In fact you were only banned from the Forum you referenced, for three days when you decided that the solution to the situation should be that Moderators should "Continue to do what they do and simply should IGNORE your posts and comments": http://foscam.us/forum/fi9821w-issue-list-t3967-340.html#p23093 Please note: The post referenced in your signature link in the Forum you referenced. Was also deleted due to the same inappropriate name calling. So if you intend to post in the Forum you referenced, in the future. Please follow the Forum you referenced guidelines. You were and are not currently permanently banned from the Forum you referenced. You are more then welcome to post in the Forum you referenced, if you can abide by that Forums guidelines. Which do not include Moderators ignoring the language used in your posts there or the Topics you advertise your software in that have no relevance to your software. Additionally, please refrain from, while trying to market your software in the Forum you referenced, as you had been from the following: From posting in Forum Topics, that have nothing to do with your software because those Forum Topics were created by IP Camera owners who were looking for help with firmware based issues. Please see the link above as one example of you doing this. Which your software cannot and could not possibly have helped, in any way, nor resolved in any way. Your attitude was that any Forum Topic was fair game for marketing your software. Even when your software was not capable of even being helpful in any way to the Forum Topic or even relevant in any way to that Forum Topic. Please start your own Topic about your software if needed instead of doing what you were doing. Which also included going into other Topics created by others who are also offering software and posting about your software in their Forum Topics. Which are/were created specifically about their software and to support their user bases questions and comments. Not created as just another additional advertising medium, for your software. Also please refrain from making false claims about your software fixing IP Camera issues that are firmware based issues. While your software may work around Web UI issues. Firmware based issues, can only be fixed by installing updated firmware which fix those firmware based issues. This was confusing some IP Camera owners making them think that if they simply downloaded/installed your software, that their IP Camera firmware related issues would be resolved. Which was/is not correct or true. If you require further clarifications about (2) please PM me here or in the Forum you referenced. I don't wish to bog down this Forum Topic with issues not relevant to it. But I did want to qualify #1 for others. So I also responded to your allegation at the same time. Don

No idea what you are trying to express and/or ask for and if it has anything to do with my post or is a general flashback to the past. Don