Re: The most basic File API use case
Peter O. Ussuri wrote: Hello! This is in reply to Eric Uhrhane's message, and other discussions [1] Various File API use cases discussed in this mailing list are designed to illustrate some kind of expansion of existing browser capabilities, with ensuing discussion of potential new security risks. However, there is one quite general use case that is very unlikely to introduce any additional security issues and that is easy for everybody to understand (and for browser vendors to implement). I would like to suggest a "Group 0" File API use case, in Eric's terminology. Basically, there should be a way to do in JavaScript everything most browsers currently in use (including IE6) do without server round-trip. In the most general terms, it is currently possible, and relatively secure, to let the user select a file for upload, upload it to the server, do arbitrary processing, and then download/save the (new/modified) file back onto the user's local file system. The current File API draft lets a web app to read the file, but there seems to be no easy way for a web app to construct an arbitrary binary file and trigger a SaveAs/download dialog, with the file name suggested by the app. I agree with this use case being a logical next step. The main idea here is to allow a "rich" client to be at least as functional as a "poor" html+server app is (w/o any dynamic client-side scripting). By recognizing this most basic use case, it will probably be easier to agree on the first iteration of FileWriter api, as most security issues have already been fleshed out. Required api is quite simple to define and implement: a file builder (similar to BlobBuilder in Google Gears), and a "SaveAs" method that takes "pre-built" files (blobs). And later this basic API can be extended to introduce an event model and cover more advanced use cases. +1 -- I think this identifies immediate next steps well, along with Eric Uhrhane's groupings. As far as Group 0 goes, I agree and think we'll need: 1. A script initiated SaveAs mechanism. 2. Something like BlobBuilder (as you point out). Next steps can evolve from these. -- A*
RE: [widgets] LCWD#3 comments (3)
Hi Marcos, All,
Just a couple of comments about the consistency of the W3C specifications:
XHR (whose editor is also from Opera) says:
"The term [...] valid MIME type [are] ..is.. defined by the HTML 5
specification. [HTML5]"
HTML5 says:
"A string is a valid MIME type if it matches the media-type rule defined in
section 3.7 "Media Types" of RFC 2616. [HTTP]"
RFC2616 [1]:
media-type = type "/" subtype *( ";" parameter )
type = token
subtype= token
So the same term of the valid MIME type once refers to RFC2046 in P&C, another
time to RFC2616 in XHR (via HTML5).
The above comments are not to be interpreted as part of my P&C LCWD#3 review.
Thanks,
Marcin
[1] http://tools.ietf.org/html/rfc2616#section-3.7
From: Marcos Caceres [marc...@opera.com]
Sent: Friday, November 20, 2009 9:38 PM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [widgets] LCWD#3 comments (3)
On Nov 20, 2009, at 8:24 PM, Marcin Hanclik wrote:
> Hi Marcos,
>
>>> I don't know, maybe parameter allows spaces? but yeah, that first
>>> space after "Content-type:" seems non-conforming.
> RFC2045:
>
> parameter := attribute "=" value
>
> attribute := token
> ; Matching of attributes
> ; is ALWAYS case-insensitive.
>
> value := token / quoted-string
>
> token := 1* or tspecials>
>
> tspecials := "(" / ")" / "<" / ">" / "@" /
> "," / ";" / ":" / "\" / <">
> "/" / "[" / "]" / "?" / "="
> ; Must be in quoted-string,
> ; to use within parameter values
>
> token excludes SPACE.
>
> We have to live with that, I think.
>
> RFC4288:
> "There is no defined syntax for parameter values."
>
> However, RFC2045 says also:
> "By itself, however, this grammar is incomplete."
> and refers to RFC822 that in turn talks about folding and unfolding
> (white-spaces, multiple lines etc.).
> It seems to be a legacy stuff from the "mail industry", therefore we
> will probably not fix it here.
LOL, this stuff truly is turtles all the way down! :)
>
> Thanks,
> Marcin
>
>
> From: marcosscace...@gmail.com [marcosscace...@gmail.com] On Behalf
> Of Marcos Caceres [marc...@opera.com]
> Sent: Friday, November 20, 2009 7:31 PM
> To: Marcin Hanclik
> Cc: WebApps WG
> Subject: Re: [widgets] LCWD#3 comments (3)
>
> On Fri, Nov 20, 2009 at 11:36 AM, Marcin Hanclik
> wrote:
>> Hi Marcos,
>>
>>
>>
>> It seems I found another problem in RFC.
>>
>>
>>
>> 7.4
>>
>> valid-MIME-type = type "/" subtype *(";" parameter)
>>
>> and we refer to RFC2045 that says:
>>
>> [1] content := "Content-Type" ":" type "/" subtype
>>
>>*(";" parameter)
>>
>>
>>
>> Then, RFC2045 gives examples like:
>>
>> [2] Content-type: text/plain; charset=us-ascii
>>
>>
>>
>> The problem is about the spaces.
>>
>> As for me [2] does not match [1].
>
> I don't know, maybe parameter allows spaces? but yeah, that first
> space after "Content-type:" seems non-conforming.
>
>>
>> Anyway, it seems I can live with that issue, since it seems to
>> affect more
>> than just P&C J.
>>
>
> Me too. Lets get some implementation feedback.
>
>> Therefore, for the purposes of my LC comments, with 99.99%
>> certainty I will
>> be satisfied with your response.
>
> Yippy! :D
>
> --
> Marcos Caceres
> http://datadriven.com.au
>
>
>
> 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.
[widgets] FW: [whatwg] FYI: Mozilla's Resource Packages
fyi From: whatwg-boun...@lists.whatwg.org [whatwg-boun...@lists.whatwg.org] On Behalf Of Anthony Bryan [anthonybr...@gmail.com] Sent: Friday, November 20, 2009 11:18 PM To: wha...@lists.whatwg.org Subject: [whatwg] FYI: Mozilla's Resource Packages More info at http://limi.net/articles/resource-packages/ and discussion at http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/31779262c6b05205 and a few responses on the HTTPbis list. Making browsers faster: Resource Packages A proposal to make downloading web page resources faster in all browsers. Introduction & Rationale What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site — CSS, JS, images, anything else — in a single HTTP request at the start of the first visit to the page? This is what Resource Package support in browsers will let you do. Implementation While Zip files do not have not the most elegant or efficient packing format out there, they have the following very desirable traits: * Easily available reference implementations. * Can be unpacked even in partial state — which means that we can stream the file, and put CSS and JavaScript first in the archive, and they will unpacked and made available before the entire file has been downloaded. * Excellent toolchain support, zip/unzip is available on all major platforms, so it’s easy for web developers to use. We propose this markup to signal a zipped resource package: -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads 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.
The most basic File API use case
Hello! This is in reply to Eric Uhrhane's message, and other discussions [1] Various File API use cases discussed in this mailing list are designed to illustrate some kind of expansion of existing browser capabilities, with ensuing discussion of potential new security risks. However, there is one quite general use case that is very unlikely to introduce any additional security issues and that is easy for everybody to understand (and for browser vendors to implement). I would like to suggest a "Group 0" File API use case, in Eric's terminology. Basically, there should be a way to do in JavaScript everything most browsers currently in use (including IE6) do without server round-trip. In the most general terms, it is currently possible, and relatively secure, to let the user select a file for upload, upload it to the server, do arbitrary processing, and then download/save the (new/modified) file back onto the user's local file system. The current File API draft lets a web app to read the file, but there seems to be no easy way for a web app to construct an arbitrary binary file and trigger a SaveAs/download dialog, with the file name suggested by the app. The main idea here is to allow a "rich" client to be at least as functional as a "poor" html+server app is (w/o any dynamic client-side scripting). By recognizing this most basic use case, it will probably be easier to agree on the first iteration of FileWriter api, as most security issues have already been fleshed out. Required api is quite simple to define and implement: a file builder (similar to BlobBuilder in Google Gears), and a "SaveAs" method that takes "pre-built" files (blobs). And later this basic API can be extended to introduce an event model and cover more advanced use cases. Peter O. [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0424.html
RE: Security evaluation of an example DAP policy
Hi Richard, I just comment on the non-legal part. The numbering schemes are the headache of the telco industry and I assume W3C will not help too much, but who knows. >>> >>The weather.example.com Widget can connect to weather.example.com >>> >>without notifying the user, except when roaming. >>How do we cover the additional 113 million+ domain names (and x number >>of subdomains) on the web via a policy such as this? Is that a blanket >>'deny all' and a fall back to user prompting for those 113 million web >>sites not explictly included in a policy document? Most importantly from >>the previous questions, does domain-based policy then work in the web >>context? If a policy covers 10,000 domains (or, let's say, 1 million >>domains) is the ability to reach 1% of web content enough incentive to >>provide a web policy? This case is about widgets, therefore WARP-like + DigSig model works. Additionally BONDI adds the following subject attributes: install-uri id version distributor-key-cn distributor-key -fingerprint distributor-key-root-cn distributor-key-root-fingerprint author-key-cn author-key -fingerprint author-key-root-cn author-key-root-fingerprint widget-attr:name If we would extend the problem to websites, then I think that the solution is already in place in the Web and in BONDI. It is based on X.500, X.509, root certificates and the tree-(or graph-?)structured trust model. Specifically in BONDI A&S we have subject attributes like "key-root-cn" and "sign-schema". 'sign-schema="tls"' says: "The page was fetched using HTTPS and the browser has verified that the site certificate’s Common Name matches the host that the page was fetched from, and it has already applied its own policies regarding whether the root certificate is in an acceptable trust domain." The pages served over plain http could be blocked from accessing DAPI. Thanks, Marcin From: richard.tibb...@orange-ftgroup.com [richard.tibb...@orange-ftgroup.com] Sent: Friday, November 20, 2009 7:30 PM To: Marcin Hanclik; frederick.hir...@nokia.com; jor...@chromium.org Cc: m...@apple.com; jo...@sicking.cc; w...@adambarth.com; ro...@berjon.com; public-device-a...@w3.org; public-webapps@w3.org Subject: RE: Security evaluation of an example DAP policy Hi, > >>The weather.example.com Widget can connect to weather.example.com > >>without notifying the user, except when roaming. How do we cover the additional 113 million+ domain names (and x number of subdomains) on the web via a policy such as this? Is that a blanket 'deny all' and a fall back to user prompting for those 113 million web sites not explictly included in a policy document? Most importantly from the previous questions, does domain-based policy then work in the web context? If a policy covers 10,000 domains (or, let's say, 1 million domains) is the ability to reach 1% of web content enough incentive to provide a web policy? > >>Reliably identified Websites can send and receive SMS except to > >>premium rate numbers. If policy is interchangeable, and we have e.g. 100 policy providers, how does the developer have confidence that each policy provider has selected the same set of premium phone numbers to block? Can such a policy be intentionally extended to prohibit non-threatening use cases at the expense of the user? If this is such an integral security issue, it should be possible to bake it in to the API itself? If it is not possible to bake it in, and the security decision is subjective based on whoever is providing a policy, then is this something web developers will be able to reliably and consistently code against? What is the legal responsibility (for data loss / misuse / corruption / etc) that policy providers take on by 'guaranteeing the web'? Is a policy provider liable for actions that it decides on behalf of a user? Over e.g. 1 million web domains? I appreciate the input of solid use cases such as this for discussion. I look forward to a use case that shows a clear reason for policy in a web context considering the massively distributed and centrally unmanageable nature of the web world - one of the tenants of its design that arguably continues to make it so successful. Kind Regards, Richard > -Original Message- > From: public-device-apis-requ...@w3.org > [mailto:public-device-apis-requ...@w3.org] On Behalf Of Marcin Hanclik > Sent: 20 November 2009 15:13 > To: Frederick Hirsch; ext Jeremy Orlow > Cc: Maciej Stachowiak; Jonas Sicking; Adam Barth; Robin > Berjon; public-device-a...@w3.org; public-webapps WG > Subject: RE: Security evaluation of an example DAP policy > > 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 long > if we wou
Re: [widgets] LCWD#3 comments (3)
On Nov 20, 2009, at 8:24 PM, Marcin Hanclik > wrote:
Hi Marcos,
I don't know, maybe parameter allows spaces? but yeah, that first
space after "Content-type:" seems non-conforming.
RFC2045:
parameter := attribute "=" value
attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.
value := token / quoted-string
token := 1*
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
token excludes SPACE.
We have to live with that, I think.
RFC4288:
"There is no defined syntax for parameter values."
However, RFC2045 says also:
"By itself, however, this grammar is incomplete."
and refers to RFC822 that in turn talks about folding and unfolding
(white-spaces, multiple lines etc.).
It seems to be a legacy stuff from the "mail industry", therefore we
will probably not fix it here.
LOL, this stuff truly is turtles all the way down! :)
Thanks,
Marcin
From: marcosscace...@gmail.com [marcosscace...@gmail.com] On Behalf
Of Marcos Caceres [marc...@opera.com]
Sent: Friday, November 20, 2009 7:31 PM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [widgets] LCWD#3 comments (3)
On Fri, Nov 20, 2009 at 11:36 AM, Marcin Hanclik
wrote:
Hi Marcos,
It seems I found another problem in RFC.
7.4
valid-MIME-type = type "/" subtype *(";" parameter)
and we refer to RFC2045 that says:
[1] content := "Content-Type" ":" type "/" subtype
*(";" parameter)
Then, RFC2045 gives examples like:
[2] Content-type: text/plain; charset=us-ascii
The problem is about the spaces.
As for me [2] does not match [1].
I don't know, maybe parameter allows spaces? but yeah, that first
space after "Content-type:" seems non-conforming.
Anyway, it seems I can live with that issue, since it seems to
affect more
than just P&C J.
Me too. Lets get some implementation feedback.
Therefore, for the purposes of my LC comments, with 99.99%
certainty I will
be satisfied with your response.
Yippy! :D
--
Marcos Caceres
http://datadriven.com.au
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.
RE: [widgets] LCWD#3 comments (3)
Hi Marcos,
>>I don't know, maybe parameter allows spaces? but yeah, that first
>>space after "Content-type:" seems non-conforming.
RFC2045:
parameter := attribute "=" value
attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.
value := token / quoted-string
token := 1*
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
token excludes SPACE.
We have to live with that, I think.
RFC4288:
"There is no defined syntax for parameter values."
However, RFC2045 says also:
"By itself, however, this grammar is incomplete."
and refers to RFC822 that in turn talks about folding and unfolding
(white-spaces, multiple lines etc.).
It seems to be a legacy stuff from the "mail industry", therefore we will
probably not fix it here.
Thanks,
Marcin
From: marcosscace...@gmail.com [marcosscace...@gmail.com] On Behalf Of Marcos
Caceres [marc...@opera.com]
Sent: Friday, November 20, 2009 7:31 PM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [widgets] LCWD#3 comments (3)
On Fri, Nov 20, 2009 at 11:36 AM, Marcin Hanclik
wrote:
> Hi Marcos,
>
>
>
> It seems I found another problem in RFC.
>
>
>
> 7.4
>
> valid-MIME-type = type "/" subtype *(";" parameter)
>
> and we refer to RFC2045 that says:
>
> [1] content := "Content-Type" ":" type "/" subtype
>
> *(";" parameter)
>
>
>
> Then, RFC2045 gives examples like:
>
> [2] Content-type: text/plain; charset=us-ascii
>
>
>
> The problem is about the spaces.
>
> As for me [2] does not match [1].
I don't know, maybe parameter allows spaces? but yeah, that first
space after "Content-type:" seems non-conforming.
>
> Anyway, it seems I can live with that issue, since it seems to affect more
> than just P&C J.
>
Me too. Lets get some implementation feedback.
> Therefore, for the purposes of my LC comments, with 99.99% certainty I will
> be satisfied with your response.
Yippy! :D
--
Marcos Caceres
http://datadriven.com.au
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.
Re: [widgets] LCWD#3 comments (3)
On Fri, Nov 20, 2009 at 11:36 AM, Marcin Hanclik
wrote:
> Hi Marcos,
>
>
>
> It seems I found another problem in RFC.
>
>
>
> 7.4
>
> valid-MIME-type = type "/" subtype *(";" parameter)
>
> and we refer to RFC2045 that says:
>
> [1] content := "Content-Type" ":" type "/" subtype
>
> *(";" parameter)
>
>
>
> Then, RFC2045 gives examples like:
>
> [2] Content-type: text/plain; charset=us-ascii
>
>
>
> The problem is about the spaces.
>
> As for me [2] does not match [1].
I don't know, maybe parameter allows spaces? but yeah, that first
space after "Content-type:" seems non-conforming.
>
> Anyway, it seems I can live with that issue, since it seems to affect more
> than just P&C J.
>
Me too. Lets get some implementation feedback.
> Therefore, for the purposes of my LC comments, with 99.99% certainty I will
> be satisfied with your response.
Yippy! :D
--
Marcos Caceres
http://datadriven.com.au
RE: Security evaluation of an example DAP policy
Hi, > >>The weather.example.com Widget can connect to weather.example.com > >>without notifying the user, except when roaming. How do we cover the additional 113 million+ domain names (and x number of subdomains) on the web via a policy such as this? Is that a blanket 'deny all' and a fall back to user prompting for those 113 million web sites not explictly included in a policy document? Most importantly from the previous questions, does domain-based policy then work in the web context? If a policy covers 10,000 domains (or, let's say, 1 million domains) is the ability to reach 1% of web content enough incentive to provide a web policy? > >>Reliably identified Websites can send and receive SMS except to > >>premium rate numbers. If policy is interchangeable, and we have e.g. 100 policy providers, how does the developer have confidence that each policy provider has selected the same set of premium phone numbers to block? Can such a policy be intentionally extended to prohibit non-threatening use cases at the expense of the user? If this is such an integral security issue, it should be possible to bake it in to the API itself? If it is not possible to bake it in, and the security decision is subjective based on whoever is providing a policy, then is this something web developers will be able to reliably and consistently code against? What is the legal responsibility (for data loss / misuse / corruption / etc) that policy providers take on by 'guaranteeing the web'? Is a policy provider liable for actions that it decides on behalf of a user? Over e.g. 1 million web domains? I appreciate the input of solid use cases such as this for discussion. I look forward to a use case that shows a clear reason for policy in a web context considering the massively distributed and centrally unmanageable nature of the web world - one of the tenants of its design that arguably continues to make it so successful. Kind Regards, Richard > -Original Message- > From: public-device-apis-requ...@w3.org > [mailto:public-device-apis-requ...@w3.org] On Behalf Of Marcin Hanclik > Sent: 20 November 2009 15:13 > To: Frederick Hirsch; ext Jeremy Orlow > Cc: Maciej Stachowiak; Jonas Sicking; Adam Barth; Robin > Berjon; public-device-a...@w3.org; public-webapps WG > Subject: RE: Security evaluation of an example DAP policy > > 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 long > 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: > > > > > > > match="weather.example.com" func="equal"/> > > > > match="weather.example.com" func="equal"/> > > > > func="equal">international > > >//this seems not needed > > func="equal">national > > > > > 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: marcin.hanc...@access-company.com > > -Original Message- > From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] > 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; > public-device-a...@w3.org; 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 weathe
Re: [widgets] about test d1.wgt
Hi Cyril, On Fri, Nov 20, 2009 at 5:50 PM, Cyril Concolato wrote: > Hi, > > The test d1.wgt is about the src attribute of the icon element. It says that > it tests the following assertion: > "If the src attribute of this icon element is absent, then the user agent > must ignore this element." > but the config.xml contains an src attribute with an empty value. This seems > a bit different to me. Maybe you should modify the spec as follows: > > "If the src attribute of this icon element is absent *or empty*, then the > user agent must ignore this element." > Well, you get the same result when you actually search for the file "", as it won't be found. But I agree, a simple clarification there won't actually hurt or change the ways UAs work at the moment. > Also you should make sure the tests are aligned between the icon element and > the content element. There does not seem to be such test with the content > element. If you make such test, you should also align the spec in the same > manner. I'm not sure I understand, can you design the test to show what you mean. I can then add it to the test suite. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] default start file table vs. src attribute
On Nov 20, 2009, at 18:36 , Cyril Concolato wrote: > Robin Berjon a écrit : >> I actually like it, it's one less thing that we need to specify (I was >> unfavourable to making the configuration requires in the first place). I've >> implemented it and it works nicely. Yes, it's a bit of a performance hit but >> it's not so bad and you can cache it easily. > I agree that it's not a big burden. I think it's more a question of taste. I > would prefer putting more in the configuration than less. Then our tastes differ :) I really think that Convention Over Configuration is the way to go here (cf http://en.wikipedia.org/wiki/Convention_over_configuration). In general, the more defaults there are, the less cases of outright failure there are, the better. Otherwise it just becomes Java programming all over again, and no one wants that, right? > What do you mean by "you can cache it easily" ? You read the widget's configuration once, then when you read the same widget again you've cached the configuration and don't need to find the start file again (unless the locale has changed). -- Robin Berjon - http://berjon.com/
[widgets] about test d1.wgt
Hi, The test d1.wgt is about the src attribute of the icon element. It says that it tests the following assertion: "If the src attribute of this icon element is absent, then the user agent must ignore this element." but the config.xml contains an src attribute with an empty value. This seems a bit different to me. Maybe you should modify the spec as follows: "If the src attribute of this icon element is absent *or empty*, then the user agent must ignore this element." Also you should make sure the tests are aligned between the icon element and the content element. There does not seem to be such test with the content element. If you make such test, you should also align the spec in the same manner. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] default start file table vs. src attribute
Marcos Caceres a écrit : On Fri, Nov 20, 2009 at 4:58 PM, Cyril Concolato wrote: Hi all, While implementing the required features to pass the tests of the test suite, I was wondering if you really want to keep the default start file table. The benefit of this table seems to be just avoiding the use of a element with an src attribute in the config file while the drawback is that you have to scan your zip file for all files in order. The spec and conformance would be simpler without that, without losing features I think. WDYT? The content element is not mandatory, so you kinda need the table. Also, it needs to be specified what precedence a user agent gives to loading files, which is the second purpose of the table. The last purpose of the table is to tell a user agent what MIME type to use for each file type, which is also fairly important. As I replied to Robin, I'd rather make it more explicit in the config file. I think it would make it more readable/understandable without requiring to know/hard-code all the default values. It's a question of taste. My suggestion was more to mandate the content element, to mandate a type attribute and to allow nesting them for indicating the precedence or use document order (multiple content elements, like the icon element). Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] default start file table vs. src attribute
Robin Berjon a écrit : Hi Cyril, On Nov 20, 2009, at 17:58 , Cyril Concolato wrote: While implementing the required features to pass the tests of the test suite, I was wondering if you really want to keep the default start file table. The benefit of this table seems to be just avoiding the use of a element with an src attribute in the config file while the drawback is that you have to scan your zip file for all files in order. The spec and conformance would be simpler without that, without losing features I think. WDYT? I actually like it, it's one less thing that we need to specify (I was unfavourable to making the configuration requires in the first place). I've implemented it and it works nicely. Yes, it's a bit of a performance hit but it's not so bad and you can cache it easily. I agree that it's not a big burden. I think it's more a question of taste. I would prefer putting more in the configuration than less. What do you mean by "you can cache it easily" ? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] About the test suite
On Fri, Nov 20, 2009 at 3:44 PM, Robin Berjon wrote: > Hi Cyril, > > On Nov 20, 2009, at 09:52 , Cyril Concolato wrote: >> Yes I agree, that should not be difficult, I've already manually created the >> green/red SVG files. But I was wondering about the order given in the >> default start files table. For example, if a widget package contains both a >> index.htm and index.svg, is the UA required to use index.htm ? If this is >> the case we need to duplicate the tests. If not, we can add the SVG files >> and use a single test (for most cases). > > As Marcos said, if the UA doesn't support HTML it'll look for the SVG instead > so you should be good there. But there are at least a few tests (at the very > least all those with a element) that fall in a different category > and would need to be separated. If we have a process for generating an SVG > tree from an HTML tree, I wonder if it might not be simpler than merging the > two. > Dunno. There are only about 10-20 or so tests that are affected by this. It's probably easier to do this by hand. > -- > Robin Berjon - http://berjon.com/ > > > > > -- Marcos Caceres http://datadriven.com.au
Re: [widgets] default start file table vs. src attribute
On Fri, Nov 20, 2009 at 4:58 PM, Cyril Concolato wrote: > Hi all, > > While implementing the required features to pass the tests of the test > suite, I was wondering if you really want to keep the default start file > table. The benefit of this table seems to be just avoiding the use of a > element with an src attribute in the config file while the > drawback is that you have to scan your zip file for all files in order. The > spec and conformance would be simpler without that, without losing features > I think. WDYT? The content element is not mandatory, so you kinda need the table. Also, it needs to be specified what precedence a user agent gives to loading files, which is the second purpose of the table. The last purpose of the table is to tell a user agent what MIME type to use for each file type, which is also fairly important. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] multiple co-authors
On Fri, Nov 20, 2009 at 11:49 AM, Scott Wilson wrote: > Thanks Marcos, > > I'm happy with this solution. > Great. Your approval has been noted in the disposition of comments: http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-20091029/doc/ -- Marcos Caceres http://datadriven.com.au
Re: [widgets] default start file table vs. src attribute
Hi Cyril, On Nov 20, 2009, at 17:58 , Cyril Concolato wrote: > While implementing the required features to pass the tests of the test suite, > I was wondering if you really want to keep the default start file table. The > benefit of this table seems to be just avoiding the use of a > element with an src attribute in the config file while the drawback is that > you have to scan your zip file for all files in order. The spec and > conformance would be simpler without that, without losing features I think. > WDYT? I actually like it, it's one less thing that we need to specify (I was unfavourable to making the configuration requires in the first place). I've implemented it and it works nicely. Yes, it's a bit of a performance hit but it's not so bad and you can cache it easily. -- Robin Berjon - http://berjon.com/
Re: Security evaluation of an example DAP policy
On Nov 20, 2009, at 17:40 , Adam Barth wrote: On Fri, Nov 20, 2009 at 8:34 AM, Robin Berjon wrote: >> DAP will handle security at the API definition level. Full stop. > > Can you elaborate on what this means concretely? For example, how is > security handled at the API definition level for the file writing API? Well, if you're asking me to define how we're going to do it for all the APIs before they've been written, it's gonna be a smidge hard :) I've been noodling a little bit over the file writing case, and have some ideas that at this stage involve hand-waving, have not been validated by the WG or in fact anyone else, and are subject to change (I only took on the action to work on this yesterday, and haven't really sat down to do it right yet). One idea, which Max had, was to tack this onto . The file browsing dialog we have today would work the same, but would have an extra checkbox (unchecked by default) saying "Enable writing back to this file". The file object would become available in the same way as for reading, but would also support writing. It has limited but real use cases, such as loading a document (HTML, image, whatever) which can be edited in the page and saved back. The problem is that it doesn't allow for creating a new document (the initial save) — I haven't cracked that one yet (creating new files, even if they can't overwrite existing ones, has clear issues). It could be that the initial save happens through a download dialog — something which users are familiar with. Another option I had in mind was an extension to Element, e.g. Element.attachData(someFileObject). Said element would then, when dragged out of the browser, drop the content of the file there. It's been a while since I've looked at ongoing work on the cut-paste/drag-drop stuff and I've been meaning to take a good look at it precisely for this. I suspect that if the security issues are solved for those, then we might be able to piggy back on them to create files safely. But that's just a braindump. I'm sorry if this all feels handwavy but if you're looking for assurance that things that haven't been defined yet are good, I can't give it. All I give is the assurance that the *principles* are there, and will be enforced. -- Robin Berjon - http://berjon.com/
[WARP4U] WARP with UPnP, was: RE: [widgets] Draft Minutes for 19 November 2009 Voice Conference
Hi All, As discussed on the yesterday's call, I committed to CVS the WARP spec with the section about local network (required for UPnP use cases) at: http://dev.w3.org/2006/waf/widgets-access-upnp/ Handling of local network is based on my proposal from [1]. Thanks, Marcin [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0456.html Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Thursday, November 19, 2009 5:05 PM To: public-webapps Subject: [widgets] Draft Minutes for 19 November 2009 Voice Conference The draft minutes from the 19 November Widgets voice conference are available at the following and copied below: http://www.w3.org/2009/11/19-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 3 December 2009 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conf 19 Nov 2009 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0763.html See also: [3]IRC log [3] http://www.w3.org/2009/11/19-wam-irc Attendees Present Art, Arve, Robin, David, Marcin, Steven, Marcos, Frederick, Suresh, Benoit, Doug, Chitturi Regrets Chair Art Scribe Art Contents * [4]Topics 1. [5]Agenda review 2. [6]Announcements: 3. [7]P&C spec: LCWD#3 comment period ends 19 November 4. [8]P&C spec: CfC to publish CR#2 5. [9]WARP spec: Patent exclusions by Apple ; PAG & Next steps .. 6. [10]WARP spec: comments 7. [11]URI Scheme spec 8. [12]AOB * [13]Summary of Action Items _ Scribe: Art ScribeNick: ArtB Date: 19 November 2009 I can't hear anything either neither do I that's better now, I'm at least hearing ArtB talk Doug and I keep ending up on the same call, but no one else Marcos, :) Marcin, quickly check out the email I just sent you Steven, Doug - we're all here on 9231 Doug and steven on a separate call again Agenda review AB: draft agenda is [14]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/07 63.html ... any change requests on the agenda? [14] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0763.html Marcos, long email :). I think option 3 should win, but I need to check what parameters we may have. I will respond shortly. AB: any change requests on agenda? [ None ] MC: can we add Marcin's regarding P&C? AB: yes Announcements: AB: No Voice Conf on 26 November; next one will be 3 December ... Reminder: last day to request publications for 2009 is Friday 18 December ... WebApps has been asked to submit comments re OASIS' Packaging spec for ODF for Office Apps spec; see ( [15]http://www.w3.org/mid/4b016692.2090...@w3.org ) for details ... Doug, anything to add? [15] http://www.w3.org/mid/4b016692.2090...@w3.org DS: they are using ZIP too AB: if there are comments, send them to the OASIS list DS: if need clarification on list, let me know AB: any other annoucements? [ None ] P&C spec: LCWD#3 comment period ends 19 November DS: I am on the ODF Tech Committee ... my main reason is SVG ... but I can be a pipe for other ODF comments SP: I will also join the ODF TC but not as a W3C rep AB: November 19 is the last day to submit comments re P&C LC#3 ( [16]http://www.w3.org/TR/2009/WD-widgets-20091029/ ). ... the comment tracking document is ( [17]http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-2 0091029/ ). Marcos, that document must be up to date before the Director's call. ... the Director's call is tentatively set for Nov 23 ... Marcos, which comments still lack a WG response? My count is 5 total: 2 from Marcin ( [18]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/07 11.html and [19]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/07 50.html ), 1 from Ericsson ( [20]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/05 67.html ), 1 from Scott Wilson ( [21]http://lists.w3.org/Archives/Public/public-w [16] http://www.w3.org/TR/2009/WD-widgets-20091029/ [17] http://www.w3.org/2006/02/lc-comments-tracker/42538/WD- widgets-20091029/ [18] http://lists.w3.org/Archives/Public/p
[widgets] default start file table vs. src attribute
Hi all, While implementing the required features to pass the tests of the test suite, I was wondering if you really want to keep the default start file table. The benefit of this table seems to be just avoiding the use of a element with an src attribute in the config file while the drawback is that you have to scan your zip file for all files in order. The spec and conformance would be simpler without that, without losing features I think. WDYT? Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
Re: [widgets] Test suite: problem with test cases
Robin pointed out that the following test was also wrong : http://samaxes.svn.beanstalkapp.com/widgets_compatibility_matrix/trunk/test-cases/ta-klLDaEgJeU/002/ Now fixed, but will need to retest. On Fri, Nov 20, 2009 at 1:17 PM, Samuel Santos wrote: > Thanks Scott, > > It's fixed now. > > -- > Samuel Santos > http://www.samaxes.com/ > > > On Fri, Nov 20, 2009 at 11:53 AM, Scott Wilson > wrote: >> >> Another test case issue: >> >> Assertion 30: test ag, ah >> === >> >> I think these two got mixed up; ag should result in "P A S S" and ah >> should result in "PASS". >> >> S >> >> On 19 Nov 2009, at 23:05, Marcos Caceres wrote: >> >>> On Wed, Nov 18, 2009 at 1:59 PM, Scott Wilson >>> wrote: On 18 Nov 2009, at 12:02, Marcos Caceres wrote: 2009/11/14 Scott Wilson : woops, fixed. Assertion 34: Test d7, d8 === These test cases both contain badly-formed XML: Presumably these ought to be: Fixed and checked in. Thanks - btw you still need to check in the updated .wgt files as well as the config.xml >>> >>> Doh, I thought I had. I just checked in new versions for these tests. >>> >>> >>> -- >>> Marcos Caceres >>> http://datadriven.com.au >> > > -- Marcos Caceres http://datadriven.com.au
Re: Security evaluation of an example DAP policy
On Fri, Nov 20, 2009 at 8:34 AM, Robin Berjon wrote: > DAP will handle security at the API definition level. Full stop. Can you elaborate on what this means concretely? For example, how is security handled at the API definition level for the file writing API? Adam
Re: Security evaluation of an example DAP policy
On Nov 20, 2009, at 01:26 , Maciej Stachowiak wrote: >> 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. That's good, because it's not part of the plan to do such a thing. The writer level for the File API, which I'm tasked to draft up, certainly doesn't plan any such thing. There is interest in a Directory level, but it's lower. And I would expect it to only be available to widgets, or /perhaps/ to some sort of virtual local file system accessed through a localFS object à la localStorage (with quotas, security considerations that UAs shouldn't implement that by actually storing files on the FS as that could open up a bunch of issues, etc.). -- Robin Berjon - http://berjon.com/
Re: Security evaluation of an example DAP policy
On Nov 20, 2009, at 00:22 , Adam Barth wrote: > It's emails like this that make me skeptical of the security work > being done in the device APIs working group. *sigh* I feel like a broken record. It feels like I've spent my time since TPAC involved in an endless repeat of the following discussion: - "You must support security at the API definition level!!!1" - "Yes. That is the plan. That is what we will do. We've already agreed to that." - "Okay... But... You must support security at the API definition level!!!1" - "..." DAP will handle security at the API definition level. Full stop. Now, there may be participants in the WG who believe that policy could *also* be used in browsers, or other such things. That may or may not be the possible, practical, doable, implementable, safe. You may or may not agree. The fact is, for the purpose of trusting that DAP will handle security at the API definition level, it doesn't matter because: DAP will handle security at the API definition level. If you don't like the policy stuff, don't implement the policy stuff. You can still implement the APIs because, you know what? DAP will handle security at the API definition level. If later a policy-based approach surfaces that changes your mind and makes you want to support it, that's also fine. But for the immediate purpose of creating DAP APIs that can work in browsers it doesn't matter because DAP will handle security at the API definition level. Is this clearer? Would people mind if we had this DAP conversation just on the DAP list and cut down on the cross-posting? It's not as if WebApps didn't see some traffic already. Oh, and yeah, DAP will handle security at the API definition level. -- Robin Berjon - http://berjon.com/
Re: Unzipping content into current directory widely considered poor practice
On Fri, Nov 20, 2009 at 5:05 PM, Marcos Caceres wrote: > On Fri, Nov 20, 2009 at 8:48 AM, Dan Brickley wrote: >> Hello, >> >> I understand from http://www.w3.org/TR/2009/WD-widgets-20091029/ that >> this is the place to direct my feedback on the widget packaging spec, >> and that I have missed the Last Call deadline by one day. I hope you >> will consider my plea anyway, since it is based on evaluation of an >> implementation I only discovered last night. See below for an issue I >> tried to raise with the implementor. >> >> It seems W3C Widget zip packages unload a mess of several files in the >> current working directory when unzipped. >> >> This is unfortunate and I urge you to consider a design that allows >> things to be kept in a single subdirectory. >> >> 1. the dominant convention in modern software development is that you >> can safely unwrap a .zip or .tar.gz in the current working directory, >> in the expectation that you'll find only a sensibly named >> subdirectory. Those who violate this expectation are often seen as >> making a basic beginners mistake. Encoding such a 'mistake' in a W3C >> REC both looks bad, and encourages bad practice. >> >> 2. by risking a mixup between pre-existing files and those from the >> archive file, we introduce the risk of confusion and inclarity, making >> widgets ever slightly harder to learn from. And or those who do try to >> learn from others works, we reward them by making a mess of their >> filetree. Assuming 1000 new developers decide each day to explore W3C >> Widget technology and learn by example, I expect 900+ of them will >> come with the reasonable assumption that a zip file can be safely >> unpacked in a directory that has already got other stuff in it >> (including possibly files with common names like index.html). Mixing >> up files will be annoying; accidentally overwriting files will be >> infuriating >> >> 3. Are we confident that all unzip tools will ask nicely before >> overwriting existing files? A quick test on my machine at least gave >> me a warning. >> >> eg. >> TellyClub:~ danbri$ mkdir w3ctest >> TellyClub:~ danbri$ cd w3ctest/ >> TellyClub:w3ctest danbri$ echo 'my original valuable html >> document' > index.html >> TellyClub:w3ctest danbri$ curl -Os http://berjon.com/tmp/a-widget.wgt >> TellyClub:w3ctest danbri$ unzip a-widget.wgt >> Archive: a-widget.wgt >> inflating: config.xml >> inflating: icon.svg >> creating: img/ >> inflating: img/me.jpg >> replace index.html? [y]es, [n]o, [A]ll, [N]one, [r]ename: >> >> >> Thanks for considering my request. >> > > I spoke to Dan about the above offline, we feel that adding the > following non-normative authoring guideline into the specification > would be sufficient to address Dan's concerns: Just a quick note to confirm that this would satisfy my concern for now. I hope a subdirectory based approach can be specified in the future, but for now I'm happy with this resolution. Also to ack Art's response which arrived as I type this. Thanks both. May 2010 not be like 1984 :) cheers, Dan
Re: Unzipping content into current directory widely considered poor practice
Hi Dan, Thanks for you comment. WebApps welcomes comments for any of its specs at any time. You are correct, however, that your comment below missed the LC#3 comment deadline and as such will not be reflected in CR#2. However, we will discuss your e-mail and depending upon the results of that discussion, it may be reflected in the publication that follows CR#2. -Regards, Art Barstow On Nov 20, 2009, at 3:48 AM, ext Dan Brickley wrote: Hello, I understand from http://www.w3.org/TR/2009/WD-widgets-20091029/ that this is the place to direct my feedback on the widget packaging spec, and that I have missed the Last Call deadline by one day. I hope you will consider my plea anyway, since it is based on evaluation of an implementation I only discovered last night. See below for an issue I tried to raise with the implementor. It seems W3C Widget zip packages unload a mess of several files in the current working directory when unzipped. This is unfortunate and I urge you to consider a design that allows things to be kept in a single subdirectory. 1. the dominant convention in modern software development is that you can safely unwrap a .zip or .tar.gz in the current working directory, in the expectation that you'll find only a sensibly named subdirectory. Those who violate this expectation are often seen as making a basic beginners mistake. Encoding such a 'mistake' in a W3C REC both looks bad, and encourages bad practice. 2. by risking a mixup between pre-existing files and those from the archive file, we introduce the risk of confusion and inclarity, making widgets ever slightly harder to learn from. And or those who do try to learn from others works, we reward them by making a mess of their filetree. Assuming 1000 new developers decide each day to explore W3C Widget technology and learn by example, I expect 900+ of them will come with the reasonable assumption that a zip file can be safely unpacked in a directory that has already got other stuff in it (including possibly files with common names like index.html). Mixing up files will be annoying; accidentally overwriting files will be infuriating 3. Are we confident that all unzip tools will ask nicely before overwriting existing files? A quick test on my machine at least gave me a warning. eg. TellyClub:~ danbri$ mkdir w3ctest TellyClub:~ danbri$ cd w3ctest/ TellyClub:w3ctest danbri$ echo 'my original valuable html document' > index.html TellyClub:w3ctest danbri$ curl -Os http://berjon.com/tmp/a-widget.wgt TellyClub:w3ctest danbri$ unzip a-widget.wgt Archive: a-widget.wgt inflating: config.xml inflating: icon.svg creating: img/ inflating: img/me.jpg replace index.html? [y]es, [n]o, [A]ll, [N]one, [r]ename: Thanks for considering my request. cheers, Dan -- Forwarded message -- From: Date: Fri, Nov 20, 2009 at 9:24 AM Subject: Re: Issue 4 in widgeon: test widget unzips in current directory To: danbrick...@gmail.com Updates: Status: Invalid Comment #1 on issue 4 by robin.berjon: test widget unzips in current directory http://code.google.com/p/widgeon/issues/detail?id=4 That is something that is imposed on us by the Widgets spec, so you'd have to complain to Marcos I'm afraid. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Re: Unzipping content into current directory widely considered poor practice
On Fri, Nov 20, 2009 at 8:48 AM, Dan Brickley wrote: > Hello, > > I understand from http://www.w3.org/TR/2009/WD-widgets-20091029/ that > this is the place to direct my feedback on the widget packaging spec, > and that I have missed the Last Call deadline by one day. I hope you > will consider my plea anyway, since it is based on evaluation of an > implementation I only discovered last night. See below for an issue I > tried to raise with the implementor. > > It seems W3C Widget zip packages unload a mess of several files in the > current working directory when unzipped. > > This is unfortunate and I urge you to consider a design that allows > things to be kept in a single subdirectory. > > 1. the dominant convention in modern software development is that you > can safely unwrap a .zip or .tar.gz in the current working directory, > in the expectation that you'll find only a sensibly named > subdirectory. Those who violate this expectation are often seen as > making a basic beginners mistake. Encoding such a 'mistake' in a W3C > REC both looks bad, and encourages bad practice. > > 2. by risking a mixup between pre-existing files and those from the > archive file, we introduce the risk of confusion and inclarity, making > widgets ever slightly harder to learn from. And or those who do try to > learn from others works, we reward them by making a mess of their > filetree. Assuming 1000 new developers decide each day to explore W3C > Widget technology and learn by example, I expect 900+ of them will > come with the reasonable assumption that a zip file can be safely > unpacked in a directory that has already got other stuff in it > (including possibly files with common names like index.html). Mixing > up files will be annoying; accidentally overwriting files will be > infuriating > > 3. Are we confident that all unzip tools will ask nicely before > overwriting existing files? A quick test on my machine at least gave > me a warning. > > eg. > TellyClub:~ danbri$ mkdir w3ctest > TellyClub:~ danbri$ cd w3ctest/ > TellyClub:w3ctest danbri$ echo 'my original valuable html > document' > index.html > TellyClub:w3ctest danbri$ curl -Os http://berjon.com/tmp/a-widget.wgt > TellyClub:w3ctest danbri$ unzip a-widget.wgt > Archive: a-widget.wgt > inflating: config.xml > inflating: icon.svg > creating: img/ > inflating: img/me.jpg > replace index.html? [y]es, [n]o, [A]ll, [N]one, [r]ename: > > > Thanks for considering my request. > I spoke to Dan about the above offline, we feel that adding the following non-normative authoring guideline into the specification would be sufficient to address Dan's concerns: Under section "Reserved File and Folder Names" "Authoring Guideline: Authors are strongly encourage to package all files, except the reserved files and the container for localized content, within a single subdirectory named, for instance, after the widget. This is to avoid unzipping several files into the end-user's current working directory. Future versions of this specification may include rules for locating index.html and config.xml within such directories. For example, best practice for packaging a widget would look something like this: config.xml index.svg index.html clock/ images/ screens/ locales/ jp/ clock/ images/ assets/ fr/ clock/ images/ assets/ " As these comments came in after the deadline, I have not included the text in the current spec. If the WG agrees, I will add them to whatever the next publication will be (fingers crossed, it will be PR). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Re: Request for Reviewers: Section 7.4 of Web Security Context: User Interface Guidelines; deadline Sep 24 ( LC-2255)
Hi Adam, The editors draft has been updated with the items from our last emails: http://www.w3.org/2006/WSC/drafts/rec/rewrite.html Please raise any additional issues by November 27. Thanks. Mez
Re: [widgets] About the test suite
Hi Cyril, On Nov 20, 2009, at 09:52 , Cyril Concolato wrote: > Yes I agree, that should not be difficult, I've already manually created the > green/red SVG files. But I was wondering about the order given in the default > start files table. For example, if a widget package contains both a index.htm > and index.svg, is the UA required to use index.htm ? If this is the case we > need to duplicate the tests. If not, we can add the SVG files and use a > single test (for most cases). As Marcos said, if the UA doesn't support HTML it'll look for the SVG instead so you should be good there. But there are at least a few tests (at the very least all those with a element) that fall in a different category and would need to be separated. If we have a process for generating an SVG tree from an HTML tree, I wonder if it might not be simpler than merging the two. -- Robin Berjon - http://berjon.com/
RE: Security evaluation of an example DAP policy
Hi Frederick, My comment inline below. I think, it would be good if someone else involved in BONDI verified my below statements. >>Do you have any more to add, or better use cases? I was going to ask >>about premium rate numbers so thanks for bringing that up. As below, maybe we should ask GSMA or anyone else responsible for premium numbers (are they assigned on national or international level? Or both?) ? Copied from below for easy summary: >>* The weather.example.com foo widget can access geolocation >>coordinates but only if it's embedded on the foo home page. [MH] I do not know what " weather.example.com foo widget embedded on the foo home page" means. I assume it is a combination of download URI with author/distributor signature. Therefore I would generously assume that it is doable. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] Sent: Friday, November 20, 2009 4:30 PM To: Marcin Hanclik Cc: Frederick Hirsch; ext Jeremy Orlow; Maciej Stachowiak; Jonas Sicking; Adam Barth; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: Security evaluation of an example DAP policy Marcin do you have any more comment on any of the following from the draft policy requirements document? http://dev.w3.org/2009/dap/policy-reqs/#use-cases Example Widget use cases, to give examples of the types of policy that might be expressed: * A Widget whose signature chains to operator root can read and write from the PIM databases. [MH] Expressible with BONDI policy. * A Widget downloaded from weather.example.com can access geolocation coordinates if the user says it's OK. [MH] Expressible with BONDI policy. * The weather.example.com Widget can connect to weather.example.com without notifying the user, except when roaming. [MH] Expressible with BONDI policy. * All Widgets with a reliably identified author can save data persistently if the user says it's OK. [MH] Expressible with BONDI policy. * No Widget can get my location, no matter who trusts it. [MH] Expressible with BONDI policy. Example web site use cases, to give examples of the types of policy that might be expressed: * A reliably identified website can access geolocation coordinates if the user confirms it's OK. [MH] Expressible with BONDI policy. * Any Website in a subdomain of mynetwork.example.com can read phone status properties. [MH] Expressible with BONDI policy. * Reliably identified Websites can send and receive SMS except to premium rate numbers. [MH] No definition of the premium rate numbers as in my previous email (intentional or not). Therefore not doable out of the box. (Maybe we should ask GSMA?) * evil.example.com cannot access any device APIs. [MH] Expressible with BONDI policy. * The weather.example.com foo widget can access geolocation coordinates but only if it's embedded on the foo home page. [MH] I do not know what " weather.example.com foo widget embedded on the foo home page" means. I assume it is a combination of download URI with author/distributor signature. Therefore I would generously assume that it is doable. Do you have any more to add, or better use cases? I was going to ask about premium rate numbers so thanks for bringing that up. Can anyone please volunteer to provide more detail on the use cases or additional use cases? regards, Frederick Frederick Hirsch Nokia On Nov 20, 2009, at 10:12 AM, ext Marcin Hanclik wrote: > 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 long 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: > > > > > > > func="equal"/> > > > > match="weather.example.com" func="equal"/> > > > > international resource-match> > > > //this seems not needed > > national resource-match> > > > > > 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 op
Re: Security evaluation of an example DAP policy
Marcin do you have any more comment on any of the following from the draft policy requirements document? http://dev.w3.org/2009/dap/policy-reqs/#use-cases Example Widget use cases, to give examples of the types of policy that might be expressed: • A Widget whose signature chains to operator root can read and write from the PIM databases. • A Widget downloaded from weather.example.com can access geolocation coordinates if the user says it’s OK. • The weather.example.com Widget can connect to weather.example.com without notifying the user, except when roaming. • All Widgets with a reliably identified author can save data persistently if the user says it’s OK. • No Widget can get my location, no matter who trusts it. Example web site use cases, to give examples of the types of policy that might be expressed: • A reliably identified website can access geolocation coordinates if the user confirms it’s OK. • Any Website in a subdomain of mynetwork.example.com can read phone status properties. • Reliably identified Websites can send and receive SMS except to premium rate numbers. • evil.example.com cannot access any device APIs. • The weather.example.com foo widget can access geolocation coordinates but only if it’s embedded on the foo home page. Do you have any more to add, or better use cases? I was going to ask about premium rate numbers so thanks for bringing that up. Can anyone please volunteer to provide more detail on the use cases or additional use cases? regards, Frederick Frederick Hirsch Nokia On Nov 20, 2009, at 10:12 AM, ext Marcin Hanclik wrote: 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 long 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: func="equal"/> match="weather.example.com" func="equal"/> internationalresource-match> //this seems not needed nationalresource-match> 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: marcin.hanc...@access-company.com -Original Message- From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] 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; public-device-a...@w3.org; 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 providin
Re: [Widgets] LCWD#3 comments (2)
Marcin Hanclik wrote: Hi Marcos, 3. say that parameter is allowed, but if it includes an encoding parameter, then @encoding beats it (or the other way around). OK " let start file encoding be the value of the last supported parameter components whose purpose is to declare the character encoding of the start file." Should be " let start file encoding be the value of the last supported parameter component whose purpose is to declare the character encoding of the start file." (components -> component) Fixed What we should do here is quickly ask Adam Barth to take a look at what we have specified and make sure it is ok. OK. For the purposes of my LC comments, I am satisfied with your response up to the next line. Great. I have recorded your approval in the DoC!
RE: Security evaluation of an example DAP policy
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 long 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: international //this seems not needed national 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: marcin.hanc...@access-company.com -Original Message- From: Frederick Hirsch [mailto:frederick.hir...@nokia.com] 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; public-device-a...@w3.org; 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 > 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: > > > > > > > > > > > /.+/ match> > > > > > > Let's see how DAP will evolve then. > > Thanks, > Marcin > > From: Maciej Stachowiak [...@apple.com] > Sent: Friday, November 20, 2009 1:26 AM > To: Jonas Sicking > Cc: Marcin Hanclik; Adam Barth; Robin Berjon; public-device-a...@w3.org > ; 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 > wrote: > Hi Adam, > > I think that > /(C|c):\\(.+)\\(.+)/ > > should be > /(C|c):\\([^\\]+)\\. > +/ > 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 thi
RE: Let's turn WebDatabase into a WG Note
On Friday, November 20, 2009 4:44 AM, Charles McCathieNevile wrote: > On Fri, 20 Nov 2009 06:23:38 +0100, Adrian Bateman > wrote: > > > ...As I noted at TPAC, at Microsoft we don't think we'll collectively > > be able to achieve reasonable interop because of the SQL dialect issue > ... > > it seems unlikely that there will be two independent interoperable > > implementations at the SQL level which makes moving to Last Call > > potentially problematic... > > I expect to see interoperable implementations from Opera and Apple/Chrome > - so although you can argue that iPhone-Safari and Safari are hardly > independent, I think we will easily get a couple of truly independent > interoperable versions. I was under the impression that Opera were using the same SQLite library as Apple/Google to provide the SQL implementation (obviously the JavaScript part Web Database API implementation would be independent). If that is not the case then I agree that they are independent however using the same library is a single implementation of the SQL dialect part of the spec. > > I do wonder whether it might make sense to include an editor's note in > > the WD indicating that independent implementations of the SQL dialect > > aren't currently anticipated just so that anyone unfamiliar with this > > conversation would be aware from the spec. > > I think the spec should be more careful, stating something like "we do > not currently anticipate that browsers will all implement the spec", and > pointing to the WebSimpleDB as a *more likely* implementation based on > current knowledge. That seems reasonable. Cheers, Adrian
Re: Security evaluation of an example DAP policy
I'm not saying that there is no need for policies (you listed two great examples of where they can be useful). They seem useful for overriding default secure behavior that we require for the web. All that I (and I believe others) am saying is that security cannot completely be decoupled from the implementation and differed to policies. Especially in APIs that we want to expose to the web. I'd even go as far as to say that differing to policies or asking the user for permission should be a last resort. On Fri, Nov 20, 2009 at 2:29 PM, Frederick Hirsch < frederick.hir...@nokia.com> wrote: > 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 < >> frederick.hir...@nokia.com> 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: >> >> >> >> >> >> >> >> >> >> >> /.+/ >> >> >> >> >> >> Let's see how DAP will evolve then. >> >> Thanks, >> Marcin >> >> From: Maciej Stachowiak [...@apple.com] >> Sent: Friday, November 20, 2009 1:26 AM >> To: Jonas Sicking >> Cc: Marcin Hanclik; Adam Barth; Robin Berjon; public-device-a...@w3.org; >> 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 >> wrote: >> Hi Adam, >> >> I think that >> /(C|c):\\(.+)\\(.+)/ >> >> should be >> /(C|c):\\([^\\]+)\\. >> +/ >> 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 anyo
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 > 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: /.+/match> Let's see how DAP will evolve then. Thanks, Marcin From: Maciej Stachowiak [...@apple.com] Sent: Friday, November 20, 2009 1:26 AM To: Jonas Sicking Cc: Marcin Hanclik; Adam Barth; Robin Berjon; public-device-a...@w3.org ; 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 wrote: Hi Adam, I think that /(C|c):\\(.+)\\(.+)/ should be /(C|c):\\([^\\]+)\\. +/ 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.
Re: Security evaluation of an example DAP policy
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 < frederick.hir...@nokia.com> 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: >> >> >> >> >> >> >> >> >> >> >> /.+/ >> >> >> >> >> >> Let's see how DAP will evolve then. >> >> Thanks, >> Marcin >> >> From: Maciej Stachowiak [...@apple.com] >> Sent: Friday, November 20, 2009 1:26 AM >> To: Jonas Sicking >> Cc: Marcin Hanclik; Adam Barth; Robin Berjon; public-device-a...@w3.org; >> 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 >>> wrote: >>> Hi Adam, I think that /(C|c):\\(.+)\\(.+)/ should be /(C|c):\\([^\\]+)\\. +/ 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. >> >> > >
Re: [widgets] About the test suite
Cyril Concolato wrote: Yes I agree, that should not be difficult, I've already manually created the green/red SVG files. But I was wondering about the order given in the default start files table. For example, if a widget package contains both a index.htm and index.svg, is the UA required to use index.htm ? Only if the user agent supports text/html. So, a user agent could be told to disable text/html support for the testing, in which case it should automatically select the SVG files. If this is the case we need to duplicate the tests. If not, we can add the SVG files and use a single test (for most cases). That is correct. We need to work out cases where the content element is used to load a html file, etc. For the testing the widget interface spec, I should probably move all the scripts to separate "test.js" files and rewrite them so they don't use element.innerHTML. We should start coordinating with Dom so he can pump out the IDL tests for both SVG and HTML automatically. Kind regards, Marcos
Re: Security evaluation of an example DAP policy
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: /.+/match> Let's see how DAP will evolve then. Thanks, Marcin From: Maciej Stachowiak [...@apple.com] Sent: Friday, November 20, 2009 1:26 AM To: Jonas Sicking Cc: Marcin Hanclik; Adam Barth; Robin Berjon; public-device-a...@w3.org ; 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 wrote: Hi Adam, I think that /(C|c):\\(.+)\\(.+)/ should be /(C|c):\\([^\\]+)\\. +/ 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.
Re: [widgets] Test suite: problem with test cases
Thanks Scott, It's fixed now. -- Samuel Santos http://www.samaxes.com/ On Fri, Nov 20, 2009 at 11:53 AM, Scott Wilson < scott.bradley.wil...@gmail.com> wrote: > Another test case issue: > > Assertion 30: test ag, ah > === > > I think these two got mixed up; ag should result in "P A S S" and ah should > result in "PASS". > > S > > > On 19 Nov 2009, at 23:05, Marcos Caceres wrote: > > On Wed, Nov 18, 2009 at 1:59 PM, Scott Wilson >> wrote: >> >>> On 18 Nov 2009, at 12:02, Marcos Caceres wrote: >>> >>> 2009/11/14 Scott Wilson : >>> >>> woops, fixed. >>> >>> Assertion 34: Test d7, d8 >>> >>> === >>> >>> These test cases both contain badly-formed XML: >>> >>> >>> >>> >>> >>> >>> >>> Presumably these ought to be: >>> >>> >>> >>> >>> >>> >>> >>> Fixed and checked in. >>> >>> Thanks - btw you still need to check in the updated .wgt files as well as >>> the config.xml >>> >>> >> Doh, I thought I had. I just checked in new versions for these tests. >> >> >> -- >> Marcos Caceres >> http://datadriven.com.au >> > >
Re: Let's turn WebDatabase into a WG Note
On Fri, 20 Nov 2009 06:23:38 +0100, Adrian Bateman wrote: ...As I noted at TPAC, at Microsoft we don't think we'll collectively be able to achieve reasonable interop because of the SQL dialect issue ... it seems unlikely that there will be two independent interoperable implementations at the SQL level which makes moving to Last Call potentially problematic... I expect to see interoperable implementations from Opera and Apple/Chrome - so although you can argue that iPhone-Safari and Safari are hardly independent, I think we will easily get a couple of truly independent interoperable versions. That said, given the current reluctance of MS and Mozilla to implement, it does seem unlikely that this will achieve reliable interoperability on the Web at large. I do wonder whether it might make sense to include an editor's note in the WD indicating that independent implementations of the SQL dialect aren't currently anticipated just so that anyone unfamiliar with this conversation would be aware from the spec. I think the spec should be more careful, stating something like "we do not currently anticipate that browsers will all implement the spec", and pointing to the WebSimpleDB as a *more likely* implementation based on current knowledge. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
RE: [widgets] LCWD#3 comments (3)
Hi Marcos, All,
For the purposes of my LC comments, I am satisfied with the text in P&C as it
is in section 7.4.
Thanks,
Marcin
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Marcin Hanclik
Sent: Friday, November 20, 2009 12:36 PM
To: WebApps WG
Subject: [widgets] LCWD#3 comments (3)
Hi Marcos,
It seems I found another problem in RFC.
7.4
valid-MIME-type = type "/" subtype *(";" parameter)
and we refer to RFC2045 that says:
[1] content := "Content-Type" ":" type "/" subtype
*(";" parameter)
Then, RFC2045 gives examples like:
[2] Content-type: text/plain; charset=us-ascii
The problem is about the spaces.
As for me [2] does not match [1].
Anyway, it seems I can live with that issue, since it seems to affect more than
just P&C :).
Therefore, for the purposes of my LC comments, with 99.99% certainty I will be
satisfied with your response.
Thanks,
Marcin
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
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.
CfC: to publish LCWD of: Sever-Sent Events, Web Storage and Web Workers; deadline 27 November
This is a Call for Consensus to publish a Last Call Working Draft of each of the following specs: 1. Server-Sent Events http://dev.w3.org/html5/eventsource/ 2. Web Storage http://dev.w3.org/html5/webstorage/ 3. Web Workers http://dev.w3.org/html5/workers/ This CfC satisfies the group's requirement to "record the group's decision to request advancement" for this LCWD. Note that as specified in the Process Document [PD], a Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. 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 November 27. Assuming there is consensus to publish LCWDs, there are two additional questions for the group: 1. Length of the review period 2. The group(s) we will specifically ask to review these specs Re Q#1 above, given the upcoming end of the year holidays and the earliest publication date of 1 December, my inclination is mid- January (say January 15) at the earliest. Re Q#2 above, I presume at least the HTML WG for all of them and IETF's HyBi WG for the Web Sockets API. If there are other groups (both within W3C and outside), please let us know. -Regards, Art Barstow [PD] http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
Re: [widgets] Test suite: problem with test cases
Another test case issue: Assertion 30: test ag, ah === I think these two got mixed up; ag should result in "P A S S" and ah should result in "PASS". S On 19 Nov 2009, at 23:05, Marcos Caceres wrote: On Wed, Nov 18, 2009 at 1:59 PM, Scott Wilson wrote: On 18 Nov 2009, at 12:02, Marcos Caceres wrote: 2009/11/14 Scott Wilson : woops, fixed. Assertion 34: Test d7, d8 === These test cases both contain badly-formed XML: Presumably these ought to be: Fixed and checked in. Thanks - btw you still need to check in the updated .wgt files as well as the config.xml Doh, I thought I had. I just checked in new versions for these tests. -- Marcos Caceres http://datadriven.com.au smime.p7s Description: S/MIME cryptographic signature
Re: [widgets] multiple co-authors
Thanks Marcos, I'm happy with this solution. S On 19 Nov 2009, at 21:05, Marcos Caceres wrote: On Thu, Nov 19, 2009 at 8:53 PM, Marcos Caceres wrote: Hi Scott, Artb would like to include this comment as part of our Disposition of Comments for P&C. We intend to republish next week, so I need an approval that you are satisfied with the response I sent you ASAP (hopefully you are:)). I modified the example in the spec. It's now: http://www.w3.org/ns/widgets";> Café Finder http://dahut.example.org/developers/"; email = "questi...@example.org"> Joey and Princesa Bacalhau -- Marcos Caceres http://datadriven.com.au smime.p7s Description: S/MIME cryptographic signature
[widgets] LCWD#3 comments (3)
Hi Marcos,
It seems I found another problem in RFC.
7.4
valid-MIME-type = type "/" subtype *(";" parameter)
and we refer to RFC2045 that says:
[1] content := "Content-Type" ":" type "/" subtype
*(";" parameter)
Then, RFC2045 gives examples like:
[2] Content-type: text/plain; charset=us-ascii
The problem is about the spaces.
As for me [2] does not match [1].
Anyway, it seems I can live with that issue, since it seems to affect more than
just P&C :).
Therefore, for the purposes of my LC comments, with 99.99% certainty I will be
satisfied with your response.
Thanks,
Marcin
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
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.
RE: [Widgets] LCWD#3 comments (2)
Hi Marcos, >>3. say that parameter is allowed, but if it includes an encoding >>parameter, then @encoding beats it (or the other way around). OK " let start file encoding be the value of the last supported parameter components whose purpose is to declare the character encoding of the start file." Should be " let start file encoding be the value of the last supported parameter component whose purpose is to declare the character encoding of the start file." (components -> component) >>heh, good point (I honestly don't know which fools let me be a spec >>editor; I'm s obviously not qualified! just hope no one will >>notice :) ) ;) Keep up! You are doing a great job! I am just reviewing :) >>What we should do here is quickly ask Adam Barth to take a look at >>what we have specified and make sure it is ok. OK. For the purposes of my LC comments, I am satisfied with your response up to the next line. >>> It is unclear why the valid-MIME-type production requires “parameter”. I will send another email with comments on this grammar. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Thursday, November 19, 2009 2:54 PM To: Marcin Hanclik Cc: WebApps WG Subject: Re: [Widgets] LCWD#3 comments (2) Hi Marcin, All, Marcin has identified an issue with the spec that requires input from people that know the MIME. Please see the changes I have proposed to the spec below. 2009/11/18 Marcin Hanclik : > 5.3 (grammar: I hope these are final corrections L ) > > > > [*folder-name] > > Should be > > *folder-name > > Since the current form makes it optional twice Right. Fixed. > > > Zip-rel-path > > file-name/ > > could be > > file-name / > > (note the space before ‘/’) Noted and fixed :) > > > safe-char > > I suggest putting the ‘/’ sign at the end of each line instead of at the > beginning > Done. > > 7.4 > > Media type attribute > > It is unclear why the valid-MIME-type production requires “parameter”. > > “parameter” could specify the charset and that could conflict with the > @encoding attribute of the element. > This is true and a really good point. It was actually the reason I included the parameter part (so you didn't need the encoding attribute). And also because parameters could appear, in which case I didn't want those strings to be treated as invalid - and hence make the whole widget invalid! However, given that I forgot to specify the behavior for the situation you describe, we should either: 1. kill the parameter bit - using the ABNF you suggest below. 2. say that it is allowed, but left up to the implementation. 3. say that parameter is allowed, but if it includes an encoding parameter, then @encoding beats it (or the other way around). I don't particularly like 1, because I can imagine use cases where one could automatically convert a web page into a widget and retain the Content-Type: header for a resource without needing to strip out the parameters. Having the parameters would automatically make the content type invalid and, hence, ignored by the UA, which I don't think is right. I share your concerns about 2, because it is ambiguous. I guess 3 seems like the right thing to do. I think @encoding should win - but I don't have a technically valid reason why... maybe just because it could serve as an explicit override. Here is a proposed text, to go into Step 7 as part of the content element parsing rule. I've added it to the latest draft. Please take the time to review it. [ [if it's ] A content element: ... 7. If the encoding attribute is used, then let content-encoding be the result of applying the rule for getting a single attribute value to the value of the encoding attribute. If the character encoding represented by the value of content-encoding is supported by the user agent, then let the start file encoding be the value of content-encoding. If content-encoding is an empty string or unsupported by the user agent, then a user agent must ignore the encoding attribute. 8. If the type attribute is used, then let content-type be the result of applying the rule for getting a single attribute value to the value of the type attribute. If the value of content-type is a media type supported by the user agent, then let the start file content-type be the value of content type. If value of content-type is invalid or unsupported by the user agent, then a user agent must treat the widget package as an invalid widget package. 9. If the start file encoding was set in step 7 of this algorithm as a result of processing a valid and supported value for the content element's encoding attribute, then skip this step in this algorithm. Otherwise, if the value of content-type is a media type supported by the user agent and if content-type contains one
Re: Seeking pre-LCWD comments for: Server-sent Events, Web {Database, Sockets, Storage Workers}; deadline 19 November
Hi All, On Nov 4, 2009, at 8:46 AM, Barstow Art (Nokia-CIC/Boston) wrote: As noted on 23 October [1], the following "HTML5 APIs" are ready or very close to being ready for Last Call Working Draft (LC): 1. Server-Sent Events http://dev.w3.org/html5/eventsource/ 2. Web Database http://dev.w3.org/html5/webdatabase/ 3. Web Sockets API http://dev.w3.org/html5/websockets/ 4. Web Storage http://dev.w3.org/html5/webstorage/ 5. Web Workers http://dev.w3.org/html5/workers/ Based on the responses for this call for comments, I see the next steps as: 1. Server-sent Events, Web Storage and Web Workers - ready for LCWD publication. Later today I will begin a CfC to publish LCWD of these three specs 2. Web Sockets API - the group should discuss Adrian's comments: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 0842.html 3. Web Database - there is sufficient interest to keep this spec on the Recommendation track. However, there is an open question about who will commit to drive this spec, in particular who will commit to being its Editor. Hixie - would you please explain your intent/ position here? -Art Barstow
Re: [widgets] About the test suite
Hi Robin, Robin Berjon a écrit : On Nov 14, 2009, at 04:30 , Marcos Caceres wrote: Also, we are working on an implementation of the widget spec but we don't have support for HTML, only SVG. The tests are currently designed with HTML start files. Would it be possible to have alternative versions with SVG start files ? Sure! I'm happy to include that. However, I will need your help to make that happen. If you can commit some time, then we can talk about how we get SVG as a standard part of the test suite. WDYT? That should actually be reasonably trivial. Most of the HTML documents in the test suite are the same green/red/grey documents. It's easy to make the same in SVG, and then replace all the HTML documents with the same hash with their corresponding SVGs, renaming the .html in the config files. That should leave a few to change manually, but nothing horrible. Yes I agree, that should not be difficult, I've already manually created the green/red SVG files. But I was wondering about the order given in the default start files table. For example, if a widget package contains both a index.htm and index.svg, is the UA required to use index.htm ? If this is the case we need to duplicate the tests. If not, we can add the SVG files and use a single test (for most cases). Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Département Traitement du Signal et Images /Dept. Signal and Image Processing Ecole Nationale Supérieure des Télécommunications 46 rue Barrault 75 013 Paris, France http://tsi.enst.fr/~concolat
RE: Security evaluation of an example DAP policy
Hi Jonas, Thanks for your comments. The below policy actually blocks access to all device APIs for all websites (up to bugs in the RE, now I think it should be /.*/ instead of /.+/), thus actually expresses the currently applied policy available in the browsers. I.e. it already works to some extent :) I assume the clear arguments raised in this mail thread will be very helpful for DAP and BONDI. Handling data exchange between scripts and OS via element with explicit user consent is another paradigm that I believe will be explored. We could think of some mapping of the APIs from/to to be able to realize functionally same scenarios with minimal change of the code. E.g. would be a kind of equivalent to addressbook.getContact() or so. The differentiation could be as above, but the properties of the objects retrieved by both above scenarios could match for easy integration. Personally I perceive it as a design pattern. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Friday, November 20, 2009 2:04 AM To: Marcin Hanclik Cc: Maciej Stachowiak; Adam Barth; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: Security evaluation of an example DAP policy On Thu, Nov 19, 2009 at 4:49 PM, Marcin Hanclik wrote: > Hi Jonas, Maciej, > > It seems that the policy that you would accept would be: > > > > > > > > > > > /.+/ > > > > > > Let's see how DAP will evolve then. Given that I don't know the specifics about this policy format I can't comment on the above policy specifically. However I will note that the security experts at Mozilla did agree that opening a non-modal dialog asking for access to geo-location was considered acceptable, as I noted in a previous email. I don't know what effect that has on the above policy. I don't know what policy other browsers have used in this area. / Jonas 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.
Unzipping content into current directory widely considered poor practice
Hello, I understand from http://www.w3.org/TR/2009/WD-widgets-20091029/ that this is the place to direct my feedback on the widget packaging spec, and that I have missed the Last Call deadline by one day. I hope you will consider my plea anyway, since it is based on evaluation of an implementation I only discovered last night. See below for an issue I tried to raise with the implementor. It seems W3C Widget zip packages unload a mess of several files in the current working directory when unzipped. This is unfortunate and I urge you to consider a design that allows things to be kept in a single subdirectory. 1. the dominant convention in modern software development is that you can safely unwrap a .zip or .tar.gz in the current working directory, in the expectation that you'll find only a sensibly named subdirectory. Those who violate this expectation are often seen as making a basic beginners mistake. Encoding such a 'mistake' in a W3C REC both looks bad, and encourages bad practice. 2. by risking a mixup between pre-existing files and those from the archive file, we introduce the risk of confusion and inclarity, making widgets ever slightly harder to learn from. And or those who do try to learn from others works, we reward them by making a mess of their filetree. Assuming 1000 new developers decide each day to explore W3C Widget technology and learn by example, I expect 900+ of them will come with the reasonable assumption that a zip file can be safely unpacked in a directory that has already got other stuff in it (including possibly files with common names like index.html). Mixing up files will be annoying; accidentally overwriting files will be infuriating 3. Are we confident that all unzip tools will ask nicely before overwriting existing files? A quick test on my machine at least gave me a warning. eg. TellyClub:~ danbri$ mkdir w3ctest TellyClub:~ danbri$ cd w3ctest/ TellyClub:w3ctest danbri$ echo 'my original valuable html document' > index.html TellyClub:w3ctest danbri$ curl -Os http://berjon.com/tmp/a-widget.wgt TellyClub:w3ctest danbri$ unzip a-widget.wgt Archive: a-widget.wgt inflating: config.xml inflating: icon.svg creating: img/ inflating: img/me.jpg replace index.html? [y]es, [n]o, [A]ll, [N]one, [r]ename: Thanks for considering my request. cheers, Dan -- Forwarded message -- From: Date: Fri, Nov 20, 2009 at 9:24 AM Subject: Re: Issue 4 in widgeon: test widget unzips in current directory To: danbrick...@gmail.com Updates: Status: Invalid Comment #1 on issue 4 by robin.berjon: test widget unzips in current directory http://code.google.com/p/widgeon/issues/detail?id=4 That is something that is imposed on us by the Widgets spec, so you'd have to complain to Marcos I'm afraid. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
