<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: News Wire: PHP Group accused of security incompetence</title>
	<atom:link href="http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/</link>
	<description>News, opinion, and fresh thinking for web developers and designers. The official podcast of sitepoint.com.</description>
	<pubDate>Thu, 04 Dec 2008 23:54:26 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: cranial-bore</title>
		<link>http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/#comment-190304</link>
		<dc:creator>cranial-bore</dc:creator>
		<pubDate>Tue, 27 Feb 2007 23:56:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/#comment-190304</guid>
		<description>The downside to me was that your site (files you manage) are split up, with some out of your direct control. If you wanted to regroup certain scripts into a single file (depending on your usage patterns) you wouldn't be able to do it.

If you wanted to (for example) make some scripts .php files served as JS to compress you wouldn't be able to do it.

You may want to make trivial changes (e.g setting up shortcuts to the long YUI names) to the library files.

You have another point of failure. Your site may be online, but the JS that powers it offline (unlikely though). 

If your site hard-links to specific JS files (admittedly not a good idea) and you want to utilize new versions you'd have a lot of links to change.

These are not insurmountable issues. Mostly I like the psychology of having the site in one place. For concurrent connections you can always setup a subdomain on your own server and load the JS files via it. Still have to supply your own bandwidth though :)</description>
		<content:encoded><![CDATA[<p>The downside to me was that your site (files you manage) are split up, with some out of your direct control. If you wanted to regroup certain scripts into a single file (depending on your usage patterns) you wouldn&#8217;t be able to do it.</p>
<p>If you wanted to (for example) make some scripts .php files served as JS to compress you wouldn&#8217;t be able to do it.</p>
<p>You may want to make trivial changes (e.g setting up shortcuts to the long YUI names) to the library files.</p>
<p>You have another point of failure. Your site may be online, but the JS that powers it offline (unlikely though). </p>
<p>If your site hard-links to specific JS files (admittedly not a good idea) and you want to utilize new versions you&#8217;d have a lot of links to change.</p>
<p>These are not insurmountable issues. Mostly I like the psychology of having the site in one place. For concurrent connections you can always setup a subdomain on your own server and load the JS files via it. Still have to supply your own bandwidth though :)</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin Yank</title>
		<link>http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/#comment-190300</link>
		<dc:creator>Kevin Yank</dc:creator>
		<pubDate>Tue, 27 Feb 2007 23:34:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/#comment-190300</guid>
		<description>&lt;blockquote&gt;What is the benefit to having your Javascript hosted remotely? I can only think of downsides.&lt;/blockquote&gt;
The benefit is that your site uses less bandwidth on your server, and most browsers will be able to load your site more quickly (most browsers will only download 2-4 files from a particular server at once).

What downsides can you think of?</description>
		<content:encoded><![CDATA[<blockquote><p>What is the benefit to having your Javascript hosted remotely? I can only think of downsides.</p></blockquote>
<p>The benefit is that your site uses less bandwidth on your server, and most browsers will be able to load your site more quickly (most browsers will only download 2-4 files from a particular server at once).</p>
<p>What downsides can you think of?</p>]]></content:encoded>
	</item>
	<item>
		<title>By: cranial-bore</title>
		<link>http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/#comment-190292</link>
		<dc:creator>cranial-bore</dc:creator>
		<pubDate>Tue, 27 Feb 2007 23:17:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/#comment-190292</guid>
		<description>What is the benefit to having your Javascript hosted remotely? I can only think of downsides.</description>
		<content:encoded><![CDATA[<p>What is the benefit to having your Javascript hosted remotely? I can only think of downsides.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: jamiemcd</title>
		<link>http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/#comment-188791</link>
		<dc:creator>jamiemcd</dc:creator>
		<pubDate>Sun, 25 Feb 2007 16:42:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/#comment-188791</guid>
		<description>I use YUI. It's a great javascript library.  However I noticed an important comment on the &lt;em&gt;Free Hosting of YUI Files from Yahoo!&lt;/em&gt; discussion.  If your site is secure, such as https://www.example.com, you need to continue hosting your own YUI files, since Yahoo! does not offer secure hosting.  I ran into this same problem with including the javascript files needed for Google Analtyics.  I would get a security warning on any pages using SSL.  Fortunately, Google did offer secure hosting of those javascript files, as described &lt;a href="http://www.sitepoint.com/forums/showthread.php?p=2355807#post2355807" rel="nofollow"&gt;here&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>I use YUI. It&#8217;s a great javascript library.  However I noticed an important comment on the <em>Free Hosting of YUI Files from Yahoo!</em> discussion.  If your site is secure, such as <a href="https://www.example.com" rel="nofollow">https://www.example.com</a>, you need to continue hosting your own YUI files, since Yahoo! does not offer secure hosting.  I ran into this same problem with including the javascript files needed for Google Analtyics.  I would get a security warning on any pages using SSL.  Fortunately, Google did offer secure hosting of those javascript files, as described <a href="http://www.sitepoint.com/forums/showthread.php?p=2355807#post2355807" rel="nofollow">here</a>.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Xenon_54</title>
		<link>http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/#comment-187782</link>
		<dc:creator>Xenon_54</dc:creator>
		<pubDate>Sat, 24 Feb 2007 07:15:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/#comment-187782</guid>
		<description>@Rick

Month of PHP bugs will be about bugs into PHP itself, not users' applications.</description>
		<content:encoded><![CDATA[<p>@Rick</p>
<p>Month of PHP bugs will be about bugs into PHP itself, not users&#8217; applications.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Rick</title>
		<link>http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/#comment-187427</link>
		<dc:creator>Rick</dc:creator>
		<pubDate>Fri, 23 Feb 2007 20:17:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/#comment-187427</guid>
		<description>The month of PHP bugs idea does sound alot like a publicity stunt.

PHP does make it easy to write insecure code, but then again I used to write web apps in ASP and VBScript, I think the amount of time I spent compensating for security is about equivalent.

All networked applications have the potential for massive security cockups (cough cough windows) especially if they are connected to the public internet, it just happens that PHP makes it very easy for developers who may never have heard of XSS and Code Injection develop applications. 

Things like magic_quotes_gpc prove that attempts to nanny users by taking responsibiltiy for security away from them always turn sour - they reduce flexibility and more importantly can't hope to gaurentee security in all situations.

I don't think its fair to blame PHP for allowing developers to write insecure applications, just as I wouldn't argue that you can blame C++ for allowing developers to write applications with memory leaks!</description>
		<content:encoded><![CDATA[<p>The month of PHP bugs idea does sound alot like a publicity stunt.</p>
<p>PHP does make it easy to write insecure code, but then again I used to write web apps in ASP and VBScript, I think the amount of time I spent compensating for security is about equivalent.</p>
<p>All networked applications have the potential for massive security cockups (cough cough windows) especially if they are connected to the public internet, it just happens that PHP makes it very easy for developers who may never have heard of XSS and Code Injection develop applications. </p>
<p>Things like magic_quotes_gpc prove that attempts to nanny users by taking responsibiltiy for security away from them always turn sour - they reduce flexibility and more importantly can&#8217;t hope to gaurentee security in all situations.</p>
<p>I don&#8217;t think its fair to blame PHP for allowing developers to write insecure applications, just as I wouldn&#8217;t argue that you can blame C++ for allowing developers to write applications with memory leaks!</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Ards</title>
		<link>http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/#comment-187311</link>
		<dc:creator>Ards</dc:creator>
		<pubDate>Fri, 23 Feb 2007 16:27:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.sitepoint.com/blogs/2007/02/24/news-wire-php-group-accused-of-security-incompetence/#comment-187311</guid>
		<description>Just hope Stefan Esser will make the right choice to help the PHP community instead of going against it for the "Month of PHP bugs". I also think that it's a self propaganda...</description>
		<content:encoded><![CDATA[<p>Just hope Stefan Esser will make the right choice to help the PHP community instead of going against it for the &#8220;Month of PHP bugs&#8221;. I also think that it&#8217;s a self propaganda&#8230;</p>]]></content:encoded>
	</item>
</channel>
</rss>
