Re: CSP: origin from a URL

On Wed, Jun 26, 2013 at 3:08 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Wed, Jun 26, 2013 at 5:19 AM, Adam Barth <w3c@adambarth.com> wrote:
>> On Tue, Jun 25, 2013 at 3:31 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> Why does https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#reporting
>>> use a different algorithm to derive an origin from a URL?
>>
>> Different from what?
>
> From: https://tools.ietf.org/html/rfc6454#section-6.2
>
>>> Also, it
>>> seems somewhat confusing to have this new origin type, actual origins,
>>> and URLs, in the same value space. Even though the property says
>>> "blocked-uri" you wouldn't be able to parse it with a URL parser and
>>> get a sensible result.
>>
>> I'm not sure I understand.  Can you give a specific situation where
>> something problematic happens?
>
> Using a URL parser just "data" would fail to parse. It seems the field
> is actually a union of schemes, origins, and URLs.
>
>> What we've tried to do with this field is include as much information
>> about the blocked URI as we can do safely.  In the same-origin case,
>> we can include the URI with the fragment removed.  For the
>> cross-origin case, we need to strip out the path and query portions as
>> well.  I guess we could do that directly instead of converting to an
>> origin and then serializing back to ASCII.  We'd just have to be
>> careful to do something sensible with data URIs.
>
> Hmm mkay.

I guess I'm not sure what behavior you're advocating for...  Are you
happy with the status quo?  Would you prefer that we stripped the URL
ourselves without referring to rfc6454?

It sounds like you think we should always have a valid URL in this
field, which seems reasonable.  If the blocked URL is a data URL,
presumably we don't want to send the whole data URL in the report...
Maybe we should find another way of summarizing the data URL that is
still a valid URL?

Adam

Received on Wednesday, 26 June 2013 16:42:55 UTC