Dropbox runs hundreds of services, written in different languages, which exchange millions of requests per second. At the core of our Service Oriented Architecture is Courier, our gRPC-based Remote Procedure Call (RPC) framework. While developing Courier, we learned a lot about extending gRPC, optimizing performance for scale, and providing a bridge from our legacy RPC system.
Note: this post shows code generation examples in Python and Go. We also support Rust and Java.
The road to gRPC
Courier is not Dropbox’s first RPC framework. Even before we started to break our Python monolith into services in earnest,
Let’s say a machine in your corporate fleet gets infected with malware. How would you detect it? How could you find out what happened on the machine? What did the malware do? Did it steal your browser’s passwords? What network connections did the malware make? Was it looking for crypto currency? By having good telemetry and a good host monitoring solution for your machines you can collect the context necessary to answer these important questions.
Proper host monitoring on macOS can be very difficult for some organizations. It can be hard to find mature tools that proactively detect security incidents.
At Dropbox, we encourage, support, and celebrate independent open security research.
One way we do this is via our bug bounty program. We recently tripled our rewards to industry leading values. We also celebrated some of the amazing hacker community results with top-up bonuses, where we retroactively issued additional rewards for particularly unusual, clever, or high-impact findings.
This post, however, is not about bug bounty programs. While a well-run bug bounty program is mandatory for maintaining top-tier security posture, this post is about the foundation on which bug bounty programs are built: the Vulnerability Disclosure Policy (VDP).
We first launched our bug bounty program in 2014, with initial bounties for critical bugs in the range of $5,000, ramping up to (currently) over $10,000 for critical bugs. Over the past three years, leading security researchers from around the world have participated in our programs with some amazing, often original research. Beyond just the individual bugs, we have learned many a lesson, uncovering unique, interesting threats, exploit vectors, and new research as well as rejigged our priorities based on the bug bounty reports. From Dropbox and all our users, a big THANK YOU to all the researchers that help secure Dropbox for our users!
Our comms team told us we need an image; our legal team told us it needed to be freely licensed. Credit: Carsten Schertzer (Creative Commons Attribution 2.0)
Dropbox employs traditional cross-site attack defenses, but we also employ same-site cookies as a defense in depth on newer browsers. In this post, we describe how we rolled out same-site cookie based defenses on Dropbox, and offer some guidelines on how you can do the same on your website.
Recently, the IETF released a new RFC introducing same-site cookies.
Security incidents happen. And when they do, they need to be dealt with—quickly. That’s where detection comes into play. The faster incidents are detected, the faster they can be handed off to the security team and resolved. To make detection as fast as possible, teams are usually aided by monitoring infrastructure that fires off an alert any time something even slightly questionable occurs. These alerts can lead to a deluge of information, making it difficult for engineers to sift through. Even worse, a large number of these alerts are false positives, caused by engineers arbitrarily running