date:20091214

I'm not really sure what we're discussing anymore.  Do you have any
new information to add, or are we just going in circles?

On Sun, Dec 13, 2009 at 1:29 PM, Mark S. Miller erig...@google.com wrote:
 On Sun, Dec 13, 2009 at 12:26 PM, Adam Barth w...@adambarth.com wrote:
 On Sun, Dec 13, 2009 at 8:54 AM, Mark S. Miller erig...@google.com
 wrote:
  On Sat, Dec 12, 2009 at 7:17 PM, Adam Barth w...@adambarth.com wrote:
  I agree with Jonas.  It seems unlikely we'll be able to
  design-by-commitee around a difference in security philosophy dating
  back to the 70s.
 
  Hi Adam, the whole point of arguing is to settle controversies. That is
  how
  human knowledge advances. If after 40 years the ACL side has no defenses
  left for its position, ACL advocates should have the good grace to
  concede
  rather than cite the length of the argument as a reason not to
  resolve the
  argument.

 I seriously doubt we're going to advance the state of human knowledge
 by debating this topic on this mailing list.  The scientific community
 is better equipped for that than the standards community.

 AFAICT, the last words on this debate in the scientific literature are the
 Horton paper

Is your position that the academic community has resoundingly decided
that object-capabilities are superior to access control?  That seems
unlikely to me.

[...]

 In either of the first two cases, since you are a member both of the
 scientific community and of this standards committee, if you don't respond
 in the scientific literature, please don't cite merely the lack of response
 in the scientific literature in support of your points.

As I said before, I don't know of any experiments we can run or data
we can measure to settle this issue, which is why science hasn't made
much progress in answering these questions in the past 40 years and
why we won't make much progress resolving them here either.

With respect to your specific question, here's a recent paper of mine
about the dangers of mixing object-capabilities and access control in
a single system, which is exactly what we'd be doing by mixing UniMess
with the same-origin policy:

http://www.adambarth.com/papers/2009/barth-weinberger-song.pdf

In any case, I don't think spamming this list with a bunch of
citations to hundreds of pages of dense prose that no one is going
read will help us make progress.

Adam

Re: [AC/CORS] Proper behavior for user agents who return 'null' Access-Control-Allow-Origin

2009-12-14 Thread Jonas Sicking

On Fri, Dec 11, 2009 at 1:26 AM, Anne van Kesteren ann...@opera.com wrote:
 On Thu, 10 Dec 2009 23:04:37 +0100, Scott Parkerson
 scott.parker...@gmail.com wrote:

 I discovered today that Origin handling for CORS is a bit odd on
 Firefox with respect to requests made from webpages that are loaded
 locally (e.g. loaded from the  file:// access scheme). In this case,
 CORS preflight requests and simple cross-origin requests are sent with
 a null (String) value for Origin. Initially, I thought this was a
 bug and filed it with Mozilla[1]. Jonas pointed out (rightfully) that
 I need to do a better job reading the spec and that a null string
 value is perfectly acceptable.

 However, I noticed that Firefox would fail to issue the follow on
 request after a successful pre-flight request IFF the server returned
 the null string for Access-Control-Allow-Origin, even though that's
 what the user agent originally sent. I added this finding onto the
 same bug (see also). Jonas responded that it appears that the CORS
 spec had changed since that was implemented in Firefox, and that he
 believes the spec may be incorrect. I was able to verify that Firefox
 behaves properly only if the server sends * for
 Access-Control-Allow-Origin.

 I dug a bit through the archives but I couldn't find the rationale for
 the change to the CORS spec. I did notice that the change occurred
 *after* the spec dated 14 Feb 2008[2], or at least the notion that
 null matches nothing disappeared after that time, and that the
 current spec[3] explicitly states in section 6.2 that the Resource
 Sharing Check algorithm ...also functions when the ASCII
 serialization of an origin is the string 'null'.

 --sgp
 cf. smerpology.org

 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=533987
 [2] http://www.w3.org/TR/2008/WD-access-control-20080214
 [3] http://www.w3.org/TR/2009/WD-cors-20090317/

 FWIW, I always intended it to be like this. If the specification ever said
 otherwise that would be an oversight. The February 2008 draft is not really
 comparable with what Firefox implemented by the way. The general idea
 remained the same, but the syntax and specifics changed a lot.

My recollection from the meeting in seattle was that we did not want
to allow this.

In any case, it does seem like a very strange feature to me. Sending

Access-Control-Allow-Origin: null

would then mean essentially, allow access to everyone who I don't
know who it is. I can't think of a situation where this makes sense.

/ Jonas

Next Steps for CORS and Uniform Messaging [Was: Re: CORS versus Uniform Messaging?]


Hi All,

Given the feedback on this thread, my proposal on the next steps are:

1. Mark and/or Tyler prepare a FPWD of UM

2. Anne proactively drive CORS to LCWD

3. Before we begin a CfC to publish #1 and #2 above, some combination  
of the active participants in the CORS and UM discussions (Adam,  
Anne, Jonas, Maciej, Hixie, Tyler, Mark, etc.) create a comparison  
document of CORS and UM (e.g. pros, cons, overlaps, etc.) as Nikunj  
did for the group's two DB specs [1]. This document does not  
necessarily need to be exhaustive. Who can commit to helping with  
this document?


-Art Barstow

[1] http://www.w3.org/2008/webapps/wiki/Database


On Dec 10, 2009, at 1:53 PM, Barstow Art (Nokia-CIC/Boston) wrote:


CORS and Uniform Messaging People,

We are now just a few weeks away from the February 2006 start of what
has now become the CORS spec. In those four years, the model has been
significantly improved, Microsoft deployed XDR, we now have the
Uniform Messaging counter-proposal. Meanwhile, the industry doesn't
have an agreed standard to address the important use cases.

Although we are following the Darwinian model of competing specs with
Web SQL Database and Indexed Database API, I believe I'm not alone in
thinking competing specs in the CORS and UM space is not desirable
and perhaps even harmful.

Ideally, the group would agree on a single model and this could be
achieved by converging CORS + UM, abandoning one model in deference
to the other, etc.

Can we all rally behind a single model?

-Art Barstow


On Dec 4, 2009, at 1:30 PM, ext Mark S. Miller wrote:

We intend that Uniform Messaging be adopted instead of CORS. We  
intend

that those APIs that were expected to utilize CORS (SSE, XBL) instead
utilize Uniform Messaging. As for XHR2, we intend to propose a  
similar

UniformRequest that utilizes Uniform Messaging.

We intend the current proposal, Uniform Messaging Level One, as an
alternative to the pre-flight-less subset of CORS. As for the
remaining Level Two issues gated on pre-flight, perhaps these are  
best

addressed after we settle the SOP restrictions that server-side app
authors may count on, which therefore protocols such as CORS and
Uniform Messaging must uphold.


On Fri, Dec 4, 2009 at 10:04 AM, Arthur Barstow
art.bars...@nokia.com wrote:

Mark, Tyler,

On Nov 23, 2009, at 12:33 PM, ext Tyler Close wrote:


I made some minor edits and formatting improvements to the document
sent out on Friday. The new version is attached. If you read the
prior
version, there's no need to review the new one. If you're just
getting
started, use the attached copy.


Would you please clarify your intent with your Uniform Messaging
proposal
vis-à-vis CORS and your expectation(s) from the Working Group?

-Art Barstow

[widgets] View Modes Media Feature document from Vodafone

During the December 3 widgets call, Marcos mentioned the following  
document by Vodafone regarding View Modes Media Feature spec [VM-MF]:


 http://lab.vodafone.com/w3c/vmmf-20091201.html

Robin - what's the status of this doc?

-Art Barstow

[VM-MF] http://dev.w3.org/2006/waf/widgets-vmmf/

Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

2009-12-14 Thread Jonathan Rees

Comments inline

On Sun, Dec 13, 2009 at 9:15 PM, Maciej Stachowiak m...@apple.com wrote:

 On Dec 13, 2009, at 3:47 PM, Mark S. Miller wrote:

 On Sun, Dec 13, 2009 at 3:19 PM, Maciej Stachowiak m...@apple.com wrote:

 The literature you cited seems to mostly be about whether capability
 systems have various technical flaws, and whether they can be made to do
 various things that ACL-based systems can do. This does not seem to me to
 show that the science is settled on how to design security systems.

The question is whether separating credentials from naming has
advantages over keeping them together. The references talk about
certain kinds of putative advantages that have been proven illusory.
It is true that there may be other advantages that haven't been
articulated or surfaced. Mark is asking for help in understanding what
they are.

 If there are undisputed weaknesses of ACLs compared to capabilities, and
 undisputed refutations of all claimed weaknesses capabilities compared ACLs,
 then what more is needed for the science to be settled?

If the security considerations can't be convincing, then you are
making your judgment of the inadequacy of the capability approach
based on other considerations. I think there is a sincere question as
to what those considerations are.

 Even if that is true with respect to formal security properties (and I
 honestly don't know), it doesn't necessarily show that ACL-based systems are
 always dangerously unsafe, or that the formal differences actually matter in
 practice in a particular case, enough to outweigh any pragmatic
 considerations in the other direction.

Because the trusted computing base can always have flaws, and desired
security policy may be formalized incorrectly, there is *always* risk.
When comparing approaches based on security criteria, you have to ask
which approach has lower risk. When applying other criteria, the
questions are different. This may be a disagreement over goodness,
so we need to work on being transparent about what good means.

 I'm also not sure that this Working Group is an appropriate venue to
 determine the answer to that question in a general way. I don't think most
 of us have the skillset  to review the literature. Beyond that, our goal in
 the Working Group is to do practical security analysis of concrete
 protocols, and if there are flaws, to address them. If there are theoretical
 results that have direct bearing on Working Group deliverables, then the
 best way to provide that information would be to explain how they apply in
 that specific context.

 Fine with me. That's what we were doing before Adam raised the history of
 this controversy as an argument that we should stop.

 One important point to consider is that we are not deploying into a vacuum.
 The Web already pervasively makes use of tokens that are passively passed
 around to identify the agent (I feel a little weird calling these ACLs given
 the specific uses). In particular, the notion of origin is used already to
 control client-side scripting access to the DOM; and cookies are used
 pervasively for persistent login.
 I don't see a clear plan on the table for removing these passive
 identifiers. Removing same-origin policy for scripting would require either
 majorly redesigning scripting APIs or would lead to massive security holes
 in existing sites. As for cookies, it does not seem anyone has a practical
 replacement that allows a user to persistently stay logged into a site. In
 fact, many proposed mechanisms for cross-site communication ultimately
 depend at some point on cookies, including you and Tyler's proposed UM-based
 protocol for cross-site communication without prior arrangement.
 Even if a pure capability-based system is better than a pure ACL-based
 system (and I really have no way to evaluate, except to note that a large
 number of security architectures in widespread production use seem to be on
 some level ACL-based), it's not clear to me that solely pushing capabilities
 is the best way to improve the already existing Web.
 There seem to be two schools of thought that to some extent inform the
 thinking of participants in this discussion:
 1) Try to encourage capability-based mechanisms by not providing anything
 that lets you extend the use of origins and cookies.
 2) Try to build on the model that already exists and that we are likely
 stuck with, and provide practical ways to mitigate its risks.
 I don't see how we are going to settle the disagreement by further mailing
 list debate, because it seems to me that much of it is at the level of
 design philosophy, not provable security properties.

This is a straw man as it does not address the question on the table.
As far as I know, even if current credential-carrying same-origin
requests are being challenged, prohibiting them is in neither the
interest nor the power of the WG, so it's off the table. (Mark may
argue for deprecation, but that in itself will have little effect.)
AFAICT

Re: [widgets] test suite, the width/height attribute

2009-12-14 Thread Marcos Caceres

On Fri, Dec 4, 2009 at 5:04 PM, Cyril Concolato cyril.concol...@enst.fr wrote:
 Dear Widgets-experts,

 While checking some of the tests, I found some unclear processing with
 regards to the width and height attribute of widget element. The spec says:

 If the width attribute is used, then let normalized width be the result of
 applying the rule for parsing a non-negative integer to the value of the
 attribute. If the normalized width is not in error  and greater than 0, then
 let widget width be the value of normalized width. If the width attribute is
 in error, then the user agent must ignore the attribute.

 It explicitely says greater than 0 which means that 0 should not be
 allowed, but the test suite says for c9.wgt that the result should be 0.

Argh. Right.

 This seems inconsistent. On top of that, the spec seems to make the
 distinction between 'null' (when in error) and '0' (not specified). From an
 implementation point of view, I would prefer two cases:
 - specified, not in error, greater than 0, width = the specified value
 - in error or not specified, width = null, empty or 0.
 Actually, I would prefer 0 since then the attribute can be implemented as an
 integer not as a string.

 What do you think ?

Given that a number of UAs have implemented support for getting back
the value 0, I think we should just say greater than or equal to
0.

So:

widget width/height= = Error. value remains null.

widget width/height=  = Error, value remains null.

widget width/height=abc returns 0, value is 0.

widget width/height=100abc returns 100, value is 100.

widget width/height=000100abc returns 100, value is 100.

However, I'm open to just saying return 0 upon error.

More thoughts on this are welcomed from interested parties.

-- 
Marcos Caceres
http://datadriven.com.au

[widgets] Widget Updates PAG recommendations

2009-12-14 Thread Marcos Caceres

FYI... Robin implemented the PAG Recommendations [1] for Widget Updates
in the latest Ed [2]. See below. Work continues and we hope to be ready
to publish next week.

Taking into account the wide variety of information made available to the PAG,
the following recommendations are given:

1. The WebApps Working Group should continue to work on the Widgets 1.0:
Updates Specification

Yay! :)

2. The WebApps Working Group should change the widgetupdate function name to
updateinfo

Function was removed. We don't need it.

3. The WebApps Working Group should change the update element name to
updatedescription

Done.

4. In section 11, the WebApps Working Group should change the sentence that says It is
conceivable that the automatic update model could be subject to a man-in-the-middle-attack...
to say Because it is not self-contained, it is conceivable that the automatic update model
could be subject to a man-in-the-middle attack...

Done.

5. The WebApps Working Group should change all occurrences of

widget.update() to checkForUpdate()

Functions were removed. We don't need them.

6. The WebApps Working Group should change all occurrences of Updating via
widget.update() to Update-checking via checkForUpdate

Function was removed. We don't need it.

7. The WebApps Working Group should change all occurrences of [Uu]pdating strategy
to [Uu]pdate-checking strategy

Occurrences all gone.

Kind regards,
Marcos
[1] http://www.w3.org/2009/03/widgets-pag/pagreport.html
[2] http://dev.w3.org/2006/waf/widgets-updates/

Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

On Mon, Dec 14, 2009 at 5:53 AM, Jonathan Rees j...@creativecommons.org wrote:
 The only complaint I know of regarding UM is that it is so complicated
 to use in practice that it will not be as enabling as CORS

Actually, Tyler's UM protocol requires the user to confirm message 5
to prevent a CSRF attack.  Maciej's CORS version of the protocol
requires no such user confirmation.  I think it's safe to say that
asking the user to confirm security-critical operations is not a good
approach.

 Regarding the idea that UM is unproven or undeployed - I think this is
 a peculiar charge given that object-oriented programming dates from
 1967, and actors date from 1973; and current use of the capability
 pattern, for example in email list validation, shared calendar access
 control, and CSRF defense (Mark can probably provide many other and
 better examples), *is* something we can build on. Ocaps have been
 essentially unchanged for 40 years, with essentially no elaboration or
 revision despite heavy stress testing. AFAIK the academic and
 practical security communities have not converged on any distributed
 (i.e. multilateral) access control system *other* than capabilities.

You're really overstating your case to the point where it's ridiculous.

Adam

Re: Next Steps for CORS and Uniform Messaging [Was: Re: CORS versus Uniform Messaging?]

I'd be happy to help with #3.

Adam


On Mon, Dec 14, 2009 at 3:57 AM, Arthur Barstow art.bars...@nokia.com wrote:
 Hi All,

 Given the feedback on this thread, my proposal on the next steps are:

 1. Mark and/or Tyler prepare a FPWD of UM

 2. Anne proactively drive CORS to LCWD

 3. Before we begin a CfC to publish #1 and #2 above, some combination of the
 active participants in the CORS and UM discussions (Adam, Anne, Jonas,
 Maciej, Hixie, Tyler, Mark, etc.) create a comparison document of CORS and
 UM (e.g. pros, cons, overlaps, etc.) as Nikunj did for the group's two DB
 specs [1]. This document does not necessarily need to be exhaustive. Who can
 commit to helping with this document?

 -Art Barstow

 [1] http://www.w3.org/2008/webapps/wiki/Database


 On Dec 10, 2009, at 1:53 PM, Barstow Art (Nokia-CIC/Boston) wrote:

 CORS and Uniform Messaging People,

 We are now just a few weeks away from the February 2006 start of what
 has now become the CORS spec. In those four years, the model has been
 significantly improved, Microsoft deployed XDR, we now have the
 Uniform Messaging counter-proposal. Meanwhile, the industry doesn't
 have an agreed standard to address the important use cases.

 Although we are following the Darwinian model of competing specs with
 Web SQL Database and Indexed Database API, I believe I'm not alone in
 thinking competing specs in the CORS and UM space is not desirable
 and perhaps even harmful.

 Ideally, the group would agree on a single model and this could be
 achieved by converging CORS + UM, abandoning one model in deference
 to the other, etc.

 Can we all rally behind a single model?

 -Art Barstow


 On Dec 4, 2009, at 1:30 PM, ext Mark S. Miller wrote:

 We intend that Uniform Messaging be adopted instead of CORS. We intend
 that those APIs that were expected to utilize CORS (SSE, XBL) instead
 utilize Uniform Messaging. As for XHR2, we intend to propose a similar
 UniformRequest that utilizes Uniform Messaging.

 We intend the current proposal, Uniform Messaging Level One, as an
 alternative to the pre-flight-less subset of CORS. As for the
 remaining Level Two issues gated on pre-flight, perhaps these are best
 addressed after we settle the SOP restrictions that server-side app
 authors may count on, which therefore protocols such as CORS and
 Uniform Messaging must uphold.


 On Fri, Dec 4, 2009 at 10:04 AM, Arthur Barstow
 art.bars...@nokia.com wrote:

 Mark, Tyler,

 On Nov 23, 2009, at 12:33 PM, ext Tyler Close wrote:

 I made some minor edits and formatting improvements to the document
 sent out on Friday. The new version is attached. If you read the
 prior
 version, there's no need to review the new one. If you're just
 getting
 started, use the attached copy.

 Would you please clarify your intent with your Uniform Messaging
 proposal
 vis-à-vis CORS and your expectation(s) from the Working Group?

 -Art Barstow

Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

On Mon, Dec 14, 2009 at 10:16 AM, Adam Barth w...@adambarth.com wrote:
 On Mon, Dec 14, 2009 at 5:53 AM, Jonathan Rees j...@creativecommons.org 
 wrote:
 The only complaint I know of regarding UM is that it is so complicated
 to use in practice that it will not be as enabling as CORS

 Actually, Tyler's UM protocol requires the user to confirm message 5
 to prevent a CSRF attack.  Maciej's CORS version of the protocol
 requires no such user confirmation.  I think it's safe to say that
 asking the user to confirm security-critical operations is not a good
 approach.

For Ian Hickson's challenge problem, I came up with a design that does
not require any confirmation, or any other user interaction. See:

http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/1232.html

That same design can be used to solve Maciej's challenge problem.

--Tyler

-- 
Waterken News: Capability security on the Web
http://waterken.sourceforge.net/recent.html

Indexed Database API (previously WebSimpleDB) ready for a new WD

2009-12-14 Thread Nikunj R. Mehta


Dear Chairs,

Indexed Database API [1] is ready for a new WD. I have addressed  
various issues reported to the WebApps WG so far. I propose the short  
name indexeddb to replace websimpledb at this time.


I know of one issue reported by Pablo Castro that is not resolved [2]:  
Usability of asynchronous APIs. This discussion needs its own time and  
more study to improve upon the approach currently in the ED.


Thanks,
Nikunj
http://o-micron.blogspot.com

[1] http://dev.w3.org/2006/webapi/WebSimpleDB/
[2] 
http://www.w3.org/mid/f753b2c401114141b426db383c8885e01b9cd...@tk5ex14mbxc126.redmond.corp.microsoft.com

Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

2009-12-14 Thread Maciej Stachowiak



On Dec 14, 2009, at 10:44 AM, Tyler Close wrote:

On Mon, Dec 14, 2009 at 10:16 AM, Adam Barth w...@adambarth.com  
wrote:
On Mon, Dec 14, 2009 at 5:53 AM, Jonathan Rees j...@creativecommons.org 
 wrote:
The only complaint I know of regarding UM is that it is so  
complicated

to use in practice that it will not be as enabling as CORS


Actually, Tyler's UM protocol requires the user to confirm message 5
to prevent a CSRF attack.  Maciej's CORS version of the protocol
requires no such user confirmation.  I think it's safe to say that
asking the user to confirm security-critical operations is not a good
approach.


For Ian Hickson's challenge problem, I came up with a design that does
not require any confirmation, or any other user interaction. See:

http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 
1232.html


That same design can be used to solve Maciej's challenge problem.


I see three ways it wouldn't satisfy the requirements given for my  
CORS example:


1) Fails AJAX UI requirement in the grant phase, since a form post  
is required.


2) The permission grant is intiated and entirely drive by Site B (the  
service consumer). Thus Site A (the service provider in this case) has  
no way to know that the request to grant access is a genuine grant  
from the user.


3) When Site A receives the request from Site B, there is no  
indication of what site initiated the communication (unless the  
request from B is expected to come with an Origin header). How does it  
even know it's supposed to redirect to B? Is site A expecting that  
it's only going to get service requests from B? That would amount to a  
prior bilateral arrangement.


I also note that the protocol you describe there uses cookies (and  
possibly origins, if point 3 is addressed) to bootstrap a shared- 
secret based scheme. As I've mentioned before, CORS would be a useful  
tool for that type of technique. It can allow such bootstrapping  
without having to jump through hoops with form posts, without  
disrupting the user's interaction with a full page load, and without  
necessarily having to put secrets in the URL (since the URL part of  
the request is by far the most likely to leak to the outside world  
inadvertantly.


Regards,
Maciej

Re: Next Steps for CORS and Uniform Messaging [Was: Re: CORS versus Uniform Messaging?]

Hi Art,

Yes, I'm happy to serve as editor for UM, as indicated by #1 below. I
will also contribute to the discussion needed for the CORS vs UM
comparison document for #3 below.

--Tyler

On Mon, Dec 14, 2009 at 3:57 AM, Arthur Barstow art.bars...@nokia.com wrote:
 Hi All,

 Given the feedback on this thread, my proposal on the next steps are:

 1. Mark and/or Tyler prepare a FPWD of UM

 2. Anne proactively drive CORS to LCWD

 3. Before we begin a CfC to publish #1 and #2 above, some combination of the
 active participants in the CORS and UM discussions (Adam, Anne, Jonas,
 Maciej, Hixie, Tyler, Mark, etc.) create a comparison document of CORS and
 UM (e.g. pros, cons, overlaps, etc.) as Nikunj did for the group's two DB
 specs [1]. This document does not necessarily need to be exhaustive. Who can
 commit to helping with this document?

 -Art Barstow

 [1] http://www.w3.org/2008/webapps/wiki/Database


 On Dec 10, 2009, at 1:53 PM, Barstow Art (Nokia-CIC/Boston) wrote:

 CORS and Uniform Messaging People,

 We are now just a few weeks away from the February 2006 start of what
 has now become the CORS spec. In those four years, the model has been
 significantly improved, Microsoft deployed XDR, we now have the
 Uniform Messaging counter-proposal. Meanwhile, the industry doesn't
 have an agreed standard to address the important use cases.

 Although we are following the Darwinian model of competing specs with
 Web SQL Database and Indexed Database API, I believe I'm not alone in
 thinking competing specs in the CORS and UM space is not desirable
 and perhaps even harmful.

 Ideally, the group would agree on a single model and this could be
 achieved by converging CORS + UM, abandoning one model in deference
 to the other, etc.

 Can we all rally behind a single model?

 -Art Barstow


 On Dec 4, 2009, at 1:30 PM, ext Mark S. Miller wrote:

 We intend that Uniform Messaging be adopted instead of CORS. We intend
 that those APIs that were expected to utilize CORS (SSE, XBL) instead
 utilize Uniform Messaging. As for XHR2, we intend to propose a similar
 UniformRequest that utilizes Uniform Messaging.

 We intend the current proposal, Uniform Messaging Level One, as an
 alternative to the pre-flight-less subset of CORS. As for the
 remaining Level Two issues gated on pre-flight, perhaps these are best
 addressed after we settle the SOP restrictions that server-side app
 authors may count on, which therefore protocols such as CORS and
 Uniform Messaging must uphold.


 On Fri, Dec 4, 2009 at 10:04 AM, Arthur Barstow
 art.bars...@nokia.com wrote:

 Mark, Tyler,

 On Nov 23, 2009, at 12:33 PM, ext Tyler Close wrote:

 I made some minor edits and formatting improvements to the document
 sent out on Friday. The new version is attached. If you read the
 prior
 version, there's no need to review the new one. If you're just
 getting
 started, use the attached copy.

 Would you please clarify your intent with your Uniform Messaging
 proposal
 vis-à-vis CORS and your expectation(s) from the Working Group?

 -Art Barstow








-- 
Waterken News: Capability security on the Web
http://waterken.sourceforge.net/recent.html

Re: Wiki for WebApps' Database, Storage, AppCache and related specs

2009-12-14 Thread Nikunj R. Mehta



On Dec 3, 2009, at 10:02 AM, Jeremy Orlow wrote:




Right now, there's a no for atomicity, concurrency-error-free  
operation, etc.  I think this at least deserves a * that explains  
this is only a problem with browsers that have multiple event loops  
and there is a solution that's spec'ed but not implemented.


Fine by me.

I don't have write access to the page, otherwise I'd go ahead and  
fix it.  Can you either give me write access (username jorlow) or do  
it?



I have no idea how this is administered. Apparently, ArtB and  
MikeSmith both have edited the page and so there must be a way for  
others to edit this as well.


Doug/Mike can you help Jeremy with this?

Thanks,
Nikunj
http://o-micron.blogspot.com

Re: CORS versus Uniform Messaging?

2009-12-14 Thread Devdatta


 I also agree with Jonas on these points.  What might make the most
 sense is to let the marketplace decide which model is most useful.
 The most likely outcome (in my mind) is that they are optimized for
 different use cases and will each find their own niche.


I am not sure this is the case. Seems to me that the CORS API is more
powerful than UM (in that stuff that can be done by UM can be done by
CORS). In the end, if W3 pushes out both UM and CORS, why would a
developer use UM ? I imagine most would end up using CORS (even if
they can achieve their goals with UM), just because its easier and
quicker.

Cheers
devdatta

Re: Next Steps for CORS and Uniform Messaging [Was: Re: CORS versus Uniform Messaging?]


On Dec 14, 2009, at 1:17 PM, ext Adam Barth wrote:


I'd be happy to help with #3.

3. Before we begin a CfC to publish #1 and #2 above, some  
combination of the
active participants in the CORS and UM discussions (Adam, Anne,  
Jonas,
Maciej, Hixie, Tyler, Mark, etc.) create a comparison document of  
CORS and
UM (e.g. pros, cons, overlaps, etc.) as Nikunj did for the group's  
two DB
specs [1]. This document does not necessarily need to be  
exhaustive. Who can

commit to helping with this document?



On Dec 14, 2009, at 2:39 PM, ext Tyler Close wrote:


Yes, I'm happy to serve as editor for UM, as indicated by #1 below. I
will also contribute to the discussion needed for the CORS vs UM
comparison document for #3 below.


Thanks Adam and Tyler!

Re #3, assuming a wiki is OK, two options are the new Security wiki  
created a few weeks ago:


 http://www.w3.org/Security/wiki/

Or WebApps wiki:

 http://www.w3.org/2008/webapps/wiki/

Using the Security wiki may help get broader review.

-Art Barstow

CfC: to publish new Working Draft of Indexed Database API; deadline December 21

This is a Call for Consensus (CfC) to publish a new Working Draft of  
the Indexed Database API spec with a new short-name of indexeddb:


 http://dev.w3.org/2006/webapi/WebSimpleDB/

As with all of our CfCs, positive response is preferred and  
encouraged and silence will be assumed to be assent. The deadline for  
comments is 21 December.


Since the comment period ends after the last day to request a 2009  
publication, assuming this CfC is agreed, the new WD will be  
published 6 January 2010.


-Regards, Art Barstow


Begin forwarded message:


From: ext Nikunj R. Mehta nikunj.me...@oracle.com
Date: December 14, 2009 2:26:22 PM EST
To: public-webapps WG public-webapps@w3.org
Subject: Indexed Database API (previously WebSimpleDB) ready for a  
new WD
Archived-At: http://www.w3.org/mid/981D8DE7-B1F3-4075-ACC6- 
a895c6665...@oracle.com


Dear Chairs,

Indexed Database API [1] is ready for a new WD. I have addressed
various issues reported to the WebApps WG so far. I propose the short
name indexeddb to replace websimpledb at this time.

I know of one issue reported by Pablo Castro that is not resolved [2]:
Usability of asynchronous APIs. This discussion needs its own time and
more study to improve upon the approach currently in the ED.

Thanks,
Nikunj
http://o-micron.blogspot.com

[1] http://dev.w3.org/2006/webapi/WebSimpleDB/
[2] http://www.w3.org/mid/ 
f753b2c401114141b426db383c8885e01b9cd...@tk5ex14mbxc126.redmond.corp.m 
icrosoft.com

Re: Wiki for WebApps' Database, Storage, AppCache and related specs


On Dec 14, 2009, at 3:06 PM, ext Nikunj R. Mehta wrote:

On Dec 3, 2009, at 10:02 AM, Jeremy Orlow wrote:

Right now, there's a no for atomicity, concurrency-error-free
operation, etc.  I think this at least deserves a * that explains
this is only a problem with browsers that have multiple event loops
and there is a solution that's spec'ed but not implemented.


Fine by me.

I don't have write access to the page, otherwise I'd go ahead and
fix it.  Can you either give me write access (username jorlow) or do
it?



I have no idea how this is administered. Apparently, ArtB and
MikeSmith both have edited the page and so there must be a way for
others to edit this as well.

Doug/Mike can you help Jeremy with this?


I think the magic has already been done such that Jeremy can edit  
WebApps' wiki. If that is not true, then let's take this off-list and  
make it happen.


-Art Barstow

Re: CORS versus Uniform Messaging?

On Mon, Dec 14, 2009 at 12:29 PM, Devdatta dev.akh...@gmail.com wrote:
 I also agree with Jonas on these points.  What might make the most
 sense is to let the marketplace decide which model is most useful.
 The most likely outcome (in my mind) is that they are optimized for
 different use cases and will each find their own niche.

 I am not sure this is the case. Seems to me that the CORS API is more
 powerful than UM (in that stuff that can be done by UM can be done by
 CORS). In the end, if W3 pushes out both UM and CORS, why would a
 developer use UM ? I imagine most would end up using CORS (even if
 they can achieve their goals with UM), just because its easier and
 quicker.

Imagine the situation where you host untrusted Caja gadgets in your
origin.  In that case, you might want to give the gadgets access to UM
but not to XMLHttpRequest2.

Adam

Re: Next Steps for CORS and Uniform Messaging [Was: Re: CORS versus Uniform Messaging?]

On Mon, Dec 14, 2009 at 12:42 PM, Arthur Barstow art.bars...@nokia.com wrote:
 Thanks Adam and Tyler!

 Re #3, assuming a wiki is OK, two options are the new Security wiki created
 a few weeks ago:

  http://www.w3.org/Security/wiki/

 Or WebApps wiki:

  http://www.w3.org/2008/webapps/wiki/

 Using the Security wiki may help get broader review.

Either seem fine.  The security wiki might be better since we're
already starting to write a number of reference-type articles for that
wiki.  It might eventually grow into a resource for this kind of
thing.

Adam

Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

On Mon, Dec 14, 2009 at 2:13 PM, Tyler Close tyler.cl...@gmail.com wrote:
 For example, the
 User Consent Phase and Grant Phase above could be replaced by a single
 copy-paste operation by the user.

Any design that involves storing confidential information in the
clipboard is insecure because IE lets arbitrary web sites read the
user's clipboard.  You can judge that to be a regrettable choice by
the IE team, but it's just a fact of the world.

Adam

Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

2009-12-14 Thread Maciej Stachowiak



On Dec 14, 2009, at 2:38 PM, Adam Barth wrote:

On Mon, Dec 14, 2009 at 2:13 PM, Tyler Close tyler.cl...@gmail.com  
wrote:

For example, the
User Consent Phase and Grant Phase above could be replaced by a  
single

copy-paste operation by the user.


Any design that involves storing confidential information in the
clipboard is insecure because IE lets arbitrary web sites read the
user's clipboard.  You can judge that to be a regrettable choice by
the IE team, but it's just a fact of the world.


Information that's copied and pasted is highly likely to leak in other  
ways than just the IE paste behavior. For example, if it looks like a  
URL, users are likely to think it's a good idea to do things like  
share the URL with their friends, or to post it to a social bookmark  
site, or to Twitter it, or to send it in email. Even if it does not  
look like a URL, users may think they need to save it (likely  
somewhere insecure) so they don't forget.


Regards,
Maciej

Re: Caching breakout session at TPAC

2009-12-14 Thread Nikunj R. Mehta



On Nov 9, 2009, at 2:09 PM, Mike Wilson wrote:


Hi Nikunj,

I find the subjects of programmable caches and local http servers  
highly interesting for the browser. The below comments and questions  
are from a quick read-through of the supplied links, so please  
excuse any misunderstandings:


Sorry to take so long to respond to you. I was swamped with other work  
and only now am beginning to respond to DataCache comments. Hope you  
will accept my apologies.




1) API orthogonality
The spec invents yet another caching mechanism and storage area.  
Have you evaluated the possibilities to build the suggested  
functionality by enhancing and combining existing APIs and features  
such as the regular HTTP cache, AppCache, localStorage, etc?


I have considered evolving AppCache to supporting DataCache. The API  
and the specified behavior are written with AppCache as the model. I  
also know that many have asked to further integrate DataCache with  
AppCache and am open to suggestions about this.




2) Data cache naming
Your examples mention data in the cache such as images and blog  
posts. But, the cache would work as well for application code  
resources such as script files, wouldn't it?
If so, would it be better to name the cache along the lines of its  
programmability or flexibility, rather than Data?


Certainly it is possible to cache resources you identify. However, I  
do think that it should be possible to think of the proposed behavior  
as an extension of the caching capabilities of the browser.  
Programmability is key to this approach and perhaps that makes for a  
better name. I don't know that will address all concerns about naming,  
though.




3) Specification naming wrt Embedded Local Servers
I find the local servers to be somewhat on the border-line of the  
topic of data caches, which seems to be confirmed by the  
specification's section headings:

  4. Programmable HTTP Processing
4.2 Data Caches
4.3 Embedded Local Server
Would it be more appropriate to name the spec Programmable HTTP  
Processing, or to move the local server to its own spec?


You are pointing out something I have suspected for a while. There are  
two ways in which interception can be performed:


1. Based on transient registrations made through the DOM
2. Based on permanent registrations made through an API with  
persistent effects


It should be very efficiently possible to check whether interception  
is required for any given request. Given the granularity that is  
required to determine this and my experience that interception is  
required only on certain resources that are in the programmable cache,  
I thought of combining the two.


I am open to picking a better name any day.



4) Cache groups
It took me a little time to grok the meaning of data caches and data  
cache groups, and my current understanding is that a data cache  
group is really a versioned cache, where the versions correspond  
to specific data cache instances in the spec. I think it may be  
better to instead talk about one cache with many versions, as this  
concept is probably more known to readers.


This concept exists in HTML5 with AppCache groups. If you are familiar  
with that one, the terminology would be easy to grasp.




5) Explicit and event-loopy API design
I see that you have taken great care to make an API that allows to  
have full control over concurrent cache state changes, through event- 
loopy transaction callbacks and explicit cache upgrades (swap).  
Your example (below) for adding a new uri to the cache first has a  
transaction callback that runs the capturing at a suitable time, but  
which doesn't result in the current cache being updated. Instead  
another callback, an onready event handler, needs to be added  
where the updated cache is explicitly swapped in:

document.body.addEventListener('onready', function(event) {
  event.cache.swapCache();
  ... // take advantage of the new stuff in the cache
});
cache.transaction(function(txn) {
  txn.capture(uri);
  txn.finish();
});
I think I understand your motivations on wanting to offer fine- 
grained control like this, but do you have any thoughts on the above  
getting a bit verbose for simple use-cases?


Good question. The API does require multiple steps to accomplish the  
goal of add a representation to the cache and then make that  
representation available to applications. The notion of transactions  
is necessary because it may be inappropriate to make some  
representations available but not others that are necessary for an  
application to function correctly. On the other hand, the use case of  
adding a single resource is interesting enough that we could special  
case it.


Perhaps,

cache.immediate(uri)

might be a nicer way of doing what the above code intends to do anyway.



6) Transaction API
I haven't followed the discussions on WebStorage/WebDatabase/ 
WebSimpleDB lately, but is the transaction style in Data Cache  
adhering to

Re: Next Steps for CORS and Uniform Messaging [Was: Re: CORS versus Uniform Messaging?]

2009-12-14 Thread Mark S. Miller

Hi Arthur, I'm happy to help Tyler with #1 and to help with #3. Thanks.

On Mon, Dec 14, 2009 at 3:57 AM, Arthur Barstow art.bars...@nokia.comwrote:

 Hi All,

 Given the feedback on this thread, my proposal on the next steps are:

 1. Mark and/or Tyler prepare a FPWD of UM

 2. Anne proactively drive CORS to LCWD

 3. Before we begin a CfC to publish #1 and #2 above, some combination of
 the active participants in the CORS and UM discussions (Adam, Anne, Jonas,
 Maciej, Hixie, Tyler, Mark, etc.) create a comparison document of CORS and
 UM (e.g. pros, cons, overlaps, etc.) as Nikunj did for the group's two DB
 specs [1]. This document does not necessarily need to be exhaustive. Who can
 commit to helping with this document?

 -Art Barstow

 [1] http://www.w3.org/2008/webapps/wiki/Database


 On Dec 10, 2009, at 1:53 PM, Barstow Art (Nokia-CIC/Boston) wrote:

  CORS and Uniform Messaging People,

 We are now just a few weeks away from the February 2006 start of what
 has now become the CORS spec. In those four years, the model has been
 significantly improved, Microsoft deployed XDR, we now have the
 Uniform Messaging counter-proposal. Meanwhile, the industry doesn't
 have an agreed standard to address the important use cases.

 Although we are following the Darwinian model of competing specs with
 Web SQL Database and Indexed Database API, I believe I'm not alone in
 thinking competing specs in the CORS and UM space is not desirable
 and perhaps even harmful.

 Ideally, the group would agree on a single model and this could be
 achieved by converging CORS + UM, abandoning one model in deference
 to the other, etc.

 Can we all rally behind a single model?

 -Art Barstow


 On Dec 4, 2009, at 1:30 PM, ext Mark S. Miller wrote:

  We intend that Uniform Messaging be adopted instead of CORS. We intend
 that those APIs that were expected to utilize CORS (SSE, XBL) instead
 utilize Uniform Messaging. As for XHR2, we intend to propose a similar
 UniformRequest that utilizes Uniform Messaging.

 We intend the current proposal, Uniform Messaging Level One, as an
 alternative to the pre-flight-less subset of CORS. As for the
 remaining Level Two issues gated on pre-flight, perhaps these are best
 addressed after we settle the SOP restrictions that server-side app
 authors may count on, which therefore protocols such as CORS and
 Uniform Messaging must uphold.


 On Fri, Dec 4, 2009 at 10:04 AM, Arthur Barstow
 art.bars...@nokia.com wrote:

 Mark, Tyler,

 On Nov 23, 2009, at 12:33 PM, ext Tyler Close wrote:

  I made some minor edits and formatting improvements to the document
 sent out on Friday. The new version is attached. If you read the
 prior
 version, there's no need to review the new one. If you're just
 getting
 started, use the attached copy.


 Would you please clarify your intent with your Uniform Messaging
 proposal
 vis-à-vis CORS and your expectation(s) from the Working Group?

 -Art Barstow








-- 
   Cheers,
   --MarkM

Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

On Mon, Dec 14, 2009 at 2:38 PM, Adam Barth w...@adambarth.com wrote:
 On Mon, Dec 14, 2009 at 2:13 PM, Tyler Close tyler.cl...@gmail.com wrote:
 For example, the
 User Consent Phase and Grant Phase above could be replaced by a single
 copy-paste operation by the user.

 Any design that involves storing confidential information in the
 clipboard is insecure because IE lets arbitrary web sites read the
 user's clipboard.  You can judge that to be a regrettable choice by
 the IE team, but it's just a fact of the world.

And so we use the alternate, no-copy-paste design on IE while waiting
for a better world; one in which users can safely copy data between
web pages.

I imagine many passwords and other PII are made vulnerable by IE's
clipboard policy.

--Tyler

-- 
Waterken News: Capability security on the Web
http://waterken.sourceforge.net/recent.html

Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

On Mon, Dec 14, 2009 at 3:04 PM, Maciej Stachowiak m...@apple.com wrote:

 On Dec 14, 2009, at 2:38 PM, Adam Barth wrote:

 On Mon, Dec 14, 2009 at 2:13 PM, Tyler Close tyler.cl...@gmail.com
 wrote:

 For example, the
 User Consent Phase and Grant Phase above could be replaced by a single
 copy-paste operation by the user.

 Any design that involves storing confidential information in the
 clipboard is insecure because IE lets arbitrary web sites read the
 user's clipboard.  You can judge that to be a regrettable choice by
 the IE team, but it's just a fact of the world.

 Information that's copied and pasted is highly likely to leak in other ways
 than just the IE paste behavior. For example, if it looks like a URL, users
 are likely to think it's a good idea to do things like share the URL with
 their friends, or to post it to a social bookmark site, or to Twitter it, or
 to send it in email. Even if it does not look like a URL, users may think
 they need to save it (likely somewhere insecure) so they don't forget.

I think the user would only be tempted to post the URL to the world if
the returned representation was interesting to talk about. That
doesn't need to be the case.

In any case, like I said earlier, if you think copy-paste is evil,
I've provided alternate designs that avoid it.

--Tyler

-- 
Waterken News: Capability security on the Web
http://waterken.sourceforge.net/recent.html

Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)