6 ms·

Show HN: Databunker – a GDPR compliant, secure storage for personal data (PII)

106 points by stremovsky 6y ago

Johnyma22 6y ago
Demo goes to 502 bad gateway ;\
- stremovsky 6y ago
  Hi, The demo is fixed now.
throwaway823882 6y ago
I think there would be more value to this project as a standard, and a set of implementations of the standard in different libraries and frameworks. The companies I work for are just going to re-implement this (poorly) in their own language and framework. They generally can't just pick up a single turn-key solution, because they already have 50 custom internal systems with records they need to manage. If there were open source libraries that followed a standard for GDPR record management, they could pick up those libraries and plug the pieces they need together, according to the standard. That would remove a lot bugs from trying to write all the code themselves, and make it easier to integrate different systems.
intricatedetail 6y ago
> and you still need to consult with an attorney specializing in privacy. Governments should be refunding solicitor costs to anyone needing GDPR advice. Otherwise this is just another way to add barriers. If you are on modest income you can forget about setting up a website in the EU.
- jdlshore 6y ago
  The law is quite readable, and the various Data Protection Agencies (country-specific regulators) have provided more concrete guidance. If you're setting up a website that takes a restrained approach to personal data, you don't necessarily need an attorney.
  - stremovsky 6y ago
    Databunker turns basically any startup to be privacy by design compliant.
    - jeffffff 5y ago
      how does it address ip addresses in server logs?
      - stremovsky 5y ago
        Take a look at this article: https://www.freecodecamp.org/news/how-to-stay-gdpr-compliant-with-access-logs/ https://www.freecodecamp.org/news/how-to-stay-gdpr-compliant...
- remus 6y ago
  > Otherwise this is just another way to add barriers. Personally I think pretty much everything in GDPR is just sensible guidelines for how to handle personal data, and if you're not willing to do those things then you probably shouldn't be handling personal data in the first place. Being ignorant of good data practice is not an excuse. > If you are on modest income you can forget about setting up a website in the EU. This is just rubbish. GDPR only applies to personal info for a start so if you don't store personal info then you have nothing to worry about. Even if you do store personal info the vast majority of use cases are really straightforward and require a very minimal understanding of the law to be compliant.
  - Rule35 6y ago
    > GDPR is just sensible guidelines for how to handle personal data And yet it doesn't say "don't give it to me if you don't want me to have it." > GDPR only applies to personal info for a start so if you don't store personal info then you have nothing to worry about. So logging IPs is fine?
    - michaelmior 5y ago
      IP addresses are (probably) considered personal data under the GDPR. https://www.fieldfisher.com/en/services/privacy-security-and-information/privacy-security-and-information-law-blog/can-a-dynamic-ip-address-constitute-personal-data https://www.fieldfisher.com/en/services/privacy-security-and...
  - reitanqild 6y ago
    Furthermore you can often ask them for help (or so I have heard).
NiceWayToDoIT 6y ago
Nice project, although I have question I would appreciate someone can answer. How does in real world "right to forget" works. What is confusing part for me that data that identify you are also required for the business, so how do you draw line what can be forgotten and what cannot. Let say I use some service, then I violate policies of that company, then I exercise my "right to forget", and after they delete my data I sign up again and repeat the entire thing? Second, how does that work in regards to book keeping and tax policies, where you are required to have data about your clients?
- remus 6y ago
  The right to erasure (aka the right to be forgotten) is not universal and only applies in certain circumstances. > Let say I use some service, then I violate policies of that company, then I exercise my "right to forget", and after they delete my data I sign up again and repeat the entire thing? In this case a business (or 'data controller' in GDPR lingo) can use 'legitimate interest' as a lawful basis for processing the users information. Of course the data you kept would have to be proportional to what you're doing. For example, it would be hard to argue that you needed to keep the users billing address history if your services used a simple email black list (this is the 'data minimisation' principle). > how does that work in regards to book keeping and tax policies, where you are required to have data about your clients? As a rule of thumb, if you're using some personal data to comply with another piece of law then that usage is generally exempt from GDPR. Source: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-erasure/#ib2 https://ico.org.uk/for-organisations/guide-to-data-protectio...
  - NiceWayToDoIT 6y ago
    Thanks.
  - tyingq 6y ago
    That does get complicated in the real world. You might need to retain some data for potential future refunds, for example. But perhaps the application that does refunds also does the loyalty program, and the internals of the app aren't always separate enough that you can delete/obfuscate/whatever info from just the loyalty part.
stremovsky 6y ago
Hi guys, Project demo is back to life. Project demo is available at: https://demo.databunker.org/ https://demo.databunker.org/ User account: Phone: 4444 Code: 4444 Admin access token: DEMO Many more info is available at: https://databunker.org/ https://databunker.org/
jonahbenton 6y ago
Really good idea. Excellent to capture the abstraction of a usertoken. Implementation looks like a good start. Good luck to you!
- stremovsky 6y ago
  Thanks!
neitrino2 6y ago
Great Project! Looks very promising!
- stremovsky 6y ago
  Thanks!
canveed 6y ago
Looks interesting, good luck!
- stremovsky 6y ago
  Thanks!
tmd83 5y ago
It seems like a nice idea, the different consent/withdraw/forget workflow. But it seems the core idea is that all user PII is stored in a central table/tables and all other places uses reference. You can do this normally in a regular application, even the old version had only userId (a non PII info without the user table) and the PII was centralized. I think the biggest challenge is getting there where your PII is not spread all over the database and some denormalized PII for performance or whatever reason. I guess the biggest advantage of this project is removing access to the PII by means of joins and such and automatically enforcing access to PII using a restricted API. I guess a premade API makes it much easier to ensure nobody ends up violating that access and integrate PII too closely with the application.
- stremovsky 5y ago
  Thanks for the feedback!
runningmike 5y ago
Nice project. But mind that Some risks are designed by default. 1. Centralisation 2. Search 3. No automatic retention 4. Hard issues for managing online and offline backup/restore are not tackled. 4. Option to use cloud storage/ service 5. Too much details needed for a customerrecord. Text on the site is often incorrect. ‘pseudonymization as a valid solution to store customer data as defined by GDPR.’ This is simple not true. Gdpr measurements are based on defined risks that differ per use case.
- stremovsky 5y ago
  Thanks for the feedback. I would love to clarify all your questions. yuli@privacybunker.io
eivarv 5y ago
I think you should differentiate between (or use one of) "personal data" and "personally identifiable information" – which are different concepts. A user-token – if consistent and mappable – would, for instance, be "personal data" at least for the service provider for a storage solution such as this. Also, like other "self-sovereign identity" and data hubs, services such as this should be very clear that the only privacy-guarantee it can practically make to its users is regarding authorization of first-party access to data. Outside of that, no technical guarantees can be made (whether we're talking caching for legitimate reasons, or sharing/selling data to partners).

106 points by stremovsky 6y ago

Johnyma22 6y ago

Demo goes to 502 bad gateway ;\

stremovsky 6y ago
Hi, The demo is fixed now.

throwaway823882 6y ago

I think there would be more value to this project as a standard, and a set of implementations of the standard in different libraries and frameworks. The companies I work for are just going to re-implement this (poorly) in their own language and framework. They generally can't just pick up a single turn-key solution, because they already have 50 custom internal systems with records they need to manage. If there were open source libraries that followed a standard for GDPR record management, they could pick up those libraries and plug the pieces they need together, according to the standard. That would remove a lot bugs from trying to write all the code themselves, and make it easier to integrate different systems.

intricatedetail 6y ago

> and you still need to consult with an attorney specializing in privacy. Governments should be refunding solicitor costs to anyone needing GDPR advice. Otherwise this is just another way to add barriers. If you are on modest income you can forget about setting up a website in the EU.

jdlshore 6y ago
The law is quite readable, and the various Data Protection Agencies (country-specific regulators) have provided more concrete guidance. If you're setting up a website that takes a restrained approach to personal data, you don't necessarily need an attorney.
- stremovsky 6y ago
  Databunker turns basically any startup to be privacy by design compliant.
  - jeffffff 5y ago
    how does it address ip addresses in server logs?
    - stremovsky 5y ago
      Take a look at this article: https://www.freecodecamp.org/news/how-to-stay-gdpr-compliant-with-access-logs/ https://www.freecodecamp.org/news/how-to-stay-gdpr-compliant...
remus 6y ago
> Otherwise this is just another way to add barriers. Personally I think pretty much everything in GDPR is just sensible guidelines for how to handle personal data, and if you're not willing to do those things then you probably shouldn't be handling personal data in the first place. Being ignorant of good data practice is not an excuse. > If you are on modest income you can forget about setting up a website in the EU. This is just rubbish. GDPR only applies to personal info for a start so if you don't store personal info then you have nothing to worry about. Even if you do store personal info the vast majority of use cases are really straightforward and require a very minimal understanding of the law to be compliant.
- Rule35 6y ago
  > GDPR is just sensible guidelines for how to handle personal data And yet it doesn't say "don't give it to me if you don't want me to have it." > GDPR only applies to personal info for a start so if you don't store personal info then you have nothing to worry about. So logging IPs is fine?
  - michaelmior 5y ago
    IP addresses are (probably) considered personal data under the GDPR. https://www.fieldfisher.com/en/services/privacy-security-and-information/privacy-security-and-information-law-blog/can-a-dynamic-ip-address-constitute-personal-data https://www.fieldfisher.com/en/services/privacy-security-and...
- reitanqild 6y ago
  Furthermore you can often ask them for help (or so I have heard).

NiceWayToDoIT 6y ago

Nice project, although I have question I would appreciate someone can answer. How does in real world "right to forget" works. What is confusing part for me that data that identify you are also required for the business, so how do you draw line what can be forgotten and what cannot. Let say I use some service, then I violate policies of that company, then I exercise my "right to forget", and after they delete my data I sign up again and repeat the entire thing? Second, how does that work in regards to book keeping and tax policies, where you are required to have data about your clients?

remus 6y ago
The right to erasure (aka the right to be forgotten) is not universal and only applies in certain circumstances. > Let say I use some service, then I violate policies of that company, then I exercise my "right to forget", and after they delete my data I sign up again and repeat the entire thing? In this case a business (or 'data controller' in GDPR lingo) can use 'legitimate interest' as a lawful basis for processing the users information. Of course the data you kept would have to be proportional to what you're doing. For example, it would be hard to argue that you needed to keep the users billing address history if your services used a simple email black list (this is the 'data minimisation' principle). > how does that work in regards to book keeping and tax policies, where you are required to have data about your clients? As a rule of thumb, if you're using some personal data to comply with another piece of law then that usage is generally exempt from GDPR. Source: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-erasure/#ib2 https://ico.org.uk/for-organisations/guide-to-data-protectio...
- NiceWayToDoIT 6y ago
  Thanks.
- tyingq 6y ago
  That does get complicated in the real world. You might need to retain some data for potential future refunds, for example. But perhaps the application that does refunds also does the loyalty program, and the internals of the app aren't always separate enough that you can delete/obfuscate/whatever info from just the loyalty part.

stremovsky 6y ago

Hi guys, Project demo is back to life. Project demo is available at: https://demo.databunker.org/ https://demo.databunker.org/ User account: Phone: 4444 Code: 4444 Admin access token: DEMO Many more info is available at: https://databunker.org/ https://databunker.org/

jonahbenton 6y ago

Really good idea. Excellent to capture the abstraction of a usertoken. Implementation looks like a good start. Good luck to you!

stremovsky 6y ago
Thanks!

neitrino2 6y ago

Great Project! Looks very promising!

stremovsky 6y ago
Thanks!

canveed 6y ago

Looks interesting, good luck!

stremovsky 6y ago
Thanks!

tmd83 5y ago

It seems like a nice idea, the different consent/withdraw/forget workflow. But it seems the core idea is that all user PII is stored in a central table/tables and all other places uses reference. You can do this normally in a regular application, even the old version had only userId (a non PII info without the user table) and the PII was centralized. I think the biggest challenge is getting there where your PII is not spread all over the database and some denormalized PII for performance or whatever reason. I guess the biggest advantage of this project is removing access to the PII by means of joins and such and automatically enforcing access to PII using a restricted API. I guess a premade API makes it much easier to ensure nobody ends up violating that access and integrate PII too closely with the application.

stremovsky 5y ago
Thanks for the feedback!

runningmike 5y ago

Nice project. But mind that Some risks are designed by default. 1. Centralisation 2. Search 3. No automatic retention 4. Hard issues for managing online and offline backup/restore are not tackled. 4. Option to use cloud storage/ service 5. Too much details needed for a customerrecord. Text on the site is often incorrect. ‘pseudonymization as a valid solution to store customer data as defined by GDPR.’ This is simple not true. Gdpr measurements are based on defined risks that differ per use case.

stremovsky 5y ago
Thanks for the feedback. I would love to clarify all your questions. yuli@privacybunker.io

eivarv 5y ago

I think you should differentiate between (or use one of) "personal data" and "personally identifiable information" – which are different concepts. A user-token – if consistent and mappable – would, for instance, be "personal data" at least for the service provider for a storage solution such as this. Also, like other "self-sovereign identity" and data hubs, services such as this should be very clear that the only privacy-guarantee it can practically make to its users is regarding authorization of first-party access to data. Outside of that, no technical guarantees can be made (whether we're talking caching for legitimate reasons, or sharing/selling data to partners).