Angelcam Cloud Video Tested

By Ethan Ace, Published Oct 13, 2015, 12:00am EDT

With the cloud getting more and more hype plus with early market leader Dropcam stumbling after being acquired by Google / Nest, there is increased interest in emerging VSaaS / cloud video options.

Cloud camera startup Angelcam claims to make security cameras smart, with an "app store" including free cloud storage and live viewing and advanced apps like heatmaps, anonymization, and more.

We tested Angelcam to see how well it performed and how it compared to other cloud camera platforms like Dropcam/Nest. We tested advanced apps like heatmaps, counting, and the anonymizer, which blurs people in the FOV, shown in this demo:

******** ****** * ******** interface *** ****** ****** use, **** ****** **** and ******* ******* **************** ******** ****. **** *** ** ********** to **** *********** ******* users *** **** ** choose ***** *** ******* and *** *********** **** the ****** **** ********** and ***** ********* ********.

******** ******** ******** ****** manufacturers *** ****, *** users **** ******** **** ports ** ***** ****** and *** **** ** use *** **** **** URL. Using **** ******* ********** this ******* ***** *-*****, which ******** *** ****** number *** ***** ************** key (***), ****** ** manual **** **********. 

********'* *** ***** ** novel, ****** **** **** are ***** ** ****. In *** *****, *** Cloud *********, *********, **** Streaming (****** ************), *******, and ********** **** ****** well. 


********'* ***** ******* ** free, ********* **** *******, 3 **** ** ***** recording (** *******), *** basic **** *********.

***** * *** ***** storage **** ***** $*, lower **** **** **********'* plans, **** ** **** ($10/month *** ** ****) or ****** ($*.**/***** *** 7 ****). 

*** **** ********* *** (for ************) ** **** for ***** *** (** embedding, ****** *** *********, Angelcam ****). **** ***** removing *** *** ******** embedding *** *********, $**/***** and **.

******* *** **** **** is ***********, ** **** are ***** ** ****.

Angelcam *********

***** **** *** ******** functions *** ***** ** the ***** ********* *********. Here, ***** *** **** live *****, ***** **** in *** ******** ** start ********, *** ********* sections ** ***** ** create ***** (.***) *** a ****** ******, ******* to *******/****'* *** *********. No *****-****** **** ** archive ******* ** *********.

** *** ***** *****, we ****** *** ****** of *** ******** ********* for **** *** ******* use, ** **** ** clip ******** *** ******** of ***** *********. 

Adding *******

******** ******** **** ******* via *-***** ******* *** manual **** **********. *******, users **** ****** *** serial ****** *** ***** authentication *** (***), ******** on ***** **** **** camera, ***** **** ***** may *** ****. **** may ** ********* **** Axis ******* ** ****.

***** ******** **** ***********, the ****** ** ************* connected ** ******** ******* further *****.

***** *************' ******* *** be **** (*** ****** supporting **** *********), ****** require ****** **** **********. For **** *************, ***** do *** **** ** supply *** **** **** address, **** *** ******** IP/DNS **** *** ****, and ******** ***** ** the **** ****** ***. For ******, *** **** RTSP *** **** ** supplied.

** **** ** **** process ** **** *****:

Angelcam **** 

********'* *** ***** ****** ***** to *** ********** ************* to ***** *******, **** functions **** ** **** lapse, **** *********, *************, heatmaps, *** ********, *** more *********. **** *** developed ** ******** ** well ** ***** ***** developers.

*******, **** **** *** currently ** **** *** not ******* ********* *** installation. ***** **** ******* Angelcam *** ***** *** beta ******.

** ****** ** **** beta ****, **** ** their ************* *** *** heatmaps, ***** ** *** video *****. 

Comments (65)

Pretty neat. I tested with Samsung Cameras (Samsung employee...). Their support pages were no help - pretty much said Samsung cameras may work, but didn't have correct URI. I entered the URI that I have for MJPEG & RTSP and got it working.

MJPEG has low delay of approx 2-3 seconds. H.264 RTSP takes longer to start streaming and has approx. 10-12 second delay. Audio came through well for both streams. The live view app works well - lots of branding for free, and make sure to turn off the google map location. Easily viewed on mobile device.

The cloud recording free plan does not allow you to save/download/export clips, making it pretty useless.

I like the idea, however the "autodetect" needs to be better - they need to update their database of camera URI, and add more apps. I know that they have a bunch in beta. The time lapse allows you to create only 3 videos for free.

It is nice that it is HTML5 with no plug ins, however, it is NOT quick to jump around between cameras, etc. to use as a management dashboard. You can view the small thumbnails or full screen, but nothing in between.

The dashboard has a snapshot of the cameras, but it is always a few hours old, so that can lead to confusion. To get live video, you have to select a cam, then wait for it to load...

Most of the forums are 2-3 years old....

Hi Aaron,

Thanks for sharing your point of view and for your kind words! You could find my answers below:

>Most of the forums are 2-3 years old....

Yep. Customers prefer another ways how to reach us today (live chat, e-mail).

> it is NOT quick to jump around between cameras, etc. to use as a management dashboard.

Yep again. We'll address this issue in one of the next updates (as described in my comment below).
> pretty much said Samsung cameras may work, but didn't have correct URI
I'll be happy if you could share an updated URIs for Samsung cams, feel free to reach me at, thanks!
> The cloud recording free plan does not allow you to save/download/export clips
Yep, that allows you to test the service and upgrade later.


"The cloud recording free plan does not allow you to save clips, making it pretty useless."

Useless seems a bit strong, no? It depends how often you need to save clips but I can imagine people (myself included) that might value seeing what happened last night but don't regularly export clips. If you need clips, you could upgrade right then and there. It's built-in to the app.

"The dashboard has a snapshot of the cameras, but it is always a few hours old, so that can lead to confusion."

Agreed. Had the same initial experience.

The snapshot is refreshed every time you log in to the dashboard - however it takes a few seconds to get a fresh one.

So if I have been logged in for an hour, or a day, it will show me the same snapshot from when I first logged in?

It's just generally confusing for it not to be as recent as possible.


The save clip/export functionality brings up an interesting question on chain/continuity of evidence.

Does anyone have any legal reference about how a downloaded clip may be used when the original video gets washed in a few days or whatever time frame?

"when the original video gets washed"

Vince, what do you mean by 'gets washed'?

"up an interesting question on chain/continuity of evidence"

Not a lawyer, but I am not sure how or why this would be protested more than recording on a DVR. What difference are you concerned about?


From experience I learn that you have noting “if you cannot prove original source and establish both chain of custody and evidentiary integrity”. In the instant case neither can be proven and both can be questioned thus opening the door for being thrown out in court. As for a copy of a DVR video file the same applies, if you can’t prove evidentiary integrity then you have nothing. For further reading on the subject check out EnCase from Guidance Software, the tool the DOJ, DHS, FBI et al. and many forensic experts rely on.

I'm genuinely interested in case studies where video evidence was "thrown out of court" due to an inability to show its chain of custody.

I looked at EnCase's web site and didn't see anything obvious.

Any pointers would be helpful.

Digital video is digital data and thus is treated as such where evidentiary integrity and chain of custody are concerned. As such there are a number of cases where “digital data” had been thrown out for lack of ability to establish evidentiary integrity and chain of custody. For example Amex v. Vinhnee, December 2005 is one such case; there are many others. Throw into the mix digital data stored in the cloud and the waters get muddier.

"For example Amex v. Vinhnee, December 2005 is one"

But Vinhee has nothing to do with video surveillance. Here is the Appellate ruling, key quote:

"The refusal to admit the billing statements in evidence left American Express with only Vinhnee’s admissions on his schedules as evidence."


“But Vinhee has nothing to do with video surveillance.”

Perhaps I missed something but, the admissibility of the fruits of video surveillance has everything to do with admissibility of digital data file(s). If the presenter cannot establish to the courts satisfaction the evidentiary integrity and chain of custody of the digital data then what that data represents is irrelevant, be it an AMEX billing statement or digital video retrieved from cloud or DVR storage. From my own experience, solving this issue in a video augmented security system is quite simple and provides a reasonable assurance the digital files (video included) meet evidentiary standards. But again, perhaps I missed something?

"If the presenter cannot establish to the courts satisfaction the evidentiary integrity and chain of custody of the digital data then what that data represents is irrelevant"

Then show us cases where video surveillance specifically is being thrown out for not having proven 'evidentiary integrity and chain of custody'.

I think it's possible, it just seems it is not a common concern or need for video to regularly be proven in this matter, since video is used hundreds / thousands of time in crimes weekly without such proof being requested.


I may have inadvertently struck a nerve and if so it was not my intent and I apologize.

To your question, in fact NO, I’m not aware of any case where surveillance video got thrown out for failure to establish chain of custody. I do have firsthand experience in a federal case where a federal grand jury handed down no true bill upon admission by a fed agent that the evidentiary integrity of digital data evidence, including video surveillance data, could not be established and proven. Of course there are a number of instances where video surveillance digital data has been tossed for failing evidentiary integrity tests, the most recent well known case being Planned Parenthood where it’s shown the digital video surveillance data evidence had been doctored, possibly by its proponents. Given there are a number of cases where digital data has failed the evidentiary integrity and/or chain of custody test, IMHO it is only a matter of time before that digital data turns out to be video surveillance footage. It's for this reason I take seriously the issues of security and integrity and if proof of chain of custody can be thrown in as well then so much the better. An ounce of prevention can go a long way, especially when it is cheap and easy to accommodate.


Originally, you declared:

"As for a copy of a DVR video file the same applies, if you can’t prove evidentiary integrity then you have nothing."

The nerve that you have struck is failing to prove that. We both agree that, in practice, video surveillance is almost always admitted / used without proving 'evidentiary integrity', right?

Beyond that, how is Angelcam inherently worse than Milestone or Exacq or Hikvision? How are you validating 'evidentiary integrity' of video surveillance?

Wrong! John, we do not agree and I suspect on this question the only thing we can agree on is to disagree.

It is my opinion that digital data (including that whose content is video derived from video surveillance) where provenance, integrity and chain of custody cannot be established will be tossed, always. That I’m not aware of a court case that demonstrates this to your satisfaction is unfortunate but then the position I stake is based on what happens in the run up to a court case. If a video surveillance file is tossed in the run up to the court case then of course there will be no court case record of it. So the real question revolves around "what is the possibility of being tossed during the run up?" Failing the three criteria I mention, being tossed is a virtual guarantee.

My basis is that video surveillance (or any other type of) digital data for which provenance, integrity or chain of custody cannot be established and assured will be tossed, explicitly or implicitly, for the simple reason that it is impossible to find a forensic expert to authenticate the questionable provenance, integrity or chain of custody. And yes, forensic expert witness testimony of affirmation is required. This “tossing” will occur early in the legal process, perhaps during production, pre-discovery or discovery phases and will not therefore show up in the court decision records. Having said all this, should you be able to identify a forensic expert willing to authenticate such a digital (video) data file lacking these various credentials then I’ll most definitely reconsider my position and quite probably eat crow.

I responded to a question regarding a process of exporting a file from a cloud server and I’ve worded my comments to make clear they apply not exclusively to the instant case but to all such cases where this process is applied. So far as I know, the Angelcam product works as advertised, I have tried it, and their service is probably equal to those of the others you identify.

The specifics of how I’m doing it in ProteqsIt are proprietary and I’d rather not discuss them in a public forum. Suffice to say I’m confident these processes will withstand the stringent tests outlined by SCOTUS and Federal Rules of Evidence 901. I hope for my clients sake they never need to be tested but if they do, I have confidence in proving provenance, integrity and chain of custody to legal standards - even should those files be exported from a cloud server.

"Wrong! John... I’m not aware of a court case that demonstrates this"

If you had at least one court case that covered video surveillance, I'd be happy to consider it. But since it is a fact that police departments use video from numerous businesses daily and you never see issues with integrity, it is reasonable to believe that it is not a major issue.

It's great that you care and will protect your clients but, without more evidence, it does not seem to be a significant risk.

I’m not a lawyer but I suspect it’s insufficient to say that all digital data files have the same implications, and thus require the same criteria in terms of how they’re handled to preserve their evidentiary value.

For example, if I produce a spreadsheet showing transfer of money from an account, and claim that it came off your computer, the implications of that evidence can be easily questioned unless I can prove it came from your computer, and was not tampered with since. Whereas if I produce a video showing a person who looks like you committing a crime, the evidentiary value is not in the data file’s provenance but rather within the contents of the video data itself. This is data that is not as easily tampered with, technically. A reasonable person is likely to take video evidence at face value, whereas that same person might need more information about the origin of other types of digital data before subscribing to its implications as evidence.

I believe this is why we so rarely see digital video “thrown out of court” simply due to lack of provenance or a thorough accounting of its chain of custody.

But like I said in my earlier comment, I’m open to suggestions for methods we as manufacturers can provide to help law enforcement and prosecution in this regard. Today I know from experience working with law enforcement that I am rarely asked to ‘prove’ the video in question satisfies some stringent criteria about it’s origin. Law enforcement tends to be more concerned about acquiring the data itself. The reason I’d like to see case studies where video evidence has been inadmissible is so I can infer where there may be gaps we can help fill.


I’m in total agreement with you; even if the data, video surveillance data in this case, cannot be used as evidence, its content could, should and would be used by law enforcement. However my response was to Vince’s original in which he questioned the potential “legal reference” of a downloaded clip from a cloud server, not to the more general question of does it have any value at all.

As to “I believe this is why we so rarely see digital video thrown out of court”, no, I suspect not. First to clarify; I’m not aware of any court case where digital video was thrown out for lack of provenance or chain of custody and further, to be honest, I haven’t searched for such and have no intent of doing so as I suspect doing so would be fruitless and a total waste of time and energy. I believe there is a simple explanation for this. SCOTUS has instructed lower courts, and Federal Rules of Evidence 901 state that, where complex computer processes and data are concerned the evidence in question must be supported by expert witness testimony.

This leads to the simple question “can you find a forensic expert willing to jeopardize both credentials and reputation by authenticating digital video surveillance data for which s/he cannot establish unquestionable provenance, and chain of custody?” Over the past I’ve done business with three computer forensic experts and can affirm they would not. So, the tossing of video surveillance data exported from a cloud server for inability to find a forensic expert witness to authenticate would happen long before court case formulation during the pre-discovery and discovery periods. You’ll not find this in court case decisions and will have to dig through volumes of data in the case dockets and even then you'll not find off the record prosecutor decisions.

As for suggestions, perhaps a couple of Rick’s golden rules would be helpful “the best witness is an eyewitness and video is an eyewitness” and “always, always error on the side of caution”. I know, common sense but... In my own development efforts I establish provenance at the camera and eliminate the question of “chain of custody” by means I’d rather not disclose in a public forum.

I'm confused wouldn't there often be at least a motion to suppress evidence, that would be searchable thru Westlaw or the like?

Actually there are 3 good sources, Westlaw as you suggest and also LexusNexus and PACER. I’ve subscribed to and used each in the past and they are good. However, if I’m on point then such a search would be fruitless as there will be no motion to suppress if the video surveillance data file is not presented by the prosecutor.

There are many factors that play into the prosecutor’s decision of what to present at trial including the provenance, integrity and chain of custody of the video surveillance data file. If any of those three legs of evidentiary rule are missing then the likelihood of the prosecutor tossing the video surveillance data file comes into play, my point.

Of course the creative risk taking prosecutor can still do such things as, for example, having her forensic expert grab applicable frames from the tainted video surveillance footage and present those as evidence wherein the provenance, integrity and chain of custody of the stills cannot be easily questioned. I’ve spoken with forensic guys in the biz who have been involved in cases such as described who indicate the courts have accepted the evidence. At the end of the day, it’s up to the prosecutor and because of that unknowable, I prefer to error on the side of caution.

From experience I learn that you have nothing “if you cannot prove original source and establish both chain of custody and evidentiary integrity".

Or maybe "you could have nothing."

Not doubting that what you say is true, just imagining that as a practical matter, criminals caught by video surveillance are 99% of the time small time criminals, who likely confess after being shown the evidence.

Even when they go to court I'm wondering how often evidence gets thrown out. And even if it does get thrown out, the information obtained from the video (red corvette, suspect description), which leads to the arrest and subsequent eye-witness evidence would still stand, correct?

In summary, is this really a thing a homeowner should be concerned with?

Not conceding your numbers, what you say is probably true. If one is comfortable with 99% (or whatever the number really is) then one is good to go. If one leans more toward satisfaction at 100% then maybe not so much. The original question was to general to know which applies.

I meant that the original video retention has expired and no longer exists.

For Angel Cam, if you buy a week retention, then the video is gone after predetermined period is my idea if they retain any at all as I am not familiar with their policies.

Interesting debate below. Not a lawyer either, was just interested in legal ramifications.

(In a case someone read this after a years)

For this reasons we introduced - a long time ago - Secured Vault.

1. When a customer enable video recording (continuous or event)
2. He can then create one or more clips (up to 3 hours long)
3. Clips can be, among downloading, shared to others (by sending long unique URL) or moved to the Secured Vault with one click. The video stay there forever (until user will decide to delete it or until the recording for the particular camera will stay active) for no additional price.

So for an evidence or investigation purposes, video stays there, unedited, with a clear evidence when it has been recorded and from what camera.

So far we haven't heard about a case this is not enough for our customers, while we know it has been used successfully many times.

"Secured Vault" is a fancy title. Without care it sets off a level-2 snake-oil alert. I hope you mean the data is digitally signed or hashed in such a way that later the data can be checked for "evidentiary integrity".

Thanks for the review!

On multi-camera availability (e.g. synchronous playback/export) - we created few variations of our UI and selected customers are testing it currently. This is one of the alternatives (combining live video monitoring & playback on one screen). When we'll have positive feedback from most of our customers for any winner, we'll release it publicly.

Angelcam group camera management


Is there a contact at Angelcam that I can direct feedback on connecting Samsung cameras? The forums listed some info that was inaccurate or out of date. I can provide the correct info so Samsung cameras connect properly. I would love to get up to date info posted on the forum. It would be nice to get the "auto detect" to properly populate the Samsung URI.


Sure! Love to do that: or Thanks Aaron!

So what's the trick to getting the no-plugin required H.264 streaming going?

I am using the latest Chrome I think, Version 46.0.2490.71 m, but I noticed that the player used to render the live stream for me is Adobe flash.

I believe Flash support is built in to the Chrome browser platform.

I believe Flash support is built in to the Chrome browser platform.

So it's NOT an HTML5 player then???

Answering my own question, no it's not a html5 player, yet. Although there looks like there is one in the works.

Its not much of a knock against angelcam, it's quite rare at the moment.

And I think the people at angelcam know what they are doing. Pulling RTSP streams directly thru a firewall without any client software is harder done than said.

Who else can claim that?

We're using Flash player for PC/Windows but working hard to introduce pure HTML5 player. For mobile devices we're using native players already. Flash is going to die soon as we all know. One day it will be completely blocked in Chrome and Firefox.

From the protocol side - at the moment we're using Apple HTTP HLS for all devices except old Androids. We're currently testing a completely different protocol approach which brings much better latency and stream startup and this will be launched with a month or two.

In case of any questions just let me know. Thanks!

I believe the "no-plugin" relates to obsolete camera admin panels. Many of them are using strange ActiveX or Quicktime or Java components or just resign to stream H264 and fall back to simple MJPEG.

Peter, I think you have accomplished a good deal so far, but I would be hesitant to pay for the service without seeing both the new HTML5 client and the non-HLS protocol implementation.

Using HLS really obscures the considerable benefit of pulling live RTSP by introducing the store and forward latency of HLS. I would say that ancient as MJPEG from server to MJPEG on client is, overall still more responsive.

One suggestion you may want to consider for your camera URL database, if you aren't doing this already:

Have the database be self-learning, so that when people add URLs that you find actually work, add them to the pool so the next guy might not need them.

Finally, is there any plans to pull the ONVIF RTSP? That would be another way to avoid URL funk.

Thanks for the suggestion, that's something we're doing manually.

We're playing with ONVIF already, there are other issues like different ONVIF paths, need for ONVIF activation etc.

Clever application and pitch but…

Some observations regarding the review of AngelCam Video Security; observations that can be applied pretty much to every other like product (D-Link, DropCap, NestCam, this cam, that cam the next cam et. al.).

First up – cost, which appears to be a bit steep. If I lived in a one room house with only one entrance and no windows, no driveway and no cars to park in the non-existent driveway then perhaps the cost of $40 per month for a single camera installation is marginally acceptable. But I don’t live and work in such an environment. In my case my home and business have more than one room, there are windows, there are three entrances, there is a drive and there are cars parked in the drive and to compound matters, there is an out building; by no means a unique setup. At minimum, six security cameras are required. For this the AngelCam numbers indicate a monthly nut in the neighborhood of $420. Added to that are onetime cost of an otherwise unnecessary router, cable modem, ComCast cable hook up and related network stuff. So, not including the one time costs involved, the annual out of pocket for an AngelCam solution is in the vicinity of $5000. I also question the longevity of the $10/month storage pricing as AWS S3 costs leave little headroom for profits. The otherwise unnecessary cable network installation is required to accommodate uplink bandwidth for 6 IP cameras doing 24/7 medium quality H264 HD video. Too bad AngelCam doesn’t support event driven recording as it would certainly improve their profits prospect and help reduce the bandwidth needs.

How about security – should a security product increase the user’s security risk? While I think not, I’m an outlier on this question. To wit, early this year HP released a study of 10 cloud based security systems using a battery of 10 security test criteria; and their findings, most products batted 1000 (all failing some tests) and all batted at least 700 (7 out of 10 failed) other tests. Enviable numbers for the majors but not so much for security products. My hopes that AngelCam would break the mold were dashed as I would learn. Use of AngelCam requires a hole punched through router and firewall to allow access to the IP camera; a front door wide open to the Internet. Added to this, AngelCam transmits camera credentials in the open over the Internet. So, it’s a snap for man-in-the-middle to grab the camera credentials, hack into the camera (that is likely running a variant of embedded Linux) infect the camera OS and from there jump to everything connected to the LAN. Adding insult to injury, although the Web App does use HTTPS to the cloud, only single factor credentials are used; the users email address is required for user name and there is virtually no restriction as to password; for my tests I used “a123”. Getting my email address is a snap, discovering my password takes minutes after which, bing, the hacker is in to my AngelCam account and the AngelCam cloud by impersonating me and using “secure HTTPS” protocol. Yes, of course I should have used a more challenging password but that would not demonstrate my point; there are lots and lots of people who continue to use “password” as their password, not advisable but they do. So it’s become the responsibility of the service provider to protect their clients by forcing use of strong multi factor credentials. Also, out of curiosity I launched Wireshark and sure enough, my personal video is streamed un-encrypted over the Internet available to anyone who may be interested. A claim that a security product is secure because parts of it use HTTPS or because it is hosted on AWS, Azure, iCloud or any other cloud service is an empty claim to be sure. In time I expect MS, Amazon, Google, Apple et. al. will start forcing their clients, in this case AngelCam, to provide their service clients, you and me, with better cloud service security. Until then “cloud security” remains an oxymoron.

Another security matter I take issue with in the AngelCam model is the concept of allowing the “free” developer access to my personal data, information and content. AngelCam, like SmartThings (Samsung), advertise for developers from around the world to join up and invest in and support their products. These totally un-vetted developers are then given the golden key to the kingdom, the cloud that holds the end users stuff. Whilst one might decide to put their trust in AngelCam or Samsung/SmartThings or others with similar business/product models, I wonder if they would do so if fully aware that in effect they were publishing their personal and private stuff to the world and anyone who wants to sign up as a service developer.

A final observation; while I’m happy to see that “Video Surveillance” is finally evolving to “Video Security”, shouldn’t a multi camera video security system include support for other related technology such as door locks, smoke detectors, CO detectors, water detectors door/window sensors, vibration sensors, motion sensors, and all the rest? Rhetorical question, of course it should.

I began this missive with it’s a “clever application and pitch” and I’m sure it will snare many but how much is it actually applicable to the subject of “security”. Missing from the list of clever gadgets (real or planned) is the very basic concepts of “motion detection”, “event enabled recording” and “event notification”; I could find no mention of either. Security is breached but there’s no notification; really? What’s the value of counting the number of criminals invading my home or business? Anonymizing the crooks to protect their identities seems a strange security system feature and counting cars or reading license plates seem far afield from the stated goal of home/business security system.

In closing, I did try out AngelCam and it did operate as advertised. It’s a neat product and application but perhaps not best suited for the application of home/business security.

"the cost of $40 per month for a single camera installation"

Where did you get that? Angelcam 30 day recording is $9.99 per camera.

"HP released a study of 10 cloud based security systems using a battery of 10 security test criteria"

For those interested, here is the HP study.

You are right John, I should have been more presice, its $39.99/month, $9.99/month for recorder storage and $30/month for the App. Or did I missread yours?

So Angelcam's service names are confusing. The 'Live Streaming' app really means 'Public Broadcasting' for those who want to share with the 'world'.

If you just want to watch video live yourself / your own account, that's free. So $9.99 total gets you traditional live viewing + 30 days recording.

Ah, you are right, very confusing. A security product that can broadcast security video to the masses, what a concept? In any case, I was wrong and stand corrected; assuming the mobile apps remain free, the monthly nut for me would be reduced to $119.94, annually a $1439.40 bill. Still a bit much! And, in reading the developer pages it sure seems to suggest that "free" and "mobile Apps" may soon part company.

Even a 90%+ price drop won't work for you! :)

I think there are people out there willing to pay Angelcam ~$100 per year for one month recording (see Dropcam who charges almost 3x for that) but a lot of people are going to be even more attracted to their free 3 days recording or $5 for a week with clip exports. This is much more for the non-traditional, low demand user.

AngelCam transmits camera credentials in the open over the Internet. So, it’s a snap for man-in-the-middle to grab the camera credentials, hack into the camera (that is likely running a variant of embedded Linux) infect the camera OS and from there jump to everything connected to the LAN.

What do you mean in the open? As in plain text or base64 encoded?

John, agreed - like I said, they will snare the naïve.

Undisclosed 1 – correct, plain like in “plain text”

plain like in “plain text”

Which transmission vector(s) did you observe this on?

  1. to webpage
  2. to mobile app
  3. to camera
  4. webpage to
  5. mobile app to
  6. camera to

So I can try it and tell you if I see the same thing from my account...

Today typically the Security-as-a-Service architecture such as used by AngelCam (and others) has at its center of the implementation a cloud Internet server, which in AngelCam’s case is hosted on an AWS S3 virtual machine. The cloud Internet server provides for three basic access paths for data flow; (1) the developer pathway normally accomplished over secure private network connection such as VPN/RDP or telnet/sh, (2) the public Internet connection between user Web/Mobile App for account setup, maintenance and content viewing and (3) the security device (in this case an IP camera) to cloud Internet service connection.

The data path or vector of interest in this case is that between cloud Internet service and the security device, path (3) from above and your vector 3 I believe.

Via path (2) the user establishes an SaaS account and in the process provides the service with certain personal data and information which in AngelCam’s case includes the external (public) IP address of the home/business router. The user also provides the access credentials and other such information required by the service to access the security device over path (3). Working together the user and the cloud Internet service figure out the correct string required to initiate an RTSP session with the security device and this is also stored in the cloud Internet server.

As an aside, there is the interesting question of what happens to the AngelCam account setup when the home/business Internet service provider decides to change the routers IP address. In the case of ComCast, this happens weekly. Following this, the next time it becomes necessary for the cloud service to re-connect (and invariably there will be a next time) it appears to me the reconnection will fail and the user will be forced into having to setup the camera account once again. I may be wrong, but I suspect this is the case since there is no mention of setting up DDNS and hence no way for the cloud service to know the new IP address assigned.

Be that as it may, the AngelCam service user also needs to setup their home/business router which may be done automatically, semi-automatically or manually. No matter which the results are the same; a hole per security device is blown through the routers firewall to allow access by the cloud Internet service to the security device.

Once setup is complete the cloud Internet service can initiate an RTSP session with the security device via path (3). Initiation is done by sending the RTSP string, established during account setup, in plain text format over the Internet to the public IP address that was provided during account setup. When the request string hits the router it is routed to the IP camera through the hole that was blown in the firewall.

From that point the un-encrypted plain video content are streamed from the security device via path (3) to the cloud Internet server where it is stored and made available for viewing via Web/Mobile App. Path (3) appears to be limited to RTSP streaming only with no out-of-band notifications leading to an assumption on my part that the AngelCam implementation has no “notification” ability, that is, no ability for the security device to notify the user of events such as motion detection indicating possibility of an intrusion. I know, this kind of defeats the purpose of the security device but...

As another aside; from the above you can see there are many opportunities for security breaches including; hacking the security device (IP camera) by a man-in-the-middle attack, stealing the video stream by a man-in-the-middle attack and pirating the account by impersonation attack. None of these possibilities are the responsibility of the cloud infrastructure provider, in this case Amazon and none are prevented by use of HTTPS.

Initiation is done by sending the RTSP string, established during account setup, in plain text format over the Internet to the public IP address that was provided during account setup. When the request string hits the router it is routed to the IP camera through the hole that was blown in the firewall.

It's true that using RTSP that the URL will be sent in the clear. However, RTSP allows the use of Digest Authentication for sending username/password. Many if not most cameras support Digest auth, so it's weird that they are not using it.

Did you see the cleartext username/password as preamble part of the URL like: rtsp://<user>:<pass>/<camera ip/video.cgi or did you see it in the WWW-authenticate header of the RTSP OPTIONS action request, or somewhere else?

DESCRIBE rtsp://root:pass@xx.xx.xx.xx:554/axis-media/media.amp RTSP/1.0

Above from shark, IP address is xx'ed out, camera as you guess is axis in default setup mode

Thanks Richard.

One small procedural question, did you have to make any changes to your switch or router (besides the 554 hole/forward) to capture the traffic, or did you just use Wireshark the usual way?

The only preconditions made, other than punching holes through firewalls, was to set the camera(s) to factory defaults to better simulate the naïve home/business DIY user setup. Then I sharked the network and posted the results.

From what machine did you run Wireshark?

Then I sharked the network and posted the results.

Richard, I would like very much to replicate your results in the manner that you did, but I am unable to because you say that

  1. The clear text credential traffic was only observed between the cloud and the security device, where the PC/web client was not involved.
  2. You didn't use any switch or router port monitoring/duplicating mechanism to allow capture by a third party interface, e.g. a PC running capture the packets.
  3. You used Wireshark to capture the frames

Aside from port monitoring/duplicating at the switch, the only ways that I know of to capture the cloud to camera interaction on the home LAN would be to

  1. Run Wireshark on the camera
  2. Run Wireshark on the router
  3. Use a 10BASE-T only hub (never tried this myself)

Did you do any of the above or is there another way?

Actually there is a forth rather simple way –

  1. Punch the requisite hole in your router and then go to AngelCam to setup and verify the camera interface.
  2. Map the router hole to the IP of a PC/Mac where you have shark running. Repeat step 1. You may have to repeat the AngelCam setup as they don’t appear to have any re-connect logic.
  3. View results…

Though you still need a listener process on the PC/MAC on 80 or 554, otherwise without a socket, there is no connection and angelcam won't send anything to the PC.

And if you run a web server for your listener, you don't even need Wireshark, just look in the web logs.

This is essentially what I did to confirm you findings, as I say below.

Web site footprint all uses TLS 1.1 with AES 128 GCM and a 2048 bit RSA key using a SHA-256 hashed signature. So they got the crypto right, sort of. All their sites are comingled on the same key. So their customer data is no more important than their blog posts in terms of their network defense strategy. And RTSP should be sent over HTTPS or HTTP, and you should not be opening firewall holes. So this one sounds insecure.

"You should not be opening firewall holes."

Agreed, in general, but, without that, they would have no support except for Axis one-click :)

Either way it's still a 'hole' in the firewall, but with Axis one-click there is no entry in the firewall rule table of the router.

RTSP should be sent over HTTPS or HTTP, and you should not be opening firewall holes.

I think the idea is not to have to run any local process running to tunnel the RTSP over http(s).

And there is no reason to send the password as part of the URL, Axis supports Digest Auth. It's not TLS, but at least it's encrypted.

There are a lot of things that could be done to improve/reduce user security risks. Using digest would help, multifactor authentication would help, encrypted user data would help... The question I suppose becomes, should the customer’s security be of concern enough to warrant such measures? Apparently not at the moment but at some point that becomes the more fundamental question to be addressed and I suspect that sooner or later security product providers will come face to face with it.

Fascinating turn this thread has made. A few random thoughts:

First off I’m not trying to apologize for the security vulnerabilities that Richard points out about AngelCam. Today I tend to assume that most implementations of cloud based surveillance products follow more mature principles that limit the particulars he points out. But in AngelCam’s case the goal is (I guess) to provide a convenient way to attach any RTSP source to the service and that limits the security options somewhat.

The HP paper that Richard mentions is pimping their Fortify On Demand offering which is a security scanner that itself is based on the OWASP’s draft IoT guidance. The thing about OWASP is it’s just a guidance. OWASP itself encourages people to ‘weight the pros and cons’ of each recommendation in the context of their own environment and system. Some recommendations are thus not always implemented even by systems that are relatively secure (for example, two factor authentication). So it’s pretty easy for HP, marketing wise, to take a category of products, evaluate them in detail against the entire set of OSWASP recommendations, and then claim that nearly everything they test is not secure and oh-by-the-way you need to buy their security scanner product.

I like Richard’s analysis but don’t agree with some implicit generalizations. Maybe I’m a little over sensitive, but I don’t believe you can look at HP’s marketing or AngleCam’s issues and then conclude that all cloud-based systems are inherently insecure or more insecure than the alternative. The state-of-the-art for providing remote access to a home security system for many years has been hanging a DVR off the local network and providing port forwarding to said DVR’s HTTP interface through the firewall. How many of those implementations fail to adhere to the OWASP guidance?

I do agree that providing a publically accessible path to a security system is something to be taken seriously. Thus any ‘cloud based’ solution needs to be scrutinized for security. And if you’re a provider/manufacturer of such a solution then security needs to be in the DNA of your development, deployment and operation. I propose that it can be done safely if it’s done well. The challenge is to discern between those that are doing it well both in terms of design and implementation and those that are not.

Yes, the thread has taken an interesting twist from general product review to a focus on security but…

I too am befuddled and not yet sure what the AngelCam target really is. There is the claim of its being some sort of security product and yet, a read of the Website seems to suggest otherwise?

Agree, like most such reports, the HP paper is somewhat self serving but the findings reported are binary in nature as is the OWASP test suite itself. The product under test either passes the test or it does not, leaving little wiggle room for debate.

I suppose I may have come across suggesting too broad a brush that paints all “cloud-based” solutions but that was not my intent. Cloud-based computing, as distinguish from cloud-based service, I believe is generally very secure as after all, the cloud-based computing client assumes all the risk. Cloud-based service is a very different kettle of fish wherein the service provider is taking virtually no risk at all and their client, the service user, is assuming all of the risk with limited or no control what-so-ever. So, in this case I think the broad brush of trust but verify generalization is warranted.

I can confirm Richard's findings that angelcam is sending user name and password in clear text in the RTSP URL.

I found it by using the RTSP Honeypot described here.

Good work, Richard!

Hi, I just want to let you know that we did another step to making cloud security more safer (and convenient) - we released Arrow. It's open-sourced library ( that allows any camera/NVR/router producer to enhance a firmware of his device for a features, that makes a device plug'n'play with angelcam, and transmits all data (credentials and video) encrypted.

You can expect first devices coming to the market in 6 weeks or so.

And for existing installations we deployed Arrow code to a Raspberry PI computer, available to purchase at, more details at

Hi guys,
Thanks for such worthy discussion! Let me comment some parts of it.
The Angelcam platform is constantly growing and so are our security features. IP cameras nowadays only support RTSP protocol for video transfer, which (by design) isn't secure. The only thing we can transmit securely is password, using digest authentication. We've implemented this feature recently and we're going to launch it in a few days. There's a secure alternative to RTSP -- it's called SRTP. However, only a handful of Cisco IP camera use it. Due to the lack of such features we're currently working on a solution that will bring security to the next level. So yes, cloud-based services mature every day. I should also add that customers with security concerns can use Axis OneClick feature with HTTPS encrypted tunnel, which is supported by all Axis IP cameras.
I've just added 2-factor authentication to our roadmap, so thanks a lot for the feedback.
Once again, thank you guys for your posts.

Read this IPVM report for free.

This article is part of IPVM's 6,814 reports, 914 tests and is only available to members. To get a one-time preview of our work, enter your work email to access the full article.

Already a member? Login here | Join now
Loading Related Reports