I think it’s about time we took a good hard look at how we want to handle the issues of privacy and in the extension of that how we should handle upgrades and security warnings.
Currently Habari fetches the beacon (http://www.habariproject.org/beacon/ ) which in itself is a great idea, but it does pose certain privacy issues as it is right now. Sure, we don’t get any data besides the IP address of the installation that requests it, but our users have no real way of deciding if they want this information to be recorded. In extension to this, there is HPM and upgrade features planned, all relies on fetching information from a central repository and then presenting it to the Habari admins out there.
While this is a great idea, one that I endorse strongly, my stance is that we should in _no_ way “phone home” by default. Even if the data we potentially collect is benign, we just shouldn’t do it ™. Software that automatically contacts an external service doesn’t look good in my book, and my opinion is that we should not enforce this behavior on the community.
My suggestion is that we make all these wonderful features available as soon as possible, but that it is not enabled by default. We should make it inherently clear that we strongly advise that these features be enabled, but they should not be enabled by default. In addition there should be clear information available on what data we might collect, and what we use it for.
On IRC today we had a long discussion regarding how this would work, and how we could potentially govern it. While there were a lot of great ideas on how this should be done, I do think that’s a bit premature. We really need to make a principal decision on how Habari should handle these kinds of privacy issues first. Talking about implementation of the consensus made should only be done after we have reached a formal decision.
We also need a formal privacy policy that explains what data we might potentially collect and how we utilize it. Sean has added some points to the wiki sandbox on http://wiki.habariproject.org/en/Policy_Sandbox#Privacy_Standards – we should work on getting that fleshed out in a proper manner and then moved to a new permanent url after it goes official.
Could we please get a discussion that hopefully ends up with a formal vote that outlines how Habari should handle issues like this?
Christian
> Users are stupid.
I did not!
~Randy ;)
You’re argument that ”everyone else does it”, just doesn’t cut it for me. Just because others do it, doesn’t make it right nor ethical. To be honest, this is an extremely important thing for me, and I would be deeply saddened if the Habari community decides to continue to enable these features by default.
Christian
Slippery slope argument. I dislike the fact that all these
applications phone home so regularly. Invariably their connection
home interrupts my normal workflow.
> Sure some paranoid people complained at first, but how
> many people have actually not used the software on that ground?
I stopped using WordPress, in no small part, because the core
development community pretty resoundingly rejected privacy concerns
raised on the wp-hackers mailing list.
> Do we want to incur the wrath of 10's of people because we "phone home" or
> 1000's of people because we're known for being buggy and insecure because
> people never update their blogs?
You're making up numbers. We have no formal metric on this.
> Users are stupid. It hurts, but it's 100% true. Sometimes you have to
> protect them from themselves... Given the amount of data companies like
> Google have on individual people (and much more easily linked to those
> people), the fact that Habari "phones home" to make sure I'm still safe is
> way down on my list of concerns.
Your list of concerns are not mine. I don't want you making decisions for me.
We can make a lot of decisions for our users -- for example, we can
decide that they absolutely must use PHP 5.2 to enjoy Habari -- but I
think it's an extremely poor action on our part to make privacy
decisions for them.
I know people who refuse to use Google due to privacy concerns. These
are extremely tech- (and obviously privacy-) savvy individuals, and I
think they'd enjoy using Habari. We could benefit from their
technical expertise on a wide range of subjects. Your cavalier
attitude toward their personal privacy will be a gigantic turn off for
them.
Christian wrote:
> My suggestion is that we make all these wonderful features
> available as soon as possible, but that it is not enabled by
> default. We should make it inherently clear that we strongly
> advise that these features be enabled, but they should not
> be enabled by default. In addition there should be clear
> information available on what data we might collect, and
> what we use it for.
How would folks feel about a checkbox on the installation screen that
read, in effect, "Please check for Habari updates automatically"? The
help icon could expand to include some brief verbage about the
process, and links to relevant documents (the manual section
describing the beacon, our formal privacy policy, etc). If the box is
checked during installation, the plugin is activated and the user
agrees to the data collection we perform.
Cheers,
Scott
You're argument that "everyone else does it", just doesn't cut it for me. Just because others do it, doesn't make it right nor ethical. To be honest, this is an extremely important thing for me, and I would be deeply saddened if the Habari community decides to continue to enable these features by default.
Something along those lines is what I am envisioning, but again I really want us as a community to make an active choice as to how we want to treat these kinds of issues.
I suggested we make a "yes/no" option in the installer, with none of them with a default value. That way users would have to make an active choice to get any of them. Simply put, the installer wouldn't continue unless you made a choice.
Christian
Slippery slope argument. I dislike the fact that all these
On Mon, Jun 9, 2008 at 5:25 PM, Chris Meller <ch...@doesnthaveone.com> wrote:
> While having a formal privacy policy is obviously a good thing, I think the
> benefits of having users running semi-recent software far outweigh the
> potential down-side to "phoning home". *Everything* checks for updates these
> days. From Windows to Adobe products to antivirus to twhirl. Even WordPress
> checks for updates.
applications phone home so regularly. Invariably their connection
home interrupts my normal workflow.
> Sure some paranoid people complained at first, but how> many people have actually not used the software on that ground?I stopped using WordPress, in no small part, because the core
development community pretty resoundingly rejected privacy concerns
raised on the wp-hackers mailing list.
You're making up numbers. We have no formal metric on this.
> Do we want to incur the wrath of 10's of people because we "phone home" or
> 1000's of people because we're known for being buggy and insecure because
> people never update their blogs?
Your list of concerns are not mine. I don't want you making decisions for me.
We can make a lot of decisions for our users -- for example, we can
decide that they absolutely must use PHP 5.2 to enjoy Habari -- but I
think it's an extremely poor action on our part to make privacy
decisions for them.
I know people who refuse to use Google due to privacy concerns. These
are extremely tech- (and obviously privacy-) savvy individuals, and I
think they'd enjoy using Habari. We could benefit from their
technical expertise on a wide range of subjects. Your cavalier
attitude toward their personal privacy will be a gigantic turn off for
them.
How would folks feel about a checkbox on the installation screen that
read, in effect, "Please check for Habari updates automatically"? The
help icon could expand to include some brief verbage about the
process, and links to relevant documents (the manual section
describing the beacon, our formal privacy policy, etc). If the box is
checked during installation, the plugin is activated and the user
agrees to the data collection we perform.
Chris Meller wrote:
> Users are stupid. It hurts, but it's 100% true. Sometimes you have to
> protect them from themselves... Given the amount of data companies like
> Google have on individual people (and much more easily linked to those
> people), the fact that Habari "phones home" to make sure I'm still safe is
> way down on my list of concerns.
In all honesty, had you made this comment at any point before joining
the PMC, I would have seen it as sufficient to oppose your inclusion.
Yes, I'm being harsh, but it's because this sentiment is directly
opposed to the core philosophy of Habari. We not only believe that users
are _not_ stupid, but that they are smart enough to do a better job of
creating this software than we are. We need to earn their trust, not the
other way around. They can be as cavalier about their privacy as they
wish, but we cannot, because it's not our data. Nothing we do, by
default should require an internet connection of any sort.
Yes we should make every effort to warn people of problems, and advise
them of what we believe is the best practice, but it is not our place to
assume we know better than they do how their privacy should be managed.
I'm not all that concerned about my own privacy, but I am in no way
comfortable deciding what an "acceptable" level of data collection is
for someone else. Is just an IP address acceptable? What about a site
URL? A list of installed plugins? A list of usernames? I'm willing to
bet that where that line falls for me is different than it is for many
other people.
I also think that a default mindset of "we have no way to be sure people
will upgrade quickly" will encourage us to make things as secure as
possible throughout the process rather than "if it's a problem we'll fix
it with a patch".
- --
Sean T Evans
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFITalLmQpMBUWJpdsRAtRnAJ9S/fNRsJIhQeP7oMs0xXIxo7Cw+wCg0vV7
vucehjQ/BgY9VzEXoKOA9ko=
=bREg
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In all honesty, had you made this comment at any point before joining
Chris Meller wrote:
> Users are stupid. It hurts, but it's 100% true. Sometimes you have to
> protect them from themselves... Given the amount of data companies like
> Google have on individual people (and much more easily linked to those
> people), the fact that Habari "phones home" to make sure I'm still safe is
> way down on my list of concerns.
the PMC, I would have seen it as sufficient to oppose your inclusion.
Yes, I'm being harsh, but it's because this sentiment is directly
opposed to the core philosophy of Habari.
We not only believe that users
are _not_ stupid, but that they are smart enough to do a better job of
creating this software than we are. We need to earn their trust, not the
other way around. They can be as cavalier about their privacy as they
wish, but we cannot, because it's not our data.
Nothing we do, by
default should require an internet connection of any sort.
Yes we should make every effort to warn people of problems, and advise
them of what we believe is the best practice, but it is not our place to
assume we know better than they do how their privacy should be managed.
I'm not all that concerned about my own privacy, but I am in no way
comfortable deciding what an "acceptable" level of data collection is
for someone else. Is just an IP address acceptable? What about a site
URL? A list of installed plugins? A list of usernames? I'm willing to
bet that where that line falls for me is different than it is for many
other people.
I also think that a default mindset of "we have no way to be sure people
will upgrade quickly" will encourage us to make things as secure as
possible throughout the process rather than "if it's a problem we'll fix
it with a patch".
I firmly believe users should have to make a decision to have any bit
of their privacy infringed upon.
Yes, there are security concerns: but, in my opinion, privacy concerns
trump security concerns. This is especially true when the issue can
very easily be negated by a simple check box.
I think the fundamental philosophy should be that Habari will share
absolutely nothing about me or my server unless I give it permission
to.
Many, actually.
I recall a concern a while ago about a battered wives support group
offering a knowledge base via the web using some other easily recognized
software.
The site was a very valued resource to women who might not have other
people to talk to about these issues. They were rightfully concerned
about the usage of data collected by the software they installed and
used to maintain an otherwise very private and exclusive community.
Imagine if a separate system existed that collected usage data of their
site, and somehow one of their abusive husbands obtained that data.
Using IP addresses and other information in those logs, he might be able
to track her down.
Honestly, if that system was Habari, I'd pack in the whole thing right then.
This was a genuine, real concern that could have shut down an actual
site. These are rightfully paranoid people. I am sure there are many
groups like this. I would hope that Habari can be a part of their
solution by providing a package that allows its users to remain truly
anonymous if that's required.
That said....
> Users are stupid. It hurts, but it's 100% true. Sometimes you have to
> protect them from themselves... Given the amount of data companies like
> Google have on individual people (and much more easily linked to those
> people), the fact that Habari "phones home" to make sure I'm still safe
> is way down on my list of concerns.
The sentiment that "users are stupid" is a bit crude, but fundamentally,
most users of our software will not truly consider the security
ramifications of their decisions.
These automated update questions are primarily about keeping each Habari
instance secure. I think we should make it easy for users to make a
correct decision about security, and that decision is going to be a
personal one - whether they place more weight on their privacy or the
vulnerability of their server to attack. It is a decision that I think
we can't make for people, but one that we can help our users make better.
It would be my preference to include in the installer a choice between
three options with verbiage similar to the following, including links to
pages on our site with more information:
* Allow this installation of Habari to contact the habariproject.org
server to check for periodic security updates and feature improvements.
Your IP address, domain, and list of active plugins will be sent to
the hp.o server. (Recommended.)
* Do not share your server IP, plugin list, or other server details with
habariproject.org. Receive no notifications of security updates. Other
features of the application (such as pingbacks) or plugins may make
external contact to other sites and share this private information.
* Disable Habari's internal mechanism for making connections to external
sites. Do not link to Habari sites from within the admin, so that
referring sites cannot be traced. Receive no notifications of security
updates. Plugins must be reviewed to verify that they do not use their
own code for making external connections, which may share private data.
Perhaps all three of these options are more than what is required
(everyone seems to be considering the first two only, but I think the
third is a valuable option to consider), but I do want to make two
points about them.
First, allowing the contact is absolutely recommended for a very good
reason: Disabling update notifications places the responsibility of
learning of security updates on the site admin. It trades an automated
mechanism of keeping the site's own data secure for keeping only the
data that would be sent over the wire (data that is open to scrutiny due
to the open source code) secure.
Consider as an extreme: If a bug somehow exists that exposes of all
your private data - your whole database - to the internet, is that more
serious than letting habariproject.org know your IP address and the
plugins you have installed? I think that the potential for more
significant security issues is greater when you don't perform critical
upgrades, even for people would would initially be more concerned about
privacy of IP address, domain, etc. At least, it merits their serious
consideration, and should be presented to users.
Providing the option still lets you make the choice. Providing a
recommendation hints to users who don't know which option is best for
them an option that is more secure. We're not making decisions for
anyone - we'd simply be saying that if you don't know what to do, don't
have any specific security need, or simply don't care, this option is
the one we recommend.
Second, this should be a separate part of the installer. You should not
be able to proceed with installation until you make this choice.
Whether you even have the option to change your mind later should be
something presented in a way that similarly requires a conscientious choice.
It's also worth noting that just because we might allow a user to turn
off automated updates for privacy reasons, that does not exclude us from
providing periodic reminders to them to go update their software. Our
beacon system currently does no more than that anyway, it just knows
when updates are released as opposed to reminding you to check at
periodic intervals.
There are many more concerns to this issue than we're really uncovering.
In one of the options above, I talk about not linking to the Habari
site. That would potentially allow us to track referers from "private"
sites. There is the idea of running sites in an intranet, and whether
the software should be able to simply disable outbound calls for the
sake of not having the internet connection to complete them.
There are some messages in this thread that liken the security concerns
of a blog to the States' Homeland Security policies. I think that's
funny. Privacy is more important than security? Without security - in
this case, the reasonable expectation that your site data is safe from
intrusion - you don't have privacy! Ben Franklin's quotations about
liberty simply don't apply here.
There is also a whole thread already discussing many of these issues,
one where we never really ended with anything concrete either:
http://groups.google.com/group/habari-dev/browse_thread/thread/d2335fc4b622ef48/
I'm interested in this conversation, although I find myself wondering
what we're arguing about. Is the question whether we should always
phone home or allow users to disable that? I think I've made a more
than reasonable case for an instance where disabling phoning home would
be prudent. If we temper that with good documentation and
recommendations for good security practices, what else can we do?
Owen
Once again, it seems that Owen has managed to step outside the storm and
clarify things quite a bit. Thank you.
I think we're looking at 2 different questions here:
1) Should Habari offer the ability to opt-in or opt-out of any sort of
"phoning home"?
2) If yes, should the ability be set, by default to opt-in or should it
be opt-out.
My answers are
1) yes, absolutely
2) given the suggestions made, the answer can be "neither". We can make
it a radio button on the installer with nothing selected so the user has
to specifically click on an option to continue.
I like the idea of the 3 options Owen suggested. I'd also like to
suggest that whatever portion of the dashboard is given to update
notification if the first option is selected be used to display a "You
have chosen not to allow Habari to check for update notifications. You
may change this setting _here_." message, or some other reminder text to
keep updates in the forefront of a user's mind. That, of course, is an
entirely separate issue.
I also want to publicly apologize to Chris Meller and to the community
as a whole for the bluntness of my previous post. I reacted emotionally
to his phrasing, rather than to the actual idea he was attempting to get
across. None of us benefits from that tone.
- --
Sean T Evans
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFITbjGmQpMBUWJpdsRAknSAJ4hcH9Mp/CwbO9wX7yn7fa5ZJ0qEwCdE6dS
xHlI0eAKTlPye0ntjHDTjm4=
=q4Md
-----END PGP SIGNATURE-----
I like the idea of the 3 options Owen suggested. I'd also like to
suggest that whatever portion of the dashboard is given to update
notification if the first option is selected be used to display a "You
have chosen not to allow Habari to check for update notifications. You
may change this setting _here_." message, or some other reminder text to
keep updates in the forefront of a user's mind. That, of course, is an
entirely separate issue.
I also want to publicly apologize to Chris Meller and to the community
as a whole for the bluntness of my previous post. I reacted emotionally
to his phrasing, rather than to the actual idea he was attempting to get
across. None of us benefits from that tone.
I think the third option is an interesting one. I know from my time
volunteering in the WordPress forums that a lot of people were
genuinely surprised at how often their site contacted other sites.
From pingbacks or trackbacks, to pingomatic. Many of these users
didn't want their site to contact any other site, ever. Such is their
perogative.
I suspect some clever coding could make this third option work, most
of the time. The RemoteRequest class could simply check whether it's
permitted to initiate an outbound connection. Sure, plugins could
work around this, but I think we can safely say that all bets are off
when it comes to activating third-party plugins. Caveat emptor.
> I, too, fail to see what we're arguing about at this point. We seem to have
> agreed on a Yes / No option (of some form or other), but are more interested
> in the "philosophy" of Habari: users aren't stupid and privacy is more
> important than anything, ever.
This issue has raised a lot of passion, and it feels to me like either
"side" isn't making much of an effort to see things from the other's
point of view. There is no absolutely right or wrong answer here:
there is only opinion and preference. We should be respectful to one
another, and make a sincere effort to try to understand one another's
points of view, rather than just dig in our heels and keep repeating
why our way is the one true way.
As for a reminder that I've opted out of automatic updates: no, that
wouldn't annoy me. As long as it's a static display that does not
hinder my ability to use Habari for what I want. I would object to
pop-ups, or anything requiring me to dismiss it to get on with my
work. A static display at the top of the dashboard -- heck, at the
top of every page, would not bother me.
Cheers,
Scott
On Mon, Jun 09, 2008 at 06:52:30PM -0400, Owen Winkler wrote:
>
> * Allow this installation of Habari to contact the habariproject.org
> server to check for periodic security updates and feature improvements.
> Your IP address, domain, and list of active plugins will be sent to
> the hp.o server. (Recommended.)
Perhaps "sent to the hp.o server but not recorded."
--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
It seems that this has been adequately discussed while I've been
asleep.
Perhaps "sent to the hp.o server but not recorded."
On Mon, Jun 09, 2008 at 06:52:30PM -0400, Owen Winkler wrote:
>
> * Allow this installation of Habari to contact the habariproject.org
> server to check for periodic security updates and feature improvements.
> Your IP address, domain, and list of active plugins will be sent to
> the hp.o server. (Recommended.)
As Owen says, insecure software can be a privacy risk too, so it's not
as simple as opt in == more privacy.
I know, but a user isn't going to come and read this thread before
installing :) I'm making a comment on the option description only, not
the substantive issues being discussed.
I will go on record as saying I think we should have the default be
"update me", but I will bow to the overwhelming sentiment expressed in
this thread.
So, no more talky about why, I don't care about that anymore. I only
care about a vote, and moving forward.
So, lets vote people.
I am +1 for an option in the installer that forces the user to choose
their notification setting before they can finish installing Habari.
There will be no option selected (neither yes or no). Once the user
has selected their notification setting the installer will finish.
What say the rest of you?
Chris
~Randy
I agree the default should be 'update me'. I didn't think there was an
overwhelming sentiment otherwise, but perhaps I'm wrong.
> So, no more talky about why, I don't care about that anymore. I only
> care about a vote, and moving forward.
>
> So, lets vote people.
>
> I am +1 for an option in the installer that forces the user to choose
> their notification setting before they can finish installing Habari.
> There will be no option selected (neither yes or no). Once the user
> has selected their notification setting the installer will finish.
I'm +1 for users choosing update notification settings in the installer.