Kimmo Suominen wrote: > Why are the plugin versions sent to the server? It should be > enough to send the plugin filename and/or name, so the server can > return a list of current versions. The client (WP) can then figure > out which plugins need updating.
The system was designed to keep the client side as light as possible so the heavy lifting can be done on the server side, allowing us a lot more flexibility and agility in adapting the service as it gets rolled out and evolves.
For example right now nothing is done with regards to localization, but because of the data being sent and the lightness of the client side we could introduce that feature in the future without having to update every install of WordPress in the world. This philosophy has worked very well for Akismet over the past 2 years. I believe it is also the best approach for WordPress.
Today the server does basically nothing, no logging, no analysis, no stats, it's just designed to be as fast as possible since I don't know what type of impact 2.3 is going to have on api.wordpress.org. In the future, however, I think there is a lot of room to grow it, particularly once we take updates to the next step and allow people to upgrade/install things with one click from their dashboard.
>> I would also recommend disabling the updates in Mac OS X, Firefox, >> Windows, Thunderbird, Adobe Photoshop, and any other third-party >> applications you have. As all of those are tied to your personal IP >> and not your server IP they have far more implications for privacy.
This takes me back to when I was teaching. I can't tell you the countless students that would say "well X does it so why can't I"?
Now consider these applications you mentioned. Every one of them also has EULA's, privacy statements, etc. Take Windows as an example. Once you complete an install you are presented with the "Stay up to date" option. Also when you install these applications you do agree to the terms laid out within said agreements (think of that little checkbox you must check to install it). Now I concede that a majority of people do not take the time to read what they are agreeing to, but it is there none the less. Having said that, using these applications as an example is nothing more than creating a straw man on the issue.
Now the complaint I am hearing involves the transparency of this feature. When users upgrade, or even install fresh, they are not told anywhere that this information is being sent, let alone any mention or promise that it won't be used for some malicious purpose. That is why I strongly feel an option to opt in/out should be given on the upgrade/install screens.
I want to reaffirm that I know this information will *not* be used for malicious purposes. I actually think it is a good idea. Think of how the stats involving PHP versions versus overall installations would have aided in the PHP4/PHP5 debate.
Yes, but not, as a pointed out several times before, in combination with the installed plugins and their versions.
> > We only have your word for that. And sorry, that is not enough > > for me. Especially if it does not have to be.
> If you don't trust wordpress.org, I suggest you do one of the following:
> 1. Use different software.
Wordpress is a great software. No reason to do so.
> 2. Fork WordPress.
This would be quite stupid. I don't have the time to do so. And I not going to that because of one or two lines of code. I as a coder can easily change those. And this is not what this discussion is about.
> 3. Install one of the aforementioned plugins.
Not an option. The update-notification is one of the reasons to switch to 2.3
On 9/23/07, Matt Mullenweg <m...@mullenweg.com> wrote:
> 3. It could be useful in the future.
What's a potential benefit for users that would require knowing both their URLs and associated plugins, as opposed to knowing just the plugins? _______________________________________________ wp-hackers mailing list wp-hack...@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-hackers
Using their host, you can obtain their home address via whois, and then send them personalized security warnings by snail mail.
Austin Matzko wrote: > On 9/23/07, Matt Mullenweg <m...@mullenweg.com> wrote:
>> 3. It could be useful in the future.
> What's a potential benefit for users that would require knowing both > their URLs and associated plugins, as opposed to knowing just the > plugins? > _______________________________________________ > wp-hackers mailing list > wp-hack...@lists.automattic.com > http://lists.automattic.com/mailman/listinfo/wp-hackers
Matt Mullenweg wrote: > Kimmo Suominen wrote: >> Why are the plugin versions sent to the server? It should be >> enough to send the plugin filename and/or name, so the server can >> return a list of current versions. The client (WP) can then figure >> out which plugins need updating.
> The system was designed to keep the client side as light as possible > so the heavy lifting can be done on the server side, allowing us a lot > more flexibility and agility in adapting the service as it gets rolled > out and evolves.
some heavy lifting, comparing versions. with Akismet the server actually provide a dynamic service to the client, here all it needs to do is to tell it the latest version. it can be as simple as storing a static file on the server.
> For example right now nothing is done with regards to localization, > but because of the data being sent and the lightness of the client > side we could introduce that feature in the future without having to > update every install of WordPress in the world. This philosophy has > worked very well for Akismet over the past 2 years. I believe it is > also the best approach for WordPress.
Localization of what?
I feel like I am wasting my time trying to convince you, but here are my arguments anyway: 1. you have stated yourself that you don't need the url. 2. the url breaks the anonymity of the request, and many people will not like it at all. most will only find about it once it blows up - and by then they will feel installing a plugin to prevent it is like closing the stable after the horses ran away. 3. it will blow up because bloggers are one most privacy aware populations, and I give it less than a week from the official release date. also expect a "Wordpress is spying on users" article on Slashdot (This is not a threat, just an attempt to predict the near future). 4. you can't compare this to sending blog url (and version, why?!) to technorati because people opt-in to send that information, and it's required to provide them with the service they are receiving. 5. you can't compare it closed source programs with high opacity, that may or may not send system information regularly. the reasons are that people does not know what they send (binary/encrypted protocols, no source) and that the companies cover their asses with the EULA. (so in a way the users agree).
Moritz 'Morty' Strübe wrote: > Yes, but not, as a pointed out several times before, in combination with > the installed plugins and their versions.
What if someone knows your blog URL can they hack your blog?
No.
What if someone hacks ping-o-matic or weblogs.com and gets all the blog URLs in the world, can they hack your blog?
No.
What if someone simply subscribes to the list of updated blogs on weblogs.com, can they hack your blog?
No.
What if someone blindly checks for filenames in your wp-content/plugins directory to see what plugins you're using, can they hack your blog?
No.
What if someone hacks wordpress.org and gets a list of blog URLs and the plugins they use, can they hack your blog?
No.
What if wordpress.org also stored what version of a plugin you were using, which there are no plans to do, AND the hacker broke in and stole that, can they hack your blog?
No.
What if you're running an insecure version of a plugin or WordPress, can someone hack your blog?
Yes. And they can (and do) do it without any of the above.
Please reread that.
Will the update notification feature shipping tomorrow in WordPress 2.3 mean fewer people are running insecure versions of WordPress and plugins?
Yes.
Just like there is premature optimization we could argue about for days, I think there is also premature paranoia. What's in trunk is what is shipping with WordPress tomorrow. I don't think your concerns are valid in the real world, and even if you assume a malicious wordpress.org the security and privacy of WordPress users will be no different tomorrow than it is today. It's optimized for a reasonable person, but with hooks and filters for those with niche concerns.
Captain's log. We received a signal from Matt Mullenweg on StarDate 24/09/07 00:29. Translated to English it stated:
> Just like there is premature optimization we could argue about for > days, I think there is also premature paranoia. What's in trunk is > what is shipping with WordPress tomorrow. I don't think your > concerns are valid in the real world, and even if you assume a > malicious wordpress.org the security and privacy of WordPress users > will be no different tomorrow than it is today. It's optimized for > a reasonable person, but with hooks and filters for those with > niche concerns.
Pardon me for asking something which might already have an answer on the Web (I read this before), but do you know the figure that corresponds to #/% of WordPress blogs that run the very latest (as of today), i.e. least insecure version of WordPress?
It's an honest question, by the way; no provocation intended at all, but one has to be realistic. Patching it about liability more than practicality, IMHO.
How are your responses constructively debating the issue at hand? Nothing personal, but IMO this is the wrong kind of approach from your position. So if an individual using the open source software (which theoretically anyone can contribute to) is questioning what a feature of the software is worth, you tell them to put up and shut up, or leave altogether?
I may regret sending this email, but this response just stoked a reaction from me.
On 9/23/07, Matt Mullenweg <m...@mullenweg.com> wrote:
It's mainly about the reasons why Automattic/WordPress need your blog's URL in order to check updates, but in truth they don't need it at all, at least that's my take on the discussion that's taken place.
On 9/23/07, Viper007Bond <vi...@viper007bond.com> wrote:
> Is anyone else confused as me to what this argument is over? Security > through obscurity isn't security at all.
On Sep 23, 2007, at 6:09 PM, Matt Mullenweg wrote:
> Mark Jaquith wrote: >> Back up a minute. Why is the blog URL needed?
> 1. It does no harm.
That's not really an argument /for/ it.
> 2. It's simple, easy, and self-evident.
It's a behind the scenes feature, so simplicity and ease don't really apply. Self-evident? Evident to whom? Evident for what purpose?
> 3. It could be useful in the future.
Having a unique token is certainly nice, because it allows you to identify unique WP installs and track percentages of people running outdated versions or core or plugins. That sort of data can help guide the project. For instance, if we want to change something that will break a few plugins, we can see how many people are using those plugins, and get an idea of the impact. That can be done with an anonymous token.
> I think this feature is actually going to dramatically improve the > security of WordPress overall. We all saw the survey that 95% of WP > blogs were vulnerable. That didn't even look a plugins. I think the > survey was flawed, but you still can't deny that for most people > knowing there is an update and actually updating just doesn't > happen, and this is a necessary first step. If the only "trade-off" > is sending an ALREADY PUBLIC blog URL to wordpress.org, then great!
But it's not a necessary trade-off. The update functionality works just as well with an anonymous token.
I'm not about to douse myself with gasoline here, but it does seem like we could address the privacy concerns (edge/paranoid though they may seem) without affecting the functionality in a negative way and without affecting WP.org's future ability to track WP/plugin version statistics. If you have some killer feature that could be enabled on WP.org without a WP update and that would require the use of blog URLs (but doesn't expose private data like which plugins they have installed), then please share. Maybe that will be enough to set people at ease about the data they're providing.
>> Mark Jaquith wrote: >I'm not about to douse myself with gasoline here, but it does seem >like we could address the privacy concerns (edge/paranoid though they >may seem) without affecting the functionality in a negative way and >without affecting WP.org's future ability to track WP/plugin version >statistics. If you have some killer feature that could be enabled on >WP.org without a WP update and that would require the use of blog >URLs (but doesn't expose private data like which plugins they have >installed), then please share. Maybe that will be enough to set >people at ease about the data they're providing.
>--
I was just looking at Drupal status update module, and they do this very thing. They create a site key that is sent:
$site_key = md5($base_url . $drupal_private_key);
That does offer a nice way to distinguish unique installs.
I also looked into PHPBB's core update checked. That just downloads a text file:
SITUATION: Currently, 2.3 sends the bloginfo('home'), the plugin name, and the plugin version # to api.wordpress.blah
The only thing currently being used by api.wordpress.blah is plugin name and possibly the version number (but just for a simple string check?).
However, having the server doing a version number check is actually powerful because the plugins have version numbers all over the place and api.wordpress.blah could actually track the chronological order to figure out what's newer than what.
The URL currently servers no purpose. It could possibly do something in the future, but I'm not clear what.
IMPACT: The ACTUAL ability for a cracker to break into your blog is not increased at all by collecting this information, assuming it was somehow made available to malicious people.
However, the ability for a hacker to get a nice list of people who haven't upgraded to the latest security fixed plugin foo is increased by this. Which makes api.wordpress.blah a seductive target.
There is also the perceived security risk, which is unrelated to the actual security risk. As we can see just from the very limited audience on this mailing list, the perception is that there is an increased risk for blog owners.
There is a reputation or privacy risk as well. The plugins that a blog runs may or may not be detectable externally. However, it is the blog owner's choice to advertise what plugins they have.
Finally, there is perception of a privacy invasion. Again, from just this limited audience we can see that there are privacy concerns.
SUGGESTIONS: I would suggest that this feature be off initially. It can be turned on by the admin if they wish. It should not send a URL, though I think generating and storing some sort of UUID, and using that instead of the blog URL is probably the best compromise.
CLOSING NOTES: I want to point out that there has been a thread about a collecting wordpress statistics. It overlaps a lot of the concerns for this feature. It was never proposed that this feature would be anything other than opt-in.
Ciao!
-- He's turned his life around. He used to be depressed and miserable. Now he's miserable and depressed. -- David Frost
Mark Jaquith wrote: >> 2. It's simple, easy, and self-evident.
> It's a behind the scenes feature, so simplicity and ease don't really > apply. Self-evident? Evident to whom? Evident for what purpose?
URLs are useful unique identifiers and in my opinion the best one to use on the web. You can normalize them, organize them by domains and subdomains, look for odd characters or paths, create stats by TLDs, map them to hosting providers, use them as a basis for a crawl, and associate them with WordPress.org profiles. MD5s are unique, but don't have a lot of value beyond that, and even a capitalization or trailing slash change will change the whole MD5. There are also things I think we haven't imagined yet that could make URLs useful. Maybe a .org toolbar that ties into your .org profile and makes it easy to manage multiple blogs and tie them together. If by the time 2.5 comes around we're still not doing anything useful with it then we can re-examine it.
I don't think an MD5 would be significantly more anonymous either. Anyone with a list of URLs could associate the md5 with a URL just by pre-computing the URL MD5s and comparing. So they would be different, but not really better. You'd have to add a salt of some kind. We're hours from the release arguing about a bikeshed that was checked in over a month ago.
I'm not trying to suck up or anything, but I have to agree with Matt on this one. I still have yet to a valid security related issue with transmitting the install URL when checking for updates. Not to mention all of this is going on the assumption that Joe Blow has an Office Depot "Easy Button" for hacking into the WP.org server and even then, as Matt said, nothing is being stored.
The paranoid factor however is valid, as shown by this long discussion. It seems just too many people are wearing tin foil hats these days and getting worked up over what in my opinion is nothing. "The Man" is not out to get you, people.
Simply put, I think we should do what is best for the majority. For the minority, plugins will work nicely.
On 9/23/07, Matt Mullenweg <m...@mullenweg.com> wrote:
> Mark Jaquith wrote: > >> 2. It's simple, easy, and self-evident.
> > It's a behind the scenes feature, so simplicity and ease don't really > > apply. Self-evident? Evident to whom? Evident for what purpose?
> URLs are useful unique identifiers and in my opinion the best one to use > on the web. You can normalize them, organize them by domains and > subdomains, look for odd characters or paths, create stats by TLDs, map > them to hosting providers, use them as a basis for a crawl, and > associate them with WordPress.org profiles. MD5s are unique, but don't > have a lot of value beyond that, and even a capitalization or trailing > slash change will change the whole MD5. There are also things I think we > haven't imagined yet that could make URLs useful. Maybe a .org toolbar > that ties into your .org profile and makes it easy to manage multiple > blogs and tie them together. If by the time 2.5 comes around we're still > not doing anything useful with it then we can re-examine it.
> I don't think an MD5 would be significantly more anonymous either. > Anyone with a list of URLs could associate the md5 with a URL just by > pre-computing the URL MD5s and comparing. So they would be different, > but not really better. You'd have to add a salt of some kind. We're > hours from the release arguing about a bikeshed that was checked in over > a month ago.
> URLs are useful unique identifiers and in my opinion the best one > to use on the web. You can normalize them, organize them by domains > and subdomains, look for odd characters or paths, create stats by > TLDs, map them to hosting providers, use them as a basis for a > crawl, and associate them with WordPress.org profiles. MD5s are > unique, but don't have a lot of value beyond that, and even a > capitalization or trailing slash change will change the whole MD5. > There are also things I think we haven't imagined yet that could > make URLs useful. Maybe a .org toolbar that ties into your .org > profile and makes it easy to manage multiple blogs and tie them > together. If by the time 2.5 comes around we're still not doing > anything useful with it then we can re-examine it.
> I don't think an MD5 would be significantly more anonymous either. > Anyone with a list of URLs could associate the md5 with a URL just > by pre-computing the URL MD5s and comparing. So they would be > different, but not really better. You'd have to add a salt of some > kind. We're hours from the release arguing about a bikeshed that > was checked in over a month ago.
[ Tried to send this ~25 minutes ago but it didn't show up. Sorry if it doubleposts ]
wp_hash() uses an unchanging salt (set once in the database and not updated by WordPress ever). So wp_hash('update-check') will remain constant for the life of the blog. The uses of a URL identifier you mention are interesting -- though none seem "killer," and some of those uses should probably be "opt-in."
I can see both sides of the fence here and I agree with Matt is be nice to have a set of statistics but I feel fundamentally we need to give the blogger the ability to opt in on sending statistics rather than just blindly sending those statistics regardless of how benign they are..
We all know the history of other applications that have sent statistics silently back without allowing opt in (or out).. and the backlash those other applications had to face, lets not go down this road..
> URLs are useful unique identifiers and in my opinion the best one > to use on the web. You can normalize them, organize them by domains > and subdomains, look for odd characters or paths, create stats by > TLDs, map them to hosting providers, use them as a basis for a > crawl, and associate them with WordPress.org profiles. MD5s are > unique, but don't have a lot of value beyond that, and even a > capitalization or trailing slash change will change the whole MD5. > There are also things I think we haven't imagined yet that could > make URLs useful. Maybe a .org toolbar that ties into your .org > profile and makes it easy to manage multiple blogs and tie them > together. If by the time 2.5 comes around we're still not doing > anything useful with it then we can re-examine it.
> I don't think an MD5 would be significantly more anonymous either. > Anyone with a list of URLs could associate the md5 with a URL just > by pre-computing the URL MD5s and comparing. So they would be > different, but not really better. You'd have to add a salt of some > kind. We're hours from the release arguing about a bikeshed that > was checked in over a month ago.
wp_hash() uses an unchanging salt (set once in the database and not updated by WordPress ever). So wp_hash('update-check') will remain constant for the life of the blog. The uses of a URL identifier you mention are interesting -- though none seem "killer," and some of those uses should probably be "opt-in."
I think an opt-in method would be a very bad idea. It'd nearly negate the whole purpose of the feature as the majority of noob users would never turn it on.
However, I full heartedly support an opt-out feature as well maybe a notice the first time checking. Simply put, the default should be to check, but it should be easy (easier than a plugin) to disable it.
On 9/23/07, ozgreg <wphack...@galleryembedded.com> wrote:
> I can see both sides of the fence here and I agree with Matt is be nice to > have a set of statistics but I feel fundamentally we need to give the > blogger the ability to opt in on sending statistics rather than just blindly > sending those statistics regardless of how benign they are..
> We all know the history of other applications that have sent statistics > silently back without allowing opt in (or out).. and the backlash those > other applications had to face, lets not go down this road..
Viper007Bond wrote: > I think an opt-in method would be a very bad idea. It'd nearly negate the > whole purpose of the feature as the majority of noob users would never turn > it on.
> However, I full heartedly support an opt-out feature as well maybe a notice > the first time checking. Simply put, the default should be to check, but it > should be easy (easier than a plugin) to disable it.
> On 9/23/07, ozgreg <wphack...@galleryembedded.com> wrote:
>> I can see both sides of the fence here and I agree with Matt is be nice to >> have a set of statistics but I feel fundamentally we need to give the >> blogger the ability to opt in on sending statistics rather than just blindly >> sending those statistics regardless of how benign they are..
>> We all know the history of other applications that have sent statistics >> silently back without allowing opt in (or out).. and the backlash those >> other applications had to face, lets not go down this road..
I think version check shouldn't be able to be turned off without a plugin. It's just too important that a user keeps up to date. But for those fringe cases, plugins handle it nicely.
As for the statistics, I think it should be opt-out not opt-in. I think the _vast_ majority of users, including me, realize there's no harm in sending along WP details and/or more likely, just don't care (all the noob users out there). For those who do care for some reason, valid or not, a simple check box would do the trick and avoid any negative... press (right word?) on the matter.
We definitely don't want to make this seem secretive IMHO.
> This is exactly why I said in the "automatic user feedback" thread that > we should not tie version check with statistical gathering.
> those are to different functions, with different importance and > characteristics.
> version check should be turned on by default, statistics gathering > should be opt-in.
> the fact that they somewhat overlap and that it's tempting to merge them > does not mean it's a good idea to do so.
> Viper007Bond wrote:
> > I think an opt-in method would be a very bad idea. It'd nearly negate > the > > whole purpose of the feature as the majority of noob users would never > turn > > it on.
> > However, I full heartedly support an opt-out feature as well maybe a > notice > > the first time checking. Simply put, the default should be to check, but > it > > should be easy (easier than a plugin) to disable it.
> > On 9/23/07, ozgreg <wphack...@galleryembedded.com> wrote:
> >> I can see both sides of the fence here and I agree with Matt is be nice > to > >> have a set of statistics but I feel fundamentally we need to give the > >> blogger the ability to opt in on sending statistics rather than just > blindly > >> sending those statistics regardless of how benign they are..
> >> We all know the history of other applications that have sent statistics > >> silently back without allowing opt in (or out).. and the backlash those > >> other applications had to face, lets not go down this road..
> I think version check shouldn't be able to be turned off without a plugin. > It's just too important that a user keeps up to date. But for those fringe > cases, plugins handle it nicely.
> As for the statistics, I think it should be opt-out not opt-in. I think the > _vast_ majority of users, including me, realize there's no harm in sending > along WP details and/or more likely, just don't care (all the noob users out > there). For those who do care for some reason, valid or not, a simple check > box would do the trick and avoid any negative... press (right word?) on the > matter.
> We definitely don't want to make this seem secretive IMHO.
