- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 07 Jan 2011 20:06:36 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv7238
Modified Files:
Overview.html
Log Message:
update headings for threat case appendix, add additional media threat
for privacy, fix additional validation issues
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.54
retrieving revision 1.55
diff -u -d -r1.54 -r1.55
--- Overview.html 6 Jan 2011 23:39:06 -0000 1.54
+++ Overview.html 7 Jan 2011 20:06:34 -0000 1.55
@@ -198,9 +198,9 @@
<p>To establish trust, a few basic parameters may be used, among which:</p>
<ul>
- <li>identity — ensuring that the privileges are granted to the application from the trusted provider itself, to avoid phishing attacks;</li>
- <li>reputation — if others have reviewed positively an application, the user is more likely to trust it; reputation is itself linked to identity, either as a way to identify the source of the recommandation (e.g. approval from a network operator), or as a way to identify the aggregator of recommendations;</li>
- <li>context — a user is more likely to trust an application that requests permissions that make sense to her use of the said application.</li>
+ <li><dfn>identity</dfn> — ensuring that the privileges are granted to the application from the trusted provider itself, to avoid phishing attacks;</li>
+ <li><dfn>reputation</dfn> — if others have reviewed positively an application, the user is more likely to trust it; reputation is itself linked to identity, either as a way to identify the source of the recommandation (e.g. approval from a network operator), or as a way to identify the aggregator of recommendations;</li>
+ <li><dfn>context</dfn> — a user is more likely to trust an application that requests permissions that make sense to her use of the said application.</li>
</ul>
<p>
@@ -246,7 +246,7 @@
<p>To that end, it should be possible to describe
platform-independent and declarative policies that determine which
APIs can be used from what Web site or application.</p>
- <section id=delgated-authority-story1-rqmts'>
+ <section id='delgated-authority-story1-rqmts'>
<h4>Requirements</h4>
<ul>
<li>The access control policy language MUST be device-independent.</li>
@@ -275,7 +275,7 @@
</p>
<p>This policy needs to be integrity-protected during various points in its life-cycle.</p>
- <section id=delgated-authority-story2-rqmts'>
+ <section id='delgated-authority-story2-rqmts'>
<h4>Requirements</h4>
<ul>
<li>Integrity protection and source authentication of the access
@@ -309,7 +309,7 @@
possible to transfer or share a
representation of user choices across devices at any time.
</p>
- <section id=delgated-authority-story3-rqmts'>
+ <section id='delgated-authority-story3-rqmts'>
<h4>Requirements</h4>
<ul>
<li>Access control policy MUST be able to record user decisions
@@ -388,7 +388,7 @@
and the size of the mobile market increases.
</p>
<section id="premium-rate-abuse">
- <h2>Abuse Case AC1: Premium Rate Abuse</h2>
+ <h2>Premium Rate Abuse</h2>
<p>A widget that seems benign but is actually spewing out
SMSs to premium rate numbers without the user’s
knowledge. This could be modified from an original safe
@@ -403,7 +403,7 @@
</p>
</section> <!-- premium rate Abuse -->
<section id="privacy-breach">
- <h3>Abuse Case AC2: Privacy Breach</h3>
+ <h3>Privacy Breach</h3>
<p>An application that gains access to locations, contacts
and gallery, silently uploading the data in the background
to a site owned by the attacker. This is something that
@@ -425,9 +425,13 @@
the knowledge that their personal data will not leak in
any way.
</p>
+<p>
+Another example is turning on the camera or audio remotely to obtain
+audio, video or photo information without permission.
+</p>
</section> <!-- privacy-breach -->
<section id="integrity-breach">
- <h3>Abuse Case AC3: Integrity Breach</h3>
+ <h3>Integrity Breach</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
@@ -449,7 +453,7 @@
</p>
</section> <!-- integrity-breach -->
<section id="phishing">
- <h3>Abuse Case AC4: Phishing</h3>
+ <h3>Phishing</h3>
<p>
Widgets contain web content making it is easy to duplicate
and masquerade as something legitimate… perhaps a bank?
Received on Friday, 7 January 2011 20:06:37 UTC