We often see data use described in blanket terms...
%20(1).webp)
We often see data use described in blanket terms: “if you use this website, they will collect your data.” This is often mixed with scarier sounding terms, like having your "data mined," or that you're being "tracked." There are numerous examples of bad actors who misuse data, but we still continue to share our data in exchange for services which we find helpful. We keep sharing data because despite knowing that our data is being seen by a third party, we have an understanding of how we expect that data to be used—and we get upset when that understanding is violated. So how can we think about these nuances of data privacy more concretely?
Let's walk through a hypothetical example. You’re headed to your favorite brunch place for a delicious weekend breakfast with a friend. You might chit-chat with the server as you decide whether you want waffles, french toast, or an omelet. After your meal is over, you manage to get your credit card out first to treat your friend.
While most people will see this as a fun weekend activity, privacy nerds like myself will also observe intricate exchange of data. You communicated your food preferences to the server, who then shared them with the chef to customize the food to your liking. You also shared your credit card information with the server, who swiped it in the reader in order to share the information with the credit card company. Due to established traditions of brunch, we expect that our data will be used in this manner.
But how would we feel if we learned that the server shared the credit card information with the chef? Or if the server called the credit card company to tell them that we prefer our eggs over easy? Even though we are sharing the same data with the same entity (the restaurant) as in our previous case, instinctively, it feels like these data uses would upset us because they violate the implied understanding of how the restaurant would use our data. When handing over a credit/debit card, we expect that it will only be used to pay for the service we are receiving. There is no reason for the chef to have this information, and it would really worry us that the chef writing down our credit card might mean that they could use it in a way to which we did not agree. Similarly, we expect our food preferences to only be used to make the food we like, not to be shared with an external third party credit card company.
If this was a software system, we would represent the restaurant as 4 separate systems, which all have different data needs (fig 1). An order placement system interacts directly with the customer, and keeps track of what the customer wants to eat, how much their order costs, and how they should pay for it. The cooking system prepares the food, and therefore only needs to keep track of what the customer wants to eat. The credit card machine only needs to know how much to charge and which card to charge, and sends this data only to the external credit card company.
.png)
To enforce the user's understanding of privacy, we can build the expectations of data sharing directly into our system. When the order placement system communicates with the cooking system, it does not send all the information it has about a user; it only sends the information about what food the user has ordered. Similarly, when the order placement system sends data to the credit card machine, it only sends the payment information, and it only shares that with the approved third-party subprocessor, the credit card company, not with external advertising companies.
Enforcing this separation as you build a software system requires a strong culture of privacy by the people who build it, who take the time to enforce this separation of data by need. At Delfina, user privacy is a paramount value, and we follow privacy best practices like these to ensure that customers consent to all of our data practices, every step of the way.
We often see data use described in blanket terms...
We often see data use described in blanket terms: “if you use this website, they will collect your data.” This is often mixed with scarier sounding terms, like having your "data mined," or that you're being "tracked." There are numerous examples of bad actors who misuse data, but we still continue to share our data in exchange for services which we find helpful. We keep sharing data because despite knowing that our data is being seen by a third party, we have an understanding of how we expect that data to be used—and we get upset when that understanding is violated. So how can we think about these nuances of data privacy more concretely?
Let's walk through a hypothetical example. You’re headed to your favorite brunch place for a delicious weekend breakfast with a friend. You might chit-chat with the server as you decide whether you want waffles, french toast, or an omelet. After your meal is over, you manage to get your credit card out first to treat your friend.
While most people will see this as a fun weekend activity, privacy nerds like myself will also observe intricate exchange of data. You communicated your food preferences to the server, who then shared them with the chef to customize the food to your liking. You also shared your credit card information with the server, who swiped it in the reader in order to share the information with the credit card company. Due to established traditions of brunch, we expect that our data will be used in this manner.
But how would we feel if we learned that the server shared the credit card information with the chef? Or if the server called the credit card company to tell them that we prefer our eggs over easy? Even though we are sharing the same data with the same entity (the restaurant) as in our previous case, instinctively, it feels like these data uses would upset us because they violate the implied understanding of how the restaurant would use our data. When handing over a credit/debit card, we expect that it will only be used to pay for the service we are receiving. There is no reason for the chef to have this information, and it would really worry us that the chef writing down our credit card might mean that they could use it in a way to which we did not agree. Similarly, we expect our food preferences to only be used to make the food we like, not to be shared with an external third party credit card company.
If this was a software system, we would represent the restaurant as 4 separate systems, which all have different data needs (fig 1). An order placement system interacts directly with the customer, and keeps track of what the customer wants to eat, how much their order costs, and how they should pay for it. The cooking system prepares the food, and therefore only needs to keep track of what the customer wants to eat. The credit card machine only needs to know how much to charge and which card to charge, and sends this data only to the external credit card company.
To enforce the user's understanding of privacy, we can build the expectations of data sharing directly into our system. When the order placement system communicates with the cooking system, it does not send all the information it has about a user; it only sends the information about what food the user has ordered. Similarly, when the order placement system sends data to the credit card machine, it only sends the payment information, and it only shares that with the approved third-party subprocessor, the credit card company, not with external advertising companies.
Enforcing this separation as you build a software system requires a strong culture of privacy by the people who build it, who take the time to enforce this separation of data by need. At Delfina, user privacy is a paramount value, and we follow privacy best practices like these to ensure that customers consent to all of our data practices, every step of the way.
We often see data use described in blanket terms...
We often see data use described in blanket terms: “if you use this website, they will collect your data.” This is often mixed with scarier sounding terms, like having your "data mined," or that you're being "tracked." There are numerous examples of bad actors who misuse data, but we still continue to share our data in exchange for services which we find helpful. We keep sharing data because despite knowing that our data is being seen by a third party, we have an understanding of how we expect that data to be used—and we get upset when that understanding is violated. So how can we think about these nuances of data privacy more concretely?
Let's walk through a hypothetical example. You’re headed to your favorite brunch place for a delicious weekend breakfast with a friend. You might chit-chat with the server as you decide whether you want waffles, french toast, or an omelet. After your meal is over, you manage to get your credit card out first to treat your friend.
While most people will see this as a fun weekend activity, privacy nerds like myself will also observe intricate exchange of data. You communicated your food preferences to the server, who then shared them with the chef to customize the food to your liking. You also shared your credit card information with the server, who swiped it in the reader in order to share the information with the credit card company. Due to established traditions of brunch, we expect that our data will be used in this manner.
But how would we feel if we learned that the server shared the credit card information with the chef? Or if the server called the credit card company to tell them that we prefer our eggs over easy? Even though we are sharing the same data with the same entity (the restaurant) as in our previous case, instinctively, it feels like these data uses would upset us because they violate the implied understanding of how the restaurant would use our data. When handing over a credit/debit card, we expect that it will only be used to pay for the service we are receiving. There is no reason for the chef to have this information, and it would really worry us that the chef writing down our credit card might mean that they could use it in a way to which we did not agree. Similarly, we expect our food preferences to only be used to make the food we like, not to be shared with an external third party credit card company.
If this was a software system, we would represent the restaurant as 4 separate systems, which all have different data needs (fig 1). An order placement system interacts directly with the customer, and keeps track of what the customer wants to eat, how much their order costs, and how they should pay for it. The cooking system prepares the food, and therefore only needs to keep track of what the customer wants to eat. The credit card machine only needs to know how much to charge and which card to charge, and sends this data only to the external credit card company.
To enforce the user's understanding of privacy, we can build the expectations of data sharing directly into our system. When the order placement system communicates with the cooking system, it does not send all the information it has about a user; it only sends the information about what food the user has ordered. Similarly, when the order placement system sends data to the credit card machine, it only sends the payment information, and it only shares that with the approved third-party subprocessor, the credit card company, not with external advertising companies.
Enforcing this separation as you build a software system requires a strong culture of privacy by the people who build it, who take the time to enforce this separation of data by need. At Delfina, user privacy is a paramount value, and we follow privacy best practices like these to ensure that customers consent to all of our data practices, every step of the way.
We often see data use described in blanket terms...
We often see data use described in blanket terms: “if you use this website, they will collect your data.” This is often mixed with scarier sounding terms, like having your "data mined," or that you're being "tracked." There are numerous examples of bad actors who misuse data, but we still continue to share our data in exchange for services which we find helpful. We keep sharing data because despite knowing that our data is being seen by a third party, we have an understanding of how we expect that data to be used—and we get upset when that understanding is violated. So how can we think about these nuances of data privacy more concretely?
Let's walk through a hypothetical example. You’re headed to your favorite brunch place for a delicious weekend breakfast with a friend. You might chit-chat with the server as you decide whether you want waffles, french toast, or an omelet. After your meal is over, you manage to get your credit card out first to treat your friend.
While most people will see this as a fun weekend activity, privacy nerds like myself will also observe intricate exchange of data. You communicated your food preferences to the server, who then shared them with the chef to customize the food to your liking. You also shared your credit card information with the server, who swiped it in the reader in order to share the information with the credit card company. Due to established traditions of brunch, we expect that our data will be used in this manner.
But how would we feel if we learned that the server shared the credit card information with the chef? Or if the server called the credit card company to tell them that we prefer our eggs over easy? Even though we are sharing the same data with the same entity (the restaurant) as in our previous case, instinctively, it feels like these data uses would upset us because they violate the implied understanding of how the restaurant would use our data. When handing over a credit/debit card, we expect that it will only be used to pay for the service we are receiving. There is no reason for the chef to have this information, and it would really worry us that the chef writing down our credit card might mean that they could use it in a way to which we did not agree. Similarly, we expect our food preferences to only be used to make the food we like, not to be shared with an external third party credit card company.
If this was a software system, we would represent the restaurant as 4 separate systems, which all have different data needs (fig 1). An order placement system interacts directly with the customer, and keeps track of what the customer wants to eat, how much their order costs, and how they should pay for it. The cooking system prepares the food, and therefore only needs to keep track of what the customer wants to eat. The credit card machine only needs to know how much to charge and which card to charge, and sends this data only to the external credit card company.
To enforce the user's understanding of privacy, we can build the expectations of data sharing directly into our system. When the order placement system communicates with the cooking system, it does not send all the information it has about a user; it only sends the information about what food the user has ordered. Similarly, when the order placement system sends data to the credit card machine, it only sends the payment information, and it only shares that with the approved third-party subprocessor, the credit card company, not with external advertising companies.
Enforcing this separation as you build a software system requires a strong culture of privacy by the people who build it, who take the time to enforce this separation of data by need. At Delfina, user privacy is a paramount value, and we follow privacy best practices like these to ensure that customers consent to all of our data practices, every step of the way.
We often see data use described in blanket terms...
We often see data use described in blanket terms: “if you use this website, they will collect your data.” This is often mixed with scarier sounding terms, like having your "data mined," or that you're being "tracked." There are numerous examples of bad actors who misuse data, but we still continue to share our data in exchange for services which we find helpful. We keep sharing data because despite knowing that our data is being seen by a third party, we have an understanding of how we expect that data to be used—and we get upset when that understanding is violated. So how can we think about these nuances of data privacy more concretely?
Let's walk through a hypothetical example. You’re headed to your favorite brunch place for a delicious weekend breakfast with a friend. You might chit-chat with the server as you decide whether you want waffles, french toast, or an omelet. After your meal is over, you manage to get your credit card out first to treat your friend.
While most people will see this as a fun weekend activity, privacy nerds like myself will also observe intricate exchange of data. You communicated your food preferences to the server, who then shared them with the chef to customize the food to your liking. You also shared your credit card information with the server, who swiped it in the reader in order to share the information with the credit card company. Due to established traditions of brunch, we expect that our data will be used in this manner.
But how would we feel if we learned that the server shared the credit card information with the chef? Or if the server called the credit card company to tell them that we prefer our eggs over easy? Even though we are sharing the same data with the same entity (the restaurant) as in our previous case, instinctively, it feels like these data uses would upset us because they violate the implied understanding of how the restaurant would use our data. When handing over a credit/debit card, we expect that it will only be used to pay for the service we are receiving. There is no reason for the chef to have this information, and it would really worry us that the chef writing down our credit card might mean that they could use it in a way to which we did not agree. Similarly, we expect our food preferences to only be used to make the food we like, not to be shared with an external third party credit card company.
If this was a software system, we would represent the restaurant as 4 separate systems, which all have different data needs (fig 1). An order placement system interacts directly with the customer, and keeps track of what the customer wants to eat, how much their order costs, and how they should pay for it. The cooking system prepares the food, and therefore only needs to keep track of what the customer wants to eat. The credit card machine only needs to know how much to charge and which card to charge, and sends this data only to the external credit card company.
To enforce the user's understanding of privacy, we can build the expectations of data sharing directly into our system. When the order placement system communicates with the cooking system, it does not send all the information it has about a user; it only sends the information about what food the user has ordered. Similarly, when the order placement system sends data to the credit card machine, it only sends the payment information, and it only shares that with the approved third-party subprocessor, the credit card company, not with external advertising companies.
Enforcing this separation as you build a software system requires a strong culture of privacy by the people who build it, who take the time to enforce this separation of data by need. At Delfina, user privacy is a paramount value, and we follow privacy best practices like these to ensure that customers consent to all of our data practices, every step of the way.
We often see data use described in blanket terms...
