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

I feel like this blends two discrete things

1. Can I have access to my data (the side effects of my interaction with an application) in a portable way?

2. Can I stop or prevent others (like the application author) from having access to my data?

I wonder which -- if users had to choose -- they care more about? I think for most uses its #1 unless its very personal data, in which its #2. I love the idea as presented in this article but I'm not so sure how practical it is. I don't know how much overlap there is between "author has to run application a central server" (can't just be a local app) and "author must not retain data".

Seems like a really awkward space to inhabit.



(Author here)

Hello there! I agree users may want one or both of these features in their interaction with an application, and that their preferences likely vary depending on the type of data we're considering. The way I'm reading what you're saying, there's some sort of tension or tradeoff between the two features that I don't fully understand. Can you help me understand it a bit better? Thank you!


Well for instance the approach that was demonstrated (as I understood it) seems to necessitate a lot of tradeoffs and maybe concessions in app design to meet the authorize criteria. Is it accurate to say that all data provided to the service is stored and operated on locally? I don't know how I would do something like a scheduled notification with that setup unless that too is locally executed (in which case it's all just an app?).

I was thinking more along the lines of how I want the ability to export my data into something machine readable, and then delete it from the server. This allows for most conveniences and flexibility on the authors part to be available, but still provides the user with control over the data.

I think I just wanted to communicate that on the spectrum between no ownership and what your approach proposes, I'm less of a maximalist.

Thank you for the piece and the reply.




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

Search: