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):
There Can Be NO Compromise On Data

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-11-07 06:57 by Karl Denninger
in Small Business , 50 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)
 



See, I told you so....

Nearly every day, after school, this mother, who asked PIX11 to hide her identity, said her 5-year-old son chats with her husband through the Nest cam, a home monitoring system users can connect through their cell phones.  This time, however, it was a complete stranger on the other end.

“He asked my son if he took the school bus home and he was asking him about the toys he was playing with and when my son said 'mommy, mommy,' he told him to shut up,” she recalled.

When she walked into her child’s playroom, the ominous voice addressed her directly.

Now she’s frightened and wonders how long a complete stranger was watching her family. Since this frightening violation, this mother called police, who, while sympathetic, said there was little they could do.

Nest, of course, claims there's no hacking involved and someone's password was compromised.

Uh huh.

Where was it compromised?

Nest claims that this has happened due to people losing passwords on "other sites", but then says this:

We are proactively alerting affected customers to reset their passwords and set up two-factor authentication, which adds another layer of account security. 

If the breach didn't involve the cloud-based system in question how do they know who is affected?

This is why if you're going to have something like this in your house you want the connection to be directly between your devices - never in a "cloud" environment, ever, period, end of discussion.

Which is exactly what HomeDaemon-MCP was designed from the ground up to accomplish.

Break the glass, disrupt the model.  Buy it out and have at it - email me for details using the contact info on the right.

View this entry with comments (opens new window)
 

2018-10-16 15:34 by Karl Denninger
in Small Business , 117 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)