RE: [WARP] Comments to WARP spec

2009-11-19 Thread 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?)

2009-11-19 Thread 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?)

2009-11-19 Thread 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?)

2009-11-19 Thread 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?)

2009-11-19 Thread Dominique Hazael-Massieux
Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit :
 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.

That’s true to a certain extent, but a reason for that might well be
that the Web platform hasn’t left enough room for third parties in that
realm.

One could very well imagine that by allowing a certain level of
abstraction in security concerns, we would allow businesses to offer
guarantees against data-loss or data-thief if the user install a
third-party extension that would check Web sites based on a number of
their security aspects.

I’m pretty sure I don’t like all the implications of such a system, and
I’m generally rather in the skeptic side when it comes to the use of a
full-blown policy framework for the Web; but I don’t think it’s fair to
conclude that it is not useful simply based on the fact that it hasn’t
been put to use yet, esp. if it’s currently difficult or impossible to
put it to use.

Dom





Re: CfC - publish Selectors API as CR

2009-11-19 Thread Robin Berjon
On Nov 19, 2009, at 00:49 , Charles McCathieNevile wrote:
 this is a Call for consensus to request publishing the Selectors API draft at 
 http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html;%20charset=iso-8859-1
  as a Candidate Recommendation (assuming Lachy fixes the apparent encoding 
 errors, the incorrect URIs and so on as editorial corrections).

That's a plus-one from us.

As for the encoding errors, I recommend going to the document directly rather 
than through the baroque URLs that cvsweb makes up:

  http://dev.w3.org/2006/webapi/selectors-api/

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




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

2009-11-19 Thread Robert O'Callahan
On Thu, Nov 19, 2009 at 10:52 PM, Dominique Hazael-Massieux d...@w3.orgwrote:

 Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit :
  There are usually no third parties to delegate to.

 That’s true to a certain extent, but a reason for that might well be
 that the Web platform hasn’t left enough room for third parties in that
 realm.

One could very well imagine that by allowing a certain level of
 abstraction in security concerns, we would allow businesses to offer
 guarantees against data-loss or data-thief if the user install a
 third-party extension that would check Web sites based on a number of
 their security aspects.


Businesses could offer that today, as a Firefox extension for example. There
are actually a lot of security toolbar extensions, but they tend to offer
advice rather than enforcement and they don't offer any guarantees. (
http://groups.csail.mit.edu/uid/projects/phishing/chi-security-toolbar.pdfhas
an interesting analysis (albeit slightly dated).)

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]


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

2009-11-19 Thread Jonas Sicking
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 implementing it.

[1] http://blog.dirolf.com/2007/06/enabling-cross-domain-ajax-in-firefox.html

/ Jonas



Re: [WARP] Comments to WARP spec

2009-11-19 Thread Robin Berjon
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/






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

2009-11-19 Thread 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?)

2009-11-19 Thread 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

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

2009-11-19 Thread David Rogers
Hi,

I'm going to answer these one by one, so apologies in advance for a slew
of emails coming from me. My comments will always be marked [DAVID]:

-Original Message-
From: Maciej Stachowiak [mailto:m...@apple.com] 
Sent: 19 November 2009 01:20
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.

[DAVID] This is the whole point - the user could choose who their policy
provider could be. The list is endless but it could be: a child
protection organisation, EFF, Which?, an anti-virus vendor/firewall
company, OS vendor, browser vendor, mobile operator - the point being
that the provider is someone the user trusts. On the subject of
whitelisting etc. have a look at http://stopbadware.org/ - potentially
these are things that could be used by policy providers (I'm sure there
are lots of other reputable sources too).

Dieter Gollman said: security-unaware users have specific security
requirements but usually no security expertise - this is why is wholly
irresponsible to defer the decision to the user in the majority of
cases. Generally, the user would much rather have someone more informed
take that decision for them. I don't think we can eliminate prompts but
we could reduce them to a level that they might actually be read and
treated as important. Right now the opposite is true.

Thanks,


David.



RE: [WARP] Comments to WARP spec

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

2009-11-19 Thread David Rogers
My comments:

-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc] 
Sent: 18 November 2009 20:15
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.

[DAVID] So potentially that 'judgement' can be made by a third party who
has more expertise than the user, extended to allow for context etc. -
there would be lots of metadata to help with that from the policy
provider point-of-view.

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.

[DAVID] Obvious answer to this - user clicks yes. Not acceptable. Given
that child protection is a use case for geolocation privacy, do you
think it is responsible to give a child that question?


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.

[DAVID] There are lot of not-so tech-savvie people using the web, so
everything is on the table - you are assuming intelligence/knowledge
from the off.

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.

[DAVID] Agreed.

/ Jonas



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

2009-11-19 Thread David Rogers
My comments:

-Original Message-
From: public-device-apis-requ...@w3.org 
[mailto:public-device-apis-requ...@w3.org] On Behalf Of Adam Barth
Sent: 19 November 2009 07:42
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.

[DAVID] I would hope that we can come up with some clever API design in terms 
of safe logic. However, this does not solve the whole problem, at some point 
you need to make a decision / judgement call. What the policy advocates are 
proposing is to advance the whole discipline here - let's improve this by 
adding strength in depth and allow the user to defer their decision to someone 
who they trust, who is willing to take the decision for them.

Adam




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

2009-11-19 Thread David Rogers
My comments:

-Original Message-
From: Dominique Hazael-Massieux [mailto:d...@w3.org] 
Sent: 19 November 2009 09:52
To: rob...@ocallahan.org
Cc: Marcin Hanclik; Jonas Sicking; David Rogers; Maciej Stachowiak; Robin 
Berjon; public-device-a...@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)

Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit :
 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.

That’s true to a certain extent, but a reason for that might well be
that the Web platform hasn’t left enough room for third parties in that
realm.

One could very well imagine that by allowing a certain level of
abstraction in security concerns, we would allow businesses to offer
guarantees against data-loss or data-thief if the user install a
third-party extension that would check Web sites based on a number of
their security aspects.

I’m pretty sure I don’t like all the implications of such a system, and
I’m generally rather in the skeptic side when it comes to the use of a
full-blown policy framework for the Web; but I don’t think it’s fair to
conclude that it is not useful simply based on the fact that it hasn’t
been put to use yet, esp. if it’s currently difficult or impossible to
put it to use.

[DAVID] I agree whole-heartedly with Dom's comments here, we need to open our 
minds to a better future here - the history of the web in security-terms is 
very nasty. Why not make it better? As I said in a previous email, we would 
like to give the user the choice about who they trust to make decisions for 
them. The vast majority of users on the web have no clue about security or any 
of the technical terms (I will hopefully add another usability study as a 
submission in the coming months which OMTP carried out). Why sandbox yourself 
to the browser? The very rationale of opening up physical 'things' to the web 
means you have to do something.


Dom



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

2009-11-19 Thread David Rogers
My comments:

 

From: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of Robert 
O'Callahan
Sent: 19 November 2009 10:10
To: Dominique Hazael-Massieux
Cc: Marcin Hanclik; Jonas Sicking; David Rogers; Maciej Stachowiak; 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:52 PM, Dominique Hazael-Massieux d...@w3.org wrote:

Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit :

 There are usually no third parties to delegate to.

That’s true to a certain extent, but a reason for that might well be
that the Web platform hasn’t left enough room for third parties in that
realm.

One could very well imagine that by allowing a certain level of
abstraction in security concerns, we would allow businesses to offer
guarantees against data-loss or data-thief if the user install a
third-party extension that would check Web sites based on a number of
their security aspects.


Businesses could offer that today, as a Firefox extension for example. There 
are actually a lot of security toolbar extensions, but they tend to offer 
advice rather than enforcement and they don't offer any guarantees. 
(http://groups.csail.mit.edu/uid/projects/phishing/chi-security-toolbar.pdf has 
an interesting analysis (albeit slightly dated).)


 

[DAVID] This is in effect an insurance policy, I’m sure there will be 
organisations willing to step-up.

 


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]



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

2009-11-19 Thread Robin Berjon
On Nov 19, 2009, at 11:35 , Marcin Hanclik wrote:
 To be clear, IMHO it's absolutely too late for FileReader
 FileReader is still ED, therefore we may have time, I think.

Actually, it's published (as a WD) and has a rather long background history of 
previous development in the File Upload spec. I think I'm not the only one who 
would like this particular baby to move forward rather fast.

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






Re: [WARP] Comments to WARP spec

2009-11-19 Thread Robin Berjon
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/






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

2009-11-19 Thread Robert O'Callahan
On Thu, Nov 19, 2009 at 11:54 PM, David Rogers david.rog...@omtp.orgwrote:

 *From:* rocalla...@gmail.com [mailto:rocalla...@gmail.com] *On Behalf Of 
 *Robert
 O'Callahan



 On Thu, Nov 19, 2009 at 10:52 PM, Dominique Hazael-Massieux d...@w3.org
 wrote:

 Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit :

  There are usually no third parties to delegate to.

 That’s true to a certain extent, but a reason for that might well be
 that the Web platform hasn’t left enough room for third parties in that
 realm.

  One could very well imagine that by allowing a certain level of
 abstraction in security concerns, we would allow businesses to offer
 guarantees against data-loss or data-thief if the user install a
 third-party extension that would check Web sites based on a number of
 their security aspects.


 Businesses could offer that today, as a Firefox extension for example.
 There are actually a lot of security toolbar extensions, but they tend to
 offer advice rather than enforcement and they don't offer any guarantees. (
 http://groups.csail.mit.edu/uid/projects/phishing/chi-security-toolbar.pdfhas 
 an interesting analysis (albeit slightly dated).)



 [DAVID] This is in effect an insurance policy, I’m sure there will be
 organisations willing to step-up.


But they haven't.

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]


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

2009-11-19 Thread David Rogers
My comments:

-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc] 
Sent: 19 November 2009 10:11
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.

[DAVID] ...apart from your example below?

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.

[DAVID] Completely agreed - and the reason why? They don't understand
(or care). Allow someone else to provide that for the user.

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.

[DAVID] See above

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.

[DAVID] I would expect that you would do this as a matter of course
anyway as part of the security lifecycle. However a side-benefit from
your argument would be that policy would therefore help reduce your
maintenance?

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.

[DAVID] Strange argument this one, so you're complaining about
protecting your users. However, I see where you are coming from, perhaps
policy could help ;-)

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

[DAVID] So the problem couldn't be solved without significant effort so
it was avoided? This a risk-avoidance strategy, rather than
risk-management - it works sometimes but you can't do it for everything.
That would be like having agoraphobia to avoid being run over by a bus. 

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 

Re: [WARP] Call for comments on pre-LC#2 of WARP spec; deadline 18 November

2009-11-19 Thread Marcos Caceres
Hi Suresh,
Thanks for the feedback; some comments and questions below...

On Wed, Nov 18, 2009 at 11:11 PM, Suresh Chitturi schitt...@rim.com wrote:
 Hello Art, all,

 Please find below a comment that we would like to submit to towards the
 following WARP Editor's draft.
  http://dev.w3.org/2006/waf/widgets-access/

 If you recall, I did raise the same comment at the joint F2F meeting
 between Widgets and DAP WG during TP week, and it was recommended that I
 submit it formally before the deadline.

 ISSUE: The access element does not specify the ability to have nested
 feature elements.

This is not really an issue. An issue would be something like The
access element does not handle scenarios x, y, and z; therefore,
access is broken.

 RATIONALE: The ability of having nested feature elements under the
 access element, allows the widget authors to control access to a
 specific set of (platform) features on a per resource/domain basis,
 improving the overall access-control and Widgets security model.

Can you describe the use cases here? I know for playing around with
the blackberry emulator that you guys (RIM) already implement this.
Can you give us some insight into the actual use case and rationale?
What kinds of features are being tightly controlled by access?

 PROPOSED RESOLUTION: Specify the use of zero or more feature elements
 as a child of access element. This will require that the current
 specification of feature element in Widgets 1.0 is reworded to say
 that it could be present either as a child of widget element or
 access element.
 However, in the spirit of having no impact to the
 Widgets PC 1.0 specification, an alternate approach would be to add a
 new element called accessFeature (or similar) that uses the same
 syntax and semantics of the feature element. An access element
 thereby, may contain a zero or more accessFeature elements under it to
 indicate the features that the subject resource/origin/domain in the
 access element is entitled or has access to during the Widget
 execution.

 This, we believe will not only offer a fine-grain access control to
 specific features on a per-domain basis but can also be benefit
 implementations to load only those feature modules into the JavaScript
 context that are declared by the widget authors on a per-domain basis.

As WARP defines it's own processing model, so any additions can just
be defined there.

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



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

2009-11-19 Thread David Rogers
 

 

From: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of Robert 
O'Callahan
Sent: 19 November 2009 10:58
To: David Rogers
Cc: Dominique Hazael-Massieux; Marcin Hanclik; Jonas Sicking; Maciej 
Stachowiak; 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 11:54 PM, David Rogers david.rog...@omtp.org wrote:

From: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of 
Robert O'Callahan

 

On Thu, Nov 19, 2009 at 10:52 PM, Dominique Hazael-Massieux 
d...@w3.org wrote:

Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a 
écrit :

 There are usually no third parties to delegate to.

That’s true to a certain extent, but a reason for that might 
well be
that the Web platform hasn’t left enough room for third parties 
in that
realm.

One could very well imagine that by allowing a certain level of
abstraction in security concerns, we would allow businesses to 
offer
guarantees against data-loss or data-thief if the user install a
third-party extension that would check Web sites based on a 
number of
their security aspects.


Businesses could offer that today, as a Firefox extension for example. 
There are actually a lot of security toolbar extensions, but they tend to 
offer advice rather than enforcement and they don't offer any guarantees. 
(http://groups.csail.mit.edu/uid/projects/phishing/chi-security-toolbar.pdf has 
an interesting analysis (albeit slightly dated).)


 

[DAVID] This is in effect an insurance policy, I’m sure there will be 
organisations willing to step-up.

 

But they haven't.



[DAVID] But they will ;-) – we have to actually create a framework for that to 
happen first! As someone mentioned before, in the mobile world this already 
happens.

 


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]



[widgets] multiple co-authors

2009-11-19 Thread Scott Wilson
In PC the author element is defined as: An author element represents  
people or an organization attributed with the creation of the widget.  
with zero or one occurrence [1]


I was wondering how the element is used to represent more than one  
person? The example used shows two names, but there can only be one  
email address, and the href and email attributes are only defined in  
terms of the singular (the author).


I'm not saying this is necessarily incorrect, but perhaps could do  
with some explanation.


S

[1] http://dev.w3.org/2006/waf/widgets/#the-author-element

smime.p7s
Description: S/MIME cryptographic signature


Trying to summarise (was Re: DAP and security)

2009-11-19 Thread Robin Berjon
Whoa.

I believe that the original renaming of the thread intended to clarify the 
DAP's mission and stance on security, but we've devolved again into more 
muddied up discussion, so I'd like to take a second stab at clarifying the 
landscape.

One, DAP *will* handle security. I think everyone's on the same page on that 
one now.

Second, DAP APIs are fully intended to be able to run in a browser context. I 
believe that there may have been unfortunate misunderstandings, but the fact of 
the matter is that APIs not supported by default in browsers will be considered 
a failure. I think that some of the confusion about the fact that these would 
necessarily have to follow a security model that works inside a browser stems 
from the fact that people (including myself) have repeatedly stated that they 
wanted authors to have the same APIs irrespective of whether they were running 
in a browser or in a web runtime used in a different context. This does *not* 
mean that the security model will be the same in both context, and indeed since 
the entry points to said APIs are likely to be different in each context some 
part of the APIs may turn out to be different. The point was that those 
differences should be minor, and clear to authors.

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 :)


Speaking of innovation and trust in browsers, it seems that the JetPack elves 
are working on some form of social web of trust for browser extensions — is 
there a chance that they could chat about it with DAP?

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






Re: [WARP] Call for comments on pre-LC#2 of WARP spec; deadline 18 November

2009-11-19 Thread Robin Berjon
On Nov 19, 2009, at 12:03 , Marcos Caceres wrote:
 RATIONALE: The ability of having nested feature elements under the
 access element, allows the widget authors to control access to a
 specific set of (platform) features on a per resource/domain basis,
 improving the overall access-control and Widgets security model.
 
 Can you describe the use cases here? I know for playing around with
 the blackberry emulator that you guys (RIM) already implement this.
 Can you give us some insight into the actual use case and rationale?
 What kinds of features are being tightly controlled by access?

That would be my question as well. To provide more detail, the idea is that 
remote resources accessed by widgets (in this case we're talking about iframe 
and object only I think) follow the normal web security model. I have qualms 
about having the widget model reach onto the web without very good reason for 
it.

It also makes WARP more complex — I would like to once again strongly reinforce 
the idea that WARP is intended to be extremely simple, and a stop-gap 
specification until DAP produces something appropriately powerful. The Feature 
Vault is guarded by an oversized Pistol Shrimp [0] with a bad temper. She will 
require a very strong use case for this sort of additional feature.


[0] http://www.youtube.com/watch?v=eKPrGxB1Kzc

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






RE: [WARP] Comments to WARP spec

2009-11-19 Thread 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] multiple co-authors

2009-11-19 Thread Marcos Caceres
On Thu, Nov 19, 2009 at 11:10 AM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
 In PC the author element is defined as: An author element represents
 people or an organization attributed with the creation of the widget. with
 zero or one occurrence [1]

 I was wondering how the element is used to represent more than one person?
 The example used shows two names, but there can only be one email address,
 and the href and email attributes are only defined in terms of the singular
 (the author).

I see what you mean, but I guess something like:

widget ...
  author email=project_n...@some.org
href=http://some.org/project_name/developers;Simon
and Garfunkel/author
/widget


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



Re: [public-webapps] Comment on Widget URI (7)

2009-11-19 Thread Robin Berjon
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/






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

2009-11-19 Thread Jeremy Orlow
On Thu, Nov 19, 2009 at 11:24 AM, Robin Berjon ro...@berjon.com wrote:

 Whoa.

 I believe that the original renaming of the thread intended to clarify the
 DAP's mission and stance on security, but we've devolved again into more
 muddied up discussion, so I'd like to take a second stab at clarifying the
 landscape.

 One, DAP *will* handle security. I think everyone's on the same page on
 that one now.

 Second, DAP APIs are fully intended to be able to run in a browser context.
 I believe that there may have been unfortunate misunderstandings, but the
 fact of the matter is that APIs not supported by default in browsers will be
 considered a failure.


Is this practical without the major browsers being part of the DAP WG?
 (Last time I checked, there were some absences.)


 I think that some of the confusion about the fact that these would
 necessarily have to follow a security model that works inside a browser
 stems from the fact that people (including myself) have repeatedly stated
 that they wanted authors to have the same APIs irrespective of whether they
 were running in a browser or in a web runtime used in a different context.
 This does *not* mean that the security model will be the same in both
 context,


I don't understand.  If security is baked into APIs from the start (as is a
requirement for browsers) and the same API should be used in the different
context, then what need is there for a policy model?  The policy model
seems to only be applicable when APIs are inherently insecure and trust is
required...which is the type of API a browser will not implement.


 and indeed since the entry points to said APIs are likely to be different
 in each context some part of the APIs may turn out to be different. The
 point was that those differences should be minor, and clear to authors.

 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 :)


 Speaking of innovation and trust in browsers, it seems that the JetPack
 elves are working on some form of social web of trust for browser extensions
 — is there a chance that they could chat about it with DAP?

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







[widgets] The people say NO to 1.0, was Re: [public-webapps] Comment on Widget URI (7)

2009-11-19 Thread Marcos Caceres
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



Re: [public-webapps] Comment on Widget URI (6)

2009-11-19 Thread Robin Berjon
Dear Larry,

thank you for your comments.

On Oct 10, 2009, at 19:44 , Larry Masinter wrote:
 6) ** EDITORIAL RE FRAGMENT **
 
 Note that assigning semantics or interpretation to the query or fragment 
 components is outside the scope of this specification. The ways in which they 
 are used depends on the content types that they are applied to, or what 
 executable script decides to do with them.
 
 The wording might be taken to mean that a URI scheme registration normally 
 *does* assign semantics or interpretation to the fragment components.
 
 Suggestion: drop this note.

Agreed, the note has been removed.

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






Re: [public-webapps] Comment on Widget URI (5)

2009-11-19 Thread Robin Berjon
Dear Larry,

thank you for your comments.

On Oct 10, 2009, at 19:44 , Larry Masinter wrote:
 5) ** EDITORIAL USE OF URI FOR IRI **
 
 Throughout this specification, wherever the term URI [URI] is used, it can 
 be replaced interchangeably with the term IRI [RFC3987]. All widget URIs are 
 IRIs, but the term URI is more common and was therefore preferred for 
 readability.
 
 Seriously, do we need a W3C Guideline or Finding to cover DO NOT REDEFINE 
 TERMS? 
 There's glory for you! (see http://www.sabian.org/Alice/lgchap06.htm ).
 
 Suggestion: Use IRI since that's what is meant.

It seems that we seriously need a finding explaining to specification authors 
that creating new terms where existing widely used ones can be made to work is 
a bad idea that will most likely fail. Most technically savvy people I have 
ever met don't know what an IRI is, and of the happy few who do I've seen many 
a native English speaker stumble while trying to speak of them orally.

All that is needed for interoperability is for implementers to know that widget 
URIs are IRIs, and the document addresses that. Importing the IRI term into 
our space would have as sole further benefit to import the confusion and 
tongue-twisting that surround it.

I recommend that while IRIs are being reinvestigated at the IETF, the naming 
issue be addressed.

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






Re: [public-webapps] Comment on Widget URI (4)

2009-11-19 Thread Robin Berjon
Dear Larry,

thank you for your comments.

On Oct 10, 2009, at 19:44 , Larry Masinter wrote:
 4) ** EDITORIAL RE OTHER SCHEME  **
 
 In fact, it is possible that both this scheme and another defined to access 
 Zip archive content would be used jointly, with little or no overlap in 
 functionality.
 
 Without any other context, this is incomprehensible.
 
 Suggestion: remove sentence.

Fair enough. The entire section has been removed.

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






Re: [public-webapps] Comment on Widget URI (8)

2009-11-19 Thread Robin Berjon
Dear Larry,

thank you for your comments.

On Oct 10, 2009, at 19:44 , Larry Masinter wrote:
 8) ** EDITORIAL DOCUMENT ORGANIZATION **
 
 Are A, B, C and D appendices? Normative?  
 Suggestion: remove A (Usage as Origin) either remove B (Requirements) or 
 edit it to be comprehensible to someone not familiar with the widgets 
 specification, make C (Acknowledgements) and D (References) into normal 
 document sections.

As per the conformance section, sections that are not normative are marked as 
such — and that has been done here.

Usage as Origin is the topic of another comment, and will be discussed 
separately.

Requirements has been removed, it will be integrated in the the Widgets 
Requirements document.

As for Acknowledgements and References, they are indeed appendices and I 
see no reason for them not to remain as such.

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






Re: [public-webapps] Comment on Widget URI (9)

2009-11-19 Thread Robin Berjon
Dear Larry,

thank you for your comments.

On Oct 10, 2009, at 19:44 , Larry Masinter wrote:
 9) ** ORIGIN CALCULATION **
 
 A: Usage as Origin
 This information applies to the notion of origin calculation which is itself 
 incomplete, and introduces an unnecessary normative dependency.
 
 Suggestion: Drop this section (if needed for widgets, put it somewhere
 else)

Can you please explain to us in what ways it is incomplete? It is unclear to me.

This section does not introduce any normative dependencies, it mentions HTML5 
for instance to give an informative example of when such calculation may be 
used, but does not in any way require support for it.

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






RE: [widgets] The people say NO to 1.0, was Re: [public-webapps] Comment on Widget URI (7)

2009-11-19 Thread 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)

2009-11-19 Thread Robin Berjon
On Nov 19, 2009, at 13:09 , Jeremy Orlow wrote:
 Is this practical without the major browsers being part of the DAP WG?  (Last 
 time I checked, there were some absences.)

Well, the absences have been vocal in commenting so far; and others have 
indicated intention to join. We can't wait for every browser vendor to find the 
resources to join a WG to get it rolling. It took a *long* while to get 
everyone on WebApps.

 I don't understand.  If security is baked into APIs from the start (as is a 
 requirement for browsers) and the same API should be used in the different 
 context, then what need is there for a policy model?  The policy model seems 
 to only be applicable when APIs are inherently insecure and trust is 
 required...which is the type of API a browser will not implement.

In a widget context for instance, policy could override the user consent 
mechanism that an API has baked in. If you have an asynchronous security entry 
point à la Geo for instance, it could return immediately (or block 
indefinitely) without ever interacting with the user.

And as I said in the message to which you replied, additional entry points can 
be made available. To take a totally random example, if the policy grants it 
you might become able to do navigator.device.gimmeOneFile(/etc/passwd) which 
would return just what you'd get from the File API.

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






Re: [public-webapps] Comment on Widget URI (3)

2009-11-19 Thread Robin Berjon
Dear Larry,

thank you for your comments.

On Oct 10, 2009, at 19:44 , Larry Masinter wrote:
 3) ** Reuse URI schemes **
 
 http://www.w3.org/TR/webarch/#URI-scheme includes   Good practice: Reuse URI 
 schemes
 
 A specification SHOULD reuse an existing URI scheme (rather than create a 
 new one) when it provides the desired properties of identifiers and their 
 relation to resources.

The WebApps WG is well familiar with webarch. In this instance, I would like to 
emphasise when it provides the desired properties of identifiers and their 
relation to resources. The WebApps WG has discussed this topic with luminaries 
and experts in both the TAG and the community at large, and to this date, while 
we have learnt about many obscure and sometimes poorly defined URI schemes, 
none has provided us with a solution.

We've long reached the point where every drive-by you should use this! 
argument is just a rehash of something we've seen before. Having done due 
diligence, I feel confident that we haven't found an existing URI scheme that, 
as per AWWW, provides the desired properties of identifiers and their relation 
to resources.

 The draft suggests there are many other schemes (with merit) already 
 proposed, but that these existing efforts, rather than identify packaged 
 resources from the outside, widget URIs identify them only on the inside of a 
 package, irrespective of that package's own location., but this seems to 
 indicate that the requirements for widget URIs are weaker, not stronger.

Actually that wasn't the intended meaning, but since it can be construed thusly 
(and since you made another comment indicating that it was hard to understand) 
I have removed this section (it was just meant to be informative anyway).

 Suggestion: Supply use cases where reuse of existing schemes (including 
 thismessage:/) do not provide the desired properties of identifiers and 
 their relation to resources.

I do not believe that it would be a useful attribution of resources from the WG 
to document this in the specification. The process of looking at alternatives 
has been conducted in public and under strong scrutiny. If someone wishes to 
document this process, they are welcome to do so, and all the information is 
available. It would, however, do nothing to lead the web to its full potential.

To further the point, I would like to underline the fact that you suggested 
using thismessage:/ before, and that the WG provided as thorough a debunking of 
that idea as can be made given such an underspecified scheme, to which you 
didn't respond:

  http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0972.html

 Alternate Suggestion: Withdraw registration of widget: and reference 
 existing scheme.

That would leave us with no way of addressing widget resources. Having just now 
implemented a widget runtime, I don't see how we could have interoperability 
without them.

 Alternate Suggestion: Provide guidelines so that widget: can be used for 
 other applications 
  that need a way of referencing components within ZIP packages; rename 
 widget: to use
  a scheme name that is appropriate for this broader application.

Anyone who uses the widget packaging can reuse the URI. Extending widget URIs 
to apply to all Zip archives would be inappropriate the properties of relating 
identifiers to resources would have to change (see AWWW and Widget P+C for more 
details). We could also make them reusable for elephantine manicure, but 
likewise those resources are obtained in entirely different ways.

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






Re: Constrained specification of Icon element

2009-11-19 Thread Marcos Caceres
Hi Ola,
Apologies for the delay in replying. I, and others, agree with your
presented use cases and have changed the spec to match. Please see
comments below. Can you please get back to us ASAP confirming that you
agree with the changes. We intend to republish this specification next
week, but we must have confirmation from you that you are satisfied
with the changes.

2009/11/10 Ola Andersson ola.anders...@ericsson.com:
 Hi,
 I understand it might be too late to modify the spec now but I still think 
 the spec isn't clear with regards to icon size and should be clarified, 
 maybe in some future version at least. I'm also not fully convinced your 
 description (bottom of this mail) about clipping an SVG icon is correct. This 
 is because the Widget PC spec states for the icon width/height attributes: 
 The width is only applicable to graphic formats that have no intrinsic width 
 or height (e.g., SVG). However, SVG do have intrinsic size when SVG 
 width/height are specified [1] (except in the case when widht/height are 
 %-values) so the widget spec might want to clarify this and your example 
 below should, according to the icon definition, ignore the icon 
 width/height and render the icon using the intrinsic 1000x1000px size.

 To me this behavior is not what you want, rather I propose the following 
 changes to the icon size:

 1. For the widget icon element's width and height attributes the spec 
 should state that the width and height attribute values are to be seen as a 
 guide to the UA in order for the widget provider to indicate the preferred 
 size of the icon. The UA is allowed to ignore the width/height in order to 
 change the size of the icon, exampels of when this might occur is if a UA is 
 to display icons from different providers in a single GUI (and thus prefer to 
 display them all at the same size). Or if a UA needs to enlarge icons in a 
 GUI due to accessability requirements (vision impaired users...)


Agreed.

 2. icon width/height attributes should apply to all graphic formats, not just 
 those without intrinsic size. Having this would make it possible to reuse the 
 same icon resource for multiple resolutions. The following example (almost 
 from the widget spec):


Agreed. Removed restriction on usage of the width and height attribute
(applies to all graphic formats).


Ok, the spec now reads:

[
Width/Height
A numeric attribute greater than 0 that represents, in CSS pixels
[CSS21], the author's preferred width/height for the icon. A user
agent may ignore this value when changing the height icon to fit a
rendering context or for accessibility reasons.
]


 icon src=icons/big.png/
 icon src=icons/medium.png/
 icon src=icons/small.png/

 could then be rewritten as:

 icon src=icons/big.png/
 icon src=icons/big.png width=128 height=128/
 icon src=icons/big.png width=64 height=64/

 Which would save the author the work of creating different pngs, and save 
 bandwith. All UAs have features for raster scaling so no issue with that.


I think in the above cases the author would just declare (and the UA
would just use the icon in all contexts):

icon src=icons/big.png/

A more complicated example would be:

icon src=icons/big.png/
icon src=icons/medium.png/
icon src=icons/big.png width=16 height=16 /

However, I do not see a need to add such complexity to the spec. In
other words, though I have changed the definition of the icon width
and height, I am reluctant to change the parsing model to allow the
same icon to be declared more than once (as above).

Kind regards,
Marcos

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



RE: Constrained specification of Icon element

2009-11-19 Thread Ola Andersson
Excellent! I'm happy with this.
cheers 
/o


 
 Hi Ola,
 Apologies for the delay in replying. I, and others, agree 
 with your presented use cases and have changed the spec to 
 match. Please see comments below. Can you please get back to 
 us ASAP confirming that you agree with the changes. We intend 
 to republish this specification next week, but we must have 
 confirmation from you that you are satisfied with the changes.
 
 2009/11/10 Ola Andersson ola.anders...@ericsson.com:
  Hi,
  I understand it might be too late to modify the spec now 
 but I still think the spec isn't clear with regards to icon 
 size and should be clarified, maybe in some future version at 
 least. I'm also not fully convinced your description (bottom 
 of this mail) about clipping an SVG icon is correct. This is 
 because the Widget PC spec states for the icon 
 width/height attributes: The width is only applicable to 
 graphic formats that have no intrinsic width or height (e.g., 
 SVG). However, SVG do have intrinsic size when SVG 
 width/height are specified [1] (except in the case when 
 widht/height are %-values) so the widget spec might want to 
 clarify this and your example below should, according to the 
 icon definition, ignore the icon width/height and render 
 the icon using the intrinsic 1000x1000px size.
 
  To me this behavior is not what you want, rather I propose 
 the following changes to the icon size:
 
  1. For the widget icon element's width and height attributes the 
  spec should state that the width and height attribute 
 values are to be 
  seen as a guide to the UA in order for the widget provider 
 to indicate 
  the preferred size of the icon. The UA is allowed to ignore the 
  width/height in order to change the size of the icon, 
 exampels of when 
  this might occur is if a UA is to display icons from different 
  providers in a single GUI (and thus prefer to display them 
 all at the 
  same size). Or if a UA needs to enlarge icons in a GUI due to 
  accessability requirements (vision impaired users...)
 
 
 Agreed.
 
  2. icon width/height attributes should apply to all graphic 
 formats, not just those without intrinsic size. Having this 
 would make it possible to reuse the same icon resource for 
 multiple resolutions. The following example (almost from the 
 widget spec):
 
 
 Agreed. Removed restriction on usage of the width and height 
 attribute (applies to all graphic formats).
 
 
 Ok, the spec now reads:
 
 [
 Width/Height
 A numeric attribute greater than 0 that represents, in CSS 
 pixels [CSS21], the author's preferred width/height for the 
 icon. A user agent may ignore this value when changing the 
 height icon to fit a rendering context or for accessibility reasons.
 ]
 
 
  icon src=icons/big.png/
  icon src=icons/medium.png/
  icon src=icons/small.png/
 
  could then be rewritten as:
 
  icon src=icons/big.png/
  icon src=icons/big.png width=128 height=128/ icon 
  src=icons/big.png width=64 height=64/
 
  Which would save the author the work of creating different 
 pngs, and save bandwith. All UAs have features for raster 
 scaling so no issue with that.
 
 
 I think in the above cases the author would just declare (and 
 the UA would just use the icon in all contexts):
 
 icon src=icons/big.png/
 
 A more complicated example would be:
 
 icon src=icons/big.png/
 icon src=icons/medium.png/
 icon src=icons/big.png width=16 height=16 /
 
 However, I do not see a need to add such complexity to the 
 spec. In other words, though I have changed the definition of 
 the icon width and height, I am reluctant to change the 
 parsing model to allow the same icon to be declared more than 
 once (as above).
 
 Kind regards,
 Marcos
 
 --
 Marcos Caceres
 http://datadriven.com.au
 



Re: [widgets] Interface published

2009-11-19 Thread Kai Hendry
Some comments:
http://dabase.com/blog/Widget_mapping_quirks/

Do I need to send them inline? I do prefer the Web since I can keep it
better upto date.

Kind regards,



Re: [widgets] Interface published

2009-11-19 Thread Robin Berjon
On Nov 19, 2009, at 14:37 , Kai Hendry wrote:
Some comments:
 http://dabase.com/blog/Widget_mapping_quirks/
 
 Do I need to send them inline? I do prefer the Web since I can keep it
 better upto date.

Right, but the problem is that you can change them after we've formally 
addressed them, which is a bit problematic. If you want to keep them on the 
web, could you make a stable dated version available?

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






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

2009-11-19 Thread Marcos Caceres
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]
parameter components whose purpose is to declare the character
encoding of the start file (e.g., the value
text/html;charset=Windows-1252, where charset is a parameter
component whose purpose is to declare the character encoding of the
start file), then 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.

In the following example, the user agent would set the start file
encoding to ISO-8859-1 and would ignore the charset parameter used in
the type attribute.

widget xmlns=http://www.w3.org/ns/widgets;
  content src  = start.php
   type = text/html;charset=Windows-1252
   encoding = ISO-8859-1 /
/widget

In the following example the user agent would set the start file
encoding to Windows-1252, if the user agent supports that encoding.

widget xmlns=http://www.w3.org/ns/widgets;
  content src  = start.php
   type = text/html;charset=Windows-1252/
/widget
]

 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.

I don't know which 

Re: [public-webapps] Comment on Widget URI (2)

2009-11-19 Thread Robin Berjon
Dear Larry,

thank you for your comments.

On Oct 10, 2009, at 19:44 , Larry Masinter wrote:
 2) ** WELL-DEFINED MAPPING TO FILES **
 
 Section 4.4 Step 2 makes normative reference:
 
 http://www.w3.org/TR/widgets/#rule-for-finding-a-file-within-a-widget-
 
 The algorithm there seems to be lacking a clear definition of matches
 which deals reasonably with the issues surrounding matching and equivalence
 for Unicode strings, or the handling of character sets in IRIs which are
 not represented in UTF8.
 
 Suggestion (Editorial): Move the definition of the mapping algorithm
 into the URI scheme registration document so that its definition can 
 be reviewed for completeness.
 Suggestion (Technical): Define exactly and precisely what match means
 and make it clear what the appropriate response or error conditions are
 if there is more than one file that matches.

This comment concerns P+C, and I'm unsure about what change you are requesting 
where. Could you please provide an example of an issue in the current setup and 
explain how you would like to see it addressed?

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






Re: [public-webapps] Comment on Widget URI (1)

2009-11-19 Thread Robin Berjon
Dear Larry,

thank you for your comments.

On Oct 10, 2009, at 19:44 , Larry Masinter wrote:
 1) ** WELL DEFINED QUERY AND AUTHORITY **
 http://www.w3.org/TR/webarch/#URI-scheme points to RFC 2617, which has been
 replaced by RFC 4395. I think WebArch should be updated to recommend that
 W3C recommendations must use permanent schemes and not provisional ones.

Does this apply in any way to us?

 RFC 4395 requires that permanent scheme definitions be Well-defined. 
 Leaving in syntactic components and declaring them out of scope  is leaving 
 them undefined.

The only parts the semantics of which were flagged as outside the scope were 
fragment and query — this section has been removed.

 Suggestion: Remove 'authority' from the syntax, and any sections that
  refer to them; disallow query components
 Alternate Suggestion: define the meaning of authority and query components.

Neither the authority nor the query components are undefined or out of scope. 
Authority is syntactically defined, and is clearly specified as being devoid of 
semantics (opaque). Stating that this makes the scheme not well-defined is 
untrue — it is like saying that XML Namespaces aren't well-defined because they 
are equally opaque.

The query component is equally defined as to its syntax, and its meaning is 
left to the processor (typically, a script inside an HTML page, but for other 
resources it could be different). I can't see how this differs from the http 
scheme.

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






Re: [public-webapps] Comments on Widget URI (General)

2009-11-19 Thread Robin Berjon
Hi Larry,

the WebApps WG deeply thank you for you comments on the widgets URI last call. 
We decided to split them over several emails that have been posted to the list 
with proposed responses to them. We would be grateful if you could indicate 
whether you are satisfied with each resolution within two weeks.

I elected not to copy them to the TAG list since your original copy was Bcc, 
since it's a WebApps LC to which the TAG can contributed, and since at least 
several of these would be noise there. Feel free to escalate the discussion 
there if you feel it may be needed though.

Thanks again!

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






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

2009-11-19 Thread Adam Barth
On Thu, Nov 19, 2009 at 2:49 AM, David Rogers david.rog...@omtp.org wrote:
 -Original Message-
 From: public-device-apis-requ...@w3.org 
 [mailto:public-device-apis-requ...@w3.org] On Behalf Of Adam Barth
 Sent: 19 November 2009 07:42
 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?)

 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.

 [DAVID] I would hope that we can come up with some clever API design in terms 
 of safe logic. However, this does not solve the whole problem, at some point 
 you need to make a decision / judgement call.

Really?  What decision / judgement call do we need to make for the
file upload control?  What decision / judgement call do we need to
make for the video tag?

 What the policy advocates are proposing is to advance the whole discipline 
 here - let's improve this by adding strength in depth and allow the user to 
 defer their decision to someone who they trust, who is willing to take the 
 decision for them.

You're not listening to the folks on this thread who are telling you
that this model has been tried and failed.  At best this is a science
experiment.  Writing web standards is a terrible way to run a science
project.

Adam



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

2009-11-19 Thread Adam Barth
David, you're not listening.

On Thu, Nov 19, 2009 at 3:02 AM, David Rogers david.rog...@omtp.org wrote:
 -Original Message-
 From: Jonas Sicking [mailto:jo...@sicking.cc]
 Sent: 19 November 2009 10:11
 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?)

 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.

 [DAVID] I would expect that you would do this as a matter of course
 anyway as part of the security lifecycle. However a side-benefit from
 your argument would be that policy would therefore help reduce your
 maintenance?

Jonas just said that they had a policy mechanism and that's what
*caused* the problem in the first place.  He solved the problem by
removing the policy lever in Thunderbird that let users shoot
themselves in the foot.

Adam



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

2009-11-19 Thread Adam Barth
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



[widgets] Draft Minutes for 19 November 2009 Voice Conference

2009-11-19 Thread Arthur Barstow
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-20091029/
 [18] http://lists.w3.org/Archives/Public/public-webapps/ 
2009OctDec/0711.html
 [19] http://lists.w3.org/Archives/Public/public-webapps/ 
2009OctDec/0750.html
 [20] http://lists.w3.org/Archives/Public/public-webapps/ 
2009OctDec/0567.html

 [21] http://lists.w3.org/Archives/Public/public-w

   ebapps/2009OctDec/0808.html ) and 1 from Benoit (
   [22]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/04
   69.html ) .

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


   AB: let's make sure we are all on the same page re these comments
   ... what's the plan to populate the CT doc?

   MC: I'll start tomorrow
   ... Benoit's is open

   scribe ACTION: benoit close the loop on your PC comment [recorded
   in 

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

2009-11-19 Thread 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)

2009-11-19 Thread Maciej Stachowiak


On Nov 19, 2009, at 7:58 AM, Adam Barth wrote:

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.


This is pretty much how I feel about the security design aspects of  
many of the proposed DAP specifications. If you look at the specs  
listed in the Input section here: http://www.w3.org/2009/dap/, they  
mostly have missing or unhelpful Security Considerations sections. The  
BONDI security document listed there doesn't seem to provide anything  
for security other than a policy mechanism, with no hint of what might  
be a safe default policy for the Web.


Apple will consider joining the DAP Working Group, but the security  
direction so far is on reason we are hesitant.


Regards,
Maciej




[WebSimpleDB] Flatting APIs to simplify primary cases

2009-11-19 Thread Pablo Castro
We're busy creating experimental implementations of WebSimpleDB to both 
understand what it takes to implement and also to see what the developer 
experience looks like. 

As we started to write application code against the API (particularly the 
async one) the first thing that popped is the fact that you need two levels of 
nested callbacks for everything. While the current factoring of the API makes 
sense on the design board, it's kind of noisy in app code. For example:

// assume you already have a database opened in dbReq 
var html = ul; 
var storeReq = new ObjectStoreRequest(dbReq.database);
storeReq.success = function() {
var cursorReq = new CursorRequest(storeReq.store);
cursorReq.callback = function(key, cursor, value) {
html += li + value.Name + /li;
}
cursorReq.onsuccess = function(r) {
document.getElementById(output).innerHTML = html + /ul;
}
cursorReq.open();
}
storeReq.open();

One option that we would like to explore is to flatten the API, so most 
common methods are straight in the database class. This trades off some of the 
factoring in favor of usability for common cases using the async API.

The change would span a couple of aspects:

1. Move operations from object store interface and the index interface into the 
Database interface.

Accessing indexes and stores through specialized objects is problematic for the 
following reasons:
- It's always the case that we need to consider when objects are invalidated 
because something changes from underneath them, for example a schema change. So 
for example, if there is an explicit store object, then when the store is 
dropped we need to consider what is valid/invalid and what its failure points 
and modes are. By not having a standalone store object, we significantly reduce 
the gotchas to consider.
- From a usability perspective, it's simpler to work with a store in a single 
step, rather than having to open it first and then work with it (see patterns 
below with a single request and one DBRequest object).
- With no two-step access pattern, the API has one less level of 
asynchronicity, as effectively the table lookup + operation are atomic within 
the store. This also consolidates all operations with an async variant in a 
single interface (the Database), which is a great simplification for 
discoverability.

var html = ul;
var request = asyncDb.forEachStoreObject(contacts, function(row) {
   html += li + row.Name + /li;
});
request.onsuccess = function(r) {
  document.getElementById(output).innerHTML = html + /ul; }

In moving the operations, it's probably best to rename them to something more 
descriptive, so we can have for example 'getFromStore(storeName, key)' and 
'getFromIndex(storeName, indexName, key)'. This also helps in that 'delete' 
won't collide with the Javascript keyword.

Note that the store and index interfaces are still around to provide metadata, 
but at this point they behave as simple read-only snapshots.

2. Generalize the use of DBRequest, add a 'result' member to it and have all 
asynchronous operations be initiated from a DatabaseAsync interface.

As a result of the previous changes, all operations that have an async 
counterpart should now exist on the DatabaseAsync interface. Rather than having 
multiple types of requests depending on the target object, it is possible to 
have operations on a DatabaseAsync interface that provide a uniform invocation 
and handling programming pattern.

This gives a nice pattern for understanding how a sync API maps to an async API.

So for example:

var record = db.getFromStore(store, key); // use record...

Becomes:

var request = asyncDb.getFromStore(store, key); request.onsuccess = 
function(req) {
  var record = req.result;
  // use record...
};

We could include more data in DBRequest or DBRequest.result as needed if in 
some cases a method produces more than just a simple result. Further 
specializatons of DBRequest (subtypes) are still possible in the future if we 
need to introduce special cases for specific operations.

Similarly, we would have something like asyncDb.forEachStoreObject() that 
queues a task to call a callback for each element in a store/index, potentially 
within a range if specified. The pattern scales well to all the other APIs 
present in db/store/index today.

If this seems like a good idea to folks, we'd be happy to write up a more 
complete version that articulates the tweaks across all the WebSimpleDB APIs to 
make this happen.

Regards,
-pablo




Re: [widgets] multiple co-authors

2009-11-19 Thread Marcos Caceres
Hi Scott,
Artb would like to include this comment as part of our Disposition of
Comments for PC. We intend to republish next week, so I need an
approval that you are satisfied with the response I sent you ASAP
(hopefully you are:)).

Kind regards,
Marcos

On Thu, Nov 19, 2009 at 11:58 AM, Marcos Caceres marc...@opera.com wrote:
 On Thu, Nov 19, 2009 at 11:10 AM, Scott Wilson
 scott.bradley.wil...@gmail.com wrote:
 In PC the author element is defined as: An author element represents
 people or an organization attributed with the creation of the widget. with
 zero or one occurrence [1]

 I was wondering how the element is used to represent more than one person?
 The example used shows two names, but there can only be one email address,
 and the href and email attributes are only defined in terms of the singular
 (the author).

 I see what you mean, but I guess something like:

 widget ...
  author email=project_n...@some.org
                href=http://some.org/project_name/developers;Simon
 and Garfunkel/author
 /widget


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




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



Microsoft pre-LCWD feedback on WebSocket API

2009-11-19 Thread Adrian Bateman
Apologies for only sending this at the deadline. I have been collecting 
feedback from a number of different groups at Microsoft who have been reviewing 
the WebSockets API spec and only had chance to collate it today.

Feedback on Web Sockets API (draft dated 29 October 2009)

1) In the WebSocket constructor, we think it would make sense to limit the 
optional protocol string to a set of characters that is easier to secure. The 
UI never surfaces this string and having something that doesn't require 
processing the full set of strings into UTF-8 shouldn't be a significant 
restriction. We also think that specifying length constraints would be useful. 
For example, stipulating the minimum length that conforming implementations 
must be able to handle. One suggestion was to re-use the same criteria as a 
valid scheme name as defined in section 3.1 of RFC 3986.

2) The second comment about the protocol string is editorial. There was quite a 
lot of confusion about what the protocol string is used for and whether a 
central registry would be needed for well-known protocol strings. I don't 
believe this is intended or necessary but this suggests that the language could 
be clearer. Perhaps an informative section describing the expected use of the 
protocol string might be included.

3) The spec uses many terms that the HTML5 spec defines. As far as I can tell, 
there isn't a definitive list of these. The 2.1 dependencies section notes that 
many concepts come from HTML5 but not saying which ones seems insufficient for 
spec moving to Last Call. Most of the people who looked at this spec had never 
looked at HTML5 before and their feedback was simply that many terms were 
undefined.

4) In step 2 of the UA steps for the WebSocket() constructor, the spec calls 
for an exception to be thrown if the user agent chooses to block a well-known 
port. We think that web developers will often miss this case because it will be 
hard to test the error case and may be an unusual failure. We propose that the 
UA signal this condition in the same way as failing to connect to a service 
which will be much more common and more likely to be handled by web developers.

5) It is not clear precisely where the 'fail the Web Socket connection 
algorithm' is defined.

6) The send() method can both throw an exception in the CONNECTING state or 
return an 'error' flag if in the CLOSED state. APIs that both have return 
values and also throw exceptions commonly cause coding errors by developers 
using them. For example, here web developers may fail to deal with the 
CONNECTING state because on their test service they get an almost immediate 
connection but once they deploy hitting this case becomes much more common. We 
recommend choosing between exceptions or return values but not both.

7) It is not clear exactly how to implement the bufferedAmount property and be 
interoperable. Where is the queue of bytes not yet sent? Is this at the 
application layer, in the networking stack, on the network card, or somewhere 
else? We propose removing the bufferedAmount property.

I think we will have some other feedback more related to the wire protocol than 
the API although changes to the protocol could potentially impact the API. I'm 
not sure how the working group plans to handle this interaction between the API 
draft and discussions elsewhere about the protocol (I understand there is a 
proposal to deal with the protocol in an IETF working group?).

Cheers,

Adrian.

-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Arthur Barstow
Sent: Wednesday, November 04, 2009 5:46 AM
To: public-webapps
Subject: Seeking pre-LCWD comments for: Server-sent Events, Web {Database, 
Sockets, Storage Workers}; deadline 19 November

As noted on 23 October [1], the following HTML5 APIs are ready or  
very close to being ready for Last Call Working Draft (LC):

1. Server-Sent Events
   http://dev.w3.org/html5/eventsource/

2. Web Database
   http://dev.w3.org/html5/webdatabase/

3. Web Sockets API
   http://dev.w3.org/html5/websockets/

4. Web Storage
   http://dev.w3.org/html5/webstorage/

5. Web Workers
   http://dev.w3.org/html5/workers/

Please submit comments about these specs by 19 November.

Note the Process Document states the following regarding the  
significance/meaning of LCWD:

[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
Purpose: 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 

Re: [widgets] multiple co-authors

2009-11-19 Thread Marcos Caceres
On Thu, Nov 19, 2009 at 8:53 PM, Marcos Caceres marc...@opera.com wrote:
 Hi Scott,
 Artb would like to include this comment as part of our Disposition of
 Comments for PC. We intend to republish next week, so I need an
 approval that you are satisfied with the response I sent you ASAP
 (hopefully you are:)).

I modified the example in the spec. It's now:

widget xmlns=http://www.w3.org/ns/widgets;
nameCafé Finder/name
author href  = http://dahut.example.org/developers/;
email = questi...@example.org
  Joey and Princesa Bacalhau
/author
/widget

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



Moving Window and stuff out of HTML5

2009-11-19 Thread Krzysztof Maczyński
Dear WGs,
(Ccing public-weba...@w3.org.)

 They could be split out into a separate specification or  
 specifications,
 and HTML5 would probably not even need to reference them.
 
 I agree that it's good design in principle to split the core platform  
 APIs (window, navigator, etc) into separate specs.
 
 However, it is also much harder than it may seem.
SVG 1.2 Tiny has some of this stuff. Window Object 1.0 WD is a more elaborate 
take, in hiatus because of no active editor and apparently also of unclearness 
still covering the dependencies and what should therefore go where to achieve a 
workable and reasonable suit of orthogonal specs.
I suggest scaling the Window Object 1.0 WD down to what SVG 1.2 Tiny specifies, 
possibly with some small and uncontroversial additions. This spec could 
progress to Rec quickly, having been long overdue and implemented since 1990s. 
Then version 2.0 could use a better approximation of our wishlists.

 To be clear, this list *is* the right venue for discussing the draft,  
 including ideas for changing it.
You also wrote to Shelley Powers:
 In the meantime, please do not attempt to quash discussion of what is  
 in the draft.
The way I understood Shelley, and actually support this position, is that 
placement of these APIs in HTML5 drafts is wrong to begin with because the 
HTML5 WG isn't chartered to work on APIs which aren't (shouldn't be) 
particularly associated with HTML. Window (although a misnomer) is the most 
important badly missing piece in Web scripting, and currently only in SVG (at 
least as W3C specs go, and of course unless I'm missing something) can it be 
used legally (e.g. expecting a property called document on the global object if 
the language is ECMAScript).

Best regards,

Krzysztof Maczyński
Invited Expert, HTML WG



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

2009-11-19 Thread 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)

2009-11-19 Thread 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 

[webdatabase] Handling of the query arguments

2009-11-19 Thread João Eiras


Hi everyone.

Neither the web database specification, nor the IDL, specify the fine  
grained handling that implementation must do of the several possible  
values that can be passed in the 2nd argument to executeSql, considering  
that those ecmascript values need to be handled by the SQL engine, and  
therefore converted into a database compatible value.


The only reference to the arguments is the paragraph that tell that the  
arguments should be replaced, but I've already asked that paragraph  
language to be reviewed in

http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1329.html

Handling of ecmascript to database types could be done the following way:
 - numerical values would be converted to REAL
 - strings would be converted to TEXT, including the empty string
 - booleans would be converted to lowercase TEXT false or true
 - null and undefined would be handled as NULL
 - functions would be converted to TEXT

Objects, which do not fit the primitive types about, can be handled in two  
ways.


1) The quick cheap way, which was already hinted, would be to convert them  
to string.
However, that's not very helpful, if the object is a native type wrapper  
like:

 new String(aa);
 new Number(1);
 new Boolean(true)

2) We can define, in the Web IDL, how an object can be converted to a  
primitive type.
Specifically, in an ecmascript binding we can do the following (note:  
returns means to stop the steps):

 - if object is null, return null
 - if object has a member function called valueOf, invoke valueOf in the  
context of object

   - if the returned value is a primitive type, return the value,
 - if object has a member function called toString, invoke toString in the  
context of object

   - if the returned value is a primitive type, return the value,
 - return Object.prototype.toString.call(object), so we get [object  
Class]


The returned primitive type would then go through the ecmascript to  
database type steps above.


However, the Web IDL need to be language agnostic, so I'll leave for the  
Web IDL maintainers to decide if this is of its scope and specifiable.


There might need to be clarification on how to define what is a numerical  
value, a string, a boolean, null and undefined, and functions.
We could say that a numerical value is just a number, but ideally, it  
should also include Number() instances, despite these could return non  
numerical values from their valueOf, but then we would go into the  
object-to-primitive steps.


The complete, we need the specification to tell how to convert database  
types back into ecmascript object, but this is easier:

 - TEXT, and other text types are converted to DOMString
 - REAL and other number types are converted to double
 - NULL is converted to null
 - DATE/TIMESTAMP types should be converted to Date objects, if supported

Thank you for your time.

--

João Eiras
Core Developer, Opera Software ASA, http://www.opera.com/



Re: [webdatabase] Handling of the query arguments

2009-11-19 Thread Maciej Stachowiak


On Nov 19, 2009, at 2:12 PM, João Eiras wrote:



Hi everyone.

Neither the web database specification, nor the IDL, specify the  
fine grained handling that implementation must do of the several  
possible values that can be passed in the 2nd argument to  
executeSql, considering that those ecmascript values need to be  
handled by the SQL engine, and therefore converted into a database  
compatible value.


The only reference to the arguments is the paragraph that tell that  
the arguments should be replaced, but I've already asked that  
paragraph language to be reviewed in
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/ 
1329.html


Handling of ecmascript to database types could be done the following  
way:

- numerical values would be converted to REAL
- strings would be converted to TEXT, including the empty string
- booleans would be converted to lowercase TEXT false or true
- null and undefined would be handled as NULL
- functions would be converted to TEXT

Objects, which do not fit the primitive types about, can be handled  
in two ways.


1) The quick cheap way, which was already hinted, would be to  
convert them to string.
However, that's not very helpful, if the object is a native type  
wrapper like:

new String(aa);
new Number(1);
new Boolean(true)

2) We can define, in the Web IDL, how an object can be converted to  
a primitive type.
Specifically, in an ecmascript binding we can do the following  
(note: returns means to stop the steps):

- if object is null, return null
- if object has a member function called valueOf, invoke valueOf in  
the context of object

  - if the returned value is a primitive type, return the value,
- if object has a member function called toString, invoke toString  
in the context of object

  - if the returned value is a primitive type, return the value,
- return Object.prototype.toString.call(object), so we get [object  
Class]


ECMAScript defines a ToPrimitive conversion (Section 9.1 of ECMA-262  
5th edition). I think the right thing to do would be for some spec to  
point to those steps. Probably it has to be Web Database, because in  
many cases where a Web IDL method takes an any type, it's not  
appropriate to do ToPrimitive conversion.


Regards,
Maciej




Re: [webdatabase] Handling of the query arguments

2009-11-19 Thread João Eiras


2) We can define, in the Web IDL, how an object can be converted to a  
primitive type.
Specifically, in an ecmascript binding we can do the following (note:  
returns means to stop the steps):

- if object is null, return null
- if object has a member function called valueOf, invoke valueOf in the  
context of object

  - if the returned value is a primitive type, return the value,
- if object has a member function called toString, invoke toString in  
the context of object

  - if the returned value is a primitive type, return the value,
- return Object.prototype.toString.call(object), so we get [object  
Class]


ECMAScript defines a ToPrimitive conversion (Section 9.1 of ECMA-262 5th  
edition). I think the right thing to do would be for some spec to point  
to those steps. Probably it has to be Web Database, because in many  
cases where a Web IDL method takes an any type, it's not appropriate  
to do ToPrimitive conversion.




Indeed !

--

João Eiras
Core Developer, Opera Software ASA, http://www.opera.com/



Re: [widgets] Test suite: problem with test cases

2009-11-19 Thread Marcos Caceres
On Wed, Nov 18, 2009 at 1:59 PM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
 On 18 Nov 2009, at 12:02, Marcos Caceres wrote:

 2009/11/14 Scott Wilson scott.bradley.wil...@gmail.com:

 woops, fixed.

 Assertion 34: Test d7, d8

 ===

 These test cases both contain badly-formed XML:

 widget

  content

 /widget

 Presumably these ought to be:

 widget

  content/

 /widget

 Fixed and checked in.

 Thanks - btw you still need to check in the updated .wgt files as well as
 the config.xml


Doh, I thought I had. I just checked in new versions for these tests.


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



Security evaluation of an example DAP policy

2009-11-19 Thread Adam Barth
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=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
        

RE: Security evaluation of an example DAP policy

2009-11-19 Thread 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=or
 

RE: Security evaluation of an example DAP policy

2009-11-19 Thread 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 

Re: Security evaluation of an example DAP policy

2009-11-19 Thread Jonas Sicking
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).

/ Jonas



Re: Security evaluation of an example DAP policy

2009-11-19 Thread Maciej Stachowiak


On Nov 19, 2009, at 4:00 PM, Marcin Hanclik wrote:


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.


Allowing write access to *any* file with just a one-shot confirmation  
prompt is unacceptable for the browser context. Or even read access.  
That's why the File API starts with input type=file which has the  
user take an affirmative step to choose a file, rather than confirming  
the Web page's choice of file. This may seem like a subtle issue but  
it makes a huge difference to the security implications.


Access after a blanket prompt to access to read any file, to send  
email as the user, to read or write the contacts list, and to record  
via the camera all sound like extremely risky designs.


Launching an app after a oneshot prompt is also extremely dangerous.  
Combined with other functionality, this can put a Web site one user  
confirmation away from running arbitrary native code.


This is the kind of issue that needs to be considered up-front in the  
design, rather than bolted on by a policy. Many of these issues have  
to be addressed in the API design, not just by tweaking a policy file,  
to be truly Web-safe.





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 :)


When a security design seems fundamentally mistaken, I think it's  
important to be really clear about the problems, even if that comes  
off as blunt or harsh to some people.


Regards,
Maciej




Re: Security evaluation of an example DAP policy

2009-11-19 Thread Maciej Stachowiak


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




Re: Moving Window and stuff out of HTML5

2009-11-19 Thread Maciej Stachowiak


On Nov 19, 2009, at 1:11 PM, Krzysztof Maczyński wrote:


Dear WGs,
(Ccing public-weba...@w3.org.)


They could be split out into a separate specification or
specifications,
and HTML5 would probably not even need to reference them.


I agree that it's good design in principle to split the core platform
APIs (window, navigator, etc) into separate specs.

However, it is also much harder than it may seem.
SVG 1.2 Tiny has some of this stuff. Window Object 1.0 WD is a more  
elaborate take, in hiatus because of no active editor and apparently  
also of unclearness still covering the dependencies and what should  
therefore go where to achieve a workable and reasonable suit of  
orthogonal specs.
I suggest scaling the Window Object 1.0 WD down to what SVG 1.2 Tiny  
specifies, possibly with some small and uncontroversial additions.  
This spec could progress to Rec quickly, having been long overdue  
and implemented since 1990s. Then version 2.0 could use a better  
approximation of our wishlists.


Speaking as the former editor, I think Window Object 1.0 actually  
specifies too little to be a useful for anything in HTML5. Cutting it  
down further would probably not result in something useful. That's  
part of why I stopped work.





To be clear, this list *is* the right venue for discussing the draft,
including ideas for changing it.

You also wrote to Shelley Powers:

In the meantime, please do not attempt to quash discussion of what is
in the draft.
The way I understood Shelley, and actually support this position, is  
that placement of these APIs in HTML5 drafts is wrong to begin with  
because the HTML5 WG isn't chartered to work on APIs which aren't  
(shouldn't be) particularly associated with HTML. Window (although a  
misnomer) is the most important badly missing piece in Web  
scripting, and currently only in SVG (at least as W3C specs go, and  
of course unless I'm missing something) can it be used legally (e.g.  
expecting a property called document on the global object if the  
language is ECMAScript).


That is a reasonable position to take and it's fine for Shelley (or  
you) to pursue it. But for now the Navigator object is in HTML5, and  
we should continue to provide a forum for discussing it until such  
time as we decide to remove it.


Regards,
Maciej




RE: Security evaluation of an example DAP policy

2009-11-19 Thread 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.



RE: Let's turn WebDatabase into a WG Note

2009-11-19 Thread Adrian Bateman
On Wednesday, November 18, 2009 2:51 PM, Charles McCathieNevile wrote:
 I think it make sense to clarify in working drafts that this spec is
 unlikely to be interoperable across the web at large, but is usable for
 various specific systems.
 
 I don't think it makes sense to just turn it into a note at this stage -
 as the Google guys said, let's get some experience with WebSimpleDB
 before
 we make a final call. Likewise, I agree with Robin that it might not make
 sense to take this to Last Call, because of the uncertainty about where
 we
 are going to end up.

I agree with Chaals. As I noted at TPAC, at Microsoft we don't think we'll 
collectively be able to achieve reasonable interop because of the SQL dialect 
issue (it's not like we can even choose one of the existing 'standard' SQL 
dialects since current implementations don't conform to anything like that). 
Considering that, it seems unlikely that there will be two independent 
interoperable implementations at the SQL level which makes moving to Last Call 
potentially problematic. On the other hand, it seems premature to dismiss the 
work entirely as a WG Note when more than one member has expressed a desire to 
move forward.

I do wonder whether it might make sense to include an editor's note in the WD 
indicating that independent implementations of the SQL dialect aren't currently 
anticipated just so that anyone unfamiliar with this conversation would be 
aware from the spec.

Cheers,

Adrian.