Testing is a crucial part of maintaining a code base, but not all tests validate what they’re testing for. Flaky tests—tests that fail sometimes but not always—are a universal problem, particularly in UI testing. In this blog post, we will discuss a new and simple approach we have taken to solve this problem. In particular, we found that a large fraction of most test code is setting up the conditions to test the actual business-logic we are interested in, and consequently a lot of the flakiness is due to errors in this setup phase. However, these errors don’t tell us anything about whether the primary test condition succeeded or failed,
The easiest way to keep a secret is to not tell it to anyone. Unfortunately passwords don’t work that way. Every time you sign in you have to tell the website your password, making it more challenging to keep the secret safe. That’s why we recommend turning on two-step verification for your account, which adds an extra layer of difficulty for anyone who has guessed, eavesdropped on, or tricked you into giving them your password. And it’s why we’re excited today to announce support for WebAuthn (“Web Authentication”) in two-step verification, a new standard for strong authentication on the web.
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).
With this post we begin a series of articles about our Service Oriented Architecture components at Dropbox, and the approaches we took in designing them. Bandaid, our service proxy, is one of these components. Follow along as we discuss Bandaid’s internal design and the approaches we chose for the implementation.
Bandaid started as a reverse proxy that compensated for inefficiencies in our server-side services. Later we developed it into a service proxy that accelerated adoption of Service Oriented Architecture at Dropbox.
A reverse proxy is a device or service that forwards requests from multiple clients to servers (i.e.
The Dropbox Security Team is responsible for securing over 500 petabytes of data belonging to over half a billion registered users across hundreds of thousands of businesses. Securing data at this scale requires a security team that is not only well-resourced, but also one that can keep ahead of the expansion of our platform. We focus on scaling our own leverage, so each new security person we add multiplies the impact of our team.
Over the course of this year—and beyond—we’ll go into more detail on how Dropbox approaches security and some of the projects we’ve tackled. Protecting Dropbox requires serious investments in security.
Open source software can provide significant benefits to an organization—it can decrease product development time, distribute development across a community, and attract developers to your organization. It’s because of these benefits that we at Dropbox love open source. However, some organizations shy away from it due to perceived risks and fears around lost intellectual property (IP) rights. You’re not alone if you’re worried that once you’ve incorporated open source into your products or open sourced your own code that you’ve surrendered control over your most valuable assets, or worse, left your organization vulnerable to litigation with no defensive weapons to counter the threat.