The Market Ticker
Commentary on The Capital Markets- Category [Small Business]
Logging in or registering will improve your experience here
Main Navigation
MUST-READ Selection(s):
Cut The Crap - NOW

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.

2019-02-01 10:12 by Karl Denninger
in Small Business , 197 references
[Comments enabled]  

Those who sell their souls to the Devil have little to complain about when he shows up without a jar of KY to go with what he intends to do to you.

Arjun Sud was standing outside his son Oliver’s Door Sunday when he heard that voice. He burst in. The voice stopped. He and his wife chalked it up to baby monitor interference. But once downstairs, they heard the voice again.

It was an unseen intruder talking to them through their Nest security camera, using obscenities including the ‘N’ word.

“Asking me, you know, why I’m looking at him because he saw obviously that I was looking back and continuing to taunt me,” he said.

“It was terrifying,” Sud’s wife Jessica said.

Sud says once his shock subsided he composed himself enough to record part of the ominous exchange.

Sud believes the hacker also turned their upstairs thermostat to 90 degrees. He noticed that potential danger to their baby the same night.

“And then they messed with our thermostat,” Jessica said. “Who does that?”

Uh, you are the idiot that connected your house to a "cloud" -- that is, a computer owned by someone else.

It's not like you didn't know in advance that these companies make their money using your data to screw you in one form or another -- even if it's just 'selling advertising.'

smiley

Of course the companies always claim it's the customer's fault -- they didn't use a good password, they didn't use 2-factor authentication, etc.  This ignores the reality of the situation, which is both simpler and more-complex.

The simple side is this: These firms make their money off selling data they accumulate on you.  Security is not their first thought or they wouldn't connect such things as your thermostat to the "cloud" at all; they'd design them to be very secure and talk only to your specific devices such as your phone.

But then they wouldn't be able to use that data themselves.

You can bet they intend to -- and are.  Just read this:

We should recognize this pattern: Tech that seems like an obvious good can develop darker dimensions as capabilities improve and data shifts into new hands. A terms-of-service update, a face-recognition upgrade or a hack could turn your doorbell into a privacy invasion you didn’t see coming.

Last month, Ring got caught allowing its team in Ukraine to view and annotate certain user videos; the company says it only looks at publicly shared videos and those from Ring owners who provide consent. Just last week, a California family’s Nest camera let a hacker take over and broadcast fake audio warnings about a missile attack, not to mention peer in on them, when they used a weak password.

Why do you think these folks all design their software and "products" to have a business model that costs them money on an ongoing, perpetual basis?  Computers are not free and neither is storage.  What possible purpose does imposing a cost model on themselves on a perpetual forward basis for said "cloud connections" have unless they are going to use it to screw you in some form or fashion?

It's not necessary for anything more than a licensing check or similar, and that contains nothing of value to a hacker provided the payment information for said license is secured properly (or not even present on that system, which it doesn't have to be.)  There's simply no reason at all to have that data and a back-channel to connect to your house in the "cloud" in terms of access for you; your phone or laptop can simply connect directly back to your house via a secured, SSL-enabled connection and if it was designed that way the only place the data would be is in your house and on your phone.

Instead these "cloud folks" try to sell you "convenience" that isn't really any more convenient at all!

HomeDaemon-MCP provides you remote access to everything in your home that you wish to look at and control along with alarms and similar in real time without any "cloud" involvement.  Yet if you want real-time video from your camera(s), you can see it.  If you want to grab a segment to your phone (directly, not to a cloud computer) you can do that on command.  If you want to adjust your thermostat, you can.  See when someone was last in a room, sure.

But nobody has that data except you, because it's not stored anywhere except on the little credit-card size computer in your house and is only transmitted to your device(s), such as your phone, when they are connected -- and nowhere else.  No cloud, no company mining your data looking for patterns it can sell things to you based on and nobody spying on you either.

I just closed on my late mother's estate (house.)  Her place was built almost-literally on a swamp (along with many others in the neighborhood) and had a full basement, which means a sump pump that had better not, ever, quit working.  Then there's the usual issues when you're not there all the time -- especially in the winter, where loss of heating (e.g. something as simple as a burned-out igniter in the furnace) means frozen pipes and a god-awful amount of damage.

HomeDaemon-MCP took care of all of that, in addition to my home here in Florida.  The sump pump was checked with a plug module that reported power usage.  It thus became trivially simple to know how often it was cycling, for starters.  In addition setting alarm points for the pump being on for too long (a sump pump should never actually run for more than a few seconds per cycle) or excessive power consumption (indicating either a blocked -- like frozen -- outlet or a locked rotor, that is, a failed pump) raised immediate and very loud alarms on my phone.  Finally, a water sensor probe down the volute above the normal level was there -- just in case everything else looked ok but the water wasn't actually being pumped.

Then in the main living space a CO/Fire detector that also talked to the system was put up (battery powered), covering that possibility, and finally a thermostat.  The latter not only made for a big reduction in power consumption when nobody was there but also allowed for trivial monitoring for the situation where it's winter and the furnace breaks, in that too-low temperature would cause an immediate alarm too.

Icing on the cake was the ability to have and look at 24x7 video feeds if desired, and knowing when motion was last detected, so if someone broke a window, well, that was covered too.

I've been living there about half the time since September; the same issue of course arises for anyone else who has a vacation or second home -- or if you just go to work 8 hours a day.  You're not there all the time and it's nice to know that all is well -- and be immediately told if it isn't.

No cloud, no bullcrap, nobody gets in except me -- and notification is effectively immediate (60 seconds or less) if something happens.  In addition should I want to let someone in (e.g. a Realtor) I can -- remotely, with the push of a button, and know if/when someone does come in, even using a key.

Want to disrupt this space?  The marketing material writes itself with stories like this cited one above, of which there are plenty already and will be more.

Email me -- contact info is to the right.

View this entry with comments (opens new window)
 



2018-11-07 06:57 by Karl Denninger
in Small Business , 51 references
[Comments enabled]  

So about those locks.....

 

One of the challenges I've had with allowing the manipulation of lock state (other than lock/unlock, or setting the keypad on or off) is the risk of someone picking off a code from your phone -- and then being able to break into your house.  For obvious reasons that would be bad.

I've decided to leverage the notification system built into the software for this purpose.  This has several advantages, chief among them being that neither the phone or the base software has to store a code from a lock in any case.

If you select "Get Code in Slot" and enter the slot number when you click Execute HomeDaemon-MCP retrieves the code in real time over the AES-encrypted channel from the lock and sends it back to your device via the encrypted notification system.  It never touches anything else (like the cloud) and is not stored anywhere other than in RAM on the device when displayed in the notification pane, which can be dismissed.  In addition there is no storage off-site, anywhere, of the event itself either so Mr. Subpoena (or "Mr. NSL") can pound sand since nobody can produce what they don't have.

If you set a code it is transmitted to the lock.  Ditto for deleting a code.

Codes on most common locks (they're all using the same basic board) can be 4 to 8 numeric digits.  8 is quite secure; 4, not so much, although after a few (wrong) attempts the lock will raise an alarm exception.  In all cases when the change "takes" an exception is raised back to the phone, so you know it went through, exactly as is the case for an asynchronous event (e.g. someone uses the code to open the lock.)

Disabling the keypad locks out all the codes, instantly (very useful if you're not at home, don't expect to be home, and don't want anyone to be able to open the door.)  The state of the lock in the background is currently set this way ("Prohibited" .vs. "Accessible.")  Oh, and the manual operation of the lock (e.g. with a key or the inside knob) is also instantly reported.

Again -- no cloud, no BeeEss, no stealing.

HomeDaemon-MCP is available to the firm, large or small, that wants to disrupt the model of "smart home" systems.  All rights, source and all, to both the base code running on a $35 piece of hardware and the Android app are included.  Look to the right and email me today!

View this entry with comments (opens new window)
 

2018-10-16 15:34 by Karl Denninger
in Small Business , 119 references
[Comments enabled]  

HomeDaemon-MCP's Android App now knows how to handle multiple locations at once -- with always-on 24x7 monitoring and control from anywhere, without any cloud involvement.

 

Got a rental house plus your own residence?  Vacation home?  Three properties?  Five?  Need to be able to open the front door for a property manager in real-time to show a rental -- and know if someone uses a 
key to lock or unlock the front door in real-time as well?  No problem.

In addition the license server now populates the HomeDaemon.Org domain automatically when a license registers or renews, and as a result for those who don't have a convenient "dynamic dns" provider, or don't wish to set one up you no longer need to -- the software does it for when the license is validated.  While this is not instant response if your IP number changes but connectivity does not go down or the unit resets (e.g. power goes off) it is convenient and "no setup required."

You may suspend monitoring on any declared host if you wish at any time, and then turn it back on without altering the others, or having to re-enter a password.  As has been the case thus far in the app's development cycle no passwords are saved, ever in the app itself or in the app's data store.

Power consumption with full-time monitoring enabled and your phone sleeping continues to be negligible -- and yet no cloud management or storage tools are used anywhere in the application.  Nobody gets your data but you -- ever -- on your house. Not your coming and going, not the motion, your thermostat or camera data.

It's yours, and only yours.

Again HomeDaemon-MCP is for sale as a complete, ready-to-go package needing only to have the customer front-end set up to meet your desired licensing scheme.  All rights are available at a very reasonable price -- contact me today if you're interested (and of course can fund the acquisition) and we'll move forward!

View this entry with comments (opens new window)
 

2018-05-14 14:28 by Karl Denninger
in Small Business , 121 references
[Comments enabled]  

Well, that wasn't all that hard.

I've never previously written a single line of Java, nor developed for Android.  Ported Android itself, yes, but not written apps -- nor used "Android Studio", Google's IDE for it.

A few weeks ago I bought the "Big Nerd Ranch" book on it, and read it.  It's a solid couple inches thick and, if you've never done programming, you'll be lost in the first half-dozen pages.  Figuring out Java at the same time was quite a trick (and one the authors warn against), but being a guy I don't read instructions anyway.

 

But now Beastie (yes, phk, the beer is on me if we are co-resident somewhere) peeks out the window, and the App lives.

 

I find some of the admonitions from Google rather amusing.  They really want you to use their cloud message management system rather than exempt your app from their battery sleep/doze stuff, for example.  I understand why, in many cases, but, in this specific case.... nope, nope and nope.  The impact on power consumption?  Nearly unmeasurable over a full night's sleep with the phone unplugged; according to GSAM consumption is about 1% over 8 hours.

A couple of weeks post-sitting down with this monstrosity and there's an app, complete with power management, background networking, preferences and all that.

HomeDaemon-MCP itself (the server/operational piece) has been taught how to do persistent notifications to mobiles as well, which is very nice.  What that means is that if you "miss one" because you're out of range (for example) as soon as you come back into range you'll get the notification.  Ditto if your phone reboots.  This also means that the complexity of said notifications can be infinite, and is subject to user permissions.

Speaking of which that's one of the big deals.  Multiple users with different permission bit masks are fully supported down to an individual device level for both read and write access flags.

I don't know if I prefer the app over the web interface for HomeDaemon-MCP, to be honest.  The app has its advantages on a phone, not the least of which is its persistence and notification capabilities.  That's real nice; what I used to do for notifications was to have the base system send a text message.  That works of course but this is nicer, easier to customize (choose your tone, do you want vibration or just sound, etc) more-granular, and has less risk of getting lost (yes, carriers do lose text messages on a somewhat-regular basis.)

The "about" page can be read here for the app... I think you'll like it.

If you do, and want to pick up the whole package -- including the App -- for marketing and sale of course, the email link is on the right.  No cloud used, security is completely under the owner's control and licensing is done with privately-CA-issued certificates -- which are damn near bomb-proof and enable both buy-once-use-forever models as well as annual or even monthly subscription-type licenses.  You choose.  And yes, the price for the whole shooting match is reasonable.

View this entry with comments (opens new window)
 

2018-04-07 12:26 by Karl Denninger
in Small Business , 115 references
[Comments enabled]  

You might have read this article when I published it originally.

Or, maybe not.

If not, then please do.  It lays out a pretty decent case, I think.

What I've now completed is the majority of the back-end work to make implementing a mobile app a rather trivial piece of coding -- instead of a lot of work.

Let me lay out the how and why for you on this.

The "hard way" to do a mobile app is to have it do all the work.  The easy way, every time, is for the mobile app to be little more than a terminal into something.

But this is a problem in the general sense even when there's a web server included because you then have to parse the web output.  That's somewhat of a pain in the ass.  So what you need to make mobile app development easy is a trivially-parsable reply format, preferably one that updates in real time for you.

HTML5 makes "dynamic updates" pretty easy, which is nice.  You send down a little javascript "listener" and then make a call to a resource that comes back with the MIME type "text/event-stream", and then sends updates.  Each has a tag, which matches that tag in your HTML document.  This connection can be (and should be!) persistent, in that this reduces overhead greatly.

Well, that's nice, but the persistence can be a problem from a resource consumption and management standpoint.  If you're not particularly persistent then the "retry" stanza will reconnect, so many pages and servers do exactly that -- they send the data but then allow the connection to close, relying on the connection cache ("Connection: keep-alive")  to cut down the overhead to something reasonable.  This will give you "every 3-5 seconds" updates -- good enough for most implementations such as social media and messaging.

What you want with an app, however, is an actual dynamic stream that stays open for minutes at a time because otherwise the overhead is a five-alarm pain in the butt.  Implementing true persistence on the server end gives you the ability to push updates as fast as you're willing to burn the CPU to handle.  You can get single-digit millisecond latencies (or better) if you are willing to burn the CPU for it, but getting latencies down into the couple hundred millisecond range, or ten to twenty times faster is an utterly-trivial exercise and actually cuts load since connection renegotiation frequency goes down enormously.

HomeDaemon did the first, until now.  It now has had the web code refactored to implement the second, which means that it is now very easy to add to the web backend a specific calling sequence that will output a table of units with locations, names, types and similar parameters followed by a stream of updates of status with one call that is nothing more than a glorified "GET" instance, and key it all off a given security level to match the user's privilege set.  Since SSL is in play the call (with authentication) and reply, plus the data stream that comes is secure.  And since the lifetime of a connection is now minutes where after the initial burst updates of status take just a few tens of bytes the overhead becomes extremely small -- which is fabulous both for data and power consumption on a handheld.

So there's no app for Android -- yet.  But the predicate for the back-end support for one is now 80% complete with the other 20% in process.  Yeah, implementing that was a five-alarm pain in the ass -- but now it's done.

After the back end is complete, along with the calling sequence, I'm going to teach myself how to write Android apps.

And yeah, somewhere between now and the endpoint of that the asking price is going to go way up for all the obvious reasons, so if you believe in the "MAGA" stuff and want to prove me wrong then get rich at the same time -- read this article again, then contact me.

View this entry with comments (opens new window)