9 responses

1. Some bloggers are reporting that WordPress 2.3 spies on users. There is a discussion taking place on Google Groups. You can also find the story at Digg.

2. I would very much disagree that there is any spying. There was an article suggesting the same that made it on to Slashdot, but it was updated and the title was changed. People seem really excited that the update feature includes your blog URL, which is as public as any information I can imagine.

   Rose, were there any specific concerns you had?

3. Ye gods, tis the man himself. Welcome Matt. Shouldn’t Donncha be the one putting out fires on Irish blogs? :)

   The word “spy” is certainly a bit OTT, but to be fair to Rose, she didn’t say that. And, having reviewed the Google Groups discussion (via Digg, thank you Rose), both WordPress 2.3 and Akismet suck in more information than they need; way, way too much information in the case of Akismet.

   What could you possibly want ALL the $_SERVER vars for? And why does WordPress need to know our blog URLs and plugin version numbers? If you want it for stats, you should say so during the install and allow people to disable it.

   You do great work Matt, but can you really afford another so-called ‘scandal’? I’d hate to see a crappy platform like MT ‘win’ because of something as silly as this. Take it out, re-release, imho.

   Completely aside from this issue, I have to say I’m not happy with my first few hours with 2.3 Matt. It’s slow as hell for me. Could be a local thing, but I’m worried.

   adam

   PS. While I think of it: please, please add a config var that allows me to turn off the Dashboard. I have no interest in that crap.

4. Your blog does seem a bit slow here, but 2.3 shouldn’t impact your front-end performance, which I know because I recently upgraded the 1.5 million blogs on WordPress.com to it, and the backend should feel faster because of the JS improvements.

   Akismet has run the way it has for 2+ years now and there have never been security or privacy problems. The same general argument was raised when Akismet was released and over time everyone realized it was a non-issue. On the mailing list someone pointed out some possible improvements to its exclusion and they’ll be in the next release. It was headers only in certain setups of PHP + Apache + HTTP Auth, I hadn’t seen them before, so didn’t know to exclude when the code was first written. Anyway there are lots of ways to interact with the Akismet API besides the default plugin, so maybe another one would suit you better? We don’t force it on anyone and of course it’s governed by a strict privacy policy.

   As for the dashboard, it’s all pluggable, and there are several plugins to replace it all.

5. It’s probably a local thing Matt, I’m between DC’s atm. :)

   I understand that Akismet’s been like that for a while, and I’m sure you have a strict privacy policy, but you didn’t answer my question: Why do you need the information? If you don’t need it, why take it?

   I realise the Dashboard is pluggable, and I appreciate that you’ve just added hooks, I just can’t understand why it’s enabled by default.

   adam

6. It’s enabled by default because based on the feedback we have it’s generally useful to a majority of WordPress users, and for those that it isn’t it’s easy to turn off. That’s the decision process we make for any default setting.

   For Akismet the extra info makes it more effective, but we don’t comment on the inner workings of the system.

7. I take your point Matt, but I wouldn’t consider it easy to turn off, unless there’s a checkbox or button I’m missing. Installing plugins is relatively easy, but checkboxes and buttons are easier.

   Fair enough on Akismet, spam control is hard and data can make it easier. You’re making pull answers ike teeth though, and I hate that: Why does v2.3 need blog URLs and plugin version numbers?

   (I really appreciate you coming here and answering my questons. I’m sure you have better things to do and you’re probably just skimming my posts. But, well, we all have better things to do, you know?)

   Thanks,
   adam

8. I agree a checkbox in core would be easier than a plugin. The problem becomes that in WP there are thousands of things that people disagree with just like you disagree with the dashboard and if we were to make each one an option WordPress would become or appear very complex, there would be a high cognitive load on configuration, and we’d have to test all the possible combinations of the options, which could be astronomically high.

   Adding a hook or filter is essentially no-cost, and by keeping what we consider niche customizations to plugins we can keep the core of WordPress small and light while still allowing for a range of experiences.

   Of course once we have better data on which plugins are actually used vs just downloaded we can make more informed decisions about these things. If a significant portion of our userbase installed a dashboard plugin, it’d definitely make us reconsider adding an option.

9. I hope you’re not using that as a way to explain your data-gathering Matt. All the update checker needs to do is pull down version numbers for the installed plugins, it certainly doesn’t need to send them to api, and it absolutely doesn’t need the blog URL. You still haven’t answered that question, three comments later.

   adam