Why we were especially diligent about our Dashboard Digital Signage Feature.
When it comes to product development, received wisdom is often to just get something into customers’ hands and if they use it and love it, fixing the odd bug will be a nice problem to have. But sometimes good enough, isn’t good enough.
There is often a tension between product and sales, especially in the early days, where the pressure to get something out there so people can buy it bashes up against the desire to not release something that isn’t quite ready yet. Often it’s a bit of a gray area: the good sales person can explain to the eager customer that this is an early release and that they may have to bear with a few teething problems; while the engineer doesn’t want the hard effort that they’ve put into something to be sullied by the one issue that hasn’t quite been ironed out yet.
However, there are times when you can’t compromise because to do so would kind of undermine the point of the feature. And that is particularly true when it comes to anything that has security at its core.
This is the challenge we were faced with when customers said they wanted to show Business Information on screens in their office. Not everyone, but enough of them had a pain point that went along the lines of:
I’ve been tasked with getting data from Tableau/Grafana/Signal FX/ChartIO/Trello/Power BI etc onto screens in our office/warehouse/factory. But I absolutely cannot do that if it’s not secure.
Getting the data onto a screen wasn’t hard. Most Business Information systems have the ability to spin up a dashboard onto a URL. But the problem is, if any of the data that lived on your dashboards was remotely sensitive, creating a public URL, however unguessable that might be, is an unacceptable security risk.
Some other digital signage providers were touting a ‘secure’ option, which basically involved recording login steps, usually in raw JavaScript, sending those details to the screen device, which in turn then opened a browser and displayed the content.
But there is so much wrong with this: for a start, to execute the login steps, the software had to run scripts on the website it was trying to access. Browsers don’t like this and have built-in protection to prevent it, so the Javascript has to disable this protection. Does disabling that protection sound secure to you? We couldn’t, in good faith, try and convince our customers that this was a ‘secure’ solution, even if that’s what everyone else was doing.
And there was more: the encrypted credentials had to be decrypted, but this was done on the screen device itself. You know, that little box that plugs into the screen and shows content. And guess what? Those devices aren’t designed to be super secure, making it easy for someone to copy data or intercept network traffic. Hardware, especially if it’s a few years old, might not get the latest version of the software and may not have up to date security patches. What’s more, anyone could just grab the device and walk off with it. So all in all, what was being done in the industry in the name of ‘secure dashboards’ was anything but. And the savvy customers knew it.
So, we went back to the drawing board. Luke, our CTO, had an idea that we could do all of the encryption in the Cloud in a super-secure AWS environment, rather than on a super insecure bit of hardware that was plugged into the back of a screen in an environment we had no control over.
What’s more, Luke thought, what if the screen never actually connected to the business information platform at all? What if, instead, it just showed an encrypted screen grab from the dashboard? This would avoid the screen device handling any credentials. Instead the AWS service (which included cool things such as Secrets Manager to ensure that nobody else could gain access), handled all of the credentials.
That would mean that the likely worse case scenario would be as bad as someone just whipping out their phone and taking a picture of a screen showing a dashboard with sensitive data on. Not perfect, but hardly handing over the keys to the Crown Jewels.
This seemed like a much smarter way and would mean that when we spoke to customers who knew what they were talking about and we used the term ‘secure’, we could do so with confidence that we meant what we said.
The downside
Unfortunately, to do this properly wasn’t going to be easy and so would take a while to work out and build. What’s more it wasn’t going to be cheap for us to host. To make it as secure as possible, Luke and Michael (our Director of Apps) wanted to spin up a separate temporary server on AWS every time a dashboard was created. And by created, we mean if a dashboard hadn’t been running for 5 minutes or more, then a new temporary server would be created — even if it was the same dashboard showing the same data from half an hour ago.
So we embarked upon a fairly lengthy project as we watched our competitors selling their versions of a secure dashboard. We bit our lips and promised our customers that our version would solve the real problem they had but that it was going to take us a while.
We got promising feedback among customers who wanted to work with us to dig deeper into what we were doing. With one engineer working at a very high profile public company based in San Francisco, telling me:
I’m consistently impressed by the tech stack you are using to solve dashboards.. kudos to the team.
The upside
We finally launched, what I believe, is the most secure solution to this problem in the industry. Is it 100% secure? No, nothing is. We’re looking at ways in which we could include an on-prem element to the process so that we (ScreenCloud) don’t even touch the encrypted screenshots. But for now, we seem to have made the right bet: customers who were previously struggling with being able to share data securely like this, can now do so with confidence.
Lessons learnt
We’ve all experienced new products or functionality taking way too long and being way too engineered, failing spectacularly when they are finally launched. It’s a waste of time and money when that lesson could have been learnt for a fraction of the time and cost. But… that doesn’t mean you always have to slavishly follow the MVP doctrine. Sometimes you do have to use common sense.
If this is something that your organisation would be interested, you can find more details at www.screencloud.com/dashboards
