<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title><![CDATA[[SecurityRatty] tag: cent]]></title>
    <link>http://securityratty.com/tag/cent</link>
    <description></description>
    <pubDate>Thu, 10 Apr 2008 12:17:52 +0000</pubDate>
    <generator>iRatty Engine</generator>
    <docs>http://blogs.law.harvard.edu/tech/rss</docs>
    <item>
      <title><![CDATA[The Ayyildiz Turkish Hacking Group VS Everyone]]></title>
      <link>http://securityratty.com/article/e5949393a0e7be6e2ea6b20dadaba58c</link>
      <guid>http://securityratty.com/article/e5949393a0e7be6e2ea6b20dadaba58c</guid>
      <description><![CDATA[Certain hacktivist groups often come and go by the time the momentum of their particular cause is long gone. Excluding the hardcore hacktivists who are obliged to defend their country's infrastructure...]]></description>
      <content:encoded><![CDATA[<div style="text-align: left;"></div><div class="separator" style="text-align: center; clear: both;"></div><div style="text-align: left;"></div><div class="" style="clear: both;"><a href="http://bp0.blogger.com/_wICHhTiQmrA/SH-6Lbjq6XI/AAAAAAAAB7M/dn0skav9XIg/s1600-h/AYYILDIZ_TEAM.jpg" imageanchor="1" style="border: 0pt none ; background-color: transparent; clear: left; margin-bottom: 1em; float: left; margin-right: 1em;"><img src="http://bp0.blogger.com/_wICHhTiQmrA/SH-6Lbjq6XI/AAAAAAAAB7M/mYlVgqX-mVU/s200-R/AYYILDIZ_TEAM.jpg" style="border: 0pt none ;" /></a>Certain hacktivist groups often come and go by the time the momentum of their particular cause is long gone. Excluding the hardcore hacktivists who are obliged to defend their country's infrastructure and reputation on the international scene, smart enough to do on one front, there are certain hacktivist groups who ensure their future existence by declaring war and every single country that has ever made statements in contradiction with their vision. Quite a stimulating factor for ensuring the future of your script kiddies group, isn't it?<br />
<br />
One of these groups is the AYYILDIZ TEAM, a group of Turkish script kiddies who've been pretty active as of recently, targeting everyone, everywhere, leaving statements like the following :</div><br />
"<i>Me, as AYT-Admin Barbaros, swear to everything which is lovely and holy to me, that you will pay for your actions. We, AYT, as a Cyber Attacking Army will make it sure. Read right, what will we do:<br />
<br />
* The government websites will be inaccessible an all lawsuits will be manipulated</i><br />
<i>* We will infiltrate the server of inland revenues for the manipulation of the data which are there.</i><br />
<i>* At the same time we will insist into the server of banks and will care for chaos</i><br />
<i>* Websites of the press will be extinguished.</i><br />
<i>* If the offence of our prophet (s.a.v.) called your press freedom, we will show you this press freedom</i><br />
<i>* Websites of divers shops will be hacked. Databank information's and the dates which are there, for example credit card dates, will be policed in this page. (Don't worry, we wouldn't taste one cent of your moneys, we aren't thieves like you. However we don't take care of what happens, if other hackers see this dates and empty your account)</i>"<br />
<br />
<div style="text-align: left;"></div><div class="separator" style="text-align: center; clear: both;"></div><a href="http://bp0.blogger.com/_wICHhTiQmrA/SIBtXRQhuII/AAAAAAAAB7U/WwX3npoBZvI/s1600-h/SQL_turkz.JPG" imageanchor="1" style="border: 0pt none ; background-color: transparent; clear: left; margin-bottom: 1em; float: left; margin-right: 1em;"><img src="http://bp0.blogger.com/_wICHhTiQmrA/SIBtXRQhuII/AAAAAAAAB7U/saIYE3fxpdA/s200-R/SQL_turkz.JPG" style="border: 0pt none ;" /></a>While this may sound inspiring, <b>some of the group's members are also involved in SQL injections in between the web site defacements</b>, which are naturally done by exploiting web application vulnerabilities. For instance, right after the defacement messages, they are also injecting the following fast-fluxed domains, part of the latest wave of SQL injections attacks.<b></b><br />
<br />
<b>bkpadd.mobi /ngg.js<br />
usaadw.com /ngg.js<br />
cliprts.com /ngg.js</b><br />
<br />
They are monetizing their defacements by either compiling lists of sites known to be SQL injectable since they've managed to defaced them, then reselling these to the SQL injectors, or are in fact part of the whole process in this scammy ecosystem. Speaking of SQL injections, here's the most recent list of fast-fluxed SQL injected domains participating in the last wave that I've been keeping track of for a while :<br />
<br />
<b>pyttco .com/ngg.js<br />
butdrv .com/ngg.js<br />
gitporg .com/ngg.js<br />
brcporb .ru/ngg.js<br />
korfd .ru/ngg.js<br />
adwnetw .com/ngg.js<br />
wowofmusiopl .com.cn/456.js<br />
adwbn .ru/ngg.js<br />
btoperc .ru/ngg.js<br />
nudk .ru/ngg.js<br />
bkpadd .mobi/ngg.js<br />
cliprts .com/ngg.js<br />
adwr .ru/ngg.js<br />
bnrc .ru/ngg.js<br />
adpzo .com/ngg.js<br />
iogp .ru/ngg.js<br />
lodse .ru/ngg.js<br />
usabnr .com/ngg.js<br />
vcre .ru/ngg.js<br />
sdkj .ru/ngg.js<br />
rcdplc .ru/ngg.js<br />
7maigol .cn/ri.js<br />
j8heisi .cn/ri.js<br />
usaadp .com/ngg.js<br />
gbradp .com/ngg.js<br />
cdrpoex .com/ngg.js<br />
rrcs .ru/ngg.js<br />
gbradw .com/ngg.js<br />
hiwowpp .cn/ri.js<br />
cdport .eu/ngg.js<br />
nopcls .com/ngg.js<br />
loopadd .com/ngg.js<br />
tertad .mobi/ngg.js<br />
gbradde .tk/ngg.js<br />
tctcow .com/ngg.js<br />
ausbnr .com/ngg.js<br />
movaddw .com/ngg.js<br />
grtsel .ru/ngg.js<br />
sslwer .ru/ngg.js<br />
destad .mobi/ngg.js<br />
hdrcom .com/ngg.js<br />
addrl .com/ngg.js<br />
porttw .mobi/ngg.js<br />
bnsdrv .com/ngg.js<br />
drvadw .com/ngg.js<br />
crtbond .com/ngg.js<br />
usaadw .com/ngg.js</b><br />
<br />
What used to be plain simple cooperating among every single participant in the underground marketplace, seems to be evolving into long-term business relationships.<br />
<br />
<b>Related posts:</b><br />
<a href="http://ddanchev.blogspot.com/2008/07/monetizing-compromised-web-sites.html">Monetizing Compromised Web Sites</a><br />
<a href="http://ddanchev.blogspot.com/2008/06/monetizing-web-site-defacements.html">Monetizing Web Site Defacements</a><br />
<a href="http://ddanchev.blogspot.com/2008/06/underground-multitasking-in-action.html">Underground Multitasking in Action</a><br />
<a href="http://ddanchev.blogspot.com/2008/06/right-wing-israeli-hackers-deface.html">Right Wing Israeli Hackers Deface Hamas's Site</a><br />
<a href="http://ddanchev.blogspot.com/2008/05/pro-serbian-hacktivists-attacking.html">Pro-Serbian Hacktivists Attacking Albanian Web Sites</a><br />
<a href="http://ddanchev.blogspot.com/2008/04/rise-of-kosovo-defacement-groups.html">The Rise of Kosovo Defacement Groups</a><br />
<a href="http://ddanchev.blogspot.com/2008/04/commercial-web-site-defacement-tool.html">A Commercial Web Site Defacement Tool</a><br />
<a href="http://ddanchev.blogspot.com/2008/04/phishing-tactics-evolving.html">Phishing Tactics Evolving</a><br />
<a href="http://ddanchev.blogspot.com/2008/04/web-site-defacement-groups-going.html">Web Site Defacement Groups Going Phishing</a><br />
<a href="http://ddanchev.blogspot.com/2006/02/hacktivism-tensions.html">Hacktivism Tensions</a><br />
<a href="http://ddanchev.blogspot.com/2006/07/hacktivism-tensions-israel-vs.html">Hacktivism Tensions - Israel vs Palestine Cyberwars</a><br />
<a href="http://ddanchev.blogspot.com/2007/11/mass-defacement-by-turkish-hacktivists.html">Mass Defacement by Turkish Hacktivists</a><br />
<a href="http://ddanchev.blogspot.com/2007/11/overperforming-turkish-hacktivists.html">Overperforming Turkish Hacktivists</a><div class="feedflare">
<a href="http://feeds.feedburner.com/~f/DanchoDanchevOnSecurityAndNewMedia?a=727PxJ"><img src="http://feeds.feedburner.com/~f/DanchoDanchevOnSecurityAndNewMedia?i=727PxJ" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/DanchoDanchevOnSecurityAndNewMedia?a=JwIAWJ"><img src="http://feeds.feedburner.com/~f/DanchoDanchevOnSecurityAndNewMedia?i=JwIAWJ" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/DanchoDanchevOnSecurityAndNewMedia?a=RvHRWj"><img src="http://feeds.feedburner.com/~f/DanchoDanchevOnSecurityAndNewMedia?i=RvHRWj" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/DanchoDanchevOnSecurityAndNewMedia?a=ZamBlj"><img src="http://feeds.feedburner.com/~f/DanchoDanchevOnSecurityAndNewMedia?i=ZamBlj" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/DanchoDanchevOnSecurityAndNewMedia?a=YzU9yJ"><img src="http://feeds.feedburner.com/~f/DanchoDanchevOnSecurityAndNewMedia?i=YzU9yJ" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/DanchoDanchevOnSecurityAndNewMedia?a=2kBf4J"><img src="http://feeds.feedburner.com/~f/DanchoDanchevOnSecurityAndNewMedia?i=2kBf4J" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/DanchoDanchevOnSecurityAndNewMedia?a=LV5ldj"><img src="http://feeds.feedburner.com/~f/DanchoDanchevOnSecurityAndNewMedia?i=LV5ldj" border="0"></img></a>
</div><img src="http://feeds.feedburner.com/~r/DanchoDanchevOnSecurityAndNewMedia/~4/338894561" height="1" width="1"/>]]></content:encoded>
      <pubDate>Fri, 18 Jul 2008 01:48:38 +0000</pubDate>
      <category domain="http://securityratty.com/tag/comngg">comngg</category>
      <category domain="http://securityratty.com/tag/sql injections attacks">sql injections attacks</category>
      <category domain="http://securityratty.com/tag/sql injections">sql injections</category>
      <category domain="http://securityratty.com/tag/rungg">rungg</category>
      <category domain="http://securityratty.com/tag/sql">sql</category>
      <category domain="http://securityratty.com/tag/web sites">web sites</category>
      <category domain="http://securityratty.com/tag/web site defacement">web site defacement</category>
      <category domain="http://securityratty.com/tag/site">site</category>
      <category domain="http://securityratty.com/tag/sites">sites</category>
      <source url="http://feeds.feedburner.com/~r/DanchoDanchevOnSecurityAndNewMedia/~3/338894561/ayyildiz-turkish-hacking-group-vs.html">The Ayyildiz Turkish Hacking Group VS Everyone</source>
    </item>
    <item>
      <title><![CDATA[ICANN's Announcement Of Anti-Domain Tasting Measures To Registrars]]></title>
      <link>http://securityratty.com/article/913d52903ceaedff758808be4b11d5bf</link>
      <guid>http://securityratty.com/article/913d52903ceaedff758808be4b11d5bf</guid>
      <description><![CDATA[The recent new that ICANN had taken measures to combat Domain Tasting came out in blogs, such as this one , based on second-hand news. ICANN had sent an e-mail to registrars announcing the policy...]]></description>
      <content:encoded><![CDATA[The recent new that ICANN had taken measures to combat Domain Tasting came out in blogs, <a href="http://www.domainnamenews.com/miscellaneous/icann-board-resolution-kills-domain-tasting/1689">such as this one</a>, based on second-hand news. ICANN had sent an e-mail to registrars announcing the policy change. But there was confusion over exactly what the policy was; most people just assumed it followed the recommendations of the GNSO council from April.  The incomplete information caused some confused analysis such as <a href="http://www.cadna.org/en/newsroom/press-releases/icann-tasting-solution">this from CADNA (the Coalition Against Domain Name Abuse)</a>.

I asked ICANN and they sent me the actual e-mail that they sent out to registrars. It is published below. My analysis of it is in <a href="http://www.eweek.com/c/a/Security/Yes-Domain-Tasting-Will-End/">a column on eWEEK</a>.

<blockquote>
Dear Registrar,

This message is intended to explain how certain decisions that were made by the ICANN Board of Directors at its meeting in Paris last week may affect your registrar.

Specifically, the Board adopted GNSO recommendations on domain tasting that included both budget and non-budget provisions designed to restrict the applicability of the Add Grace Period (AGP).  Please note that this message is a summary of changes that affect registrars.  You should refer to the adopted budget document and adopted motions for further information.


Summary of Important Timing Issues

After several months of discussion and public comment on both the budget and the GNSO recommendations, the Board has approved the proposed budget containing a provision for collecting transaction fees above a threshold during the AGP.  Effective 1 July 2008, the registrar-level transaction fee will be collected on transactions, including names added on or after 1 July
2008 and deleted during the Add Grace Period above a certain minimum threshold.  Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if
offered)
will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater.  The budget assumes the transaction fee rate will remain at US ./send.20.

The second change prohibits registries from issuing refunds above a similar threshold for names registered and deleted during the AGP (although some registries have made plans to charge for such transactions independent of this motion).  The implementation timing of this change has not been set, but should be expected to take place over a period of some months.  ICANN staff will solicit public comments and post a registrar advisory prior to implementation of this aspect of the GNSO recommendation.


Budget - Registrar Fees Effective 1 July 2008

The Operating Plan and Budget details for 2008-2009 fiscal year can be found at:

http://www.icann.org/en/financials/proposed-opplan-budget-v3-fy09-25jun0
8-en.pdf

Relevant section from the approved budget:

* Registrar-Level Transaction Fees

In FY08 the per transaction-year rate was ./send.20 (or a 5 cent discount from the established ./send.25 rate).  The draft FY09 budget assumes that the ./send.20 rate will continue for registrar transaction fees.  As in past years, each transaction will be defined as one-year domain registration increment caused by a successful add renewal or transfer command.  FY09 revenue is estimated to be .4 million for registrar-level transaction fees.  Each "transaction"
will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater.  Therefore per-transaction fee will continue to be charged for each one-year increment of every transaction (e.g.  at a ./send.20 fee level, the fee for a three-year renewal will be US ./send.60), and registrars will continue to have the option to "defer" payment of the fees for the years beyond one for each transaction.  n

Note, as in previous years, ICANN can collect such fees directly from the registrars only if they are "expressly approved by registrars who account, in the aggregate, for payment of two-thirds of all registrar-level fees collected by ICANN." ICANN will shortly undertake the process of requesting such approval for the 2008-09 fiscal year.  While ICANN is grateful for consistent approval by registrars of fee levels in prior years, and is optimistic about such approval this year, if for some reason the necessary approval is not achieved, the fees will be collected by ICANN, as permitted under the registry agreements through the registries.  (Note that the amount of such fees varies by registry, but in no case exceeds US ./send.25.) Registries will then be able to collect those payments from registrars to the extent permitted under the relevant contracts.  It is expected that the same transaction increments (including AGP) will be covered, whether collected directly by ICANN or in! directly by the registries, so registrars should anticipate this liability under either scenario.


ICANN Board Resolution

Whereas, ICANN community stakeholders are increasingly concerned about domain tasting, which is the practice of using the add grace period (AGP) to register domain names in bulk in order to test their profitability.

Whereas, on 17 April 2008, the GNSO Council approved, by a Supermajority vote, a motion to prohibit any gTLD operator that has implemented an AGP from offering a refund for any domain name deleted during the AGP that exceeds 10% of its net new registrations in that month, or fifty domain names, whichever is greater.  <http://gnso.icann.org/meetings/minutes-gnso-17apr08.shtml>

Whereas, on 25 April 2008, the GNSO Council forwarded its formal "Report to the ICANN Board - Recommendation for Domain Tasting"
<http://gnso.icann.org/issues/domain-tasting/domain-tasting-board-report
-gnso-council-25apr08.pdf>,
which outlines the full text of the motion and the full context and procedural history of this proceeding.

Whereas, the Board is also considering the Proposed FY 09 Operating Plan and Budget <http://www.icann.org/financials/fiscal-30jun09.htm>, which includes (at the encouragement of the GNSO Council) a proposal similar to the GNSO policy recommendation to expand the applicability of the ICANN transaction fee in order to limit domain tasting.

Resolved (2008.06.26.06), the Board adopts the GNSO policy recommendation on domain tasting, and directs staff to implement the policy following appropriate comment and notice periods on the implementation documents.


Domain tasting motion approved by the GNSO Council 17 April 2008

<http://gnso.icann.org/issues/domain-tasting/domain-tasting-board-report
-gnso-council-25apr08.pdf>

Whereas, the GNSO Council has discussed the Issues Report on Domain Tasting and the Final Outcomes Report of the ad hoc group on Domain Tasting;

Whereas, the GNSO Council resolved on 31 October 2007 to launch a PDP on Domain Tasting;

Whereas, the GNSO Council authorized on 17 January 2008 the formation of a small design team to develop a plan for the deliberations on the Domain Tasting PDP (the "Design Team"), the principal volunteers to which had been members of the Ad Hoc Group on Domain Tasting and were well-informed of both the Final Outcomes Report of the Ad Hoc Group on Domain Tasting and the GNSO Initial Report on Domain Tasting (collectively with the Issues Report, the "Reports on Domain Tasting");

Whereas, the GNSO Council has received the Draft Final Report on Domain Tasting;

Whereas, PIR, the .org registry operator, has amended its Registry Agreement to charge an Excess Deletion Fee; and both NeuStar, the .biz registry operator, and Afilias, the .info registry operator, are seeking amendments to their respective Registry Agreements to modify the existing AGP;

The GNSO Council recommends to the ICANN Board of Directors that:

1.  The applicability of the Add Grace Period shall be restricted for any gTLD which has implemented an AGP ("Applicable gTLD Operator").
Specifically, for each Applicable gTLD Operator:

  a.  During any given month, an Applicable gTLD Operator may not offer any
  refund to a registrar for any domain names deleted during the AGP that
  exceed (i) 10% of that registrar's net new registrations in that month
  (defined as total new registrations less domains deleted during AGP), or
  (ii) fifty (50) domain names, whichever is greater.

  b.  A Registrar may seek an exemption from the application of such
  restriction in a specific month, upon the documented showing of
  extraordinary circumstances.  For any Registrar requesting such an
  exemption, the Registrar must confirm in writing to the Registry Operator
  how, at the time the names were deleted, these extraordinary circumstances
  were not known, reasonably could not have been known, and were outside of
  the Registrar's control.  Acceptance of any exemption will be at the sole
  reasonable discretion of the Registry Operator, however "extraordinary
  circumstances" which reoccur regularly will not be deemed extraordinary.

  c.  In addition to all other reporting requirements to ICANN, each
  Applicable gTLD Operator shall identify each Registrar that has sought an
  exemption, along with a brief descriptive identification of the type of
  extraordinary circumstance and the action (if any) that was taken by the
  Applicable gTLD Operator.

2.  Implementation and execution of these recommendations shall be monitored by the GNSO.  Specifically;

  a.  ICANN Staff shall analyze and report to the GNSO at six month intervals
  for two years after implementation, until such time as the GNSO resolves
  otherwise, with the goal of determining;

    i.  How effectively and to what extent the policies have been implemented
    and followed by Registries and Registrars, and

    ii.  Whether or not modifications to these policies should be considered
    by the GNSO as a result of the experiences gained during the
    implementation and monitoring stages,

  b.  The purpose of these monitoring and reporting requirements are to allow
  the GNSO to determine when, if ever, these recommendations and any ensuing
  policy require additional clarification or attention based on the results
  of the reports prepared by ICANN Staff.

</blockquote>

<br style="clear: both;"/>
  <img alt="" style="border: 0; height:1px; width:1px;" border="0" src="http://www.pheedo.com/img.phdo?i=152f487f101abbcdd9c900fc3eb46268" height="1" width="1"/>
<img src="http://www.pheedo.com/feeds/tracker.php?i=152f487f101abbcdd9c900fc3eb46268" style="display: none;" border="0" height="1" width="1" alt=""/><img src="http://feeds.ziffdavisenterprise.com/~r/RSS/cheap_hack/~4/330098895" height="1" width="1"/>]]></content:encoded>
      <pubDate>Tue, 08 Jul 2008 11:42:32 +0000</pubDate>
      <category domain="http://securityratty.com/tag/icann">icann</category>
      <category domain="http://securityratty.com/tag/directly">directly</category>
      <category domain="http://securityratty.com/tag/fees directly">fees directly</category>
      <category domain="http://securityratty.com/tag/fees">fees</category>
      <category domain="http://securityratty.com/tag/registrar fees effective">registrar fees effective</category>
      <category domain="http://securityratty.com/tag/effective">effective</category>
      <category domain="http://securityratty.com/tag/registrar-level fees">registrar-level fees</category>
      <category domain="http://securityratty.com/tag/fee">fee</category>
      <category domain="http://securityratty.com/tag/per-transaction fee">per-transaction fee</category>
      <source url="http://feeds.ziffdavisenterprise.com/~r/RSS/cheap_hack/~3/330098895/ch_icanns_announcement_of_antidomain_tasting_measures_to_registrars.html">ICANN's Announcement Of Anti-Domain Tasting Measures To Registrars</source>
    </item>
    <item>
      <title><![CDATA[ICANN's Announcement Of Anti-Domain Tasting Measures To Registrars]]></title>
      <link>http://securityratty.com/article/1438af7a2605c2bbe5326444d5bd9d27</link>
      <guid>http://securityratty.com/article/1438af7a2605c2bbe5326444d5bd9d27</guid>
      <description><![CDATA[The recent new that ICANN had taken measures to combat Domain Tasting came out in blogs, such as this one , based on second-hand news. ICANN had sent an e-mail to registrars announcing the policy...]]></description>
      <content:encoded><![CDATA[The recent new that ICANN had taken measures to combat Domain Tasting came out in blogs, <a href="http://www.domainnamenews.com/miscellaneous/icann-board-resolution-kills-domain-tasting/1689">such as this one</a>, based on second-hand news. ICANN had sent an e-mail to registrars announcing the policy change. But there was confusion over exactly what the policy was; most people just assumed it followed the recommendations of the GNSO council from April.  The incomplete information caused some confused analysis such as <a href="http://www.cadna.org/en/newsroom/press-releases/icann-tasting-solution">this from CADNA (the Coalition Against Domain Name Abuse)</a>.

I asked ICANN and they sent me the actual e-mail that they sent out to registrars. It is published below. My analysis of it is in <a href="http://www.eweek.com/c/a/Security/Yes-Domain-Tasting-Will-End/">a column on eWEEK</a>.

<blockquote>
Dear Registrar,

This message is intended to explain how certain decisions that were made by the ICANN Board of Directors at its meeting in Paris last week may affect your registrar.

Specifically, the Board adopted GNSO recommendations on domain tasting that included both budget and non-budget provisions designed to restrict the applicability of the Add Grace Period (AGP).  Please note that this message is a summary of changes that affect registrars.  You should refer to the adopted budget document and adopted motions for further information.


Summary of Important Timing Issues

After several months of discussion and public comment on both the budget and the GNSO recommendations, the Board has approved the proposed budget containing a provision for collecting transaction fees above a threshold during the AGP.  Effective 1 July 2008, the registrar-level transaction fee will be collected on transactions, including names added on or after 1 July
2008 and deleted during the Add Grace Period above a certain minimum threshold.  Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if
offered)
will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater.  The budget assumes the transaction fee rate will remain at US ./send.20.

The second change prohibits registries from issuing refunds above a similar threshold for names registered and deleted during the AGP (although some registries have made plans to charge for such transactions independent of this motion).  The implementation timing of this change has not been set, but should be expected to take place over a period of some months.  ICANN staff will solicit public comments and post a registrar advisory prior to implementation of this aspect of the GNSO recommendation.


Budget - Registrar Fees Effective 1 July 2008

The Operating Plan and Budget details for 2008-2009 fiscal year can be found at:

http://www.icann.org/en/financials/proposed-opplan-budget-v3-fy09-25jun0
8-en.pdf

Relevant section from the approved budget:

* Registrar-Level Transaction Fees

In FY08 the per transaction-year rate was ./send.20 (or a 5 cent discount from the established ./send.25 rate).  The draft FY09 budget assumes that the ./send.20 rate will continue for registrar transaction fees.  As in past years, each transaction will be defined as one-year domain registration increment caused by a successful add renewal or transfer command.  FY09 revenue is estimated to be .4 million for registrar-level transaction fees.  Each "transaction"
will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater.  Therefore per-transaction fee will continue to be charged for each one-year increment of every transaction (e.g.  at a ./send.20 fee level, the fee for a three-year renewal will be US ./send.60), and registrars will continue to have the option to "defer" payment of the fees for the years beyond one for each transaction.  n

Note, as in previous years, ICANN can collect such fees directly from the registrars only if they are "expressly approved by registrars who account, in the aggregate, for payment of two-thirds of all registrar-level fees collected by ICANN." ICANN will shortly undertake the process of requesting such approval for the 2008-09 fiscal year.  While ICANN is grateful for consistent approval by registrars of fee levels in prior years, and is optimistic about such approval this year, if for some reason the necessary approval is not achieved, the fees will be collected by ICANN, as permitted under the registry agreements through the registries.  (Note that the amount of such fees varies by registry, but in no case exceeds US ./send.25.) Registries will then be able to collect those payments from registrars to the extent permitted under the relevant contracts.  It is expected that the same transaction increments (including AGP) will be covered, whether collected directly by ICANN or in! directly by the registries, so registrars should anticipate this liability under either scenario.


ICANN Board Resolution

Whereas, ICANN community stakeholders are increasingly concerned about domain tasting, which is the practice of using the add grace period (AGP) to register domain names in bulk in order to test their profitability.

Whereas, on 17 April 2008, the GNSO Council approved, by a Supermajority vote, a motion to prohibit any gTLD operator that has implemented an AGP from offering a refund for any domain name deleted during the AGP that exceeds 10% of its net new registrations in that month, or fifty domain names, whichever is greater.  <http://gnso.icann.org/meetings/minutes-gnso-17apr08.shtml>

Whereas, on 25 April 2008, the GNSO Council forwarded its formal "Report to the ICANN Board - Recommendation for Domain Tasting"
<http://gnso.icann.org/issues/domain-tasting/domain-tasting-board-report
-gnso-council-25apr08.pdf>,
which outlines the full text of the motion and the full context and procedural history of this proceeding.

Whereas, the Board is also considering the Proposed FY 09 Operating Plan and Budget <http://www.icann.org/financials/fiscal-30jun09.htm>, which includes (at the encouragement of the GNSO Council) a proposal similar to the GNSO policy recommendation to expand the applicability of the ICANN transaction fee in order to limit domain tasting.

Resolved (2008.06.26.06), the Board adopts the GNSO policy recommendation on domain tasting, and directs staff to implement the policy following appropriate comment and notice periods on the implementation documents.


Domain tasting motion approved by the GNSO Council 17 April 2008

<http://gnso.icann.org/issues/domain-tasting/domain-tasting-board-report
-gnso-council-25apr08.pdf>

Whereas, the GNSO Council has discussed the Issues Report on Domain Tasting and the Final Outcomes Report of the ad hoc group on Domain Tasting;

Whereas, the GNSO Council resolved on 31 October 2007 to launch a PDP on Domain Tasting;

Whereas, the GNSO Council authorized on 17 January 2008 the formation of a small design team to develop a plan for the deliberations on the Domain Tasting PDP (the "Design Team"), the principal volunteers to which had been members of the Ad Hoc Group on Domain Tasting and were well-informed of both the Final Outcomes Report of the Ad Hoc Group on Domain Tasting and the GNSO Initial Report on Domain Tasting (collectively with the Issues Report, the "Reports on Domain Tasting");

Whereas, the GNSO Council has received the Draft Final Report on Domain Tasting;

Whereas, PIR, the .org registry operator, has amended its Registry Agreement to charge an Excess Deletion Fee; and both NeuStar, the .biz registry operator, and Afilias, the .info registry operator, are seeking amendments to their respective Registry Agreements to modify the existing AGP;

The GNSO Council recommends to the ICANN Board of Directors that:

1.  The applicability of the Add Grace Period shall be restricted for any gTLD which has implemented an AGP ("Applicable gTLD Operator").
Specifically, for each Applicable gTLD Operator:

  a.  During any given month, an Applicable gTLD Operator may not offer any
  refund to a registrar for any domain names deleted during the AGP that
  exceed (i) 10% of that registrar's net new registrations in that month
  (defined as total new registrations less domains deleted during AGP), or
  (ii) fifty (50) domain names, whichever is greater.

  b.  A Registrar may seek an exemption from the application of such
  restriction in a specific month, upon the documented showing of
  extraordinary circumstances.  For any Registrar requesting such an
  exemption, the Registrar must confirm in writing to the Registry Operator
  how, at the time the names were deleted, these extraordinary circumstances
  were not known, reasonably could not have been known, and were outside of
  the Registrar's control.  Acceptance of any exemption will be at the sole
  reasonable discretion of the Registry Operator, however "extraordinary
  circumstances" which reoccur regularly will not be deemed extraordinary.

  c.  In addition to all other reporting requirements to ICANN, each
  Applicable gTLD Operator shall identify each Registrar that has sought an
  exemption, along with a brief descriptive identification of the type of
  extraordinary circumstance and the action (if any) that was taken by the
  Applicable gTLD Operator.

2.  Implementation and execution of these recommendations shall be monitored by the GNSO.  Specifically;

  a.  ICANN Staff shall analyze and report to the GNSO at six month intervals
  for two years after implementation, until such time as the GNSO resolves
  otherwise, with the goal of determining;

    i.  How effectively and to what extent the policies have been implemented
    and followed by Registries and Registrars, and

    ii.  Whether or not modifications to these policies should be considered
    by the GNSO as a result of the experiences gained during the
    implementation and monitoring stages,

  b.  The purpose of these monitoring and reporting requirements are to allow
  the GNSO to determine when, if ever, these recommendations and any ensuing
  policy require additional clarification or attention based on the results
  of the reports prepared by ICANN Staff.

</blockquote>

<br style="clear: both;"/>
      <a href="http://www.pheedo.com/click.phdo?s=8eea0eb864e902bc67c9b814b1af0256"><img alt="" style="border: 0;" border="0" src="http://www.pheedo.com/img.phdo?s=8eea0eb864e902bc67c9b814b1af0256"/></a>
  <img src="http://www.pheedo.com/feeds/tracker.php?i=8eea0eb864e902bc67c9b814b1af0256" style="display: none;" border="0" height="1" width="1" alt=""/><img src="http://feeds.ziffdavisenterprise.com/~r/RSS/cheap_hack/~4/338277687" height="1" width="1"/>]]></content:encoded>
      <pubDate>Tue, 08 Jul 2008 11:42:32 +0000</pubDate>
      <category domain="http://securityratty.com/tag/icann">icann</category>
      <category domain="http://securityratty.com/tag/directly">directly</category>
      <category domain="http://securityratty.com/tag/fees directly">fees directly</category>
      <category domain="http://securityratty.com/tag/fees">fees</category>
      <category domain="http://securityratty.com/tag/registrar fees effective">registrar fees effective</category>
      <category domain="http://securityratty.com/tag/effective">effective</category>
      <category domain="http://securityratty.com/tag/registrar-level fees">registrar-level fees</category>
      <category domain="http://securityratty.com/tag/fee">fee</category>
      <category domain="http://securityratty.com/tag/per-transaction fee">per-transaction fee</category>
      <source url="http://feeds.ziffdavisenterprise.com/~r/RSS/cheap_hack/~3/338277687/ch_icanns_announcement_of_antidomain_tasting_measures_to_registrars.html">ICANN's Announcement Of Anti-Domain Tasting Measures To Registrars</source>
    </item>
    <item>
      <title><![CDATA[ICANN's Announcement Of Anti-Domain Tasting Measures To Registrars]]></title>
      <link>http://securityratty.com/article/266456c2c42bc5e4cf836f3ca19af1c2</link>
      <guid>http://securityratty.com/article/266456c2c42bc5e4cf836f3ca19af1c2</guid>
      <description><![CDATA[The recent new that ICANN had taken measures to combat Domain Tasting came out in blogs, such as this one , based on second-hand news. ICANN had sent an e-mail to registrars announcing the policy...]]></description>
      <content:encoded><![CDATA[The recent new that ICANN had taken measures to combat Domain Tasting came out in blogs, <a href="http://www.domainnamenews.com/miscellaneous/icann-board-resolution-kills-domain-tasting/1689">such as this one</a>, based on second-hand news. ICANN had sent an e-mail to registrars announcing the policy change. But there was confusion over exactly what the policy was; most people just assumed it followed the recommendations of the GNSO council from April.  The incomplete information caused some confused analysis such as <a href="http://www.cadna.org/en/newsroom/press-releases/icann-tasting-solution">this from CADNA (the Coalition Against Domain Name Abuse)</a>.

I asked ICANN and they sent me the actual e-mail that they sent out to registrars. It is published below. My analysis of it is in <a href="http://www.eweek.com/c/a/Security/Yes-Domain-Tasting-Will-End/">a column on eWEEK</a>.

<blockquote>
Dear Registrar,

This message is intended to explain how certain decisions that were made by the ICANN Board of Directors at its meeting in Paris last week may affect your registrar.

Specifically, the Board adopted GNSO recommendations on domain tasting that included both budget and non-budget provisions designed to restrict the applicability of the Add Grace Period (AGP).  Please note that this message is a summary of changes that affect registrars.  You should refer to the adopted budget document and adopted motions for further information.


Summary of Important Timing Issues

After several months of discussion and public comment on both the budget and the GNSO recommendations, the Board has approved the proposed budget containing a provision for collecting transaction fees above a threshold during the AGP.  Effective 1 July 2008, the registrar-level transaction fee will be collected on transactions, including names added on or after 1 July
2008 and deleted during the Add Grace Period above a certain minimum threshold.  Each "transaction" will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if
offered)
will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater.  The budget assumes the transaction fee rate will remain at US ./send.20.

The second change prohibits registries from issuing refunds above a similar threshold for names registered and deleted during the AGP (although some registries have made plans to charge for such transactions independent of this motion).  The implementation timing of this change has not been set, but should be expected to take place over a period of some months.  ICANN staff will solicit public comments and post a registrar advisory prior to implementation of this aspect of the GNSO recommendation.


Budget - Registrar Fees Effective 1 July 2008

The Operating Plan and Budget details for 2008-2009 fiscal year can be found at:

http://www.icann.org/en/financials/proposed-opplan-budget-v3-fy09-25jun0
8-en.pdf

Relevant section from the approved budget:

* Registrar-Level Transaction Fees

In FY08 the per transaction-year rate was ./send.20 (or a 5 cent discount from the established ./send.25 rate).  The draft FY09 budget assumes that the ./send.20 rate will continue for registrar transaction fees.  As in past years, each transaction will be defined as one-year domain registration increment caused by a successful add renewal or transfer command.  FY09 revenue is estimated to be .4 million for registrar-level transaction fees.  Each "transaction"
will continue to be defined as a one-year domain registration increment caused by a successful add, renewal or transfer command, but this year any domain names deleted during the AGP (if offered) will be included as transactions if they exceed the maximum of (i) 10% of that registrar's net new registrations in that month (defined as total new registrations less domains deleted during AGP), or (ii) fifty (50) domain names, whichever is greater.  Therefore per-transaction fee will continue to be charged for each one-year increment of every transaction (e.g.  at a ./send.20 fee level, the fee for a three-year renewal will be US ./send.60), and registrars will continue to have the option to "defer" payment of the fees for the years beyond one for each transaction.  n

Note, as in previous years, ICANN can collect such fees directly from the registrars only if they are "expressly approved by registrars who account, in the aggregate, for payment of two-thirds of all registrar-level fees collected by ICANN." ICANN will shortly undertake the process of requesting such approval for the 2008-09 fiscal year.  While ICANN is grateful for consistent approval by registrars of fee levels in prior years, and is optimistic about such approval this year, if for some reason the necessary approval is not achieved, the fees will be collected by ICANN, as permitted under the registry agreements through the registries.  (Note that the amount of such fees varies by registry, but in no case exceeds US ./send.25.) Registries will then be able to collect those payments from registrars to the extent permitted under the relevant contracts.  It is expected that the same transaction increments (including AGP) will be covered, whether collected directly by ICANN or in! directly by the registries, so registrars should anticipate this liability under either scenario.


ICANN Board Resolution

Whereas, ICANN community stakeholders are increasingly concerned about domain tasting, which is the practice of using the add grace period (AGP) to register domain names in bulk in order to test their profitability.

Whereas, on 17 April 2008, the GNSO Council approved, by a Supermajority vote, a motion to prohibit any gTLD operator that has implemented an AGP from offering a refund for any domain name deleted during the AGP that exceeds 10% of its net new registrations in that month, or fifty domain names, whichever is greater.  <http://gnso.icann.org/meetings/minutes-gnso-17apr08.shtml>

Whereas, on 25 April 2008, the GNSO Council forwarded its formal "Report to the ICANN Board - Recommendation for Domain Tasting"
<http://gnso.icann.org/issues/domain-tasting/domain-tasting-board-report
-gnso-council-25apr08.pdf>,
which outlines the full text of the motion and the full context and procedural history of this proceeding.

Whereas, the Board is also considering the Proposed FY 09 Operating Plan and Budget <http://www.icann.org/financials/fiscal-30jun09.htm>, which includes (at the encouragement of the GNSO Council) a proposal similar to the GNSO policy recommendation to expand the applicability of the ICANN transaction fee in order to limit domain tasting.

Resolved (2008.06.26.06), the Board adopts the GNSO policy recommendation on domain tasting, and directs staff to implement the policy following appropriate comment and notice periods on the implementation documents.


Domain tasting motion approved by the GNSO Council 17 April 2008

<http://gnso.icann.org/issues/domain-tasting/domain-tasting-board-report
-gnso-council-25apr08.pdf>

Whereas, the GNSO Council has discussed the Issues Report on Domain Tasting and the Final Outcomes Report of the ad hoc group on Domain Tasting;

Whereas, the GNSO Council resolved on 31 October 2007 to launch a PDP on Domain Tasting;

Whereas, the GNSO Council authorized on 17 January 2008 the formation of a small design team to develop a plan for the deliberations on the Domain Tasting PDP (the "Design Team"), the principal volunteers to which had been members of the Ad Hoc Group on Domain Tasting and were well-informed of both the Final Outcomes Report of the Ad Hoc Group on Domain Tasting and the GNSO Initial Report on Domain Tasting (collectively with the Issues Report, the "Reports on Domain Tasting");

Whereas, the GNSO Council has received the Draft Final Report on Domain Tasting;

Whereas, PIR, the .org registry operator, has amended its Registry Agreement to charge an Excess Deletion Fee; and both NeuStar, the .biz registry operator, and Afilias, the .info registry operator, are seeking amendments to their respective Registry Agreements to modify the existing AGP;

The GNSO Council recommends to the ICANN Board of Directors that:

1.  The applicability of the Add Grace Period shall be restricted for any gTLD which has implemented an AGP ("Applicable gTLD Operator").
Specifically, for each Applicable gTLD Operator:

  a.  During any given month, an Applicable gTLD Operator may not offer any
  refund to a registrar for any domain names deleted during the AGP that
  exceed (i) 10% of that registrar's net new registrations in that month
  (defined as total new registrations less domains deleted during AGP), or
  (ii) fifty (50) domain names, whichever is greater.

  b.  A Registrar may seek an exemption from the application of such
  restriction in a specific month, upon the documented showing of
  extraordinary circumstances.  For any Registrar requesting such an
  exemption, the Registrar must confirm in writing to the Registry Operator
  how, at the time the names were deleted, these extraordinary circumstances
  were not known, reasonably could not have been known, and were outside of
  the Registrar's control.  Acceptance of any exemption will be at the sole
  reasonable discretion of the Registry Operator, however "extraordinary
  circumstances" which reoccur regularly will not be deemed extraordinary.

  c.  In addition to all other reporting requirements to ICANN, each
  Applicable gTLD Operator shall identify each Registrar that has sought an
  exemption, along with a brief descriptive identification of the type of
  extraordinary circumstance and the action (if any) that was taken by the
  Applicable gTLD Operator.

2.  Implementation and execution of these recommendations shall be monitored by the GNSO.  Specifically;

  a.  ICANN Staff shall analyze and report to the GNSO at six month intervals
  for two years after implementation, until such time as the GNSO resolves
  otherwise, with the goal of determining;

    i.  How effectively and to what extent the policies have been implemented
    and followed by Registries and Registrars, and

    ii.  Whether or not modifications to these policies should be considered
    by the GNSO as a result of the experiences gained during the
    implementation and monitoring stages,

  b.  The purpose of these monitoring and reporting requirements are to allow
  the GNSO to determine when, if ever, these recommendations and any ensuing
  policy require additional clarification or attention based on the results
  of the reports prepared by ICANN Staff.

</blockquote><img src="http://feedproxy.google.com/~r/RSS/cheap_hack/~4/xJKws7q3qKE" height="1" width="1"/>]]></content:encoded>
      <pubDate>Tue, 08 Jul 2008 11:42:32 +0000</pubDate>
      <category domain="http://securityratty.com/tag/icann">icann</category>
      <category domain="http://securityratty.com/tag/directly">directly</category>
      <category domain="http://securityratty.com/tag/fees directly">fees directly</category>
      <category domain="http://securityratty.com/tag/fees">fees</category>
      <category domain="http://securityratty.com/tag/registrar fees effective">registrar fees effective</category>
      <category domain="http://securityratty.com/tag/effective">effective</category>
      <category domain="http://securityratty.com/tag/registrar-level fees">registrar-level fees</category>
      <category domain="http://securityratty.com/tag/fee">fee</category>
      <category domain="http://securityratty.com/tag/per-transaction fee">per-transaction fee</category>
      <source url="http://feeds.ziffdavisenterprise.com/~r/RSS/cheap_hack/~3/xJKws7q3qKE/ch_icanns_announcement_of_antidomain_tasting_measures_to_registrars.html">ICANN's Announcement Of Anti-Domain Tasting Measures To Registrars</source>
    </item>
    <item>
      <title><![CDATA[Managers Admit Theyd Exploit Private Data]]></title>
      <link>http://securityratty.com/article/e117f58d8771a76eb58c7e75d5454c27</link>
      <guid>http://securityratty.com/article/e117f58d8771a76eb58c7e75d5454c27</guid>
      <description><![CDATA[Anything to make a buck for some folks. A study commissioned by the folks at StrongMail Systems found that some marketing managers would be willing to dish out private customer data in order to bump...]]></description>
      <content:encoded><![CDATA[<p>Anything to make a buck for some folks. A study commissioned by the folks at StrongMail Systems found that some marketing managers would be willing to dish out private customer data in order to bump up sales.</p>
<p>From the Financial Times:</p>
<blockquote><p>The research – which was commissioned by StrongMail Systems, an e-mail security company – comes after the privacy watchdog warned of receiving an alarming number of reports of data security breaches in the private sector.</p>
<p>The survey, which covered 900 data security and marketing professionals, found that 7 per cent of marketing managers would disclose customers’ sexual orientation, 14 per cent their involvement in political activism, and 19 per cent their credit card details.</p>
<p>Some managers said they would also disclose data about ethnicity and religious beliefs. </p>
<p>The research found that marketing managers never reported data losses or thefts to customers in 90 per cent of cases, as they thought they were not required to do so.</p></blockquote>
<p>So, are you keeping tabs on your marketing folks?<br />
 <img src='http://www.liquidmatrix.org/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /><br />
<a href="http://www.ft.com/cms/s/0/14ce2cc6-40a1-11dd-bd48-0000779fd2ac.html?nclick_check=1">Article Link</a></p>

<p><a href="http://feeds.feedburner.com/~a/Liquidmatrix?a=j0OPyK"><img src="http://feeds.feedburner.com/~a/Liquidmatrix?i=j0OPyK" border="0"></img></a></p><div class="feedflare">
<a href="http://feeds.feedburner.com/~f/Liquidmatrix?a=IurgJI"><img src="http://feeds.feedburner.com/~f/Liquidmatrix?i=IurgJI" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/Liquidmatrix?a=WzWGii"><img src="http://feeds.feedburner.com/~f/Liquidmatrix?i=WzWGii" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/Liquidmatrix?a=JIWSWi"><img src="http://feeds.feedburner.com/~f/Liquidmatrix?i=JIWSWi" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/Liquidmatrix?a=i0wYoi"><img src="http://feeds.feedburner.com/~f/Liquidmatrix?i=i0wYoi" border="0"></img></a> <a href="http://feeds.feedburner.com/~f/Liquidmatrix?a=zvTWii"><img src="http://feeds.feedburner.com/~f/Liquidmatrix?i=zvTWii" border="0"></img></a>
</div><img src="http://feeds.feedburner.com/~r/Liquidmatrix/~4/318003190" height="1" width="1"/>]]></content:encoded>
      <pubDate>Mon, 23 Jun 2008 06:21:46 +0000</pubDate>
      <category domain="http://securityratty.com/tag/managers">managers</category>
      <category domain="http://securityratty.com/tag/data security">data security</category>
      <category domain="http://securityratty.com/tag/data security breaches">data security breaches</category>
      <category domain="http://securityratty.com/tag/strongmail systems">strongmail systems</category>
      <category domain="http://securityratty.com/tag/cent">cent</category>
      <category domain="http://securityratty.com/tag/e-mail security company">e-mail security company</category>
      <category domain="http://securityratty.com/tag/credit card details">credit card details</category>
      <category domain="http://securityratty.com/tag/folks">folks</category>
      <category domain="http://securityratty.com/tag/privacy watchdog">privacy watchdog</category>
      <source url="http://feeds.feedburner.com/~r/Liquidmatrix/~3/318003190/">Managers Admit Theyd Exploit Private Data</source>
    </item>
    <item>
      <title><![CDATA[A coward exposes personal information on 40% of Chileans]]></title>
      <link>http://securityratty.com/article/a890175464a0c736ed03e75a745166d8</link>
      <guid>http://securityratty.com/article/a890175464a0c736ed03e75a745166d8</guid>
      <description><![CDATA[Technorati Tag: Security Breach

Date Reported
5/10/08

Organization
Chilean Government

Contractor/Consultant/Branch
None

Victims
Chilean residents

Number Affected
6,000,000

Types of Data
names,...]]></description>
      <content:encoded><![CDATA[Technorati Tag: <a href="http://technorati.com/tag/security+breach" rel="tag">Security Breach</a><br><br>
<img src="http://breachblog.com/images/95781-88451/chile.jpg" align="right" height="70" width="72"><font size="2"><span style="font-weight: bold;">Date Reported: </span><br>5/10/08<br><br><span style="font-weight: bold;">Organization: </span><br><a href="http://www.chileangovernment.cl/">Chilean Government</a> <br><br><span style="font-weight: bold;">Contractor/Consultant/Branch:</span><br>None<br><br><span style="font-weight: bold;">Victims:</span><br>Chilean residents<br><br><span style="font-weight: bold;">Number Affected:</span><br>~6,000,000<br><br><span style="font-weight: bold;">Types of Data:</span><br>"names, addresses, telephone numbers and taxpayer identification numbers"<br><br><span style="font-weight: bold;">Breach Description:</span><br>"An anonymous hacker has posted personal data about 6 million Chilean residents on the Internet, highlighting wider privacy problems in the country.&nbsp; The data was posted early Saturday morning on Fayerwayer.com, a popular Chilean technology blog."<br><br><span style="font-weight: bold;">Reference URL:</span><br><a href="http://www.fayerwayer.com/2008/05/alerta-se-filtran-datos-personales-de-6-millones-de-chilenos-via-internet/">Fayerwayer.com Alert</a><br><a href="http://abcnews.go.com/Technology/GadgetGuide/story?id=4841870">ABC News</a> <br><a href="http://www.thetechherald.com/article.php/200820/963/Anonymous-Coward-posts-information-to-prove-point">The Tech Herald</a> <br><a href="http://www.iht.com/articles/ap/2008/05/11/america/LA-GEN-Chile-Data-Leaked.php">International Herald Tribune</a> <br><a href="http://www.vnunet.com/vnunet/news/2216464/six-million-chileans-details-online">vnunet.com</a> <br><br><span style="font-weight: bold;">Report Credit:</span><br>JI Stark, Fayerwayer.com<br><br><span style="font-weight: bold;">Response:</span><br>From the online sources cited above:<br><br><img src="http://images.quickblogcast.com/95781-88451/alerta.jpg" border="0" width="500"><br><br>ORIGINAL POST TEXT GOOGLE TRANSLATED<br>Something really horrible has just come to our comments.&nbsp; Moments after writing about the purchase of Inquisitor by Yahoo, an anonymous comment left three links to download two files that contain databases in CSV of public and private institutions where there is sensitive information of millions of Chileans, like RUN - Role purely national identification number Chilean -, socio-economic data, electoral, educational, addresses, and telephone numbers individuals, among others.<br><br>We urge that these files if they see us please not download or disseminated by any electronic means.<br><br>It is extremely dangerous what can happen - and what can happen to you, as the only disseminate is an offence punishable by law - in the case that such senstive data failling to the hands unscrupulous.&nbsp; It seriously.<br><br>Update 02:46 AM (GMT -4): The team of FireWire is doing everything in its power at this time to cooperate and ensure that this situation is resolved as soon as possible. <br><br>Update 03:25 AM (GMT -4): The topics in our forums with links to the files were deleted. The FireWire forums require registration, so that data - although most likely false, including IP's mask - will be put in the hands of the authorities.<br><br>Update 04:45 PM (GMT -4): The Cybercrime Brigade of the Investigative Police of Chile already contacted us, told us about the progress of the investigation that is already under way and we extend all cooperation that is within our grasp. <br><br>END OF ORIGINAL POST TEXT<br><br>A hacker has obtained the personal details of around six million Chileans from government and military servers and posted them on a technology blog.<br><span style="font-style: italic;">[Evan] "Anonymous Coward" posted the information in the comments of the </span><a style="font-style: italic;" href="http://www.fayerwayer.com/2008/05/yahoo-se-hace-de-inquisitor/">purchase of Inquisitor by Yahoo </a><span style="font-style: italic;">posting on <a href="http://www.fayerwayer.com.</span><a">www.fayerwayer.com.</span><a</a> href="http://www.fayerwayer.com.%3C/span%3E%3Cbr%3E%3Cbr%3EThe"><br><br></a>The hacker, who calls himself "Anonymous Coward," posted three compressed files of data that included names, addresses, telephone numbers and taxpayer identification numbers for Chilean residents, said Leo Prieto, Fayerwayer.com's director.<br><br>The data was taken early Friday from servers at the Education Ministry, the electoral service and the military<br><br>it was first reported to police early Saturday by Leo Prieto, the administrator of a local technology-oriented Internet site who discovered links to the information online.<br><br>Among the data was a list of students who receive preferential public transportation rates, including one of President Michelle Bachelet's two daughters<br><br>Despite the information's prompt removal from the Internet, some people may have downloaded it "and it may still be around on the Internet,"<br><br>over the following days the files started popping up on other sites including Google's Blogger<br><span style="font-style: italic;">[Evan] You can't un-disclose confidential information.&nbsp; Once the confidentiality of information has been compromised, it is always going to be compromised.</span><br><br>Reports claim that the hacker performed the stunt to highlight poor levels of data protection in Chile.<br><span style="font-style: italic;">[Evan] What idiot would pull such a stunt and claim such a ridiculous justification?</span><br><br>In a note accompanying the files, Anonymous Coward said he posted the databases to draw attention to the poor data protection measures in the country<br><span style="font-style: italic;">[Evan] This is the worst way to draw attention to poor data protection.&nbsp; What "Anonymous Coward" did was create 6,000,000+ enemies and put his/her very well being at risk.&nbsp; He/she caused an extraordinary amount of harm to almost 40% of Chile's population and made a complete ass out of him/herself.</span><br><br>El Mercurio reported that it had access to some of the data, including a file in which the hacker said he intended "to demonstrate how poorly protected the data in Chile is, and how nobody works to protect it."<br><br>The files include tips on what to do with the data and how best to access it.<br><br>"Chile may be on the other side of the world, but the scale of this data breach should not be ignored," said Graham Cluley, senior technology consultant at security firm Sophos.<br><br>"No matter how moral or ethical the motive, this prank was irresponsible and has left almost 40 per cent of Chile's population at risk of identity theft."<br><br>Cluley added that all organisations around the world should see this as a wake-up call and ensure that all personal and sensitive information is stored securely.<br><span style="font-style: italic;">[Evan] You would think that the 94,000,000 credit card numbers stolen from TJX, or the 26,500,000 Social Security numbers on the stolen Veterans Affairs laptop, or the 25,000,000 personal records lost on CDs from HM Customs and Revenue would wake organizations up.&nbsp; There is still this illogical thought in organizations that "this will never happen to us".&nbsp; It <span style="font-weight: bold;">DOES </span>and <span style="font-weight: bold;">IT WILL</span>.&nbsp; I'm not even going to get into information security personnel that lack skill and have business leaders fooled into thinking that they are doing the right thing(s).</span><br><br>"Whether or not the loss results in a fine is almost irrelevant; the consequences of falling victim to such an attack can mean irreversible damage to reputation and customer confidence."<br><span style="font-style: italic;">[Evan] I couldn't agree with Mr. Cluley any more.&nbsp; This is a guy that "gets it".</span><br><br><span style="font-weight: bold;">Commentary:</span><br>Unbelievable.&nbsp; The evil in some people.&nbsp; So let's say that "Anonymous Coward" is caught (I think chances are better that 50/50).&nbsp; Now what?&nbsp; How do you punish someone whose actions put 6,000,000 people at risk of losing their identities.&nbsp; These people will live with some level of fear for a very long time.&nbsp; Punishment will be severe, but how severe is enough?&nbsp; This will be an interesting story to follow.<br><br>Let's not lose sight of another issue with this breach.&nbsp; What is the Chilean government doing to protect confidential information and what does it intend to do in response to this breach?&nbsp; Obviously the government needs to secure information better, but how will they respond to 40% of their residents being exposed to fraud and all that comes with it?&nbsp; I don't know what can be done short of re-assigning government issued identifiers to Chilean residents.&nbsp; This breach (or series of breaches) could be very costly to residents, the Chilean economy and the government. <br><br><span style="font-weight: bold;">Past Breaches:</span><br>Unknown</font><br><br>
<script src="http://feeds.feedburner.com/%7Es/breachblog?i=http://breachblog.com/2008/05/16/chile.aspx" type="text/javascript" charset="utf-8"></script>]]></content:encoded>
      <pubDate>Fri, 16 May 2008 09:56:50 +0000</pubDate>
      <category domain="http://securityratty.com/tag/personal">personal</category>
      <category domain="http://securityratty.com/tag/information">information</category>
      <category domain="http://securityratty.com/tag/chilean residents">chilean residents</category>
      <category domain="http://securityratty.com/tag/residents">residents</category>
      <category domain="http://securityratty.com/tag/poor data protection">poor data protection</category>
      <category domain="http://securityratty.com/tag/data protection">data protection</category>
      <category domain="http://securityratty.com/tag/personal data">personal data</category>
      <category domain="http://securityratty.com/tag/breach description">breach description</category>
      <category domain="http://securityratty.com/tag/breach">breach</category>
      <source url="http://breachblog.com/2008/05/16/chile.aspx">A coward exposes personal information on 40% of Chileans</source>
    </item>
    <item>
      <title><![CDATA[Data Loss Epidemic]]></title>
      <link>http://securityratty.com/article/c6a6474bcc74d7136c8b8fac3bf60743</link>
      <guid>http://securityratty.com/article/c6a6474bcc74d7136c8b8fac3bf60743</guid>
      <description><![CDATA[Most UK companies are losing data every month a survey has found. The majority of UK businesses, 79 per cent, are losing data at least once per month, according to the survey of 250 senior IT staff at...]]></description>
      <content:encoded><![CDATA[
      Most UK companies are losing data every month a survey has found. The majority of UK businesses, 79 per cent, are losing data at least once per month, according to the survey of 250 senior IT staff at businesses larger than 1,000 staff.. Read the rest of the article <a href="http://www.silicon.com/research/specialreports/fulldisclosure/0,3800014102,39219219,00.htm">here</a>.

The results of such surveys are great marketing for companies such as CA with their portfolio of threat management tools. I suppose the question is how you define "losing data." One record or a thousand records? Do you want to count every lost USB stick and mobile phone? Perhaps you should if they are likely to contain private data. Most of the problem is that we don't know where all our data is. There's no neat perimeter - it's everywhere from in your pocket to the third party company that does your mailshots.

Personally I'd prefer to not play on scare stories and wild statistics. There's a change of attitude required. We're not going to solve data security problems with technology alone and it's not simply an IT problem. It's culture, training, awareness, and technology. We need people to start asking how to protect data rather than waiting to be told.
      
   ]]></content:encoded>
      <pubDate>Tue, 13 May 2008 04:30:00 +0000</pubDate>
      <category domain="http://securityratty.com/tag/data">data</category>
      <category domain="http://securityratty.com/tag/protect data">protect data</category>
      <category domain="http://securityratty.com/tag/solve data security">solve data security</category>
      <category domain="http://securityratty.com/tag/lost usb stick">lost usb stick</category>
      <category domain="http://securityratty.com/tag/threat management tools">threat management tools</category>
      <category domain="http://securityratty.com/tag/businesses larger">businesses larger</category>
      <category domain="http://securityratty.com/tag/businesses">businesses</category>
      <category domain="http://securityratty.com/tag/wild statistics">wild statistics</category>
      <category domain="http://securityratty.com/tag/scare stories">scare stories</category>
      <source url="http://www.computerweekly.com/blogs/stuart_king/2008/05/data-loss-epidemic.html">Data Loss Epidemic</source>
    </item>
    <item>
      <title><![CDATA[I want my XP back !]]></title>
      <link>http://securityratty.com/article/c3b85407896a54d344d2ba8357ecc712</link>
      <guid>http://securityratty.com/article/c3b85407896a54d344d2ba8357ecc712</guid>
      <description><![CDATA[Seriously, I have nothing against Vista, except the almost daily BSODs


clipped from www.theregister.co.uk
Vista security credentials tarnished in malware survey


Vista]has been hailed by Microsoft...]]></description>
      <content:encoded><![CDATA[<div > Seriously, I have nothing against Vista, except the almost daily BSOD&#8217;s. </div>
<table cellpadding="0" cellspacing="0" width="100%" style="margin: 12px 0px; font-family: arial; color: #333333; background: #ffffff; border: solid 4px #e5e5e5; width: 100%; clear: left;">
<tr>
<td valign="top">
<table cellpadding="0" cellspacing="0" width="100%" class="CM_CTB_Content_Wrap" style="margin: 0px; padding: 0px;background-color: #ffffff;">
<tr>
<td valign="top">
<table cellpadding="0" cellspacing="0" width="100%" style="border-bottom: solid 1px #dcdcdc; white-space: nowrap; margin-bottom: 8px; background-color: #eeeeee ;background-image: url(http://clipmarks.com/images/source-bg.gif); background-repeat: repeat-x; height: 24px; line-height: 24px; vertical-align: middle; padding-bottom: 4px; color: #666666; font-size: 10px;">
<tr>
<td valign="top"><a href="http://clipmarks.com/clipmark/95C72BCF-2A5B-4E30-82CE-C39F197AC70F/" title="go to this clipmark"><img src="http://content.clipmarks.com/blog_icon/957d3c18-36b8-4a03-8a24-e3d38fd2785d/95C72BCF-2A5B-4E30-82CE-C39F197AC70F/" alt="" width="19" height="19" border="0" style="vertical-align: middle; margin: 0px 4px; display: inline; border: none; float:none;" /></a>clipped from <a title="http://www.theregister.co.uk/2008/05/09/win_malware_survey/" href="http://www.theregister.co.uk/2008/05/09/win_malware_survey/" style="font-size: 11px;">www.theregister.co.uk</a></td>
</tr>
</table>
<table cellpadding="0" cellspacing="0" width="100%" style="text-align: left; padding: 0px 8px; margin: 4px 0px 8px 0px; background: transparent; border: none;">
<tr>
<td valign="top"><!-- CLIPPED FROM: http://www.theregister.co.uk/2008/05/09/win_malware_survey/ --><H2>Vista security credentials tarnished in malware survey</H2></td>
</tr>
</table>
<div style="height: 2px; font-size: 2px; background: #dcdcdc; border-bottom: solid 1px #f5f5f5; margin: 2px 4px;"></div>
<table cellpadding="0" cellspacing="0" width="100%" style="text-align: left; padding: 0px 8px; margin: 4px 0px 8px 0px; background: transparent; border: none;">
<tr>
<td valign="top"><!-- CLIPPED FROM: http://www.theregister.co.uk/2008/05/09/win_malware_survey/ --><P>&#8220;[Vista]has been hailed by Microsoft as the most secure version of Windows to date. However, recent research conducted with statistics from over 1.4 million computers within the ThreatFire community has shown that Windows Vista is more susceptible to malware than the eight year old Windows 2000 operating system, and only 37 per cent more secure than Windows XP,&#8221; said Simon Clausen, chief exec at PC Tools.</P></td>
</tr>
</table>
</td>
</tr>
</table>
<div style="margin: 0px 6px 6px 4px;">
<table style="font-size: 11px;border-spacing: 0px;padding: 0px;" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td style="background:transparent;border-width:0px;padding:0px;">&nbsp;</td>
<td align="right" style="background:transparent;border-width:0px;padding:0px;width:107px" width="107"><a href="http://clipmarks.com/share/95C72BCF-2A5B-4E30-82CE-C39F197AC70F/blog/" title="blog or email this clip"><img src="http://content8.clipmarks.com/images/c2b-foot.png" border="0" alt="blog it" width="107" height="17" style="border-width:0px;padding:0px;margin:0px;" /></a></td>
</tr>
</table>
</div>
</td>
</tr>
</table>
]]></content:encoded>
      <pubDate>Fri, 09 May 2008 19:40:07 +0000</pubDate>
      <category domain="http://securityratty.com/tag/vista">vista</category>
      <category domain="http://securityratty.com/tag/vista security credentials">vista security credentials</category>
      <category domain="http://securityratty.com/tag/windows vista">windows vista</category>
      <category domain="http://securityratty.com/tag/windows">windows</category>
      <category domain="http://securityratty.com/tag/secure">secure</category>
      <category domain="http://securityratty.com/tag/malware survey">malware survey</category>
      <category domain="http://securityratty.com/tag/secure version">secure version</category>
      <category domain="http://securityratty.com/tag/malware">malware</category>
      <category domain="http://securityratty.com/tag/chief exec">chief exec</category>
      <source url="http://spywarebiz.com/spywarebizblog/?p=449">I want my XP back !</source>
    </item>
    <item>
      <title><![CDATA[Learning from Ghana]]></title>
      <link>http://securityratty.com/article/6db10d84d0fd57500d7865198a2bae4a</link>
      <guid>http://securityratty.com/article/6db10d84d0fd57500d7865198a2bae4a</guid>
      <description><![CDATA[Its always interesting to see where the developed world can learn from emerging economies. A lot of the best engineering work comes from having to deal with harsh constraints (opposite of architecture...]]></description>
      <content:encoded><![CDATA[<p>Its always interesting to see where the developed world can learn from emerging economies. A lot of the best engineering work comes from having to deal with harsh constraints (opposite of architecture astronomics). I <a href="http://1raindrop.typepad.com/1_raindrop/2007/08/beer-shotguns-a.html">blogged awhile ago</a> about using smart cards for digital cash in Africa</p>

<p><br />
<img alt="Ezwichcard" title="Ezwichcard" src="http://1raindrop.typepad.com/photos/uncategorized/2008/05/09/ezwichcard.jpg" border="0" style="float: left; margin: 0px 5px 5px 0px;" /></p>

<p>Looks like there is a new system in Ghana as well</p>

<blockquote><a href="http://www.newtimesonline.com/index.php?option=com_content&task=view&id=15408&Itemid=203">E-zwhich smart launched</a>

<p>-ZWICH smartcard, a universal electronic system that facilitates easy access to and transfer of money has now become part of financial transactions in Ghana.</p>

<p>The new system which is also designed to remove the cumbersome and insecure processes of using cash, was launched in Accra yesterday by President J.A. Kufuor, with a call on corporate bodies and government agencies to use it to ensure transparency and integrity on payrolls.</p>

<p>E-zwich is an electronic payment system that allows one to make payments for goods and services or transfer money to others without having to carry physical cash.</p>

<p>Available at all banks countrywide, the system involves the loading of money onto the smart card after registering with any bank without necessarily having an accounts with that bank.</p>

<p>President Kufuor said the introduction of the system has the potential of transforming the payments landscape, the financial services industry and the general conduct of business in the country.</p>

<p>He said accessing the technology was an integral part of government’s overall vision of making Ghana the gateway to the West Africa sub-region and transforming her into a major financial hub.</p>

<p>The President said that globalisation has come with a major challenge of adopting best practices in all spheres of endeavour especially within the macro economy in order to survive in the market.</p>

<p>He said it was against that background that the government has pursued polices to develop and modernise the financial sector to enable it to play a key role in resource mobilisation for increased investment.</p>

<p>With the reforms and the stability of the macro-economy, President Kufuor said the nation was witnessing dramatic growth in the banking sector.</p>

<p>He pointed out, however, that inspite of the impressive growth of financial institutions, an estimated 80 per cent of the eligible population was still "un-banked" or "under-banked" and seemed not to have access to financial services.</p>

<p><br />
</blockquote></p>

<p>Wonder when we will see US, UK, and other first world banks and brokerages catch up to Ghana and South Africa on these technologies? Is it really a good idea in 2008 to have everyone type their username and password into a web browser?</p>]]></content:encoded>
      <pubDate>Fri, 09 May 2008 06:27:18 +0000</pubDate>
      <category domain="http://securityratty.com/tag/system involves">system involves</category>
      <category domain="http://securityratty.com/tag/system">system</category>
      <category domain="http://securityratty.com/tag/financial services industry">financial services industry</category>
      <category domain="http://securityratty.com/tag/services">services</category>
      <category domain="http://securityratty.com/tag/electronic payment system">electronic payment system</category>
      <category domain="http://securityratty.com/tag/ghana">ghana</category>
      <category domain="http://securityratty.com/tag/president kufuor">president kufuor</category>
      <category domain="http://securityratty.com/tag/kufuor">kufuor</category>
      <category domain="http://securityratty.com/tag/universal electronic system">universal electronic system</category>
      <source url="http://1raindrop.typepad.com/1_raindrop/2008/05/learning-from-g.html">Learning from Ghana</source>
    </item>
    <item>
      <title><![CDATA[If your computer is not secure, Bank may not pay]]></title>
      <link>http://securityratty.com/article/b0a527905eed34e2a512b2f155dc389a</link>
      <guid>http://securityratty.com/article/b0a527905eed34e2a512b2f155dc389a</guid>
      <description><![CDATA[Great article that will make users think more about how secure their computer is. If the bank requires you to be secure, and you are not, they may not pay if your account is stolen


clipped from...]]></description>
      <content:encoded><![CDATA[<div > Great article that will make users think more about how secure their computer is. If the bank requires you to be secure, and you are not, they may not pay if your account is stolen. </div>
<table cellpadding="0" cellspacing="0" width="100%" style="margin: 12px 0px; font-family: arial; color: #333333; background: #ffffff; border: solid 4px #e5e5e5; width: 100%; clear: left;">
<tr>
<td valign="top">
<table cellpadding="0" cellspacing="0" width="100%" class="CM_CTB_Content_Wrap" style="margin: 0px; padding: 0px;background-color: #ffffff;">
<tr>
<td valign="top">
<table cellpadding="0" cellspacing="0" width="100%" style="border-bottom: solid 1px #dcdcdc; white-space: nowrap; margin-bottom: 8px; background-color: #eeeeee ;background-image: url(http://clipmarks.com/images/source-bg.gif); background-repeat: repeat-x; height: 24px; line-height: 24px; vertical-align: middle; padding-bottom: 4px; color: #666666; font-size: 10px;">
<tr>
<td valign="top"><a href="http://clipmarks.com/clipmark/B49207B8-CCEE-47C4-AC47-B9E1388937D7/" title="go to this clipmark"><img src="http://content.clipmarks.com/blog_icon/6c8fdc6d-cba3-468e-8cb0-d89ae2a4e6c9/B49207B8-CCEE-47C4-AC47-B9E1388937D7/" alt="" width="19" height="19" border="0" style="vertical-align: middle; margin: 0px 4px; display: inline; border: none; float:none;" /></a>clipped from <a title="http://www.canada.com/windsorstar/news/story.html?id=314a61ef-6e7a-4268-b897-00d1903e3b3e" href="http://www.canada.com/windsorstar/news/story.html?id=314a61ef-6e7a-4268-b897-00d1903e3b3e" style="font-size: 11px;">www.canada.com</a></td>
</tr>
</table>
<table cellpadding="0" cellspacing="0" width="100%" style="text-align: left; padding: 0px 8px; margin: 4px 0px 8px 0px; background: transparent; border: none;">
<tr>
<td valign="top"><!-- CLIPPED FROM: http://www.canada.com/windsorstar/news/story.html?id=314a61ef-6e7a-4268-b897-00d1903e3b3e --><H2>Bank online security misleading, study finds</H2></td>
</tr>
</table>
<div style="height: 2px; font-size: 2px; background: #dcdcdc; border-bottom: solid 1px #f5f5f5; margin: 2px 4px;"></div>
<table cellpadding="0" cellspacing="0" width="100%" style="text-align: left; padding: 0px 8px; margin: 4px 0px 8px 0px; background: transparent; border: none;">
<tr>
<td valign="top"><!-- CLIPPED FROM: http://www.canada.com/windsorstar/news/story.html?id=314a61ef-6e7a-4268-b897-00d1903e3b3e --><P>Paul Van Oorschot, Canada Research Chair in Network and Software Security at Carleton University, and Ph.D. student Mohammad Mannan, a specialist in Internet security, tested the standard banking claim of a &#8220;100 per cent online security guarantee&#8221; against the fine print that makes it conditional on fulfilling complicated security requirements.</P></td>
</tr>
</table>
</td>
</tr>
</table>
<div style="margin: 0px 6px 6px 4px;">
<table style="font-size: 11px;border-spacing: 0px;padding: 0px;" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td style="background:transparent;border-width:0px;padding:0px;">&nbsp;</td>
<td align="right" style="background:transparent;border-width:0px;padding:0px;width:107px" width="107"><a href="http://clipmarks.com/share/B49207B8-CCEE-47C4-AC47-B9E1388937D7/blog/" title="blog or email this clip"><img src="http://content8.clipmarks.com/images/c2b-foot.png" border="0" alt="blog it" width="107" height="17" style="border-width:0px;padding:0px;margin:0px;" /></a></td>
</tr>
</table>
</div>
</td>
</tr>
</table>
]]></content:encoded>
      <pubDate>Thu, 10 Apr 2008 12:17:52 +0000</pubDate>
      <category domain="http://securityratty.com/tag/secure">secure</category>
      <category domain="http://securityratty.com/tag/canada">canada</category>
      <category domain="http://securityratty.com/tag/canada research chair">canada research chair</category>
      <category domain="http://securityratty.com/tag/paul van oorschot">paul van oorschot</category>
      <category domain="http://securityratty.com/tag/bank online security">bank online security</category>
      <category domain="http://securityratty.com/tag/student mohammad mannan">student mohammad mannan</category>
      <category domain="http://securityratty.com/tag/fine print">fine print</category>
      <category domain="http://securityratty.com/tag/security requirements">security requirements</category>
      <category domain="http://securityratty.com/tag/internet security">internet security</category>
      <source url="http://spywarebiz.com/spywarebizblog/?p=426">If your computer is not secure, Bank may not pay</source>
    </item>
  </channel>
</rss>
