Sad state of affairs - this is so messed up. No trust anywhere! I’m senior Software Architect in Germany and some years ago we built an app that handles highly confidential tax-related data. And we did everything to stick to the highest standards: Strong encryption, distribution of keys and data into different datacenter operated by different companies, protocols of deletion of data, implementing every aspect of DSGVO, including Art.35 - „creation of a DSFA (Assessment Of Consequences of Data Privacy Measures)“ more than 100 pages thick. Guess what: When I tell customers that we cannot read and really delete their data - they straight up accuse me of lying!
- state level actors can basically break into any computer system given enough time
- corporate databases have a gigantic amount of information on everyon
- states want all of that data
I hope the conclusion is as straightforward as it seems to me.
OK, not exactly what you are responding about Let's talk about corporate IT systems, let's get into "deleted". Is it:
- deleted from backups? Almost universally this answer will be no.
- deleted from each and every database and system in your presumably huge corporation, which may involve literally thousands of IT systems? I'd guess no.
- is it deleted by moving the data to a separate "deleted data" table or database, thus sequestering the data from the "active data" rather than deleting it, just in case you want to "undo"?
- is it deleted from all system logs?
- is it deleted from all records systems that may have minimum retention periods legally or by policy?
- what about data warehouses or data lakes that repackage/mirror data?
That’s an interesting point to add to the feature list of a future product:
“Proof” of deletion that is plausible to laypeople.
Of course one has to delete according to the law, too, but that plausible proof may get rid of a lot of support calls escalating to your level.
> When I tell customers that we cannot read and really delete their data - they straight up accuse me of lying!
I'd accuse you too. If you can't read their data, then the data doesn't exist? Also, if you can't read read their data, how are the customers seeing it on their dashboard?
I try to explain it shortly:
The encrypted data is in a different datacenter than the keys needed to decrypt the data. The services we implemented to bring both together run in an secured environment that has no services implemented to access the servers and where physical access is restricted. Errors and monitoring data gets out, PII does not. Everything is documented and was inspected and certified by a 3rd party.
If a customer requests to delete his data we instantly delete the key, a litte later we delete the (already useless) data and all backups will lose this information about a month later too.
And of course we did that not because we are nice people (though we belive we are). We did it, because we had the hypothesis that a reputation to handle the user-data with proofable utmost respect to security and privacy would be more valuable than having access to this data.
People not believing us or accusing us of lying obviously defy that hypothesis.
Row level encryption, yes it’s possible to break the glass but it’s code changes and that sort of thing is noticed by the org and would be reported on.
In the automotive space we are leaning heavily on confidential computing primitives to make it actually impossible, for example keys generated entirely inside enclaves and only attested software can run on those etc etc.
Fantastic book. I read it for the first time about a year ago but I still think about it once every week or two. Thought about it as soon as the "spaceship" started to accelerate towards light speed.
> I don't think anyone exists who doesn't game and also watch video on the same system.
Actually I have a dedicated computer connected to my TV to watch videos. My gaming computer is dedicated to gaming (and doesn't get much use these days). I have a Linux computer for everything else.
Well it ain't in OpenSUSE Tumbleweed, Arch, or Gentoo. Though I don't know which software is installed out of the box in Fedora, Debian, the many Debian derivatives, and all of the smaller distros out there; so you may still be right.
This is getting to be less and less true. `telnet MACHINE PORT` was my go to quick connectivity test for a couple of decades. And increasingly that's being replaced to me having to think about the right non-telnet way to do it.
Reverse proxies usually require configuration changes to work. Plus they are single points of failure. Server Name Indication (SNI) is a fairly recent development as well - any apps written before that was widespread, or designed in that way, will have a unique web server for every HTTP based service that has its own separately managed certificate.
Reverse proxying is less common in wild IoT devices, network appliances, and certain kinds of enterprise/line-of-business apps... Surprisingly Microsoft IIS seems to be an exception in that area
You're assuming that people are going to use the smartest "best practice" way to do things from your perspective. This is not often what actually happens. It takes forever for people to realize that they should re-architect things to work like this, and that there are benefits to doing so. If you're able to have this happen in a production environment, with no conflicts with other things or other people around you, count yourself lucky...