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
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
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
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
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
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
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
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
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
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
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
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
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;
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
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:
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;
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
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
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.
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
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,
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:
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.
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
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
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 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
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]
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
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
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
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
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
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,
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
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
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.
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
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
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)
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
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
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,
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
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 )
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
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
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
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
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;
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.
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
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,
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
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
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
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
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
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
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 -
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
74 matches
Mail list logo
