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 T. 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?
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?
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.
On Mon, Jun 9, 2008 at 4:59 PM, Christian Mohn <h0b...@gmail.com> wrote: > 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?
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
From: habari-dev@googlegroups.com [mailto:habari-dev@googlegroups.com] On Behalf Of Chris Meller Sent: 9. juni 2008 23:26 To: habari-dev@googlegroups.com Subject: [habari-dev] Re: Updates and Privacy
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?
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.
On Mon, Jun 9, 2008 at 4:59 PM, Christian Mohn <h0b...@gmail.com> wrote:
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 T. 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?
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.
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.
On Mon, Jun 9, 2008 at 5:31 PM, Christian Mohn <h0b...@gmail.com> wrote: > 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.
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...
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.
> 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.
On Mon, Jun 9, 2008 at 5:39 PM, Scott Merrill <ski...@skippy.net> wrote:
> 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.
> Slippery slope argument. I dislike the fact that all these > 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.
> > 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.
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...
> 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...
Sure. Hence the privacy policy and the openness around it. This being
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.
Why should you decide what I want to do? You seem to want to
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.
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
> 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.
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...
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.
On Jun 9, 6:06 pm, Sean T Evans <se...@morydd.net> wrote:
> 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
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...
If they enable update notification, they get notified. How does that
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.
On Mon, Jun 9, 2008 at 6:29 PM, Arthus Erea <arthus.e...@gmail.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?
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.
Chris Meller 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. 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:
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?
Yes! The three options presented here are excellent and is very much
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
On Jun 10, 12:52 am, Owen Winkler <epit...@gmail.com> wrote:
> Chris Meller 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. 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:
> 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?
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, 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.
On Mon, Jun 9, 2008 at 6:52 PM, Owen Winkler <epit...@gmail.com> wrote:
> Chris Meller 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. 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:
> 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?
> On Mon, Jun 9, 2008 at 6:29 PM, Arthus Erea <arthus.e...@gmail.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?
So IPs and GUIDs aren't "anything?" They're absolutely nothing?
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.
Owen Winkler wrote: > Chris Meller 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. 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:
> 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
On Mon, Jun 9, 2008 at 7:12 PM, Sean T Evans <se...@morydd.net> wrote:
<snip>
> 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.
On Mon, Jun 9, 2008 at 7:04 PM, Chris Meller <ch...@doesnthaveone.com> wrote: > 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.
On Jun 9, 7:30 pm, "Scott Merrill" <ski...@skippy.net> wrote:
> 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.
Another option would be sending a notification at a reasonable
interval (once a month). Not very annoying, but reminds me that my
install is potentially insecure.
It seems that this has been adequately discussed while I've been 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."
Privacy isn't something to be taken lightly. Stated in short terms, my
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.
