2009/dap/docs policy-requirements-proposal.html,1.1,1.2

Update of /sources/public/2009/dap/docs
In directory hutz:/tmp/cvs-serv29609

Modified Files:
	policy-requirements-proposal.html 
Log Message:
Update section 4.1 text, and fix phishing section 5.4 as noted by
Claes, http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0053.html


Index: policy-requirements-proposal.html
===================================================================
RCS file: /sources/public/2009/dap/docs/policy-requirements-proposal.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- policy-requirements-proposal.html	14 Aug 2010 00:49:38 -0000	1.1
+++ policy-requirements-proposal.html	17 Aug 2010 18:53:14 -0000	1.2
@@ -288,7 +288,7 @@
       <h3>Delegated Authority</h3>
       <section id='delegated-authority-case-overview'>
         <h4>Use Case Overview</h4>
-        <p>The enterprise Managed Device API use case includes the use of
+        <p>The Delegated Authority Device API use case includes the use of
         explicit and interoperable policy definitions to control the use of
         an extensive set of APIs, save and unsafe.  Such rules may be used
         in the case of a trusted widget or the web case with clients that
@@ -596,24 +596,32 @@
         </section> <!-- integrity-breach -->
         <section id="phishing">
           <h3>Abuse Case AC4: Phishing</h3>
-          <p>A widget that replaces the voicemail number with a
-          premium rate number instead? There are number of reasons
-          why an attacker would want to breach the integrity of
-          the device. Simply changing the telephone number of the
-          voicemail that is stored on the device could be enough
-          to make an attacker a lot of money. Users usually have a
-          shortcut key to their voicemail and may not notice for a
-          long time that anything is wrong. A more sinister use
-          could be to plant evidence on a device. Pictures, files
-          and even criminal contacts could potentially be
-          anonymously planted all without the user's consent or
-          knowledge. Proving innocence could suddenly become very
-          difficult. 
-          There are also a number of reasons why somebody would want to steal
-          data. The contents of corporate e-mails would be very
-          interesting to a competitor, as would sabotaging data
-          stored in spreadsheets and presentations on the target
-          phone. 
+          <p>
+            Widgets contain web content making it is easy to duplicate
+            and masquerade as something legitimate… perhaps a bank? 
+          </p>
+          <p> 
+            In January 2010, Google removed a number of applications
+            from the Android Market which were supposed to be banking
+            applications for a number of different banks worldwide. It
+            is unclear whether these applications were intentional
+            phishing applications. The removal was based on a breach
+            of terms and conditions surrounding copyright. The episode
+            however highlighted the phishing potential. Widgets
+            contain web content, therefore it is very easy to
+            duplicate the look and feel of something that  the user
+            trusts and proceed to abuse that trust either by stealing
+            credentials or by manipulating money transfers. 
+          </p>
+          <p>
+            These are of course just examples to consider in relation to how we
+            would manage the policies for device APIs and are of course not
+            exhaustive. Alongside the device-API specific examples
+            above, we still 
+             need to consider traditional web threats which pose a
+            significant risk 
+and lots of other types of attack which should be considered in a 
+ formal threat model. 
           </p>
         </section> <!-- phishing -->
       </section> <!-- threats -->

Received on Tuesday, 17 August 2010 18:53:18 UTC