1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1047 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-07-11 21:56:21 +00:00
parent 2d6d81bc89
commit a8f9070ba0

View File

@ -18,85 +18,77 @@
<spec>XMPP IM</spec>
<spec>XEP-0004</spec>
<spec>XEP-0066</spec>
<spec>XEP-0221</spec>
</dependencies>
<supersedes>None</supersedes>
<supersededby>None</supersededby>
<shortname>challenge</shortname>
<shortname>TO BE ASSIGNED</shortname>
&ianpaterson;
&stpeter;
<revision>
<version>0.6</version>
<date>2007-07-11</date>
<initials>psa/ip</initials>
<remark><p>Moved media element definition to XEP-0221; consistently used the terms sender and challenger rather than client and entity; modified provisional namespaces to adhere to XMPP Registrar policies; completed editorial review.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2006-10-30</date>
<initials>ip</initials>
<remark>Added reference to SPIM Reporting</remark>
<remark><p>Added reference to SPIM Reporting.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2005-09-30</date>
<initials>ip</initials>
<remark>Required WAV instead of MP3 for audio CAPTCHAs; minor corrections</remark>
<remark><p>Required WAV instead of MP3 for audio CAPTCHAs; minor corrections.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2005-09-28</date>
<initials>ip</initials>
<remark>Added more CAPTCHA types and the legacy question and answer section</remark>
<remark><p>Added more CAPTCHA types and the legacy question and answer section.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2005-09-14</date>
<initials>ip</initials>
<remark>Minor fixes</remark>
<remark><p>Minor fixes.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2005-09-14</date>
<initials>ip</initials>
<remark>Initial version.</remark>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2005-09-07</date>
<initials>ip</initials>
<remark>First draft.</remark>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The appearance of large public IM services based on &rfc3920; and &rfc3921; makes it desirable to implement protocols that <em>discourage</em> the sending of large quantities of IM SPAM (SPIM) from XMPP clients (connected to legitimate servers) and XMPP servers (with virtual clients) -- all hosted on networks of 'zombie' machines. SPIM is defined here as any type of unsolicited XMPP stanza sent by a 'robot' and delivered to a human, including messages and subscription requests. SPIM has the potential to disrupt people even more than SPAM, because each message interrupts the receiver (humans typically filter SPAM in batch mode).</p>
<p>Several of the most effective techniques developed to combat SPAM require humans to be differentiated from bots using a "Completely Automated Public Turing Test to Tell Computers and Humans Apart" or CAPTCHA (see &lt;<link url='http://www.captcha.net/'>http://www.captcha.net/</link>&gt;). These challenge techniques are easily adapted to discourage SPIM. The very occasional inconvenience of responding to a CAPTCHA (for example, when creating an IM account or sending a message to a new correspondent) is small and perfectly acceptable -- especially when compared to the countless robot-generated interruptions people might otherwise have to filter every day.</p>
<p>An alternative technique to CAPTCHAs requires Desktop PC clients to undertake a <span class='ref'>Hashcash</span> <note>Hashcash &lt;<link url='http://hashcash.org/'>http://hashcash.org/</link>&gt;.</note> challenge. These are completely transparent to PC users. They require clients to perform specified CPU-intensive work, making it difficult to send large amounts of SPIM.</p>
<p>The generic challenge protocol described in this document is designed for incorporation into other protocols like &xep0077; and &xep0159;.</p>
<p>The appearance of large public IM services based on &rfc3920; and &rfc3921; makes it desirable to implement protocols that <em>discourage</em> the sending of large quantities of instant messaging spam (a.k.a. "spim"). Spim could be generated by XMPP clients connected to legitimate servers or by XMPP servers with virtual clients, where the malicious entities are hosted on networks of "zombie" machines. Spim is defined here as any type of unsolicited XMPP stanza sent by a "robot" and delivered to a human, including messages and subscription requests. Spim has the potential to disrupt people even more than spam, because each message interrupts the receiver (humans typically filter SPAM in batch mode).</p>
<p>Several of the most effective techniques developed to combat SPAM require humans to be differentiated from bots using a "Completely Automated Public Turing Test to Tell Computers and Humans Apart" or CAPTCHA (see &lt;<link url='http://www.captcha.net/'>http://www.captcha.net/</link>&gt;). These challenge techniques are easily adapted to discourage spim. The very occasional inconvenience of responding to a CAPTCHA (e.g., when creating an IM account or sending a message to a new correspondent) is small and perfectly acceptable -- especially when compared to the countless robot-generated interruptions people might otherwise have to filter every day.</p>
<p>An alternative technique to CAPTCHAs requires Desktop PC clients to undertake a <span class='ref'>Hashcash</span> <note>Hashcash &lt;<link url='http://hashcash.org/'>http://hashcash.org/</link>&gt;.</note> challenge. These are completely transparent to PC users. They require clients to perform specified CPU-intensive work, making it difficult to send large amounts of spim.</p>
<p>The generic challenge protocol described in this document is designed for incorporation into protocols such as &xep0077; and &xep0159;.</p>
</section1>
<section1 topic='Requirements' anchor='require'>
<section2 topic='Extensibility' anchor='require-extend'>
<p>The CAPTCHAs in most common use today are Optical Character Recognition (OCR) challenges where an image containing deformed text is presented and the human enters the characters they can read. However if OCR software advances more rapidly than the techniques used to disguise text from Artificial Intelligence (AI) then very different CAPTCHAs will need to be deployed. This protocol must be extensible enough to allow the incorporation of CAPTCHA techniques that may not have been envisaged.</p>
<p>The CAPTCHAs in most common use today are Optical Character Recognition (OCR) challenges where an image containing deformed text is presented and the human enters the characters they can read. However, if OCR software advances more rapidly than the techniques used to disguise text from Artificial Intelligence (AI) then very different CAPTCHAs will need to be deployed. This protocol must be extensible enough to allow the incorporation of CAPTCHA techniques that may not have been envisaged.</p>
</section2>
<section2 topic='Variety' anchor='require-variety'>
<p>Several common CAPTCHA techniques present major problems to users with disabilities (see &w3turingtest;). Clients running in constrained environments may not be able to perform some challenges (for example, due to the absence of audio output or a lack of CPU performance). This protocol must allow clients to be offered a choice from a variety of challenges.</p>
<p>Several common CAPTCHA techniques present major problems to users with disabilities (see &w3turingtest;). Clients running in constrained environments may not be able to perform some challenges (e.g., due to the absence of audio output or a lack of CPU performance). This protocol must allow clients to be offered a choice from a variety of challenges.</p>
</section2>
</section1>
<section1 topic='Media Element' anchor='media'>
<p>This protocol requires multimedia to be included within &xep0004;. This section defines a new namespace ('urn:xmpp:media') for that purpose. The root element for the namespace is &lt;media/&gt;. It MUST be contained within a &lt;field/&gt; element qualified by the 'jabber:x:data' namespace.</p>
<p>If the media is an image or video then the &lt;media/&gt; element SHOULD include 'width' and 'height' attributes specifying the recommended display size of the media in pixels.</p>
<p>The &lt;media/&gt; element SHOULD contain at least one &lt;uri/&gt; element to specify the out-of-band location of the media data. <note>Constrained execution environments prevent some clients rendering media unless it has been received out-of-band (e.g., Web clients).</note> The &lt;uri/&gt; element MUST contain a URI that indicates the location.</p>
<p>The &lt;media/&gt; element MAY also contain one or more &lt;data/&gt; elements for distributing the media in-band. The &lt;data/&gt; element MUST contain the Base64 encoded (in accordance with Section 4 of &rfc4648;) media data. The <em>encoded</em> data SHOULD NOT be larger than 8 KB. Note that if a stanza contains more than one &lt;data/&gt; element then the sending entity MUST take care not to trigger karma limits.</p>
<p>Each &lt;uri/&gt; or &lt;data/&gt; element MUST include a 'type' atribute that specifies the MIME type (see &rfc2045;) of the media.</p>
<example caption='Audio Media Element'><![CDATA[
<media xmlns='xmlns='urn:xmpp:media'>
<uri type='audio/x-wav'>http://www.victim.com/challenges/speech.wav?F3A6292C</uri>
<uri type='audio/ogg-speex'>http://www.victim.com/challenges/speech.ogg?F3A6292C</uri>
<uri type='audio/mpeg'>http://www.victim.com/challenges/speech.mp3?F3A6292C</uri>
<data type='audio/x-wav'> ** Base64 encoded audio ** </data>
</media>
]]></example>
</section1>
<section1 topic='Protocol Usage' anchor='protocol'>
<section2 topic='Simple Challenge' anchor='protocol-simple'>
<p>An entity (client or server) MAY send a challenge to a client immediately after receiving a stanza from the client. An entity MUST NOT send challenges under any other circumstances. Hereafter, the entity that sends a challenge is called a "challenger".</p>
<example caption='Client Sends Stanza Via Server'><![CDATA[
<p>An entity (client or server) MAY send a challenge immediately after receiving a stanza from another entitiy. An entity MUST NOT send challenges under any other circumstances. Hereafter, the entity that generates the stanza that triggers the challenge is called the "sender" and the entity that sends the challenge is called the "challenger".</p>
<example caption='Sender Generates Stanza'><![CDATA[
<message from='robot@spimmer.com/zombie'
to='innocent@victim.com'
xml:lang='en'
@ -108,51 +100,53 @@
</message>
]]></example>
<section3 topic='Challenge Stanza' anchor='protocol-challenge'>
<p>Each of the challenge form's &lt;field/&gt; elements (see <cite>Data Forms</cite>) that are not hidden MAY contain a different challenge and any media required for the challenge. The hidden 'from' field MUST contain the value of the 'to' attribute of the client's stanza that triggered the challenge. If the stanza from the client included an 'id' attribute then the hidden 'sid' field MUST be set to that value. The 'xml:lang' attribute of the challenge stanza SHOULD be the same as the one received from the client. The hidden 'FORM_TYPE' field MUST have a value of "urn:xmpp:challenge" in accordance with &xep0068;.</p>
<p>The challenger SHOULD include an explanation (in the &BODY; element) for clients that do not support this protocol. The challenger MAY also include a URL (typically a Web page with instructions) using &xep0066; as an alternative for clients that do not support the challenge form. Note: even if it provides a URL, a challenger MUST always provide a challenge form. <note>A constrained client, like a mobile phone, cannot present a Web page to its user.</note></p>
<example caption='Server Offers a Choice of Challenges to a Client'><![CDATA[
<p>The challange consists of a message containing a form for the sender to fill out, formatted according to &xep0004;. Each of the challenge form's &lt;field/&gt; elements that are not hidden MAY contain a different challenge and any media required for the challenge (see &xep0221;). The hidden 'from' field MUST contain the value of the 'to' attribute of the sender's triggering stanza. If the stanza from the sender included an 'id' attribute then the hidden 'sid' field MUST be set to that value. The 'xml:lang' attribute of the challenge stanza SHOULD be the same as the one received from the sender. In accordance with &xep0068;, the hidden 'FORM_TYPE' field MUST have a value of "http://www.xmpp.org/extensions/xep-0158.html#ns" &NSNOTE;.</p>
<p>The challenger SHOULD include an explanation (in the &BODY; element) for clients that do not support this protocol. The challenger MAY also include a URL (typically a Web page with instructions) using &xep0066; as an alternative for clients that do not support the challenge form. Note: Even if it provides a URL, a challenger MUST always provide a challenge form. <note>A constrained client, like a mobile phone, cannot present a Web page to its user.</note></p>
<example caption='Challenge Offers a Choice of Challenges to Sender'><![CDATA[
<message from='victim.com'
to='robot@spimmer.com/zombie'
xml:lang='en'
id='F3A6292C'>
<body>Your messages to innocent@victim.com are being blocked.
Visit the Web page to unblock them.</body>
<body>
Your messages to innocent@example.com are being blocked. To unblock
them, visit http://www.victim.com/challenge.html?F3A6292C
</body>
<x xmlns='jabber:x:oob'>
<url>http://www.victim.com/challenge.html?F3A6292C</url>
</x>
<challenge xmlns='urn:xmpp:challenge'>
<challenge xmlns='http://www.xmpp.org/extensions/xep-0158.html#ns'>
<x xmlns='jabber:x:data' type='form'>
<field type='hidden' var='FORM_TYPE'>
<value>urn:xmpp:challenge</value>
<value>http://www.xmpp.org/extensions/xep-0158.html#ns</value>
</field>
<field type='hidden' var='from'><value>innocent@victim.com</value></field>
<field type='hidden' var='sid'><value>spam1</value></field>
<field var='ocr'>
<media xmlns='xmlns='urn:xmpp:media'
width='290'
height='80'>
<media xmlns='xmlns='http://www.xmpp.org/extensions/xep-0221.html#ns'
height='80'
width='290'>
<uri type='image/jpeg'>http://www.victim.com/challenges/ocr.jpeg?F3A6292C</uri>
<data type='image/jpeg'> ** Base64 encoded image ** </data>
</media>
</field>
<field var='picture_recog'>
<media xmlns='xmlns='urn:xmpp:media'
width='150'
height='150'>
<media xmlns='xmlns='http://www.xmpp.org/extensions/xep-0221.html#ns'
height='150'
width='150'>
<uri type='image/jpeg'>http://www.victim.com/challenges/picture.jpeg?F3A6292C</uri>
<data type='image/jpeg'> ** Base64 encoded image ** </data>
</media>
</field>
<field var='speech_recog'>
<media xmlns='xmlns='urn:xmpp:media'>
<media xmlns='xmlns='http://www.xmpp.org/extensions/xep-0221.html#ns'>
<uri type='audio/x-wav'>http://www.victim.com/challenges/speech.wav?F3A6292C</uri>
<uri type='audio/ogg-speex'>http://www.victim.com/challenges/speech.ogg?F3A6292C</uri>
</media>
</field>
<field var='video_recog'>
<media xmlns='xmlns='urn:xmpp:media'
width='150'
height='150'>
<media xmlns='xmlns='http://www.xmpp.org/extensions/xep-0221.html#ns'
height='150'
width='150'>
<uri type='video/mpeg'>http://www.victim.com/challenges/video.mpeg?F3A6292C</uri>
</media>
</field>
@ -165,25 +159,25 @@
</section3>
<section3 topic='Response Stanza' anchor='protocol-response'>
<p>The client SHOULD ignore the challenge stanza in either of the following cases:</p>
<p>The sender's client SHOULD ignore the challenge stanza in either of the following cases:</p>
<ul>
<li>If it has not recently sent (in the last two minutes for example) a stanza to the JID specified in the 'from' field of the form with the 'id' specified in the 'sid' field (or with no 'id' if no 'sid' field is included). <note>Otherwise the user's presence would be disclosed, or a SPIM robot might dupe the user into providing answers to other people's challenges!</note></li>
<li>If it has not recently sent (e.g., in the last two minutes) a stanza to the JID specified in the 'from' field of the form with the 'id' specified in the 'sid' field (or with no 'id' if no 'sid' field is included). <note>Otherwise the user's presence would be disclosed, or a spim robot might dupe the user into providing answers to other people's challenges!</note></li>
<li>If the 'from' attribute of the challenge stanza does not match the 'from' field of the form. (If the values are different, then they still match if the bare JIDs are the same, or if the 'from' attribute is the domain of the other JID.)</li>
</ul>
<p>Otherwise, if the challenger provided a URL using <cite>Out-of-Band Data</cite>, then the client MAY present the URL to its user, instead of responding to the challenge form, in any of the following cases:</p>
<p>Otherwise, if the challenger provided a URL using <cite>Out-of-Band Data</cite>, then the sender's client MAY present the URL to the sender, instead of responding to the challenge form, in any of the following cases:</p>
<ul>
<li>if it does not understand the challenge form</li>
<li>if it does not support all of the <em>required</em> challenges (see <link url='#protocol-multiple'>Multiple Challenges</link>)</li>
<li>if it does not support enough of the challenges (see <link url='#protocol-multiple'>Multiple Challenges</link>)</li>
</ul>
<p>Otherwise, the client MUST respond to the challenger, preserving the 'id' attribute of the challenge stanza.</p>
<p>The client MUST respond with a &notacceptable; error in any of the following cases:</p>
<p>Otherwise, the sender's client MUST respond to the challenge, preserving the 'id' attribute of the challenge stanza.</p>
<p>The sender's client MUST respond with a &notacceptable; error in any of the following cases:</p>
<ul>
<li>if it does not support all of the required challenges (see <link url='#protocol-multiple'>Multiple Challenges</link>)</li>
<li>if it does not support enough of the challenges (see <link url='#protocol-multiple'>Multiple Challenges</link>)</li>
<li>if its user declines the challenge</li>
<li>if the sender declines the challenge</li>
</ul>
<example caption='Client Reports Challenge Not Acceptable'><![CDATA[
<example caption='Sender Reports Challenge Not Acceptable'><![CDATA[
<message type='error'
from='robot@spimmer.com/zombie'
to='victim.com'
@ -194,17 +188,17 @@
</error>
</message>
]]></example>
<p>Otherwise, it MUST select one challenge according to the user's preferences and submit the user's response form to the challenger.</p>
<example caption='Client Sends one Response to the Server'><![CDATA[
<p>Otherwise, it MUST select one challenge according to the sender's preferences and submit the sender's response form to the challenger.</p>
<example caption='Sender Sends One Response to Challenger'><![CDATA[
<iq type='set'
from='robot@spimmer.com/zombie'
to='victim.com'
xml:lang='en'
id='F3A6292C'>
<challenge xmlns='urn:xmpp:challenge'>
<challenge xmlns='http://www.xmpp.org/extensions/xep-0158.html#ns'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>urn:xmpp:challenge</value>
<value>http://www.xmpp.org/extensions/xep-0158.html#ns</value>
</field>
<field var='from'><value>innocent@victim.com</value></field>
<field var='sid'><value>spam1</value></field>
@ -216,14 +210,14 @@
</section3>
<section3 topic='Result Stanza' anchor='protocol-result'>
<p>The challenger SHOULD send a &unavailable; error to the client if:</p>
<p>The challenger SHOULD send a &unavailable; error to the sender if:</p>
<ul>
<li>The challenger did not send the specified challenge. <note>If the challenger is a client then it SHOULD be careful not to leak information about the presence of its user and reply to potentially bogus challenge responses with exactly the same XML that its server would send if its user were offline.</note></li>
<li>The client already submitted its response to this challenge.</li>
<li>The client took too long to submit its response.</li>
<li>The challenger did not send the specified challenge. <note>If the challenger is a client then it SHOULD be careful not to leak information about the presence of the sender and reply to potentially bogus challenge responses with exactly the same XML that its server would send if the sender were offline.</note></li>
<li>The sender already submitted its response to this challenge.</li>
<li>The sender took too long to submit its response.</li>
</ul>
<p>Note: This error MAY be sent even in cases where the challenge became unnecessary while the challenger was waiting for the response.</p>
<example caption='Server Indicates Challenge Not Found'><![CDATA[
<example caption='Challenger Indicates Challenge Not Found'><![CDATA[
<iq type='error'
from='victim.com'
to='robot@spimmer.com/zombie'
@ -233,15 +227,15 @@
</error>
</iq>
]]></example>
<p>After receiving a correct response to its challenge, the challenger SHOULD inform the client that it was successful.</p>
<example caption='Server Tells the Client it Passed'><![CDATA[
<p>After receiving a correct response to its challenge, the challenger SHOULD inform the sender that it was successful.</p>
<example caption='Challenger Tells Sender it Passed'><![CDATA[
<iq type='result'
from='victim.com'
to='robot@spimmer.com/zombie'
id='F3A6292C'/>
]]></example>
<p>However, if the client submits an incorrect response the challenger SHOULD send it a &notacceptable; error with type "cancel": <note>If a large proportion of the responses a server is receiving from another IP are incorrect then it SHOULD inform the administrator of the other server (using the protocol to be defined in a forthcoming proposal on SPIM reporting). It SHOULD also automatically block all stanzas from the abusive user, users, server or IP.</note></p>
<example caption='Server Tells the Client it Failed'><![CDATA[
<p>However, if the sender submits an incorrect response the challenger SHOULD send it a &notacceptable; error with type "cancel": <note>If a large proportion of the responses a server is receiving from another IP are incorrect then it SHOULD inform the administrator of the other server using the protocol specified in &xep0161;. It SHOULD also automatically block all stanzas from the abusive user, users, server or IP.</note></p>
<example caption='Challenger Tells Sender it Failed'><![CDATA[
<iq type='error'
from='victim.com'
to='robot@spimmer.com/zombie'
@ -254,31 +248,31 @@
</section3>
</section2>
<section2 topic='Multiple Challenges' anchor='protocol-multiple'>
<p>The enitity may demand responses to more than one of the challenges it is offering by including an 'answers' &lt;field/&gt; element in the form. It may require responses to particular challenges by including &lt;required/&gt; elements in the compulsory fields.</p>
<example caption='Server Sets Multiple Challenges'><![CDATA[
<p>The challenger may demand responses to more than one of the challenges it is offering by including an 'answers' &lt;field/&gt; element in the form. It may require responses to particular challenges by including &lt;required/&gt; elements in the compulsory fields.</p>
<example caption='Challenger Sets Multiple Challenges'><![CDATA[
<message from='victim.com'
to='robot@spimmer.com/zombie'
xml:lang='en'
id='73DE28A2'>
<body>Your messages to innocent@victim.com are being blocked.
To unblock them, ask innocent@victim.com to send you a message.</body>
<challenge xmlns='urn:xmpp:challenge'>
<challenge xmlns='http://www.xmpp.org/extensions/xep-0158.html#ns'>
<x xmlns='jabber:x:data' type='form'>
<field type='hidden' var='FORM_TYPE'>
<value>urn:xmpp:challenge</value>
<value>http://www.xmpp.org/extensions/xep-0158.html#ns</value>
</field>
<field type='hidden' var='from'><value>innocent@victim.com</value></field>
<field type='hidden' var='sid'><value>spam2</value></field>
<field type='hidden' var='answers'><value>2</value></field>
<field var='ocr'>
<media xmlns='xmlns='urn:xmpp:media'
width='290'
height='80'>
<media xmlns='xmlns='http://www.xmpp.org/extensions/xep-0221.html#ns'
height='80'
width='290'>
<uri type='image/jpeg'>http://www.victim.com/challenges/ocr.jpeg?F3A6292C</uri>
</media>
</field>
<field var='audio_recog'>
<media xmlns='xmlns='urn:xmpp:media'>
<media xmlns='xmlns='http://www.xmpp.org/extensions/xep-0221.html#ns'>
<uri type='audio/x-wav'>http://www.victim.com/challenges/audio.wav?F3A6292C</uri>
</media>
</field>
@ -291,17 +285,17 @@
</message>
]]></example>
<p>If the client finds the request acceptable, it MUST answer all challenges that include a &lt;required/&gt; element. If the total number of answers was specified and it is greater than the number of &lt;required/&gt; elements then the client MUST also answer one or more of the challenges without a &lt;required/&gt; element. In the example above, the client should respond to the 'qa' challenge <em>and</em> one of the other challenges ('ocr', 'audio_recog' or 'SHA-256').</p>
<example caption='Client Sends Multiple Responses to the Server'><![CDATA[
<p>If the sender finds the request acceptable, it MUST answer all challenges that include a &lt;required/&gt; element. If the total number of answers was specified and it is greater than the number of &lt;required/&gt; elements then the sender MUST also answer one or more of the challenges without a &lt;required/&gt; element. In the example above, the sender should respond to the 'qa' challenge <em>and</em> one of the other challenges ('ocr', 'audio_recog' or 'SHA-256').</p>
<example caption='Sender Sends Multiple Responses to the Challenger'><![CDATA[
<iq type='set'
from='robot@spimmer.com/zombie'
to='victim.com'
xml:lang='en'
id='73DE28A2'>
<challenge xmlns='urn:xmpp:challenge'>
<challenge xmlns='http://www.xmpp.org/extensions/xep-0158.html#ns'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>urn:xmpp:challenge</value>
<value>http://www.xmpp.org/extensions/xep-0158.html#ns</value>
</field>
<field var='from'><value>innocent@victim.com</value></field>
<field var='sid'><value>spam2</value></field>
@ -312,7 +306,7 @@
</challenge>
</iq>
]]></example>
<p>The challenger MAY decide the client has passed a challenge even if the responses are not all perfectly correct.</p>
<p>The challenger MAY decide the sender has passed a challenge even if the responses are not all perfectly correct.</p>
</section2>
</section1>
@ -329,14 +323,14 @@
<query xmlns='jabber:iq:register'>
<x xmlns='jabber:x:data' type='form'>
<field type='hidden' var='FORM_TYPE'>
<value>urn:xmpp:challenge</value>
<value>http://www.xmpp.org/extensions/xep-0158.html#ns</value>
</field>
<field type='hidden' var='cid'><value>F3A6292C</value></field>
<field type='hidden' var='answers'><value>3</value></field>
<field var='ocr'>
<media xmlns='xmlns='urn:xmpp:media'
width='290'
height='80'>
<media xmlns='xmlns='http://www.xmpp.org/extensions/xep-0221.html#ns'
height='80'
width='290'>
<uri type='image/jpeg'>http://www.victim.com/challenges/ocr.jpeg?F3A6292C</uri>
</media>
</field>
@ -364,7 +358,7 @@
<query xmlns='jabber:iq:register'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE'>
<value>urn:xmpp:challenge</value>
<value>http://www.xmpp.org/extensions/xep-0158.html#ns</value>
</field>
<field var='cid'><value>F3A6292C</value></field>
<field var='answers'><value>3</value></field>
@ -380,20 +374,20 @@
<section1 topic='Challenge Types' anchor='captcha'>
<section2 topic='Introduction' anchor='captcha-intro'>
<p>Entities MUST address the needs of disabled people and CPU-constrained clients by offering people a reasonable choice of different types of challenges.</p>
<p>Desktop clients running on modern PCs will typically be configured to automatically perform a specified 'SHA-256' Hashcash challenge (see below) whenever it is below a certain level of difficulty, with the result that many people may not even notice challenges most of the time. However, people using CPU-constrained clients (e.g. Web or mobile clients) would notice the performance hit. They might prefer to take a CAPTCHA challenge instead. <note>A CPU-constrained client could ask a faster computer (its server, for example) to perform a Hashcash challenge for it.</note></p>
<p>Desktop clients running on modern PCs will typically be configured to automatically perform a specified 'SHA-256' Hashcash challenge (see below) whenever it is below a certain level of difficulty, with the result that many people may not even notice challenges most of the time. However, people using CPU-constrained clients (e.g. Web or mobile clients) would notice the performance hit. They might prefer to take a CAPTCHA challenge instead. <note>A CPU-constrained client could ask a faster computer (e.g., its server) to perform a Hashcash challenge for it.</note></p>
<p>Visually disabled people using a CPU-constrained client could configure their client to always present them with an audio CAPTCHA challenge.</p>
<p>Most of the challenges below are language sensitive. However, the evaluation of the OCR and Hashcash responses does not depend on the language the client is using.</p>
<p>Challenge types are distinguished by the 'var' attribute of each &lt;field/&gt; element. Several types of challenges are described below. More challenges MAY be documented elsewhere and registered with the &REGISTRAR; (see <link url='#registrar-formtypes'>Field Standardization</link>).</p>
<p>Most of the challenges below are language sensitive. However, the evaluation of the OCR and Hashcash responses does not depend on the language the sender is using.</p>
<p>Challenge types are distinguished by the 'var' attribute of each &lt;field/&gt; element. Several types of challenges are described below. More challenges MAY be documented elsewhere and registered with the XMPP Registrar (see <link url='#registrar-formtypes'>Field Standardization</link>).</p>
</section2>
<section2 topic='SHA-256 Hashcash' anchor='captcha-hashcash'>
<p>The SHA-256 Hashcash challenge is transparent to average PC users. It is indicated when the value of the 'var' attribute is 'SHA-256'. It forces clients to perform CPU-intensive work, making it difficult to send large amounts of SPIM. This significantly reduces SPIM, but alone it will not completely stop SPIM being sent through large collections of 'zombie' computers. <note>The hope is that the extra CPU usage will often be noticed by the owners of the zombie machines, who will be more likely to fix them.</note></p>
<p>The challenger MUST set the 'label' attribute of the &lt;field/&gt; element to a hexadecimal random number containing a configured number of bits (2<span class='super'>20</span> &#8804; label &lt; 2<span class='super'>21</span>, for example).</p>
<p>To pass the test, the client MUST return a text string that starts with the JID the client sent the first stanza to (i.e., the stanza that triggered the challenge). The least significant bits of the SHA-256 hash (see &nistfips180-2;) of the string MUST equal the hexadecimal value specified by the challenger (in the 'label' attribute of the &lt;field/&gt; element). For example, if the 'label' attribute is the 20-bit value 'e03d7' then the following string would be correct:</p>
<p>The SHA-256 Hashcash challenge is transparent to average PC users. It is indicated when the value of the 'var' attribute is 'SHA-256'. It forces clients to perform CPU-intensive work, making it difficult to send large amounts of spim. This significantly reduces spim, but alone it will not completely stop spim being sent through large collections of 'zombie' computers. <note>The hope is that the extra CPU usage will often be noticed by the owners of the zombie machines, who will be more likely to fix them.</note></p>
<p>The challenger MUST set the 'label' attribute of the &lt;field/&gt; element to a hexadecimal random number containing a configured number of bits (e.g., 2<span class='super'>20</span> &#8804; label &lt; 2<span class='super'>21</span>).</p>
<p>To pass the test, the sender MUST return a text string that starts with the JID the sender sent the first stanza to (i.e., the stanza that triggered the challenge). The least significant bits of the SHA-256 hash (see &nistfips180-2;) of the string MUST equal the hexadecimal value specified by the challenger (in the 'label' attribute of the &lt;field/&gt; element). For example, if the 'label' attribute is the 20-bit value 'e03d7' then the following string would be correct:</p>
<code>innocent@victim.com2450F06C173B05E3</code>
<p>Note: When configuring the number of bits to be specified by a challenger in the 'label' attribute values, administrators MUST balance the need to make mass SPIM as difficult as possible, with the inconvenience that may be caused to the users of less powerful computers. (Most clients will be challenged only very occasionally, so the consumption of 70% of a typical desktop CPU for 4 seconds might be considered appropriate.) Administrators SHOULD increment the configured number of bits from time to time to match increases in the performance of typical desktop PCs. If an administrator notices that SPIM robots never attempt the Hashcash challenge, then he SHOULD consider reducing the number of bits, to avoid inconveniencing people unnecessarily.</p>
<p>Note: When configuring the number of bits to be specified by a challenger in the 'label' attribute values, administrators MUST balance the need to make mass spim as difficult as possible, with the inconvenience that may be caused to the users of less powerful computers. (Most clients will be challenged only very occasionally, so the consumption of 70% of a typical desktop CPU for 4 seconds might be considered appropriate.) Administrators SHOULD increment the configured number of bits from time to time to match increases in the performance of typical desktop PCs. If an administrator notices that spim robots never attempt the Hashcash challenge, then he SHOULD consider reducing the number of bits, to avoid inconveniencing people unnecessarily.</p>
</section2>
<section2 topic='CAPTCHAs' anchor='captcha-captcha'>
<p>For those CAPTCHA types where generic instructions are possible (see table below) then the &lt;field/&gt; element SHOULD NOT include a 'label' attribute (the client MUST present generic instructions to its user in the language of its user interface). Otherwise the 'label' attribute SHOULD ask a specific question in the language indicated by the 'xml:lang' attribute of the challenge stanza.</p>
<p>For those CAPTCHA types where generic instructions are possible (see table below) then the &lt;field/&gt; element SHOULD NOT include a 'label' attribute (the client MUST present generic instructions to the sender in the language of its user interface). Otherwise the 'label' attribute SHOULD ask a specific question in the language indicated by the 'xml:lang' attribute of the challenge stanza.</p>
<p>If a media type is specified (see table below) then the &lt;field/&gt; element MUST contain a &lt;media/&gt; element that includes a &lt;uri/&gt; element of that type. Clients that support the CAPTCHA type MUST be able to play or render the specified MIME-types (see table below). They MAY also support other formats. <note>Audio CAPTCHAs typically require challengers to provide at least the 'audio/x-wav' MIME-type (with the PCM codec) because more efficient patent-free formats are often not supported by constrained clients. It is RECOMMENDED that challengers provide more compact formats (like Ogg Speex or MP3) too.</note></p>
<p>The 'type' attribute of the &lt;field/&gt; element SHOULD be 'text-single', 'text-private', or 'text-multi' (if no 'type' is specified, the default is 'text-single'). <note>The 'boolean' and 'list-single' field types would make it trivial for a robot to provide a correct response at least some of the time.</note> The response MUST be provided in the language specified by the 'xml:lang' attribute of the challenge stanza.</p>
<table caption='CAPTCHAs'>
@ -478,9 +472,9 @@
<td>-</td>
</tr>
</table>
<p>* The image portrays random characters that humans can read but OCR software cannot. <note>See PWNtcha &lt;<link url='http://sam.zoy.org/pwntcha/'>http://sam.zoy.org/pwntcha/</link>&gt; for some example OCR CAPTCHA images.</note> To pass the challenge, the user must simply type the characters. The correct answer SHOULD NOT depend on the language specified by the 'xml:lang' attribute of the challenge stanza.</p>
<p>** To pass the challenge, the user must type the answer to the question in the 'label' attribute.</p>
<p>Note: It may be profitable to send SPIM even if less than one percent of CAPTCHA responses are successful. The effectiveness of a CAPTCHA challenge needs to be close to perfect, unless it is used in combination with other anti-SPIM techniques.</p>
<p>* The image portrays random characters that humans can read but OCR software cannot. <note>See PWNtcha &lt;<link url='http://sam.zoy.org/pwntcha/'>http://sam.zoy.org/pwntcha/</link>&gt; for some example OCR CAPTCHA images.</note> To pass the challenge, the sender must simply type the characters. The correct answer SHOULD NOT depend on the language specified by the 'xml:lang' attribute of the challenge stanza.</p>
<p>** To pass the challenge, the sender must type the answer to the question in the 'label' attribute.</p>
<p>Note: It may be profitable to send spim even if less than one percent of CAPTCHA responses are successful. The effectiveness of a CAPTCHA challenge needs to be close to perfect, unless it is used in combination with other anti-spim techniques.</p>
</section2>
</section1>
@ -489,17 +483,17 @@
<!-- It also allows entities to provide a challenge for minimal legacy clients that do not support <cite>Out-of-Band Data</cite> URLs (these don't exist). -->
<p>Note: Robots always attempt the easiest challenge they are offered. So the question MUST be at least as difficult for a robot as the challenge form.</p>
<p>Note: Even if it provides a text question in the &BODY; element, a challenger MUST always provide a challenge form.</p>
<example caption='Client Includes a Legacy Challenge'><![CDATA[
<example caption='Challenger Includes a Legacy Challenge'><![CDATA[
<message from='innocent@victim.com/pda'
to='robot@spimmer.com/zombie'
xml:lang='en'
id='F3A6292C'>
<body>Your messages to me are being blocked. To unblock them,
reply with the color of a stop light followed by 'F3A6292C'.</body>
<challenge xmlns='urn:xmpp:challenge'>
<challenge xmlns='http://www.xmpp.org/extensions/xep-0158.html#ns'>
<x xmlns='jabber:x:data' type='form'>
<field type='hidden' var='FORM_TYPE'>
<value>urn:xmpp:challenge</value>
<value>http://www.xmpp.org/extensions/xep-0158.html#ns</value>
</field>
<field type='hidden' var='from'><value>innocent@victim.com</value></field>
<field type='hidden' var='sid'><value>spam1</value></field>
@ -510,20 +504,20 @@
</message>
]]></example>
<p>Legacy clients respond to the challenger using a &MESSAGE; stanza (not an &IQ;).</p>
<example caption='Legacy Client Responds'><![CDATA[
<example caption='Legacy Sender Responds'><![CDATA[
<message from='robot@spimmer.com/zombie' to='innocent@victim.com/pda'>
<body>red F3A6292C</body>
</message>
]]></example>
<p>The challenger SHOULD treat the stanza as a normal message (instead of as a response to its challenge) if the legacy client either takes too long to submit it or has already responded to the challenge. The challenger MAY treat the response as a normal message even in cases where the challenge became unnecessary while the challenger was waiting for the response.</p>
<p>Otherwise the challenger MUST report the result of the challenge to the legacy client using a &MESSAGE; stanza (not an &IQ;).</p>
<example caption='Client Tells the Legacy Client it Passed'><![CDATA[
<example caption='Challenger Tells Legacy Sender it Passed'><![CDATA[
<message from='innocent@victim.com/pda' to='robot@spimmer.com/zombie'>
<body>Your message was delivered. Your messages
to me are no longer being blocked.</body>
</message>
]]></example>
<example caption='Client Tells the Legacy Client it Failed'><![CDATA[
<example caption='Challenger Tells Legacy Sender it Failed'><![CDATA[
<message type='error'
from='innocent@victim.com/pda'
to='robot@spimmer.com/zombie'>
@ -538,13 +532,13 @@
</section1>
<section1 topic='Discontinuation Policy' anchor='stop'>
<p>It is RECOMMENDED that entities employ other techniques to combat SPIM in addition to those described in this document. For example see &xep0161;.</p>
<p>The expectation is that this protocol will be an important and successful tool for discouraging SPIM. However, much of its success is dependent on the quality of the CAPTCHAs employed by a particular implementation.</p>
<p>It is RECOMMENDED that entities employ other techniques to combat spim in addition to those described in this document (e.g., see <cite>XEP-0161</cite> and &xep0205;).</p>
<p>It is expected that this protocol will be an important and successful tool for discouraging spim. However, much of its success is dependent on the quality of the CAPTCHAs employed by a particular implementation.</p>
<p>The administrator of a challenger MUST discontinue the use of Robot Challenges under the following circumstances:</p>
<ul>
<li>If he realises that the challenger's challenges are largely ineffective in combating SPIM, and that the reduction in SPIM does not compensate for the inconvenience to humans of responding to the challenger's challenges.</li>
<li>If other, <em>more transparent</em>, techniques being employed by the challenger are so successful that challenges are offering only negligible additional protection against SPIM.</li>
<li>If the challenger needs no protection at all because it receives only a negligible amount of SPIM.</li>
<li>If he realises that the challenger's challenges are largely ineffective in combating spim, and that the reduction in spim does not compensate for the inconvenience to humans of responding to the challenger's challenges.</li>
<li>If other, <em>more transparent</em>, techniques being employed by the challenger are so successful that challenges are offering only negligible additional protection against spim.</li>
<li>If the challenger needs no protection at all because it receives only a negligible amount of spim.</li>
</ul>
</section1>
@ -557,19 +551,15 @@
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>Upon approval of this document, the &REGISTRAR; shall register the following protocol namespaces:</p>
<ul>
<li>urn:xmpp:challenge</li>
<li>urn:xmpp:media</li>
</ul>
<section2 topic='Protocol Namespaces' anchor='ns'>
<p>Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-00158.html#ns"; upon advancement of this specification, the &REGISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>
</section2>
<section2 topic='Field Standardization' anchor='registrar-formtypes'>
<section3 topic='challenge FORM_TYPE' anchor='registrar-formtypes-challenge'>
<p>Upon approval of this document, the <cite>XMPP Registrar</cite> shall register the following new FORM_TYPE. Additional fields will be defined in future submissions.</p>
<code><![CDATA[
<form_type>
<name>urn:xmpp:challenge</name>
<name>http://www.xmpp.org/extensions/xep-0158.html#ns</name>
<doc>XEP-0158</doc>
<desc>forms enabling robot challenges</desc>
<field
@ -691,15 +681,14 @@
</section2>
</section1>
<section1 topic='XML Schemas' anchor='schemas'>
<section2 topic='urn:xmpp:challenge' anchor='schemas-challenge'>
<section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:challenge'
xmlns='urn:xmpp:challenge'
targetNamespace='http://www.xmpp.org/extensions/xep-0158.html#ns'
xmlns='http://www.xmpp.org/extensions/xep-0158.html#ns'
elementFormDefault='qualified'>
<xs:element name='challenge'>
@ -712,55 +701,10 @@
</xs:schema>
]]></code>
</section2>
<section2 topic='urn:xmpp:media' anchor='schemas-media'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:media'
xmlns='urn:xmpp:media'
elementFormDefault='qualified'>
<xs:element name='media'>
<xs:complexType>
<xs:sequence>
<xs:element ref='uri' minOccurs='1' maxOccurs='unbounded'/>
<xs:element ref='data' minOccurs='0' maxOccurs='unbounded'/>
</xs:sequence>
<xs:attribute name='height' type='xs:string' use='optional'/>
<xs:attribute name='width' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='uri'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='type' use='required'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='data'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='type' use='required'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
]]></code>
</section2>
</section1>
<section1 topic='Open Issues' anchor='open'>
<p>Another protocol could allow users to edit the challenges their server will make on their behalf. For example, the number of SHA-256 bits, a personal or original question and answer, a picture, a video, or a sound recording... Of course Aunt Tillie would typically only use this feature if she was plagued by SPIM.</p>
<p>Another protocol could allow users to edit the challenges their server will make on their behalf. For example, the number of SHA-256 bits, a personal or original question and answer, a picture, a video, or a sound recording. Of course Aunt Tillie would typically use this feature only if she was plagued by spim.</p>
</section1>
</xep>