Addressing vendor security is a significant and inescapable problem for any modern company. Like many other companies, Dropbox has external third-party integrations with our products, and we also use vendors for internal services, from HR workflows to sales, marketing, and IT. In many ways, vendors play a critical part in Dropbox’s overall security posture and thus require appropriate scrutiny from our security team based on the risk posed by the vendor and feasible mitigations.
Today, we’re sharing the results of an experiment to improve vendor security assessments—directly codifying reasonable security requirements into our vendor contracts. We’re also sharing our model security legal terms and making them freely available for anyone to use and modify.
Editor’s note: On January, 18, 2019 the Dropbox Design blog featured a post from Product Designer, Jenny Wen, on working with engineers. This post covers the topic from an engineer’s perspective.
One of my favorite things as an engineer building Paper is how closely I get to work with designers. It’s an important partnership. When we share the same goals, work closely together, and understand what is important to each other we can create things that we would never be able to accomplish on our own. The opposite is also true. When we don’t align early,
This is the first in a series of posts that Dropbox Principal Engineer James Cowling has published on his personal Medium blog about technical leadership. Being a strong tech lead is very different from being a strong engineer and we thought the readers of our tech blog would find his experiences relevant and interesting.
Back when I was a first-time tech lead at Dropbox I had the misfortune of juggling two intimidating responsibilities at the same time:
- Build a multi-exabyte distributed storage system and migrate our data off Amazon S3,
The Dropbox desktop client is relied on by millions of users across the world to save their most important files and keep them in sync across their devices. Weighing in at over 1 million lines of Python logic, we had a massive surface area for potential issues in our migration from Python 2 to Python 3. In this process, we knew that we had to be worthy of the trust that users place in Dropbox and keep their information safe.
Over the last few months, we’ve explored why and how we rolled out our Python 3 migration,
Apache Kafka is a popular solution for distributed streaming and queuing for large amounts of data. It is widely adopted in the technology industry, and Dropbox is no exception. Kafka plays an important role in the data fabric of many of our critical distributed systems: data analytics, machine learning, monitoring, search, and stream processing (Cape), to name a few.
At Dropbox, Kafka clusters are managed by the Jetstream team, whose primary responsibility is to provide high quality Kafka services. Understanding Kafka’s throughput limit in Dropbox infrastructure is crucial in making proper provisioning decision for different use cases,
Dropbox needs its underlying network infrastructure to be reliable, high-performing, cost-effective, and truly scalable. In previous posts we described how the edge network was designed to improve user performance, and how the supporting multi-terabit backbone network spans continents to interconnect edge PoPs and multiple data centers.
In this post we describe how we evolved the Dropbox data center network from the legacy chassis based four-post architecture to a scalable multi-tier, quad-plane fabric. Also, we successfully deployed our first fabric at our newest data center in California earlier this year!
Dropbox network physical footprint
We currently have global network presence and multiple data centers in California,