Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is good to hear. I have spent a lot of time looking at this topic, and for me there's 3 things worth exploring.

1. Versioning of user consent.

A lot of services have been designed around the idea that once a user consents to the terms, they consent to any alternations you make in the future. This is legally very questionable, at least in many countries. Some services manage to keep track of the version of the agreement a user has approved, but then force agreement with any updated version. But in reality there's no need for this - users should be able to granularly consent (and withdraw consent) to different things, as and when it's desired.

In any case given the way this is interpreted in GDPR, and the direction of travel in California and other states, having granular consent seems to be a sensible short term investment to save a lot of pain down the line.

2. Handling data at a sale, acquisition or liquidation.

This one is more tricky, and I believe a Stripe co-founder mentioned this recently on HN as something to look into. Lots of companies see their database as an asset to sell. There's an interesting history of companies like RadioShack, ToysRUs, and others going through this issue and ending up in court over it...

3. Aligning your goals with your users.

It might be a bit idealistic, but it always seems to me that privacy works best when everyone's interests are aligned. I'm not sure how this fits for your situation, but it strikes me users wanting visibility get visibility, and if they get a job you'll benefit, as do they. That seems nicely aligned. And for people who want to be incognito, they remain incognito, but they know you're there. It's probably counter to lots of the "startup playbook", but even these incognito users are likely still valuable, maybe even net promoters, just not currently looking to be seen. So it seems your goals align nicely with users', and there need not be any hyper growth "dark patterns".



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: