W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2013

Re: Agenda for January 29 Teleconference

From: Daniel Veditz <dveditz@mozilla.com>
Date: Tue, 29 Jan 2013 14:28:09 -0800
Message-ID: <51084CF9.6050101@mozilla.com>
To: Neil Matatall <neil@matatall.com>
CC: Ian Melven <imelven@mozilla.com>, Neil Matatall <neilm@twitter.com>, public-webappsec <public-webappsec@w3.org>, Eric Rescorla <ekr@rtfm.com>
On 1/29/2013 9:42 AM, Neil Matatall wrote:
> 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.

As browser implementors we don't only worry about people using the 
feature for its intended purpose, we have to worry about intentional 
mis-use of a feature. If an attacker can inject a policy what data can 
be sent where? If the reporting URL is restricted to the same domain 
that set the policy and provided the content then I'm comfortable that 
the data is really being sent to you, the site implementor; in that case 
yes, please, do what you want with the data. If the data is being sent 
to some other site then I don't know it's you (might be, might not be) 
and then my instinct is to restrict the amount of data available so as 
not to further additional attacks. The downside of that is that you 
might not get enough data to do anything useful.

That's the trade-off. Are you getting enough data from the current error 
reports? If not can we safely send the additional data just anywhere 
potentially to anyone or will we have to restrict the destinations. Is 
it worth the spec complications of saying reports may differ depending 
on the destination?

-Dan Veditz
Received on Tuesday, 29 January 2013 22:28:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 29 January 2013 22:28:38 GMT