Re: Proposal for a credential management API.

[Hill, Brad]

I think the broader goals Jonas has articulated probably belong in their own 
group, perhaps chartered along with some of what comes out of the upcoming Web 
Crypto Next Steps workshop.  

http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers.html

I'll say by way of indicating possible conflict-of-interest that the FIDO 
Alliance is also working on parts of this problem space 
(https://fidoalliance.org) but is focusing more specifically on enabling strong 
authentication without passwords.  We (FIDO) are presenting a paper at the 
workshop.

Ideally, then, without being too optimistic, I'd like to see passwords replaced 
entirely by better technology rather than continuing to kludge upon them.  
They're still a fundamentally broken technology in many important respects even 
with better management tools.

Also, we should be careful in decomposing our targets here.  Federation is a 
different layer than replacing passwords or password management.  There are 
already a number of standards in that area which could be given "native" 
support in a browser without having to re-invent the wheel.  (e.g. SAML2, 
WS-Federation, OpenID Connect / OAuth2, etc.)

-Brad


On Aug 18, 2014, at 4:45 AM, Mike West  wrote:

> On Tue, Aug 12, 2014 at 10:19 PM, Jonas Sicking  wrote:
> > One- or two-click sign _up_, on the other hand, will likely be more
> > difficult given the complexities of authorization (scopes, etc).
> 
> I'm not sure what you count as sign-up? Today, if I visit a new
> website that I've never visited before, I can log in to that website
> in two clicks using identity providers as facebook/twitter/google. I
> don't think anything more than that is going get the support we need.
> 
> You're right. I was thinking about username/password flows for sign-up, which 
> can be significantly more complex than IDP's general "pick an IDP, then grant 
> access" flows.
> 
> I'd like to support both, for what it's worth.
> 
> -mike
> 
> --
> Mike West 
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
> 
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
> 

RE: security model of Web Components, etc. - joint work with WebAppSec?

[Hill, Brad]

As I mentioned in my introductory message, I am specifically interested in the 
security model of components loaded cross-origin - do they get complete control 
of the application / DOM into which they are loaded?  Does an application have 
any ability to restrict or explicitly pass capabilities to a cross-origin 
component?

-Brad Hill

> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@nokia.com]
> Sent: Friday, March 15, 2013 7:20 AM
> To: Hill, Brad; Dimitri Glazkov
> Cc: public-webapp...@w3.org; public-webapps
> Subject: Re: security model of Web Components, etc. - joint work with
> WebAppSec?
> 
> On 3/14/13 8:16 PM, ext Charles McCathie Nevile wrote:
> > On Thu, 14 Mar 2013 18:15:14 +0100, Dimitri Glazkov
> >  wrote:
> >
> >> On Thu, Mar 14, 2013 at 7:10 AM, Hill, Brad 
> >> wrote:
> >>
> >>> Is there time available on the April F2F agenda for discussion of this?
> >>> If not in WebApps, would relevant WG members be willing to join us
> >>> if we found time to discuss in WebAppSec's timeslot Thursday or
> >>> Friday?
> >>>
> >> http://www.w3.org/wiki/Webapps/April2013Meeting#Potential_Topics
> >> Shows agenda wide open so far. Should we just plop something into one
> >> of the slots?
> >
> > Yep, that's a reasonable thing to do...
> 
> I allocated a slot for the joint meeting on Thursday from 2:30-3:00. If anyone
> thinks more time is needed, please speak up.
> 
> Please use public-webapps@w3.org for _all_ Web Components discussions and
> I encourage feedback, comments, etc. in _advance_ of the meeting.
> 
> FYI Brad, Dimitri and the Editors have created a suite of Web Components
> specs. The set of specs that have already been published is:
> 
> * Web Components Introduction
> <http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html>
> 
> * HTML Templates
> <http://dvcs.w3.org/hg/webcomponents/raw-
> file/tip/spec/templates/index.html>
> 
> * Shadow DOM
> <http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html>
> 
> There is at least one unpublished ED (not sure if this is ready yet for 
> security
> review):
> 
> * Web Components ( and Components API)
> <https://dvcs.w3.org/hg/webcomponents/raw-
> file/tip/spec/components/index.html>
> 
> Dimitri - if you can think of specific areas of potential security concerns 
> you
> would like reviewed or if I missed any specs, please let us know.
> 
> -Thanks, ArtB
> 
> 
> >
> > cheers
> >
> > Chaals
> >

RE: security model of Web Components, etc. - joint work with WebAppSec?

[Hill, Brad]

Is there time available on the April F2F agenda for discussion of this?  If not 
in WebApps, would relevant WG members be willing to join us if we found time to 
discuss in WebAppSec's timeslot Thursday or Friday?

From: dglaz...@google.com [mailto:dglaz...@google.com] On Behalf Of Dimitri 
Glazkov
Sent: Monday, March 11, 2013 1:23 PM
To: Arthur Barstow
Cc: Hill, Brad; public-webapp...@w3.org; WebApps WG (public-webapps@w3.org)
Subject: Re: security model of Web Components, etc. - joint work with WebAppSec?

On Sat, Mar 9, 2013 at 4:36 AM, Arthur Barstow 
mailto:art.bars...@nokia.com>> wrote:
[ Apology for top-posting and continuing the cross-posting ]

Hi Brad,

Thanks, yes earlier security review and feedback would be good.

My preference is to use public-webapps (solely) for all discussions related to 
Web Components (WC).

Re discussing security and WC f2f, I added a joint meeting between these two 
groups as a potential agenda topic for WebApps' April 25-26 f2f meeting [1] but 
I did not allocate a specific day+time slot because it could be a bit premature 
right now. That said, if you, or Dimitri, or other WC people have a specific 
day+time you would prefer, please speak up and note we intend to meet all day 
on the 25th but only until noon on the 26th. (Of course we can cancel the joint 
meeting if it turns out there is no need to meet.)

I am happy to help facilitate this. Please let me know how I can help.

:DG<

security model of Web Components, etc. - joint work with WebAppSec?

[Hill, Brad]

WebApps WG,

  I have been following with interest (though with less time to give it the 
attention I wish) the emergence of Web Components and related specifications. 
(HTML Templates, Shadow DOM, etc.)

 I  wonder if it would be a good time to start discussing the security model 
jointly with the WebAppSec WG, both on list, and possibly at the upcoming F2F 
in April?

  One of our goals in WebAppSec is that a mashup web of re-usable and 
composable pieces be possible to do securely. An example anti-pattern in this 
area is the widely deployed 

Call for Consensus: CORS to Candidate Recommendation

[Hill, Brad]

WebApps and WebAppSec WG members, (and copied security interest groups who we 
invite to provide comments)

Following discussion at TPAC, I've resolved outstanding changes in the security 
considerations section agreed to by WebAppSec as well as differences between 
the W3C and WHATWG versions of CORS, and believe we are ready to go to 
Candidate Recommendation.  We probably have enough implementations to proceed 
directly to Proposed Recommendation, but our test suite still needs better 
documentation of its coverage and some test cases need repairs, so I believe 
moving to CR first, and as soon as possible, is the right next step, while we 
work out those details.

I have placed a draft for review at:

http://www.w3.org/2011/webappsec/cors-draft/

And this is a Call for Consensus among the WebAppSec and WebApps WGs to take 
this particular text (with necessary additions to the Status of this Document 
section if approved) forward to Candidate Recommendation.

Please send comments to public-webapp...@w3.org 
, positive feedback is encouraged.

This CfC will end on November 23, 2012.

Substantive changes from the last published version (both pulled from the 
WHATWG version) include:

1.updating the redirect status codes to include the newly defined 308

2.   adding the referrer source header as input to the fetch algorithm

Non-substantive changes include:


1.   Clarified text defining 5.1, Access-Control-Origin allow header to 
read: the value of the Origin request header, "*", or "null"

2.   Updated "certificates differ" reason for algorithm abort to 
"certificate errors"

3.   Replaced "ambient authority" with "user credentials sent with 
cross-origin requests"

4.   Replaced a number of instances of "server" with more consistent usage 
of "resource"

5.   Updated language slightly about OWS in header value definitions in 
HTTP/1.1 spec

6.   Removed reference in security considerations to Origin header as a 
credential, as it is explicitly defined as not being a credential

7.   Deleted paragraph in security considerations section on forwarding 
attacks as on further consideration it is not a genuine concern

8.   Removed language about validating data in the security considerations 
section comparing CORS to JSONP

9.   Removed "safe and idempotent" language in security considerations and 
replaced with "significance other than retrieval"

10.   Changed "implicit" credentials language to "user credentials 
automatically attached to the request by the user agent"

11.   Updated language in security considerations on path-distinguished 
application principals vs. origin-distinguished principals

12.   Merged updated thanks and acknowledgements from WHATWG version

13.   Removed language about multiple origins in security considerations as 
that is now forbidden by the redirect steps

14.   Added a non-normative "Implementation Considerations" as Section 6.4 
under the Resource Processing Model with the following text:

"Resources that wish to enable themselves to be shared with multiple
  Origins but do not respond uniformly with "*"
  must in practice generate the Access-Control-Allow-Origin
  header dynamically in response to every request they wish
  to allow.  As a consequence, authors of such resources should send a
  Vary: Origin HTTP header or provide other appropriate control
  directives to prevent caching of such responses, which may be inaccurate
  if re-used across-origins."

Thank you,

Brad Hill
WebAppSec WG Co-Chair

[webappsec] CORS bug 19315

[Hill, Brad]

http://lists.w3.org/Archives/Public/public-webappsec/2012Oct/0004.html

This bug report on CORS, that the "Last-Event-ID" header should be a simple 
header, (along with Origin and Referer based on the status of actual 
implementations) is the last substantive change to the document that remains 
unresolved.

I would like to propose we add "Last-Event-ID", "Origin" and "Referer" to the 
set of simple headers.   Are there any objections, concerns or comments?

Thank you,
-Brad Hill

Call for Review of Content Security Policy 1.0

[Hill, Brad]

The Web Application Security Working Group at the W3C is planning to advance 
Content Security Policy 1.0 to Candidate Recommendation - a final set of 
features and syntax - and is seeking wide review of the document at this time.  
We would especially value the input of members of the WebApps WG.



http://www.w3.org/TR/2012/WD-CSP-20120710/



Content Security Policy is a mechanism web applications can use to mitigate a 
broad class of content injection vulnerabilities, such as cross-site scripting 
(XSS). Content Security Policy is a declarative policy that lets the authors 
(or server administrators) of a web application restrict from where the 
application can load resources.



To mitigate XSS, for example, a web application can restrict itself to loading 
scripts only from known, trusted URIs, making it difficult for an attacker who 
can inject content into the web application to inject malicious script.



Content Security Policy (CSP) is not intended as a first line of defense 
against content injection vulnerabilities. Instead, CSP is best used as 
defense-in-depth, to reduce the harm caused by content injection attacks.



There is often a non-trivial amount of work required to apply CSP to an 
existing web application. To reap the greatest benefit, authors will need to 
move all inline script and style out-of-line, for example into external 
scripts, because the user agent cannot determine whether an inline script was 
injected by an attacker.



To take advantage of CSP, a web application opts into using CSP by supplying a 
Content-Security-Policy HTTP header Such policies apply the current resource 
representation only. To supply a policy for an entire site, the server needs to 
supply a policy with each resource representation.



Please submit comments to 
public-webapp...@w3.org



Thank you,

Brad Hill

Co-Chair

W3C Web Application Security WG

TransAnn: CORS published as Last Call Working Draft

[Hill, Brad]

The WebApps and WebAppSec WG would like to announce the publication of 
Cross-Origin Resource Sharing (CORS) as a Last Call Working Draft.

http://www.w3.org/TR/cors/

Please send comments about this document to public-webapp...@w3.org with [CORS] 
as the start of the subject line.

Deadline for comments is 1 May 2012.

The decision to move to Last Call was recorded at: 
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1012.html
http://www.w3.org/2012/02/28-webappsec-minutes.html 

We especially encourage comments from the following groups:
WebApps WG
WebAppSec WG
Security IG
HTML WG
W3C TAG

Thank you,

Brad Hill

Security bug in XmlHttpRequest, setRequestHeader()

[Hill, Brad]

Kusuke Ebihara (Ikousuke at co3k.org ) has discovered an interesting security 
bug with XHR.

http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2012-January/008170.html
 

Basically, for CGI programs, characters that are valid in HTTP headers but not 
in Unix shell environment variables are commonly all coerced to "_".  This 
allows bypass of the security restrictions in 
http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader-method, section 5.  
If an application sets, e.g. a header of "User_Agent" (or in some cases 
"User.Agent", "User*Agent", etc...), that is indistinguishable when delivered 
to a CGI application from the forbidden "User-Agent". 

As this behavior is at least partially formally documented in  
http://tools.ietf.org/html/rfc3875#section-4.1.18 , and very widely 
implemented, the algorithm for XHR should be updated to at least consider "_", 
and possibly all non-alphanumeric characters, as equivalent to "-" for purposes 
of comparison to the blacklisted header set.

Brad Hill
Sr. MTS, Internet Standards and Governance
PayPal Information Risk Management
cell: 206.245.7844 / skype: hillbrad
email: bh...@paypal-inc.com

CfC: CORS to advance to Last Call

[Hill, Brad]

As discussed in the WebAppSec WG call on Dec 6, the editor would like to 
promote Cross-Origin Resource Sharing (CORS) to Last Call and this is a Call 
for Consensus to do so:

http://www.w3.org/TR/2010/WD-cors-20100727/


This CfC satisfies the group's requirement to "record the group's decision to 
request advancement".



Positive response to this CfC is preferred and encouraged and silence will be 
considered as agreement with the proposal. The deadline for comments is January 
3, 2012.  Please send all comments to:

public-webapp...@w3.org

Thank you,

Brad Hill

RE: From-Origin FPWD

[Hill, Brad]

The ability to do all of these things server-side, with referrer checking, has 
been universally available for fifteen years.  (RFC 1945)

In every one of the use cases below, From-Origin is a worse solution than 
referrer checking.  What is the benefit?  Why should I choose From-Origin?  Why 
should we expect it to become universally deployed where referrer checking is 
not?

-Brad

From: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of Robert 
O'Callahan
Sent: Monday, August 01, 2011 6:16 AM
To: Hill, Brad
Cc: Anne van Kesteren; WebApps WG
Subject: Re: From-Origin FPWD

On Thu, Jul 28, 2011 at 12:44 PM, Hill, Brad 
mailto:bh...@paypal-inc.com>> wrote:
What are the use cases where a user is better off if their browser obeys 
From-Origin than if it does not?

Bandwidth "theft"?  The user wants to see the image.  The problem, such that 
one exists, is for the hosting server.  They can and do address this risk with 
the Referrer header today. Servers are not better off with this mechanism, 
since From-Origin is enforced too late, on the client-side, after they've 
already paid the bandwidth cost to send the image.

If From-Origin is widely implemented, then there is no incentive to attempt to 
steal bandwidth since the stealing page will be broken for most users. 
Therefore authors won't even try to do it, so servers will be better off.
Font licensing?  Again, the user would prefer that his or her agent display the 
font.  The license here is about attempting to keep the user from using 
something of value and their own agent is a poor policy enforcement point for 
this.

As above, as long as a majority of user-agents honor From-Origin, cross-origin 
embedding will be discouraged and authors will get a useful tool to control 
access to their resources. Some users choosing to disable From-Origin checking, 
or just downloading resources some other way, will not break the system.

In fact, if most user-agents honor From-Origin, there is no incentive to do 
cross-origin embedding in a way that violates From-Origin, so authors won't, so 
there will be no incentive for users to disable From-Origin.
Privacy leakage?  Elimination of side channels is an extremely difficult task; 
generally the best result is that the bandwidth of such channels can be 
limited, but we are attempting to protect a single bit of information here.  
Methods such as cache-timing and the active attacks recently described by 
Weinberg, et al (http://websec.sv.cmu.edu/visited/visited.pdf) are likely more 
than sufficient to reveal whether a user has an account somewhere.

Precisely because side channels are very difficult to eliminate, we need to 
create mechanisms to prevent cross-origin embedding, since such embedding is 
prone to all kinds of information leakage due to side channels. For example, 
cross-origin image embedding leaks not just whether the image can be loaded, 
but also the image size, and there are proof-of-concept timing attacks that 
leak information about image pixel data.

An intranet configured to use "From-Origin: same" by default, with all intranet 
users using From-Origin-supporting browsers, would be considerably more robust 
against information leaks than what we can ensure today.

Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in 
us. If we confess our sins, he is faithful and just and will forgive us our 
sins and purify us from all unrighteousness. If we claim we have not sinned, we 
make him out to be a liar and his word is not in us." [1 John 1:8-10]

RE: From-Origin FPWD

[Hill, Brad]

I'm still not convinced that implementing this as a feature of the User Agent 
benefits the user or is the most appropriate technology for addressing the 
problem statements in the specification.

What are the use cases where a user is better off if their browser obeys 
From-Origin than if it does not?

Bandwidth "theft"?  The user wants to see the image.  The problem, such that 
one exists, is for the hosting server.  They can and do address this risk with 
the Referrer header today. Servers are not better off with this mechanism, 
since From-Origin is enforced too late, on the client-side, after they've 
already paid the bandwidth cost to send the image.

Font licensing?  Again, the user would prefer that his or her agent display the 
font.  The license here is about attempting to keep the user from using 
something of value and their own agent is a poor policy enforcement point for 
this.

Clickjacking?  X-Frame-Options has support in every major browser and is 
currently sent by over 10,000 sites according to http://www.shodanhq.com/.  I 
see little reason to re-invent something with such broad adoption, or to 
conflate a feature that is scoped to provide clear security benefit with 
additional features that users are incentivized to disable. (client-side 
license and bandwidth "theft" enforcement)  

Privacy leakage?  Elimination of side channels is an extremely difficult task; 
generally the best result is that the bandwidth of such channels can be 
limited, but we are attempting to protect a single bit of information here.  
Methods such as cache-timing and the active attacks recently described by 
Weinberg, et al (http://websec.sv.cmu.edu/visited/visited.pdf) are likely more 
than sufficient to reveal whether a user has an account somewhere.   

Do we have any data here on how common this very specific kind of leakage is, 
and if there are any sites that would actually be interested in sending this 
header for this purpose?  For this specific case, I would again assert that 
server-side enforcement based on Referer is simpler and more likely to succeed, 
as the server can send the same response for both conditions to unauthorized 
parties, instead of sending a differential response anyway and asking that it 
not be measured.  

-Brad
  
P.S: the header itself is a cause of privacy leakage for the sending server by 
indicating which other servers it is willing to allow embedding content in.  
There are also issues of header size with the proposed approach.  In 
X-Frame-Options, the current discussion is to allow only a single origin 
instead of a list.  

-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Anne van Kesteren
Sent: Friday, July 22, 2011 8:09 AM
To: WebApps WG
Subject: From-Origin FPWD

Hi,

The WebApps WG published the From-Origin header proposal as FPWD:

   http://www.w3.org/TR/from-origin/

The main open issue is whether X-Frame-Options should be replaced by this 
header or should absorb its functionality somehow.

Cheers,


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

RE: From-Origin FPWD

[Hill, Brad]

-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Anne van Kesteren
Sent: Friday, July 22, 2011 8:09 AM
To: WebApps WG
Subject: From-Origin FPWD

Hi,

The WebApps WG published the From-Origin header proposal as FPWD:

   http://www.w3.org/TR/from-origin/

The main open issue is whether X-Frame-Options should be replaced by this 
header or should absorb its functionality somehow.

Cheers,


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

RE: Frame embedding: One problem, three possible specs?

[Hill, Brad]

The latest draft of the WebAppSec charter includes a secure cross-domain 
framing mechanism as a distinct deliverable from the CSP, it's relation is only 
in proposing re-use of same browsing context capability grammar as CSP.  So 
retaining option #1 is not in conflict with dropping frame-ancestors from CSP 
v1.

#2 and #3 (and frame-ancestors in the current CSP draft) allow expression of 
similar policies: "This content can only be framed/embedded by these origins."  
I think it makes sense to consolidate these going forward.

#1 in the new WebAppSec WG draft charter is different.  While there isn't a 
strawman yet, it seeks to allow expression of a policy like: "Anyone can frame 
this content, but it must allow X, Y and Z."  or maybe, "This frame is 
non-interactive unless X, Y and Z."  (where X, Y and Z might be: an 
unobstructed canvas, allowed to execute script, allowed to top-nav, top 
z-order, minimum display size, etc...) 

I think both approaches can co-exist and that #1 can proceed without conflict 
for now.  If the proposal that emerges is determined to be best transported as 
additional semantics for X-Frame-Options or From-Origin, the WebAppSec WG is 
already chartered to do the necessary coordination.

-Brad


-Original Message-
From: Adam Barth [mailto:w...@adambarth.com] 
Sent: Thursday, July 07, 2011 3:24 PM
To: Thomas Roessler
Cc: Tobias Gondrom; Arthur Barstow; Hill, Brad; Eric Rescorla; Alexey Melnikov; 
David Ross; Anne van Kesteren; Adrian Bateman; Brandon Sterne; Charles 
McCathieNevile; Maciej Stachowiak; Peter Saint-Andre; Michael(tm) Smith; Mark 
Nottingham; Hodges, Jeff; public-web-secur...@w3.org; public-webapps@w3.org; 
web...@ietf.org
Subject: Re: Frame embedding: One problem, three possible specs?

My sense from talking with folks is that there isn't a lot of enthusiasm for 
supporting this use case in CSP at the present time.
We're trying to concentrate on a core set of directives for the first 
iteration.  If it helps reduce complexity, you might consider dropping option 
(1) for the time being.

Adam


On Thu, Jul 7, 2011 at 2:11 PM, Thomas Roessler  wrote:
> (Warning, this is cross-posted widely. One of the lists is the IETF 
> websec mailing list, to which the IETF NOTE WELL applies: 
> http://www.ietf.org/about/note-well.html)
>
>
> Folks,
>
> there appear to be at least three possible specifications addressing this 
> space, with similar but different designs:
>
> 1. A proposed deliverable in the WebAppSec group to take up on 
> X-Frame-Options and express those in CSP:
>  http://www.w3.org/2011/07/appsecwg-charter.html
>
> (We expect that this charter might go to the W3C AC for review as soon 
> as next week.)
>
> 2. The "From-Origin" draft (aka "Cross-Origin Resource Embedding Exclusion") 
> currently considered for publication as an FPWD in the Webapps WG:
>  
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0088.htm
> l
>
> This draft mentions integration into CSP as a possible path forward.
>
> 3. draft-gondrom-frame-options, an individual I-D mentioned to websec:
>  https://datatracker.ietf.org/doc/draft-gondrom-frame-options/
>  http://www.ietf.org/mail-archive/web/websec/current/msg00388.html
>
>
> How do we go about it?  One path forward might be to just proceed as 
> currently planned and coordinate when webappsec starts working.
>
> Another path forward might be to see whether we can agree now on what forum 
> to take these things forward in (and what the coordination dance might look 
> like).
>
> Thoughts welcome.
>
> Regards,
> --
> Thomas Roessler, W3C    (@roessler)
>
>
>
>

RE: Publishing From-Origin Proposal as FPWD

[Hill, Brad]

To the procedural points:

I am not a member of the Web Applications WG.  I do not have standing to block 
or make a formal objection to this moving forward as a FPWD.  Responsibility to 
measure consensus and the decision to move forward within that WG rests with 
Art.

The opinion of the proposed Web Applications Security WG (currently in the 
process of being chartered and of which I am a proposed co-chair)  was 
solicited as to whether the work should move to that forum or be a joint 
deliverable with the Content Security Policy.  Additionally, one of the goals 
of the draft was to address concerns around clickjacking, an item under the 
proposed charter scope of the WebAppSec WG.  Wearing that (still phantom) hat, 
I can say is that there isn't consensus to move this proposed mechanism as a 
cross-domain framing security solution to FPWD, alone or as part of the CSP, in 
the WebAppSec WG, at this time.  Until AC approval, we can't move anything to 
FPWD at this time.  :)

My other concerns with the proposal are put forward only as an interested 
member of the community.  I expect there will be ample opportunity to discuss 
them.  If Art feels that moving forward to FPWD is the best next step to foster 
that and other discussions, I'm more than happy to participate there to the 
extent the WG welcomes my feedback and finds it useful.

Thanks,

Brad Hill

-Original Message-
From: public-web-security-requ...@w3.org 
[mailto:public-web-security-requ...@w3.org] On Behalf Of Bjoern Hoehrmann
Sent: Tuesday, July 05, 2011 4:38 PM
To: Marcos Caceres
Cc: WebApps WG; public-web-secur...@w3.org
Subject: Re: Publishing From-Origin Proposal as FPWD

* Marcos Caceres wrote:
>On Tue, Jul 5, 2011 at 5:50 PM, Hill, Brad  wrote:
>> I feel that the goals of this draft are either inconsistent with the 
>> basic architecture of the web, cannot be meaningfully accomplished by 
>> the proposed mechanism, or both, and I haven't seen any discussion of 
>> these concerns yet.

I note that the Web Applications Working Group's Charter, if Brad Hill is a 
member, does require the rest of the Working Group to duly consider his points 
before moving on without consensus. If not, then the group is not required to 
wait with publication, but not discussing the points in a timely manner, 
without an argument how publication is urgent in some way, does not inspire 
confidence that the arguments will be heard and duly handled.

>Publication will enable wider discussion - particularly wrt the issues 
>you have raised. Not publishing it is tantamount to saying "I OBJECT TO 
>PROGRESS!". If you are correct, more people will see it and the 
>proposal will be shot down. Otherwise, other opinions will flourish 
>that may sway your position (or a new perspective will emerge all 
>together). In any case, calling for a spec not to be published, no 
>matter how bad it is, is not the right way to do this. Publishing a 
>spec is just a formality which can lead to discussion.

The more invested people are into something, the less likely they are to cut 
their losses; by doing things, you frame the discussion in favour of doing 
more. You get people to think more about how something can be fixed rather than 
thinking about whether to abandon the work, or use a very different approach. 
If you just propose an idea to me, we can talk about it more freely than if you 
had already invested a lot of effort on implementing the idea and asked me to 
review the idea after the fact.

(~ "Die normative Kraft des Faktischen")

Realizing something is a bad idea early is therefore very important and not 
objecting to progress. Not wasting time on bad ideas is certainly progress, 
even if only indirectly as you'd work on other things instead.
As such it is quite important to react timely to design critique with care and 
detail. Psychologically, if you press ahead, you communicate that you care more 
about moving on than discussing details, which is likely to turn away the 
people more interested in details and quality; and the same is of course true 
for draft of genuinely bad quality.

Which is just to say this is actually an important matter; sometimes it is best 
to go ahead and put your ideas into practise whatever others may be saying, 
other times it turns out that you should have listened more.
That is why we allow people to block actions, not necessarily progress, but 
only up to the point where arguments have been duly considered. And here we 
have yet to do that. Until that happens, short of someone making the case for 
urgency, I would agree the group should not publish and talk about this instead.
--
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am 
Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

RE: Publishing From-Origin Proposal as FPWD

[Hill, Brad]

Well, my disagreement is not with its content; I think we should not move 
forward with this spec at all.

I feel that the goals of this draft are either inconsistent with the basic 
architecture of the web, cannot be meaningfully accomplished by the proposed 
mechanism, or both, and I haven't seen any discussion of these concerns yet.   

-Brad

-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com] 
Sent: Tuesday, July 05, 2011 7:30 AM
To: Hill, Brad; Anne van Kesteren
Cc: WebApps WG; public-web-secur...@w3.org; Daniel Veditz
Subject: Re: Publishing From-Origin Proposal as FPWD

Hi Brad, Anne,

As I mentioned in [1], I think there is sufficient support for WebApps to 
publish this spec as a FPWD and I will start a Call for Consensus to more 
formally determine WebApps' level of support.

A WG may publish a FPWD without consensus on the _contents_ of the spec. 
The Status of the Document section may be explicit on this point. We try to 
employ a "publish early, publish often" to encourage early and frequent 
comments and I think a FPWD will help stimulate comments.

Anne - please add some text re the consensus of the contents point and then 
I'll start the CfC.

-Art Barstow

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0012.html

On 7/1/11 1:52 PM, ext Hill, Brad wrote:
> The new WebAppSec WG charter draft does include a deliverable for secure 
> mashups built with cross-domain framing, with the specific intent to put 
> forward a proposal for anti-clickjacking in this space.
>
> However, I have concerns with nearly every aspect of this draft.
>
> First, I am concerned about mixed goals in the problem statement.  It's 
> definitely not in the proposed charter scope for the WebAppSec WG to address 
> issues like bandwidth "theft" and license enforcement.   Even for the WebApps 
> WG, it is arguable that some of these goals go against core Web Architecture 
> principles. (http://www.w3.org/TR/webarch/)
>
> Secondly, several of the goals, even if couched in terms of security, aren't 
> in the interest of the user.  If I go to a page, I want to see images, fonts 
> and videos on it.  Policies that prevent that from working are actually 
> adversarial to the user.From a basic security principles perspective, the 
> client-side UA is not the place for such restrictions to be enforced, as they 
> can be easily disabled.Further, conflating mechanisms to protect the user 
> (anti-clickjacking) with mechanisms adversarial to the user (font licensing) 
> encourages the user to disable even the protections that they should want.
>
> Finally, don't think the proposed mechanism here for user-protection is 
> adequate for many/most use cases at risk of clickjacking that web application 
> owners would like to deploy.  A binary frame/no-frame policy based on a 
> whitelist of origins is both very limiting and not terribly secure.   
> Consider a "like", "+1" or "pay" button.  These may be framed on tens of 
> thousands of origins, making a whitelist unmanageable.  Or they may be 
> framed-by-permission on an origin with tens of thousands of 
> resources/pages/applications (forum, auction site, etc.)  where an XSS or 
> similar in any one of which would expose the framed content to clickjacking 
> again.
>
> I think it's preferable to work towards a mechanism where resources can 
> declare they can be framed, but only subject to some policy or set of 
> capabilities which guarantee clickjacking protection, visibility, etc.
>
> Brad Hill
>
> -Original Message-
> From: public-web-security-requ...@w3.org 
> [mailto:public-web-security-requ...@w3.org] On Behalf Of Anne van 
> Kesteren
> Sent: Thursday, June 30, 2011 7:23 AM
> To: WebApps WG
> Cc: public-web-secur...@w3.org
> Subject: Publishing From-Origin Proposal as FPWD
>
> Hi hi,
>
> Is there anyone who has objections against publishing 
> http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html as a FPWD.
> The idea is mainly to gather more feedback to see if there is any interest in 
> taking this forward.
>
> (Added public-web-security because of the potential for doing this in 
> CSP instead. Though that would require a slight change of scope for 
> CSP, which I'm not sure is actually desirable.)
>
> Cheers,
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

RE: Publishing From-Origin Proposal as FPWD

[Hill, Brad]

The new WebAppSec WG charter draft does include a deliverable for secure 
mashups built with cross-domain framing, with the specific intent to put 
forward a proposal for anti-clickjacking in this space.   

However, I have concerns with nearly every aspect of this draft.   

First, I am concerned about mixed goals in the problem statement.  It's 
definitely not in the proposed charter scope for the WebAppSec WG to address 
issues like bandwidth "theft" and license enforcement.   Even for the WebApps 
WG, it is arguable that some of these goals go against core Web Architecture 
principles. (http://www.w3.org/TR/webarch/) 

Secondly, several of the goals, even if couched in terms of security, aren't in 
the interest of the user.  If I go to a page, I want to see images, fonts and 
videos on it.  Policies that prevent that from working are actually adversarial 
to the user.From a basic security principles perspective, the client-side 
UA is not the place for such restrictions to be enforced, as they can be easily 
disabled.Further, conflating mechanisms to protect the user 
(anti-clickjacking) with mechanisms adversarial to the user (font licensing) 
encourages the user to disable even the protections that they should want. 

Finally, don't think the proposed mechanism here for user-protection is 
adequate for many/most use cases at risk of clickjacking that web application 
owners would like to deploy.  A binary frame/no-frame policy based on a 
whitelist of origins is both very limiting and not terribly secure.   Consider 
a "like", "+1" or "pay" button.  These may be framed on tens of thousands of 
origins, making a whitelist unmanageable.  Or they may be framed-by-permission 
on an origin with tens of thousands of resources/pages/applications (forum, 
auction site, etc.)  where an XSS or similar in any one of which would expose 
the framed content to clickjacking again.

I think it's preferable to work towards a mechanism where resources can declare 
they can be framed, but only subject to some policy or set of capabilities 
which guarantee clickjacking protection, visibility, etc.

Brad Hill

-Original Message-
From: public-web-security-requ...@w3.org 
[mailto:public-web-security-requ...@w3.org] On Behalf Of Anne van Kesteren
Sent: Thursday, June 30, 2011 7:23 AM
To: WebApps WG
Cc: public-web-secur...@w3.org
Subject: Publishing From-Origin Proposal as FPWD

Hi hi,

Is there anyone who has objections against publishing 
http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html as a FPWD.  
The idea is mainly to gather more feedback to see if there is any interest in 
taking this forward.

(Added public-web-security because of the potential for doing this in CSP 
instead. Though that would require a slight change of scope for CSP, which I'm 
not sure is actually desirable.)

Cheers,


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