A MASSIVE Privacy and Security Problem
The Market Ticker - Commentary on The Capital Markets
Logging in or registering will improve your experience here
Main Navigation
Display list of topics
Sarah's Resources You Should See
Sarah's Blog Buy Sarah's Pictures
Full-Text Search & Archives
Legal Disclaimer

The content on this site is provided without any warranty, express or implied. All opinions expressed on this site are those of the author and may contain errors or omissions.

NO MATERIAL HERE CONSTITUTES "INVESTMENT ADVICE" NOR IS IT A RECOMMENDATION TO BUY OR SELL ANY FINANCIAL INSTRUMENT, INCLUDING BUT NOT LIMITED TO STOCKS, OPTIONS, BONDS OR FUTURES.

The author may have a position in any company or security mentioned herein. Actions you undertake as a consequence of any analysis, opinion or advertisement on this site are your sole responsibility.

Market charts, when present, used with permission of TD Ameritrade/ThinkOrSwim Inc. Neither TD Ameritrade or ThinkOrSwim have reviewed, approved or disapproved any content herein.

The Market Ticker content may be sent unmodified to lawmakers via print or electronic means or excerpted online for non-commercial purposes provided full attribution is given and the original article source is linked to. Please contact Karl Denninger for reprint permission in other media, to republish full articles, or for any commercial use (which includes any site where advertising is displayed.)

Submissions or tips on matters of economic or political interest may be sent "over the transom" to The Editor at any time. To be considered for publication your submission must include full and correct contact information and be related to an economic or political matter of the day. All submissions become the property of The Market Ticker.

Considering sending spam? Read this first.

2018-05-17 10:08 by Karl Denninger
in Technology , 142 references Ignore this thread
A MASSIVE Privacy and Security Problem
[Comments enabled]

You're not going to like this.

Got a "Ring" doorbell?  Or, for that matter, any of those other nice IP cameras?  Doesn't matter who makes them, by the way.

Most security-conscious people are aware that there's a huge problem with allowing any sort of "cloud" storage option to be turned on.  Many people don't care, but you damn well should.

But here's the other problem that comes with these things: The video stream itself is totally insecure and your credentials are not much safer.

I'm unfortunately forced to recommend at this point that all such devices be immediately shut down in terms of off-premise access to the video.  Period.  Full-stop.  Right now.

The reason is a bit complex, so hopefully you'll read the whole thing to understand it.

Here's a typical start-up transaction for real-time video streaming to one of these cameras:

13:15:16.697677 IP (tos 0x0, ttl 63, id 20712, offset 0, flags [DF], proto TCP (6), length 163)
D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [P.], cksum 0xc419 (correct), seq 1:112, ack 1, win 343, options [nop,nop,TS val 7363585 ecr 37265593], length 111: RTSP, length: 111
OPTIONS rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0 RTSP/1.0
CSeq: 1
User-Agent: Live555

I want to look at the camera in real-time, main channel and normal "substream" (different resolutions, etc) using RTSP (streaming video)


192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0x2c43 (correct), seq 1:143, ack 112, win 905, options [nop,nop,TS val 37265595 ecr 7363585],length 142: RTSP, length: 142
RTSP/1.0 401 Unauthorized
CSeq: 1
WWW-Authenticate: Digest realm="Login to AMC000PD39KR3820JT", nonce="da8
684cec2ea70ff015538fb006139e3"

Heh jackass, you didn't give me any sort of credentials -- go away or tell me who you are with a password.

13:15:16.724851 IP (tos 0x0, ttl 63, id 20714, offset 0, flags [DF], proto TCP (6), length 394)
D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [P.], cksum 0xb072 (correct), seq 112:454, ack 143, win 347, options [nop,nop,TS val 7363588 ecr 37265595], length 342: RTSP, length: 342
OPTIONS rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0 RTSP/1.0
CSeq: 2
User-Agent: Live555
Authorization: Digest username="karl", realm="Login to AMC000PD39KR3820JT", nonce="da8684cec2ea70ff015538fb006139e3", uri="rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0", response="20dc9cda80205b5d2d8f2ae9c335dc27"

Ok, I'm Karl and here's a password for that previously-requested video stream.  Can I have it now?

Note that there is no actual password.  There's a "nonce" and a "response", both of which are not clear text.  The reason is that the camera (thankfully) demanded "digest" authentication.  Note that some earlier versions of camera software allowed "basic", which transmitted credentials -- including the password itself -- in plain text.

Amcrest shut that off about a year ago which is a good thing.  When they did they broke a lot of third-party software that, believe it or not, actually used and relied on plain-text passwords being sent over the wire.  That's so stupid it belies basic logic, but there was a lot of third-party code out there that did.  The fact that Amcrest forcibly disabled this by removing the option from their firmware is one of the reasons I've sort of liked their cameras -- they at least try.

The problem, however, will become clear momentarily....  let's continue.

13:15:16.741703 IP (tos 0x0, ttl 64, id 4151, offset 0, flags [DF], proto TCP (6), length 210)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0x9460 (correct), seq 143:301, ack 454, win 972, options [nop,nop,TS val 37265597 ecr 7363588], length 158: RTSP, length: 158
RTSP/1.0 200 OK
CSeq: 2
Server: Rtsp Server/3.0
Public: OPTIONS, DESCRIBE, ANNOUNCE, SETUP, PLAY, RECORD, PAUSE, TEARDOWN, SET_PARAMETER, GET_PARAMETER

I'm the camera, I like you and your password is good.  Here is what I know how to do with the RTSP protocol.  Please tell me how to proceed.

D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [P.], cksum 0xa4a0 (correct), seq 454:822, ack 301, win 351, options [nop,nop,TS val 7363590 ecr 37265597], length 368: RTSP, length: 368
DESCRIBE rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0 RTSP/1.0
Accept: application/sdp
CSeq: 3
User-Agent: Live555
Authorization: Digest username="karl", realm="Login to AMC000PD39KR3820JT", nonce="da8684cec2ea70ff015538fb006139e3", uri="rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0", response="55f38faa28da02835fdfd2de248f1632"

Ok, please tell me what the stream that is identified as channel 1, subchannel 0 looks like.  Oh, and here's authentication credentials again (note the "response" is different, because the hash includes the command, in this case "DESCRIBE" (with parameters) although the nonce has not been re-generated (this is part of problem #3 I'll get to later)

 

13:15:16.759068 IP (tos 0x0, ttl 64, id 4153, offset 0, flags [DF], proto TCP (6), length 773)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0xbee2 (correct), seq 301:1022, ack 822, win 1039, options [nop,nop,TS val 37265599 ecr 7363590], length 721: RTSP, length: 721
RTSP/1.0 200 OK
CSeq: 3
x-Accept-Dynamic-Rate: 1
Content-Base: rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0/
Cache-Control: must-revalidate
Content-Length: 506
Content-Type: application/sdp

v=0
o=- 2252311096 2252311096 IN IP4 0.0.0.0
s=Media Server
c=IN IP4 0.0.0.0
t=0 0
a=control:*
a=packetization-supported:DH
a=rtppayload-supported:DH
a=range:npt=now-
m=video 0 RTP/AVP 96
a=control:trackID=0
a=framerate:13.000000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=640029;sprop-parameter-s
ets=Z2QAKaw0yAeAIn5cBbgICAoAAAfQAADLIdDACpIACpFXeXGhgBUkABUirvLhQAA=,aO48MAA=
a=recvonly
m=audio 0 RTP/AVP 8
a=control:trackID=1
a=rtpmap:8 PCMA/16000
a=recvonly

Here's a bunch of information for you describing the media you requested.  The frame rate, the format of it, the audio that's included and its bitrate, etc -- all of which you'll need in order to successfully decode and display the video.  Oh, and your password is still good because I said "ok".

D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [P.], cksum 0xbc55 (correct), seq 822:1249, ack 1022, win 357, options [nop,nop,TS val 7363592 ecr 37265599], length 427: RTSP, length: 427
SETUP rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0/trackID=0 RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
x-Dynamic-Rate: 0
CSeq: 4
User-Agent: Live555
Authorization: Digest username="karl", realm="Login to AMC000PD39KR3820JT", nonce="da8684cec2ea70ff015538fb006139e3", uri="rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0/trackID=0", response="a069805debe9e14f99804d37242eac50"

Thank you.  Please set up to play the stream in question (I've decided I can understand it), and by the way, here's another hash (with my password of course) just so you know it's really me.

13:15:16.776718 IP (tos 0x0, ttl 64, id 4154, offset 0, flags [DF], proto TCP (6), length 195)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0xf8ba (correct), seq 1022:1165, ack 1249, win 1106, options [nop,nop,TS val 37265601 ecr 7363592], length 143: RTSP, length: 143
RTSP/1.0 200 OK
CSeq: 4
Session: 372956013002;timeout=60
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6D23767F
x-Dynamic-Rate: 1

Ok, you're good.  We're ready to go whenever you are, but the session I'm setting up for you is only valid for the next 60 seconds.  I'm going to send it over TCP, here's a session ID so you know it's the right one when it starts and oh, your password is still ok.

13:15:16.780403 IP (tos 0x0, ttl 63, id 20717, offset 0, flags [DF], proto TCP (6), length 435)
D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [P.], cksum 0xb842 (correct), seq 1249:1632, ack 1165, win 362, options [nop,nop,TS val 7363594 ecr 37265601], length 383: RTSP, length: 383
PLAY rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0/ RTSP/
1.0
Range: npt=0.000-
CSeq: 5
User-Agent: Live555
Session: 372956013002
Authorization: Digest username="karl", realm="Login to AMC000PD39KR3820JT", nonce="da8684cec2ea70ff015538fb006139e3", uri="rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0/", response="b215d803b422a92152c11d1abcf94387"

All good.  Start the stream please, play from time 0.000 on the session ID you previously set up for me.  Oh, and here's my credentials again.


13:15:16.816148 IP (tos 0x0, ttl 64, id 4156, offset 0, flags [DF], proto TCP (6), length 176)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0x97a8 (correct), seq 1165:1289, ack 1632, win 1173, options [nop,nop,TS val 37265605 ecr 7363594], length 124: RTSP, length: 124
RTSP/1.0 200 OK
CSeq: 5
Session: 372956013002
Range: npt=0.000000-
RTP-Info: url=trackID=0;seq=32390;rtptime=2924735

Here it comes!

192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0x4d5c (correct), seq 1289:1341, ack 1632, win 1173, options [nop,nop,TS val 37265609 ecr 7363601], length 52: RTSP
13:15:16.871343 IP (tos 0x0, ttl 63, id 20719, offset 0, flags [DF], proto TCP (6), length 52)
D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [.], cksum 0x9535 (correct), ack 1341, win 362, options [nop,nop,TS val 7363602 ecr 37265609], length 0
13:15:16.962682 IP (tos 0x0, ttl 64, id 4158, offset 0, flags [DF], proto TCP (6), length 1500)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [.], cksum 0x5aa7 (correct), seq 1341:2789, ack 1632, win 1173, options [nop,nop,TS val 37265619 ecr 7363602], length 1448: RTSP
13:15:16.962846 IP (tos 0x0, ttl 64, id 4159, offset 0, flags [DF], proto TCP (6), length 1500)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [.], cksum 0xdfe3 (correct), seq 2789:4237, ack 1632, win 1173, options [nop,nop,TS val 37265619 ecr 7363602], length 1448: RTSP

And there it is.... there's a lot more of course but these are the start of the packets containing the actual video.

Now here are the problems, in order:

1. RTSP is unencrypted. This means that the actual video is flowing over the network with absolutely zero encryption of any sort, and anyone in the middle can pick it off.  Watching it on a WiFi network that is unsecured in some coffee shop?  Everyone within 200' of you can see your video.  Is that your cute kid on the "baby monitor" or your empty house?  That wouldn't be a problem, right?

2. Every three-letter spook and criminal malefactor who can access any part of the infrastructure between you and the camera can also trivially decode and display that video in real-time.  Yes, I said anyone.  It requires exactly zero coding or effort to display an RTSP stream you capture; simply feed it to any media player that understands the format and voila -- there you are.  This means that any time you have an actual video stream running anyone who is sufficiently motivated can watch it too at the same time you do or grab the stream, save it to their device and watch it whenever they'd like.  There is not a single online store or financial institution that finds this sort of crap acceptable which is why they all have those little padlocks (https) on their web pages.

3. MD5 is not secure.  That's what "digest" uses to hash those passwords.  It's better than sending them in plain text over the Internet, but not that much better.  While someone who gets a single session would probably have trouble breaking your password someone who manages to get a bunch of these negotiations over time absolutely can do so.  I will note that MD5 was deprecated a long time ago as a sufficiently good digest for hashing passwords in general and it's also not considered acceptable as a hashing algorithm in SSL either, for the same reason -- it's not very hard to break.  If your camera is connected to any sort of "central" or "cloud" service those transactions are all going to one destination and thus you must assume your password has been stolen.  Once stolen, of course, said bad actor can now break into your camera at any time in the future, not just when you're watching it.  Again, I repeat: If you allow your "IP camera" to connect to or if you use any sort of "cloud" storage, control or similar facility you must assume that the login credentials have been compromised.

I've made a "command decision" when it comes to HomeDaemon's app -- it's not going to support doing that as it stands although literally every single damn app out there right now does.  No way am I doing that with my code as it's a blatant and severe security problem.

Instead what I support now is SSL-encrypted transport of captured stills, which is easy because I already use SSL-encrypted transport to talk to the server, the server has the ability to ask the camera for stills already, both are on the same local LAN which is encrypted with AES (and thus reasonably secure) and HomeDaemon-MCP (the server code) already knows how to enforce permissions for sessions so you not only need to authenticate but some users can have access to the camera images and others not, as you wish.  That is secure off-premise right here, right now because (1) the camera is not directly sending the picture, HomeDaemon-MCP is, (2) it demanded and got an SSL connection to the client on the phone and (3) the transport is thus safe from interception or even knowledge that you made the request.

So if you click a camera icon on the HomeDaemon-MCP app what you'll get is the most-recent still the camera has captured, usually configured on the base code to be snapped whenever the camera "sees" movement -- instead of a real-time video stream.

What I'm investigating supporting (if I can figure out how to feed Android's media decoder and display tools bidirectionally with arbitrary streams of data) is a secure, SSL-encrypted tunnel for that video generated by HomeDaemon-MCP and the app, removing the risk for video displayed through the app.  You can then absolutely block all outside access to the cameras, period, at your firewall without losing functionality.  The power consumption on the phone doing this might make you grimace due to the data rate involved but if I can figure it out the transport will be secure.  My first blush look at this is that it's not something either the stock mediaplayer or Exoplayer were designed to handle; the former is part of the framework and not designed to be modified at all, but the latter is an open-source project.  In any event it doesn't look like a "quick" thing to support, if it's even reasonable to do at all given the current state of the Android codebase.  It might not be.

I suspect the reason there is no "RTSPS" is that these cameras simply don't have the CPU horsepower to run SSL encryption for a video stream at the data rates required without puking, and fixing that would massively increase the cost of the cameras.  That makes sense but it means that every single IP camera out there right now is trivially intercepted by anyone sufficiently motivated to do so when in actual use to view video, and any connected to a cloud account gives anyone sufficiently interested a nasty and unencrypted "choke point" through which to collect enough digest information to break your password.

I repeat: As it stands right now Internet-accessible streaming cams at minimum expose the actual video in real time to anyone who cares to intercept it without any sort of real effort and any connected to a cloud service of any sort almost-certainly wind up divulging enough information to make compromise of your password and thus permanent access to same quite easy.

Psst.... if you're in the "home control and monitoring" business, or anything associated with it.... yes, the entire codebase is for sale as I've pointed out before.  Who wants to have the competitive advantage of their systems not being trivially watched by the neighborhood crook say much less organized rings of same?  Email me.....

Go to responses (registration required to post)
 

 
Comments.......
User: Not logged on
Login Register Top Blog Top Blog Topics FAQ
Showing Page 1 of 2  First12Last
User Info A MASSIVE Privacy and Security Problem in forum [Market-Ticker]
Elkad
Posts: 407
Incept: 2009-09-04

Report This As A Bad Post Add To Your Ignored User List
We need a push to better home VPNs. That means better routers (including what's built into cable modems, since that's all most people have), and a better (end-user friendly) way to setup VPNs to home on your phone.

And apps that respect working from inside the network only - without setting up the cloud crap.

Then you don't have to expose anything. Start the VPN on your phone and you are effectively inside your house from anywhere in the world. Of course there is an overhead hit to your phone and your router, but that's better than having to handle that overhead on every device.
Tickerguy
Posts: 152887
Incept: 2007-06-26
A True American Patriot!
Report This As A Bad Post Add To Your Ignored User List
Yep.

That will work just fine, and is what I can do now (and do now!)

That also means it's easy to use something like TinyCamPro to watch video in real-time (which is nice, by the way -- very lightweight, a couple bucks one-time to buy, etc) and yet is secure since the TRANSPORT is secure.

But I'm not going to be ALLOWING HomeDaemon-MCP's app to directly go after RTSP streams. No ****ing way. It's ridiculously insecure and unlike most developers I am NOT building something that is trivially easy to abuse for spying purposes.

Incidentally I have previously offered (and it's still good) to make SD cards for those little AMD-powered fanless PC modules (the "apc" ones) -- they're VERY powerful, are inexpensive (~$100 or so) and handle IPSEC/Ikev2 very nicely, and the Android StrongSwan VPN app works perfectly well with it. THAT is secure.

----------
Winding it down.

Attilahooper
Posts: 2833
Incept: 2007-08-28

New York, by way of Montreal Canada.
Report This As A Bad Post Add To Your Ignored User List
Why not allow homedaemon to connect to the rtsp stream, if your network is secure? I hit my network remotely over vpn.

----------
I've retired and bought Shecky's - Welcome, have fun, **** **** up, let's get this party started
https://www.youtube.com/watch?v=ykZbxFub....

Tickerguy
Posts: 152887
Incept: 2007-06-26
A True American Patriot!
Report This As A Bad Post Add To Your Ignored User List
It's not that simple because the Android Media player components don't appear to know how to do digest authentication at all.

In addition I definitely DO NOT want to store authentication credentials (of ANY sort) in the app, because if you do and someone steals your phone they can get into the sandbox and steal them. As the code is written right now if you steal my phone and break into it you get nothing, as there are no credentials stored at all; when you sign in originally you get an authentication cookie back from the server and the login and password you use aren't saved anywhere.

If I can find a media player interface library that understands digest authentication I can code up something to have HomeDaemon (on the server end) feed the authentication credentials to the app when a stream is requested and use them but not store them anywhere. Since you have to be signed into HomeDaemon with an appropriate permission mask AND that pathway is SSL secured that's acceptable. That doesn't get me "anywhere" use (since the RTSP stream remains unsecured) but DOES get me "in-app" use without having to store credentials.

But right now the barrier on that is the fact that the media player appears to not understand digest authentication on RTSP at all. Unfortunately since Android's mediaplayer is part of the base OS it can't be grabbed, hacked on and modified -- which sort of sucks, but is what it is. The alternative EVO isn't in the base framework but doesn't understand RTSP at all which is even worse (teaching it THAT would be a ****-ton of work.)

Doing this right without leaving a gaping security hole SOMEWHERE isn't trivial, in short, which is likely why all the existing "camera viewer" apps simply don't bother and say "**** the security implications."

As it stands you can only get to my cams from inside, which means when connected to the VPN. If that constraint remains (e.g. I can't tunnel through HomeDaemon-MCP's server-side on the Pi since I can't connect an arbitrary stream to the media player components in Android) then there's no reason to embed the capability in the app at all since TinyCamPro can already get at the cam streams when the VPN is up.

But I still can get the images (stills) securely -- that capability is already there, since it works from the web interface and it's just a matter of fetching the correct URL from the server, which already does the proper authentication to make sure you're supposed to be able to get it, and runs over SSL.

----------
Winding it down.

Redbrian
Posts: 35
Incept: 2010-06-25


Banned
Report This As A Bad Post Add To Your Ignored User List
Way too much trust in technology these days...

"On Twitter, Nests support account shared the news of outage reports at 11:30pm ET, informing customers with Nest Secure and Nest x Yale Lock devices about the inability to arm their alarms or lock or unlock doors using the app."

https://gizmodo.com/nest-devices-went-of....
Tickerguy
Posts: 152887
Incept: 2007-06-26
A True American Patriot!
Report This As A Bad Post Add To Your Ignored User List
And this is why you do NOT want centralized, "cloud" control -- with HomeDaemon as long as the network itself is working so does your connection.

In an extreme case where the Internet is down if you get close enough to the house to get a WiFi connection to the house with your phone the app still works just fine.

----------
Winding it down.
Oldno7
Posts: 2653
Incept: 2008-11-14

RECALL STATE USA
Online
Report This As A Bad Post Add To Your Ignored User List
Probably off topic and maybe not. We finally broke down and got smart phones because my wife has friends that insist on texting her. So the wife goes into Steins to buy some plants and when she gets home she goes to shut down her phone and there is a message for her to comment on her experience at Steins. Not sure if her phone was off or on during her visit. If it were up to me I would trash these phones but all men know we have nothing to say about these things just yes honey that's just fine!!!

----------
IT'S THE SPENDING STUPID The US must become less a government of men, and more a government of LAW.When people lose everything and have nothing left to lose they lose it -Gerald Celente
Tickerguy
Posts: 152887
Incept: 2007-06-26
A True American Patriot!
Report This As A Bad Post Add To Your Ignored User List
It was likely on and location enabled. TURN LOCATION OFF when not ACTIVELY using mapping functions (e.g. driving with directions from the GPS.)

If you don't you WILL get this sort of horse**** all the ****ing time, and in addition Google is tracking EVERY SINGLE PLACE you go, EVERY SINGLE MINUTE of every day.

----------
Winding it down.
Oldno7
Posts: 2653
Incept: 2008-11-14

RECALL STATE USA
Online
Report This As A Bad Post Add To Your Ignored User List
Karl, I will give that a try but if I remember right years ago all cell phones had to have GPS so 911 calls could to tracked. So is it even possible to turn it off?

----------
IT'S THE SPENDING STUPID The US must become less a government of men, and more a government of LAW.When people lose everything and have nothing left to lose they lose it -Gerald Celente
Tickerguy
Posts: 152887
Incept: 2007-06-26
A True American Patriot!
Report This As A Bad Post Add To Your Ignored User List
The cell chip turns it back on (there are callbacks in the RIL layer that you MUST honor -- "or else") if you dial 911.

Is Google probably still grabbing it? Likely. It's not like lying gets you in trouble these days, right?

----------
Winding it down.
Oldno7
Posts: 2653
Incept: 2008-11-14

RECALL STATE USA
Online
Report This As A Bad Post Add To Your Ignored User List
Thanks Karl
This will be easy to check out anyway so it will be fun trying.

----------
IT'S THE SPENDING STUPID The US must become less a government of men, and more a government of LAW.When people lose everything and have nothing left to lose they lose it -Gerald Celente
Thystra
Posts: 1004
Incept: 2009-07-12

Around the World
Report This As A Bad Post Add To Your Ignored User List
I had hopes for the Ubuntu phone and blackberry. Sadly neither worked out.
Tickerguy
Posts: 152887
Incept: 2007-06-26
A True American Patriot!
Report This As A Bad Post Add To Your Ignored User List
The problem is the apps -- without the buy-in to build those, the odds are zero.

----------
Winding it down.
Ckaminski
Posts: 4639
Incept: 2011-04-08

Mass-Hole!
Report This As A Bad Post Add To Your Ignored User List
Ubuntu Mobile had bigger problems - the X interface is a giant ****ing boat anchor. Supporting it gets you a ****load of apps "by default", but supporting it is a PITA in touch interfaces, plus there's a legacy of remote-access code that needs to be purged for mobile devices.

Not supporting it and doing something else means getting a clean slate, but also means porting way too many apps. It's not the right time for a dedicated mobile Linux - if the push to the Wayland compositor can get it's **** together, and dump X style remoting, instead going to ssh-tunnel framebuffer capture, maybe, just maybe this problem is fixed on desktop and mobile and they can try again.

Blackberry... that's just a travesty. Maybe if they'd spent less money on building phones and focusing on the software, which is pretty much what happened in the end..

We haven't heard the last of Ubuntu Mobile, methinks. Just not for a while.
Tickerguy
Posts: 152887
Incept: 2007-06-26
A True American Patriot!
Report This As A Bad Post Add To Your Ignored User List
Well don't get me started on the Android thing.... while it "makes it easy" it also makes it stupid, as I've learned in a big hurry....

----------
Winding it down.
Djloche
Posts: 3757
Incept: 2008-07-07

Vancouver, WA
Report This As A Bad Post Add To Your Ignored User List
Between things like this popping up on neighbors doors that I routinely walk by, and the recent confirmation that the phone carriers are selling access to location data to third parties with terrible security practices, i Definitely need to spend a week or two in the woods disconnected.

The idiocy of that "LocationSmart" "bug" that would let anyone ping any cell phone and get the real time location, that had been on the site since for at least a year, of course that's just the bug of getting past the paywall, you can pay them money and get access to their tools - lots of companies buying location data / access to it, and the cell service providers hand over the keys to the kingdom with a cheery smile for a small fee
smiley

----------
"The Constitution is the IDE. The 2nd Amendment is the debugger."
Tickerguy
Posts: 152887
Incept: 2007-06-26
A True American Patriot!
Report This As A Bad Post Add To Your Ignored User List
I've got the webcam security problem 100% solved for a 50% answer (in other words, not the best quality or lowest-bandwidth, but it'll work.)

Coding now.... and yeah, the price on HomeDaemon just went up a bit, as it now does what nothing else on the market does -- it makes your inexpensive IP webcam SAFE to use from ANYWHERE and impossible to intercept both the credentials (since they are NEVER on your phone) and FULLY ENCRYPTS the data stream -- for cameras that have NO support for any of that internally, and never will.

Bingo.

----------
Winding it down.

Attilahooper
Posts: 2833
Incept: 2007-08-28

New York, by way of Montreal Canada.
Report This As A Bad Post Add To Your Ignored User List
^That didn't take long^ Very cool KD. Buffering the stream and encrypting on the fly in homedaemon?

----------
I've retired and bought Shecky's - Welcome, have fun, **** **** up, let's get this party started
https://www.youtube.com/watch?v=ykZbxFub....

Tickerguy
Posts: 152887
Incept: 2007-06-26
A True American Patriot!
Report This As A Bad Post Add To Your Ignored User List
Credentials are in the base (on your premises), you already authenticate in the app so I already have a voidable (and volatile) credential; there's code to write for the base but the premise on which it will work is now known good.

In the future I should be able to extend it for lower bandwidth consumption and higher quality; there are serious problems that remain with that and more work to do before that's fully supportable but half a loaf (fully secure) is better than none and doesn't require you set up a full-blown VPN (which for most people is a bridge too far; it's somewhat of a pain in the ass, never mind requiring a machine with some decent moxie behind it, which the Pi just doesn't have -- you want a CPU with AES instructions in it.)

There is a SEVERE bug in digest authentication for Android that made a pure pass-through impossible to make work (they're ****ing up the URI which means the digest fails!) and who knows if or when Google will fix it. Never mind that digest authentication is insecure itself but wrapping that is no good if it doesn't work once you do!

----------
Winding it down.

Asimov
Posts: 109862
Incept: 2007-08-26

East Tennessee Eastern Time
Report This As A Bad Post Add To Your Ignored User List
Wow. Nice.

----------
It's justifiably immoral to deal morally with an immoral entity.

Festina lente.
Tickerguy
Posts: 152887
Incept: 2007-06-26
A True American Patriot!
Report This As A Bad Post Add To Your Ignored User List
Yeah we'll see how it performs once I get it going. Unknown right now if it'll be "good enough" performance-wise. It SHOULD be, but.....

Maybe later today depending on whether I decide to break out some single-malt later...... smiley

----------
Winding it down.

Asimov
Posts: 109862
Incept: 2007-08-26

East Tennessee Eastern Time
Report This As A Bad Post Add To Your Ignored User List
What would keep you from selling kits with license fees for the software? Or even free for personal use but license any commercial venture?

Keep the business to just a couple employees?

----------
It's justifiably immoral to deal morally with an immoral entity.

Festina lente.
Tickerguy
Posts: 152887
Incept: 2007-06-26
A True American Patriot!
Report This As A Bad Post Add To Your Ignored User List
Nothing other than my willingness (or not) to stand up said business.

I'm simply not interested in doing it, but SOMEONE ought to be, especially with all the hard work done!

----------
Winding it down.
Asimov
Posts: 109862
Incept: 2007-08-26

East Tennessee Eastern Time
Report This As A Bad Post Add To Your Ignored User List
I had been thinking quite a bit bigger - I think it just dawned on me how small it could be and still be reasonably viable.

----------
It's justifiably immoral to deal morally with an immoral entity.

Festina lente.
Login Register Top Blog Top Blog Topics FAQ
Showing Page 1 of 2  First12Last