Re: Beacon feedback

On Sun, Feb 16, 2014 at 3:15 AM, Arvind Jain <arvind@google.com> wrote:
> I've addressed some of your comments and have questions about the others.
> Please review (inline below).

I was on vacation, hence the delay.


> On Thu, Feb 13, 2014 at 10:25 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
>> 1. I don't understand the part of section 4.2 that is not IDL. It
>> seems to contradict the processing model on multiple occasions. Part
>> of it does not, I think, but that should be separated and the
>> authorization bit should be a parameter to Fetch.
>
> Could you tell me what parts contradict and which parts do you not
> understand?

Could you explain why you need double requirements first? That's bad practice.


>> 2c) You convert /data/ to code points but forget about /url/.
>
> Could you please elaborate? I'm not able to see the issue.

The URL parser does not deal with lone surrogates. You can use an IDL
feature for this, not sure if it'll remain in its current form though.


>> 2e) You invoke "cross-origin request" from CORS (which is obsolete as
>> you know, Fetch is here) without actually defining all the parameters
>> that requires.
>
> I am not sure how to fix this. The XMLHTTPRequest send() call seems to have
> similar language to this. I'll look into it more but if you can clarify
> further, that would be helpful.

What XMLHttpRequest specification are you reviewing? I recommend
looking at http://xhr.spec.whatwg.org/ only.



>> 2f) You don't deal with closed blobs (unclear yet how that should be
>> done).
>
> Will handle in next pass. (Not sure how to).

Ok.


>> 2g) For FormData you are concatenating code points and bytes.
>
> Not sure. Will handle in next pass.

Ok.


>> 2h) Your origin check has a major security bug. You cannot check
>> against the base URL's origin, that can be anything!
>
> What is the security bug? Again, I review XMLHTTPRequest send() call which
> makes a similar check. Please explain what the bug is.

Both URL and the base URL are controlled by the author. Meaning they
can be always same origin with each other and going to any server
whatsoever. Seems obvious.


>> I'm curious how implementers managed to implement this. I guess they
>> did not actually read the specification and just implemented what they
>> thought it should mean approximately?

Still curious.


-- 
http://annevankesteren.nl/

Received on Monday, 17 March 2014 15:35:17 UTC