<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Google Chrome &#8211; the Security Implications</title>
	<atom:link href="http://etbe.coker.com.au/2008/09/02/google-chrome-the-security-implications/feed/" rel="self" type="application/rss+xml" />
	<link>http://etbe.coker.com.au/2008/09/02/google-chrome-the-security-implications/</link>
	<description>Linux, politics, and other interesting things</description>
	<lastBuildDate>Thu, 09 Feb 2012 01:09:24 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Bakalite</title>
		<link>http://etbe.coker.com.au/2008/09/02/google-chrome-the-security-implications/comment-page-1/#comment-15948</link>
		<dc:creator>Bakalite</dc:creator>
		<pubDate>Fri, 19 Sep 2008 01:32:11 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=748#comment-15948</guid>
		<description>Yes.  Your right Lloyd about time and getting it right.  Google is a remarkable company.  By far the most successful advertising company on the planet.

I know that Chrome code is open source, but I really wish it wasn&#039;t.  Brendan Eich at Mozilla must be quietly spitting chips.

Which brings me to my point.  I&#039;m going to go out on a limb here and expand the concept of security momentarily. 

As I have spent much of my career coding ways and means of capturing granular, user specific data I&#039;m really not very comfortable with an independent (and for most, foreign) advertising company using their backward propagation technology to track so many of our moves quite so thoroughly.  

Its very easy to overlook this concern, but I suspect those who don&#039;t see a problem with their activities being exposed haven&#039;t had, on the rare occasion in the course of their professional careers, various security organisations show an interest in using their work.

So, my biggest security concern is not the specifics of the various functions and objects within Chrome (after all Goggle will get it right over time), but with Chrome itself.</description>
		<content:encoded><![CDATA[<p>Yes.  Your right Lloyd about time and getting it right.  Google is a remarkable company.  By far the most successful advertising company on the planet.</p>
<p>I know that Chrome code is open source, but I really wish it wasn&#8217;t.  Brendan Eich at Mozilla must be quietly spitting chips.</p>
<p>Which brings me to my point.  I&#8217;m going to go out on a limb here and expand the concept of security momentarily. </p>
<p>As I have spent much of my career coding ways and means of capturing granular, user specific data I&#8217;m really not very comfortable with an independent (and for most, foreign) advertising company using their backward propagation technology to track so many of our moves quite so thoroughly.  </p>
<p>Its very easy to overlook this concern, but I suspect those who don&#8217;t see a problem with their activities being exposed haven&#8217;t had, on the rare occasion in the course of their professional careers, various security organisations show an interest in using their work.</p>
<p>So, my biggest security concern is not the specifics of the various functions and objects within Chrome (after all Goggle will get it right over time), but with Chrome itself.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: etbe</title>
		<link>http://etbe.coker.com.au/2008/09/02/google-chrome-the-security-implications/comment-page-1/#comment-15939</link>
		<dc:creator>etbe</dc:creator>
		<pubDate>Thu, 18 Sep 2008 20:36:24 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=748#comment-15939</guid>
		<description>Bakalite: Thanks for your comments, it&#039;s interesting to read such a review.

I agree that it&#039;s mostly about the concept at this stage.  We know that Google can produce successful large projects, so it&#039;s just a matter of time before they get this one right.</description>
		<content:encoded><![CDATA[<p>Bakalite: Thanks for your comments, it&#8217;s interesting to read such a review.</p>
<p>I agree that it&#8217;s mostly about the concept at this stage.  We know that Google can produce successful large projects, so it&#8217;s just a matter of time before they get this one right.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bakalite</title>
		<link>http://etbe.coker.com.au/2008/09/02/google-chrome-the-security-implications/comment-page-1/#comment-15934</link>
		<dc:creator>Bakalite</dc:creator>
		<pubDate>Thu, 18 Sep 2008 14:22:03 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=748#comment-15934</guid>
		<description>I&#039;m with Lloyd on this.  As a CTO of CMS company the exploits our users get hit with are almost exclusively injection related attacks - and I do mean related as the work arounds to prevent injection attacks are obvious to developers.  

Its a double blind for us. As we are a CMS we permit script insertion, so our users tend to get hit when they permit anonymous script insertion on their sites.  Mostly we can detect it but, as these things tend to work, exploits are usually a tad ahead of the game.

Anyway, my post is really about Chrome.  Its still really early days yet.  Lots of (particularly) javascript related functions arent quite working yet, and their javascript debugger really, really sucks - its a toy. 

To name only one obvious general area that affects loads of script - pixel width and height issues.  Annoyingly scroll bars appear even when they have been explicitly denied.  Chrome is touted as a web 2 application (at least in my local media spin from google) that is ideal for function heavy javascript client server applications.  Well... Not yet.  It cant even run FCKEditor without stripping javascript from the editor source - not that we use this editor but millions of users do.  Google still has a long way go before really function rich applications can even think of seriously coming on board.

Having said that.  Seriously good little (big really) product and absolutely going in the right direction.  They really need to get some of the mozilla  developers on board to sort out the bugs though.</description>
		<content:encoded><![CDATA[<p>I&#8217;m with Lloyd on this.  As a CTO of CMS company the exploits our users get hit with are almost exclusively injection related attacks &#8211; and I do mean related as the work arounds to prevent injection attacks are obvious to developers.  </p>
<p>Its a double blind for us. As we are a CMS we permit script insertion, so our users tend to get hit when they permit anonymous script insertion on their sites.  Mostly we can detect it but, as these things tend to work, exploits are usually a tad ahead of the game.</p>
<p>Anyway, my post is really about Chrome.  Its still really early days yet.  Lots of (particularly) javascript related functions arent quite working yet, and their javascript debugger really, really sucks &#8211; its a toy. </p>
<p>To name only one obvious general area that affects loads of script &#8211; pixel width and height issues.  Annoyingly scroll bars appear even when they have been explicitly denied.  Chrome is touted as a web 2 application (at least in my local media spin from google) that is ideal for function heavy javascript client server applications.  Well&#8230; Not yet.  It cant even run FCKEditor without stripping javascript from the editor source &#8211; not that we use this editor but millions of users do.  Google still has a long way go before really function rich applications can even think of seriously coming on board.</p>
<p>Having said that.  Seriously good little (big really) product and absolutely going in the right direction.  They really need to get some of the mozilla  developers on board to sort out the bugs though.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: etbe</title>
		<link>http://etbe.coker.com.au/2008/09/02/google-chrome-the-security-implications/comment-page-1/#comment-15794</link>
		<dc:creator>etbe</dc:creator>
		<pubDate>Thu, 11 Sep 2008 00:02:07 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=748#comment-15794</guid>
		<description>http://ulissescastro.wordpress.com/2008/09/10/google-chrome-se-linux-navegador-blindado/
At the above URL Ulisses Castro writes in Portuguese about the potential for adding SE Linux support to Chrome.  He links to this post and posts by Joshua and Dan about it and suggests using different types for different levels of content.</description>
		<content:encoded><![CDATA[<p><a href="http://ulissescastro.wordpress.com/2008/09/10/google-chrome-se-linux-navegador-blindado/" rel="nofollow">http://ulissescastro.wordpress.com/2008/09/10/google-chrome-se-linux-navegador-blindado/</a><br />
At the above URL Ulisses Castro writes in Portuguese about the potential for adding SE Linux support to Chrome.  He links to this post and posts by Joshua and Dan about it and suggests using different types for different levels of content.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Google Chrome + SE Linux = Navegador Blindado &#171; Ulisses Castro (thebug) - Ethical Hacking, Pentest and Computer Security</title>
		<link>http://etbe.coker.com.au/2008/09/02/google-chrome-the-security-implications/comment-page-1/#comment-15793</link>
		<dc:creator>Google Chrome + SE Linux = Navegador Blindado &#171; Ulisses Castro (thebug) - Ethical Hacking, Pentest and Computer Security</dc:creator>
		<pubDate>Wed, 10 Sep 2008 23:51:52 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=748#comment-15793</guid>
		<description>[...] GURUS do SE Linux já blogaram sobre essa possibilidde, Russel Cocker (debian/redhat), Dan Walsh(redhat), Joshua Brindle(tresys) comentaram em seus blogs essas semanas [...]</description>
		<content:encoded><![CDATA[<p>[...] GURUS do SE Linux já blogaram sobre essa possibilidde, Russel Cocker (debian/redhat), Dan Walsh(redhat), Joshua Brindle(tresys) comentaram em seus blogs essas semanas [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lloyd Borrett</title>
		<link>http://etbe.coker.com.au/2008/09/02/google-chrome-the-security-implications/comment-page-1/#comment-15715</link>
		<dc:creator>Lloyd Borrett</dc:creator>
		<pubDate>Fri, 05 Sep 2008 01:51:02 +0000</pubDate>
		<guid isPermaLink="false">http://etbe.coker.com.au/?p=748#comment-15715</guid>
		<description>It&#039;s great that Google have recognised that security needs to be an important consideration with browsers. It&#039;s a shame that this beta of Chrome shows that they haven&#039;t been thorough enough about it to fix known security problems with the toolkits they&#039;ve built Chrome on. But it&#039;s a beta version and no doubt these issues will be addressed with the release version. (But then again, some Google products seem to remain as beta versions forever!)

It&#039;s also great that Google is acknowledging the need to keep ahead of the bad guys and their rapidly evolving ways of using exploits, social engineering and other web-borne threats to harm users. The inclusion of the malware and phishing blacklists in Google Chrome is a step in the right direction. Google state that the software checks a URL against their blacklist databases of web pages/sites that are known to have delivered malware and phishing attacks in the past.

Of course, that approach is mostly too slow to protect against transient threats, and most online threats today are highly transient. The bad guys register and invoke domains, or put their exploit payloads onto legitimate web sites they&#039;ve been able to poison, for just the few days they&#039;ll be able to fly under the radar and not make it onto blacklists. The bad guys either shut the exploit down before making it onto the blacklists, or very soon after. So often these days, the threat is gone before it can be recorded into the blacklists. Worse, at least for the operators of legitimate sites that have been compromised, when the threats are detected and the sites added to the blacklists, the sites show up as infected even after the threats are gone.

AVG believes the best approach is real-time scanning that inspects each web page for exploits right when the user clicks on the link to visit it. That&#039;s the approach the AVG LinkScanner technology uses. This real-time scanning functionality is more effective against transient threats. The safe surf AVG LinkScanner Active Surf-Shield module in all paid AVG products does real-time scanning to detect infected and potentially-infected content as you browse the web. This real-time approach delivers the maximum protection simply not able to be provided by blacklists.

Best Regards, Lloyd Borrett
Marketing Manager, AVG (AU/NZ)</description>
		<content:encoded><![CDATA[<p>It&#8217;s great that Google have recognised that security needs to be an important consideration with browsers. It&#8217;s a shame that this beta of Chrome shows that they haven&#8217;t been thorough enough about it to fix known security problems with the toolkits they&#8217;ve built Chrome on. But it&#8217;s a beta version and no doubt these issues will be addressed with the release version. (But then again, some Google products seem to remain as beta versions forever!)</p>
<p>It&#8217;s also great that Google is acknowledging the need to keep ahead of the bad guys and their rapidly evolving ways of using exploits, social engineering and other web-borne threats to harm users. The inclusion of the malware and phishing blacklists in Google Chrome is a step in the right direction. Google state that the software checks a URL against their blacklist databases of web pages/sites that are known to have delivered malware and phishing attacks in the past.</p>
<p>Of course, that approach is mostly too slow to protect against transient threats, and most online threats today are highly transient. The bad guys register and invoke domains, or put their exploit payloads onto legitimate web sites they&#8217;ve been able to poison, for just the few days they&#8217;ll be able to fly under the radar and not make it onto blacklists. The bad guys either shut the exploit down before making it onto the blacklists, or very soon after. So often these days, the threat is gone before it can be recorded into the blacklists. Worse, at least for the operators of legitimate sites that have been compromised, when the threats are detected and the sites added to the blacklists, the sites show up as infected even after the threats are gone.</p>
<p>AVG believes the best approach is real-time scanning that inspects each web page for exploits right when the user clicks on the link to visit it. That&#8217;s the approach the AVG LinkScanner technology uses. This real-time scanning functionality is more effective against transient threats. The safe surf AVG LinkScanner Active Surf-Shield module in all paid AVG products does real-time scanning to detect infected and potentially-infected content as you browse the web. This real-time approach delivers the maximum protection simply not able to be provided by blacklists.</p>
<p>Best Regards, Lloyd Borrett<br />
Marketing Manager, AVG (AU/NZ)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

