Re: Agenda for January 29 Teleconference

As an implementor, I would prefer no restrictions. I feel it is my choice to do what I please with the data. In this case, we aggregate logs at a central host. In other cases, I shipped data to "cloud" services like Splunk/loggly. I imagine this use case will be more common than directly logging back to the host application. 

I don't think the spec or implementations should be concerned with things like this as it is up to the implementor to do things "wrong". If I am the type to disregard such warnings, then I am possibly violating privacy in many other and more serious ways. 

One thing I would be fine with is requiring posts to be over SSL. Perhaps I am not understanding the privacy goals of this spec, but it seems like all pitfalls would lie in the implementation of the header on an applications, rather than the spec.

I will be on today's call. 

-- 
Neil Matatall


On Tuesday, January 29, 2013 at 9:16 AM, Ian Melven wrote:

> 
> 
> Hi,
> 
> that's the item i was waiting to comment on last teleconference :)
> 
> Within Mozilla, we recently discussed something along the same lines for report-uri to replace
> our current same eTLD+1 restriction on sending reports. The suggestion was that reports could be
> sent to any host a la the spec, but then potentially privacy or security sensitive information
> would only be included if the report was going to a same eTLD+1 host.
> 
> would this be useful to site implementers ? or would this essentially be the same
> as the current restriction because all the available info is desired ? 
> 
> i've been meaning to bring this up on the list before today's call, but flu :(
> 
> cheers,
> ian
> 
> 
> ----- Original Message -----
> From: "Neil Matatall" <neilm@twitter.com (mailto:neilm@twitter.com)>
> To: "Eric Rescorla" <ekr@rtfm.com (mailto:ekr@rtfm.com)>
> Cc: "public-webappsec" <public-webappsec@w3.org (mailto:public-webappsec@w3.org)>
> Sent: Monday, January 28, 2013 6:36:17 PM
> Subject: Re: Agenda for January 29 Teleconference
> 
> 
> Did this item drop off from last time? Or has there been some consensus? 
> 
> 
> 22:37 - 22:39 Line #s in CSP reports only for same-origin, CORS? 
> 
> 
> 
> 
> - Neil 
> 
> On Monday, January 28, 2013 at 6:01 PM, Eric Rescorla wrote: 
> 
> 
> 
> 
> 
> DATE: Jan, 29 2013 
> TIME: 22:00-23:00 UTC (14:00-15:00 PST) 
> 
> +1.617.761.6200 ; PIN 92794 ('WASWG') and #webappsec on irc.w3.org:6665 (http://irc.w3.org:6665) 
> (Or VoIP via the Zakim SIP bridge: http://www.w3.org/2006/tools/wiki/Zakim-SIP ) 
> 
> 
> 22:00 - 22:03 Scribe Selection (Default -> Eric Rescorla) 
> 22:03 - 22:05 Roll Call 
> 22:05 - 22:06 Minutes Approval 
> 22:07 - 22:08 Agenda Bashing 
> 22:08 - 22:09 News: CSP 1.0 to CR 
> 22:10 - 22:15 Review of open actions in tracker 
> 22:15 - 22:30 Review raised+open issues, assign actions 
> 22:30 - 22:35 default-src violation types 
> http://lists.w3.org/Archives/Public/public-webappsec/2013Jan/0036.html 
> 22:35 - 22:40 CSP and HSTS 
> http://lists.w3.org/Archives/Public/public-webappsec/2013Jan/0034.html 
> 22:40 - 22:45 Defaults for clipping and selectors 
> http://lists.w3.org/Archives/Public/public-webappsec/2013Jan/0045.html 
> 22:45 - 22:57 UI Safety ISSUE 2 
> "The restriction to a single additional host source value was 
> based on the request of the Websec WG as part of moving this 
> feature to this document. This decision should be evaluated in the 
> context of CSP. For example, while standalone implementations of 
> X-Frame-Options may not have wanted to incur the complexity of 
> parsing potentially large lists of origins, CSP implementaions 
> must already be robust in their handling of such lists. The 
> inclusion of multiple origins may reveal details of the security 
> model of a resource that chooses to publish such a policy and 
> risks associated with this should be discussed in the Security 
> Considerations section if any change is made." 
> 22:57 - 23:00 Move of testing repos to github 
> http://lists.w3.org/Archives/Public/public-webappsec/2013Jan/0044.html 
> 
> 
> Scribe Rotation. We go down the list in order. Please advise if you 
> cannot scribe for some reason, or if you are not listed here and 
> should be. 
> 
> 
> Adam Barth 
> Jeff Hodges 
> David Huang 
> Gopal Raghavan 
> Eric Rescorla <-- 
> Jacob Rossi 
> Tanvi Vyas 
> Peleus Uhley 
> Dan Veditz 
> Ryan Ware 
> Jim O'Leary 
> Adam Bresee 
> Ian Melven 
> 
>