Updates and Privacy
Christian Mohn
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
Chris Meller
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?
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.
Randy Walker
On Jun 9, 2008, at 5:25 PM, Chris Meller wrote:
> Users are stupid.
I did not!
~Randy ;)
Christian Mohn
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
Scott Merrill
> 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.
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
Chris Meller
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.
I'm all for privacy, but this is something that comes up time and again when software updates and just seems stupid. If you're that concerned about a company or organization having your IP address, shouldn't you re-evaluate your use of their software? Being able to opt-out of updates (which you'll likely perform anyway) is treating a symptom of the distrust disease, not the actual problem.
Christian Mohn
> 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.
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
Chris Meller
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.
Ever considered that it was originally because people complained about them silently checking for updates that caused them to add that annoying workflow-killing update procedure? If you kept hitting a bug only to find out that there was an update available that addressed it, but you had to manually check for that update you'd complain too... Where does the software provider not lose?
> 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?
Yes, obviously I was making up the numbers and exaggerating the difference. The point still remains, regardless of the numbers used. How many people have you seen publicly complain about the updates vs. the number you've seen publicly complain about continued security exploits? We're talking common sense here, not rocket science.
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.
I don't think I'm being cavalier about their privacy. I'm simply being realistic... We could be doing all sorts of evil things to their server and with their data, but they're obviously trusting us not to. How is this any different?
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.
At the very least it should be checked by default...
Christian Mohn (h0bbel)
> If you're at all concerned about the fact that this provider could
> potentially be recording your information, should you be trusting them with
> your server? We could easily be sending all sorts of things back to a
> home-base and just not tell you...
a PHP application that doesn't need reverse engineering or raw packet
inspection to figure out what it is sending helps us a lot in that
regard.
> I'm all for privacy, but this is something that comes up time and again when
> software updates and just seems stupid. If you're that concerned about a
> company or organization having your IP address, shouldn't you re-evaluate
> your use of their software? Being able to opt-out of updates (which you'll
> likely perform anyway) is treating a symptom of the distrust disease, not
> the actual problem.
arbitrarily decide what the community wants in this regard, while my
suggestion simply leaves the decision up to them? What seems more
community friendly? I wonder.
Sean T Evans
Hash: SHA1
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-----
Chris Meller
-----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.
So much for welcoming opposing viewpoints... :\
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.
Working in an IT helpdesk is far different than working with the kinds of people who can procure web hosting, check out SVN (or download a zip and upload it), setup a database, and install a software package. No matter what your expectations going in, you'll eventually realize that the reality is much much worse. Many companies think developers should have helpdesk / support experience because it gives them insight into the minds of their target audience. This in turn helps you develop more user-friendly ( / idiot-proof) software.
I fully admit that there are any number of things we can learn from our users, and many which we can't learn anywhere else. At the same time, they have placed trust in us to run our software (which a normal user doesn't know how to examine the code of). That trust includes keeping them safe from un-necessary threats. Like I said before: if you can't trust the written privacy policy of the people whose software you're using, should you be using their software? There are many worse things I could do than collect your GUIDs once you run my code on your server...
Nothing we do, by
default should require an internet connection of any sort.
I would say that this is becoming increasingly unreasonable even for client-side applications, but a web-based blog?
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".
Absolutely, but having no way to get those updates out to people once they are (and invariably will be) available is stupid.
I'm not nearly as passionate about this issue as the privacy advocates are, I simply think we should do everything possible to keep users safe. Christian's suggestion of requiring a Yes / No response in order to continue the installer is a good idea, but what happens a month (three? six? twelve?) later when they've forgotten all about updates? Do we now nag them every x days, or just assume they're being security conscious and let the blog go to hell if they're not? It's not a one-stop solution...
Arthus Erea
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.
Christian Mohn (h0bbel)
On Jun 10, 12:29 am, "Chris Meller" <ch...@doesnthaveone.com> wrote:
> I'm not nearly as passionate about this issue as the privacy advocates are,
> I simply think we should do everything possible to keep users safe.
> Christian's suggestion of requiring a Yes / No response in order to continue
> the installer is a good idea, but what happens a month (three? six? twelve?)
> later when they've forgotten all about updates? Do we now nag them every x
> days, or just assume they're being security conscious and let the blog go to
> hell if they're not? It's not a one-stop solution...
change in x months time? I fail to see that point? If they opt-out,
they are on their own. This is what we need to make clear for the
users, and have them decide based on that.
Christian Mohn (h0bbel)
On Jun 10, 12:29 am, Arthus Erea <arthus.e...@gmail.com> wrote:
> I think the fundamental philosophy should be that Habari will share
> absolutely nothing about me or my server unless I give it permission
> to.
upon.
Christian
Chris Meller
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 agree entirely. Hell, I've made it through the Bush administration... I just don't see how, even if we logged IPs and GUIDs sent from them (which our privacy policy would clearly say we don't), this could in any way be any sort of privacy concern. There's simply no downside...
I think the fundamental philosophy should be that Habari will share
absolutely nothing about me or my server unless I give it permission
to.
But we're not actually sharing anything... that's the point. If we were sharing something, I'd totally agree that updates were bad, but we're not. Even if we *did* record IPs and their GUIDs, what could that *possibly* compromise?
A yes / no prompt, as long as Yes - I want updates is clearly the preferred response (for those users who don't know which to pick on their own), is fine... I just still fail to see what the problem here actually is.
Owen Winkler
> 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. Sure some paranoid people
> complained at first, but how many people have actually not used the
> software on that ground?
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
Christian Mohn (h0bbel)
in line with what I would love to see. Opt-In, with a clear
recommendation as to what you actually do if you don't (As well as if
you do).
Well said, and you summarize a whole two hours of IRC discussion in
one single post to the maillinglist. As I said on IRC; I love you. ;-)
Christian
Chris Meller
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.
Arthus Erea
On Jun 9, 6:51 pm, "Chris Meller" <ch...@doesnthaveone.com> wrote:
>
> > 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 agree entirely. Hell, I've made it through the Bush administration... I
> just don't see how, even if we logged IPs and GUIDs sent from them (which
> our privacy policy would clearly say we don't), this could in any way be any
> sort of privacy concern. There's simply no downside...
>
> > I think the fundamental philosophy should be that Habari will share
> > absolutely nothing about me or my server unless I give it permission
> > to.
>
> But we're not actually sharing anything... that's the point. If we were
> sharing something, I'd totally agree that updates were bad, but we're not.
> Even if we *did* record IPs and their GUIDs, what could that *possibly*
> compromise?
Really? So how will the updates be received? In fact, what goes in the
packets? Because it sure as hell isn't nothing.
ringmaster makes a very good point about situations where even IP
addresses would be too much information.
There are all sorts of scary things which could be done with a list of
IP addresses, especially with a list of IP addresses linked to
bloggers.
The point is that by forcing people to send information to our server
we are forcing them to trust us with that data.
Sean T Evans
Hash: SHA1
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-----
Chris Meller
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.
Would that not annoy Scott? He's already opted out, why does this *@#!$)&% thing keep annoying him?
I think it's a great idea (hell, it should be big, red, bold, and blinking), but on the off chance I cared enough to turn off updates it would probably annoy me...
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.
Thank you. :)
Scott Merrill
> I think the third option is a bit of a nonsense choice. There's no way we
> can *guarantee* that your site won't send *any* information to *any* other
> site *ever*, so I think presenting that impression is just asking for
> trouble. As they say, never say never.
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
Arthus Erea
> 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.
interval (once a month). Not very annoying, but reminds me that my
install is potentially insecure.
Michael C. Harris
asleep.
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
rick c
feeling is that opt out is bad, opt in is okay.
I really have little to add to the thread other than Habari should
have the ability to phone home to check for updates. This ability
should basically be an opt-in option, with the user having to make a
conscious decision to opt-in or opt-out. And the option shouldn't be a
one shot thing. Somewhere on the options page the ability to change
your mind should always exist. Habari should have a formal privacy
policy stating what is done with the information the server receives
if the user opts into receiving update notifications.
Any further options, such as Owen's third option, would be good, but
it is in the nature of protecting the user from themselves and may be
better added only to the options page or as a plugin to be activated
by the user, not as an installation option. Unless a plugin is doing
something it shouldn't, any attempts to connect to other sites is the
result of a plugin the user activated themselves, hopefully with the
knowledge of what they were doing.
If I did opt into receiving update notifications, I'm one of those who
would be irritated by seeing a reminder on every page or even just my
dashboard every time I go to it. A tool I use now does this and is one
of the reasons I can't wait to be able to get away from it. But that's
just me. :) I wouldn't mind an occasional reminder to check for
updates because we do tend to forget things.
Rick Cockrum
Chris Meller
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.)
FWIW, we were never talking about recording anything.
Chris Meller
It goes away as soon as you update it, duhhh. That's the point! :)
I still think a "we don't send out data, ever" policy would be a pain in the end. I think users would get a potentially misleading sense of "security" or "privacy" when it doesn't necessarily apply. A false sense of security is more dangerous than no sense of security at all. And if the logic we use is that "you activated the plugin, you know what it does" that could easily extend to Habari as a whole and re-open the entire argument...
Arthus Erea
On Jun 9, 9:02 pm, rick c <rickcock...@gmail.com> wrote:
> If I did opt into receiving update notifications, I'm one of those who
> would be irritated by seeing a reminder on every page or even just my
> dashboard every time I go to it. A tool I use now does this and is one
> of the reasons I can't wait to be able to get away from it. But that's
> just me. :) I wouldn't mind an occasional reminder to check for
> updates because we do tend to forget things.
notifications."
If you opted into receiving update notifications, you would only get
notifications when the update is available and installed/installable.
If you opted out, my thought was to give a once a month reminder to
check for updates.
Michael C. Harris
>
> Privacy isn't something to be taken lightly. Stated in short terms, my
> feeling is that opt out is bad, opt in is okay.
As Owen says, insecure software can be a privacy risk too, so it's not
as simple as opt in == more privacy.
Michael C. Harris
> On Mon, Jun 9, 2008 at 8:17 PM, Michael C. Harris wrote:
> > 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."
>
> FWIW, we were never talking about recording anything.
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.
rick c
On Jun 9, 9:20 pm, "Chris Meller" <ch...@doesnthaveone.com> wrote:
receiving update notifications, I wouldn't want to see a reminder
constantly.
> I still think a "we don't send out data, ever" policy would be a pain in the
> end. I think users would get a potentially misleading sense of "security" or
> "privacy" when it doesn't necessarily apply. A false sense of security is
> more dangerous than no sense of security at all. And if the logic we use is
> that "you activated the plugin, you know what it does" that could easily
> extend to Habari as a whole and re-open the entire argument...
"...any attempts to connect to other sites is the
knowledge of what they were doing. "
to block plugins from contacting other sites. As Scott said, this
should be possible, but not foolproof. I agree that a misleading sense
of security or privacy is worse than no sense of security. On a lesser
scale, having a spam filter installed isn't 100% effective in blocking
spam, but does that mean we shouldn't install one?
Rick Cockrum
Arthus Erea
1) request updates
2) don't request updates
Stopping 3rd party plugins from contacting the outside world would be
very hard to do, in addition to having relatively little benefit.
Additionally, the third option could potentially lure users into
trusting all plugins, even with inherit risks.
Finally, it has a potential usability issue. When I'm going through
the install, I decide upon the third option because I am very privacy
conscious. I blog away, etc. Months later, I am told I should be
sending pingbacks to other blogs by a friend of mine. I think it over,
and decide I'm willing to do so. Therefore, I go and enable the
pingback plugin.
Yet, nothing is happening. It appears broken. I'm not likely to
remember the decision I made when I installed to not allow plugins to
make any contact to outside. Thus, I'm confused and distressed.
Finally, from a core perspective options 2 and 3 are the same: when no
plugins are active, the only pinging would be updates which are
disabled by option 2.
Here's a challenge: name a plugin which I would activate, which sends
data out, which I wouldn't want to send data out?
Chris J. Davis
opt-in solution that does not allow you to proceed in the installer
until you either opt-in, or say no, I don't want to be notified of
updates.
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
rick c
their notification setting before they can finish installing Habari.
Randy Walker
~Randy
Michael C. Harris
>
> Okay, so having read this thread, it seems we have agreed to have an
> opt-in solution that does not allow you to proceed in the installer
> until you either opt-in, or say no, I don't want to be notified of
> updates.
>
> 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.
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.
Christian Mohn (h0bbel)
section. I heartly condone Owens suggestion of options.
I am strongly -1 to leaving the opt-in feature the default during
installation. If something should be default, it should be opt-out but
I'm positive to the idea of not having any default option and letting
the user decide before the installation finishes.
Christian
On Jun 10, 5:58 am, "Michael C. Harris" <michael.twof...@gmail.com>
wrote:
Ali B.
Blake Johnson
selection, but we should certainly encourage users to enable update
notification.
--Blake