195 stories

★ Users and Customers

1 Comment and 2 Shares

Fascinating, wide-ranging podcast interview (with an excellent transcript) between Vox’s Ezra Klein and Facebook CEO Mark Zuckerberg:

Klein: One of the things that has been coming up a lot in the conversation is whether the business model of monetizing user attention is what is letting in a lot of these problems. Tim Cook, the CEO of Apple, gave an interview the other day and he was asked what he would do if he was in your shoes. He said, “I wouldn’t be in this situation,” and argued that Apple sells products to users, it doesn’t sell users to advertisers, and so it’s a sounder business model that doesn’t open itself to these problems.

Do you think part of the problem here is the business model where attention ends up dominating above all else, and so anything that can engage has powerful value within the ecosystem?

Zuckerberg: You know, I find that argument, that if you’re not paying that somehow we can’t care about you, to be extremely glib and not at all aligned with the truth. The reality here is that if you want to build a service that helps connect everyone in the world, then there are a lot of people who can’t afford to pay. And therefore, as with a lot of media, having an advertising-supported model is the only rational model that can support building this service to reach people. […]

But if you want to build a service which is not just serving rich people, then you need to have something that people can afford. I thought Jeff Bezos had an excellent saying on this in one of his Kindle launches a number of years back. He said, “There are companies that work hard to charge you more, and there are companies that work hard to charge you less.” And at Facebook, we are squarely in the camp of the companies that work hard to charge you less and provide a free service that everyone can use.

I don’t think at all that that means that we don’t care about people. To the contrary, I think it’s important that we don’t all get Stockholm syndrome and let the companies that work hard to charge you more convince you that they actually care more about you. Because that sounds ridiculous to me.

There is certainly something to Zuckerberg’s argument here, but the speciousness of the way he formulates it is that a company working hard to charge you more money is undeniably incentivized to care more about you, if you can afford their product or service. I think it’s undeniable that Apple cares more about the hundreds of millions of people who buy its products than Facebook cares about any of its billions of users.

The more apt Tim Cook quote that applies here is this long-standing internet adage: “When an online service is free, you’re not the customer. You’re the product.” Amazon is undeniably focused on low prices. But Facebook doesn’t charge low prices — they charge high prices. To their customers: advertisers. And a cursory look at their financials indicates they’ve been working hard to raise those prices.

The linguistic trick Zuckerberg pulls here is that nowhere in the entire interview does he mention the words user or customer. He only says you (in the plural sense) and people. That’s a dodge, because unlike Apple — and Amazon — Facebook’s users are not its customers — and most of the controversies they are dealing with today all stem from the fact that they favored their customers (advertisers willing to pay ever-higher sums for ever-more-invasively-targeted ads) at the expense of their users.

Read the whole story
21 days ago
Share this story

Best books for new, first-time managers

1 Share

I recently asked on Twitter: “what book would you recommend most for new, first-time managers?” It’s been a while since I’ve been a first-time manager or managed first-time managers directly, so I was curious. Below is the list of what folks recommended. The categories were added by me after realizing an unstructured list of 35+ books would be too overwhelming. I certainly haven’t read all of these books but put some notes in the list next to books I have read and a few notes next to ones I haven’t read but know something about. If you have a book you think should be here and isn’t, email me ( I’ll also include this in the newsletter I’m launching (more info here).

General management & leadership

Tech management and leadership

Note: having been a CTO and CEO, I recommend reading these books alongside the more general management books. An engineering leader with strong general management chops and business skills is a rare and valuable breed. 



 Prioritization and results

Psychology and how people think

Other (literature, non-fiction with important themes)

Michael Dearing suggested taking his very well-regarded general management course, so I mention that here. Even if you can’t take the course, check out page two of the syllabus for some great readings. Thanks, Michael!

Again, if you have a book you think should be here and isn’t, email me!( I’ll try to keep it updated.

Read the whole story
92 days ago
Share this story

The World is UDP

1 Share

There are two types of people: TCP people and UDP people. (Yes, those are Internet protocols. I’m the guy who wrote software to text my wife. Of course I’m going to classify people by Internet protocols.)

TCP, the protocol, guarantees delivery. When you send something via TCP, you know it’s either arrived or it hasn’t. It’s a phone call, where the person on the other end keeps repeating, “Uh huh” to let you know that they’re listening.

UDP does not guarantee delivery. You send something off into the ether and have no idea if it eventually lands where it’s supposed. It’s the postal mail, where you drop a letter into the box, and there’s a chance that it will be waylaid somewhere, and you’ll never know.

TCP is used for reliable communication. UDP is used for mass communication. E-mail is delivered via TCP, a packet at a time, confirmed and verified. Video conferences are delivered via UDP, a torrent of data vomited willy-nilly towards its destination, and if some of it is lost along the way, well, it’s just a few frames, a hiccup that nobody will notice.

TCP people — people with the TCP personality type — consume everything in their feeds. Every tweet, every e-mail, every photo. They’re completists, and neurotic completists at that. “Mark as Read” makes them feel uncomfortable, like something that needed to be done has been left undone, without actually being able to say what it might be. The data, to a TCP person, was sent, so it must arrive. If it doesn’t, something is broken.

UDP people think TCP people are bonkers. They’ll dip in and out of whatever data happens to be sluicing towards them at any particular moment, without giving the slightest thought to what might have come before and what might come after. If it’s important, they think, it will probably come around again. Missing something, by definition, makes it unimportant.

I am a TCP person, a habit formed back when it was possible to be a TCP person and not be driven to whimpering madness by the constant deluge of text and images and video — there hardly was any video — and whatever else managed to crawl off stand-alone computers and onto the then-fledging Internet. Bandwidth, never mind the relatively few people contributing the the miasma, made it possible to keep up. You can cope with anything at 300 baud.

The world, today, many years after my habit formed, is UDP. Bandwidth doubled, and doubled again, and doubled again and again and again and again. The Internet was flooded with literally billions of people. More data has swung around the planet in the last week than in all of prior history combined. (I just made that up. But you believed it for a second, didn’t you?) There’s just too much, and if you’re intent on crawling through the endless sand of this particular beach, it’s a lot easier not to have to mark every grain as “Done”.

And so people are becoming UDP as well. People wander into and out of their Twitter stream, produced by the N-thousand people they follow, as time allows. They let Gmail decide which messages are important enough to highlight. They happily allow a thousand-thousand posts and tweets and pictures to sail by, without the slightest concern that they might have enjoyed any of them, because they know there’s a thousand-thousand times as much coming over the spillway.

UDP people are right: TCP like me are bonkers. We maintain a tradition in the complete absence of the circumstance that allowed that tradition to form. When the land we stand on finally sinks below the relentlessly rising tide, it’s the people who have adapted, transformed, evolved who will survive. The only place for TCP people in the post-diluvian world will be on the small outcroppings of rock that poke above the endless, endless sea, and the only approach TCP people will be able to take is to pretend that the vast deep that surrounds them doesn’t exist. The world is UDP, and the people who live in it need to be as well.

But it would have been nice if anybody had actually seen this post.

Read the whole story
274 days ago
Share this story

Apple’s Achilles Heel

1 Comment

Neil Cybart, in his weekly Above Avalon column last week, “The Mac Is Turning into Apple’s Achilles Heel”:

Apple’s decision to change course and develop a new Mac Pro has received near-universal praise from the company’s pro community. While developing a new Mac Pro is the right decision for Apple to make given the current situation, it has become clear that the Mac is a major vulnerability in Apple’s broader product strategy. The product that helped save Apple from bankruptcy 20 years ago is now turning into a barrier that is preventing Apple from focusing on what comes next.

I read this last week and it didn’t sit right with me at all. But I couldn’t put my finger on why until this weekend. It’s actually very simple: I think Cybart’s entire premise is completely backwards. The Mac is not Apple’s Achilles heel. The iPhone is. That’s why the rest of his column doesn’t make much sense.

The iPhone hasn’t suffered because Apple is focused on the Mac. New iPhones come out like clockwork every year. Apple has really gotten it down to a science in recent years. The Mac lineup, however — and the Mac Pro in particular — has clearly suffered from a lack of attention. Where did that institutional attention go? Surely much of it went to iPhone.

I’m not arguing that it’s a mistake for Apple to devote more attention to the iPhone than any other product. Smartphones are the greatest opportunity in the history of mass market consumer goods, and also the greatest opportunity in the history of personal computing. The iPhone epitomizes everything Apple stands for. But it’s a mistake to focus so much attention on the iPhone that other important products suffer.

Read the whole story
371 days ago
Apple has over $200 billion in the bank. I wonder which form of attention is scarce inside Apple.
363 days ago
You can't solve every problem with money. The one Apple is facing is managing engineering resources and talent. This is very though, especially for a large company like Apple which has a very narrow/limited set of products which are from a technical POV very similar to develop. Skills useful to develop both the Mac and iOS-based devices (iPhone/iPad/Apple Watch) overlap a lot. We're talking about both hardware/industrial/physical design and software development here. The main exceptions to this are their cloud services and their chip/soc development.
Share this story

About the PPK talk and tweet

1 Comment and 5 Shares

Yesterday I attended a talk at a tech meetup here in Amsterdam by Peter-Paul Koch — during which I tweeted a photo of one of his slides:

This tweet has gotten quite a lot of attention — mostly negative — and I’d like to give some much-needed context.

PPK’s talk was about the problems he sees in with modern front-end web development. Problems for developers, problems for users, and problems for the web in general. It was more than an hour long and covered many topics, weaving in his rich knowledge of web-development history. Some opinions he articulated:

  • Web developers have become overly focused on emulating native mobile apps, when in fact they should focus on the strengths of the web. Sort of by definition, a website will never be as performant as a native app, given native apps speak directly to an OS while websites always have the browser as middleman — barring some significant technical shifts. So it’s an unattainable goal.
  • Modern front-end libraries and frameworks have become overly complicated, with so many abstractions and so much tooling that it’s very difficult for developers, especially beginners, to hold it all in their heads. He cited the brilliant How it feels to learn JavaScript in 2016 by Jose Aguinaga.
  • Relatedly, browser vendors should have a year-long moratorium on adding new features. (See also his blog post on this.)
  • Modern front-end libraries and frameworks encourage a style of development that punishes people on underpowered/mobile devices and slow connections. In many cases, he argued, there’s no reason to pull in hundreds of kilobytes of JavaScript, or naively traverse the entire DOM for the sake of developer convenience (he gave the example of Angular here), when doing it at a lower level of abstraction would perform better and might also result in less code that’s easier to reason about.
  • Developers who come to front-end work from back-end work often underestimate how difficult it is to be a front-end developer. Web browsers — with competing standards, implementation differences and browser bugs — are the “most hostile development environment in the world.” The key to being a front-end developer is to embrace that. In fact, certain Computer Science Best Practices, such as the DRY principle, don’t necessarily apply in front-end work (e.g., when practicing progressive enhancement, you develop the same thing twice).
  • A key distinction of front-end web programming is that users download your code when visiting a web page, which means users get “punished” if your code is bloated. This is different from back-end web programming, where it doesn’t matter nearly as much which tools you use as long as the network request is served quickly enough.

I’m working from memory, so I hope I did PPK’s opinions justice here. It was a fantastic, thought-provoking talk. I assume video, or at least the slides, will be posted online soon — and I’ll update this post with links when that happens.

Which brings me to my tweet. One of PPK’s slides said: “If you can’t do without tools you’re not a web developer.” In context of the presentation, this was already a controversial statement. Out of context, it’s absolutely incindiary (and, frankly, a bit nonsensical).

I regret tweeting this photo. It was clearly out of context, and I should have either used a different slide or waited until the video was posted. I hope the context here helps explain it.

Many people saw that slide, interpreted it at face value, and tweeted sarcastic responses such as “If you can’t put in a nail without a hammer, you’re not a carpenter.” They took it way too literally, suggesting PPK was telling us to cease using all tools, code in assembly, or otherwise be luddites. Obviously this is nonsense.

Other people took issue with drawing lines in the sand, saying it’s counterproductive (and can scare away beginners) to make exclusionary statements like this. I agree. Saying “You’re not a real X unless Y” is the wrong way to make the point. The arbitrary distinction of “Real Programmers” (versus, uh, not-Real Programmers?) is a disease of our profession.

In fact, regarding beginners, one of PPK’s most salient points was that the modern front-end development landscape is so complex that it’s impenetrable to newcomers. If I were starting web development today, I’d be terrified by the complexity — and probably give up. The aforementioned Jose Aguinaga post illustrates this brilliantly.

My interpretation of PPK’s slide, having seen the entire presentation, was simply this: web developers should have knowledge of what’s happening behind the scenes, so that they can use their tools more effectively. This, I agree with. If you blindly use a 20K library that traverses the entire DOM on every page load, in a situation where five lines of vanilla JavaScript would have done the same thing, you’re adding unnecessary strain on your users and possibly unnecessary strain on your development team. (That assumes “unnecessary strain” is a bad thing for your particular project/work.)

I’ve always thought the same about Django, by the way. Take, for example, the Django ORM. I think developers ought to have an understanding of SQL — the advantages, the limitations, the dos and don’ts — before they jump into using an ORM. That doesn’t mean everybody needs to write their own ORM, or always use raw SQL (two strawman arguments people have been making repeatedly in response to this tweet) — it just means they should have a basic understanding of what’s happening. Not enough to be a DBA, just enough to not make poor decisions.

Read the whole story
436 days ago
436 days ago
Washington, DC
Share this story
1 public comment
436 days ago
It's not just web. Same as with Django ORM or Hibernate mentioned, you should have some idea of the SQL being generated. And for general programming, you should have some idea about big-O, malloc, threads, processes, filesystems, etc even if your code never directly uses any of them. Because your code will *always* be impacted by those indirectly. Not knowing about those and leaning on tooling to handle it makes you a dabbler, throwing random code at a problem until something sticks.

Open Whisper Systems >> Blog >> There is no WhatsApp 'backdoor'

1 Share

Today, the Guardian published a story falsely claiming that WhatsApp's end to end encryption contains a "backdoor."


WhatsApp's encryption uses Signal Protocol, as detailed in their technical whitepaper. In systems that deploy Signal Protocol, each client is cryptographically identified by a key pair composed of a public key and a private key. The public key is advertised publicly, through the server, while the private key remains private on the user's device.

This identity key pair is bound into the encrypted channel that's established between two parties when they exchange messages, and is exposed through the "safety number" (aka "security code" in WhatsApp) that participants can check to verify the privacy of their communication.

Most end-to-end encrypted communication systems have something that resembles this type of verification, because otherwise an attacker who compromised the server could lie about a user's public key, and instead advertise a key which the attacker knows the corresponding private key for. This is called a "man in the middle" attack, or MITM, and is endemic to public key cryptography, not just WhatsApp.

The issue

One fact of life in real world cryptography is that these keys will change under normal circumstances. Every time someone gets a new device, or even just reinstalls the app, their identity key pair will change. This is something any public key cryptography system has to deal with. WhatsApp gives users the option to be notified when those changes occur.

While it is likely that not every WhatsApp user verifies safety numbers or safety number changes, the WhatsApp clients have been carefully designed so that the WhatsApp server has no knowledge of whether users have enabled the change notifications, or whether users have verified safety numbers. WhatsApp could try to "man in the middle" a conversation, just like with any encrypted communication system, but they would risk getting caught by users who verify keys.

Under normal circumstances, when communicating with a contact who has recently changed devices or reinstalled WhatsApp, it might be possible to send a message before the sending client discovers that the receiving client has new keys. The recipient's device immediately responds, and asks the sender to reencrypt the message with the recipient's new identity key pair. The sender displays the "safety number has changed" notification, reencrypts the message, and delivers it.

The WhatsApp clients have been carefully designed so that they will not re-encrypt messages that have already been delivered. Once the sending client displays a "double check mark," it can no longer be asked to re-send that message. This prevents anyone who compromises the server from being able to selectively target previously delivered messages for re-encryption.

The fact that WhatsApp handles key changes is not a "backdoor," it is how cryptography works. Any attempt to intercept messages in transmit by the server is detectable by the sender, just like with Signal, PGP, or any other end-to-end encrypted communication system.

The only question it might be reasonable to ask is whether these safety number change notifications should be "blocking" or "non-blocking." In other words, when a contact's key changes, should WhatsApp require the user to manually verify the new key before continuing, or should WhatsApp display an advisory notification and continue without blocking the user.

Given the size and scope of WhatsApp's user base, we feel that their choice to display a non-blocking notification is appropriate. It provides transparent and cryptographically guaranteed confidence in the privacy of a user's communication, along with a simple user experience. The choice to make these notifications "blocking" would in some ways make things worse. That would leak information to the server about who has enabled safety number change notifications and who hasn't, effectively telling the server who it could MITM transparently and who it couldn't; something that WhatsApp considered very carefully.

Even if others disagree about the details of the UX, under no circumstances is it reasonable to call this a "backdoor," as key changes are immediately detected by the sender and can be verified.

The reporting

The way this story has been reported has been disappointing. There are many quotes in the article, but it seems that the Guardian put very little effort into verifying the original technical claims they've made. Even though we are the creators of the encryption protocol supposedly "backdoored" by WhatsApp, we were not asked for comment.

Instead, most of the quotes in the story are from policy and advocacy organizations who seem to have been asked "WhatsApp put a backdoor in their encryption, do you think that's bad?"

We believe that it is important to honestly and accurately evaluate the choices that organizations like WhatsApp or Facebook make. There are many things to criticize Facebook for; running a product that deployed end-to-end encryption by default for over a billion people is not one of them.

It is great that the Guardian thinks privacy is something their readers should be concerned about. However, running a story like this without taking the time to carefully evaluate claims of a "backdoor" will ultimately only hurt their readers. It has the potential to drive them away from a well engineered and carefully considered system to much more dangerous products that make truly false claims. Since the story has been published, we have repeatedly reached out to the author and the editors at the Guardian, but have received no response.

We believe that WhatsApp remains a great choice for users concerned with the privacy of their message content.

Read the whole story
464 days ago
461 days ago
Just like Apple's central iMessage key directory, this effectively introduces a clear path for law enforcement to tap WhatsApp conversations with minimal user warning. In case of iMessage there is no warning and in case of WhatsApp there is no warning by default. In both cases past conversations can likely not be retrieved by the attacker. In both cases a national security letter and gag order in the US or equivalent mechanisms in other countries would make it illegal for WhatsApp/Facebook or Apple to admit such requests exist. It's not exactly a backdoor, but it is a design weakness that potentially tapped conversations are not clearly marked as such and potentially incriminating content is transmitted regardless. However, it must be mentioned that in most cases, the pure metadata of who communicates with whom and when, is already sufficient and this data can be siphoned off in bulk.
Share this story
Next Page of Stories