<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>UW Computer Security Research and Course Blog &#187; Integrity</title>
	<atom:link href="http://cubist.cs.washington.edu/Security/category/integrity/feed/" rel="self" type="application/rss+xml" />
	<link>http://cubist.cs.washington.edu/Security</link>
	<description></description>
	<lastBuildDate>Tue, 17 Mar 2009 01:02:40 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Security Review: New Weapons in the Fight Against Doping</title>
		<link>http://cubist.cs.washington.edu/Security/2009/03/13/security-review-new-weapons-in-the-fight-against-doping/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/03/13/security-review-new-weapons-in-the-fight-against-doping/#comments</comments>
		<pubDate>Sat, 14 Mar 2009 05:57:15 +0000</pubDate>
		<dc:creator>oterod</dc:creator>
				<category><![CDATA[Current Events]]></category>
		<category><![CDATA[Ethics]]></category>
		<category><![CDATA[Integrity]]></category>
		<category><![CDATA[Research]]></category>
		<category><![CDATA[Security Reviews]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=1293</guid>
		<description><![CDATA[ The use of performance enhancing drugs and medical techniques is a serious problem in every sport, but no sport is as notorious for doping scandals as is professional cycling. While Olympic athletes, baseball players, and body builders are often caught boosting, the effect of their “cheating” on the sport, society, and economy is minimal. [...]]]></description>
			<content:encoded><![CDATA[<p><!--[if gte mso 9]&gt;  Normal 0     false false false  EN-US X-NONE X-NONE              MicrosoftInternetExplorer4              &lt;![endif]--><!--[if gte mso 9]&gt;                                                                                                                                            &lt;![endif]--> The use of performance enhancing drugs and medical techniques is a serious problem in every sport, but no sport is as notorious for doping scandals as is professional cycling. While Olympic athletes, baseball players, and body builders are often caught boosting, the effect of their “cheating” on the sport, society, and economy is minimal. Marion Jones, for instance, a five-medal winner in Sydney’s 2000 summer Olympics, was retroactively indicted on drug charges and agreed to forfeit her awards. While the revelation shocked many, Jones relinquished her medals and life went on.</p>
<p class="MsoNormal" style="text-align: justify;">Professional cycling, however, is a very different story. Combining the commercialism of motorsport racing with athletic demands exceeding almost any other sport, the pressure on riders to perform is tremendous. Good performance not only makes careers, but it pleases sponsors and significantly impacts their economic standing. Sponsoring a winning Tour de France team brings in tremendous revenue for a company in Europe. Continuous defeat, on the other hand, can have devastating consequences. As such, riders must reach for the leader board not only to meet their own expectations of success and competition, but simply to remain employed.</p>
<p class="MsoNormal" style="text-align: justify;"><span id="more-1293"></span>For years, dopers and anti-doping agencies have played much the same cat-and-mouse game that security researchers play with crackers. Riders use performance enhancers; researchers create tests to detect them; riders find new drugs to use, and so on and so forth. Doping was present in cycling long ago already, but it was the 1998 expulsion of the entire Festina team from that year’s Tour de France that signaled the beginning of the “doping era.” Since that year, every “grand tour” (the class defined by the Tour de France, the Giro d’Italia, and the Vuelta a España) has been plagued by expulsions, positive tests, litigations and scandals. In order to restore honor and fairness to the sport, many are crusading against the use of performance enhancing drugs. Until recently, the fervor of athlete and corporate lust for success seemed unbeatable.</p>
<p class="MsoNormal" style="text-align: justify;">According to an article by Juliet Macur in the February 28<sup>th</sup>, 2009 edition of the New York Times, the anti-doping community has developed a new methodology for detecting cheating. Rather than attempting to detect traces of illicit chemicals in riders’ bloodstreams, drug testers are attempting to develop a “biological passport” for each rider. By comparing a rider’s current blood work against earlier tests, it is now possible to detect telltale signs of substance abuse via the changes observed in that rider’s blood. Legal action has already been brought against several riders with this biological passport as evidence.</p>
<p class="MsoNormal" style="text-align: justify;"><strong>Assets</strong></p>
<ul>
<li>Riders don’t want to suffer in the ranks as a result of their competition using performance enhancing drugs</li>
<li>Sponsors and team owners don’t want the cheating of other riders to reduce the acclaim, visibility, or overall performance of their respective teams.</li>
<li>Race officials and fans want to see respectable racing, not battle-of-the-druggies. Cycling has been tainted in recent years by the proliferation of doping scandals.</li>
<li>Every non-adversary wants final rankings to be representative of rider athleticism and effort.</li>
</ul>
<p class="MsoNormal" style="text-align: justify;"><strong>Potential Adversaries</strong></p>
<ul>
<li>Riders whose competitive spirit may drive them to seek “help” in order to win.</li>
<li>Riders who suffer from excessive pressure from sponsors to perform.</li>
<li>Sponsors, team owners, or team managers wishing for more team/product/brand visibility thanks to front-running riders.</li>
<li>Doctors and researchers developing new doping methods.</li>
</ul>
<p class="MsoNormal" style="text-align: justify;"><strong>Potential Weaknesses:</strong></p>
<ul>
<li>Though I don’t claim to understand the biology, and while I can’t imagine that an attack this simple would be possible against the “latest and greatest” in anti-doping technology, I see one fundamental flaw in this approach. If detection of substance abuse relies on change between two test dates, the test is vulnerable to a rider who is never tested prior to adopting a doping habit. Because blood may not change once routine doping is adopted, there might not be a difference between old tests and current tests either.</li>
</ul>
<p class="MsoNormal" style="text-align: justify;"><strong>Potential Defenses:</strong></p>
<ul>
<li>In addition to using these “biological passports,” parallel research should continue into discovery and detection of new doping techniques. These detection methods should be applied in addition to any delta-comparison between bloodtests.</li>
<li>If it is possible, attempt to correlate blood of dopers, as well as the blood of likely non-dopers (very poor performers, amateurs, etc.). It may be feasible to derive a model that can detect riders for whom an accurate “clean” sample is unavailable.</li>
</ul>
<p class="MsoNormal" style="text-align: justify;">
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/03/13/security-review-new-weapons-in-the-fight-against-doping/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Security Review: Helios Online Voting</title>
		<link>http://cubist.cs.washington.edu/Security/2009/03/13/security-review-helios-online-voting/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/03/13/security-review-helios-online-voting/#comments</comments>
		<pubDate>Sat, 14 Mar 2009 05:55:23 +0000</pubDate>
		<dc:creator>Orion</dc:creator>
				<category><![CDATA[Integrity]]></category>
		<category><![CDATA[Privacy]]></category>
		<category><![CDATA[Security Reviews]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=1285</guid>
		<description><![CDATA[The Technology
The technology being evaluated is the Helios Online Voting Booth, usable at http://www.heliosvoting.org and outlined in the 2008 Usenix Secuirty paper available at the same site. The election system does not create novel cryptographic tools or algorithms, rather it provides a protocol for using existing cryptography to make an election that is universally verifiable [...]]]></description>
			<content:encoded><![CDATA[<h2>The Technology</h2>
<p>The technology being evaluated is the Helios Online Voting Booth, usable at http://www.heliosvoting.org and outlined in the 2008 Usenix Secuirty paper available at the same site. The election system does not create novel cryptographic tools or algorithms, rather it provides a protocol for using existing cryptography to make an election that is universally verifiable and provides ballot casting assurance as well as voter secrecy. <span id="more-1285"></span>The general outline of the system is as follows:</p>
<ul class="unIndentedList">
<li> The voter fills out a ballot and then &#8220;seals&#8221; it by essentially encrypting it with the election&#8217;s public key so that only the election administrators can decrypt it.</li>
<li> The voter then has the option of verifying that the sealed ballot contains her same choices, if chosen requires the voter to &#8220;reseal&#8221; it with new randomness.</li>
<li> The voter is then authenticated and, if allowed to participate in the election, their ballot is &#8220;cast&#8221; to the server and the voter receives a copy of their sealed ballot.</li>
<li> Upon receipt, the server publicly publishes the voter&#8217;s name and sealed ballot so the voter can verify that the sealed ballot is the same as the one cast.</li>
<li> Upon election conclusion, the server downloads all sealed ballots from the previously mentioned public place and scrambles and re-encrypts them with a mixnet.</li>
<li> The server then decrypts all ballots and tallies the totals, providing proof of correctness.</li>
</ul>
<p>The paper contains a few proposed improvements to current weaknesses, but I still felt it reasonable to discuss those weaknesses. More information on the broader implications of this system was presented in a Current Events article published earlier today.</p>
<h2>Assets and Security Goals</h2>
<ul class="unIndentedList">
<li> The election system needs to provide <em>ballot casting assurance</em>. The voter needs to be able to verify that his/her ballot was received, and received correctly in order for him/her to deem the election valid. The makes sure that the voting system cannot change or destroy a voter&#8217;s ballot without the voter being able to find out.</li>
<li> The election system needs to provide <em>universal verifiability</em>. <strong>Anyone</strong> must be able to independently and externally verify that all votes that were received were, in fact, counted and counted correctly in order for the election to be known to be valid. This, with the above, makes sure that not even the election administrators can tamper with the election.</li>
<li> The election system needs to provide <em>voter secrecy</em>. It should be impossible for <strong>anyone</strong> to link a voter and his/her vote in order for voters to be free to vote for whomever he/she wants without fear of punishment.</li>
</ul>
<h2>Adversaries and Threats</h2>
<ul class="unIndentedList">
<li> Anyone (including the election administrators) wishing to fix an election for monetary, religious, or political gain may try to change or destroy ballots or tamper with ballot counting without being discovered.</li>
<li> Anyone wishing to discover who voted for whom may try to link individual voters and ballots, either during or after voting.</li>
</ul>
<h2>Potential Weaknesses</h2>
<ul class="unIndentedList">
<li> It is possible, just after the voter casts his/her ballot, for a corrupt router to intercept the ballot en route to the Helios server and send the user a fake Helios server success code, causing the &#8220;voting booth&#8221; to immediately display a false success message and clear the ballot from memory. At worst, the voter fails to later check that their ballot was recorded on the server before the end of the election and his/her ballot is never counted. At best, the voter realizes their vote was not counted and has to cast a new ballot.</li>
<li> As it currently exists, if the election administrator allows Helios to administrate the election (as it seems they suggest doing), it is possible for a corrupt Helios server to create new, fake voters and cast ballots on their behalf without easily being discovered. Since the system relies upon voters validating their votes, it would be difficult to distinguish between actual voters who didn&#8217;t validate their vote and server-generated voters.</li>
<li> As the client-side code utilizes jQuery, LiveConnect, and Java BigInteger libraries, any vulnerabilities or cryptographic insecurities in that code could potentially be exploited to tamper with the election.</li>
<li> As currently implemented, the election administrator (who has the power to add voters and freeze the election) is authenticated through Google Accounts. Any vulnerability in the login (weak password, easily guessed security questions, etc.) could allow an attacker to end the election prematurely or add additional voters (potentially multiple accounts for the same voter).</li>
</ul>
<h2>Potential Defenses</h2>
<ul class="unIndentedList">
<li> The main defense the Helios system uses to prevent the sort of ballot manipulation or rejection described in the first weakness is to provide open-source tools for the user to verify that the ballot they have created (but not yet cast) does indeed contain the desired voting preferences. This seems to be the best-possible solution short of forcing the user to verify their ballot because it should be inherently impossible to validate the values in a ballot after it has been cast (otherwise others could view the values as well).</li>
<li> The Helios defense against a corrupt Helios administering a server and creating fake voters is to provide means for other election administrators to acquire and store the election&#8217;s private key necessary for decrypting the votes.</li>
</ul>
<h2>Risks and the Big Picture</h2>
<ul class="unIndentedList">
<li> The risks associated with this sort of system are nothing less that selling democracy to the highest bidder, or at least the one with the most computing power. If this sort of system were eventually used for a governmental election, the key lengths (currently 1024) would need to be significantly larger because the stake is so much higher. All of a sudden the researchers with 10,000 PS3 cells, or the BBC with a botnet of 10,000 computers might be able to crack encryption keys and tamper with ballots or fake election results. Since this system is based upon computational security, it needs to be implemented in such a way that even the best of the FBI cannot affect the results. Otherwise the currently established government could control all subsequent election results.</li>
<li> Most of the risks can be alleviated through complete voter validation of their ballots in combination with auditing of the election results given the provided proofs of correctness which are part of the system. If many voters do not do this, however, then it is possible for many security flaws to go unnoticed.</li>
</ul>
<h2>Conclusion</h2>
<p>The general idea is that here is finally a system which seems to hint that it may be possible to design an electronic voting system that is secure and transparent. The details have obviously not been ironed out, and may not be for some time, but the spirit of the system is enough to provide some hope in this era where <span style="text-decoration: line-through;">Diebold</span> Premier Election Solutions voting booths are still being used in US elections. The Helios system is not the solution, but it is a step in the right direction, if for no other reason than Kerckhoffs would be rolling in his grave if he knew how we trusted Diebold&#8217;s secret code to run this democracy. When not even the government in charge of an election can alter its outcome without the public being able to check, elections may finally be able to be trusted.</p>
<h2>Sources</h2>
<p>http://www.physorg.com/news155473407.html<br />
Adida, B., Helios: Web-based Open-Audit Voting, <em>Usenix Security 2008</em></p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/03/13/security-review-helios-online-voting/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Cryptography towards a new kind of election?</title>
		<link>http://cubist.cs.washington.edu/Security/2009/03/13/1249/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/03/13/1249/#comments</comments>
		<pubDate>Sat, 14 Mar 2009 04:11:54 +0000</pubDate>
		<dc:creator>Orion</dc:creator>
				<category><![CDATA[Current Events]]></category>
		<category><![CDATA[Integrity]]></category>
		<category><![CDATA[Privacy]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=1249</guid>
		<description><![CDATA[Computer scientists at the Harvard School of Engineering and Applied Sciences recently deployed the first “practical, Web-based, secure, verifiable voting system.” After testing through 2008 and early 2009, the system, dubbed “Helios,” was used for the university presidential elections at the Belgian Université Catholique de Louvain (UCL) in the first week of March 2009. The [...]]]></description>
			<content:encoded><![CDATA[<p>Computer scientists at the Harvard School of Engineering and Applied Sciences recently deployed the first “<a href="http://www.physorg.com/news155473407.html">practical, Web-based, secure, verifiable voting system</a>.” After testing through 2008 and early 2009, the system, dubbed “Helios,” was used for the university presidential elections at the Belgian Université Catholique de Louvain (UCL) in the first week of March 2009. The system uses asymmetric cryptography and mixnets to provide anonymity, ballot integrity, and open, public verifiability. The system is designed to be used to what they call “low-coercion” elections, because they have not provided any way for users to change their vote at another time if the user has been coerced into voting a certain way. But, the system does provide cryptographic auditing that allows any voter to verify that their vote has been correctly recorded, and allows anyone to verify that all recorded votes have been correctly tallied, something standard elections in the USA don’t even guarantee.</p>
<p><span id="more-1249"></span></p>
<p>This project rose out of the recognition that relatively recent advancements in cryptography and computer science have paved the way for the possibility of actually implementing election protocols that guarantee ballot casting assurance, universal verifiability, and voter secrecy. One issue that the developers of this system are facing is that the public is not really aware (or if they are, they fail to recognize the implications) of the lack of these properties in our current election system. Especially as absentee balloting is becoming more popular, there is little guarantee that 1) your vote is ever received, 2) that no one changed en route, 3) that it was counted at all, and 4) that is was counted correctly. The Helios system allows the user to verify 1, 2, and 3, and allows anyone to verify 4. The source for the Helios system is available for free under Creative Commons, and an <a href="http://www.heliosvoting.org">online server</a> is available for general use.</p>
<p>This new development is especially important given the recent Diebold debacle which emphasized the importance of Kerckhoffs&#8217; principle in the development of important security systems. Entrusting something as important as democracy to some proprietary, secret code hacked up by some people under investigation for putting Trojans in ATMs is no way to go. It will be interesting whether or not this new style of election will ever be used in general governmental elections, but it hints that the day when we may actually be able to cast e-votes with confidence is drawing near. If you are interested in more details of the Helios system, a follow-up security review will be posted shortly.</p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/03/13/1249/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Security Review: UW Parking Enforcement</title>
		<link>http://cubist.cs.washington.edu/Security/2009/03/13/security-review-uw-parking-enforcement/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/03/13/security-review-uw-parking-enforcement/#comments</comments>
		<pubDate>Fri, 13 Mar 2009 23:32:00 +0000</pubDate>
		<dc:creator>ezwelty</dc:creator>
				<category><![CDATA[Ethics]]></category>
		<category><![CDATA[Integrity]]></category>
		<category><![CDATA[Miscellaneous]]></category>
		<category><![CDATA[Security Reviews]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=1172</guid>
		<description><![CDATA[The parking at the University of Washington has always been a deadly game of cat and mouse between driver and parking enforcement. There are limited parking resources on campus, and parking enforcement wants to make sure that they are maximizing their revenue for the spaces they have available. On the flip side, poor students/faculty are [...]]]></description>
			<content:encoded><![CDATA[<p>The parking at the University of Washington has always been a deadly game of cat and mouse between driver and parking enforcement. There are limited parking resources on campus, and parking enforcement wants to make sure that they are maximizing their revenue for the spaces they have available. On the flip side, poor students/faculty are trying to get away with parking their cars/motorcycles free of charge.</p>
<p>There are a few assets that parking enforcement wants to protect. One is their revenue stream &#8212; making sure that they are receiving money for the parking that is available. Another is the availability of spaces, so that legitimate paying customers won&#8217;t be turned away at the door if the lots are oversold. In both cases, the adversary is the driver trying to cheat the system (aka, me).</p>
<p>One weakness of the system stems from having way more parking spots than there are parking enforcement officials. While this can work in an cheater&#8217;s favor in general, the longer one spends in the same spot, the more likely they are to be eventually ticketed. This might assume someone illegally parked would stay shorter &#8212; but then they have the added overhead of having to move their car frequently. One way that they can combat this is to deploy resources first towards the most high-traffic lots, and then check less frequently at satellite lots.</p>
<p>Another weakness of the system involves procedures for contesting tickets through the parking department. Any ticket can be contested through the office, and last checked, they had an average turnaround of 3-6 months, no doubt due to bureaucratic inefficiencies. If an adversary were to contest a ticket, they wouldn&#8217;t have to pay it for months, and would be likely to get it fined. One could also try sending in a longer letter to the department as to why they deserve to not get the ticket, in order to push it to the back of the queue for processing.</p>
<p>In the future, there might be an emphasis on more high-tech solutions (such as cameras) to quickly monitor parking lots and possibly detect cheaters. For the time being, however, there are some vulnerabilities in the parking system that allow attackers to get away with free campus parking undetected.</p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/03/13/security-review-uw-parking-enforcement/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Current Event: Air Force Engineers develop BitTorrent sniffer</title>
		<link>http://cubist.cs.washington.edu/Security/2009/03/13/current-event-air-force-engineers-develop-bittorrent-sniffer/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/03/13/current-event-air-force-engineers-develop-bittorrent-sniffer/#comments</comments>
		<pubDate>Fri, 13 Mar 2009 20:52:06 +0000</pubDate>
		<dc:creator>ezwelty</dc:creator>
				<category><![CDATA[Current Events]]></category>
		<category><![CDATA[Ethics]]></category>
		<category><![CDATA[Integrity]]></category>
		<category><![CDATA[Privacy]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=1146</guid>
		<description><![CDATA[Original article: http://arstechnica.com/security/news/2009/02/airforce-engineers-develop-bittorrent-sniffer.ars
The Air Force Institute of Technology has a new method for passive BitTorrent tracking. The system attempts to read the header of BitTorrent packets, and compare the hash in the packet to a known set of bad hashes. If a bad hash is matched, then the system logs it for future investigation. The [...]]]></description>
			<content:encoded><![CDATA[<p>Original article: <a href="http://arstechnica.com/security/news/2009/02/airforce-engineers-develop-bittorrent-sniffer.ars">http://arstechnica.com/security/news/2009/02/airforce-engineers-develop-bittorrent-sniffer.ars</a></p>
<p>The Air Force Institute of Technology has a new method for passive BitTorrent tracking. The system attempts to read the header of BitTorrent packets, and compare the hash in the packet to a known set of bad hashes. If a bad hash is matched, then the system logs it for future investigation. The system uses programmable FPGAs, and sniffing capacity tops out at 100Mbps.</p>
<p>Recent developments in traffic shaping / packet analysis have been largely spurred by large ISPs&#8217; desire to limit user&#8217;s consumption of high-bandwidth services such as BitTorrent. Complaints towards users of BitTorrent include high bandwidth usage, as well as accusations of illegally sharing copyrighted material.</p>
<p>However, packet inspection at any level raises a number of privacy concerns, as systems at the ISP level would definitively be reading the data that flows through their network from an end user&#8217;s machine. This can either be malicious or not &#8212; it really depends on <a href="http://blog.johnath.com/2009/03/05/deep-packet-inspection-considered-harmful/comment-page-1/">how ISPs use it</a>. It seems like ISPs are highly motivated to keep traffic down so that they can keep their networks from becoming congested. However, no ISP customer can ever exceed the maximum amount of bandwidth that they are advertised to get. It seems like the ISPs are not being forthcoming about the real amount of bandwidth that they want customers to use.</p>
<p>Bandwidth isn&#8217;t the only issue, with litigation being handed out to file sharers. It&#8217;s in the ISP&#8217;s best interest to stay out of any legal issues they can, which also provides a good motivator for packet shaping BitTorrent traffic. However, given millions of motivated BitTorrent users versus companies with relatively limited resources, they are fighting an uphill battle that will not end up in their favor. This Air Force sniffing technology can&#8217;t detect encrypted BitTorrent packets, which compromise 25% of the BT traffic out there. As well, with projects such as <a href="http://oneswarm.cs.washington.edu">OneSwarm</a>, people can set up much more anonymous sharing networks between friends. The only way for corporations to survive file sharing is to adapt, <a href="http://tech.slashdot.org/article.pl?sid=09/03/08/2129255&amp;from=rss">like the Norwegian state broadcasting company did</a> when it started offering its broadcasts as full, unencrypted downloads on its own hosted BitTorrent tracker.</p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/03/13/current-event-air-force-engineers-develop-bittorrent-sniffer/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Current Event: racial profiling no more effective than random screening</title>
		<link>http://cubist.cs.washington.edu/Security/2009/02/06/current-event-racial-profiling-no-more-effective-than-random-screening/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/02/06/current-event-racial-profiling-no-more-effective-than-random-screening/#comments</comments>
		<pubDate>Fri, 06 Feb 2009 16:56:08 +0000</pubDate>
		<dc:creator>ezwelty</dc:creator>
				<category><![CDATA[Current Events]]></category>
		<category><![CDATA[Ethics]]></category>
		<category><![CDATA[Integrity]]></category>
		<category><![CDATA[Physical Security]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=700</guid>
		<description><![CDATA[In &#8220;Study: racial profiling no more effective than random screen&#8221;, ArsTechnica reports on a new study by William Press, who claims that using profiling at security checkpoints such as airports is not effective in catching threats. The ineffectiveness, according to Press, stems from small numbers of screeners being able to only resample a small subset [...]]]></description>
			<content:encoded><![CDATA[<p>In &#8220;Study: racial profiling no more effective than random screen&#8221;, ArsTechnica reports on a new study by William Press, who claims that using profiling at security checkpoints such as airports is not effective in catching threats. The ineffectiveness, according to Press, stems from small numbers of screeners being able to only resample a small subset of the total population at any given moment. Screeners, on the average, end up retesting the same innocent individuals that happen to have large correlations with risk profiles.</p>
<p>This event arises from the current security concerns of DHS, and their mandate to catch terrorists at the various entrances to the United States. It seems that the methods employed in profiling are faulty, and need revisiting. As a counter-example to this article, the Israeli airports employ racial profiling to great success in ensuring security, and <a href="http://en.wikipedia.org/wiki/Airport_security#Israel" target="_blank">haven&#8217;t had an incident since 1986</a> &#8212; however, they combine these profiling methods with other forms of security measures.</p>
<p>However, there are larger issues in having such broad-sweeping racial profiling in the US. Applying racial targeting to minorities at checkpoints would cause a fair amount of backlash, considering the historical implications. As well, all the racial groups that are on profiling lists also are likely not adversarial threats, and are certainly as legitimate of citizens as people that aren&#8217;t on the list. Also, it seems like  relying heavily on profiling means that defeating it is simply a matter of not fitting the current terrorist profile.</p>
<p>While there has been some success stories in racial profiling with regards to border security, the idea leaves a bad taste in my mouth. There are inarguably a number of things that DHS can do to improve security at checkpoints (<a href="http://www.theaviationnation.com/2009/01/15/rhona-mahony-packs-gunpowder-tsa-ignores/" target="_blank">hire competent TSA employees</a> comes to mind), without going down the dangerous path of racial profiling &#8212; profiling that has been shown in this recent study to be mostly ineffective given how it is currently applied.</p>
<p>Original Article: <a href="http://en.wikipedia.org/wiki/Airport_security#Israel" target="_blank">http://arstechnica.com/science/news/2009/02/study-racial-profiling-no-more-effective-than-random-screen.ars</a></p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/02/06/current-event-racial-profiling-no-more-effective-than-random-screening/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Current Event: Rigged Red Lights</title>
		<link>http://cubist.cs.washington.edu/Security/2009/02/06/current-event-rigged-red-lights/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/02/06/current-event-rigged-red-lights/#comments</comments>
		<pubDate>Fri, 06 Feb 2009 09:05:01 +0000</pubDate>
		<dc:creator>petermil</dc:creator>
				<category><![CDATA[Current Events]]></category>
		<category><![CDATA[Ethics]]></category>
		<category><![CDATA[Integrity]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=692</guid>
		<description><![CDATA[Summary
In Italy, public officials have been abusing their authority to make more money from the public by making reds come earlier than they are supposed to (a shorter duration yellow than legally allowed).   This means that, since they use cameras to automatically give tickets to people running red lights (see security review of automated traffic [...]]]></description>
			<content:encoded><![CDATA[<p><strong>Summary</strong></p>
<p>In Italy, public officials have been abusing their authority to make more money from the public by <a href="http://arstechnica.com/tech-policy/news/2009/02/italian-red-light-cameras-rigged-with-shorter-yellow-lights.ars">making reds come earlier</a> than they are supposed to (a shorter duration yellow than legally allowed).   This means that, since they use cameras to automatically give tickets to people running red lights (see <a href="http://cubist.cs.washington.edu/Security/2009/02/05/security-review-automated-traffic-enforcement/">security review of automated traffic cameras</a> for a different look at that aspect of it), they can make money off residents who are given inadequate time to come to a stop, and thus must run a red.</p>
<p><strong>Who Was Hurt By It<br />
</strong></p>
<p>Drivers have been economically affected, with 1439 people caught over two months (the fine is 150 Euros, or roughly $190 at current exchange rate).  Prior to that, at most 900 people would have been expected to be caught assuming the maximum number of tickets normally given were given out per day (this means a 50% increase over a value previously considered unrealistic to obtain!).</p>
<p>The public has also suffered a reduced amount of trust in the transparency and honesty of their government&#8211;a system which was out of their control and which they were mostly powerless to oppose or investigate was found to have been compromised in such a way that people were labelled as both criminals and charged unfair money.</p>
<p><strong>Who Did It</strong></p>
<p>109 officials are being investigated with regards to it, although the programmer himself is the current person taking most of the blame in the news.  Also involved were: police, local government officials, and the heads of seven different companies. Roughly 300 municipalities and a host of different companies were profiting from this scheme.</p>
<p><strong>What&#8217;s Being Done</strong></p>
<p>Currently a criminal case is being pursued against those responsible.  However, this does not really address the problem&#8211;the faulty systems are still in use, and ultimately fixing them should be the first priority.  Although the programmer responsible has a lawyer proclaiming his innocence, ultimately a review of the cameras themselves will need to be done.</p>
<p><strong>Long Term View</strong></p>
<p>This adds yet another complaint against automated traffic cameras.  Many object on privacy reasons, but this also adds concerns about faulty software, either maliciously or through incompetence.  Although it is unlikely that Italy will suddenly abandon automated traffic cameras, it may cause them to take a second look at them, at the least, and hopefully be more open in the future.  In all likelihood, however, they will continue to use a closed source solution, and will merely (hopefully) patch this problem.</p>
<p>Finally, this also adds another potential weakness to the list in the security review&#8211;corrupt officials who view it as a way of making more money.</p>
<p>Source: <a href="http://arstechnica.com/tech-policy/news/2009/02/italian-red-light-cameras-rigged-with-shorter-yellow-lights.ars">http://arstechnica.com/tech-policy/news/2009/02/italian-red-light-cameras-rigged-with-shorter-yellow-lights.ars</a></p>
<p>See also: <a href="http://cubist.cs.washington.edu/Security/2009/02/05/security-review-automated-traffic-enforcement">http://cubist.cs.washington.edu/Security/2009/02/05/security-review-automated-traffic-enforcement</a></p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/02/06/current-event-rigged-red-lights/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Security Review: ShopAds from Adgregate Markets</title>
		<link>http://cubist.cs.washington.edu/Security/2009/02/05/security-review-shopads-from-adgregate-markets/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/02/05/security-review-shopads-from-adgregate-markets/#comments</comments>
		<pubDate>Fri, 06 Feb 2009 04:30:40 +0000</pubDate>
		<dc:creator>rctucker</dc:creator>
				<category><![CDATA[Integrity]]></category>
		<category><![CDATA[Privacy]]></category>
		<category><![CDATA[Security Reviews]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=665</guid>
		<description><![CDATA[In early September 2008 during the TechCrunch50 Conference, there we many companies that came forward presenting ideas on how to change the advertising business.  One such company,  Adgregate Markets, presented an idea they call the ShopAds widget.  This widget can be placed on any website like a normal banner ad, but is instead [...]]]></description>
			<content:encoded><![CDATA[<p>In early September 2008 during the TechCrunch50 Conference, there we many companies that came forward presenting ideas on how to change the advertising business.  One such company, <a href="http://www.adgregate.com/"> Adgregate Markets</a>, presented an idea they call the ShopAds widget.  This widget can be placed on any website like a normal banner ad, but is instead a fully transactional ad that allows visitors to the site the ad is place on to conduct a business transaction (such as buying and item or ordering a service) without leaving the hosting web page.</p>
<p>This is big news both for host sites that may gain revenue from their ads, as well as the companies trying to sell a product.  For host sites, it means their pages are sticky; visitors no longer leave the for a 3rd party site when they see a product they like.  Instead, they can just purchase it and continue to view the content.  For  the company selling the product, it means their returns are much greater than previous click-through counting methods as the results they are in the form of actual sales and revenue.</p>
<p>But what does this mean for the online consumer? Of course, it means they can now make purchases through ads without having to go to another site, but it <em>also</em> means they have to be smarter.  Adgregate claims in their <a href="http://www.techcrunch50.com/2008/conference/press_releases/feeef21605a27e30fa531c7b16b8e074.pdf">press release</a> that &#8220;Through ShopAds, Adregate Markets enables consumers to securely purchase products entirely within the confines of the ad unit, without being redirected away from the publisher&#8217;s site.&#8221;  However, a problem arises when a ShopAds widget is placed on a web page that uses HTTP instead of HTTPS.  Since the page itself is transmitted HTTP, the content of the page is in plaintext. Additionally there is no way to verify that widget came from any particular location.  For example, a malicious router launching a man-in-the-middle attack could replace the widget on a page with their own widget that appears to be legitimate.  Visitors to the web page may then interact with it assuming it is the company it says it is.  Although ShopAds are flash-based, and thus can establish secure connections, this only has meaning if the source of the ad itself can be verified.</p>
<p>Assets and Security Goals:</p>
<ul>
<li>Purchase Orders &#8211; The purchase made by a visitor/customer must be accurate when it is received by the merchant company.</li>
<li>Consumer Identities &#8211; Identifying information, such as credit card numbers, should not.</li>
<li>Merchant Identities &#8211; It should be possible for a consumer to know for sure that they are buying from a particular merchant.  In other words, it should not be possible for an adversary to pretend to be a Macy&#8217;s ad.</li>
</ul>
<p>Potential Adversaries or Threats</p>
<ul>
<li>Eavesdroppers &#8211; It could be possible to collect customer information by sniffing packets</li>
<li>Copy Cats -  By replacing ShopAds widgets with a malicious flash ad, one could pretend to be a company that they are not.</li>
<li>Modifiers &#8211; By modifying the information being exchanged, it may be possible to alter the purchase order itself (such as the quantity of certain items) or change where it is being shipped to.</li>
</ul>
<p>Potential Weaknesses</p>
<ul>
<li>HTTP Pages &#8211; Pages using HTTP cannot guarantee the origin of the content displayed on the page, including the ShopAds widget, and would be vulnerable to man-in-the-middle attacks.  Additionally, information is sent over plaintext.</li>
<li>HTTPS Pages &#8211; Even on an HTTPS page, you would have to trust the hosting (publishing) website you were visiting.  HTTPS only verifies that the site is who they say they are. So, visiting https://www.evil.com and conducting a business transaction through one of their evil ads is still dangerous.</li>
<li>ShopAds Widget &#8211; If the widget does not take advantage of  the features in flash to establish secure connections, information may be sent over plaintext.</li>
</ul>
<p>Potential Defenses</p>
<ul>
<li>HTTPS Pages &#8211; HTTPS pages can at least guarantee that the page is who they say they are and that the data is not sent over plaintext.  If a customer trusts the hosting/publishing site, and they trust the company who owns the ad, they could trust the transaction.  However, this would require every page with a ShopAds widget to use HTTPS&#8230;</li>
<li>Flash Security &#8211; Make sure to take advantage of features to establish secure connections to prevent transaction information from being transmitted in plaintext, even if the widget is properly placed on a trusted HTTP page that has not been maliciously modified.</li>
<li>Ad/Merchant Verification &#8211; Having the potential for a consumer to verify that the ad belongs to a particular consumer would help guarantee online shoppers do not buy from copy-cats.  Ideally, this would be done in the widget as well so as to keep to the nature of this new technology.</li>
</ul>
<p>The largest problem here is that consumers may have no idea about the threats posed by these types of ads.  Many customers may not even know why HTTPS is important, let alone how it affects the security of shopping through an ad. Furthermore, it is unlikely that every page that will be sporting the ShopAds widgets will start using HTTPS, so shoppers will learn to have trust in these very dangerous situations. Even if the publishing site can be trusted, if the widget is not on an HTTPS page, it cannot be trusted.</p>
<p>If the ShopAds widget is to become the next best thing in advertisement and online shopping, these security concerns will have to be addressed.  In the same way that an online banker would not (hopefully!) enter their bank account number and password on an insecure page, neither should an online shopper provide their credit card or other identifying information.  It will also be necessary for shoppers to be more aware of where and how they are making purchases.  To help out visitors to the site, some of the responsibility may rest with the publishing website to make sure the ads they are providing do not compromise the identities of its visitors.  If this does catch on, it may become necessary in the future for browsers to be able to verify the origin of chunks of content, such as the ShopAds widget, to guarantee the security of its users.</p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/02/05/security-review-shopads-from-adgregate-markets/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Wikipedia Editing Could Be Made More Restrictive Due to Vandalism</title>
		<link>http://cubist.cs.washington.edu/Security/2009/01/30/wikipedia-editing-could-be-made-more-restrictive-due-to-vandalism/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/01/30/wikipedia-editing-could-be-made-more-restrictive-due-to-vandalism/#comments</comments>
		<pubDate>Sat, 31 Jan 2009 03:56:35 +0000</pubDate>
		<dc:creator>jap24</dc:creator>
				<category><![CDATA[Availability]]></category>
		<category><![CDATA[Current Events]]></category>
		<category><![CDATA[Integrity]]></category>
		<category><![CDATA[Add new tag]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=599</guid>
		<description><![CDATA[According to this article, the English version of Wikipedia may be implementing a system called “flagged revisions” to the editing software, which would require that edits would have to be approved (“flagged”) by a “trusted” user (see the Wikipedia page on flagged revisions here).   Edits that have not yet been approved could be [...]]]></description>
			<content:encoded><![CDATA[<p>According to <a title="this" href="http://news.cnet.com/8301-1023_3-10149648-93.html?part=rss&amp;subj=news&amp;tag=2547-1_3-0-20">this </a>article, the English version of Wikipedia may be implementing a system called “flagged revisions” to the editing software, which would require that edits would have to be approved (“flagged”) by a “trusted” user (see the Wikipedia page on flagged revisions <a href="http://en.wikipedia.org/wiki/Wikipedia:Flagged_revisions">here</a>).   Edits that have not yet been approved could be viewed by users on request, but the default version of a page would exclude any changes that have not yet been approved.  Trusted users’ edits are automatically approved.  There could be long wait times for edits to be approved; this system has already been implemented in the German Wikipedia version, and edits there have taken as long as three weeks to be approved. <span id="more-599"></span></p>
<p>This change was proposed to combat vandalism.  As it is now, a user could maliciously and instantaneously change the content of any article in an arbitrary way.  For example, the article announcing the proposed change noted an instance of vandalism where a Wikipedia user vandalized Senator Ted Kennedy’s article to say that he had died after President Obama’s inauguration.  According to <a href="http://en.wikipedia.org/wiki/Wikipedia:Vandalism">Wikipedia’s page on Vandalism</a>, the current method of dealing with vandalism is to delete the changes, and  possibly take action against the user who posted the changes.  A user believed to have vandalized an article could be given a warning, or blocked from making any further edits by an administrator.  This current policy still allows the flawed article to be seen (and possibly taken as fact).  The flagged revision system would mean that malicious edits might never be seen at all.</p>
<p>Another way to discourage vandalism might be to impose more draconian penalties on users thought to be maliciously altering articles, such as banning both the user and the computer from accessing Wikipedia in the future.  This would be too harsh, since foolish edits could possibly be innocent mistakes, and there could be more than one person using a given computer.   Another alternative would be to only allow users who are already considered trustworthy to make edits.  This would be too restrictive, and does not allow for as broad a community of editors as Wikipedia has currently.  The only methods that seem to allow for a reasonable amount of freedom for users are the current reactive system, and the flagged revision proposal.</p>
<p>With the proposed system, Wikipedia is trying to ensure the correctness of the content of its articles.  Vandalism could potentially hurt users by spreading false information.  This is especially troublesome for people such as this author, who generally trusts Wikipedia to be accurate.   Vandalism also harms Wikipedia’s reputation for accuracy, perhaps deterring potential users from using the website at all.</p>
<p>The flagged revision idea does seem to be a good way to prevent vandalism, assuming there is a reasonable system for selecting which users are considered “trusted.”   However, it also reduces the freedom of the Wikipedia users to make edits.  Also, since all changes are subject to the perceptions of the trusted users, it is possible for those trusted users to exercise censorship against other users.  In addition, the proposed system would place a very large burden on the trusted users to inspect others edits so that they can be added to the article within a reasonable amount of time.  It would limit the ability of Wikipedia’s editors to modify articles to keep up with current events, something that has been a useful feature.  Despite the flaws of the current more permissive system, it might be better for Wikipedia to leave it as it is.</p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/01/30/wikipedia-editing-could-be-made-more-restrictive-due-to-vandalism/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Absent student forfeits raffle</title>
		<link>http://cubist.cs.washington.edu/Security/2009/01/16/absent-student-forfeits-raffle/</link>
		<comments>http://cubist.cs.washington.edu/Security/2009/01/16/absent-student-forfeits-raffle/#comments</comments>
		<pubDate>Sat, 17 Jan 2009 05:23:46 +0000</pubDate>
		<dc:creator>stemcel</dc:creator>
				<category><![CDATA[Current Events]]></category>
		<category><![CDATA[Ethics]]></category>
		<category><![CDATA[Integrity]]></category>
		<category><![CDATA[Physical Security]]></category>

		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/?p=460</guid>
		<description><![CDATA[Here at the University of Washington CSE Department we often have events called Tech Talks, where guest companies come in and give a demonstration of their technologies and expertise. Last night we had a tech talk given by Palantir Technologies, a very promising-looking company that aims to transform the way people work with large data sets by making it easier to discover and visualizing trends and connections in the ever-accumulating mountains of data generated by our modern technological culture. And at the end of the evening they planned to raffle off an iPod touch.]]></description>
			<content:encoded><![CDATA[<p>Here at the University of Washington CSE Department we often have events called Tech Talks, where guest companies come in and give a demonstration of their technologies and expertise. Tech talks are usually interesting, and the visiting companies usually bring free company-branded &#8220;swag&#8221; and often have raffles for bigger, more exciting prizes. But what usually draws hungry CS students (this one, anyway) is the free food that the company inevitably brings. I&#8217;ve never won anything.</p>
<p>Last night we had a tech talk given by <a href="http://www.palantirtech.com/">Palantir Technologies</a>, a very promising-looking company that aims to transform the way people work with large data sets by making it easier to discover and visualizing trends and connections in the ever-accumulating mountains of data generated by our modern technological culture. They had a great sales pitch, a fascinating presentation, tons of free swag (hyperbole here, but it was really a lot), and quality free frood from Taco del Mar. And at the end of the evening they planned to raffle off an iPod touch. Not everyone stayed for the whole event, but as it wound down the time for the raffle finally came.</p>
<p><span id="more-460"></span>Normally everyone attending a tech talk who is interested in participating in a raffle writes their name on a piece of paper, folds it in half, and places it in a box/hat/whatever. Palantir had all the entries in a black beanie, and built up the suspense before reaching into the hat and pulling out a name. Drat, not me again. I could tell by the size and shape of the paper that some other student was the lucky recipient. But who? The Palantir rep unfolded the paper and read it aloud in stentorian tones: &#8220;John Smith!&#8221; (That&#8217;s not really his name, but that&#8217;s not the point of this story. We&#8217;ll call him &#8220;John Smith.&#8221;) I looked around for John, but couldn&#8217;t see him. &#8220;He&#8217;s not here!&#8221; I called, joined by several other voices. Maybe I&#8217;d have a chance to win this after all! &#8220;Not here?&#8221; asked the rep. &#8220;Well, we&#8217;ll just draw again.&#8221; He tossed the forfeited entry aside and reached into the hat again. Suspense built as he pulled out a piece of paper, unfolded it, and read aloud once again&#8230;. &#8220;John Smith!&#8221; The atrium was silent for a few seconds. After a moment or two had passed I said &#8220;Well, that explains a few things.&#8221;</p>
<p>I&#8217;d always attributed to luck the fact that some people just seem to win more often in raffles like that. Naively you might expect not to see repeat winners (after all, it has to be spread around, right?), but a little bit of probabilistic reasoning tells you that runs or repeats may be improbable in any specific case but in general are to be expected. Now I suddenly admitted the possibility that while there was something chancey going on here, it wasn&#8217;t chance. And why not, right? If you&#8217;re having a one-item raffle there&#8217;s no reason not to put your name in more than once. No one&#8217;s going to go looking through the entries afterwards, and if you win you win. Unless, of course, you&#8217;re not there and you win. Twice.</p>
<p>It&#8217;s possible that I&#8217;ve misunderstood all these years the unwritten rules that these raffle are run by, or perhaps more properly the unwritten rules that these raffles are <em>won</em> by. After all, there are many raffles, sweepstakes, etc. where multiple entries are accepted. But if not, well, that&#8217;s a different story.</p>
<p>Obviously no one was hurt here, no bones broken and no innocents harmed (though perhaps some innocence was lost). But these sort of events should be treated seriously. Real things are at stake. I&#8217;ll list just some of the things I&#8217;ve seen go at tech talk raffles recently:</p>
<ul>
<li> iPod touch: <a href="http://www.apple.com/ipodtouch/">at least $229</a></li>
<li>Xbox 360: <a href="http://www.amazon.com/s/qid=1232169098/ref=sr_nr_p_4_0?ie=UTF8&amp;rs=172282&amp;keywords=xbox%20360&amp;bbn=172282&amp;rnid=15784691&amp;rh=i%3Aaps%2Ck%3Axbox%20360%2Ci%3Aelectronics%2Cn%3A172282%2Cp_36%3A20000-99999999%2Cp_4%3AXBOX">$300 or so</a></li>
<li>Adobe Design suites: <a href="https://store1.adobe.com/cfusion/store/html/index.cfm?store=OLS-US&amp;promoid=121DJGPP_P_US_M_ABCD_MC_CS4_B_1&amp;event=displayProduct&amp;categoryPath=/Applications/CSMasterCollection&amp;distributionMethod=FULL&amp;fpr=true">$&#8230; a whole lot</a></li>
<li>Integrity? Priceless</li>
</ul>
<p>I guess in the broader context you&#8217;re not stealing anything by stuffing a raffle hat. Not from me anyway. But how far is it from there to stuffing ballot boxes? Bank accounts? Money is all just bits now anyway. A little extra here and there wouldn&#8217;t really hurt the economy. Should we be comfortable with this sort of attitude being held by the same people who may write the software that handles your bank account? I don&#8217;t think so. A paper-cut is a little thing, once. But this way of thinking, when carried to its natural conclusion, is not just one paper cut. It&#8217;s many. And that&#8217;s not sustainable.  I used to think that around here we just didn&#8217;t have to worry about that sort of thing.</p>
<p>I wish I could have kept thinking it, if just for a little longer.</p>
]]></content:encoded>
			<wfw:commentRss>http://cubist.cs.washington.edu/Security/2009/01/16/absent-student-forfeits-raffle/feed/</wfw:commentRss>
		<slash:comments>6</slash:comments>
		</item>
	</channel>
</rss>
