<?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: Tempted by location apps?</title>
	<atom:link href="http://blogs.parc.com/blog/2009/11/tempted-by-location-apps/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.parc.com/blog/2009/11/tempted-by-location-apps/</link>
	<description>perspectives, trends, discussions</description>
	<lastBuildDate>Sun, 20 Nov 2011 06:03:50 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Richard Chow</title>
		<link>http://blogs.parc.com/blog/2009/11/tempted-by-location-apps/comment-page-1/#comment-1027</link>
		<dc:creator>Richard Chow</dc:creator>
		<pubDate>Thu, 12 Nov 2009 18:33:12 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.parc.com/?p=1953#comment-1027</guid>
		<description>Thanks for the comments, everybody!

Pravin, your guess is right. You&#039;ve pointed out that some adjustments are needed in the distributions used by the coordinate-generation algorithm.

What&#039;s tricky is that ideally we don&#039;t want the algorithm to depend on data from actual trips along the route. The advantage of the algorithm is not needing this data (otherwise, we might have used John Krumm&#039;s algorithm). One thought is to divide up roads into some categories like &quot;freeway&quot; and &quot;residential&quot;, and have distributions for each category. Of course, there might need to be a time-component to the category also, e.g. &quot;freeway-during-rushhour&quot;...</description>
		<content:encoded><![CDATA[<p>Thanks for the comments, everybody!</p>
<p>Pravin, your guess is right. You&#8217;ve pointed out that some adjustments are needed in the distributions used by the coordinate-generation algorithm.</p>
<p>What&#8217;s tricky is that ideally we don&#8217;t want the algorithm to depend on data from actual trips along the route. The advantage of the algorithm is not needing this data (otherwise, we might have used John Krumm&#8217;s algorithm). One thought is to divide up roads into some categories like &#8220;freeway&#8221; and &#8220;residential&#8221;, and have distributions for each category. Of course, there might need to be a time-component to the category also, e.g. &#8220;freeway-during-rushhour&#8221;&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pravin Shankar</title>
		<link>http://blogs.parc.com/blog/2009/11/tempted-by-location-apps/comment-page-1/#comment-1026</link>
		<dc:creator>Pravin Shankar</dc:creator>
		<pubDate>Thu, 12 Nov 2009 15:39:07 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.parc.com/?p=1953#comment-1026</guid>
		<description>Very interesting post, thanks for pointing to my work.

I agree that evaluation of &quot;fake locations&quot; or SybilQueries is an important problem. This would have to be done as a combination of user study/peer review, as well as machine learning/clustering techniques, and is a great avenue for future research.

I took a look at your traces, and my guess for the fake traces are 08042008.kml and 08062008.kml The rather naive reasoning is that the CDF of distance between consecutive points of these two traces looks different from the other 4 (&lt;a href=&quot;http://paul.rutgers.edu/~spravin/tmp/trips.png&quot; rel=&quot;nofollow&quot;&gt;see this figure&lt;/a&gt;)
 </description>
		<content:encoded><![CDATA[<p>Very interesting post, thanks for pointing to my work.</p>
<p>I agree that evaluation of &#8220;fake locations&#8221; or SybilQueries is an important problem. This would have to be done as a combination of user study/peer review, as well as machine learning/clustering techniques, and is a great avenue for future research.</p>
<p>I took a look at your traces, and my guess for the fake traces are 08042008.kml and 08062008.kml The rather naive reasoning is that the CDF of distance between consecutive points of these two traces looks different from the other 4 (<a href="http://paul.rutgers.edu/~spravin/tmp/trips.png" rel="nofollow">see this figure</a>)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Krumm</title>
		<link>http://blogs.parc.com/blog/2009/11/tempted-by-location-apps/comment-page-1/#comment-1024</link>
		<dc:creator>John Krumm</dc:creator>
		<pubDate>Mon, 09 Nov 2009 17:36:29 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.parc.com/?p=1953#comment-1024</guid>
		<description>Nice post. Thanks for pointing to my work. I like how you’ve thought beyond just the technical aspects of this solution for privacy.

I also like your answer to why we can’t just use previously gathered GPS traces as the fake traces. I’m sometimes asked this question (e.g. by reviewers), and I never had a very good answer until reading your post. You’re right that attackers could have access to the same historical traces as anyone else, rendering the traces useless for this purpose. Good thinking!</description>
		<content:encoded><![CDATA[<p>Nice post. Thanks for pointing to my work. I like how you’ve thought beyond just the technical aspects of this solution for privacy.</p>
<p>I also like your answer to why we can’t just use previously gathered GPS traces as the fake traces. I’m sometimes asked this question (e.g. by reviewers), and I never had a very good answer until reading your post. You’re right that attackers could have access to the same historical traces as anyone else, rendering the traces useless for this purpose. Good thinking!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Senthil</title>
		<link>http://blogs.parc.com/blog/2009/11/tempted-by-location-apps/comment-page-1/#comment-1022</link>
		<dc:creator>Senthil</dc:creator>
		<pubDate>Sat, 07 Nov 2009 05:59:48 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.parc.com/?p=1953#comment-1022</guid>
		<description>Nice one, Richard! Interesting read.</description>
		<content:encoded><![CDATA[<p>Nice one, Richard! Interesting read.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

