Hi,
Reliably identified Websites can send and receive SMS except to
premium rate numbers.
There seems to be no worldwide pattern to recognize the premium
numbers based on the number itself, this could be some network
operators service or something similar IP-geolocation databases. The
policy would be very looooong if we would put all the worldwide
available premium numbers into it.
Therefore this use case is not fully doable out of the box.
However, BONDI allows to (reliably?) identify websites and allows to
control sending and receiving SMS.
The weather.example.com Widget can connect to weather.example.com
without notifying the user, except when roaming.
I am not sure what " weather.example.com Widget".
I assume it is the widget that was downloaded from
weather.example.com.
The BONDI policy format would encode this e.g. like this:
<policy-set combine="deny-overrides">
<policy description="">
<target>
<subject>
<subject-match attr="class" match="website" func="equal"/>
<subject-match attr="uri.host" match="weather.example.com"
func="equal"/>
</subject>
<subject>
<subject-match attr="class" match="widget" func="equal"/>
<subject-match attr="install-uri.host"
match="weather.example.com" func="equal"/>
</subject> </target>
<rule effect="deny">
<condition combine="or">
<environment-match attr="roaming" func="equal">international</
resource-match>
</condition>
</rule>
<rule effect="permit"> //this seems not needed
<condition combine="or">
<environment-match attr="roaming" func="equal">national</
resource-match>
</condition>
</rule> </policy>
</policy-set>
Thanks,
Marcin
P.S. I think I will not write more policies until there is some use
case that is not doable (at least in my opinion. I may be wrong.)
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: [email protected]
-----Original Message-----
From: Frederick Hirsch [mailto:[email protected]]
Sent: Friday, November 20, 2009 3:29 PM
To: ext Jeremy Orlow
Cc: Frederick Hirsch; Marcin Hanclik; Maciej Stachowiak; Jonas
Sicking; Adam Barth; Robin Berjon; [email protected]; public-
webapps WG
Subject: Re: Security evaluation of an example DAP policy
Jeremy
Thanks. I want to make sure I understand the concerns.
I guess the question is whether one can bake all the security in that
is needed for various (possibly conflicting) use cases, including
those that do not presume user interaction. An argument for policy is
to decouple the mechanism from the decision criteria to get that
flexibility, while making sure the mechanism is secure. On the other
side I hear the concern that the mechanism cannot be as secure.
I note that the policy requirements document includes some use cases
Paddy contributed in an earlier email:
http://dev.w3.org/2009/dap/policy-reqs/#use-cases
So for example, how does one "bake in" these:
The weather.example.com Widget can connect to weather.example.com
without notifying the user, except when roaming.
Reliably identified Websites can send and receive SMS except to
premium rate numbers.
Do we need to go into more detail on these two (as examples)?
regards, Frederick
Frederick Hirsch
Nokia
On Nov 20, 2009, at 9:15 AM, ext Jeremy Orlow wrote:
These are reasons, but I think the greatest cause of our concern is
that we have not seen any examples of how policies can provide the
same level of security that baking security into the API from the
beginning can provide.
All too often the policy based approaches fall back on either asking
the user or simply denying access--both of which are not viable
solutions in most cases within the browser. If we take security
into account when designing the APIs we can often find creative
approaches that satisfy all of the requirements/use-cases while
providing an API that can be on by default.
On Fri, Nov 20, 2009 at 1:53 PM, Frederick Hirsch <[email protected]
wrote:
My understanding from reading the thread is that the concern is with
complexity, increased attack surface due to mechanisms that can be
used in unanticipated ways or misconfigured, and management issues.
Thus though policy can state a simple approach, I'm not sure the
above concerns are addressed by that expression.
I think we need to work through the use cases, both for those that
do need a policy language and those that do not, then consider if
APIs have various methods as Robin suggested, or otherwise how it
will all fit together.
regards, Frederick (not as chair)
Frederick Hirsch
Nokia
On Nov 19, 2009, at 7:49 PM, ext Marcin Hanclik wrote:
Hi Jonas, Maciej,
It seems that the policy that you would accept would be:
<policy-set combine="deny-overrides">
<policy description="Default Policy for websites. Simply denying all
API that are covered by some device capability:) ">
<target>
<subject>
<subject-match attr="class" match="website" func="equal"/>
</subject>
</target>
<rule effect="deny">
<condition>
<resource-match attr="device-cap" func="regexp">/.+/</resource-
match>
</condition>
</rule>
</policy>
</policy-set>
Let's see how DAP will evolve then.
Thanks,
Marcin
________________________________________
From: Maciej Stachowiak [[email protected]]
Sent: Friday, November 20, 2009 1:26 AM
To: Jonas Sicking
Cc: Marcin Hanclik; Adam Barth; Robin Berjon; [email protected]
; public-webapps WG
Subject: Re: Security evaluation of an example DAP policy
On Nov 19, 2009, at 4:23 PM, Jonas Sicking wrote:
On Thu, Nov 19, 2009 at 4:07 PM, Marcin Hanclik
<[email protected]> wrote:
Hi Adam,
I think that
<resource-match attr="param:name" func="regexp">/(C|c):\\(.+)\\(.+)/
<resource-match />
should be
<resource-match attr="param:name" func="regexp">/(C|c):\\([^\\]+)\\.
+/<resource-match />
up to any further bug in the RE.
Sorry, my problem.
Anyway, the general comment is that the use case is under control
based on the current spec.
For what it's worth, I think any API that opened a dialog asking the
user "Do you want to give website X access to directory Y in your
file
system" would not be an API we'd be willing to implement in firefox.
I.e. our security policy would be to always deny such a request (thus
making implementing the API useless for our users).
Ditto for Safari.
- Maciej
________________________________________
Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
www.access-company.com
CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that
is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure,
copying or distribution of the information by anyone else is
strictly prohibited.
If you have received this document in error, please notify us
promptly by responding to this e-mail. Thank you.
________________________________________
Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
www.access-company.com
CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that
is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure,
copying or distribution of the information by anyone else is
strictly prohibited.
If you have received this document in error, please notify us
promptly by responding to this e-mail. Thank you.
