WordPress and phone home

[Ryan]

... "This plugin does not coform with wordpress plugin standard updates cannot be handled (Link: What is this?). Do you wish to continue with activation?

That could work I guess.

Still seems like a lot of work for something that works fine the way it is though. If the privacy policy is updated on WordPress.org and there is a small link to it somewhere in the core installer then I'd have thought all of these problems were solved. Anyone that doesn't like the data being sent can install a plugin to block it and the rest of us can happily send our worthless data off to WordPress.org for storage/processing.

[Elpie]

I think it was Mark who mentioned somewhere that hashed URLs are no use as they're too easily faked, which would make it impossible to mine information from the data collected if spammers started to "work" the system.

Everything can be faked. That's not a valid excuse for invading personal privacy. The update check is supposed to be providing a service to end users. It's nice that it can also send PHP and MySQL versions back to WordPress but ultimately, WordPress hasn't been developed to be a data gathering machine for whoever gets to access the data. I think.

[Elpie]

Still seems like a lot of work for something that works fine the way it is though. If the privacy policy is updated on WordPress.org and there is a small link to it somewhere in the core installer then I'd have thought all of these problems were solved. Anyone that doesn't like the data being sent can install a plugin to block it and the rest of us can happily send our worthless data off to WordPress.org for storage/processing.

Don't kid yourself Ryan - the data Automattic gets is worth millions. However, if the core team agree with you then please send the data to me

[chipbennett]

I think it was Mark who mentioned somewhere that hashed URLs are no use as they're too easily faked, which would make it impossible to mine information from the data collected if spammers started to "work" the system.

It could be related to only having slept 4 hours in the past 48, but I'm struggling to find a feasible example of such faking/system-gaming.

Wouldn't it be easier to fake a blog URL than a hash of a blog URL? And, to what end? To skew aggregate data around which development/support decisions might be made? To skew plugin/theme popularity ratings?

Can you give an example of such "working" of the system?

[andreasnrb]

I can't really understand why it was easier to gather a lot of info to solve a problem than having a simple notification box to notify the user that there is one.

[Ryan]

EDIT: Didn't see Chip's quote till after I answered it for Elpie:

... Wouldn't it be easier to fake a blog URL than a hash of a blog URL? And, to what end? To skew aggregate data around which development/support decisions might be made? To skew plugin/theme popularity ratings?

Can you give an example of such "working" of the system?

Everything can be faked.

You can't fake a URL. Either it exists, or it doesn't. If WordPress.org notice that a specific plugin is being used excessively, they can check a bunch of URLs to see if they really are valid WordPress powered sites. You can't do that with a hashed URL.

That's not a valid excuse for invading personal privacy.

I don't consider sending a sites URL after being presented with a link to a privacy policy which outlines what data is being sent, stored and processed to be a breach of privacy.

[Rarst]

Question.

I don't know how fully this pattern from desktop software can be applied to engine/plugins. So if anyone cares to comment on pro/con, please.

Why exactly WordPress.org must manage how all and every plugin gets updates? If mirroring desktop software it is plugin that should be aware where and how to check for its update.

Currently it goes like this:
(plugin) My name is vague name, I am from site sitename.com that runs PHP5, etc... Do you know me and if I have update?
(wp.org) Say what?..

Why not make it:
(plugin) Do you have update for exact_name
(wp.org OR third party server) Yep!
(plugin) Give me that update.
(server) Served!

Model it like PAD files. Add into plugin link to standardized XML file that describes (among other things) latest version and download location.

Non-unique plugin names solved - plugin would only look for certainly compatible information.
Privacy solved - all exchange would boil down to 1-2 HTTP GET requests per plugin: for description file and for updated archive if needed.

[Ryan]

@Rarst - Your route wouldn't give them ability to mine the data stored for useful information like plugin and theme usage patterns.

[chipbennett]

That could work I guess.

Still seems like a lot of work for something that works fine the way it is though. If the privacy policy is updated on WordPress.org and there is a small link to it somewhere in the core installer then I'd have thought all of these problems were solved. Anyone that doesn't like the data being sent can install a plugin to block it and the rest of us can happily send our worthless data off to WordPress.org for storage/processing.

I don't think that, currently, there is any way to block data retention without also blocking update checking.

That is a problem - no, a fatal flaw - with the "just use a plugin" solution.

This seems to be another example of the disconnect: user data belongs to the user, and cannot be transmitted to a third party without disclosure and consent, regardless of how valuable or worthless those data are.

Now, I'm amenable to the "gray area" of allowing data (without explicit consent) to be sent (but not retained) for update-check only. In this case, the "use a plugin" solution is fine, because in order not to send data at all, one would have to accept not performing the update check. Then, data transmitted for retention can be sent separately (with consent).

I know that Elpie has a problem even with that compromise, but I think it can be adequately addressed by a) fully disclosing the data transmission practices, b) providing an opt-out for data retention, and c) stating that use of the update-check functionality constitutes implicit consent for the necessary data to be sent.

[andreasnrb]

You can't fake a URL. Either it exists, or it doesn't. If WordPress.org notice that a specific plugin is being used excessively, they can check a bunch of URLs to see if they really are valid WordPress powered sites. You can't do that with a hashed URL.

Welll you don't need to fake it. You just make an array with real urls and a foreach loop wrapping the updating/installations function which you then deploy to a number of servers and accounts, make simple randomized cron job and of you go. =). I don't think they match IP with domains.


*** disclaimer ***
As I don't know fully what they check on the other side on api.wordpress.org. So take my idea for whats it worth.
**