Dear LinkedIn Recruiter

Rules for contacting people that you want to hire, from my perspective:

  • Tell me what company you are recruiting for. I don’t care that you think the company is exciting.
  • Include my name at the top or your email. And when you do, please stop for a second and think to yourself: “Is their first name really David Volquartz or just David”.
  • If someone actually recommended my profile to you, let me know who it is so I can thank them for thinking about me.
  • Please look at my work history. I haven’t worked professionally with your technology for ten years so my knowledge is outdated.

As a sidenote, I probably get less recruiter mail than many developers. Probably about once per week. And I actually write full answers to all recruiters that figure out my name is just David.

Corporate Bullying

A few days ago, we received some reports from users that all went something like this: “Norton is blocking access to your site. It says the site has a security risk.”

First reaction: Panic! Did our site get taken over by hackers? Not quite… When reading the security report, it turns out that Norton had incorrectly classified a link from one of our receipt emails as a phishing attack. To be clear, the link does nothing else than redirect to the user’s website, i.e. there is no phishing going on, neither on our site nor the user’s site.

We immediately issued a dispute and request for re-evaluation with Norton’s website. And then… nothing really happened. After five days, it seemed that the red warning disappeared, but for the site dispute, the re-evaluation is still “in progress”.

Now, this would not be so bad if it was not for Norton’s massive userbase and the trust that they have. Besides the users that were blocked from using our app, a slightly more serious consequence was the 1-star review on the Shopify app store that popped up on Friday morning with just the text: “My Norton Antivirus software shows this site to have an identity threat.”

Needless to say, being wrongly flagged by Norton can have real consequences for a business.

And that is the main problem here. This whole ordeal reminds of me of some of the many things I hate about big corporations: Stepping on smaller businesses, misusing power and slow processes. I would go so far as to call it Corporate Bullying. Norton makes millions of dollars by tricking people into thinking that they need an expensive security solution (when they probably don’t). They can easily afford to make a few false positives when flagging sites because it has no consequences for them, only for the businesses in the receiving end. And when confronted with the problem, Norton does not care about us and our wrong security rating, nor do they take immediate action to rectify the problem.

The only thing missing here to make the bully analogy complete is if Norton came back to us and said that we need to pay them some “administrative fee” to remove the bad rating. Then they would truly have stolen our lunch money. I would not be surprised if that happened, but I hope that the story ends here.

People Debt

noun, Definition:
Unwillingness or resistance to change in the context of organizations, application design and development, when the change is objectively or arguably positive for the organization.
From the David Dictionary :-)

Deal with the tech debt
Deal with the tech debt by Dafydd Vaughan (CC-BY-SA)

Imagine a house in need of renovation. You can continue to paint the walls over and build new extensions, but at some point, the foundation needs an overhaul or you risk having to tear down the entire house.

Tech debt is like that. As an application grows, some old parts inevitably start to get outdated and in need of repairs. The biggest problem in application development is often not tech debt itself though. A lot of the time, people are the problem, not the code.

I recently had a conversation with a good friend about one of those little conflicts that happens at work sometimes. In this instance, my friend was trying to optimize a process that was rather slow and costly for the company. Apparently, this rubbed a manager the wrong way and they basically told my friend to stop making things more efficient. I only know one side of the story, but the situation sounds familiar. It is a symptom of People Debt.

People Debt is not about competence. It is about unwillingness or resistance to change. “We have always done it this way” is a common quote to hear in an organization with high people debt. Change is difficult to handle, even if the change is objectively for the better, e.g. more happiness, more profits, less complexity etc. When you combine people debt and tech debt, you get a very bad cocktail. This cocktail is often called Corporate Software, but it can also happen in smaller organizations.

I do not know exactly what leads to people debt, but it probably has a lot to do with pride and fear of looking bad in other’s eyes. I can relate to that feeling. It does not feel good when one’s decisions are being challenged and this often leads to defensiveness. Another part of the problem might be a consequence of “normal” power struggles. For example, encroaching on the area of responsibility of someone else.

I think one of the first steps to avoid people debt is to create a company culture where people feel comfortable and secure in their position in the company. Insecurity leads to defensiveness. I also think it is important to encourage open and positive collaboration between different areas of responsibilities. The best results usually come from team efforts and not a “me” effort. Finally, encouraging people to not be complacent and instead challenge the status quo from time to time also helps.

As always, the most difficult change to make is to ourselves. Defensiveness and insecurity are natural feelings to have. But I do believe that we can tame those emotions when it makes sense. When someone tries to help us improve in any way, it is easy to dismiss and defend, and much harder to listen, accept and maybe even learn something new. This goes for everything in life by the way — not just my tech bubble.

Chat is the new TODO

It used to be that the TODO app was a common way of demonstrating a specific language, framework or perhaps just as hobby project. Well, it occurred to me that now it seems that the new TODO app is a chat client. There are already many full-fledged “Slack Alternatives” and the hobby projects also seem to be popping up a lot. One of my colleagues was even starting out in Python by writing a chat app.

Ahh, how I enjoy making observations based on anecdotes and gut-feelings :-)

Privacy Leak “By Design”

I had an interesting chat with Intercom support about what I perceived to be a security and privacy hole in their support messenger app, but it turned out that what I thought should be a great concern for them was happening “by design”.

Intercom is a popular customer relations tool, and one of their cool features is the chat messenger app. It adds a little chat icon to the bottom-right of a website and allows real-time chat with customers for help and support. We use it at Receiptful which allows us to chat directly with our users when they are signed-in to our app. It looks like this:

Intercom in Receiptful

Chats are not private

A few days ago, I was using the Intercom chat app on a website that hosts some of our data. I needed to update some basic settings for our account and asked for help using the Intercom chat while I was signed-in to the service. A common use case for the Intercom chat is to allow support for both anonymous and signed-in users. What I found out is that there is no distinction between these by default.

When I signed out from the website, I noticed that my private chat session was still visible in the “anonymous” chat window. Even after restarting the browser and without signing in to the service, my private chat session was visible.

In other words: If I was on a shared computer, the next person using the browser would be able to see my private chat sessions, even though I signed out from the service where I had the chat in the first place.

Next, I tried to do the same thing on the Intercom website and it was the same deal: All previous announcements and private chats were visible from their frontpage without me signing in:

Intercom chat

“This is, in fact, by design”

When I noticed that my private support chats were leaking into the anonymous part of their website, I reported it to Intercom as a possible security hole because I did not think that it was intentional that private chats were visible while being signed out. This is the response from Intercom support:

This is, in fact, by design. We track users using an anonymous cookie, and when they logout that cookie still exists, so we can use that to keep the conversations in the messenger. I think your concern though is interesting, and I’ll forward this as feedback to our Messenger team.

If you’d like to ensure that others won’t see the conversations, I recommend clearing your cookies with us after logging out.

Apologies for the confusion there, it’s clear that sometimes what we think is a good idea isn’t always agreed upon by others.

No kidding…

So the privacy leak is “by design” and I have to remember to clear all my cookies to avoid it. What a joke. Imagine having a private chat on Facebook that was still visible after signing out. That would be quite horrible. Intercom clearly does not see their support chat system as a private conversation, although it most certainly is. In the chats, both my real name and email are used and what is even worse: I can create a new conversation using the same chat window, thereby impersonating whoever was the last one to use the system.

Now to be fair, there is a documented API called Intercom('shutdown') which clears the user cookie and resets the state of Intercom. However, Intercom does not even use this API themselves and I cannot imagine many websites that do this. So leaking chats are probably quite common.

The bigger picture

I think what really bothered me is that I already knew what Intercom would say when I reported the issue. Before I got the above answer from Intercom, I wrote this message to my colleagues:

It's been reported to Intercom. Now awaiting the response "that's by design". I ​_know_​ that will be their response because that's the world we live in these days. Where you can close your browser and then someone else can view your data afterwards. Noone cares about these things. Sigh...

The problem with lack of privacy is systemic. In this case with Intercom, usability won over privacy. They thought it was a “good idea” to keep chat windows open even after the user had signed out of their service and in most cases, this decision does not present a problem for the user if they are not on a shared computer. But by asking the questions “should private chats be visible after the user signs out”, “what if the user is on a shared computer” and “how does this relate to the privacy of our users”, I think they would have arrived at a different conclusion.

As developers in an a world of increasing surveillance, we need to ask ourselves questions about privacy when developing our solutions. And if there is an obvious case of private information leaking to a non-secured area, we should most definitely not consider it to be “by design”.

For full transparency, here is a copy of my support chat with Intercom.