The Market Ticker
Commentary on The Capital Markets- Category [Technology]

This article is amusing to me....

Randall Rothenberg doesn’t want anyone to forget the dangers posed by software that hides online advertising. Rothenberg, who runs the Interactive Advertising Bureau, gave a scathing speech at an industry conference this week in which he accused ad blockers of “stealing from publishers, subverting freedom of the press, operating a business model predicated on censorship of content, and ultimately forcing customers to pay more money for less—and less diverse—information.”

Rothenberg said publishers have begun to fight back with their own technology designed to disrupt ad blocking software and encourage readers to either turn the blockers off or pay for content. Readers should be forgiven for not noticing that this battle is happening.

I have a simple solution to this -- those media properties that insist on slamming me with ads and data mining are media properties that I don't need to use -- and won't.

I see both sides of this, of course, since The Market Ticker runs on advertising.  Unobtrusive, on-the-sidebar advertising.

Unfortunately the sort of "interweaved" and "pop-over" or through advertising is more and more common and what's worse, by far, is that some of those properties go even further and have tried to load malware on my machine when I shut the blocker off.

Forbes is one of those sites I no longer read for this reason.

This is not a new problem.  And let's face it -- advertising is content, and when I use Google's Adwords I am placing their content on my page.  Now yes, it comes from Google, but if Google either will not or does not police said content such that when it's on my site my readers are exposed to some sort of nefarious crap should I be surprised when folks think it's my problem?  After all, they didn't go to Google, they came to The Market Ticker.

But this belies part of the problem because Google doesn't, as is commonly thought, serve all its own ads.  In fact Adwords interconnects with a huge number of other "partner" networks, yet all are billed and sent through Google.  Who's responsible?

I've yet to have a serious issue with Adwords in this regard, but when it comes to other ad networks it's a different story.  There are even many of them that insist on delivering their ads without https; which means that my usual and customary practice of allowing anyone to use https (and in fact pinning the site to secure mode if you do use it, even once) instantly removes them from consideration as a competitor.

The ads -vs- blocking thing isn't going away.  I've certainly toyed with the idea of forbidding readers from coming in here with ad blockers turned on, but thus far I've decided not to.

Advertising, provided that its not intrusive and (1) doesn't attempt to misrepresent itself as content that is organic, that is, is clearly delineated and distinguished as advertising such as being on the side bar (incidentally all Facebook ads violate this stricture), (2) consumes a modest and thus immaterial amount of bandwidth and time compared to the content being sought, which specifically bars any non-asked for display of things such as video and/or audio (no, mouse-overs don't count) and (3) does not attempt to load anything persistent on the user's machine, including pop-under or "hidden" content, is in my view perfectly ok and a legitimate means of generating revenue with online content.

Violate any of the three above, however, and most sites do including a lot of the big ones, and I will refuse to add you to the exception list.  If you won't let me in without that and yet won't conform to the three points above as far as I'm concerned at best you're a thief trying to force me to pay for the delivery of your message and at worst you're a cyberterrorist and I want nothing to do with you.

View this entry with comments (registration required to post)

2016-01-28 08:11 by Karl Denninger
in Technology , 204 references

Gizmodo has really stepped in this one....

Good news from the world of online security: Oracle, developer of the Java plugin that has been making browsers insecure since 1995, has finally announced that it’s sending it six feet under.


More importantly, Java is a terrible blight on our computer security that must be stopped at all costs. Everyone from independent developers to theDepartment of Homeland Security have **** on Java for opening up access to a billion computers thanks to zero-day programming bugs. So long, Java; we won’t miss you.

Well you might not miss it Gizmodo, but I'll tell you who will: Anyone who currently uses remote-access KVMs and other similar tools.

Why?  They're nearly all Java-based.

Oh by the way, who uses that stuff?  Virtually everyone that has server-class (you know, "real computers") hardware deployed in the field at various places like colocation facilities and similar.

This announcement will (obviously) drive companies to change their tune on remote management, probably moving it to HTML5.  But that's not an overnight proposition; I have implemented a full-HTML5 streaming system for my home control software but doing it on a not-necessarily-text basis (which a KVM of necessity is) turns into a materially-more difficult thing to accomplish.

The bigger backstory is how this "language" managed to get so bloated and so insecure that actually fixing it became an unreasonable task.

But that's a backstory you will not hear because it is an indictment of "computer language bloat" -- an argument I've made repeatedly over the years, and which reaches deeply into the world of computer programming today including, most-particularly, all those "rapid" languages that have proliferated over the last ten or fifteen years.  There's a reason I write nearly all of my code in C, even today......

This is going to be interesting to watch and probably not in a good sort of way either.

View this entry with comments (registration required to post)

While doing some "hardness tests" on my re-write of my home control software (since it can be "seen" by the Internet) I found a number of rather-interesting things out when it comes to OpenSSL-related programming.

Some of these might explain some of the problems with various "Denial of Service" attacks and other misbehavior seen around the 'Net in general.

I don't know that I can actually blame anyone for this, other than software authors not checking the "hardness" of their software before they ship it.  But there are some real problems exposed by some of the "field tests" that you can use, and the programming requirements to mitigate them are not instantly obvious -- nor are they the defaults.

The latter makes it easy to miss, if you don't explicitly test for such things.

One of the more-serious "denial of service" problems, for example, is the fact that by default OpenSSL will allow either a client or server to initiate a protocol renegotiation.  This sounds like something that's generally good, but there's a problem -- it requires a lot more resource on the server to renegotiate a session than on the client end.  Like more than 10 times as much, to be specific.  Further, it's trivial to ask for a renegotiation (meaning that code to do that repeatedly on a malicious basis takes about 30 seconds to write.)

This is very bad because any random jackass can point said code at your site and take it offline or dramatically slow it down by hammering it, even with a little itty-bitty PC on their end!

Preventing that particular attack from working means you must detect the renegotiation and drop the connection if someone tries to hammer you; this requires a bit more code than a simple setting of a flag that says "don't allow that", and if you don't know this is a serious risk and/or simply don't care.....

It gets even worse with a lot of so-called "Web-enabled" things.  I've got a few here, and I'll say this: Most should not be anywhere near the public Internet.

A few, like modern webcams with updated firmware, are only somewhat dangerous.  They're dangerous because they include poor ciphers that can be trivially picked off, but there may be a valid reason for that -- if they're sold in a market where strong crypto is illegal, there's no other option.  In addition some include Diffie-Hellman keying options with weak keys which is sort of like putting a lock-picking manual right next to your front door -- with a set of picks.  These products should expose their cipher settings so you can change them and disable the stupid if you live somewhere it's legal.

But.... they don't.

Others, which I will not name for obvious reasons, are far worse in that they enable ciphers known to be subject to either outright breakage or Man-in-the-Middle attack.

I only found a couple of things that needed improvement in the code I have written, and all were able to be hardened right up.  But if you've got a device out there that plugs into the Internet, and you bought it from someone, you probably don't even know what questions to ask of them in this regard, or how to test it.

That's bad.  If it's a security-related product or one that could damage your property if misused (e.g. a thermostat or a device that controls something dangerous if turned on or off inappropriately) it could be ruinously bad.

I've written on the so-called "Internet of Things" issues before, but this little exercise, including testing some pretty-recent stuff found "in the wild", gives me great cause for concern.

Be careful what you plug in if it does something, or can do something, that matters to your safety or privacy in the real world.  Oh by the way, when it comes to things in your house -- that's pretty-much anything.

View this entry with comments (registration required to post)

This is not "new news."  It has been circulating around for a while; I became aware of it quite a bit ago, but declined to write on it originally as it was a big fat nothingburger.  I'll get into why in a minute, but there are a bunch of screaming idiots who just will not stop when it comes to privacy and security issues, nor when it comes to taking cheap (and unearned) shots at firms, whether it be Google or BlackBerry.  (As an aside these same idiots also cheer crapfaces like Apple who make similarly-worthless claims on the other side of the issue!)

A Dutch police unit has confirmed to the BBC that it can decrypt messages on Blackberry's most secure smartphones.

It did not go into details about how it does this but said that its methods allow police to read messages.

Troubled phonemaker Blackberry has prided itself on providing customers with one of the safest methods of communication.

First, this is in relationship to older (BBOS7) handsets.

Second, the handsets in question were being sold by vendors who had added their own code to the handset, which obviously leads one to question whether the problem even has anything at all to do with BlackBerry itself.

Third, apparently this "secure" service includes the use of a custom (run by them) BES server.  As I've pointed out repeatedly when you use someone else's certificate and "secure" transport facilities you are trusting themif they are not trustworthy and give away the keys to the store you're screwed and you won't even know it happened until it's too late.

It is extremely likely that the "compromise" involves one or more of the following:

1. Arm-twisting.  If the firm that did the "modification and resale" can be shown to have intentionally marketed to a "criminal element" then you simply threaten to prosecute the firm's officers unless they turn over the keys.  That was easy.  (This is just a mild variation on the old "Oh, you won't give me the password eh? Well sir, may I introduce you to Mr. Vicegrips for your fingernails" game....)

2. A foolish (or technically incompetent) choice by the modifier.  There's a lot of bad code out there.  Some because people don't understand yet put themselves out as "experts", some due to simple errors (humans commit mistakes), some due to use of deliberately-poisoned code (either through subterfuge or foolish trust) or similar.  Compromise of someone in the chain of trust for the BES server, by the way, counts.

3. A heretofore undisclosed vulnerability in the base code.  The least-likely, but possible scenario.  Again, these are older handsets; it's certainly possible there's a weakness in the code somewhere.  But I'll put my money on #1 or #2.

In any event since these are handsets being resold after being modified with someone else's "enhancement" it's very unlikely that this is actually about BlackBerry at all.

But it does make for good clickbait -- and bashing -- material, even if it's flat-out false.

PS: If you're a serious crook -- serious enough that governments come after you in this sort of fashion -- you really need to rethink trusting some third-party company that claims they have something "better" or "more-secure."  Insisting on strict proof might be a good idea, given that governments tend to have resources available to them that the ordinary thug or jackass (of which you are) does not.

View this entry with comments (registration required to post)

Oh my, this is what you deserve when you trust the so-called "Flashy Crap" that corporate America wants to sell you...

A Nest software update in December came with a hidden surprise: a bug that drains the thermostat's battery and ultimately deactivates the device. Users were caught by surprise, and in the case of The New York Times writer Nick Bilton, he woke up to a cold home when his Nest switched off in the middle of the night. The Google-owned company's co-founder, Matt Rogers, confirmed to NYT that the cause was a software glitch that didn't manifest itself until January. The complaints posted on Twitter and on Nest's own forum support that statement.

Yeah, this is really cute.

So your thermostat stops working, despite the fact that a thermostat has a 24VAC power supply connected to it that works whenever the AC power is on.  Your furnace (and/or AC unit) provides that; it's what runs the furnace and AC control systems in the unit itself, and that power is provided to the thermostat.

So how come the "Nest" ran "batteries" down and shut off?  Because someone got "cute" in the design, that's why, and forgot that a thermostat serves not a "comfort" function first but a life and property safety function, particularly in the winter months.

See, in the winter if your thermostat fails and you're not home your pipes freeze and the resulting damage costs thousands to fix on a good day and might total your house.

There's always risk of mechanical failure.  The blower motor in your furnace might puke, or the gas valve fail, or the igniter not ignite (which, incidentally, is one reason I hate the so-called 'hot-surface' igniters that have become all the rage rather than spark igniters -- the hot-surface ones not only fail catastrophically without warning they cannot be bypassed on a one-time basis.  A spark igniter can be, so you can use a BBQ lighter to get the furnace going once, heat the house, repeat as needed until you can get a new igniter.  Not so with the hot-surface models since the controller will refuse to open the gas valve unless it "sees" the igniter drawing the correct amount of current.)

But this is a particularly egregious fault because there's no real reason for it other than a vendor getting cute.  Batteries for backup purposes in a thermostat are fine but they should never be necessary for primary power because the unit always has 24VAC available to it.

My home is controlled by automation -- automation that I built.  The thermostat is indeed "smart" enabled, in that it talks Zwave.  But, if the controller disappears it will continue to work as an ordinary thermostat, requiring exactly nothing to do so, as it was last set, since it gets its power from the HVAC system and while it can report to the controller and take commands from it, it runs perfectly fine without anything talking to it at all.

Likewise, the pool equipment here has potential property-damaging implications, especially if it gets too cold.  Like plumbing in a house freezing weather can split pipes, so in such weather the pump must remain on so water is flowing (moving water does not freeze nearly as readily, and the pool itself is a reservoir of water above the freeze point, so as long as you're exchanging it will take a long time before it freezes up.)  As a result the controller that I implemented to run that gear will run autonomously without the master, and it is powered from the same power that runs the pump.  So long as there is AC power available the pump will work, and if the controller fails the last commanded state is retained -- again, as long as there is power.  (There is also a programmable function in the VFD drive for the motor itself that will run the pump if the temperature gets low enough should communication be lost.)

Thinking this through is part of intelligent design and yet it appears that such takes a back seat to being "cute", "pretty" or "full of features."

Of course if you come home from vacation to find a flood of water coming out your front door you might be less-amused with the "cute" than you were at the store when you plunked down all that money -- 2 or 3x as much, incidentally, as the thermostat on my wall cost -- for that "cute" device.

PS: The technology that I developed is not something I'm intending to individually distribute, but I'm open to selling it on a source, all-rights basis to someone who wants to do so.  Those willing to do the "bizness thing" in this market and government environment, who are in this sort of line of work, might want to contact me -- but do bring your checkbook....

View this entry with comments (registration required to post)

Main Navigation
MUST-READ Selection:
Convention Of States?

Full-Text Search & Archives
Archive Access

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.


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 reproduced 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 or for commercial use.

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.