Re: Agenda for January 29 Teleconference

Hello Dan,

Thanks for the background, I'll try to take off my hat :) Just some questions:

> If an attacker can inject a policy what data can be sent where?

Is this a threat that we should keep in mind? If you can inject a
policy, I would think you likely have bigger issues. And if you're
over http://, you have no guarantees whatsoever.



On Tue, Jan 29, 2013 at 2:28 PM, Daniel Veditz <dveditz@mozilla.com> wrote:
> 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:55:29 UTC