Jach's personal blog

(Largely containing a mind-dump to myselves: past, present, and future)
Current favorite quote: "Supposedly smart people are weirdly ignorant of Bayes' Rule." William B Vogt, 2010

What is customer trust?

My last job often championed "trust" as its number one value, though sometimes it was a bit nebulous about what was meant by it. Having not worked there for over a year, even I have started to forget what exactly is meant by it. But thinking about it again, it's actually really simple, and the company says as much in various places if you look.

Trust is simply whether people trust you or not, and maybe how much. Trust you with what? With anything they possibly could. If you're a business, and you want trust, you typically want to be trusted to do the right thing, to have a product that does something useful in a good way and in line with customer expectations, to be upfront and honest and transparent about your mistakes instead of burying them (and try hard not to make mistakes). This trust extends beyond your customers and includes your employees, too. Part of why I left was a loss of trust between myself and the company -- so many pieces of information were learned via public news instead of an internal announcement, for instance. Trust, once broken, is really hard to re-establish.

Another thing about trust is that what people do or do not trust you in changes from person to person, which is why it can be a bit nebulous. Is it reasonable for me, a simple IC, to expect that the details of firing a security pair moments after giving a talk at Defcon would be provided in news articles and public forums and totally ignored internally and talked around when brought up in a company all-hands? Maybe, maybe not, but that was an early loss-of-trust moment for me, and even a rage-quit-in-solidarity moment if I was part of the security team.

If you're a game company, you end up making a lot of implicit promises to your players (and can thus create cursed design problems, where there's no direct solution to resolve/fulfill two promises). When you break them, even unintentionally, you end up losing some trust. This is part of why it's hard to make successful sequels to popular games, since there's a conflict between player expectations about what came before and providing something fresh. And of course as so many indies learn, the most basic element of trust you want to cultivate, is your game even fun to others, doesn't always work out. Some studios have even started flirting with "no crunch time!" promises to employees, which employees should never believe, and inevitably it ends up being a self-inflicted wound to themselves when crunch time happens. If you can't make good on promises, don't make them.

If you're an antivirus company, but you end up false-flagging so much software customers want to use (games, game mods), you lose trust that your product does what it claims, and customers may even turn it off and stop using it, and are likely to seek out an alternative. It's unfortunate that there's basically 0 trustworthy vendors in this space.

If you're a company that stores lots of customer data, they trust you not to lose that data, or make it available to other people. When they want that data, they trust you to provide timely access to it.

In the open source world, a lot has been built on a presumption of trust. Every so often we'll see some "supply chain" attacks on developer infrastructure (e.g. NPM, Pypi..) but crapware in core distro package releases is very rare. On the browser front, Chromium add-ons are so much less trustworthy than Firefox add-ons, even though there have been some high-profile Firefox add-on shenanigans with things stealing data/phoning home.

Trust isn't always necessary. I wanted to get some toilet paper at the grocery store the other day, but of course the aisle was barren, because this is the world we apparently live in now. Even though I had an expectation of getting some TP, this wasn't elevated to a form of trust, and no trust was lost from it. And when I got home, I just ordered my usual from Amazon. And even though I paid with credit, we didn't need to first establish trust that I'm good for it and won't go to my CC company to try and dispute the charge. In other cases, like used car dealerships, there's simply no one trustworthy enough anyway, but you still need a product or service from one of the groups providing it, so you go with the one that seems least likely to screw you over the least amount, and try to have mitigations. (For example in the used car scenario, having even a one year comprehensive warranty will avoid driving off the lot with a lemon that totally breaks down in a week or two, the cost of the warranty is much less than the cost of a defective vehicle.) Insurance as an industry is a great innovation to establishing backup plans in low-trust environments -- so long as you can trust the insurer to pay up, which is often difficult in itself.

Trust can be in a brand as much as a company. Sony is a huge company with a lot of product areas, but I avoid them all because as a brand they have 0 of my trust. Primarily because of the rootkit saga, which was done by their music division and didn't even affect me and happened in 2005. Secondarily by their actions with Linux on the PS3, where they (the gaming division) removed support in 2010. Again, didn't affect me (I already had no trust in them by then, why would I get a PS3) but it's just another point of data showing they don't care about my trust or even trying to gain it back. I don't even have to research anything about their TVs, or modern DRM schemes, to know that they're not doing anything that would make me trust them. I happily live without any Sony products.

When an employee is "working on trust items", that sometimes gets interpreted as "working on bugs", but really it's just working on anything that by implementing or fixing or addressing either decreases the chance of losing customer trust or increases the chance of gaining more. A new feature can be trust work, a bug fix can be trust work, writing documentation can be trust work. It's not a great idea to ignore such work, because even though there are many situations where trust is not needed, and even in no or low-trust environments money can still be exchanged (for instance I don't trust Oracle with anything, but their DB basically works fine, and if you're stuck in a partnership with them then finding a replacement or backup solution nevertheless may not be the most pressing thing -- similarly if someone gifted me e.g. a Sony sound bar), losing too much customer trust in one area or overall can be a misstep you just can't recover from. On the other hand, trust work does need some justification and analysis, just like work on security. The fact that a lot of "security" work gets put under the trust umbrella highlights this. And like security, there can often be inherent conflicts with the surface level desires of customers and the paternalistic "what's best for them" realities of security or trust. I added to my resume a blurb about enjoying "combining customer delight with customer trust", because both things should be valued by a company, but there are conflicts and tradeoffs to make (and for me it's fun to think about them).

Security is often the only one that successfully borrows the high value of trust in order to mandate something, but really the problem is mandates, they trump analysis every time in large companies, and will often use whatever justification they can to avoid just coming out and saying it's a mandate (which can lead to employee loss of trust). Here's an example: we're no longer storing this third party API password in source control, but instead in a centralized internal dynamic database that returns a different value depending on whether the application asking it for the password is a developer machine or a production machine. This was filed as a mandated "must-do trust/security work", and it wasn't too difficult so it was done without much grumbling, but there was no security or trust analysis done.

It would have been easy to do one, and indeed while working on it I concluded that it wasn't actually serious. It moves the problem from attackers having source code access, already a huge problem, to attackers needing to compromise either the database machine or a production machine, an even bigger and harder problem sure, but the prize in either case is minimal with respect to this data. The password to the API service is only used to speed up page rendering for search engine bots.

In theory (I forget if there was signing) a compromise could lead to worst-case an attacker serving up custom HTML to search engines, which could then negatively impact SEO, but this is an annoyance (and something we were already bad at by our own hands, it took a long time to iron out SEO issues, customers already didn't trust us that much with it). More likely, the attacker would use the password to drain our monthly API request quota, forcing us to either blindly pay more or provoking an analysis. So anyway it's easy to conclude that losing this password would minimally impact either security or trust.

It's interesting to ask can trust be the number one value? There's a dependency problem in play. If customers trust you to deploy new software updates without breaking things, then to avoid losing that trust you need to make sure you invest enough time in QA among other things. Wouldn't it be curious if such resources were lacking? Isn't this better explained by QA being a low-valued item by most companies? It doesn't seem that there's a consistent power transfer of the value of trust to the value of things that enable trust -- perhaps if things that enable trust were explicitly valued higher on their own merits, not just for the trust increase they have, then trust comes along for the ride, and you may even get higher trust without having to give it so much lip service.

Posted on 2021-10-03 by Jach

Tags: business, philosophy


Trackback URL:

Back to the top

Back to the first comment

Comment using the form below

(Only if you want to be notified of further responses, never displayed.)

Your Comment:

LaTeX allowed in comments, use $$\$\$...\$\$$$ to wrap inline and $$[math]...[/math]$$ to wrap blocks.