2 ms·

Risk of abortion data subpoenas led Proov off AWS to Google Cloud

matt321 4y ago
Neither company is immune to subpoena.
- giuliomagnifico 4y ago
  > Google had more viable options for protecting its customers’ fertility information. Both Google and AWS offer data center storage options in California and Oregon, which together issued a multistate commitment last month to defend reproductive health care access. And both cloud providers offer storage in more restrictive states including Ohio and Virginia. >But Nevada was what tipped the scales toward Google. It was one additional option offered by Google, but not AWS, that Proov believes will be a safe home for its reproductive health data.
LinuxBender 4y ago
I know that companies would never do this but I will suggest it anyway. Don't store customer data. Instead, cache a copy of the customers encrypted blob in the customers client side application. Customer sets the TTL for their cache to expire. The customer and only the customer may decrypt the data. If they wish to share their data with a health practitioner then they can screen share. If the government want this data, they will have to subpoena every individual customer. No lawful intercept. No intentionally weak frameworks. No "Oops we stored this in an unsecured S3". Just put the data and decryption keys under full control of the hands of the customers. Forward NSL's and subpoenas to the customers. Data retention policies are entirely up to the customer at this point. Create a disclaimer that explains it is on the customer to back up their data and/or decryption keys. If the keys are lost, just start over with a blank slate, or manually put in some stats from a customers copy of a printed report. One could probably even compress/encode the data in a way that a customers printed copy could be ingested into a program to re-encrypt and store it. QRCodes, Dots, etc... One argument against this would be that a company can't run reports on all their customers, use machine learning, etc... to which I say, "Good, cease and desist treating customers like cattle." If there are specific data points that a company wish to gather from its customer base, send a beacon to customers that would ask them if they wish to volunteer this specific data and make it painfully clear who will have access and for how long and how the data will be anonymized. Before a customer clicks "Send" they get a highly detailed display of what exactly is being shared in easily human readable format.

Neither company is immune to subpoena.

giuliomagnifico 4y ago
> Google had more viable options for protecting its customers’ fertility information. Both Google and AWS offer data center storage options in California and Oregon, which together issued a multistate commitment last month to defend reproductive health care access. And both cloud providers offer storage in more restrictive states including Ohio and Virginia. >But Nevada was what tipped the scales toward Google. It was one additional option offered by Google, but not AWS, that Proov believes will be a safe home for its reproductive health data.

I know that companies would never do this but I will suggest it anyway. Don't store customer data. Instead, cache a copy of the customers encrypted blob in the customers client side application. Customer sets the TTL for their cache to expire. The customer and only the customer may decrypt the data. If they wish to share their data with a health practitioner then they can screen share. If the government want this data, they will have to subpoena every individual customer. No lawful intercept. No intentionally weak frameworks. No "Oops we stored this in an unsecured S3". Just put the data and decryption keys under full control of the hands of the customers. Forward NSL's and subpoenas to the customers. Data retention policies are entirely up to the customer at this point. Create a disclaimer that explains it is on the customer to back up their data and/or decryption keys. If the keys are lost, just start over with a blank slate, or manually put in some stats from a customers copy of a printed report. One could probably even compress/encode the data in a way that a customers printed copy could be ingested into a program to re-encrypt and store it. QRCodes, Dots, etc... One argument against this would be that a company can't run reports on all their customers, use machine learning, etc... to which I say, "Good, cease and desist treating customers like cattle." If there are specific data points that a company wish to gather from its customer base, send a beacon to customers that would ask them if they wish to volunteer this specific data and make it painfully clear who will have access and for how long and how the data will be anonymized. Before a customer clicks "Send" they get a highly detailed display of what exactly is being shared in easily human readable format.