Editing Network services/Model privacy policy approaches to network services
From WikiDotMako
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| Line 1: | Line 1: | ||
= LuisVilla's rant on privacy and autonomous services = | |||
Privacy policies should not be part of the definition of freedom/autonomy-protecting services. Tying privacy and freedom together is similar to tying software quality and freedom. FSF would never say 'code is only free if it has < X bugs per LOC.' Instead, FSF would say that once you use Free Software, you have the freedom to improve the code, share your improvements with others, etc., and that those freedoms are the best way toprotect you from buggy software in the long run. Similarly, just as a buggy codebase might be forked to improve quality, in a truly free/autonomous service, it should be possible for users to decide 'this privacy policy is not good enough' and then fork (or induce others to fork) the ''service.'' So, in my mind, this right to "fork" the service is the key tool by which free/autonomous services would protect privacy, rather than by any specific privacy policy. | |||
Β | |||
This isn't to say that privacy policies are unimportant, just that they aren't central, and that good policies will be a natural side effect of a good free/autonomous service definition. | |||
Β | |||
I'm persuadable on this issue; I realize that the unrestricted sharing of personal information may impinge on autonomy in ways that software bugs do not. But this is my default (perhaps unusual) position and I thought it would be good to get that out of the way now :) | |||
