RE: [widget] technology/specification name

[Marcin Hanclik]

The problem with widgets is that the name conflicts (or is a bit different
angle) with the UI widgets (or controls) that are also in use (e.g.
wxWidgets, GTK widgets etc.). We could invent some other name (WAF,
WebApplicationPackaging etc. as people quote already), but ...

On the other hand many people already talk W3C widgets. W3C widgets as
the spec name is used in many other specs, not only W3C ones.

Thus I suggest keeping the name as it is. Changing it now could confuse
the industry even more and will not help, I think.

BTW: There are also NetFront Widgets :)

Thanks,
Marcin

-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org]
On Behalf Of Scott Wilson
Sent: Thursday, June 23, 2011 8:18 PM
To: Dave Raggett
Cc: Karl Dubost; public-webapps@w3.org; Bruce Lawson
Subject: Re: [widget] technology/specification name

Part of the issue is that its a fairly generic technology that can be
applied to areas including:

- Browser extensions
- Installable web apps
- Desktop widgets
- Site gadgets
- TV/STB widgets
- Mobile webapps

I think the name widgets came from the heritage of Opera Widgets, Nokia
Widgets, Apple Dashboard Widgets (etc). Personally I don't think its all
that bad as a name, but I don't feel especially attached to it either. If
there is a better option, lets go for it.

On the other hand, if there are barriers to adoption other than branding,
lets address them. Unfortunately, I suspect a fair amount of it is just
NIH syndrome.

S

On 23 Jun 2011, at 17:26, Dave Raggett wrote:

 In the webinos project [1] we are using installed vs hosted web apps.

 On 23/06/11 15:58, Karl Dubost wrote:
 I do not want to start a name bikeshedding.
 The name doesn't bother me so far, but I have seen that comment again
and again.

 On Thu, 23 Jun 2011 14:06:24 GMT
 In Bruce Lawson's personal site : Installable web apps and
interoperability
 At
http://www.brucelawson.co.uk/2011/installable-web-apps-and-interoperabilit
y/

 Installable apps (in W3C parlance, Widgets - which
 is a terrible name) allow authors to write apps
 using HTML(5), CSS, JavaScript, SVG etc, and
 package them up into a glorified Zip file with
 some configuration details which can then be
 installed on a computer.

 It seems that extensions or addons would be more cognitively
connected with Web developers.

 y'know, so terrible is the W3C Widgets name
 that I didn't even think it referred to the
 same thing as Chrome's apps, et al.
 - http://twitter.com/nevali/status/83866541388603392

 [1] http://webinos.org/

 --
 Dave Raggettd...@w3.org  http://www.w3.org/People/Raggett

RE: [widgets] rename View Mode Media Feature spec

[Marcin Hanclik]

+1 to carelessness.
Are we going to have a media feature catalogue in the future?

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Robin Berjon
Sent: Wednesday, May 19, 2010 2:42 PM
To: Marcos Caceres
Cc: public-webapps
Subject: Re: [widgets] rename View Mode Media Feature spec

On May 18, 2010, at 10:45 , Marcos Caceres wrote:
 Can we please rename the View Mode Media Feature to The 'view-mode' media 
 feature? The current name of the spec is confusing [me].

Ooh, a naming discussion!

I'll be completely honest: I couldn't care less. Since you want it, if no one 
else objects I'll make the change.

--
Robin Berjon - http://berjon.com/







Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Kiyoyasu Oishi, 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: JS crypto?

[Marcin Hanclik]

Hi Ben, Vivek, Nathan,

Great thanks for your reviews!
I am forwarding your comments (or pointers to them) to the Bondi ML and the 
authors of the API.
I am sorry, but due to time constraints I am not able now to dive deeper into 
the comments (although I'd love to :) ).

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Nathan
Sent: Thursday, May 13, 2010 6:24 PM
To: Vivek Khurana
Cc: public-webapps
Subject: Re: JS crypto?

Vivek Khurana wrote:
 On Wed, May 12, 2010 at 10:24 PM, Marcin Hanclik
 marcin.hanc...@access-company.com wrote:
 Hi Nathan,

 This seems to be the current related standardization effort:
 http://bondidev.omtp.org/1.5/crypto.html
 =
 http://bondi01.obe.access-company.com/1_5_5602_145/crypto.html

  I think the OP request is much larger than this. Bondi is restricted
 to widgets and mobile browsers, while having crypto support built into
 the browser has several advantages for web applications in general.
  If we plan to take this up, I can provide couple of use cases to support 
 this.

 regards
 Vivek


snap, there were a few good use-cases in the original mail, but I could
produce many more.

what's needed (or what I can see people making use of ever increasingly)
is two levels:

1: UA support for crypto functions, specifically
openssl_open/seal/hash/verify and generating key pairs

2: the same exposed to javascript

:)

ps: I don't know what use I could be other than adopting immediately and
testing very heavily.

Best,

Nathan





Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Kiyoyasu Oishi, 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: JS crypto?

[Marcin Hanclik]

Hi Nathan,

This seems to be the current related standardization effort:
http://bondidev.omtp.org/1.5/crypto.html
=
http://bondi01.obe.access-company.com/1_5_5602_145/crypto.html

Past related efforts were less robust (just signText in WMLScript) in 
http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-161-wmlsscriptcrypto-20010620-a.pdf

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Nathan
Sent: Wednesday, May 12, 2010 6:31 PM
To: Jeremy Orlow
Cc: public-webapps; art.bars...@nokia.com; foaf-protocols
Subject: Re: JS crypto?

Arthur:
Thanks for pointing me in the right direction [1] :)

Jeremy:
Fully agree re the right time to explore the possibility.

I can think of many, many use cases - particularly in conjunction with
work that's going on in the social, swxg, foaf, foaf-protocols, linked
data, and read write web camps.

With foaf+ssl we have public keys in profiles used for authentication
over HTTPS where the user has a certificate installed in the browser,
since the public key is available it leads the way to encrypted
communication over http between two parties, and also mounting
information on the web which is encypted with those public keys, making
it safe and secure - obviously if one where to pass the private key in
to a server side application then security would be somewhat flawed,
however if it's in the browser then this paves the way for almost
infinite uses - including many web of trust related functions
(particularly with signing resources exposed by uris).

So whilst usage may be somewhat low, I fully envision need and usage
rising exponentially over the next few years and onwards, so a
relatively early start at standardisation would indeed be a very good thing!

[1] http://lists.w3.org/Archives/Public/public-web-security/

Best,

Nathan


Jeremy Orlow wrote:
 This came up not too long ago in the context of persistent storage.  The
 verdict (IIRC) was that we're not interested in adding crypto just to
 the persistent storage APIs, but that we might be interested in adding a
 general crypto API.

 Does anyone have any data for how widely used window.crypto and/or JS
 library alternatives are?  If they aren't widely used, maybe it's worth
 seeing if we can find use cases for crypto in the browser that aren't
 satisfied by JS libraries?

 To answer your question, I'm not aware of any existing standardization
 efforts, but I think the time might be right to explore the possibility.

 J


 On Wed, May 12, 2010 at 5:09 PM, Nathan nat...@webr3.org wrote:

 Hi All,

 Unsure if this is the best place to ask, but is there currently any JS (or
 user agent) support for cryto functions such as sign/seal/encrypt/decrypt?

 Perhaps a working group, a draft, anything?

 I would be very keen to see crypto support in all the browsers standardized
 and methods exposed to JS.

 For instance, if you have your public key on the web somewhere, I should be
 able to seal a document using it, publish it on the web, and know that if
 you visit that uri in your browser that it will decrypt it using the private
 key from a certificate you have installed in the browser.

 Best  thanks in advance for any response,

 ps: aware of window.crypto in firefox/gecko

 Nathan








Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Kiyoyasu Oishi, 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.

Regrets, RE: [widgets] Draft minutes from 11 February 2010 voice conference

[Marcin Hanclik]

Hi,

I will not be able to join the call this Thursday.

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Arthur Barstow
Sent: Thursday, February 11, 2010 6:14 PM
To: public-webapps
Subject: [widgets] Draft minutes from 11 February 2010 voice conference

The draft minutes from the 11 February Widgets voice conference are
available at the following and copied below:

  http://www.w3.org/2010/02/11-wam-minutes.html

WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before 18 February (the next
Widgets voice conference); otherwise these minutes will be considered
Approved.

-Art Barstow

[1]W3C

   [1] http://www.w3.org/

- DRAFT -

  Web Applications Working Group Teleconference

11 Feb 2010

[2]Agenda

   [2] http://lists.w3.org/Archives/Public/public-webapps/
2010JanMar/0532.html

See also: [3]IRC log

   [3] http://www.w3.org/2010/02/11-wam-irc

Attendees

Present
   Art, Robin, Bryan, StevenP, Marcos, Arve, Doug

Regrets
   Stephen_Jolly, David_Rogers, Marcin_Hanclik

Chair
   Art

Scribe
   Art

Contents

  * [4]Topics
  1. [5]Review and tweak agenda
  2. [6]Announcements
  3. [7]PC spec: Important Test Suite Updates
  4. [8]PC spec: Action-486: Create ITS test case(s) for the
 PC test suite
  5. [9]Widget Interface spec: openURL() security considerations
  6. [10]Widget Interface spec: general comments by Cyril
 Concolato
  7. [11]Widget Interface spec: window object comments by Cyril
 Concolato
  8. [12]TWI spec: test suite
  9. [13]AOB: charter renewal
 10. [14]AOB: ISO's MPEG-U and Widgets
  * [15]Summary of Action Items
  _

trackbot Date: 11 February 2010

scribe ScribeNick: ArtB

scribe Scribe: Art

scribe Meeting: Widgets Voice Conference

Date: 11 February 2010

Marcos member:Zakim, +1.479.524. is me

scribe Meeting: Widgets Voice Conference

Marcos bah

Review and tweak agenda

AB: yesterday I sent out the draft agenda for this meeting (
[16]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/05
32.html ). Are there any change requests?
... we will add MPEG-U discussion to AOB (
[17]http://mpeg.chiariglione.org/working_documents/mpeg-u/pt1.zip )
... we will drop 5.a discuss Action-490 (
[18]http://www.w3.org/2008/webapps/track/actions/490 ) since I
hoping to get to it before this meeting but did not and thus have
nothing to report.
... any agenda change requests?

  [16] http://lists.w3.org/Archives/Public/public-webapps/
2010JanMar/0532.html
  [17] http://mpeg.chiariglione.org/working_documents/mpeg-u/pt1.zip
  [18] http://www.w3.org/2008/webapps/track/actions/490

[ no ]

Announcements

AB: two normative refs in Widgets DigSig to XML Signatures specs
entered LCWD on Feb 4 (
[19]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/05
31.html ). Any other short announcements?

  [19] http://lists.w3.org/Archives/Public/public-webapps/
2010JanMar/0531.html

PC spec: Important Test Suite Updates

AB: last week Marcos mentioned he would add a new test case to the
PC test suite. He has done that (
[20]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/04
85.html ). Thanks Marcos! What is the status of people running this
new test?

  [20] http://lists.w3.org/Archives/Public/public-webapps/
2010JanMar/0485.html

MC: it has been run by Aplix, BONDI, Wookie have all run this new
test and passed it

AB: wrt the PC Interop Report, are we back to 3 impls that pass
100% of the test suite?

MC: yes, that is correct

PC spec: Action-486: Create ITS test case(s) for the PC test suite

AB: Marcos, what is the status of the PC ITS testing and Action-486
( [21]http://www.w3.org/2008/webapps/track/actions/486 )?

  [21] http://www.w3.org/2008/webapps/track/actions/486

MC: I haven't done that yet

AB: do you need some help wrt coordinating with the I18N WG?

MC: no, I just need to create the test or tests
... it's not that much work
... I don't think it should block us from going to PR

AB: I agree but we know the Director has indicated he would like to
see that test
... do you need an impl of ITS to test the tests?

MC: yes, that is correct
... I am not aware of any impl that will support it
... it is indeed optional

AB: would like SP to help us with the process here

SP

RE: [widgets] Draft Agenda for 11 February 2010 voice conf

[Marcin Hanclik]

Hi,

I will not be able to join the telco this time.

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Arthur Barstow
Sent: Wednesday, February 10, 2010 2:30 PM
To: public-webapps
Subject: [widgets] Draft Agenda for 11 February 2010 voice conf

Below is the draft agenda for the 11 February Widgets Voice
Conference (VC).

Inputs and discussion before the VC on all of the agenda topics via
public-webapps is encouraged (as it can result in a shortened
meeting). Please address Open and Raised Issues and Open Actions
before the meeting:

  http://www.w3.org/2008/webapps/track/products/8

Minutes from the last VC:

   http://www.w3.org/2010/02/04-wam-minutes.html

Logistics below.

-Regards, Art Barstow

Agenda:

1. Review and tweak agenda

2. Announcements

a. LC of XML Signatures spec published 4 Feb:
  http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/
0531.html

3. Packaging and Configuration spec
  http://dev.w3.org/2006/waf/widgets/

  CR Implementation Report:
  http://dev.w3.org/2006/waf/widgets/imp-report/

a. Important Test Suite Updates by Marcos
  http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/
0485.html

b. Action-486: Create ITS test case(s) for the PC test suite
  http://www.w3.org/2008/webapps/track/actions/486

4. Widget Interface spec
  http://dev.w3.org/2006/waf/widgets-api/

a. API - openURL security considerations by Marcos
  http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/
0501.html

b. TWI: comments by Cyril
  http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/
0479.html

c. window object by Cyril
  http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/
0476.html

5. Access Requests Policy (WARP) spec
  http://dev.w3.org/2006/waf/widgets-access/

a. Action-490: [AB to] Work with MC, RB and Dom on creating a
infrastructure to test the WARP spec
  http://www.w3.org/2008/webapps/track/actions/490

6. AOB

a. Charter renewal - please send comments to public-webapps:
  http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/
0493.html

Comments from Scott Wilson:
  http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/
0525.html


Logistics:

  Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00
Boston; 06:00 Seattle
  Duration: 90 minutes max
  Zakim Bridge: +1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152
  PIN: 9231 (WAF1);
  IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/
member-bin/irc/irc.cgi
  Confidentiality of minutes: Public






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: [WARP] Use cases for local network access

[Marcin Hanclik]

Hi Arve,

Alternatively, should fine-grained distinction between the three, these
could alternatively be keywords in the existing origin attribute.
+1
It matches the proposal at http://dev.w3.org/2006/waf/widgets-access-upnp/, 
although the name of that document is misleading.

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Arve Bersvendsen
Sent: Thursday, February 04, 2010 4:16 PM
To: Stephen Jolly; public-webapps@w3.org
Subject: Re: [WARP] Use cases for local network access

On Tue, 02 Feb 2010 19:09:26 +0100, Stephen Jolly
stephen.jo...@rd.bbc.co.uk wrote:

 All,

 As actioned in the 21st Jan teleconference, here are the use cases that
 have motivated my specific proposal for supporting local network access
 in the WARP spec (see
 http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0173.html
 for details).

 1. A developer wishes to write widgets that can connect to the web API
 exposed by a network-connected television or personal video recorder
 (aka digital video recorder) on their home network.  This API allows
 (for example) the channel being viewed to be changed or the list of
 scheduled recordings to be modified, via a user interface presented by
 the widget.

During this teleconference, I was asked to elaborate my position on this
topic.  The advantage of creating a definition of a local network is the
following variant of the use case:

A developer wants to write a widget that posts whatever channel the user
switches to on a network-connected TV to http://μblogging.example.com/.
The problem, with WARP as is that, since the network address of said TV is
indeterminate, the developer's only option is to allow the widget to
connect to any URL it wishes (specifying '*' in origin, or add a large
(read: huge) set of origins in order to be able to do this.

My proposal would be to add a second attribute to the specification, a
boolean, such as origin-local, which would replace any IP address the user
agent considers to be local, link-local or even local-machine addresses.
Alternatively, should fine-grained distinction between the three, these
could alternatively be keywords in the existing origin attribute.



--
Arve Bersvendsen

Opera Software ASA, http://www.opera.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.

[widgets][vmmf] clarifications

[Marcin Hanclik]

Hi All,

I have modified the VMMF draft at http://dev.w3.org/2006/waf/widgets-vmmf/ and 
merged the comments from Vodafone after reviewing them.
I have the following questions that I would like to agree on (the VMMF text 
highlights the corresponding content):

1. Does the interactivity affect the value of disabled attribute of the 
instances of the HTMLInputElement in the document? (I assume yes)

2. Does the interactivity affect the :enabled and :disabled 
pseudo-classes? (I assume yes)

3. Since opacity property in CSS affects the rendered elements' tree, it 
seems we cannot use opacity on body element to make it transparent. What 
about defining new property (e.g. transparent: on | off) that would be 
applicable on body element only? Then the transparency would depend on the 
content and not on the view-mode, thus it would limit the necessity for 
additional values. For example, I would like to have the widget behave like 
fullscreen or mini, but the transparency could depend on the content.

4. Should we use the DOM0 objects in the spec? It seems to be clearer to the 
readers, but the objects / methods / attributes are not normatively documented.

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] View Modes Media Feature document from Vodafone

[Marcin Hanclik]

Hi Art, All,

I am sorry for my delayed response re VM-MF/-I.

I will be happy include the proposals from Vodafone into the original documents.
The interface parts will go into VMI, I think.

In [1] I promised deeper review of the VM principles (CSS, CSSOM) and this task 
is still pending on me.
I will do my best to provide it in the first half of January.

Re the document itself:
Taking into account the OneWeb principle, I think we should not distinguish in 
the VMMF definition whether the widgets run on PC/PDA/TV etc.
This differentiation is already captured in the CSS medias. Therefore VMMF 
should provide more generic definitions of the values.
I consider defining new media features to support the properties behind VMMF 
(like interactivity, size control, chrome visibility) and making view modes a 
kind of defined vectors over those media features. There could be possibility 
to include the media features individually or via view-mode.
I outlined this early idea in [2] and it needs a further review as above.

It seems to be my last email on this list this year,
so herewith I wish everybody
Merry Christmas and a Happy New Year 2010.

Thanks,
Marcin

[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0833.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0047.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: Friday, December 18, 2009 2:19 PM
To: public-webapps
Subject: Re: [widgets] View Modes Media Feature document from Vodafone

On Dec 14, 2009, at 8:19 AM, Barstow Art (Nokia-CIC/Boston) wrote:

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

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

 Robin - what's the status of this doc?

Robin reported yesterday this document is an input to the group: the
media features text for the View Modes Media Features spec and the
interfaces for the View Modes Interfaces spec.

Please review this input and submit comments to the mail list.

-Art Barstow





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.

Regrets

[Marcin Hanclik]

Hi,

I will not be able to attend the call tomorrow.

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: [public-webapps] Comment on Widget URI (7)

[Marcin Hanclik]

Hi Larry,

WOW:
It's a pity you were not involved in the discussions around PC's version 
attribute.

Thanks,
Marcin

From: public-webapps-requ...@w3.org [public-webapps-requ...@w3.org] On Behalf 
Of Larry Masinter [masin...@adobe.com]
Sent: Wednesday, December 09, 2009 7:20 PM
To: Robin Berjon
Cc: public-webapps@w3.org
Subject: RE: [public-webapps] Comment on Widget URI (7)

FWIW, just to be clear:

My comments about versioning and version numbers only apply
to the URI scheme, and not to language specifications in
general.

I haven't reviewed any of the other WebApps documents,
except in the context of reviewing the URI scheme.

In general, I support appropriate use of version numbers in
languages and language specifications, especially since
documents and file formats have ample opportunities for
in-band version indicators. It's unfortunate that URIs,
being compact strings, have no place for version indicators.

Larry
--
http://larry.masinter.net


-Original Message-
From: Robin Berjon [mailto:ro...@berjon.com]
Sent: Thursday, November 19, 2009 4:08 AM
To: Larry Masinter
Cc: public-webapps@w3.org
Subject: Re: [public-webapps] Comment on Widget URI (7)

Dear Larry,

thank you for your comments.

On Oct 10, 2009, at 19:44 , Larry Masinter wrote:
 7) ** EDITORIAL TITLE **
 Widgets 1.0: Widget URIs the 1.0 might imply some kind of versioning, but 
 there is no versioning of URI schemes.

 Suggestion: retitle Widget URIs

I have provisionally made this change. I agree with Marcos that it would be 
good to do so throughout the widget family of specifications, especially since 
there is no reason why versions of its various components need to evolve in 
synchronised fashion - one could use P+C 4.2 with WARP 2.7.

Recommendation to the WG: apply the same change throughout.

--
Robin Berjon - http://berjon.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] comments re View Modes Interface spec

[Marcin Hanclik]

Hi Yael, Art,

Thanks for your comments.

Below are my comments and refining questions.
Please let me know what you think.

Below are some comments from Yael re the View Modes Interface spec:

  http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html

-Art Barstow

= Section 3.1:

Interface Media:

1. Interface Media is also defined in CSSOM (4.1), and the definition
is not consistent.
I cannot find the definition of the interface Media in CSSOM in section 4.1.
Did you mean 4.4 interface MediaList (also in DOM2CSS) and mediaText attribute?
mediaText is the same as Media, but it has just different syntax.
Therefore I would opt for removal of the Media interface.

I think it should be defined in one spec, and the
other spec should refer to that.
Agreed. Alignment will require discussion with Anne.


2. onTypeChanged attribute is defined to be an event. Usually,
onXXchanged attributes are defined as event listeners, I think this
is a mistake.
Agreed.
I am thinking about removal of this attribute.
The events are dispatched on the Document, therefore event handler/listener 
seems not needed.
Any thoughts?


3. The descriptions of the attributes type and ontypechanged
under the IDL definition are swapped.
Fixed.

Interface ViewCSS:

1. Interface ViewCSS is also defined in DOM2-CSS (2.2.1), and the
definition is not consistent. I think it should be defined in one
spec, and the other spec should refer to that.
Since CSSOM is to replace DOM2CSS, I assume we should refer to CSSOM.
I think we need to discuss this: DOM2CSS is CR, CSSOM is ED.

= Section 3.2:

1. I do not understand the use-case for changing media type.
According to CSS2-Media (7.3), e.g., the act of printing a document
would add a second canvas, and would not change the media type of the
existing canvas.
This depends on UA. E.g. as for printing you could switch the media type, print 
and switch it back.
This use case seems to be intentionally specified as may to give the UAs some 
freedom.
Changing media type within a media group (CSS2-Media 7.3.1) resembles e.g. 
changing resolution and color-depth.
For example, you could switch between print, projection, screen, tty, tv within 
visual media group.

2. I do not understand the use case of creating a
MediaTypeChangedEvent from JavaScript. This comment applies to all
the events that are defined in this specification.
It is quite underspecified at present.
In general the events are triggered once something happens to the UA and UA is 
aware of that (e.g. from OS). E.g. MediaTypeChangeEvent could be triggered if 
the UA gets connected to the projector. In such a case my assumption is (not 
discussed yet in the group) a few events would be triggered (order unknown), 
since not only media type changed but also potentially resolution, orientation 
etc. So my immediate and temporary idea could be to issue just one event 
(instead of the current few events) and let the script check what actually 
happened by means of CSSOM.
Any thoughts on that?

On the other hand, this question may be related to appendMedium/deleteMedium 
when setting mediaText.


3. The pragmas of the links behind Event.initEvent()  are wrong.
They lead to the top of the document DOM3-Events, instead of to the
correct section.
Fixed for initEvent().
initXXXEventNS() were removed from D3E as of its version 1.99 (proposed as a 
new feature, links broken there as well). Since this is a discussion point, I 
will keep the initXXXEventNS() BROKEN as they are; I marked them as a proposal 
(in yellow as is D3E).


= Section 3.4:

1. The media feature Resolution is defined in CSS3-Media-Queries
 (4.11) as density of the pixels, e.g. DPI. It is very confusing to
reuse the same name (resolution) for something completely different.
Agreed.
There is a related mail thread [1] in which this topic is discussed.
Nevertheless I think that ResolutionChangeEvent would be helpful to notify 
about the changed resolution (in its original sense).

BTW: Actually also the term media type has different meanings (PC vs. CSS), 
but in this case I think of saying CSS media type.


2. Would ResizeEvent be sufficient instead of adding the new event
ResolutionChangedEvent ?
What about SizeChangedEvent? Just for naming consistency.



= Section 3.5:

1. Copy/paste error in multiple places where media type is used
instead of orientation.
This was fixed as of VMI 1.3 [2].


2. iphone's orientation events use degrees instead of
 landscape/portrait. That allows developers to know if the handset
is held upside-down.
Good point. I think CSS / CSSOM should be upgraded first.
The general model is that VMI refers to CSSOM wherever possible to keep 
consistency.

Thanks,
Marcin

[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0764.html
[2] 
http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets-vm/vm-interfaces.src.html?rev=1.3content-type=text/html;%20charset=iso-8859-1




Access Systems Germany GmbH
Essener Strasse 5  |  

RE: [widgets] CfC: to publish LC#2 of the WARP spec; deadline 2 December

[Marcin Hanclik]

Hi Marcos,

You once accused us of being a kindergarten, and now you are asking us
to willfully violate the process?
Well :), I do not want to remember those multi-context discussions.

We have already aligned.
Thanks.

Maybe... I recommend that you formally re-raise the local pattern
issues once we publish LC#2 or continue working on your new spec
(which Opera supports, btw)... but please, remove all duplicate text
and keep is short, as Robin suggested.
Ok, I will re-raise in LC#2 or discuss how to bring them back a kind of 
automatically.
The delta spec will be short.

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, December 03, 2009 1:23 PM
To: Marcin Hanclik
Cc: Arthur Barstow; Robin Berjon; public-webapps
Subject: Re: [widgets] CfC: to publish LC#2 of the WARP spec; deadline 2 
December

On Wed, Dec 2, 2009 at 11:58 PM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
 Hi Art, Robin, Marcos,

 Thanks for your comments.
 Here is the consolidated answer.

 Just to clarify:
 I do not think that we should be so strict about the dates regarding the 
 arrival of the comments.

If we were not strict, we would never publish. We are strict because
we get consensus on a draft from either 1) the WG or 2) in the case of
CR+, the Director and the Chairs.

 The flexibility is already present for many of the WebApps WG's 
 specifications.

Only for typos, simple clarifications, and all non-normative text.
Art, being responsible for how this working group functions and
adheres to the W3C Process, makes sure of that.

You once accused us of being a kindergarten, and now you are asking us
to willfully violate the process?

I believe all of the comments submitted during the LC#1 comment
period (that ended 20-Sept-2009) were addressed. Since you indicate
otherwise, please clearly identify any comment submitted during the
LC comment period that was _not_ addressed.
 Yes, as far as I can tell all the comments provided in the LC#1 period were 
 already addressed.
 It is my oversight to name the comments that arrived later as received within 
 LC#1 period.
 I have just assumed that all comments - also those received after LC period - 
 should be addressed.


Of course all emails will be addressed; we are not monsters. We
address all emails that come in and never ignore an email. However, we
are under no obligation to include those emails as part of the LC
process.

 As indicated earlier in this mail thread, the comments that in my opinion 
 need technical answers stem from the mail thread [1].
 They arrived after LC#1.


Than they shall be addressed in the period between LC1 and LC2. But
will be part of neither unless they require a substantive change in
LC2.

 Technically the comments in [1] are about the flexibility of expressing the 
 URIs by means of a pattern.
 [2] from Scott Wilson backs it up, although we seem to agree that regular 
 expression is better name for the syntax.
 [3] from Stephen Jolly is about local network.
 [4] from Phil Archer about using POWDER.
 [5] from Bryan Sullivan about semantics of the special value U+002A ASTERISK 
 (*).

 Some other comments started in [5] were already addressed.

 From the comments [1]-[5] I derive that the general use case that people are 
 asking for from WARP is the ability to flexibly (by some pattern / regexp) 
 define the value of @origin attribute that later is to be applied to define 
 some kind of local or private network, either by means of domain names 
 (addressed in the current WARP based on the @subdomains attribute) or by IP 
 addresses (not possible to realize efficiently based on the current WARP).
 Given the above use case, I think that the special value local could 
 address it and together with @subdomains attribute covers all but one ([5]) 
 from the above comments.

 In the light of LC#2 it seems that the my comments to CfC could be summarized 
 as:

 Do the comments that arrived after the LC#1 deadline have to be repeated by 
 their authors to get into LC#2 review (I assume not, but it is unclear to me).


Comments should be addressed and we should leave it to the editor and
chair to decide which comments become part of the Disposition of
Comments. Regardless, all comments will be addressed. Robin has always
addressed every comment that has come in.

 If not, then I assume they will be addressed in the LC#2 and I should not 
 worry.

Yes, you can rest easy:)

 Additionally, I may be (again) wrong, but I assume that LC#2 should start 
 once the group internally is aligned with regard to the already received 
 comments.


We have already aligned. Hence this being public call for consensus.
You still have not presented any valid reasons to progress LC#1 to
LC#2.

 http://dev.w3.org

RE: [WARP4U] WARP with UPnP, was: RE: [widgets] Draft Minutes for 19 November 2009 Voice Conference

[Marcin Hanclik]

I agree with the principle.
I hope this approach could propagate to other specs and WGs, like Geo API etc.
It is probably too late for some other specs, though.

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: Thursday, December 03, 2009 6:10 PM
To: ext Robin Berjon
Cc: Frederick Hirsch; Marcin Hanclik; Barstow Art (Nokia-CIC/Boston); 
public-webapps
Subject: Re: [WARP4U] WARP with UPnP, was: RE: [widgets] Draft Minutes for 19 
November 2009 Voice Conference

+1, duplicating material is a recipe for disaster.

regards, Frederick

Frederick Hirsch
Nokia



On Dec 2, 2009, at 8:22 AM, ext Robin Berjon wrote:

 On Dec 1, 2009, at 22:22 , Marcin Hanclik wrote:
 Can you please update this to just be a delta?
 As far as I know W3C specs, delta documents are usually errata or
 WG Notes.

 What we have been calling delta specification in WebApps are
 specifications that add to another. For instance, WARP adds the
 access element to P+C. It doesn't make some huge cut and paste of P
 +C just because it modifies. This is as much about sane editing
 practice and being able to work with a team as it is about clean
 architecture and separation of concerns.

 The expectation was that WARP4U would add something to WARP, perhaps
 attributes, perhaps attribute values, perhaps child elements, and
 certainly some processing. It's a delta spec. It's not considered to
 be the next version, it's a different feature set.

 Therefore I would keep the document as it is.

 I then have to maintain the strongest objection possible to it being
 published, even as FPWD. Such copying is inappropriate, and will
 lead to no end of editorial problems. It fosters confusion and
 brings no value.

 --
 Robin Berjon - http://berjon.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: [WARP4U] WARP with UPnP

[Marcin Hanclik]

Hi Arve, Art,

I am sorry for bypassing earlier comments, I want to answer them anyway asap. 
So here comes short summary.

What are we trying to solve?
Forgetting the UPnP and related stacks, the issues can be summarized as follows:
- pattern for IP addresses in URIs (we have pattern for domains, but nothing 
for IP addresses)

and/or

- possibility to exclude local (definition needed: I proposed to leave it out 
of scope if we cannot agree, but it could be home or corporate network or 
private LAN etc) - network resource from being controlled with access 
element. This acts as a kind of (loosely defined) pattern for IP addresses.

The above would solve the UPnP issue (we could forget it actually), since UPnP 
could be regarded as any other non-Web protocol (DNS etc) that simply delivers 
metadata within which the http URIs to media files are contained.

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: Arve Bersvendsen [mailto:ar...@opera.com]
Sent: Wednesday, December 02, 2009 1:48 PM
To: Arthur Barstow; Marcin Hanclik
Cc: public-webapps
Subject: Re: [WARP4U] WARP with UPnP

On Wed, 02 Dec 2009 13:18:43 +0100, Arthur Barstow art.bars...@nokia.com
wrote:

 It would be helpful to have a clear definition of at least: the problem
 statement, use case(s), requirement(s), security considerations,
 proposed syntax and semantics, UA processing model.

I would propose dropping any syntax and semantics, until we have a proper
definition of the problem. What are we trying to solve?
--
Arve Bersvendsen

Opera Software ASA, http://www.opera.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: [WARP4U] WARP with UPnP, was: RE: [widgets] Draft Minutes for 19 November 2009 Voice Conference

[Marcin Hanclik]

Hi Robin,

The expectation was that WARP4U would add something to WARP, perhaps 
attributes, perhaps attribute values,
perhaps child elements, and certainly some processing. It's a
delta spec. It's not considered to be the next version, it's a different 
feature set.
Ok, I agree. I will then add an excerpt about the local special value and its 
processing model.
It will be potentially extremely short.

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: Robin Berjon [mailto:ro...@berjon.com]
Sent: Wednesday, December 02, 2009 2:22 PM
To: Marcin Hanclik
Cc: Arthur Barstow; public-webapps
Subject: Re: [WARP4U] WARP with UPnP, was: RE: [widgets] Draft Minutes for 19 
November 2009 Voice Conference

On Dec 1, 2009, at 22:22 , Marcin Hanclik wrote:
 Can you please update this to just be a delta?
 As far as I know W3C specs, delta documents are usually errata or WG Notes.

What we have been calling delta specification in WebApps are specifications 
that add to another. For instance, WARP adds the access element to P+C. It 
doesn't make some huge cut and paste of P+C just because it modifies. This is 
as much about sane editing practice and being able to work with a team as it is 
about clean architecture and separation of concerns.

The expectation was that WARP4U would add something to WARP, perhaps 
attributes, perhaps attribute values, perhaps child elements, and certainly 
some processing. It's a delta spec. It's not considered to be the next version, 
it's a different feature set.

 Therefore I would keep the document as it is.

I then have to maintain the strongest objection possible to it being published, 
even as FPWD. Such copying is inappropriate, and will lead to no end of 
editorial problems. It fosters confusion and brings no value.

--
Robin Berjon - http://berjon.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] CfC: to publish LC#2 of the WARP spec; deadline 2 December

[Marcin Hanclik]

Hi Art, All,

ACCESS does not support this publication.
Our motivation is that the comments received during the LC#1 were not all 
addressed.

Since the PAG has started with the earlier draft of WARP and relation to PAG 
was an argument for LC#2, we assume that the group still has time to 
accommodate the LC#1 comments in the present version of the specification 
without the detrimental effect on the proceedings within PAG.

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Arthur Barstow
Sent: Friday, November 27, 2009 3:50 PM
To: public-webapps
Subject: [widgets] CfC: to publish LC#2 of the WARP spec; deadline 2 December

This is a Call for Consensus (CfC) to publish Last Call Working Draft
#2 of:

  http://dev.w3.org/2006/waf/widgets-access/

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 December 2.

For some additional background on this proposal, see:

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

-Art Barstow








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] editing problem

[Marcin Hanclik]

Hi,

I assumed it was corrected with this email:
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0828.html

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Cyril Concolato
Sent: Friday, November 27, 2009 3:44 PM
To: public-webapps
Subject: [widgets] editing problem

Hi Marcos,

Reading the rule for identifying the media type of a file in the editor's 
draft [1], I think there is an editing problem. The first 4 bullets are 
numbered (1,2,3,4) and rest of the bullets are not which makes the algorithm 
refer to step 10 and 11 that don't exist.

Regards,
Cyril

[1] 
http://dev.w3.org/2006/waf/widgets/#rule-for-identifying-the-media-type-of-a0
--
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




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: File writing ponderings (was: Re: Security evaluation of an example DAP policy)

[Marcin Hanclik]

+1 to this idea

The issue is that DAP tries to handle CRUD for multiple types of data.
If we want to consider input type=file/ for reading files, then we may 
think of something like the following potential API design pattern:

a) output type=file/ to possibly trigger File Save As dialog (if it is not 
only to be programmatic) that would also communicate via URN with JS

b) for other types of data we could have input type=contact /, input 
type=event / etc, plus output type=XXX/ for those types.
The output's would be handled by platform specific UIs, similarly to input 
type=file/ handled by File Open Dialog.

BTW:
File Open Dialog (actually any similar Dialog) may be regarded as the prompt 
(oneshot etc) in the policy-based API. This aspect is usually left to 
implementations.
In case of file API the issue is about abstraction of the path with URN. So the 
path could be available in the policy-based approach, whereas only URN would be 
available in the policy-less design.
If the File API changes urn attribute to url, we could handle both already 
now.

Thanks,
Marcin

From: public-device-apis-requ...@w3.org [public-device-apis-requ...@w3.org] On 
Behalf Of Aaron Boodman [...@google.com]
Sent: Saturday, November 21, 2009 9:31 AM
To: Jonas Sicking
Cc: Robin Berjon; Adam Barth; public-device-a...@w3.org; public-webapps WG
Subject: Re: File writing ponderings (was: Re: Security evaluation of an
example DAP policy)

On Sat, Nov 21, 2009 at 12:26 AM, Jonas Sicking jo...@sicking.cc wrote:
 Hmm.. This is a very interesting idea. Definitely worth exploring more.

 What I had in mind was basically something like this:

 1. An API for creating File objects by concatinating strings, Blobs,
 ByteArrays (or whatever they'll be called, see Maciejs proposals to
 public-webapps and public-script-coord). A mimetype and a default name
 (possibly without extension) would also be assigned to the File in
 some fashion.
 2. A API that given a File object brings up the normal Safe File As dialog.

FWIW, this is what I had in mind, too, back when I used to think about
such things.

- a




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

[Marcin Hanclik]

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 input 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 input to be able to 
realize functionally same scenarios with minimal change of the code.
E.g. input type=contact 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
marcin.hanc...@access-company.com wrote:
 Hi Jonas, Maciej,

 It seems that the policy that you would accept would be:

 policy-set combine=deny-overrides
  policy description=Default Policy for websites. Simply denying all API 
 that are covered by some device capability:) 
   target
 subject
   subject-match attr=class match=website func=equal/
 /subject
   /target
   rule effect=deny
 condition
   resource-match attr=device-cap func=regexp/.+//resource-match
 /condition
   /rule
  /policy
 /policy-set

 Let's see how DAP will evolve then.

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.

RE: [Widgets] LCWD#3 comments (2)

[Marcin Hanclik]

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 marcin.hanc...@access-company.com:
 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 content 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 or more [MIME

[widgets] LCWD#3 comments (3)

[Marcin Hanclik]

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 PC :).
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 (3)

[Marcin Hanclik]

Hi Marcos, All,

For the purposes of my LC comments, I am satisfied with the text in PC 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 PC :).
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.

RE: Security evaluation of an example DAP policy

[Marcin Hanclik]

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:

 policy-set combine=deny-overrides
 policy description=
  target
   subject
 subject-match attr=class match=website func=equal/
 subject-match attr=uri.host match=weather.example.com
 func=equal/
   /subject
   subject
 subject-match attr=class match=widget func=equal/
 subject-match attr=install-uri.host
 match=weather.example.com func=equal/
   /subject  /target
  rule effect=deny
   condition combine

[WARP4U] WARP with UPnP, was: RE: [widgets] Draft Minutes for 19 November 2009 Voice Conference

[Marcin Hanclik]

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]PC spec: LCWD#3 comment period ends 19 November
  4. [8]PC 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 Scribe: Art

scribe ScribeNick: ArtB

Date: 19 November 2009

drogersuk I can't hear anything either

arve neither do I

drogersuk that's better

arve now, I'm at least hearing ArtB talk

Steven Doug and I keep ending up on the same call, but no one else

marcin Marcos, :)

Marcos Marcin, quickly check out the email I just sent you

Steven, Doug - we're all here on 9231

Steven 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

marcin 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 PC?

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 ]

PC 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 PC 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] FW: [whatwg] FYI: Mozilla's Resource Packages

[Marcin Hanclik]

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:

link rel=resource-package
 type=application/zip
 href=site-resources.zip /

--
(( 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.

RE: [widgets] LCWD#3 comments (3)

[Marcin Hanclik]

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 PC, another 
time to RFC2616 in XHR (via HTML5).

The above comments are not to be interpreted as part of my PC 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 marcin.hanc...@access-company.com
  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*any (US-ASCII) CHAR except SPACE, CTLs,
 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
 marcin.hanc...@access-company.com 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 PC 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.

RE: [WARP] Comments to WARP spec

[Marcin Hanclik]

Hi Robin,

Great thanks for the descriptive example!

At first I thought that it all depends on the trust model.
The security issue in your example results from the eval that is contained in 
the html within a widget. So we could assume that if the widget is signed we 
could somehow rely on its content. Then the evil eval would maybe not be used 
(at least not in the context you quote).
So we could have the simple distinction between executable content (js, html) 
and non-executable content (img, css [until scripts come there] ).

However, since some images can also be executed, the distinction is de-facto 
void.
Therefore it seems the use case is not doable, because we probably do not want 
to overload the implementations with [SNIFF] algorithms.

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: Robin Berjon [mailto:ro...@berjon.com]
Sent: Wednesday, November 18, 2009 6:37 PM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [WARP] Comments to WARP spec

Hi Marcin,

On Nov 18, 2009, at 14:37 , Marcin Hanclik wrote:
 One could request an
 image that is redirected to 
 http://address/of/image?put+a+complete+script+here
 and then evaluate the query.
 Ok, but then it will still be processed as image and will result in an 
 invalid image, I think.

Not so. Consider the following piece of Perl:

#!/usr/bin/perl
print Location: img.png?alert('I am evil!')\n\n;

And the following HTML:

!DOCTYPE html
iframe src='img.pl' id='pl'/iframe
script
  window.onload = function () {
  
eval(unescape(document.getElementById(pl).contentDocument.location.search.substring(1)));
  }
/script

This produces the expected alert. No script was ever exchanged, and I get the 
image to display perfectly fine.

--
Robin Berjon - http://berjon.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: DAP and security (was: Rename File API to FileReader API?)

[Marcin Hanclik]

Hi Jonas,

I think that it all depends on the user or the abstraction that we seem to have 
about the user.

We can take the analogy to the operating system.
OS may e.g. not be writable for the user, may have pre-defined active firewalls 
etc.
The user then may not access some sites, may not install any native app etc.
The OS or PC is a kind of a toy or a kiosk.

Later, the user switches off firewalls, gets admin rights, installs apps that 
have access to the file system etc.

I think that the same principle is being applied to the browser world.
Policy is to make it all easier and more comprehensible.
The default settings within a browser could e.g. disable directory walking and 
file writing. But if the user changes the settings (and is warned about the 
potential security risks when switching some protection off), then it is up to 
the user and she/he takes over the responsibility.
The abstraction of the security concerns within a policy may allow delegation 
of the security to some third parties.

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: Wednesday, November 18, 2009 9:15 PM
To: David Rogers
Cc: Maciej Stachowiak; Marcin Hanclik; Dominique Hazael-Massieux; Robin Berjon; 
public-device-a...@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)

On Wed, Nov 18, 2009 at 5:27 AM, David Rogers david.rog...@omtp.org wrote:
 Hi Maciej,

 From my side I'd like to understand what your thoughts and proposals for 
 file writing security / policy would entail - would you defer the decision 
 responsibility to the user via a prompt?

From my point of view the answer is unfortunately there are no simple
answers, it's always a judgement call.

For example for the geolocation the security model is basically:

1. Page asks for user position
2. User is faced with a non-modal dialog where he/she can answer yes
or no, or simply ignore the dialog
3. Only if the user answers yes then the position is returned to the page.

In this case I think this was an acceptable solution.

If we added a directory API which gave access to a requested path on
the users hard drive we could use a similar security model:

1. Page asks user for permission to read/write to a specific
directory, say C:\
2. User is faced with a non-modal dialog where he/she can answer yes
or no, or simply ignore the dialog
3. Only if the user answeres yes a reference to the directory is
returned which the page can read from/write to.

This would *not* be an acceptable solution to me, despite being
basically identical to the geolocation case.

The reason is two-fold. I think it's easier to explain to the user
what the user is authorizing (your location), and if a user doesn't
understand and still clicks yes, it has less catastrophic results.

For the directory API though, it's much harder to explain the decision
to the user. What's the C:\ directory? What's the difference between
that and C:\Documents and Settings\Jonas Sicking\My Images? What's a
directory? Also, if a user clicks yes without understanding the
risks, that has catastrophic results if the directory in question is
C:\ and read/write access is granted.

When it comes to security dialogs, the basic rule to keep in mind is
Lots of people are not going to understand it and just click whatever
button they think will get stuff to work, or a random button.

/ 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.

RE: DAP and security (was: Rename File API to FileReader API?)

[Marcin Hanclik]

Hi Maciej,

I think we should separate the policy definition from its application.
We could have a single policy abstraction for browsers/OS vendors and all 
others.
At the risk of oversimplification we could summarize that such abstraction is 
just a list of applicable security concerns.
In some environments some third parties could be responsible for policy 
application (corporate, walled garden etc) within a configurable runtime/OS/etc 
and in the others the policy could be hard-coded and not modifiable (e.g. in a 
freely downloaded browser the browser vendor applies the policy once and 
forever).
Still we could have the same security concerns.

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: Maciej Stachowiak [mailto:m...@apple.com]
Sent: Thursday, November 19, 2009 2:20 AM
To: Frederick Hirsch
Cc: ext Jonas Sicking; David Rogers; Marcin Hanclik; Dominique Hazael-Massieux; 
Robin Berjon; public-device-a...@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)


On Nov 18, 2009, at 5:13 PM, Frederick Hirsch wrote:

 This is a good point, and an argument for policy rather than
 implicit user consent, if I'm not mistaken. It highlights that
 usability might also be an issue with the non-modal interaction
 model,  as well as not always be very meaningful (since I the user
 might have no idea what most directories are for or where to
 navigate). Arbitrary directory navigation for writing files is not a
 good idea.

policy is not a solution to the scenario Jonas posted either. Who is
going to define a home PC or Mac user's browser policy? The user
doesn't have the expertise to do it. There's no sysadmin to do it for
them. And browser/OS vendors should not be in the game of whitelisting
a specific set of sites for extra access.

Regards,
Maciej


 More importantly we have to be careful with analogies.


 regards, Frederick

 Frederick Hirsch
 Nokia



 On Nov 18, 2009, at 3:14 PM, ext Jonas Sicking wrote:

 On Wed, Nov 18, 2009 at 5:27 AM, David Rogers
 david.rog...@omtp.org wrote:
 Hi Maciej,

 From my side I'd like to understand what your thoughts and
 proposals for file writing security / policy would entail - would
 you defer the decision responsibility to the user via a prompt?

 From my point of view the answer is unfortunately there are no
 simple
 answers, it's always a judgement call.

 For example for the geolocation the security model is basically:

 1. Page asks for user position
 2. User is faced with a non-modal dialog where he/she can answer yes
 or no, or simply ignore the dialog
 3. Only if the user answers yes then the position is returned to
 the page.

 In this case I think this was an acceptable solution.

 If we added a directory API which gave access to a requested path on
 the users hard drive we could use a similar security model:

 1. Page asks user for permission to read/write to a specific
 directory, say C:\
 2. User is faced with a non-modal dialog where he/she can answer yes
 or no, or simply ignore the dialog
 3. Only if the user answeres yes a reference to the directory is
 returned which the page can read from/write to.

 This would *not* be an acceptable solution to me, despite being
 basically identical to the geolocation case.

 The reason is two-fold. I think it's easier to explain to the user
 what the user is authorizing (your location), and if a user doesn't
 understand and still clicks yes, it has less catastrophic results.

 For the directory API though, it's much harder to explain the
 decision
 to the user. What's the C:\ directory? What's the difference
 between
 that and C:\Documents and Settings\Jonas Sicking\My Images?
 What's a
 directory? Also, if a user clicks yes without understanding the
 risks, that has catastrophic results if the directory in question is
 C:\ and read/write access is granted.

 When it comes to security dialogs, the basic rule to keep in mind is
 Lots of people are not going to understand it and just click
 whatever
 button they think will get stuff to work, or a random button.

 / 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.

RE: DAP and security (was: Rename File API to FileReader API?)

[Marcin Hanclik]

Hi Adam,

Abstracting the problem doesn't make the security challenges
any easier.
I agree.
The implementations still need to properly code the abstractions, and 
additionally have to properly capture the application of the policy. So the 
work virtually doubles.
The only difference / advantage of having the abstraction is that the way of 
operation is configurable.
That's what the policy is in the nutshell.

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: Adam Barth [mailto:w...@adambarth.com]
Sent: Thursday, November 19, 2009 8:42 AM
To: Marcin Hanclik
Cc: Maciej Stachowiak; Dominique Hazael-Massieux; Robin Berjon; 
public-device-a...@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)

On Wed, Nov 18, 2009 at 6:16 AM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
 The first step is to have the security concerns.
 The widget environment, BONDI etc. then encode them somehow (e.g. as device 
 capability, feature etc.) creating an abstraction.
 In case of the browser, those concerns seem to be simply coded in the browser.
 Still the concerns remain and are handled.
 The widgets spec try to abstract them in order to give the freedom either to 
 the end user, administrator, operator or any other party. Alternatively they 
 could be simply hard-coded in the webruntime.  So the issue is only who is 
 able to specify whether the policy is applied, the concerns are still there.

I'm skeptical that this approach will lead to a secure API for file
access.  Abstracting the problem doesn't make the security challenges
any easier.  The reason the HTML file upload control has been such a
successful secure API for reading files is because the security issues
are specifically *not* abstracted.  The entire API is designed around
the security considerations and eliciting user consent in a
easy-to-understand way.

I suspect we'll need a similarly clever API design to address the
security challenges of letting web content write to the user's file
system.

Adam



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: DAP and security (was: Rename File API to FileReader API?)

[Marcin Hanclik]

Hi Robert,

Thanks for the report!

This model generally does not work on the Web.
What about: “This model generally have not yet worked on the Web”?
Maybe we do not know.
Let’s assume I am an advanced user and I want to create a system that allows me 
to write to arbitrary files and dirs on my PC from the web page, e.g. a walled 
garden solution.
Then I can either take Fx sources, add the APIs, compile and use it, or take 
binary Fx as is, configure the policy and use it.

Taking the analogy to the OneWeb principle [1] (I found that there is also 
OneWeb™) we specify the general security concerns, but their handling would be 
different in various environments (e.g. based on applied policies).

Forcing users to make decisions they do not want to make or cannot make is a 
failure.
I am not sure whether anyone is forcing the user.
The policy may be such that it prompts the user (forces her/him) or it may 
enable/disable the functionality.
If the user does not want to make the decision, then she/he will not 
re-configure the browser.

I think that the API (file walking) selected as the initial example is quite 
unfortunate.
We may really want to disable access to some parts of the file system, for all 
(the policy could say that “C:\Windows\*” is not writable at all).
To overcome this, we may focus on gallery API that could be a selected area 
within a file system.
Then the policy is less about enabling something critical (access to 
“C:\Windows\System”) and more about limiting access to something what we could 
think is generally available.
Let’s take another example then: Bluetooth API.
Some people may want it to be accessible always and the others would like to 
limit that (for any reason).

There are usually no third parties to delegate to.
I have an impression that mobile operators and vendors (i.e. those who want to 
write the actual policies) are eager to take the responsibility.
But I cannot speak for them.

Thanks,
Marcin

[1] http://www.w3.org/TR/mobile-bp/#OneWeb

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: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of Robert 
O'Callahan
Sent: Thursday, November 19, 2009 10:40 AM
To: Marcin Hanclik
Cc: Jonas Sicking; David Rogers; Maciej Stachowiak; Dominique Hazael-Massieux; 
Robin Berjon; public-device-a...@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)

On Thu, Nov 19, 2009 at 10:08 PM, Marcin Hanclik 
marcin.hanc...@access-company.commailto:marcin.hanc...@access-company.com 
wrote:
The default settings within a browser could e.g. disable directory walking and 
file writing. But if the user changes the settings (and is warned about the 
potential security risks when switching some protection off), then it is up to 
the user and she/he takes over the responsibility.

This model generally does not work on the Web. Few users understand settings or 
potential security risks and even fewer care. Lots of studies have shown this 
(e.g. see 
http://groups.csail.mit.edu/uid/projects/phishing/chi-security-toolbar.pdf). 
Forcing users to make decisions they do not want to make or cannot make is a 
failure.
The abstraction of the security concerns within a policy may allow delegation 
of the security to some third parties.

There are usually no third parties to delegate to. If you're mainly concerned 
with intranet applications, you might be able to delegate to corporate 
administrators, but you probably want to avoid that too.

Rob
--
He was pierced for our transgressions, he was crushed for our iniquities; the 
punishment that brought us peace was upon him, and by his wounds we are healed. 
We all, like sheep, have gone astray, each of us has turned to his own way; and 
the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]




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: DAP and security (was: Rename File API to FileReader API?)

[Marcin Hanclik]

Hi Jonas,

Well, great thanks for the very exhaustive report.
It seems we will have to think a lot in DAP.

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: Thursday, November 19, 2009 11:11 AM
To: Marcin Hanclik
Cc: David Rogers; Maciej Stachowiak; Dominique Hazael-Massieux; Robin Berjon; 
public-device-a...@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)

On Thu, Nov 19, 2009 at 1:08 AM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
 Hi Jonas,

 I think that it all depends on the user or the abstraction that we seem to 
 have about the user.

 We can take the analogy to the operating system.
 OS may e.g. not be writable for the user, may have pre-defined active 
 firewalls etc.
 The user then may not access some sites, may not install any native app etc.
 The OS or PC is a kind of a toy or a kiosk.

 Later, the user switches off firewalls, gets admin rights, installs apps that 
 have access to the file system etc.

 I think that the same principle is being applied to the browser world.
 Policy is to make it all easier and more comprehensible.
 The default settings within a browser could e.g. disable directory walking 
 and file writing. But if the user changes the settings (and is warned about 
 the potential security risks when switching some protection off), then it is 
 up to the user and she/he takes over the responsibility.
 The abstraction of the security concerns within a policy may allow delegation 
 of the security to some third parties.

I doubt that we'd spend time on implementing a feature that is
disabled by default out of security considerations.

First of all it'd basically not be worth our time since very few users
change default settings. This is magnified by the fact that very few
websites would use such a feature (since, again, few users change
default settings), so we wouldn't really be improving the web a whole
lot.

Second, users would inevitably turn the feature on without realizing
what security implications it has, meaning that we put a group of
users at risk.

Third, we'll have to spend efforts maintaining the code, even though
it benefits only a small number of people. For example if a buffer
overflow bug is found we'll have to treat that as as serious of a bug
as a overflow in normal on-by-default code. Up to and including
engineering efforts to fix the bug, QA efforts to test the fix,
release resources to spin a new emergency release, and marketing
efforts asking people to upgrade.

I can draw a couple of real-world analogies. In Thunderbird (the email
reader from mozilla), there is support for enabling javascript in
emails. This support is turned off by default. However many people
turn it on, without realizing that this means that someone that sends
you an email can see if you forward this email to anyone, and see what
comments you are adding to that email. All they wanted was javascript
for some other, much more secure, use case.

Additionally, we've having to release *many* security updates
specifically to account for the minority of people that turn on
javascript. We're currently on security update number 23. If we didn't
bother making updates when only people that had turned on javascript
were affected, we would have had a fraction as many updates.

As a result, the next major version of thunderbird is removing the
ability to turn on javascript completely. Not even a hidden preference
exists.


Similarly, there was a preference in Firefox 3 that allowed
XMLHttpRequest to load resources from any site without any security
restrictions. Originally the preference had been added for no
particular reason; why not, it's disabled by default. And intended
to be enabled only on a per-site basis. However due to how some
security architecture works it was possible to set a default behavior
that applied to all sites.

Eventually developers found this preference (how, i do not know, we
never had documentation for it) and word spread through blogs that
switching this pref was useful during development and testing [1].
What these people didn't realize is that switching this pref means
that any website you go to can read your creditcard numbers and bank
statements if you happen to be logged in to your bank. Or your emails
if you happen to be logged in to gmail. So switching that pref
essentially handed all the personal information you store on the web
to any evil site you visit.

Once I noticed that that pref existed I removed it.


Ultimately I don't really have anything against security policies in
principal. However when looking at implementing an API in firefox
we'll definitely be reviewing the API in the light of the default
policy used by Firefox. If the API doesn't make sense from that point
of view I don't see us

RE: [FileReader API, ProgressEvents] Design patterns, FileWriter API

[Marcin Hanclik]

Hi Arun,

 To be clear, IMHO it's absolutely too late for FileReader
FileReader is still ED, therefore we may have time, I think.

Regarding FileWriter, I'm open to considering new event names, but in
general, discussing FileWriter's event model may be putting the cart in
front of the horse.  Even if we had an event-driven FileWriter, what
would it do?  We'll need to figure out filesystem access (real or
virtual) first! :-)
Agreed.
I have been thinking in terms of API design patterns and IMHO their target is 
to first document what we have in order to be able to foresee potential 
incompatibilities.
That is why I shout early :)

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: Arun Ranganathan [mailto:a...@mozilla.com]
Sent: Thursday, November 19, 2009 12:55 AM
To: Marcin Hanclik
Cc: Anne van Kesteren; WebApps WG; public-device-a...@w3.org
Subject: Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API

Marcin Hanclik wrote:
 Hi Anne,

 XHR still is used also for data retrieval, so it is a kind of border case and 
 I can live with load there :) .

 Using load for writing to a file will mean that we are stuck with the 
 legacy stuff. load and write pull semantically in the opposite 
 directions, IMHO.

 I think there is still time to change it in case of FileReader and prepare 
 background for FileWriter.


To be clear, IMHO it's absolutely too late for FileReader, and also not
desirable.  I've already mentioned developer familiarity with onload,
etc. and I strongly disagree with changing names in this case.  The
existing progress events are fine for FileReader.  We've also got a beta
implementation in place in Fx 3.6.

Regarding FileWriter, I'm open to considering new event names, but in
general, discussing FileWriter's event model may be putting the cart in
front of the horse.  Even if we had an event-driven FileWriter, what
would it do?  We'll need to figure out filesystem access (real or
virtual) first! :-)  More on this topic in separate email.

-- A*



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: [WARP] Comments to WARP spec

[Marcin Hanclik]

Hi Robin,

For instance consider a createElement(name, parent, content) method; you 
could obtain
script and alert('I am evil!') using the same trick, and call
createElement(script, document.body, alert('I am evil!')) - it would work 
just
the same as eval().
Yes, it seems the architecture is simply vulnerable per current design (e.g. in 
ECMA allowing non-strict eval etc.) and we cannot do too much.

Right, it's one of those things that people would've done differently if we'd 
had a
chance to think about the consequences while the web was being organically 
grown, but
that's water under the bridge now.
Keeping the context of having a chance: what about event naming in [1]?

Thanks,
Marcin

[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0795.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: Robin Berjon [mailto:ro...@berjon.com]
Sent: Thursday, November 19, 2009 11:15 AM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [WARP] Comments to WARP spec

Hi Marcin,

On Nov 19, 2009, at 09:44 , Marcin Hanclik wrote:
 Great thanks for the descriptive example!

A pleasure :)

 The security issue in your example results from the eval that is contained in 
 the html within a widget. So we could assume that if the widget is signed we 
 could somehow rely on its content. Then the evil eval would maybe not be used 
 (at least not in the context you quote).

Perhaps, but the example I used was very straightforward and easy to review - 
it would be possible for the original HTML to be a trojan with a less obvious 
attack path.

For instance consider a createElement(name, parent, content) method; you could 
obtain script and alert('I am evil!') using the same trick, and call 
createElement(script, document.body, alert('I am evil!')) - it would work 
just the same as eval().

 However, since some images can also be executed, the distinction is de-facto 
 void.

Right, it's one of those things that people would've done differently if we'd 
had a chance to think about the consequences while the web was being 
organically grown, but that's water under the bridge now.

--
Robin Berjon - http://berjon.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: [WARP] Comments to WARP spec

[Marcin Hanclik]

Hi Robin,

It seems in I am a naming purist :)

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: Robin Berjon [mailto:ro...@berjon.com]
Sent: Thursday, November 19, 2009 11:58 AM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [WARP] Comments to WARP spec

Hi,

On Nov 19, 2009, at 11:38 , Marcin Hanclik wrote:
 Right, it's one of those things that people would've done differently if 
 we'd had a
 chance to think about the consequences while the web was being organically 
 grown, but
 that's water under the bridge now.
 Keeping the context of having a chance: what about event naming in [1]?

Honestly I think that naming is far less important than architecture, and 
generally a bike shed topic :)

--
Robin Berjon - http://berjon.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] The people say NO to 1.0, was Re: [public-webapps] Comment on Widget URI (7)

[Marcin Hanclik]

Hi,

Versioning gets revisited :)
I agree to the change, since explicit versioning has been deprecated by many.
We switch to spec soup with implicit versioning.

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Marcos Caceres
Sent: Thursday, November 19, 2009 1:12 PM
To: Robin Berjon
Cc: Larry Masinter; public-webapps@w3.org
Subject: [widgets] The people say NO to 1.0, was Re: [public-webapps] Comment 
on Widget URI (7)

On Thu, Nov 19, 2009 at 12:07 PM, Robin Berjon ro...@berjon.com wrote:
 Dear Larry,

 thank you for your comments.

 On Oct 10, 2009, at 19:44 , Larry Masinter wrote:
 7) ** EDITORIAL TITLE **
 Widgets 1.0: Widget URIs the 1.0 might imply some kind of versioning, 
 but there is no versioning of URI schemes.

 Suggestion: retitle Widget URIs

 I have provisionally made this change. I agree with Marcos that it would be 
 good to do so throughout the widget family of specifications, especially 
 since there is no reason why versions of its various components need to 
 evolve in synchronised fashion — one could use P+C 4.2 with WARP 2.7.

 Recommendation to the WG: apply the same change throughout.

I strongly agree (and have been pushing this for a long time)... Lets
drop the 1.0 everywhere in the widget family of specs.

--
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: Trying to summarise (was Re: DAP and security)

[Marcin Hanclik]

I don't believe you can design secure APIs by first implementing the
APIs and then worrying about security later.
+1
Speaking for myself, in BONDI [1] the most interesting, controversial and 
complex topics arise when the Interfaces [2] meet Architecture  Security [3,4].
Security requires clarity, i.e. Architecture. Interfaces - to deliver 
Architecture - require something like API design patterns [5].
The task may be not completed on all fronts, but BONDI tries to deliver all of 
those components in a consistent manner as required.

Though, it is hard to make a large group work together on all aspects at once.

Thanks,
Marcin

[1] http://bondi.omtp.org/1.1/CR/
[2] http://bondi.omtp.org/1.1/CR/apis/index.html
[3] 
http://bondi.omtp.org/1.1/CR/security/BONDI_Architecture_and_Security_v1.1_CR.pdf
[4] 
http://bondi.omtp.org/1.1/CR/security/BONDI_Architecture_and_Security_Appendices_v1.1_CR.pdf
[5] http://bondi.omtp.org/1.1/CR/apis/BONDI_Interface_Patterns_v1.1.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-device-apis-requ...@w3.org 
[mailto:public-device-apis-requ...@w3.org] On Behalf Of Adam Barth
Sent: Thursday, November 19, 2009 4:59 PM
To: Robin Berjon
Cc: public-device-a...@w3.org; public-webapps WG
Subject: Re: Trying to summarise (was Re: DAP and security)

On Thu, Nov 19, 2009 at 3:24 AM, Robin Berjon ro...@berjon.com wrote:
 Finally, we can all talk about policy and trust in browsers until we're bluer 
 in the face than a hypothermic smurf the fact of the matter is that I don't 
 believe that this is a case where discussion can produce consensus. There are 
 use cases for policy, and solutions for those will be developed at the very 
 least for the widgets landscape. If it so happens that they yield interesting 
 innovative stuff that could be useful in browsers, then it'll be easy to 
 point to it as proof and demo. Far easier than to argue about it, and it'll 
 happen faster if we create the technology rather than talk about it :)

I don't believe you can design secure APIs by first implementing the
APIs and then worrying about security later.  That's the road that
leads to systems like User Account Control (UAC).  Instead, you need
to understand the security requirements up-front and design your APIs
to match.

If you ignore input from browser vendors who've been working with
these issues for years, it's unlikely you'd design something they'll
find palatable.

Adam




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: Trying to summarise (was Re: DAP and security)

[Marcin Hanclik]

Hi Maciej,

Thanks for your review!

The page http://www.w3.org/2009/dap/ does not yet include the BONDI 1.1 
Candidate Release at [1].
The device capabilities [2] could be regarded as a compact form of security 
considerations within BONDI APIs.
It should be noted that the device capabilities - although related to BONDI 
APIs - could be regarded as generic enough to incorporate any APIs.

Based on the BONDI policy format specification, I would propose to start with 
the following default policy for the Web:

policy-set combine=deny-overrides
  policy description=Default Policy for BONDI API  device capabilities 
within Win2K environment
target
  subject
subject-match attr=class match=website func=equal/
subject-match attr=uri.scheme match=http func=equal/
  /subject
  subject
subject-match attr=class match=website func=equal/
subject-match attr=uri.scheme match=https func=equal/
  /subject
/target
rule effect=deny
  condition combine=or
condition combine=and
  condition combine=or
resource-match attr=device-cap match=io.file.read/
resource-match attr=device-cap match=io.file.write/
  /condition
  condition combine=or
resource-match attr=param:nameC:\WINNTresource-match /
resource-match attr=param:nameC:\Documents and 
Settingsresource-match /
  /condition
/condition
condition combine=or
resource-match attr=device-cap match=devicestatus.set/
resource-match attr=device-cap match=commlog.clear/
/condition
  /condition
/rule
rule effect=prompt-session
  condition combine=or
 resource-match attr=device-cap match=location.position/
 resource-match attr=device-cap match=devicestatus.get/
 resource-match attr=device-cap match=devicestatus.list/
condition combine=and
  condition combine=or
resource-match attr=param:inContactsundefinedresource-match /
  /condition
  condition combine=or
resource-match attr='device-cap' match='messaging.email.send'
resource-match attr='device-cap' match='messaging.mms.send'
resource-match attr='device-cap' match='messaging.sms.send'
resource-match attr='device-cap' match='messaging.binary.send'
  /condition
/condition
  /condition
/rule
rule effect=prompt-oneshot
  condition combine=or
 resource-match attr=device-cap match=applauncher.launch/
 resource-match attr=device-cap match=io.file.write/
  /condition
/rule
rule effect=permit
  condition combine=or
resource-match attr='device-cap' match='appconfig.get'
  /condition
/rule
rule effect=prompt-blanket
  condition combine=or
resource-match attr=device-cap match=appconfig.set
resource-match attr=device-cap match=applauncher.get
resource-match attr=device-cap match=camera.access
resource-match attr=device-cap match=camera.capture
resource-match attr=device-cap match=camera.record
resource-match attr=device-cap match=commlog.sms.get
resource-match attr=device-cap match=commlog.mms.get
resource-match attr=device-cap match=commlog.email.get
resource-match attr=device-cap match=commlog.call.get
resource-match attr=device-cap match=io.file.read/
resource-match attr=device-cap match=location.position
resource-match attr=device-cap match=messaging.email.attach
resource-match attr=device-cap match=messaging.mms.attach
resource-match attr=device-cap match=messaging.email.getAccounts
resource-match attr=device-cap match=messaging.email.send
resource-match attr=device-cap match=messaging.mms.send
resource-match attr=device-cap match=messaging.sms.send
resource-match attr=device-cap match=messaging.binary.send
resource-match attr=device-cap match=messaging.mms.subscribe
resource-match attr=device-cap match=messaging.sms.subscribe
resource-match attr=device-cap match=messaging.binary.subscribe
resource-match attr=device-cap match=pim.contact.read
resource-match attr=device-cap match=pim.contact.write
resource-match attr=device-cap match=pim.task.read
resource-match attr=device-cap match=pim.task.read
resource-match attr=device-cap match=pim.event.write
resource-match attr=device-cap match=pim.event.read
resource-match attr=device-cap match=ui
  /condition
/rule
  /policy
/policy-set


Thanks,
Marcin

[1] http://bondi.omtp.org/1.1/CR/
[2] http://bondi.omtp.org/1.1/CR/apis/devcaps.html

From: public-device-apis-requ...@w3.org [public-device-apis-requ...@w3.org] On 
Behalf Of Maciej Stachowiak [...@apple.com]
Sent: Thursday, November 19, 2009 6:35 PM
To: 

RE: Trying to summarise (was Re: DAP and security)

[Marcin Hanclik]

Hi Maciej, All,

The file under [1] is not clickable, therefore browsing the relationships 
between various identifiers may be difficult at the first time.
At [3,4] there is/are clickable versions of the BONDI API specs.
At [5] there are live updates of the APIs.

I hope this helps.

Thanks,
Marcin

[3] http://bondi01.obe.access-company.com/1_1_4263_120/devcaps_clickable.html
[4] http://bondi01.obe.access-company.com/1_1_4263_120/
[5] http://bondi01.obe.access-company.com/

From: public-device-apis-requ...@w3.org [public-device-apis-requ...@w3.org] On 
Behalf Of Marcin Hanclik [marcin.hanc...@access-company.com]
Sent: Thursday, November 19, 2009 10:41 PM
To: Maciej Stachowiak; Adam Barth
Cc: Robin Berjon; public-device-a...@w3.org; public-webapps WG
Subject: RE: Trying to summarise (was Re: DAP and security)

Hi Maciej,

Thanks for your review!

The page http://www.w3.org/2009/dap/ does not yet include the BONDI 1.1 
Candidate Release at [1].
The device capabilities [2] could be regarded as a compact form of security 
considerations within BONDI APIs.
It should be noted that the device capabilities - although related to BONDI 
APIs - could be regarded as generic enough to incorporate any APIs.

Based on the BONDI policy format specification, I would propose to start with 
the following default policy for the Web:

policy-set combine=deny-overrides
  policy description=Default Policy for BONDI API  device capabilities 
within Win2K environment
target
  subject
subject-match attr=class match=website func=equal/
subject-match attr=uri.scheme match=http func=equal/
  /subject
  subject
subject-match attr=class match=website func=equal/
subject-match attr=uri.scheme match=https func=equal/
  /subject
/target
rule effect=deny
  condition combine=or
condition combine=and
  condition combine=or
resource-match attr=device-cap match=io.file.read/
resource-match attr=device-cap match=io.file.write/
  /condition
  condition combine=or
resource-match attr=param:nameC:\WINNTresource-match /
resource-match attr=param:nameC:\Documents and 
Settingsresource-match /
  /condition
/condition
condition combine=or
resource-match attr=device-cap match=devicestatus.set/
resource-match attr=device-cap match=commlog.clear/
/condition
  /condition
/rule
rule effect=prompt-session
  condition combine=or
 resource-match attr=device-cap match=location.position/
 resource-match attr=device-cap match=devicestatus.get/
 resource-match attr=device-cap match=devicestatus.list/
condition combine=and
  condition combine=or
resource-match attr=param:inContactsundefinedresource-match /
  /condition
  condition combine=or
resource-match attr='device-cap' match='messaging.email.send'
resource-match attr='device-cap' match='messaging.mms.send'
resource-match attr='device-cap' match='messaging.sms.send'
resource-match attr='device-cap' match='messaging.binary.send'
  /condition
/condition
  /condition
/rule
rule effect=prompt-oneshot
  condition combine=or
 resource-match attr=device-cap match=applauncher.launch/
 resource-match attr=device-cap match=io.file.write/
  /condition
/rule
rule effect=permit
  condition combine=or
resource-match attr='device-cap' match='appconfig.get'
  /condition
/rule
rule effect=prompt-blanket
  condition combine=or
resource-match attr=device-cap match=appconfig.set
resource-match attr=device-cap match=applauncher.get
resource-match attr=device-cap match=camera.access
resource-match attr=device-cap match=camera.capture
resource-match attr=device-cap match=camera.record
resource-match attr=device-cap match=commlog.sms.get
resource-match attr=device-cap match=commlog.mms.get
resource-match attr=device-cap match=commlog.email.get
resource-match attr=device-cap match=commlog.call.get
resource-match attr=device-cap match=io.file.read/
resource-match attr=device-cap match=location.position
resource-match attr=device-cap match=messaging.email.attach
resource-match attr=device-cap match=messaging.mms.attach
resource-match attr=device-cap match=messaging.email.getAccounts
resource-match attr=device-cap match=messaging.email.send
resource-match attr=device-cap match=messaging.mms.send
resource-match attr=device-cap match=messaging.sms.send
resource-match attr=device-cap match=messaging.binary.send
resource-match attr=device-cap match=messaging.mms.subscribe
resource-match attr=device-cap match

RE: Security evaluation of an example DAP policy

[Marcin Hanclik]

Hi Adam,

Thanks for your review!
This is what the BONDI specs need :)
I am sorry that you are skeptical and believe that with joint forces BONDI and 
DAP will end up with a good solution.

If I understand this policy correctly, this would let a web site
overwrite boot.ini if the user clicks through a prompt-oneshot.  This
does not seem like a good idea.
To handle this use case a more general regular expression could be defined.
E.g. the following would have to be inserted into the prompt-oneshot section
resource-match attr=param:name 
func=regexp/(C|c):\\(.+)\\(.+)/resource-match /
and the following into deny section
resource-match attr=param:name 
func=regexp/(C|c):\\(.+)/resource-match /
Anyway, the BONDI FS is guarded as below.

You can tell your policy is in trouble because you're blacklisting
C:\WINNT.  What if my system is installed on my D: drive?
Please note that access to FS is guarded by FileSystemManager.resolve that is 
described as:
Validates and resolves the given location to a File handle and returns a 
handle. A valid location is prefixed with a valid root or default location and 
must address an existing and accessible file.

The path is resolved and visible to the JS code, but is it not necessarily 
readable or writable as is.
For this there are getDefaultLocations and getRootLocations methods.

In other APIs there are already cases around e.g. inContacts that refer to 
the device-specific information on the policy level.

It's emails like this that make me skeptical of the security work
being done in the device APIs working group.
We try to stay positive and be constructive :)

Thanks,
Marcin


From: Adam Barth [...@adambarth.com]
Sent: Friday, November 20, 2009 12:22 AM
To: Marcin Hanclik
Cc: Maciej Stachowiak; Robin Berjon; public-device-a...@w3.org; public-webapps 
WG
Subject: Security evaluation of an example DAP policy

If I understand this policy correctly, this would let a web site
overwrite boot.ini if the user clicks through a prompt-oneshot.  This
does not seem like a good idea.

You can tell your policy is in trouble because you're blacklisting
C:\WINNT.  What if my system is installed on my D: drive?

It's emails like this that make me skeptical of the security work
being done in the device APIs working group.

Adam


On Thu, Nov 19, 2009 at 1:41 PM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
 Hi Maciej,

 Thanks for your review!

 The page http://www.w3.org/2009/dap/ does not yet include the BONDI 1.1 
 Candidate Release at [1].
 The device capabilities [2] could be regarded as a compact form of security 
 considerations within BONDI APIs.
 It should be noted that the device capabilities - although related to BONDI 
 APIs - could be regarded as generic enough to incorporate any APIs.

 Based on the BONDI policy format specification, I would propose to start with 
 the following default policy for the Web:

 policy-set combine=deny-overrides
  policy description=Default Policy for BONDI API  device capabilities 
 within Win2K environment
target
  subject
subject-match attr=class match=website func=equal/
subject-match attr=uri.scheme match=http func=equal/
  /subject
  subject
subject-match attr=class match=website func=equal/
subject-match attr=uri.scheme match=https func=equal/
  /subject
/target
rule effect=deny
  condition combine=or
condition combine=and
  condition combine=or
resource-match attr=device-cap match=io.file.read/
resource-match attr=device-cap match=io.file.write/
  /condition
  condition combine=or
resource-match attr=param:nameC:\WINNTresource-match /
resource-match attr=param:nameC:\Documents and 
 Settingsresource-match /
  /condition
/condition
condition combine=or
resource-match attr=device-cap match=devicestatus.set/
resource-match attr=device-cap match=commlog.clear/
/condition
  /condition
/rule
rule effect=prompt-session
  condition combine=or
 resource-match attr=device-cap match=location.position/
 resource-match attr=device-cap match=devicestatus.get/
 resource-match attr=device-cap match=devicestatus.list/
condition combine=and
  condition combine=or
resource-match attr=param:inContactsundefinedresource-match /
  /condition
  condition combine=or
resource-match attr='device-cap' match='messaging.email.send'
resource-match attr='device-cap' match='messaging.mms.send'
resource-match attr='device-cap' match='messaging.sms.send'
resource-match attr='device-cap' 
 match='messaging.binary.send'
  /condition
/condition
  /condition
/rule
rule effect=prompt-oneshot
  condition combine

RE: Security evaluation of an example DAP policy

[Marcin Hanclik]

Hi Adam,

I think that
resource-match attr=param:name 
func=regexp/(C|c):\\(.+)\\(.+)/resource-match /
should be
resource-match attr=param:name 
func=regexp/(C|c):\\([^\\]+)\\.+/resource-match /
up to any further bug in the RE.
Sorry, my problem.

Anyway, the general comment is that the use case is under control based on the 
current spec.

Thanks,
Marcin

From: public-device-apis-requ...@w3.org [public-device-apis-requ...@w3.org] On 
Behalf Of Marcin Hanclik [marcin.hanc...@access-company.com]
Sent: Friday, November 20, 2009 1:00 AM
To: Adam Barth
Cc: Maciej Stachowiak; Robin Berjon; public-device-a...@w3.org; public-webapps 
WG
Subject: RE: Security evaluation of an example DAP policy

Hi Adam,

Thanks for your review!
This is what the BONDI specs need :)
I am sorry that you are skeptical and believe that with joint forces BONDI and 
DAP will end up with a good solution.

If I understand this policy correctly, this would let a web site
overwrite boot.ini if the user clicks through a prompt-oneshot.  This
does not seem like a good idea.
To handle this use case a more general regular expression could be defined.
E.g. the following would have to be inserted into the prompt-oneshot section
resource-match attr=param:name 
func=regexp/(C|c):\\(.+)\\(.+)/resource-match /
and the following into deny section
resource-match attr=param:name 
func=regexp/(C|c):\\(.+)/resource-match /
Anyway, the BONDI FS is guarded as below.

You can tell your policy is in trouble because you're blacklisting
C:\WINNT.  What if my system is installed on my D: drive?
Please note that access to FS is guarded by FileSystemManager.resolve that is 
described as:
Validates and resolves the given location to a File handle and returns a 
handle. A valid location is prefixed with a valid root or default location and 
must address an existing and accessible file.

The path is resolved and visible to the JS code, but is it not necessarily 
readable or writable as is.
For this there are getDefaultLocations and getRootLocations methods.

In other APIs there are already cases around e.g. inContacts that refer to 
the device-specific information on the policy level.

It's emails like this that make me skeptical of the security work
being done in the device APIs working group.
We try to stay positive and be constructive :)

Thanks,
Marcin


From: Adam Barth [...@adambarth.com]
Sent: Friday, November 20, 2009 12:22 AM
To: Marcin Hanclik
Cc: Maciej Stachowiak; Robin Berjon; public-device-a...@w3.org; public-webapps 
WG
Subject: Security evaluation of an example DAP policy

If I understand this policy correctly, this would let a web site
overwrite boot.ini if the user clicks through a prompt-oneshot.  This
does not seem like a good idea.

You can tell your policy is in trouble because you're blacklisting
C:\WINNT.  What if my system is installed on my D: drive?

It's emails like this that make me skeptical of the security work
being done in the device APIs working group.

Adam


On Thu, Nov 19, 2009 at 1:41 PM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
 Hi Maciej,

 Thanks for your review!

 The page http://www.w3.org/2009/dap/ does not yet include the BONDI 1.1 
 Candidate Release at [1].
 The device capabilities [2] could be regarded as a compact form of security 
 considerations within BONDI APIs.
 It should be noted that the device capabilities - although related to BONDI 
 APIs - could be regarded as generic enough to incorporate any APIs.

 Based on the BONDI policy format specification, I would propose to start with 
 the following default policy for the Web:

 policy-set combine=deny-overrides
  policy description=Default Policy for BONDI API  device capabilities 
 within Win2K environment
target
  subject
subject-match attr=class match=website func=equal/
subject-match attr=uri.scheme match=http func=equal/
  /subject
  subject
subject-match attr=class match=website func=equal/
subject-match attr=uri.scheme match=https func=equal/
  /subject
/target
rule effect=deny
  condition combine=or
condition combine=and
  condition combine=or
resource-match attr=device-cap match=io.file.read/
resource-match attr=device-cap match=io.file.write/
  /condition
  condition combine=or
resource-match attr=param:nameC:\WINNTresource-match /
resource-match attr=param:nameC:\Documents and 
 Settingsresource-match /
  /condition
/condition
condition combine=or
resource-match attr=device-cap match=devicestatus.set/
resource-match attr=device-cap match=commlog.clear/
/condition
  /condition
/rule
rule effect=prompt-session
  condition combine=or
 resource-match attr=device-cap match=location.position/
 resource-match attr

RE: Security evaluation of an example DAP policy

[Marcin Hanclik]

Hi Jonas, Maciej,

It seems that the policy that you would accept would be:

policy-set combine=deny-overrides
 policy description=Default Policy for websites. Simply denying all API that 
are covered by some device capability:) 
   target
 subject
   subject-match attr=class match=website func=equal/
 /subject
   /target
   rule effect=deny
 condition
   resource-match attr=device-cap func=regexp/.+//resource-match
 /condition
   /rule
 /policy
/policy-set

Let's see how DAP will evolve then.

Thanks,
Marcin

From: Maciej Stachowiak [...@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
 marcin.hanc...@access-company.com wrote:
 Hi Adam,

 I think that
 resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/
 resource-match /
 should be
 resource-match attr=param:name func=regexp/(C|c):\\([^\\]+)\\.
 +/resource-match /
 up to any further bug in the RE.
 Sorry, my problem.

 Anyway, the general comment is that the use case is under control
 based on the current spec.

 For what it's worth, I think any API that opened a dialog asking the
 user Do you want to give website X access to directory Y in your file
 system would not be an API we'd be willing to implement in firefox.
 I.e. our security policy would be to always deny such a request (thus
 making implementing the API useless for our users).

Ditto for Safari.

  - Maciej




Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is 
privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or 
distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by 
responding to this e-mail. Thank you.

[Widgets] LCWD#3 comments (2)

[Marcin Hanclik]

5.3 (grammar: I hope these are final corrections :( )

[*folder-name]
Should be
*folder-name
Since the current form makes it optional twice

Zip-rel-path
file-name/
could be
file-name /
(note the space before '/')

safe-char
I suggest putting the '/' sign at the end of each line instead of at the 
beginning

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 content element.
Also the valid-MIME-type could be replaced with the following from RFC4288
   type-name = reg-name
   subtype-name = reg-name

   reg-name = 1*127reg-name-chars
   reg-name-chars = ALPHA / DIGIT / ! /
   # / $ /  / . /
   + / - / ^ / _

BTW:
I understand that W3CMediaReg uses RFC2046 (actually RFC2048), but RFC4288 
(also BCP13) obsoletes RFC2048.
So it gets blurred to me.

Path attribute
a valid path represent a hierarchical
Should be
a valid path represents a hierarchical

Version attribute
e.g. '1.0' is not greater than '2.0'
Could be
e.g. '1.0' is not less than '2.0'
9.1.10
a) There is no step 11, ol was changed to ul after step 4.

b) SNIFF spec basically specifies the algorithms for the resources retrieved 
from the network.
The statement relevant to PC seems to be:

   For resources fetched from the file system, user agents should use

   platform-specific conventions, e.g. operating system file extension/

   type mappings.

Therefore it is unclear what
processing filehttp://dev.w3.org/2006/waf/widgets/#file through the 
[SNIFF]http://dev.w3.org/2006/waf/widgets/#sniff specification.
means (i.e. SNIFF is big, but we need just one sentence?).
Are we restricted e.g. to section 5 (Unknown Type)?

c) The version of the SNIFF spec that is referred by PC is 00 (by date) and it 
has already expired as ID.

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 (1)

[Marcin Hanclik]

Hi Marcos,

Thanks!

Kind regards,
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: Wednesday, November 18, 2009 1:02 PM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [Widgets] LCWD#3 comments (1)

Hi, Marcin!

2009/11/17 Marcin Hanclik marcin.hanc...@access-company.com:
 Hi,

 A couple of comments to the latest PC.

 7.4
 Media type attribute
 Media type attribute defines the grammar and refers to RFC2045/6.
 What about referring to RFC4288 that includes the grammar required for MIME 
 registration [1]? (I have no strong opinion about this point, though.)


I think I will leave this as is.


 Numeric attribute
 For example, the characters 002, 323, 23214
 Could be
 For example, the character strings 002, 323, 23214

Good suggestion, but I changed it to just say the strings...

The words character strings would be a tautology.

 7.11.1
 When an icon  element is used, it is required for authors to use the src 
 attribute.
 Should be an authoring guideline.

Fixed.

 7.13.1
 that a user agent will behave as the required  attribute
 Should be
 that a user agent will behave as if the required  attribute

Fixed.

 Acknowledgments
 It seems a paragraph is missing there.

Fixed.




--
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: DAP and security (was: Rename “File API” to “FileReader API”?)

[Marcin Hanclik]

+1
APIs - specifically their design - shall be specified tightly with the security 
model in mind to make them both easy to use and effective.
This is what makes the whole task that difficult.

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: public-device-apis-requ...@w3.org 
[mailto:public-device-apis-requ...@w3.org] On Behalf Of Dominique 
Hazael-Massieux
Sent: Thursday, November 12, 2009 10:30 AM
To: Maciej Stachowiak
Cc: Robin Berjon; public-device-a...@w3.org; public-webapps WG
Subject: DAP and security (was: Rename “File API” to “FileReader API”?)

Le mardi 10 novembre 2009 à 17:47 -0800, Maciej Stachowiak a écrit :
 I would be concerned with leaving file writing to DAP, because a
 widely held view in DAP seems to be that security can be ignored while
 designing APIs and added back later with an external policy file
 mechanism.

Frederick already mentioned this isn’t the case at all, and I want to
strongly reject the notion that DAP is considering security as an
after-the-fact or out-of-band aspect in the design of its APIs.

Our charter clearly stipulates that our policy model “must be consistent
with the existing same origin policies (as documented in the HTML5
specification), in the sense that a deployment of the policy model in
Web browsers must be possible”.

In fact, most of models that have been discussed in this thread to
reduce the risks exposed by new APIs (sandbox for writing, user
interaction or markup-based element for sharing data) were already
mentioned as options by DAP WG participants during our F2F last week.

More generally, I don’t think assuming that DAP would create worse/less
secure APIs than WebApps or any other group would is either right nor
useful to ensure a good collaboration between our groups. And clearly,
we will actively be seeking feedback and input from the WebApps Working
Group when we produce new APIs, which should also contribute to reduce
the fears that we would get it all wrong :)

Regards,

Dom






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: [FileReader API, ProgressEvents] Design patterns, FileWriter API

[Marcin Hanclik]

Hi Anne,

XHR still is used also for data retrieval, so it is a kind of border case and I 
can live with load there :) .

Using load for writing to a file will mean that we are stuck with the legacy 
stuff. load and write pull semantically in the opposite directions, IMHO.

I think there is still time to change it in case of FileReader and prepare 
background for FileWriter.
I like the ProgressEvents spec and would keep it generic, i.e. change the names 
there to be generic and mandate their change in each spec that refer to 
ProgressEvents. PE is perfect to be a design pattern for asynchronous (and 
lengthy, more-than-one-shot, with-start-and-end, abortable and potentially 
erroneous) DAP APIs.

In the firing grammar:
progressgrammar = loadstart working (error | abort | load) loadend
working = *( progress | (progress suspend progress) | (progress stalled 
progress) )

potentially rewritten to

progressgrammar = start working (error | abort | done) end
working = *( progress | (progress suspend progress) | (progress stalled 
progress) )

we would only need to change the working rule to accommodate various event 
firing scenarios. Thus under the same design pattern we could accommodate XHR, 
HTML5's media API, FileReader and any new DAP API.
The event names could be related to the API for naming consistency, but firing 
model would be pre-defined were possible for design consistency.

For example for directory walker (aka File Directory API or File API Level 3: 
Directories as proposed by Robin) we could have:

directorywalkereventgrammar = start working (error | abort | done) end
working = *( enterdir *file leavedir )

to be able to walk over e.g. 1M file entries in some FS.

Any thoughts?
I guess it may be over-engineering, but ...

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: Anne van Kesteren [mailto:ann...@opera.com]
Sent: Wednesday, November 18, 2009 10:31 AM
To: a...@mozilla.com; Marcin Hanclik
Cc: WebApps WG; public-device-a...@w3.org
Subject: Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API

On Wed, 18 Nov 2009 02:30:16 +0100, Arun Ranganathan a...@mozilla.com
wrote:
 I think that just as the names 'load*' were chosen for generic data
 transfer events (either networked or within a document), and are used
 within documents loaded in the DOM, XHR, and FileReader, we'll need
 reusable 'write*' events.  Without bikeshedding too much, I like your
 proposal above, but wonder whether we should use the name 'write*' or
 something else.  Since we already have document.write, 'write' is
 probably the most vetted string to use here :)

For what it's worth, for XMLHttpRequest sending events (which are
arguably somewhat like write) we still use loadstart/... and simply
dispatch them on a distinct object. I've no idea what the file writer API
will look like, but I can imagine we might be able to do the same there.


--
Anne van Kesteren
http://annevankesteren.nl/



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 (1)

[Marcin Hanclik]

Hi Marcos,

For the purposes of my LC comments, I am 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

-Original Message-
From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of 
Marcos Caceres
Sent: Wednesday, November 18, 2009 1:02 PM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [Widgets] LCWD#3 comments (1)

Hi, Marcin!

2009/11/17 Marcin Hanclik marcin.hanc...@access-company.com:
 Hi,

 A couple of comments to the latest PC.

 7.4
 Media type attribute
 Media type attribute defines the grammar and refers to RFC2045/6.
 What about referring to RFC4288 that includes the grammar required for MIME 
 registration [1]? (I have no strong opinion about this point, though.)


I think I will leave this as is.


 Numeric attribute
 For example, the characters 002, 323, 23214
 Could be
 For example, the character strings 002, 323, 23214

Good suggestion, but I changed it to just say the strings...

The words character strings would be a tautology.

 7.11.1
 When an icon  element is used, it is required for authors to use the src 
 attribute.
 Should be an authoring guideline.

Fixed.

 7.13.1
 that a user agent will behave as the required  attribute
 Should be
 that a user agent will behave as if the required  attribute

Fixed.

 Acknowledgments
 It seems a paragraph is missing there.

Fixed.




--
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: DAP and security (was: Rename File API to FileReader API?)

[Marcin Hanclik]

Hi Maciej,

I think that there are many potential oversimplifications when stating that 
security concerns are to be left to the policy and that a policy file could be 
a cure to everything. These seem to be just superficial comments from the 
people who already did related exercise in some implementation. E.g. BONDI spec 
- input to DAP already in version 1.1 - touches upon the whole problem.

OK, I will take your word for it that security is an important
consideration for DAP.
It is for me after BONDI experience. I cannot speak for the others.

The first step is to have the security concerns.
The widget environment, BONDI etc. then encode them somehow (e.g. as device 
capability, feature etc.) creating an abstraction.
In case of the browser, those concerns seem to be simply coded in the browser.
Still the concerns remain and are handled.
The widgets spec try to abstract them in order to give the freedom either to 
the end user, administrator, operator or any other party. Alternatively they 
could be simply hard-coded in the webruntime.  So the issue is only who is able 
to specify whether the policy is applied, the concerns are still there.

During the TPAC I commented on irc that the policy file is just a 
representation of the policy, specifically for interchange purposes. It is up 
to the spec designers whether the concerns are properly reflected in the policy 
and later in the format/syntax of the policy file.
In BONDI we agreed on the format, there is no need for all to comply with that 
format.
No problem with that, but the security concerns are still there and are handled.

It seems to me that for most of DAP's likely deliverables, there are
serious security considerations, but the same-origin policy is
irrelevant to addressing them. The same-origin policy is designed to
protect Web sites from attacks by other Web sites. It does not really
apply to access to system resources. Doing that in a Web-safe way will
require new inventions or might not even be possible in some cases.
The origin is a topic in WebApps in the Widgets 1.0 spec,  e.g. TWI [1].
We have the issue of the widget instance (e.g. do we allow the same widget be 
instantiated multiple times, how to synchronize between instances etc.).
BONDI specs distinguish additionally between websites and widgets.
The same-origin policy is still there. We would potentially like a widget not 
to be able to act in place of another widget (identity spoofing, for this we 
need widget URI [2] with authority component).
So similarly to same-website/script, we have same-widget policy. Origins are 
websites and widgets.

It may be up to the policy (set by whoever) whether e.g. two widgets or two 
websites are able to write to the same folder in the FS.
In this case, the security concern is: who can write to FS, where actually can 
it write etc.
The realization of these concerns is abstracted in BONDI as:
- io.file.read / io.file.write: device capability (abstraction to accommodate 
various APIs doing file writing / reading)
- http://bondi.omtp.org/api/filesystem.read / 
http://bondi.omtp.org/api/filesystem.write: API feature (api availability, 
specific for BONDI-defined APIs)
- path: parameter to device capability that states the actual path being 
accessed.
Each API has different security concerns, thus there are e.g. different 
parameters in BONDI.

In case of the browser environment, I was personally thinking about something 
like personal firewall (a tab in the browser settings? ) where the end-user 
defines the actual policy defaulted by the browser vendor. In walled-garden 
environments such firewall would be disabled and e.g. the operator would define 
the policy. The prompts would then depend on the policy and not only on the API 
being used.
There could also be browsers that do not expose the policy settings to the end 
users. In BONDI there is freedom about that, but still the security concerns 
are there and are handled.

Thanks,
Marcin

[1] http://dev.w3.org/2006/waf/widgets-api/
[2] http://dev.w3.org/2006/waf/widgets-uri/

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: Maciej Stachowiak [mailto:m...@apple.com]
Sent: Wednesday, November 18, 2009 1:35 PM
To: Marcin Hanclik
Cc: Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; 
public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)


OK, I will take your word for it that security is an important
consideration for DAP. But while at the TPAC, I heard more than one
DAP participant say, when faced with a potential security concern,
something like can't we just leave that up to the policy? In one
case when I enquired further, at least one DAP member mentioned to me
the idea of using some sort of policy file that would take care of
all security issues. He suggested this might come from a corporate

[FileReader API, ProgressEvents] Design patterns, FileWriter API

[Marcin Hanclik]

Hi,

This is a set of architectural comments to the FileReader API, ProgressEvents 
and the design patterns for DAP.

For DAP in [1] I propose the following consistency requirement (still [1] is a 
very early draft with bugs):
All APIs MUST follow the same convention when handling callback functions 
(e.g. XHR / FileReaderAPI style with onreadystatechange, or ProgressEvents with 
EventTarget).
There is currently discrepancy between XHR/FileReaderAPI and the ProgressEvents 
in terms of handling the same functionality differently.

The ProgressEvents specification proposes is the event firing order [2], that 
could be summarized as a firing grammar
(up to some lack of clarity around suspend and stalled events):

progressgrammar = loadstart working (error | abort | load) loadend
working = *( progress | (progress suspend progress) | (progress stalled 
progress) )

In my opinion some part of the design from ProgressEvents is taken over in 
FileReader API too directly.
Specifically the event names are the same as within the ProgressEvents, but I 
assume they should be adjusted to the FileReader API.
Therefore instead of (forgetting the above issue with the callback model for 
now):

  attribute Function onloadstart;
  attribute Function onprogress;
  attribute Function onload;
  attribute Function onabort;
  attribute Function onerror;
  attribute Function onloadend;

we could have:

  attribute Function onreadstart;
  attribute Function onprogress;
  attribute Function onread;
  attribute Function onabort;
  attribute Function onerror;
  attribute Function onreadend;

Assuming that we will have an interface like FileWriter in the (near) future, 
we could already now anticipate that the interface would include e.g. the 
following:

  attribute Function onwritestart;
  attribute Function onprogress;
  attribute Function onwrite;
  attribute Function onabort;
  attribute Function onerror;
  attribute Function onwriteend;

Then, the ProgressEvents spec could act as a design pattern definition for 
lengthy, asynchronous operations.
To make it happen, the names of the events there could be changed to be generic:
loadstart - start
progress
stalled
suspend
error
abort
load - done
loadend - end

Additionally the ProgressEvents spec could be divided (or split into two 
documents? ) to contain the section specific to the design pattern definition 
and to the section specific to data transfer / loading.

What to you think?

Thanks,
Marcin

[1] 
http://dev.w3.org/cvsweb/~checkout~/2009/dap/design-patterns/Overview.html?rev=1.1content-type=text/html;%20charset=iso-8859-1
[2] http://dev.w3.org/2006/webapi/progress/Progress.html#Event1

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.

[Widgets] LCWD#3 comments (1)

[Marcin Hanclik]

Hi,

A couple of comments to the latest PC.

7.4
Media type attribute
Media type attribute defines the grammar and refers to RFC2045/6.
What about referring to RFC4288 that includes the grammar required for MIME 
registration [1]? (I have no strong opinion about this point, though.)


Numeric attribute
For example, the characters 002, 323, 23214
Could be
For example, the character strings 002, 323, 23214

7.11.1
When an icon  element is used, it is required for authors to use the src 
attribute.
Should be an authoring guideline.

7.13.1
that a user agent will behave as the required  attribute
Should be
that a user agent will behave as if the required  attribute

Acknowledgments
It seems a paragraph is missing there.

Thanks,
Marcin

[1] http://tools.ietf.org/html/rfc4288#section-4.2

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: [WARP] Comments to WARP spec

[Marcin Hanclik]

Hi,

What about semantic distinctions?
tag as proposed till now seems to be too detailed and does not scale.
For HTML/XHR:
script means an executable content retrieved from the remote host.
img, video etc means a displayable content retrieved from the remote host.
iframe means a container (possibly for executable and displayable content) 
retrieved from the remote host.
form means form submission, i.e. data is sent and not retrieved (topic 
discussed at TPAC. This also relates to the notion of retrievable content that 
is currently defined in WARP).
API means that the network resource is to be requested by some API and not 
markup.

We could have similar model to @rel on link from HTML, i.e. some meta 
information.
We probably would like to distinguish between executable/non-executable (e.g. 
displayable or styling) contents and a kind of containers into which we 
have/not have insights.
Keeping WARP on an abstract level, we could specify that the semantics of the 
particular content in the WARP model is out of scope for WARP.
Then e.g. for HTML we could adopt the above distinctions in some other spec. It 
should work for HTML+SVG.

The proposal is:
add type attribute on access element that must have a value that is a set 
of space-separated tokens:
exec -  any retrievable content that is executed within the user agent (i.e. 
something that - when retrieved - will be executed),
display - any retrievable content that is (only) displayed by the user agent,
form - any data submitted by the user agent,
container - any (markup) container that could be used to load executable, 
displayable or any other type of content by the user agent (i.e. e.g. some html 
page. This touches upon a being clicked in a widget: should the browser be 
opened? ),
api - any retrievable and displayable content that is to be processed by the 
executable content within the user agent (e.g. by XHR. But what to do with the 
submissions based on XHR...? It seems API blurs this model a bit, since it is 
undefined what would happened to the retrieved data. Also e.g. the retrieved 
XML may be executed by some processor developed in script.),
any - all/any of the above.
Missing value equals to any (the default).
This attribute specifies the origin of the access request and purpose for the 
submitted/retrieved data.

Any views on this?

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Marcos Caceres
Sent: Tuesday, November 10, 2009 4:30 PM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: WebApps WG
Subject: Re: [WARP] Comments to WARP spec



SULLIVAN, BRYAN L (ATTCINW) wrote:
 Marcos,
 I agree there is an assumption behind the approach I proposed, which I also 
 believe will be valid for the vast majority of widgets which will actually 
 have index.html or something like that as the start page. Further, the 
 statements in the config.xml apply to all resources in the widget, not just 
 the start page, i.e. I can start with a non-HTML which references an HTML 
 file in the package, to which the tag attribute applies.

So we are clear, the tag attribute does not work in the following
situation. I want to disable x:script, but allow v:script... unless you
know what the things different namespaces will not be added dynamically
to the DOM:

x:html xmlns:x=http://www.w3.org/1999/xhtml;
...
x:script ... /x:script

v:svg v:width=6cm v:height=5cm v:viewBox=0 0 600 500
  xmlns:v=http://www.w3.org/2000/svg; version=1.1
   v:script src=../v:script
/v:svg

/x:html

 If the proposed solution is inadequate, I welcome other suggestions.

I don't have a suggestion because I don't believe this part of WARP is
broken or is necessary.

 But as it stands, the WARP spec is not consistent with the web
security model, so we need to fix theaccess  element definition somehow.

  Well, the whole point of WARP is to put these boundaries around the
behavior of widgets because they run locally. How a browsing context
should behave when run locally is not really defined by HTML5. This
leaves a gap for us to fill.




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: [WARP] Comments to WARP spec

[Marcin Hanclik]

Hi Marcos,

I understand that too many details may not work or be an obstacle in the 
adoption.
However, I derive that from the security point of view we still would like to 
distinguish at least between executable and non-executable content.
The distinction between retrievable and submissible touches upon the privacy 
(at present the users do not complain when they submit any data), but seems to 
be out of concerns at present.

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: Marcos Caceres [mailto:marc...@opera.com]
Sent: Thursday, November 12, 2009 3:04 PM
To: Marcin Hanclik
Cc: SULLIVAN, BRYAN L (ATTCINW); WebApps WG
Subject: Re: [WARP] Comments to WARP spec



Marcin Hanclik wrote:
 Hi,

 What about semantic distinctions?
 tag as proposed till now seems to be too detailed and does not scale.
 For HTML/XHR:
 script  means an executable content retrieved from the remote host.
 img,video  etc means a displayable content retrieved from the remote host.
 iframe  means a container (possibly for executable and displayable content) 
 retrieved from the remote host.
 form  means form submission, i.e. data is sent and not retrieved (topic 
 discussed at TPAC. This also relates to the notion of retrievable content 
 that is currently defined in WARP).
 API means that the network resource is to be requested by some API and not 
 markup.

 We could have similar model to @rel onlink  from HTML, i.e. some meta 
 information.
 We probably would like to distinguish between executable/non-executable (e.g. 
 displayable or styling) contents and a kind of containers into which we 
 have/not have insights.
 Keeping WARP on an abstract level, we could specify that the semantics of the 
 particular content in the WARP model is out of scope for WARP.
 Then e.g. for HTML we could adopt the above distinctions in some other spec. 
 It should work for HTML+SVG.

 The proposal is:
 add type attribute on access element that must have a value that is a set 
 of space-separated tokens:
 exec -  any retrievable content that is executed within the user agent 
 (i.e. something that - when retrieved - will be executed),
 display - any retrievable content that is (only) displayed by the user 
 agent,
 form - any data submitted by the user agent,
 container - any (markup) container that could be used to load executable, 
 displayable or any other type of content by the user agent (i.e. e.g. some 
 html page. This touches upona  being clicked in a widget: should the 
 browser be opened? ),
 api - any retrievable and displayable content that is to be processed by 
 the executable content within the user agent (e.g. by XHR. But what to do 
 with the submissions based on XHR...? It seems API blurs this model a bit, 
 since it is undefined what would happened to the retrieved data. Also e.g. 
 the retrieved XML may be executed by some processor developed in script.),
 any - all/any of the above.
 Missing value equals to any (the default).
 This attribute specifies the origin of the access request and purpose for the 
 submitted/retrieved data.

 Any views on this?


My view is that all this is overkill. I would prefer to keep things simple.

To add the above would mean that a UA would have to flag every single
element and every future supported element, as well as every feature,
into a particular class (or into multiple classes or worst, do this
dynamically (e.g., script style=display: block;
background-color:red;.../script)). This proposal does not scale either.

Kind regards,
Marcos



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.

[WARP] local addresses, UPnP, comments

[Marcin Hanclik]

Hi,

Following our yesterday's discussion about specification of the local addresses 
within WARP I have the following proposal.
Additionally, below there are few comments to the existing text.
Change from:

origin
An IRI attribute that defines the specifics of the access request that is 
requested. Additionally, the special value of U+002A ASTERISK (*) MAY be used. 
This special value provides a means for an author to request from the user 
agent unrestricted access to network resources. Only the scheme and authority 
components can be present in the IRI that this attribute contains ([[!URI]], 
[[!RFC3987]]).

subdomains
A boolean attribute that indicates whether or not the host component part of 
the access request applies to subdomains of domain in the origin attribute. The 
default value when this attribute is absent is false, meaning that access to 
subdomains is not requested.

to

origin
One of:
- an IRI attribute that defines the specifics of the access request that is 
requested. Or
- the special value of U+002A ASTERISK (*). This special value provides a means 
for an author to request from the user agent unrestricted access to network 
resources. Only the scheme and authority components can be present in the IRI 
that this attribute contains ([[!URI]], [[!RFC3987]]).
- the special value of local (%x6c.6f.63.61.6c in ABNF). This special value 
provides a means for an author to request from the user agent unrestricted 
access to local network resources. The addressing of the resources relies 
primarily on IP addressing of hosts. It is up to the underlying network which 
version of the IP protocol is used and how local network is identified.

subdomains
A boolean attribute that indicates whether or not the host component part of 
the access request applies to subdomains of domain in the origin attribute. The 
default value when this attribute is absent is false, meaning that access to 
subdomains is not requested. This attribute applies only to the origin 
attribute values that rely on the DNS.

The above abstract specification of locality shall allow for inclusion of 
IPv6,e.g. [1].

Additional comments
1. It should be clarified that the subdomains attribute applies only when the 
host is specified using DNS and not based on IP address. In other cases it 
shall be skipped.

2.  Only the scheme and authority components can be present in the IRI
:// should be added between scheme and authority to make IRI [2] (this was 
discussed already in BONDI, although it is not yet in the related spec there).

3. Attributes section uses authority whereas the processing model section 
uses iauthority. There the attributes section shall be corrected.

Thanks,
Marcin


[1] http://tools.ietf.org/html/rfc4193#section-4.6
[2] http://tools.ietf.org/html/rfc3986#section-3

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: [WARP] UPnP LAN

[Marcin Hanclik]

Hi,

Additionally to the below addresses we shall probably consider IPv6 addresses.

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: Tuesday, October 27, 2009 3:24 PM
To: public-webapps
Subject: [WARP] UPnP  LAN

Hi All,

These are some comments about the requirements for WARP to handle the UPnP 
traffic.


1.   UPnP uses multicast address 239.255.255.250.

2.   UPnP uses UDP-based HTTP (GENA, SSDP).

3.   The UPnP traffic takes place in local networks (LAN), therefore we 
shall assume that the host addresses will be from one of the private IP ranges 
[1]:

 10.0.0.0-   10.255.255.255  (10/8 prefix)

 172.16.0.0  -   172.31.255.255  (172.16/12 prefix)

 192.168.0.0 -   192.168.255.255 (192.168/16 prefix)

a.   We shall be able to assume that all private LANs are configured 
correctly with the above addresses and exclude other 
considerations/misconfigurations (alternatively we could mandate checking the 
DHCP configuration - masks etc. in the host to derive what the local network 
is, but it may lead us nowhere)

4.   It is a security-related decision whether an application / widget may 
access both the Internet and the LAN network at the same time.

a.   Some interesting use cases may be realized.

   i.  E.g. 
storage of the Internet-downloaded content (e.g. XHR's GET) onto UPnP device or 
e.g. SVN repository in LAN.

b.  Privacy is a concern.

Thanks,
Marcin

[1] http://tools.ietf.org/html/rfc1918
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.

RE: [Widgets] Security Considerations

[Marcin Hanclik]

Hi Marcos,

I think the section below is ok.
FWIW:
1. As in [1] we could add more detailed statements about HTML tags.
2. Also together with the term security we could add privacy.
So e.g. we may have another paragraph like this (the below text may need more 
details):

Widget packages may contain content that is able to interact both with the 
remote host and local device.
Therefore, implementers need to take into account the privacy-related 
implications resulting from the potential exposure of private information to 
the remote host given the relevant programming interface / model is defined.

3. [2] has a more thorough list of considerations that seem to be related to 
widgets, but more in the context of DAP. Anyway some of them could be reflected 
in the registration of application/widget.

[1] http://tools.ietf.org/html/rfc4287#section-8
[2] http://dev.w3.org/geo/api/spec-source.html#security


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 Marcos Caceres
Sent: Monday, October 26, 2009 6:46 PM
To: public-webapps; Thomas Roessler
Subject: [Widgets] Security Considerations

In order to register application/widgets as an official MIME type with
IANA, we need to have a section in the spec that outlines the security
considerations. I've made a first stab at this section (below)... but
I'm no security peep, so I would appreciate some input from those that
know better...

[[
Security considerations

This section is non-normative.

In addition to the security considerations specified for Zip files in
the [Zip-MIME] registration, there are a number of security
considerations that need to be taken into account when dealing with
widget packages and configuration documents.

As the configuration document format is [XML] and [Unicode], the
security considerations described in [XML-MIME] and [UTR36] apply.

The configuration document allows authors, through the feature
element, to request permission to enable third-party runtime
components and APIs. As these features are outside the scope of this
specification, significant caution needs to be taken when granting a
widget the capability to use a feature. Features themselves define
their own security considerations.

Widget packages will generally contain ECMAscript, HTML, CSS files,
and other media, which are executed in a sand boxed environment. As
such, implementers need to be aware of the security implications for
the types they support. Specifically, implementers need to consider
the security implications outlined in the [CSS-MIME] specification,
the [ECMAScript-MIME], and the [HTML-MIME] specification.

As this specification relies on the standardized heuristics for
determining the content type of files defined in the SNIFF
specification, implementers need to consider the security
considerations discussed in the [SNIFF] specification.

As this specification allows for the declaration of IRIs within
certain elements of a configuration documents, implementers need to
consider the security considerations discussed in the [IRI]
specification.

]]

--
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] Security Considerations

[Marcin Hanclik]

Hi Marcos,

Fine for me.

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: Tuesday, October 27, 2009 5:23 PM
To: Marcin Hanclik
Cc: public-webapps; Thomas Roessler
Subject: Re: [Widgets] Security Considerations

On Tue, Oct 27, 2009 at 5:38 PM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
 Hi Marcos,

 I think the section below is ok.
 FWIW:
 1. As in [1] we could add more detailed statements about HTML tags.

I could, but this might be mostly outdated because of HTML5.

 2. Also together with the term security we could add privacy.

Added.

 So e.g. we may have another paragraph like this (the below text may need more 
 details):

 Widget packages may contain content that is able to interact both with the 
 remote host and local device.
 Therefore, implementers need to take into account the privacy-related 
 implications resulting from the potential exposure of private information to 
 the remote host given the relevant programming interface / model is defined.



I tried to shorten it and included it... details below...

 3. [2] has a more thorough list of considerations that seem to be related to 
 widgets, but more in the context of DAP. Anyway some of them could be 
 reflected in the registration of application/widget.

 [1] http://tools.ietf.org/html/rfc4287#section-8
 [2] http://dev.w3.org/geo/api/spec-source.html#security


Ok, I took from [2] and got:

As widget packages can contain content that is able to simultaneously
interact with the local device and a remote host, implementers need to
consider the privacy implications resulting from exposing private
information to a remote host. Mitigation and in-depth defensive
measures are an implementation responsibility and not prescribed by
this specification. However, in designing these measures, implementers
are advised to enable user awareness of information sharing, and to
provide easy access to interfaces that enable revocation of
permissions. 


--
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] Potential bug in Rule for Identifying the Media Type of a File

[Marcin Hanclik]

Hi Marcos, All,

If any character in the extension is outside the U+0041-U+005A range
and the U+0061-U+007A range, then go to step 7 in this algorithm.
Unfortunately I disagree with that.
Motivation:
a) only ASCII characters are listed
b) no digits are listed. What about file extensions that include digits, like 
e.g. .p12 (PKCS#12 certificate)?
c) at present internationalization is a key topic in many circles and I do not 
understand why we shall restrict the file extensions in XXI century.
d) there exist proprietary widget specifications and it seems none of them 
restricts the file extensions.

Proposed actions:
Drop ranges and limits.
Eventually also contact I18N group and ask their opinion.

That is not possible because trying to do Unicode case comparisons is
a nightmare (or so I'm told).
I think we should distinguish between possibility and difficulty.
The whole filenames are to be compared (as per PC) in many cases, and suddenly 
file extensions cannot be compared.
E.g.
A default start file is a reserved start file at the root of the widget 
package or at the root of a locale folder whose file name case-sensitively and 
exactly matches a file name given in the file name column of the default start 
files table, and whose media type matches the media type given in the media 
type column of the table.

That is correct. This behavior is *nix systems (including Mac OS X).
This is not consistent with the behavior of the operating systems I
have tested.
I disagree.
Could you please publish your tests?
In general I think that there is no standard for the term file extension. PC 
actually standardizes it, it seems.
In the *nix, *inux systems it seems not to exist, it can only be somehow 
artificially handled by some application (shell etc., see below).
Here is mine test (executed on Ubuntu and Debian):
host:~$ mkdir test
host:~$ touch test/.jpg
host:~$ touch test/img.jpg
host:~$ touch test/.gif
host:~$ touch test/img.gif
host:~$ ls -laX test/
total 8
drwxr-xr-x 2 user user 4096 2009-10-22 15:33 .
drwxr-xr-x 5 user user 4096 2009-10-22 15:33 ..
-rw-r--r-- 1 user user0 2009-10-22 15:33 .gif
-rw-r--r-- 1 user user0 2009-10-22 15:33 img.gif
-rw-r--r-- 1 user user0 2009-10-22 15:33 img.jpg
-rw-r--r-- 1 user user0 2009-10-22 15:33 .jpg
//It seems that shell is confused, or?
host:~$ cd test/
host:~/test$ ls -laX
total 8
drwxr-xr-x 2 user user 4096 2009-10-22 15:33 .
drwxr-xr-x 5 user user 4096 2009-10-22 15:33 ..
-rw-r--r-- 1 user user0 2009-10-22 15:33 .gif
-rw-r--r-- 1 user user0 2009-10-22 15:33 img.gif
-rw-r--r-- 1 user user0 2009-10-22 15:33 img.jpg
-rw-r--r-- 1 user user0 2009-10-22 15:33 .jpg
//It seems that shell is confused, or?
host:~/test$ basename .jpg
.jpg
host:~/test$ cd ..
host:~$ basename test/.jpg
.jpg
host:~$ basename test/.jpg .jpg
.jpg
host:~$ basename test/img.jpg .jpg
img
host:~$ basename test/img.jpg
img.jpg
host:~$ basename test/img.jpg pg
img.j
//this test actually proves that the basename app is looking for the [SUFFIX] 
string in the file name. File extension is ARTIFICIAL!!
host:~$

Further comments:
[1] gives the following guidelines for media type registration:
Various sorts of optional information SHOULD be included in the
specification of a media type if it is available:
...
   o  File name extension(s) commonly used on one or more platforms to
  indicate that some file contains a given media type.

   o  Mac OS File Type code(s) (4 octets) used to label files containing
  a given media type.
The term file (name) extension is not defined. MacOS File Type code seems not 
to be equivalent to file extension (that stems more from Windows world).
Historically Windows worked with 3 characters and Mac with 4 characters.

Therefore in PC we shall assume that file extension is just any sequence of 
characters that occur after the last dot (U+002E FULL STOP) including that dot.

Thanks,
Marcin

[1] http://tools.ietf.org/html/rfc4288#section-4.11

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, October 22, 2009 1:56 PM
To: Marcin Hanclik
Cc: public-webapps
Subject: Re: [widgets] Potential bug in Rule for Identifying the Media Type of 
a File

On Fri, Oct 16, 2009 at 12:06 PM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
 Hi Marcos,

 These are my remarks as discussed yesterday on the call.

 Comment a)

 6.A.If all characters in the extension are outside the two ranges, then go to 
 step 5 in this algorithm.

 Should be

 6.A.If any of the characters in the extension is outside the two ranges, then 
 go to step 5 in this algorithm.

 But this is also problematic since it infinitely loops the algorithm in this 
 given case.
 So it should be:

 6.A.If any of the characters in the extension

RE: [widgets] Potential bug in Rule for Identifying the Media Type of a File

[Marcin Hanclik]

Hi Marcos,

To be clear: All we want to do is check if the file extension of a
file case-insensitively matches one of the extensions in the File
Identification Table. If you can't match it, then the MIME type gets
resolved with SNIFF.
Ok, I understand the intention of this section.

The ranges are an implementation detail (optimization/efficiency of some 
implementation, not a MUST for all).
So in general all the comments about Unicode comparison/difficulty etc are 
irrelevant.
Thus ranges as well.

Then the only really disputable thing is whether .jpg should be sniffed (your 
proposal) or whether it is to be interpreted as pure file extension (my 
proposal).
In my argumentation I showed that on *nix/*inux systems .jpg is a file 
extension to support the interpretation as pure file extension.

The suggestion to remove ranges aims at facilitating any extensions/additions 
to the spec. E.g. if we would like to add .p12 or Unicode extension to the 
File Identification Table, we should only have to add it there and not change 
the processing algorithm.

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, October 22, 2009 5:25 PM
To: Marcin Hanclik
Cc: public-webapps
Subject: Re: [widgets] Potential bug in Rule for Identifying the Media Type of 
a File

2009/10/22 Marcin Hanclik marcin.hanc...@access-company.com:
 Hi Marcos, All,

If any character in the extension is outside the U+0041-U+005A range
and the U+0061-U+007A range, then go to step 7 in this algorithm.
 Unfortunately I disagree with that.
 Motivation:
 a) only ASCII characters are listed
 b) no digits are listed. What about file extensions that include digits, like 
 e.g. .p12 (PKCS#12 certificate)?

I don't see that file format in the  File Identification Table.

 c) at present internationalization is a key topic in many circles and I do 
 not understand why we shall restrict the file extensions in XXI century.


Because we are trying to find stuff in the File Identification Table
(i.e., the algorithm is limited just to those file names). We are not
writing a general algorithm for extension to MIME mapping! That's what
SNIFF does.

 d) there exist proprietary widget specifications and it seems none of them 
 restricts the file extensions.

I don't know what you mean here? We don't restrict anything. We have
the most common types defined, and the ones we don't defined are
handled by SNIFF. I don't see the problem?

 Proposed actions:
 Drop ranges and limits.
 Eventually also contact I18N group and ask their opinion.

I think you've misunderstood the intention of the specification wrt
this section.

That is not possible because trying to do Unicode case comparisons is
a nightmare (or so I'm told).
 I think we should distinguish between possibility and difficulty.

this is totally irrelevant for this algorithm?

 The whole filenames are to be compared (as per PC) in many cases, and 
 suddenly file extensions cannot be compared.


This is just for efficiency.

 E.g.
 A default start file is a reserved start file at the root of the widget 
 package or at the root of a locale folder whose file name case-sensitively 
 and exactly matches a file name given in the file name column of the default 
 start files table, and whose media type matches the media type given in the 
 media type column of the table.

That is correct. This behavior is *nix systems (including Mac OS X).
This is not consistent with the behavior of the operating systems I
have tested.
 I disagree.
 Could you please publish your tests?

I created the files in the finder on MacOs X (Snow Leopard). I prefer
not to send a screenshot to the mailing list.

 In general I think that there is no standard for the term file extension. 
 PC actually standardizes it, it seems.
 In the *nix, *inux systems it seems not to exist, it can only be somehow 
 artificially handled by some application (shell etc., see below).
 Here is mine test (executed on Ubuntu and Debian):
 host:~$ mkdir test
 host:~$ touch test/.jpg
 host:~$ touch test/img.jpg
 host:~$ touch test/.gif
 host:~$ touch test/img.gif
 host:~$ ls -laX test/
 total 8
 drwxr-xr-x 2 user user 4096 2009-10-22 15:33 .
 drwxr-xr-x 5 user user 4096 2009-10-22 15:33 ..
 -rw-r--r-- 1 user user0 2009-10-22 15:33 .gif
 -rw-r--r-- 1 user user0 2009-10-22 15:33 img.gif
 -rw-r--r-- 1 user user0 2009-10-22 15:33 img.jpg
 -rw-r--r-- 1 user user0 2009-10-22 15:33 .jpg
 //It seems that shell is confused, or?
 host:~$ cd test/
 host:~/test$ ls -laX
 total 8
 drwxr-xr-x 2 user user 4096 2009-10-22 15:33 .
 drwxr-xr-x 5 user user 4096 2009-10-22 15:33 ..
 -rw-r--r-- 1 user user0 2009-10-22 15:33 .gif
 -rw-r--r-- 1 user user0 2009-10-22 15:33 img.gif
 -rw-r--r-- 1 user user0 2009

RE: [widgets] Potential bug in Rule for Identifying the Media Type of a File

[Marcin Hanclik]

Hi Marcos,

I think we will drink some beer soon :)

I understand the rationale, but I don't see it as necessary. Lets just
cover what is in the spec. In version 2, if we need to support this
later, we can add it easily. It won't break backwards compat because
we will just be expanding the range.
I am not religious about the change, but I would suggest to be minimalistic in 
the present requirements for v2.

BTW:
Relevant (IMHO) excerpts from Snow Leopard and BSD:
1)
macmini:folder user$ ls -X
ls: illegal option -- X
usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...]

2)
man ls on Snow Leopard and BSD does not know the terms extension or code 
(file type code)

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, October 22, 2009 6:12 PM
To: Marcin Hanclik
Cc: public-webapps
Subject: Re: [widgets] Potential bug in Rule for Identifying the Media Type of 
a File

2009/10/22 Marcin Hanclik marcin.hanc...@access-company.com:
 Hi Marcos,

To be clear: All we want to do is check if the file extension of a
file case-insensitively matches one of the extensions in the File
Identification Table. If you can't match it, then the MIME type gets
resolved with SNIFF.
 Ok, I understand the intention of this section.

 The ranges are an implementation detail (optimization/efficiency of some 
 implementation, not a MUST for all).
 So in general all the comments about Unicode comparison/difficulty etc are 
 irrelevant.
 Thus ranges as well.

Ok, cool. We are in agreement.

 Then the only really disputable thing is whether .jpg should be sniffed 
 (your proposal) or whether it is to be interpreted as pure file extension (my 
 proposal).
 In my argumentation I showed that on *nix/*inux systems .jpg is a file 
 extension to support the interpretation as pure file extension.


Yes, and on my Mac, it was not. It seems more logical to me to not
treat it as an extension. Look at all the .whatever files on your
system. I bet you 2 beers that 99% will be text files. And I bet you
will .whatever.ext will identify a type (like .something.plist).

 The suggestion to remove ranges aims at facilitating any extensions/additions 
 to the spec. E.g. if we would like to add .p12 or Unicode extension to the 
 File Identification Table, we should only have to add it there and not change 
 the processing algorithm.


I understand the rationale, but I don't see it as necessary. Lets just
cover what is in the spec. In version 2, if we need to support this
later, we can add it easily. It won't break backwards compat because
we will just be expanding the range.

--
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] Draft Minutes for 22 October 2009 Voice Conf

[Marcin Hanclik]

+1
We could continue discussion during the LC period as usual.
I am sorry for my blackout on the call.

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of David Rogers
Sent: Thursday, October 22, 2009 6:26 PM
To: Arthur Barstow; public-webapps
Subject: RE: [widgets] Draft Minutes for 22 October 2009 Voice Conf

Art and all,

AB: any other comments on this?
... given we don't consensus on this, we will not be able to publish
a new LC until after the TPAC meeting
... any last comments?
... given this is still an open issue, we will not discuss LC
publication today

Given that Marcin and Marcos appear to have resolved this on the mailing
lists, I would like to support LC publication as soon as possible.
Thoughts anyone?

Thanks,


David.

-Original Message-
From: public-webapps-requ...@w3.org
[mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow
Sent: 22 October 2009 14:51
To: public-webapps
Subject: [widgets] Draft Minutes for 22 October 2009 Voice Conf

The draft minutes from the October 22 Widgets voice conference are
available at the following and copied below:

  http://www.w3.org/2009/10/22-wam-minutes.html

WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before October 29 (the next
Widgets voice conference); otherwise these minutes will be considered
Approved.

-Regards, Art Barstow

[1]W3C

   [1] http://www.w3.org/

- DRAFT -

Widgets Voice Conference

22 Oct 2009

[2]Agenda

   [2] http://lists.w3.org/Archives/Public/public-webapps/
2009OctDec/0283.html

See also: [3]IRC log

   [3] http://www.w3.org/2009/10/22-wam-irc

Attendees

Present
   Art, Frederick, Jere, Bryan, Marcin_Hanclik, Magnus, Marcin,
   AndyB

Regrets
   Marcos, Arve, David

Chair
   Art

Scribe
   Art

Contents

  * [4]Topics
  1. [5]Review and tweak agenda
  2. [6]Announcements
  3. [7]PC spec: Potential bug in Rule for Identifying the
 Media Type of a File
  4. [8]AOB
  * [9]Summary of Action Items
  _



scribe ScribeNick: ArtB

scribe Scribe: Art

Review and tweak agenda

AB: I posted the draft agenda on October 21 (
[10]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/02
83.html ). Since Marcos sent regrets for today we will drop the
Widget interface spec agenda item.
... any other agenda change requests?

  [10] http://lists.w3.org/Archives/Public/public-webapps/
2009OctDec/0283.html

FH: I think we should talk about DAP + WebApps meeting during TPAC

AB: ok, during AOB

JK: we could talk about Web Notifications
... but may want to wait for more people

FH: yes, think we should wait

AB: I agree
... if there is no closure by next week, it will be on the Oct 29
agenda

Announcements

AB: I have 4 short announcements/reminders:
... 1. draft agendas for the November 2-3 TPAC f2f meeting have been
updated: Widgets group (
[11]http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets ) and APIs
group ( [12]http://www.w3.org/2008/webapps/wiki/TPAC2009APIs ).
Fleshing-out the TPAC widgets agenda will be an agenda item for our
October 29 call.
... 2. the TPAC registration deadline is Oct 23 (
[13]http://www.w3.org/2009/11/TPAC/Overview.html )
... 3. TPAC Public Developer Gathering Nov 5 (
[14]http://www.w3.org/2009/11/TPAC/DevMeeting ). Please spread the
word.
... 4. Our Oct 29 call will be the same time for everyone except US.
The time for US will be one hour later. Thereafter, the times will
be the same as today. No call of course during the TPAC week.
... any other annoucements?

  [11] http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets
  [12] http://www.w3.org/2008/webapps/wiki/TPAC2009APIs
  [13] http://www.w3.org/2009/11/TPAC/Overview.html
  [14] http://www.w3.org/2009/11/TPAC/DevMeeting

[ None ]

PC spec: Potential bug in Rule for Identifying the Media Type of a
File

AB: the remaining open bug for P+C spec is documented in the
Potential bug in Rule for Identifying the Media Type of a File
thread (
[15]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/01
83.html ).
... earlier today Marcos responded to Marcin's latest proposal (
[16]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/02
93.html ). I think this now closes this bug. Any comments?

  [15] http://lists.w3.org/Archives/Public/public-webapps/
2009OctDec/0183.html

RE: [widgets] Potential bug in Rule for Identifying the Media Type of a File

[Marcin Hanclik]

Hi Marcos, All,

It seems more logical to me to not
treat it as an extension. Look at all the .whatever files on your
system. I bet you 2 beers that 99% will be text files. And I bet you
will .whatever.ext will identify a type (like .something.plist).
I actually agree with this argumentation.
Even taking the implementation of ls [1] and sorting by file extension, it 
seems that file extension is fully abstract term that does not fit to the 
usually hidden files that start with the dot.
So I am ok with the current PC TSE and await being able to comment the next 
LCWD asap.

Thanks,
Marcin


[1] 
http://www.koders.com/c/fid5323BD5A5C27DBA053F42826EEA5EE8617B34335.aspx#L3064

From: marcosscace...@gmail.com [marcosscace...@gmail.com] On Behalf Of Marcos 
Caceres [marc...@opera.com]
Sent: Thursday, October 22, 2009 6:12 PM
To: Marcin Hanclik
Cc: public-webapps
Subject: Re: [widgets] Potential bug in Rule for Identifying the Media Type of  
a File

2009/10/22 Marcin Hanclik marcin.hanc...@access-company.com:
 Hi Marcos,

To be clear: All we want to do is check if the file extension of a
file case-insensitively matches one of the extensions in the File
Identification Table. If you can't match it, then the MIME type gets
resolved with SNIFF.
 Ok, I understand the intention of this section.

 The ranges are an implementation detail (optimization/efficiency of some 
 implementation, not a MUST for all).
 So in general all the comments about Unicode comparison/difficulty etc are 
 irrelevant.
 Thus ranges as well.

Ok, cool. We are in agreement.

 Then the only really disputable thing is whether .jpg should be sniffed 
 (your proposal) or whether it is to be interpreted as pure file extension (my 
 proposal).
 In my argumentation I showed that on *nix/*inux systems .jpg is a file 
 extension to support the interpretation as pure file extension.


Yes, and on my Mac, it was not. It seems more logical to me to not
treat it as an extension. Look at all the .whatever files on your
system. I bet you 2 beers that 99% will be text files. And I bet you
will .whatever.ext will identify a type (like .something.plist).

 The suggestion to remove ranges aims at facilitating any extensions/additions 
 to the spec. E.g. if we would like to add .p12 or Unicode extension to the 
 File Identification Table, we should only have to add it there and not change 
 the processing algorithm.


I understand the rationale, but I don't see it as necessary. Lets just
cover what is in the spec. In version 2, if we need to support this
later, we can add it easily. It won't break backwards compat because
we will just be expanding the range.

--
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] Potential bug in Rule for Identifying the Media Type of a File

[Marcin Hanclik]

Hi Marcos,

These are my remarks as discussed yesterday on the call.

Comment a)

6.A.If all characters in the extension are outside the two ranges, then go to 
step 5 in this algorithm.

Should be

6.A.If any of the characters in the extension is outside the two ranges, then 
go to step 5 in this algorithm.

But this is also problematic since it infinitely loops the algorithm in this 
given case.
So it should be:

6.A.If any of the characters in the extension is outside the two ranges, then 
go to step 7 in this algorithm.

Another comment to 6.A:
It seems that the whole algorithm assumes that the File Identification Table is 
constant.
E.g. if any vendor would like to add some extension with a character outside of 
the given ranges (or we in W3C would like to do this in the future), then we 
would need to rewrite the algorithm.

So what about this (we do not need the ranges IMHO):
6.  Attempt to case-insensitively match the value of extension to one of the 
values in the file extension column in the file identification table. If there 
is a match, then return the corresponding value from the media type column and 
terminate this algorithm.
And remove 6.A and 6.B as they were.

*
Comment b)

4. If the first character of the name is a U+002E 'FULL STOP' character, and 
the file name contains no other U+002E 'FULL STOP' character then go to step 7 
of this algorithm.

What about .jpg?
Do you assume that this is filename and not file extension?

What about this:
4. If the first character of the name is a U+002E 'FULL STOP' character, and 
the file name contains no other U+002E 'FULL STOP' character then let extension 
be name and go to step 6 of this algorithm.

*
Comment c)

Given that the processing model is developed in prose, I think we MUST fix the 
ambiguity of the grammar anyway.
Thus I suggest the following change from:

file-name  = base-name [ file-extension ]
base-name  = 1*allowed-char
file-extension = . 1*allowed-char

to:

file-name  = 1*allowed-char

(i.e. remove base-name and file-extension).
The removal of ambiguity is motivated by the dependency of the WURI/WUS spec on 
PC in this particular detail, so it is better to keep it right, I think.
File extension does not play any role in WURI/WUS anyway.
I think either the above change or the one in my mail below has to be 
implemented in the spec.

*
Comment d)

We need to somehow derive the extension if the grammar is modified as in 
comment c) [i.e. removal of two rules].
Therefore I suggest the change from:

3. If the first character of the name is not a U+002E 'FULL STOP' character and 
the name has a file-extension  component, let extension be value of the 
file-extension component.

To:

3. Let extension be an empty string. If the first character of the name is 
not a U+002E 'FULL STOP' character and the file name contains U+002E 'FULL 
STOP' character, then let extension be the sequence of characters from the last 
U+002E 'FULL STOP' (inclusive) to the end of name and go to step 6 of this 
algorithm (as proposed in comment a) [no ranges etc.]).

SUMMARY
   1.

  Let file be the file to be processed.
   2.

  Let name be the file-name string component of the zip relative path that 
identifies the file.
   3.

  Let extension be an empty string. If the first character of the name is 
not a U+002E 'FULL STOP' character and the file name contains U+002E 'FULL 
STOP' character, then let extension be the sequence of characters from the last 
U+002E 'FULL STOP' (inclusive) to the end of name and go to step 6 of this 
algorithm

  For example, the extension of the file name cat.html would be .html.
   4.

  If the first character of the name is a U+002E 'FULL STOP' character, and 
the file name contains no other U+002E 'FULL STOP' character then let extension 
be name and go to step 6 of this algorithm.

  REMOVE For example, if the name is .htaccess, jump to step 7 and derive 
the mime type using the [SNIFF] specification.
ADD For example, if the name is .jpg, jump to step 6 and match 
image/jpeg.
   5.

  If the first character of the name is a U+002E 'FULL STOP' character, and 
the file name contains another U+002E 'FULL STOP' character, then let extension 
be the sequence of characters from the last U+002E 'FULL STOP' (inclusive) to 
the end of name.

  For example, if the name is .myhidden.html, then the extension would be 
.html.
   6.

  Attempt to case-insensitively match the value of extension to one of the 
values in the file extension column in the file identification table. If there 
is a match, then return the corresponding value from the media type column and 
terminate this algorithm.

   7. Return the result of processing file through the [SNIFF] specification.

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

RE: [WARP] uri attribute is confusing

[Marcin Hanclik]

Hi Stephen,

I share your opinion that local network.
I posted comments on more extensibility [1] in WARP.
I think your use case with private / local networks adds a lot to the target 
goal for WARP.

There is definitely a gap between what can become a standard and what remains 
at the vendors' discretion.
It is intentionally there to allow for differentiation.
However, the standard should not harm the introduction of extensions and, IMHO, 
the current WARP text would make e.g. the aspects of private network somehow 
incompatible.
I.e. @subdomains attribute makes no sense, the @uri attribute is based on 
prefix and does not accommodate the IP address range or pattern at all.
Thus for the local network case the implementers would simply not use WARP as 
is. E.g. access element would be used, but @uri (being mandatory in WARP, 
[2]) would be replaced with something else.

Therefore I think that WARP could be redesigned to e.g. be only a generic 
access element without attributes (those would be added by the 
vendors/communities etc.) or move to feature etc.

Thanks,
Marcin

[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0844.html
[2] http://www.w3.org/TR/2009/WD-widgets-access-20090804/#uri

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: Stephen Jolly [mailto:stephen.jo...@rd.bbc.co.uk]
Sent: Wednesday, October 07, 2009 12:52 PM
To: public-webapps WG
Cc: Phil Archer; Scott Wilson; Dominique Hazael-Massieux; Marcin Hanclik
Subject: Re: [WARP] uri attribute is confusing

Phil Archer wrote:
 The problem is finding the right amount of flexibility without making it
 too complicated or opening unwanted security holes.
...
 It depends on your use cases of course.

I guess the reason I've joined this discussion is that I'm concerned
that most of the schemes out there (including the one proposed for WARP)
don't allow the local network to be defined as a security domain, which
precludes use cases I care about.

The Opera widget security model has the concept of private addresses
(the RFC 1918 and 3927 ranges) - I presume that this group made the
conscious decision not to include this concept in the WARP model?

Personally, I'm not sure even the Opera model[1] (which talks about
these private addresses in the context of intranets) is as flexible as
one might like: you could make a good case that 127.0.0.0/8 and the UA
device's own IP address(es) masked by the appropriate subnet masks
should be added to that list.

It does all come down to the use cases though, and I guess my
fundamental question is still whether or not widget access to resources
on the local network is seen as important by this group.  Answers
welcome. :-)

S

[1] http://dev.opera.com/articles/view/opera-widgets-security-model/



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: View modes: more precision on fullscreen

[Marcin Hanclik]

Hi Robin,

OK.
E.g. all is currently not in VMMF, I am adding it now.
What do you mean by superseding in this context?
Shall we assume that VMMF will change (invalidate or possibly only add) PC in 
this matter?

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: Robin Berjon [mailto:ro...@berjon.com]
Sent: Monday, October 05, 2009 12:59 PM
To: Marcin Hanclik
Cc: public-webapps WG
Subject: Re: View modes: more precision on fullscreen

Hi Marcin,

On Oct 5, 2009, at 12:12 , Marcin Hanclik wrote:
 The mode in VMMF could be added, are we going to change PC as well?
 The all value from PC is a catch-all value.

I'd rather avoid changing P+C unless we need to - VMMF should be the
superseding document on this topic.

--
Robin Berjon - http://berjon.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.

[VMMF] Comments (1)

[Marcin Hanclik]

Hi All,

A couple of comment to the Widgets 1.0: View Modes Media Feature document [1]

1)
all value
What about the behavior of UA in case all is  specified in CSS?
Does it mean that the UA must pick any other view-mode and set it or does it 
mean that we do not care about the combination of the properties (current text)?
My opinion is that UA must pick up one value and set it. This would match the 
proposed behaviour for VMIF [2] wrt ViewModeChangedEvent. Otherwise, there 
seems to be no mode and the point 2) applies.

2) How many view-mode values do we foresee?
The properties of the presentation mode generate many possible values, the 
value of view-mode is actually just a selector of a specific combination.

Currently the values are as follows:
Chrome: yes/no (2)
Transparency: yes/no (2)
Overflow: visible/hidden/scroll/auto (4 values [auto selects 1 of 3, though])
Size control: user-agent/widget (2)
Interactivity: yes/no (2)
Initial width and height: used/ignored (2)

These are 7 bits altogether, 128 distinct combinations.
On the other hand we have 4 distinct view-mode values.

Question:
Do we allow other combinations of the properties?
If so, how do we handle the proposed ViewModeChangedEvent (possible issue for 
future)?
Maybe - instead - we should define some new set of media features, like: 
size-control, interactivity; or drop some of the properties to be very exact?

Thanks,
Marcin


[1] http://dev.w3.org/2006/waf/widgets-vmmf/
[2] 
http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html#viewmodes-events-viewmodechangedevent

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: [AE] Last Call comments (2): discovery localization

[Marcin Hanclik]

Hi Marcos,

 What if the feature name would be hardware://keyboard indicating that a 
 keyboard is required for the widget
or codec://H.264?

That would be fine.

 The above could be merged into device://dev/keyboard and 
 device://codec/H.264 respectively.

That would be fine too.

 (another BTW: similarly I would treat the network access as a runtime 
 component, see the WARP discussions).

That would also be fine too.
So let's imagine the following:
feature name=device://dev/keyboard required=false /

How do you test that keyboard is actually there then?
Do you assume that there will be some keyboard specific function to discover 
whether the keyboard is there?
Then we would need to prepare such a function for each feature.
Design like this would actually double the information required for 1 bit test 
of keyboard availability.
If device://dev/keyboard and a method like isKeyboardThere() would be 
required, then I think it is a non-optimal design/architecture.
Discovery mechanism in TWI based e.g. on IRI would work for all features, so I 
think it would be a more generic architecture.

Why? And also, in the case of APIs like geolocation, you just test if
the geolocation methods are there.
I think there are different opinions about that in general, see e.g. [1].

I don't understand why you would want
anything else?
Because not all features are APIs and not all non-API features need API to make 
the whole stuff work correctly, IRI is enough for identification of features' 
existence.

This is getting into the hasFeature() debate again. I
thought we had proved to you that hasFeature is no suitable and
basically borked.
I understand that hasFeature() has not worked on the Web as it was designed to 
work, specifically because in this context we talked only about APIs. Also, 
hasFeature() is still there in the currently discussed W3C drafts.
There are valid use cases where the discovery of the available, but optional, 
features are important, therefore I do not know why we should refrain from 
standardizing it.


Thanks,
Marcin

[1] http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/0034.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: Marcos Caceres [mailto:marc...@opera.com]
Sent: Friday, October 02, 2009 11:36 AM
To: Marcin Hanclik
Cc: public-webapps@w3.org
Subject: Re: [AE] Last Call comments (2): discovery  localization



Marcin Hanclik wrote:
 Hi Marcos,

 It is out of scope to define how bindings to features occur.
 Why? Where is the scope defined?

The scope (and binding way the binding occurs) is defined in the spec
that is behaving as a feature. Take Geolocation: it clearly states that
binding of the geolocation API happens on the Window object. I guess
that means the scope is the scripting environment.

If a feature wants to override the widget object, then that is ok with
me. We should not impose any restrictions on features and how they are
associated/bound/scoped/supplemented etc. to widgets.

 And yes, i.e. we should not limit bindings to API only.

Right.

 If you want to discover if you
 have a feature, try to run it.

 PC says:
  A feature is a runtime component (e.g. an Application Programming Interface 
 or video decoder) that is not part of the specified set provided by the 
 Widgets 1.0 family of specifications. The feature element serves as a 
 standardized means to request the binding of an (IRI) identifiable runtime 
 component to a widget for use at runtime. Using a feature element denotes 
 that, at runtime, a widget can attempt to access the feature  identified by 
 the feature element's name attribute.

 Therefore it is nowhere specified that you can run a feature. E.g. how 
 could you run a video decoder?

I don't know. What is the real question you are trying to ask?

 What if the feature has bigger scope than just a method or property?

That's fine. It could be like Google Frame, for all widgets care (i.e.,
completely take over the runtime and provide its own runtime).

 If we want to keep the feature more abstract, we should be able to discover 
 whether the feature was available during instantiation or installation of the 
 widget without prescribing that we must run a feature.

Why? And also, in the case of APIs like geolocation, you just test if
the geolocation methods are there. I don't understand why you would want
anything else? This is getting into the hasFeature() debate again. I
thought we had proved to you that hasFeature is no suitable and
basically borked.

 The phrase a runtime component does not entail the fact that the runtime 
 component is runnable. API is just an example.

Yes, that is fine. If it was not available at all, then the widget would
not have run. That is the rule.

If its run but not available within the scope of the scripting
environment, then the specification defining the feature

RE: [AE] Last Call comments (2): discovery localization

[Marcin Hanclik]

Hi Marcos,

Thanks for the proposal.
I agree with the approach you suggest.
1:1 we may have problems with consensus in this matter.

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: Marcos Caceres [mailto:marc...@opera.com]
Sent: Friday, October 02, 2009 1:44 PM
To: Marcin Hanclik
Cc: public-webapps@w3.org
Subject: Re: [AE] Last Call comments (2): discovery  localization



Marcin Hanclik wrote:
 Hi Marcos,

 What if the feature name would be hardware://keyboard indicating that a 
 keyboard is required for the widget
 or codec://H.264?

 That would be fine.

 The above could be merged into device://dev/keyboard and 
 device://codec/H.264 respectively.
 That would be fine too.

 (another BTW: similarly I would treat the network access as a runtime 
 component, see the WARP discussions).
 That would also be fine too.
 So let's imagine the following:
 feature name=device://dev/keyboard required=false /

 How do you test that keyboard is actually there then?
 Do you assume that there will be some keyboard specific function to discover 
 whether the keyboard is there?
 Then we would need to prepare such a function for each feature.
 Design like this would actually double the information required for 1 bit 
 test of keyboard availability.
 If device://dev/keyboard and a method like isKeyboardThere() would be 
 required, then I think it is a non-optimal design/architecture.
 Discovery mechanism in TWI based e.g. on IRI would work for all features, so 
 I think it would be a more generic architecture.

 Why? And also, in the case of APIs like geolocation, you just test if
 the geolocation methods are there.
 I think there are different opinions about that in general, see e.g. [1].

 I don't understand why you would want
 anything else?
 Because not all features are APIs and not all non-API features need API to 
 make the whole stuff work correctly, IRI is enough for identification of 
 features' existence.

 This is getting into the hasFeature() debate again. I
 thought we had proved to you that hasFeature is no suitable and
 basically borked.
 I understand that hasFeature() has not worked on the Web as it was designed 
 to work, specifically because in this context we talked only about APIs. 
 Also, hasFeature() is still there in the currently discussed W3C drafts.
 There are valid use cases where the discovery of the available, but optional, 
 features are important, therefore I do not know why we should refrain from 
 standardizing it.

I'm sorry Marcin, but I respectfully disagree with your position on this
matter. I do, however, understand your rationale.

Again, my personal position is that we do nothing in the Widget specs.
If means of detection are required by some feature, then the feature
must provide them.

I hand it to the rest of the working group to come up with consensus on
this issue.

Kind regards,
Marcos



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: Comments on View Modes Media Feature ED

[Marcin Hanclik]

Hi Robin,

Thanks for your comments.
My answers inline below.

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Robin Berjon
Sent: Thursday, September 24, 2009 2:37 PM
To: public-webapps WG
Subject: Comments on View Modes Media Feature ED

Hi,

here are my comments on 
http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.html
.

 Abstract
 This specification defines a media feature related to the
 presentation mode of the document. Multiple view modes are specified
 that allow for accomodation of various content presentation use
 cases. This document builds upon the Media Queries [MediaQueries]
 and Widgets-Packaging [Widgets-Packaging] specifications.

The terms media features and presentation mode should be linked to
their definitions.

various content presentation use cases is a bit vague, giving a few
examples afterwards could help make it more concrete.

 1. Introduction
 This document defines new media feature and its values.


I understand that this is a FPWD, but this is still a little bit
short :) At least adding a couple sentences to explain what they do
would help.

[MH] I added a bit more prose.

 1.4. Definitions
 Chrome
 The chrome encompases the visible parts of the user agent that do
 not depend on the content being rendered, such as minimize, restore/
 maximize, and close buttons in addition to adjacent items, such as
 title bars, toolbars and resize handlers. Scrollbars, though, are
 parts of the rendering area, and thus - being dependent on the
 content - may be rendered even if the regular chrome is not.


I think that this may be taking the risk of getting into trouble. For
instance, while it is true that some scrollbars belong to the content,
others belong to the chrome. Explaining all of that without tying
oneself to specifics is hard. How about The chrome is everything
rendered in visual media that is considered to belong to the user
agent but sits outside the CSS viewport?

[MH] I modified the text by combining what was there and your sentence.

 3. 'view-mode' media feature
 The view-mode feature describes the current rendering context for a
 widget.


This calls for a definition of rendering context.

[MH] Modified to the combination of view mode and media feature. I hope it is 
simpler now.

 3.1 View mode's properties
 The following table defines each of the view-modes' values in terms
 of its properties.


You say the following table but start with a list explaining the
table, it confuses people with slow brains like me. I think that it
might be clearer to put the table first, and place the legend (with a
Legend header) right after.

For the table I would also:

   - use th instead of td for the first row
Fixed.

   - use CSS instead of border=1
Fixed.

   - instead of having the left column be dfn, make them links (not
bold) to the view modes defined in the following section
Fixed.

An example of the sort of style I'm thinking of: 
http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css
  and grep for .simple.

   * chrome: its presence or absence,

Whether the chrome is shown or not

   * transparency: the user agent renders the view port with (CSS-
 equivalent) opacity zero with respect to the background or
 application environment,

I don't understand this, and I think that an equivalent to CSS opacity
zero doesn't do what you want (for one, it still gets interaction
events). Is this about whether the viewport is displayed or not?

[MH] This may need more detail. I hope to get feedback during WD review.
In case the part of the viewport is transparent (opacity zero), no events for 
the WUA and widget/document shall be fired. It may depend on the underlying 
graphics engine and its configuration. Some study could be made. I added new 
column about interactivity.

I'm thinking that maybe you're trying to make too much information fit
in a table, when sometimes the fields would need real sentences. For
instance, in addition to not really understanding this column, I
understand even less when the value is yes/no. It might be clearer
to use a dl and normative statements for each mode value.

[MH] Changed to more prose and more prose to come.

   * overflow: CSS overflow property for the viewport,

Same thing, I'm not sure what this applies to. Does floating really
have hidden overflow?

[MH] Yes. Do you have some usability issues in mind?

How does it relate to:

UAs must apply the 'overflow' property set on the root element to the
viewport. When the root element is an HTML HTML element or an XHTML
html element, and that element has an HTML BODY element or an
XHTML body element as a child, user agents must instead apply the
'overflow' property from the first such child element to the viewport,
if the value on the root element

RE: [WARP] uri attribute is confusing

[Marcin Hanclik]

Hi Dom, All,

I am not convinced by the need to include the word pattern in the name of the 
attribute taken the current WARP text.
Specifically because the semantics of the value of the attribute is more like 
namespace or just the leading part of the URI.
Pattern would be ok, if e.g. we would use regular expression or similar 
construct in the value of the attribute.

On the other hand, I think that having some pattern mechanism (like e.g. 
regular expression) would help in having better semantics of the functionality 
currently proposed behind access element.
The recent need to handle local network [1] could be probably satisfied based 
on regular expression / pattern for IP address in HTTP URI (related to the 
issue with subdomains as in [2]).
The private IP address ranges [3] could be then possibly fine-tuned if required 
by the application.
Pattern mechanism could nicely complement (or maybe replace to some extent?) my 
proposal from [2], however, we would risk it being too complex (maybe very good 
for Perl people, but could blur the actual value for an average RE reader; so 
we may discard this RE idea, specifically because the security model should not 
be too complex IMHO in order to be widely and successfully deployed).
I assume that some pattern mechanism could be discussed in the light of the 
recent comments on WARP and proposal to use POWDER (a bit too rich also IMHO, 
but maybe some subset could be adopted).

Thanks,
Marcin

[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0011.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0844.html
[3] http://tools.ietf.org/html/rfc1918


From: public-webapps-requ...@w3.org [public-webapps-requ...@w3.org] On Behalf 
Of Dominique Hazael-Massieux [...@w3.org]
Sent: Wednesday, September 23, 2009 3:19 PM
To: public-webapps@w3.org
Cc: ph...@w3.org
Subject: [WARP] uri attribute is confusing

Hi,

The attribute uri on the access element in WARP is somewhat
misleading - what it takes is more a URL pattern than a URI. I would
suggest renaming it in urlpattern or just pattern (unless there are
already many implementations that rely on that attribute name).

There may be lessons to be taken in designing these patterns from POWDER
http://www.w3.org/TR/2009/REC-powder-dr-20090901/ - although I suspect
the POWDER expressivity needs are much greater than what is needed here.

Dom






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: [AE] Last Call comments (1)

[Marcin Hanclik]

Hi Marcos,

 5.4.2#2.4.1
 ... apply the  rule for dealing with an invalid Zip archive ...
 And
 In the event that an implementation encounters an invalid Zip archive ...
 In the case the UA is a CC, it must inform the author that the Zip archive
is an invalid Zip archive. From PC.

 Do not play well together.
 The problem is with the WUA and not with the widget, so the correct
information should be provided to the user.

Sorry. I don't understand the problem, can you elaborate? Are you
saying that all UAs (not just CCs) must inform the end-user of the
error?
7.4.2 says:
If the user agent cannot write to the storage area (e.g., because it ran out 
of disk space, or the space quota was exceeded, etc.), apply the  rule for 
dealing with an invalid Zip archive specified in the [Widgets-Packaging] 
specification.

The problem is that the user agent cannot write to the storage area and the 
action is related to invalid Zip archive.
It is possible that the UA will inform the user that the Zip archive is invalid 
as part of the rule (probably added by the implementers).
And then the end-user would get notified e.g. that Widget is corrupted, 
whereas simply the WUA does not have enough quota.

 @href from license and license,

What is the use case?
Similar to description, nothing specific.
I think the rule could be to map the elements and attributes from config.xml to 
DOM. The spec could then probably be shorter and easily extensible.

 icons

What is the use case? Also, these may be changing dynamically so it
makes things a mess.
As above, just map what we have in config.xml.

 The above requirements seem contradicting and not prepared for handling the
security policy.

Which security policy?
Any, specifically the one planned for DAP.
At present we have WARP LCWD as a sample of the security policy.

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: Wednesday, September 23, 2009 6:10 PM
To: Marcin Hanclik
Cc: public-webapps@w3.org
Subject: Re: [AE] Last Call comments (1)

2009/9/15 Marcin Hanclik marcin.hanc...@access-company.com:
 The below comments refer to:
 Widgets 1.0: The widget Interface
 Editor's Draft 14 September 2009

 General:
 Replace can with may in the whole document.

I've used can deliberately throughout the document where statements of
fact are made. To use may would result in a conformance clause where
one is not needed.

 2.
 Feature
 Why to repeat the definition from PC?

People complain about having to jump from spec to spec. Makes the
document easier to read.

 Getting / Setting
 Refer to HTML5 for those definitions?

No, they are defined in WebStorage but I stole them  (muahaha!) :) I
only reference other specs where something that affects
conformance/behavior is said.

 Viewport
 [1] says that scrollbars are part of the rendering area
 (I do not claim that it is fully correct, I assume scrollbars are a 
 discussion point, specifically in the context of DHTML where they could 
 appear and vanish depending on the dynamic content).
 My proposal is to make this definition non-final.

 All definitions:
 Could we have a document with the definitions for all specifications from the 
 family?

That could be possible, but some definitions are inline - better to
leave them where they are and just follow the anchors in the document.

 3.
 achived - achieved

Fixed.

 4.
 Again about the definitions:
 Could we have a common definition of the user agent, decoupled from the specs?
 (e.g. UA in PC is an implementation, here it is a software implementation)

Yes, we have talked about this but just haven't got around to doing
it. I personally don't think we need an overarching definition,
however. The more modular these specs are, the better IMO. We try to
make it pretty clear what the dependencies for each UA are.

 4.2
 a read-only item is an item in a storage area cannot be ...
 should be
 a read-only item is an item in a storage area that cannot be ...

Fixed.

 5.
 Why aren't the following attributes available on the widget interface?
 @viewmodes from widget,

That's your spec :) Add it as supplemental attribute to the widget interface.

 @short from name,

I would not mind adding this one, maybe calling it widget.shortname.

 @href from license and license,

What is the use case?

 icons

What is the use case? Also, these may be changing dynamically so it
makes things a mess.

I think we should create and Icon API at some point in the near future
(leverage HTML5 cross-doc communication), but we should not add
anything poorly specified now.

 5.
 It preferences(via the preferences attribute).
 Unclear.

Yikes, changed it to:
The interface also allows authors to access persistently-stored
preferences (via the preferences attribute).

 5.
 A user agent

RE: [widgets] Potential bug in Rule for Identifying the Media Type of a File

[Marcin Hanclik]

Hi Marcos,

Good spot!

2. If file has a file-extension, attempt to match the file-extension
to one in the file extensions column in the file identification table.
If there is a match, then return the media type value. (returns
image/jpeg)
I think file-extension would not be matched, but only base-name.

I think the grammar is not ambiguous with regard to which rules would be 
matched.
The problem is that at present in case of .jpg, there would be no file 
extension.
A greedy parser would only match base-name and leave file-extension empty, 
since it is optional.
So we need to modify the grammar to clearly specify what the extension is.
With the current grammar, there is also a problem that . is also allowed in 
the file-extension as part of the allowed-char.
Therefore any parser may be confused which dot is the . from the 
file-extension rule (I am not sure whether a parser can be developed at all).
And thus, file-extension has problems. I assume that file extensions do not 
have dots, dot is to be the delimiter.

What about modifying the ABNF to:

file-name = file-name-with-extension | file-name-no-extension

file-name-with-extension  = base-name file-extension

base-name = *allowed-char

file-extension= . 1*allowed-char-no-dot

allowed-char-no-dot   = safe-char-no-dot / utf8-char

safe-char-no-dot  = ALPHA / DIGIT / SP / $ / %
   / ' / - / _ / @
   / ~ / ( / ) /  / +
   / , / . / = / [ / ]

file-name-no-extension= base-name-no-ext

base-name-no-ext  = 1*allowed-char-no-dot

This would make the base-name optional.
.jpg is a valid file name, specifically on Linux platforms.
Then, .jpg would have (only) a file extension and probably the prose of PC 
would not need to be changed.

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Marcos Caceres
Sent: Tuesday, September 29, 2009 4:51 PM
To: public-webapps
Subject: [widgets] Potential bug in Rule for Identifying the Media Type of a 
File

Hi, I think I found another bug :(

The current ABNF for a zip relative path allows the first character of
a file name to be a ..

So, imagine you have a file in the zip archive called .jpg which is
actually a text file.

In the Rule for Identifying the Media Type of a File, it reads:

1. Let file be the file to be processed. (in this case, .jpg)
2. If file has a file-extension, attempt to match the file-extension
to one in the file extensions column in the file identification table.
If there is a match, then return the media type value. (returns
image/jpeg)
3. If file extension is absent, the media type of a file is determined
by using the rules set forth in the [SNIFF] specification.

So, the rule has incorrectly matched the type and returns image/jpeg.

Options:

1. Disallow . in the base-name of a file (this means that files
named a...b...c. will be ignored, and so are any file starting with
a .: .foobar).
2. Modify 2 above to say:
   If file has a file-extension and a base-name, ... 
  And modify 3, to say Otherwise, the media type of a file is
determined by using the rules set forth in the [SNIFF] specification.

However, because of the ambiguity caused by allowing . in base
names, it is basically not possible to determine if the file
extension of a file is in fact a file extension or a base name.

Unsure how to proceed as it is likely that .filename type files will
end up in widget packages it might be safe for user agents to
ignore those files.

--
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] Draft Agenda for 24 September 2009 Voice Conf

[Marcin Hanclik]

Hi Marcos,

I'm still confused as to why we can't keep both. Is it because of redundancy?
Yes. My personal opinion is that one source of the same information would be 
enough. It could be a kind of optimization.

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: Wednesday, September 23, 2009 6:15 PM
To: Marcin Hanclik
Cc: Arthur Barstow; public-webapps
Subject: Re: [widgets] Draft Agenda for 24 September 2009 Voice Conf

On Wed, Sep 23, 2009 at 4:36 PM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
 Hi,

 One more comment to the below:
 There is one use case not handled by the below scenarios:
 In case the width/height are dropped on the Widget interface, the widget 
 would not know the initial dimensions.
 E.g. in Win32 each new window get WM_SIZE event with the initial width/height.
 However, I am not sure whether we should mandate the ResolutionChangedEvent 
 to be used for the initial viewport size.

 So I would opt for keeping the ResolutionChangedEvent, dropping width/height 
 on the ResolutionChangedEvent, and keeping width/height in the Widget 
 interface.


I'm still confused as to why we can't keep both. Is it because of redundancy?


--
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] Draft Agenda for 24 September 2009 Voice Conf

[Marcin Hanclik]

Hi Art, All,

I will not be able to attend the call today, since I will be traveling (it just 
confirm it).

Ad 6.
I have committed the document with your proposed modifications.
I would vote for FPWD to start the open discussion.

Ad 7.
I do not know the details of Arve's issues, but I assume they are related to 
orientation event. Rotation may probably provide more info (e.g. more exact 
angles etc.), though.
The VM interfaces draft is quite buggy now, but we could start discussing it as 
well (e.g. orientation is not defined).

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Arthur Barstow
Sent: Wednesday, September 23, 2009 1:56 PM
To: public-webapps
Subject: [widgets] Draft Agenda for 24 September 2009 Voice Conf

Below is the draft agenda for the September 24 Widgets Voice
Conference (VC).

Inputs and discussion before the VC on all of the agenda topics via
public-webapps is encouraged).

Please address Open/Raised Issues and Open Actions before the meeting:

   http://www.w3.org/2008/webapps/track/products/8

Minutes from the last VC:

   http://www.w3.org/2009/09/17-wam-minutes.html

-Regards, Art Barstow

Logistics:

 Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London;
09:00 Boston; 06:00 Seattle
 Duration = 90 minutes
 Zakim Bridge = +1.617.761.6200, +33.4.89.06.34.99 or
+44.117.370.6152
 PIN = 9231 (WAF1);
 IRC channel = #wam; irc://irc.w3.org:6665
 Confidentiality of minutes = Public

Regrets: Marcos, Marcin, Josh

Agenda:

1. Review and tweak agenda

2. Announcements

a. News/summary from the Widget Testing event
   http://www.w3.org/2008/webapps/wiki/TestWorkshop2009

3. Widget Interface spec: proposal to publish LCWD #2

  http://dev.w3.org/2006/waf/widgets-api/

4. Access Requests Policy (WARP) spec: comment period ended Sept 20;
review comments

  http://dev.w3.org/2006/waf/widgets-access/
  http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-
access-20090804/

5. URI Scheme spec: status of LC publication

  http://dev.w3.org/cvsweb/2006/waf/widgets-uri/

6. View Modes Media Features spec: proposal to publish FPWD

  http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.html

7. View Modes Interfaces spec: Arve (from IRC) the bit that troubles
me is rotation

  http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html

8. AOB






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] Draft Agenda for 24 September 2009 Voice Conf

[Marcin Hanclik]

Hi Art, All,

I would like to suggest to add to the agenda the point that appeared during the 
widgets testing event.
It is related to the Widget Interface, View Modes and patterns.
The comments below will be valid also as LC comments to the Widget Interface.

The Widget Interface includes width and height attributes. On the other hand 
the View Modes Interfaces defines the ResolutionChangedEvent event.
So we may have at least the following scenarios:
Scenario 1:

a) the dimensions of the viewport change.

b) the ResolutionChangedEvent is fired.

c) the widget gets the new dimensions from the event

Scenario 2:

a) the dimensions of the viewport change.

b) the ResolutionChangedEvent is fired.

c) the widget gets the new dimensions from the Widget interface (the widget 
object)

Incorporating the onresize handler on the body element, we could have another 
scenarion:
Scenario 2:

a) the dimensions of the viewport change.

b) the onresize handler is triggered.

c) the widget gets the new dimensions from the Widget interface (the widget 
object)

So we have 3 scenarios for 1 thing (notification about changed size and 
retrieval of the new dimensions).
If we want to keep ResolutionChangedEvent, we have two methods of getting the 
new width/height:

i) from the ResolutionChangedEvent

ii) from the Widget interface

Therefore I suggest picking up one of the following:

1. Drop the ResolutionChangedEvent, mandate onresize handler, keep width/height 
in the Widget interface.

2. Drop width/height from the ResolutionChangedEvent, ignore onresize handler, 
keep width/height in the Widget interface.

3. Keep the ResolutionChangedEvent, ignore onresize handler, drop width/height 
in the Widget interface.

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Arthur Barstow
Sent: Wednesday, September 23, 2009 1:56 PM
To: public-webapps
Subject: [widgets] Draft Agenda for 24 September 2009 Voice Conf

Below is the draft agenda for the September 24 Widgets Voice
Conference (VC).

Inputs and discussion before the VC on all of the agenda topics via
public-webapps is encouraged).

Please address Open/Raised Issues and Open Actions before the meeting:

   http://www.w3.org/2008/webapps/track/products/8

Minutes from the last VC:

   http://www.w3.org/2009/09/17-wam-minutes.html

-Regards, Art Barstow

Logistics:

 Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London;
09:00 Boston; 06:00 Seattle
 Duration = 90 minutes
 Zakim Bridge = +1.617.761.6200, +33.4.89.06.34.99 or
+44.117.370.6152
 PIN = 9231 (WAF1);
 IRC channel = #wam; irc://irc.w3.org:6665
 Confidentiality of minutes = Public

Regrets: Marcos, Marcin, Josh

Agenda:

1. Review and tweak agenda

2. Announcements

a. News/summary from the Widget Testing event
   http://www.w3.org/2008/webapps/wiki/TestWorkshop2009

3. Widget Interface spec: proposal to publish LCWD #2

  http://dev.w3.org/2006/waf/widgets-api/

4. Access Requests Policy (WARP) spec: comment period ended Sept 20;
review comments

  http://dev.w3.org/2006/waf/widgets-access/
  http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-
access-20090804/

5. URI Scheme spec: status of LC publication

  http://dev.w3.org/cvsweb/2006/waf/widgets-uri/

6. View Modes Media Features spec: proposal to publish FPWD

  http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.html

7. View Modes Interfaces spec: Arve (from IRC) the bit that troubles
me is rotation

  http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html

8. AOB






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] Draft Agenda for 24 September 2009 Voice Conf

[Marcin Hanclik]

Hi,

One more comment to the below:
There is one use case not handled by the below scenarios:
In case the width/height are dropped on the Widget interface, the widget would 
not know the initial dimensions.
E.g. in Win32 each new window get WM_SIZE event with the initial width/height.
However, I am not sure whether we should mandate the ResolutionChangedEvent to 
be used for the initial viewport size.

So I would opt for keeping the ResolutionChangedEvent, dropping width/height on 
the ResolutionChangedEvent, and keeping width/height in the Widget interface.

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Marcin Hanclik
Sent: Wednesday, September 23, 2009 3:22 PM
To: Arthur Barstow; public-webapps
Subject: RE: [widgets] Draft Agenda for 24 September 2009 Voice Conf

Hi Art, All,

I would like to suggest to add to the agenda the point that appeared during the 
widgets testing event.
It is related to the Widget Interface, View Modes and patterns.
The comments below will be valid also as LC comments to the Widget Interface.

The Widget Interface includes width and height attributes. On the other hand 
the View Modes Interfaces defines the ResolutionChangedEvent event.
So we may have at least the following scenarios:
Scenario 1:

a) the dimensions of the viewport change.

b) the ResolutionChangedEvent is fired.

c) the widget gets the new dimensions from the event

Scenario 2:

a) the dimensions of the viewport change.

b) the ResolutionChangedEvent is fired.

c) the widget gets the new dimensions from the Widget interface (the widget 
object)

Incorporating the onresize handler on the body element, we could have another 
scenarion:
Scenario 2:

a) the dimensions of the viewport change.

b) the onresize handler is triggered.

c) the widget gets the new dimensions from the Widget interface (the widget 
object)

So we have 3 scenarios for 1 thing (notification about changed size and 
retrieval of the new dimensions).
If we want to keep ResolutionChangedEvent, we have two methods of getting the 
new width/height:

i) from the ResolutionChangedEvent

ii) from the Widget interface

Therefore I suggest picking up one of the following:

1. Drop the ResolutionChangedEvent, mandate onresize handler, keep width/height 
in the Widget interface.

2. Drop width/height from the ResolutionChangedEvent, ignore onresize handler, 
keep width/height in the Widget interface.

3. Keep the ResolutionChangedEvent, ignore onresize handler, drop width/height 
in the Widget interface.

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Arthur Barstow
Sent: Wednesday, September 23, 2009 1:56 PM
To: public-webapps
Subject: [widgets] Draft Agenda for 24 September 2009 Voice Conf

Below is the draft agenda for the September 24 Widgets Voice
Conference (VC).

Inputs and discussion before the VC on all of the agenda topics via
public-webapps is encouraged).

Please address Open/Raised Issues and Open Actions before the meeting:

   http://www.w3.org/2008/webapps/track/products/8

Minutes from the last VC:

   http://www.w3.org/2009/09/17-wam-minutes.html

-Regards, Art Barstow

Logistics:

 Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London;
09:00 Boston; 06:00 Seattle
 Duration = 90 minutes
 Zakim Bridge = +1.617.761.6200, +33.4.89.06.34.99 or
+44.117.370.6152
 PIN = 9231 (WAF1);
 IRC channel = #wam; irc://irc.w3.org:6665
 Confidentiality of minutes = Public

Regrets: Marcos, Marcin, Josh

Agenda:

1. Review and tweak agenda

2. Announcements

a. News/summary from the Widget Testing event
   http://www.w3.org/2008/webapps/wiki/TestWorkshop2009

3. Widget Interface spec: proposal to publish LCWD #2

  http://dev.w3.org/2006/waf/widgets-api/

4. Access Requests Policy (WARP) spec: comment period ended Sept 20;
review comments

  http://dev.w3.org/2006/waf/widgets-access/
  http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-
access-20090804/

5. URI Scheme spec: status of LC publication

  http://dev.w3.org/cvsweb/2006/waf/widgets-uri/

6. View Modes Media Features spec: proposal to publish FPWD

  http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.html

7. View Modes Interfaces spec: Arve (from IRC) the bit that troubles
me is rotation

  http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html

8. AOB






Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke

RE: [WARP] Last Call comments (1)

[Marcin Hanclik]

Hi Robin,

I understand the 80/20 principle.
It is about quality.
I am however not sure that publication of the spec as is will result in the 
companies listed below to adjust to the correct meaning.

BONDI has network-access which is different
It was done, because there was no access when BONDI discussed this.
And actually in BONDI no-one seems to be against the proposals of making the 
design more robust based on feature.
My proposal is not about syntax, but about semantics that is missing in WARP.

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: Robin Berjon [mailto:ro...@berjon.com]
Sent: Thursday, September 17, 2009 4:41 PM
To: Marcin Hanclik
Cc: Marcos Caceres; public-webapps@w3.org
Subject: Re: [WARP] Last Call comments (1)

On Sep 8, 2009, at 11:00 , Marcin Hanclik wrote:
 As stated in my original email, one of the targets is that access
 is not an obstacle for DAP.

The design was based on:

  - not restricting DAP's ability to define a security policy
  - enabling boolean access to URIs
  - having pattern matching that covers most cases
  - making sure that web content that works outside of a widget can
work inside a widget

 It is currently undefined how the related access control will be
 done and we would probably want to avoid the situation that access
 is deprecated once DAP is ready with their model.

Quite the contrary. If all goes well DAP's security policy will be
available within a couple years, and after that we'll need another
year before it ships as presumably it'll have some degree of
complexity. That's all fine but the problem that we have today is that
people are shipping implementations with support for something a lot
like access but that are not compatible. Just off the top of my head
I know that Opera has their own stuff (which was the original
proposal), BONDI has network-access which is different, JIL has
something of their own with different default rules, and Microsoft has
a widget engine using access from the December 2008 PC draft.

What WARP does is that it provides the strictly minimal solution that
will make interoperability possible before DAP finishes its work,
while adhering to its fundamental design principles. If it gets
obsoleted, superseded, set on fire in public displays of wrath, or
trampled by a horde of arctic hippopotami on MDMA then great. The
primary goal is to gain 3 years of interoperability which we need to
have. A complementary goal is that since we want content created
conforming to WARP today to be valid forever is that the policies that
WARP enables should be expressible using whatever DAP comes up with,
so that access can be defined as simply a syntactical shortcut to DAP.

In other words it is future-proof *because* it is simple. It's
extensible (if we need to, which I don't think we should) because it's
XML (and because its processing model is intended for that).

--
Robin Berjon - http://berjon.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: [WARP] Last Call comments (1)

[Marcin Hanclik]

Hi Robin,

Herewith I reply to both your recent answers [1] and [2].

It is good for me to see that the intentions and scope of the WARP spec get 
clarified upon discussion.

 Schemes such as sms and tel are definitely out of scope for
this simple approach.
If so, then please add clear rules to the spec which schemes are in scope.
These are the hints:

a)
A network resource is a retrievable resource of any type that is identified by 
a URI that has a DNS or IP as its authority.
So here sms: and tel: seem out of scope. What about E164 and DNS [3]?
Another edge case:
sms:+41796431851;pid=smtp:i...@dret.net from [4]

b)
This special value provides a means for an author to request from the user 
agent unrestricted access to resources through any and all schemes and 
protocols supported by the user agent.
Here the set of schemes is infinite. So I suggest adding the relevant text, e.g.
This special value provides a means for an author to request from the user 
agent unrestricted access to network resources through any and all schemes and 
protocols that have DNS or IP as its authority and that are supported by the 
user agent.

Schemes such as sms and tel are definitely out of scope for this
simple approach. Even if they weren't they would *still* be out of
scope for access because they aren't network resources. You can't
make an XHR request to sms:, it is meaningless to have img
src='tel:...'/. These are therefore rejected immediately - just
because it has a scheme doesn't mean it's a network resource, those
are two completely separate things.
Can you do XHR to mailto:? Or img src='mailto:...'?
But mailto: is explicitly mentioned in WARP.

There is a major distinction here. When you use mailto: or tel:, it
triggers an external application (email client, phone dialer)
Not necessarily. My mail client may be another widget/webapp.
Similarly to tel: (depends on DAP).

 and you
can decide from within that application whether to enact those. If you
have access to a messaging or calling API, then you can do those
stealthily - but that's not WARP's problem, it's DAP's problem.
From the security point of view it does not matter whether a message or a call 
was accomplished by a programmatic call to device API or by an external 
application that was triggered by the URI embedded in a widget. If restricted, 
it should simply not happen. I understand that this is a DAP issue, therefore 
I suggest to leave it all to DAP.

In general, if the text of WARP specifies that WARP is only about http, https, 
and XHR I could live with it.


Thanks,
Marcin

[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1113.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1114.html
[3] http://www.ietf.org/rfc/rfc2916.txt
[4] http://tools.ietf.org/html/draft-wilde-sms-uri-00#section-2.4

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: Robin Berjon [mailto:ro...@berjon.com]
Sent: Thursday, September 17, 2009 4:27 PM
To: Marcin Hanclik
Cc: Marcos Caceres; public-webapps@w3.org
Subject: Re: [WARP] Last Call comments (1)

On Sep 7, 2009, at 15:11 , Marcin Hanclik wrote:
 is pretty simple, logical, and gets the job done for most use cases.

 The above is not the case e.g. for mailto: or tel:, specifically if
 you want to be more specific/selective with the additional arguments
 (a la subdomains).

There is a major distinction here. When you use mailto: or tel:, it
triggers an external application (email client, phone dialer) and you
can decide from within that application whether to enact those. If you
have access to a messaging or calling API, then you can do those
stealthily - but that's not WARP's problem, it's DAP's problem.

What WARP is concerned with is whatever access can be made without
user interaction (an img/@src, or an XHR request) that is possible
today in a WRT. Anything else is out of scope, and is DAP's job.

--
Robin Berjon - http://berjon.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.

[WARP] Last Call comments (2)

[Marcin Hanclik]

What is the relation of access element to openURL from Widget interface 
specification?

openURL examples use sms: and tel:.



As discussed in another mail thread [1], the scope of WARP in terms of 
programmatic usage of URIs focuses on XHR.

Should then openURL be incorporated there as well?



Thanks,

Marcin



[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0844.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




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: [WARP] Last Call comments (1)

[Marcin Hanclik]

Hi Robin,

Please bear in mind that my proposal moves the access's @uri to param 
name=uri value=XXX/ and not to feature's @name.
The distinction is clear.
Thus there seems to be no confusion.

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: Robin Berjon [mailto:ro...@berjon.com]
Sent: Thursday, September 17, 2009 4:43 PM
To: Frederick Hirsch
Cc: Marcin Hanclik; public-webapps@w3.org
Subject: Re: [WARP] Last Call comments (1)

On Sep 10, 2009, at 15:00 , Frederick Hirsch wrote:
 Is the fundamental difference of feature and access the following:

 feature - API set expected to be possibly used
 access - network resource to be accessed.

Exactly. I think that part of the confusion stems from the different
uses of URIs. For features they're just identifiers, for access
they're locators (or partial patterns on locators).

--
Robin Berjon - http://berjon.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.

[WARP] Last Call comments (3)

[Marcin Hanclik]

In section 1.3 [1] (non-normative) I suggest changing all the instances of word 
service to resource.
Service could mean e.g. mail, telephony, messaging service etc. and WARP is 
about access to retrievable network resources.

Thanks,
Marcin

[1] http://dev.w3.org/2006/waf/widgets-access/#design-goals-and-requirements


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: [WARP] Last Call comments (1)

[Marcin Hanclik]

Hi Robin,

I am further trying to align the syntax and semantics of WARP.

The design was based on:
...
  - enabling boolean access to URIs
...
As in the previous emails, I assume that WARP should more underline the 
retrievable character of the network RESOURCE.
Then mailto: should not be mentioned at all (or mentioned as not in scope for 
WARP, bad example due to non-retrievability etc). Then the following sentence:

However, a user agent may grant access to certain URI schemes (e.g., mailto:) 
without the need of an access request if its security policy considers those 
schemes benign.

could be rephrased e.g. to:

It is out of the scope of this specification how schemes other than http, 
https and interfaces other than XmlHttpRequest access the network.

Similarly I assume that e.g. a element is out of the scope, this could entail 
that openURL from widget interface would be excluded as well (aka my previous 
email).

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: Robin Berjon [mailto:ro...@berjon.com]
Sent: Thursday, September 17, 2009 4:41 PM
To: Marcin Hanclik
Cc: Marcos Caceres; public-webapps@w3.org
Subject: Re: [WARP] Last Call comments (1)

On Sep 8, 2009, at 11:00 , Marcin Hanclik wrote:
 As stated in my original email, one of the targets is that access
 is not an obstacle for DAP.

The design was based on:

  - not restricting DAP's ability to define a security policy
  - enabling boolean access to URIs
  - having pattern matching that covers most cases
  - making sure that web content that works outside of a widget can
work inside a widget

 It is currently undefined how the related access control will be
 done and we would probably want to avoid the situation that access
 is deprecated once DAP is ready with their model.

Quite the contrary. If all goes well DAP's security policy will be
available within a couple years, and after that we'll need another
year before it ships as presumably it'll have some degree of
complexity. That's all fine but the problem that we have today is that
people are shipping implementations with support for something a lot
like access but that are not compatible. Just off the top of my head
I know that Opera has their own stuff (which was the original
proposal), BONDI has network-access which is different, JIL has
something of their own with different default rules, and Microsoft has
a widget engine using access from the December 2008 PC draft.

What WARP does is that it provides the strictly minimal solution that
will make interoperability possible before DAP finishes its work,
while adhering to its fundamental design principles. If it gets
obsoleted, superseded, set on fire in public displays of wrath, or
trampled by a horde of arctic hippopotami on MDMA then great. The
primary goal is to gain 3 years of interoperability which we need to
have. A complementary goal is that since we want content created
conforming to WARP today to be valid forever is that the policies that
WARP enables should be expressible using whatever DAP comes up with,
so that access can be defined as simply a syntactical shortcut to DAP.

In other words it is future-proof *because* it is simple. It's
extensible (if we need to, which I don't think we should) because it's
XML (and because its processing model is intended for that).

--
Robin Berjon - http://berjon.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: [AE] LC deadline: request to prolong LC period

[Marcin Hanclik]

Hi Art,

Thank you for the clarification.

Kind regards,
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: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Wednesday, September 16, 2009 12:49 AM
To: public-webapps; Marcin Hanclik
Subject: Re: [AE] LC deadline: request to prolong LC period

All,

On Sep 15, 2009, at 5:35 PM, ext Marcin Hanclik wrote:

 Herewith I would like to ask for extending the LC period for AE
 LCWD by 1 week.
 I have just provided some comments and have a feeling that I could
 provide more, specifically related to ViewModes and WebStorage.

As with all of WebApps' specs, regardless of their maturity
level [1], comments are welcome at any time.

Regarding the 18-Aug-2009, Widgets AE LCWD - to address the
substantive comments already submitted, the next publication will be
another Working Draft (possibly a LCWD); that document is not yet
ready to advance to Candidate. Consequently, everyone can and should
continue to submit comments about the AE spec (nka Widget Interface
[2]) but this LCWD's comment period will not be extended.

-Regards, Art Barstow

[1] http://www.w3.org/2005/10/Process-20051014/tr.html#maturity-levels
[2] http://dev.w3.org/2006/waf/widgets-api/







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: Normalization, was: RE: [Widget URI] Internationalization, widget IRI?

[Marcin Hanclik]

Hi Marcos,

I will try to do it next week in Dusseldorf then.
Even if an/your implementation handles it, I assume the details should be 
speced.

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: Wednesday, September 16, 2009 4:17 PM
To: Marcin Hanclik
Cc: Robin Berjon; public-webapps WG
Subject: Re: Normalization, was: RE: [Widget URI] Internationalization, widget 
IRI?

Marcin,
Lets try this another way. Can you make me a widget that explicitly
demos the problem? I will then run it against our implementation and
see what happens.

I will also add the widget to the test suite, to make sure we expose
and potential misunderstandings in the spec wrt URIs.

Kind regards,
Marcos

On Wed, Sep 16, 2009 at 4:08 PM, Marcos Caceres marc...@opera.com wrote:
 On Wed, Sep 16, 2009 at 12:32 PM, Marcin Hanclik
 marcin.hanc...@access-company.com wrote:
 Hi Marcos,

So it turns out that %-encoded really just means replace this '%xx'
with UTF-8 bytes.
 Yes.

So we don't need to do anything.
 PC shall state the actual algorithm and equivalence.

 http://www.w3.org/TR/2009/WD-widgets-apis-20090423/
 had this issue:
 ISSUE: do we need to do some kind of URI normalization to check for 
 equivalency?

 According to RFC3987, 5.1:
   Applications using IRIs as identity tokens with no relationship to a
   protocol MUST use the Simple String Comparison (see section 5.3.1).
   All other applications MUST select one of the comparison practices
   from the Comparison Ladder (see section 5.3 or, after IRI-to-URI
   conversion, select one of the comparison practices from the URI
   comparison ladder in [RFC3986], section 6.2)

 @href may fall into Comparison Ladder case, id into namespaces.
 The question (still the same) is whether in case of @name of feature the 
 IRIs are used as identity tokens (id, simple string) or anything else/new.


 They are namespaces. I actually raised this issue a long time ago too
 because I had the same concerns as you. The WG decided that strings
 that name things (@id, @name) are treated as namespaces.

 Once the answer is that IRIs are to be treated as identity tokens (as you 
 propose and I agree), then we still have the issue of expressing the 
 non-ASCII IRIs in ASCII documents (border case). Then we would need a 
 guideline / example that in XML the author shall use character entities to 
 encode the IRI (I marked this solution awkward, but I could live with it).


 I think Addison already said this was not a problem: if you know the
 encoding of the XML document, you know the encoding of the URI. URI
 are always treated as UTF-8 internally. There is no problem here.


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




--
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: [WARP] Last Call comments (1)

[Marcin Hanclik]

Hi Frederick,

I do not think they are so different.
feature points to anything, we can still build the interpretation.
We can build new worlds on top of feature and param elements, 
independently of any spec IMHO.
feature does not necessarily have to point to the same category of 
components, we can define the categories in any way, e.g. by various IRI 
namespaces.

I think it can be disputable what access is for.
WARP says:
 A network resource is a retrievable resource of any type that is identified 
by a URI that has a DNS or IP as its authority.

Then, how to fit e.g. sms: or tel: schemes into this context?
@subdomains makes also little sense for those schemes.
Apart from DNS/IP issues, I assume that some Web resources are not meant to 
be retrievable, e.g. POSTing a form uses URI to send information to, and not to 
retrieve a resource.
If we would like the spec to be future-/scheme-proof, we could prepare the 
model based on actual schemes, as e.g. suggested in my below email. Experience 
from CORS could also help.

if so, doesn't feature imply both the loading and permission to access
a library, whereas access is about accessing a resource.
E.g. generic network access (not to specific resource, but just to the 
information whether the WUA is online/connected) may be regarded as runtime 
component of the WUA or its environment.

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: Thursday, September 10, 2009 3:01 PM
To: Marcin Hanclik
Cc: Frederick Hirsch; public-webapps@w3.org
Subject: Re: [WARP] Last Call comments (1)

Is the fundamental difference of feature and access the following:

feature - API set expected to be possibly used
access - network resource to be accessed.

if so, doesn't feature imply both the loading and permission to access
a library, whereas access is about accessing a resource.

if this is correct, aren't these fundamentally different?

regards, Frederick

Frederick Hirsch
Nokia



On Aug 27, 2009, at 2:06 PM, ext Marcin Hanclik wrote:

 Hi All,

 Here are a couple of the Last Call comments to WARP LCWD [1].
 They were already partially presented in my emails [2] and [3].

 The comments below are more of architectural nature than just
 editorial fixes.
 That is why the arguments together with the derived understanding
 are followed by the proposed changes to the specification. The
 proposed changes below are incomplete.

 MOTIVATION / ARGUMENTS

 The main motivation for the changes proposed below is the syntax and
 the underlying architecture related to the treatment of the network
 access - from the widget's or web application's point of view - as
 the resource to which access is to be controlled by some security
 policy.

 The specification that underlies the overall widgets ecosystem,
 Widgets 1.0: Packaging and Configuration (further referred to as
 PC) [4], defines a method to express the dependency of the widget
 on a resource/component, namely the feature element.
 PC in [5] - the definition of the feature element - states:

 A feature is a runtime component

 The feature element serves as a standardized means to request the
 binding of an (IRI) identifiable runtime component to a widget for
 use at runtime.

 ...a widget can attempt to access the feature identified by the
 feature element's name attribute.

 PC [6] states non-normatively:
 The Widgets 1.0: Access Requests specification defines a means to
 request access to URI-identifiable resources (e.g. resources on the
 Web) (see [Widgets-Access]).

 On the other hand, however, WARP states [7]:
  The purpose of this specification is precisely to define the
 security model for network interactions from within a widget that
 has access to sensitive information, and to provide means for a
 widget to declare the need to access specific network resources so
 that a policy may control it.
 And [8]
 A network resource is a retrievable resource of any type that is
 identified by a URI that has a DNS or IP as its authority.

 WARP states that it addresses [9] the requirements [10] and [11].

 [10] R52 Default Security Policy:

 A conforming specification MUST specify a default security policy
 that limits the privileges afforded to a widget at runtime. The
 default security policy MUST be specified in such a way that it
 forces a widget package to explicitly request permission to use
 particular device capabilities (see also the Security Declarations
 requirement).

 [11] R54 Security Declarations:

 A conforming specification MUST specify or recommend a means for
 declaring that an instantiated widget will require access to
 resources or services that have the potential to introduce a
 security risk for an end user. A conforming specification SHOULD
 also make it possible to externalize and associate security

[AE] Last Call comments (1)

[Marcin Hanclik]

The below comments refer to:
Widgets 1.0: The widget Interface
Editor's Draft 14 September 2009

General:
Replace can with may in the whole document.

2.
Feature
Why to repeat the definition from PC?

Getting / Setting
Refer to HTML5 for those definitions?

Viewport
[1] says that scrollbars are part of the rendering area
(I do not claim that it is fully correct, I assume scrollbars are a discussion 
point, specifically in the context of DHTML where they could appear and vanish 
depending on the dynamic content).
My proposal is to make this definition non-final.

All definitions:
Could we have a document with the definitions for all specifications from the 
family?

3.
achived - achieved

4.
Again about the definitions:
Could we have a common definition of the user agent, decoupled from the specs?
(e.g. UA in PC is an implementation, here it is a software implementation)

4.2
a read-only item is an item in a storage area cannot be ...
should be
a read-only item is an item in a storage area that cannot be ...

5.
Why aren't the following attributes available on the widget interface?
@viewmodes from widget,
@short from name,
@href from license and license,
icons

5.
It preferences(via the preferences attribute).
Unclear.

5.
A user agent should to impose ...
Should be
A user agent should impose ...

5.
... global object context of the widget's start file.
What about:
... global object context of the document loaded from widget's start file.
???

5.
In
... global object context of the widget's start file.
And
A user agent whose start file implements HTML5's Window interface ...
The start files refer to 2 different locations.

5.4
How to handle multiple instances of the same widget?
As far as I remember it was to be moved to WURIv2, but it seems important in 
the context of preferences.

5.4
Storage interface:
The AE specification should not add interpretation to the WebStorage with 
regard to the exceptions thrown. It would be better to improve the WebStorage 
specification.
Specifically the NO_MODIFICATION_ALLOWER_ERR shall be presented in WebIDL on 
Storage interface based on raises keyword of WebIDL.

5.4.1
onClick - onclick

5.4.2#3
... make the preferences attribute a pointer that storage area.
Should be
... make the preferences attribute a pointer to that storage area.

5.4.2#2.4.1
... apply the  rule for dealing with an invalid Zip archive ...
And
In the event that an implementation encounters an invalid Zip archive ...
In the case the UA is a CC, it must inform the author that the Zip archive is 
an invalid Zip archive. From PC.

Do not play well together.
The problem is with the WUA and not with the widget, so the correct information 
should be provided to the user.

The problem
5.5
... should open the provided iri ...
What does opening of the IRI mean?
Maybe this would work (IRI handler could be defined anyway) :

... should handle the provided iri ...

5.5
... it is otherwise rejected by the user agent (e.g., because of security 
policy or user prompting), or iri is not a valid IRI, then the user agent must 
act as if the method had not been invoked.

The user agent should inform the end-user when a request to handle the IRI via 
the openURL() method has failed.

The above requirements seem contradicting and not prepared for handling the 
security policy.
a) acting as if the method had not been invoked (a MUST) and informing the end 
user (a SHOULD) may not work well together.
b) it should be possible for the UA to reject the call to openURL, and then the 
exception or error shall be thrown, so that the script could catch it and 
inform the user.
I suggest leaving the WebIDL for openURL to DAP.

5.5
Last sentence seems to be lost in action.

[1] http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.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




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.

[AE] Last Call comments (2): discovery localization

[Marcin Hanclik]

The below comments refer to:

Widgets 1.0: The widget Interface

Editor's Draft 14 September 2009



5.1

Configuration Attributes Table does not contain features/params.

We may assume that when the widget gets installed and loaded, the mandatory 
(@required=true) features were present/accessible.

However, the widget does not know whether the optional features 
(@required=false)  are present/accessible.

Therefore, I suggest adding the list of available features to the widget 
object. E.g. as an array of IRI or by means of a query API (or shall 
hasFeature() work? Not sure why it was removed from the previous WD) so that 
the widget could discover the available components/features.



5.1

Localization

Shall it be possible for the widget to programmatically discover the 
localization path it was loaded from (section 9 of PC)?

[ I understand the folder-based and element-based localizations are specified 
in PC and wonder why it is not possible to programmatically discover the 
localization that was applied (it could also help with testing IMHO). ]

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.

[AE] LC deadline: request to prolong LC period

[Marcin Hanclik]

Hi All,

Herewith I would like to ask for extending the LC period for AE LCWD by 1 week.
I have just provided some comments and have a feeling that I could provide 
more, specifically related to ViewModes and WebStorage.

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: [WARP] Last Call comments (1)

[Marcin Hanclik]

Hi Marcos,

Re 99% fulfillment of the needs:
As stated in my original email, one of the targets is that access is not an 
obstacle for DAP.
It is currently undefined how the related access control will be done and we 
would probably want to avoid the situation that access is deprecated once DAP 
is ready with their model.
So we may fulfill 99% of the needs now, but 1% in a few months with the 
access element.
That is why I proposed a more robust and extensible (hopefully future-proof) 
design of the functionality based on feature element.

 What's more, the conditional character of feature brings flexibility to 
 the design of widgets/webapps and may be important from
their usability point of view.

I don't understand the above sentence, can you give me an example of
what you mean?

Here I refer to the absence of the @required attribute on access element and 
its presence on feature element.
By flexibility I mean the fact that access to some web resource could be 
conditional (i.e. not-required).
Let's say my widget wants to retrieve resources from 2 websites / domains.
One website provides the core functionality of the widget, i.e. the resources 
from it are mandatory/required, instantiation of the widget without access to 
those resources makes no sense etc.
The second website provides additional functionality, a kind of nice-to-have 
for my widget. So access to the resources from this website is optional 
(@required=false).

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: Marcos Caceres [mailto:marc...@opera.com]
Sent: Monday, September 07, 2009 3:37 PM
To: Marcin Hanclik
Cc: public-webapps@w3.org
Subject: Re: [WARP] Last Call comments (1)



Marcin Hanclik wrote:
 Hi Marcos,

 is pretty simple, logical, and gets the job done for most use cases.

 The above is not the case e.g. for mailto: or tel:, specifically if you want 
 to be more specific/selective with the additional arguments (a la subdomains).

Access requests for those are not relevant, IMO. Those would be
controlled by the policy of the UA. (e.g., policy may say all 'tel:' and
'mailto:' are allowed and handled by the appropriate scheme handler -
the phone dialer or the mail app.)

I don't see any use case for access uri=mailto:*...@gmail.com; or
access uri=tel:+47*. That's overkill, IMO.

access covers the common (+99%) use case of accessing stuff on the
Web. Like I said, other scheme handlers can handle tel, mailto, etc.
like is currently done by browsers.

 It is also not the case for the distinction between programmatic vs. 
 declarative/URL (not sure how to name it :) ) access.
 Those aspects may be important from the DAP's security model perspective.

Key word here is may: you are adding solutions before you have a
problem. Just focus on solving the issue at hand.

 Most use cases currently entails a few assumptions implicitly, e.g. 
 relation to installation-time or dynamic access to the resource etc.

Let me make the assumptions explicit: Most use cases for Opera = the
Opera gallery of Widgets and what our developer community need and want.
They want access to, for instance, the flickr API, the Google APIs,
Twitter, etc. and the ability to mash up stuff really quickly,
painlessly, and easily. They (and I) want a super easy to use platform
that kicks ass for developing and delivering client-side applications.
My goal is to give that to them:) I'm sure your goals are the same.

In the future, they might want access to features provided by dap.
Hopefully, they won't have to request those through a feature element
(i.e., the APIs will just be there for them to use without requesting
them), but, in the unfortunate case that they do have to request them, I
want to make sure it's as simple as possible.

 What's more, the conditional character of feature brings flexibility to the 
 design of widgets/webapps and may be important from their usability point of 
 view.

I don't understand the above sentence, can you give me an example of
what you mean?


Kind regards,
Marcos



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: Normalization, was: RE: [Widget URI] Internationalization, widget IRI?

[Marcin Hanclik]

Hi Marcos,

Thanks for your comments.
It seems we are aligned.

 UAs will just have to deal with that internally
I assume there could be an easy solution to the normalization:
The normalization / mandating some equivalence-determining algorithm (from 
RFC3987) could go into PC.
Then maybe I18N would not have to be bothered further.

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: Marcos Caceres [mailto:marc...@opera.com]
Sent: Monday, September 07, 2009 4:33 PM
To: Marcin Hanclik
Cc: Robin Berjon; public-webapps WG
Subject: Re: Normalization, was: RE: [Widget URI] Internationalization, widget 
IRI?



Marcin Hanclik wrote:
 Hi Marcos,

 The spec just treats them as opaque strings.
 Yes. This is the reason for my email to I18N.

 Ok, so what you are saying is, given an XML document's encoding, any URI
 should be converted to a default encoding (say, UTF-8)?

 This is one of the proposed solutions.
 In the email to I18N I asked/suggested that moving everything to UTF8 could 
 be studied, but I was not sure whether it is ok for the developers who could 
 have non-UTF8 text editors at hand (assuming config.xml is developed some 
 basic text editor).

That's ok. Best practice for developers is to write XML in UTF-8. If a
developer writes XML in some obscure encoding, then, it is to their
determent. The same would happen on the Web, you can't stop that. And,
if a new super format emerges that is better than UTF-8, developers
should be able to use it (and UAs support it).

 The main motivation for default encoding is to move from octets to characters.

Yep.

 Opaque strings with pct encoding bring unnecessary encoding that should 
 actually vanish if the URI/IRI normalization would be mandated.

This is why we treat them as opaque strings.

 I can make this explicit.
 Perfect.

 widget id=foo:mañana  is a valid URI.
 This is BTW comment: it seems to be IRI, since ñ is non-ASCII.

A crap. I meant valid IRI (if I say URI again, just pretend I meant
IRI :)).

 Right. That is an implementation detail - my implementation might be
 super internally optimized to run UTF-16. But, as you always know what
 the bytes are from the XML file, there should be no problem for comparison:

 XML file(utf-8 or ISO--Y)--  UA (UTF-16)--  zip archive(CP437|UTF-8)
 Agreed.

 To sum up:
 The whole issue about IRI/URI normalization is about treatment of the 
 IRI-valued attributes as a string of characters and not as a string of 
 octets. Such normalization is currently not in PC and my understanding is 
 that the normalizations mentioned in RFC3987 must be explicitly mandated in 
 specs using it to make them effective.

Ok, I was not aware that RFC3987 says we have to normalize IRIs to a
canonical form. Grumble... guess I gotta read that spec again :(

Like I said, the way we designed this was that IRIs were just opaque
strings. The internal representation of that string is irrelevant, but
the following metadata is maintained:

   1. the string is treated as a IRI (hence, could be normalized, if
need be). So a = new IRI(someString);

   2. The encoding of the IRI recorded for transcoding (as needed).

IRIs come in two flavors: encoded and normalized. Mandating one over the
other to developers is a waste of time. UAs will just have to deal with
that internally (I guess that's what RFC3987 is for).

 Character-set conversion is another issue.
 In [1] I wrote:
 So by inclusion of [XML], it seems that other encodings than UTF-8 are 
 implicitly mandated, or?
 I am not sure whether this is the understanding in WebApps.

Yes. This is certainly the understanding in Web Apps. A UA can support
whatever encodings it wants. A UA is only required to support UTF-8 -
every other encoding optional (though you would be pretty silly if you
didn't support a few common encoding formats, but we leave those to the
market).

 And it seems that this is to be pending for discussion in I18N [2].

Ok, now that I'm starting to understand all this a bit better, I might
be able to contribute to [2]. Thanks again for helping me understand the
problem.

Kind regards,
Marcos

[2]
http://lists.w3.org/Archives/Public/public-i18n-core/2009JulSep/0065.html



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: [Widget URI] Internationalization, widget IRI?

[Marcin Hanclik]

Hi Marcos,

As a summary of the URI/IRI-related issues, we have currently the following as 
far as I can tell:
1. URI/IRI normalization in PC [1], it is currently at I18N [2]
2. Widget URI issues related to internationalization [3]

The URI/IRI normalization in PC is mainly for attribute values that are to be 
IRIs. At present these are:
a) @id in widget
b) @href in author
c) @href in license
d) @name in feature

Your use cases seem to be related to the above, since you quote non-ASCII 
character in the @src of content.
They are exactly the same with regard to the above issues 1. and 2.
They differ on the CP437/UTF8 level.

The widgets URI is on the character level and my point was about naming it URI 
(octet-level, whereas IRI operates clearly on character level).

My comments to the details:

PC addresses the transcoding from CP437 to UTF8 [4] ( however, only as SHOULD, 
so maybe it should be also SHALL? This was not raised yet and it is probably 
late now):
 For the sake of comparison and matching, it is recommended that a user agent 
treat all Zip-relative paths as [UTF-8].

The problematic character in your case is 'ñ', U+00F1.
In CP437 it is has the value 0xA4, in ISO-8859-1 it is 0xF1.
In UTF8 this character is encoded as the sequence of the following octets: 0xC3 
0xB1.

The assumption of PC seems to be that everything gets converted to UTF8.
The only issue is that this is an assumption.
My case of IRI and your cases with file name are similar with regard to this 
assumption.

Specifically in case of IRI we have the issue of pct encoding, in your cases we 
have just character-set transcoding.

I hope it is clearer now.

Thanks,
Marcin


[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0644.html
[2] http://lists.w3.org/Archives/Public/public-i18n-core/2009JulSep/0065.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0339.html
[4] http://www.w3.org/TR/widgets/#zip-relative-paths
[5] http://www.w3.org/TR/widgets/#the-content-element

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: Friday, September 04, 2009 11:11 AM
To: Marcin Hanclik
Cc: Robin Berjon; public-webapps WG
Subject: Re: [Widget URI] Internationalization, widget IRI?

On Thu, Sep 3, 2009 at 1:32 PM, Marcin
Hanclikmarcin.hanc...@access-company.com wrote:
 Hi Robin,

 Thanks for your comments.

 I believe the terminology could be clarified once the IRI/URI issue from PC 
 gets solved in I18N, hopefully together with HREF and all related stuff.

 +1 for simplification.


I'm still not understanding the problem in the PC spec.

Let me try to walk through a simple widget. Marcin, pretend I'm 9
years old and explain the problem to me in the most simplest of terms
possible (i.e., don't cite me URI/IRI spec stuff because all that
stuff makes no sense, just talk to me about bytes... I'm one those
smarty 9 year-olds, who knows about bytes, but as a consequence gets
pushed around by bullies...:)).

USE CASE 1
1. I have a widget called foo.wgt. The widget contains 2 files:
mañana.html and config.xml.
2. The file names of both files are encoded in the zip archive as
UTF-8 (explicitly marked as such by the presence of a flag).
3. In the config doc, which is encoded in iso-8859-1, it says:
   content src=mañana.html/
4. The UA reads the value of src attribute and converts it to UTF-8.
5. The UA matches the string that represents the value of src to the
mañana.html file entry.
6. done?


USE CASE 2
1. I have a widget called foo.wgt. The widget contains 2 files:
mañana.html and config.xml.
2. The file names of both files are encoded in the zip archive as
CP-437 (explicitly marked as such).
2.1 The UA maps all the files names in the zip archive to UTF-8 equivalents.
3. In the config doc, which is encoded in iso-8859-1, it says:
   content src=mañana.html/
4. The UA reads the value of the src attribute and converts it to UTF-8.
5. The UA matches the string that represents the value of src to the
mañana.html file entry.
6. done?


--
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: [WARP] Last Call comments (1)

[Marcin Hanclik]

Hi Marcos,

What you did in 192 characters, the access element does in 52.

That is the point of the access element: to make these kind of
annoying declarations easy to write.

I do not think that the conciseness is the main driver of this aspect of the 
config.xml.
What matters seems to be semantics, specifically in the light of the security 
model and selectiveness of the intentions.

The size of the expression could be lowered a bit, e.g. the IRI could be 
changed from;
http://www.w3.org/widgetfeatures/networkaccess/http
to
http://www.w3.org/wf10/na/http
and so on.

From another angle:
We seem to agree to have implicit API versioning (in DAP) that result in 
multiplication of the size of the runtime code (note the performance impact), 
so having a few more characters in config.xml with clearly defined semantics 
seems not to be an issue, I think.

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: Friday, September 04, 2009 5:04 PM
To: Marcin Hanclik
Cc: public-webapps@w3.org
Subject: Re: [WARP] Last Call comments (1)

Hi Marcin,
I tried to respond to this email, but in all honesty, I can't follow
your line of argumentation. Maybe you can list your main points as a
list (sorry, I'm a bit simple)...

From what I got, I agree that WARP is over reaching: It does not
address the requirements it lists from the Widgets 1.0: Requirements
document. Otherwise, I'll just leave it to Robin to respond.

I've made some notes on the proposed changes.

On Thu, Aug 27, 2009 at 8:06 PM, Marcin
Hanclikmarcin.hanc...@access-company.com wrote:

 PROPOSED CHANGES

 Given the semantic similarities (or equivalence) between:

 access uri=http://example.org; subdomains=true/

 and e.g.:

 feature name=http://www.w3.org/widgetfeatures/networkaccess/http; 
 required=false
param name=uri value=http://example.org/
param name=subdomains value=true/ /feature


What you did in 192 characters, the access element does in 52.

That is the point of the access element: to make these kind of
annoying declarations easy to write.

 I propose the following:

 1. Change the name of the specification to Widgets 1.0: Network Access 
 Feature and focus on per-URI-scheme definition of the syntax dependencies 
 and functionality.

 Examples:
 a)
 The following feature could replace the generic network access (proposed in 
 the LCWD as * for @uri attribute):

 feature name=http://www.w3.org/widgetfeatures/networkaccess; 
 required=true /

 b)
 The following features could define the http and https access

 feature name=http://www.w3.org/widgetfeatures/networkaccess/http; 
 required=false
param name=uri value=http://example.org/
param name=subdomains value=true/
param name=ports value=80, 8080/ /feature

 feature name=http://www.w3.org/widgetfeatures/networkaccess/https; 
 required=true
param name=uri value=https://example.org/
param name=subdomains value=false/
param name=interface value=XMLHttpRequest/
!-- port defaults to 443 --
 /feature

 c)
 The following feature could define access to SMS feature:

 feature name=http://www.w3.org/widgetfeatures/networkaccess/sms; 
 required=true
param name=uri value=sms:+16177166200/ /feature

 feature name=http://www.w3.org/widgetfeatures/networkaccess/sms; 
 required=true
param name=countrycallingcodes value=1,48,49,34/ /feature

 2. Rewrite parts of the specification - specifically section 3, while keeping 
 its majority as is - to adhere to the syntax of the feature and param 
 elements as outlined above.

 3. Refrain from specifying the default policy; remove the word security from 
 the specification (since this is to be handled in DAP).

 4. Focus in the specification text only on declarative aspects of the 
 intention of the author of the widget, leaving e.g. prompting aspects for 
 DAP. I.e. assuming that the network access is conditional, what are the 
 implications for the widget's code and author in case the network access is 
 not present or its presence is dynamic? (e.g. provide a definition of the 
 event mechanism).

 5. In order to be able to define the IRI for network access feature, another 
 document should probably be prepared that would also define the namespace for 
 the further feature definitions (e.g. http://www.w3.org/widgetfeatures/).

 6. Focus in the specification only on http and https. subdomains attribute 
 / value of the parameter is valid mainly for this protocol family (also 
 including e.g. rtsp, ftp etc.). Other schemes, like sms, tel, mms (there is 
 no RFC for some) have their own specificities, e.g. country calling/dialing 
 codes, shortcodes.

 Thanks.

 Kind regards,
 Marcin

 [1] http://www.w3.org/TR/2009/WD-widgets-access-20090804/
 [2] http://lists.w3.org/Archives/Public

RE: [WARP] Last Call comments (1)

[Marcin Hanclik]

Hi Marcos,

is pretty simple, logical, and gets the job done for most use cases.

The above is not the case e.g. for mailto: or tel:, specifically if you want to 
be more specific/selective with the additional arguments (a la subdomains).
It is also not the case for the distinction between programmatic vs. 
declarative/URL (not sure how to name it :) ) access.
Those aspects may be important from the DAP's security model perspective.

Most use cases currently entails a few assumptions implicitly, e.g. relation 
to installation-time or dynamic access to the resource etc.

What's more, the conditional character of feature brings flexibility to the 
design of widgets/webapps and may be important from their usability point of 
view.

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.

Normalization, was: RE: [Widget URI] Internationalization, widget IRI?

[Marcin Hanclik]

Hi Marcos,

The spec just treats them as opaque strings.
Yes. This is the reason for my email to I18N.

Ok, so what you are saying is, given an XML document's encoding, any URI
should be converted to a default encoding (say, UTF-8)?

This is one of the proposed solutions.
In the email to I18N I asked/suggested that moving everything to UTF8 could be 
studied, but I was not sure whether it is ok for the developers who could have 
non-UTF8 text editors at hand (assuming config.xml is developed some basic text 
editor).
The main motivation for default encoding is to move from octets to characters.
Opaque strings with pct encoding bring unnecessary encoding that should 
actually vanish if the URI/IRI normalization would be mandated.

I can make this explicit.
Perfect.

widget id=foo:mañana is a valid URI.
This is BTW comment: it seems to be IRI, since ñ is non-ASCII.

Right. That is an implementation detail - my implementation might be
super internally optimized to run UTF-16. But, as you always know what
the bytes are from the XML file, there should be no problem for comparison:

XML file(utf-8 or ISO--Y) -- UA (UTF-16) -- zip archive(CP437|UTF-8)
Agreed.

To sum up:
The whole issue about IRI/URI normalization is about treatment of the 
IRI-valued attributes as a string of characters and not as a string of octets. 
Such normalization is currently not in PC and my understanding is that the 
normalizations mentioned in RFC3987 must be explicitly mandated in specs using 
it to make them effective.
Character-set conversion is another issue.
In [1] I wrote:
So by inclusion of [XML], it seems that other encodings than UTF-8 are 
implicitly mandated, or?
I am not sure whether this is the understanding in WebApps.
And it seems that this is to be pending for discussion in I18N [2].

Thanks,
Marcin

[1] http://lists.w3.org/Archives/Public/public-i18n-core/2009JulSep/0042.html
[2] http://lists.w3.org/Archives/Public/public-i18n-core/2009JulSep/0065.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: Marcos Caceres [mailto:marc...@opera.com]
Sent: Monday, September 07, 2009 3:01 PM
To: Marcin Hanclik
Cc: Robin Berjon; public-webapps WG
Subject: Re: [Widget URI] Internationalization, widget IRI?



Marcin Hanclik wrote:
 Hi Marcos,

 As a summary of the URI/IRI-related issues, we have currently the following 
 as far as I can tell:
 1. URI/IRI normalization in PC [1], it is currently at I18N [2]
 2. Widget URI issues related to internationalization [3]

 The URI/IRI normalization in PC is mainly for attribute values that are to 
 be IRIs. At present these are:
 a) @id inwidget
 b) @href inauthor
 c) @href inlicense
 d) @name infeature

There is no normalization done on any of those values (by designed, and
modeled explicitly after the behavior of XML namespaces, which are also
not normalized). The spec just treats them as opaque strings.

Remember that the PC UA does not do anything meaningful with any of the
metadata it collects (leaves that to other UAs). It merely validates
that data (The UA just checks if the value of the attribute is a valid
IRI, that's it! And it certainly does not need to do any normalization
to check for validity).

For example, from the spec:

wid...@id:
If the id attribute is used, then let id be the result of applying the
rule for getting a single attribute value to the id attribute. If id is
a valid IRI, then let widget id be the value of the id...

Where A valid IRI is one that matches the IRI token of the [RFC3987]
specification.

(i.e., read the @id value, if it is a valid IRI, save it.)

So:

widget id=foo:bar 123 is not valid.

widget id=fooo:bar%20123 is valid, and the value is fooo:bar%20123.

widget id=foo:mañana is a valid URI.

Also, lice...@href:
If the href attribute is used, then let potential license href be the
result of applying the rule for getting a single attribute value to the
href attribute.
If potential license href is not a valid IRI or a valid path, then the
href attribute is in error and the user agent must ignore the attribute.
If potential license href is a valid IRI, then let widget license href
be the value of potential license href.

(i.e., read the @href value, if it is a valid IRI, save it.)

And so on... it's the same for the other attributes. We don't normalize
anything nor should they be normalized. They are just treated as opaque
strings.

The only place where it changes is if license href is a valid path, in
which case a UA checks for the file internally in the package. I think
this is where you see issues arising...

 Your use cases seem to be related to the above, since you quote non-ASCII 
 character in the @src ofcontent.

Yes, zip relative paths, which are either CP437 or UTF-8 internally in
the widget package.

What is assumed is a layer of abstraction between the package and the
config document

RE: [Widget URI] Internationalization, widget IRI?

[Marcin Hanclik]

Hi Robin,

Thanks for your comments.

I believe the terminology could be clarified once the IRI/URI issue from PC 
gets solved in I18N, hopefully together with HREF and all related stuff.

+1 for simplification.

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: Robin Berjon [mailto:ro...@berjon.com]
Sent: Wednesday, September 02, 2009 11:17 PM
To: Marcin Hanclik
Cc: public-webapps WG
Subject: Re: [Widget URI] Internationalization, widget IRI?

Hi Marcin,

On Jul 24, 2009, at 18:36 , Marcin Hanclik wrote:
 Why is the Widgets 1.0: URI Scheme about URI and not IRI?

Because it was written quickly :) And also because I'm sick and tired
of the level of terminology needed to address (no pun intended) what
should be a simple field - I'd like to just say URI and since this
isn't a legacy context obviously it means IRI with the added advantage
that it doesn't hurt the brains of the majority of readers... Anyway,
no point in ranting over spilt beer I guess.

Based on the follow-up discussion what I've done is that I've used IRI
throughout the specification except when discussing URI schemes. I've
also updated the reference to be to RFC 3987 and the syntax to
reference iauthority, iquery, and ifragment - which is indeed more
correct.

Thanks!

--
Robin Berjon - http://berjon.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: to publish a new WD of the DOM3 Events spec; deadline Sep 4

[Marcin Hanclik]

Hi,

ACCESS supports this publication.

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: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Arthur Barstow
Sent: Friday, August 28, 2009 5:29 PM
To: public-webapps; www-...@w3.org
Subject: CfC: to publish a new WD of the DOM3 Events spec; deadline Sep 4

This is a Call for Consensus (CfC) to publish a new WD of the DOM 3
Events spec:

  http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html

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 Sep 4.

Although rev 1.50 is currently the latest version [1] and it says the
date is July 20, the CVS history indicates Doug modified the document
today. Doug - please update the date.

DOM folks - please see [2] for a brief overview of WebApps' CfC process.

-Regards, Art Barstow

[1] http://dev.w3.org/cvsweb/2006/webapi/DOM-Level-3-Events/html/DOM3-
Events.html
[2] http://www.w3.org/2008/webapps/wiki/
WorkMode#Consensus_and_Call_for_Consensus


Begin forwarded message:

 From: ext Doug Schepers schep...@w3.org
 Date: August 28, 2009 11:08:01 AM EDT
 To: member-weba...@w3.org member-weba...@w3.org
 Subject: New WD of DOM3 Events?
 Archived-At: http://www.w3.org/mid/4a97f2d1.6010...@w3.org

 Hi, WebApps WG-

 We have been working on the DOM3 Events spec for a while, and I have
 made quite a few edits recently.  While it's certainly not complete, I
 believe it is at a stage where it would benefit from greater public
 review.  I would like to ask the chairs to put the question to the
 WG on
 publishing a new Working Draft of the spec:

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-
 Events.html

 Regards-
 -Doug Schepers
 W3C Team Contact, SVG and WebApps WGs






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.

[WARP] Last Call comments (1)

[Marcin Hanclik]

 section 3, while keeping 
its majority as is - to adhere to the syntax of the feature and param 
elements as outlined above.

3. Refrain from specifying the default policy; remove the word security from 
the specification (since this is to be handled in DAP).

4. Focus in the specification text only on declarative aspects of the intention 
of the author of the widget, leaving e.g. prompting aspects for DAP. I.e. 
assuming that the network access is conditional, what are the implications for 
the widget's code and author in case the network access is not present or its 
presence is dynamic? (e.g. provide a definition of the event mechanism).

5. In order to be able to define the IRI for network access feature, another 
document should probably be prepared that would also define the namespace for 
the further feature definitions (e.g. http://www.w3.org/widgetfeatures/).

6. Focus in the specification only on http and https. subdomains attribute / 
value of the parameter is valid mainly for this protocol family (also including 
e.g. rtsp, ftp etc.). Other schemes, like sms, tel, mms (there is no RFC for 
some) have their own specificities, e.g. country calling/dialing codes, 
shortcodes.

Thanks.

Kind regards,
Marcin

[1] http://www.w3.org/TR/2009/WD-widgets-access-20090804/
[2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0290.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0294.html
[4] http://www.w3.org/TR/widgets
[5] http://www.w3.org/TR/widgets/#the-feature-element
[6] http://www.w3.org/TR/widgets/#the-widget-family-of-specifications
[7] http://www.w3.org/TR/2009/WD-widgets-access-20090804/#introduction
[8] http://www.w3.org/TR/2009/WD-widgets-access-20090804/#definitions
[9] 
http://www.w3.org/TR/2009/WD-widgets-access-20090804/#design-goals-and-requirements
[10] http://www.w3.org/TR/widgets-reqs/#default-security-policy
[11] http://www.w3.org/TR/widgets-reqs/#security-declarations
[12] http://www.w3.org/2009/06/09-wam-minutes.html
[13] http://www.w3.org/2009/05/DeviceAPICharter
[14] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022264.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



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: Orientation event in Firefox

[Marcin Hanclik]

Hi Doug,

What do you think about the proposal in [1]?
Some discussion is needed on WebApps for this topic to move forward.

Thanks,
Marcin

[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0764.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-device-apis-requ...@w3.org 
[mailto:public-device-apis-requ...@w3.org] On Behalf Of Doug Turner
Sent: Monday, August 24, 2009 5:40 AM
To: wha...@whatwg.org; public-device-a...@w3.org
Subject: Orientation event in Firefox

I posted some thoughts and a strawman for orientation in Firefox:

http://dougt.org/wordpress/2009/08/orientation/

Regards,
Doug Turner







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: [ViewModes] Proposal: split the specification, add new events

[Marcin Hanclik]

Hi Robin,

Good point!

In the email and attachment starting this thread I included the comment that 
AspectRatioChangeEvent could be realized with ResolutionChangeEvent. With your 
comment the question is whether we need ResolutionChangeEvent if we already 
have onresize.
We have change from pull model (onresize is invoked, but the resolution has to 
be fetched separately) to push model (new dimensions are in the event). Do we 
need ResolutionChangeEvent then?
Any opinion?

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: Robin Berjon [mailto:ro...@berjon.com]
Sent: Monday, August 24, 2009 12:40 PM
To: Marcin Hanclik
Cc: public-webapps@w3.org
Subject: Re: [ViewModes] Proposal: split the specification, add new events

Hi,

On Aug 20, 2009, at 13:55 , Marcin Hanclik wrote:
 My proposal is:

 1. Let [2] specify only view-mode media feature.

I think that's a good idea.

 Ad b)

 As listed in the attached document the orientation and aspect-ratio
 media features do not depend on the device and may change
 dynamically. So I would like to propose the following:

 1. Add OrientationChangeEvent
 2. Add AspectRatioChangeEvent

I think that these are useful events, but I'd like to make sure we're
not duplicating existing stuff. Notably, how is AspectRatioChangeEvent
different from onresize?

--
Robin Berjon - http://berjon.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.

DOM3EV: [ViewModes] typeArg on initXXXEvent

[Marcin Hanclik]

Hi,

In the ViewModes specification [1] we define a few new events.
All the initXXXEvent methods have currently typeArg parameter.
I think they are superfluous, but they seem to mimic what is defined in 
DOM2Events and DOM3Events.
The problem is that in DOM2Events and DOM3Event the initXXXEvent methods are 
for groups of lower level events, like UIEvent (DOMActivate, DOMFocusIn etc.), 
KeyboardEvent (keydown, keyup), MouseEvent (click, dblclick, mousedown etc.) 
etc.

However, e.g.  DOM3Events' MouseWheelEvent [2] has only 1 possible value for 
typeArg, namely mousewheel [3] (if I read current version of the specification 
correctly).

So the question arises whether typeArg is required for MouseWheelEvent?
What happens the typeArg passed is not mousewheel?
Could we have latest Web IDL for DOM3Events with related raises?

Once we have the answer to the above questions, I assume the ViewModes 
specification will follow.
As for me for the events specified in the current pre-FPWD document do not need 
typeArg, since it just unnecessarily doubles the information in the method 
invocation.

What do you think?

Thanks.

Kind regards,
Marcin


[1] http://dev.w3.org/2006/waf/widgets-vm/Overview.src.html
[2] http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-MouseWheelEvent
[3] http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-mousewheel

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.