Re: CORS performance

2015-02-17 Thread Devdatta Akhawe
+1 to Anne's suggestion. The current design is pretty terrible for API performance. I think a request to / with OPTIONS or something, with a response that requires some server side logic (like return the random number UA just sent) is pretty darn secure. cheers dev On 17 February 2015 at 11:24,

Re: Security use cases for packaging

2015-01-29 Thread Devdatta Akhawe
Maybe the code from the downloaded package has to be run from a local origin like chrome://*. Doesn't the same issue that Chris raised still exist? You need a unit of isolation that says only code signed with this public key runs in this isolation compartment. Chrome extensions have that

Re: A URL API

2010-09-24 Thread Devdatta Akhawe
If you really don't want to care what happened before, either do a clearParameter every time first, or define your own setParameter that just clears then appends.  Append/clear is a cleaner API design in general imo, precisely because you don't have to worry about colliding with previous

Re: A URL API

2010-09-22 Thread Devdatta Akhawe
2) I've added two flavors of appendParameter.  The first flavor takes a DOMString for a value and appends a single parameter.  The second flavor takes an array of DOMStrings and appends one parameter for each array.  This seemed better than using a variable number of arguments. -1 I really

Re: A URL API

2010-09-21 Thread Devdatta Akhawe
or any webservice that likes to have lots of query parameters - Google Search for example. In general, why would you not want a robust way to make complicated queries - those who are making simple queries and prefer simple one liners can continue using it. On 20 September 2010 23:42, Darin

Re: A URL API

2010-09-21 Thread Devdatta Akhawe
instances of the same parameter name.  I like the easy of supplying a JSON object, but I'm not in love with the magical syntax.  An alternative is to use two APIs, like we current have for reading the parameter values. Adam On Mon, Sep 20, 2010 at 11:47 PM, Devdatta Akhawe dev.akh...@gmail.com

Re: A URL API

2010-09-21 Thread Devdatta Akhawe
APIs, like we current have for reading the parameter values. Adam On Mon, Sep 20, 2010 at 11:47 PM, Devdatta Akhawe dev.akh...@gmail.com wrote: or any webservice that likes to have lots of query parameters - Google Search for example. In general, why would you not want a robust way

Re: A URL API

2010-09-21 Thread Devdatta Akhawe
Perhaps appendParameter(x, a, b, c) ? where appendParameter is the second API - separate from setParameter? so appendParmeter(x',a,b,c); setParameter(x,a) would result in ?x=a and without the second function call it would be ?x=ax=bx=c I am fine with this. cheers devdatta Adam

Re: A URL API

2010-09-19 Thread Devdatta Akhawe
hi Is the word 'hash' for fragment identifiers common? I personally prefer the attribute being called 'fragment' or 'fragmentID' over 'hash' - its the standard afaik in all the RFCs. regards devdatta On 19 September 2010 15:47, João Eiras joao.ei...@gmail.com wrote: That would be different

Re: A URL API

2010-09-19 Thread Devdatta Akhawe
1) There are now two methods for getting at the URL parameters.  The and none for setting them? cheers devdatta 2) The origin attribute is now readonly.  Once I wired up the origin attribute to the actual definition of how to compute the origin of a URL, it became obvious that we don't

Re: A URL API

2010-09-17 Thread Devdatta Akhawe
hi You mean you didn't mention that I drafted a much better one over two years ago? Garrett : could you send a link to your ES4 draft/proposal ? My simple google skills couldn't find it. thanks devdatta And you felt this API was worth mentioning? My criticism is spot-on and appropriate.

[cors] Protecting benign but buggy client side code

2010-08-20 Thread Devdatta Akhawe
Hi The CORS specification in its current form seems to be very concerned about increasing attack surface of benign servers (the preflight request etc. concern). Seeing [1] I am concerned about the other case - benign clients and malicious cross origin servers. for the tl;dr crowd - my (possibly

Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?

2010-07-07 Thread Devdatta Akhawe
Because it's undesirable to prevent the browser from sending cookies on an img request, Why ? I can understand why you can't do it today - but why is this undesirable even for new applications? Ad tracking ? ~devdatta On 7 July 2010 16:11, Charlie Reis cr...@chromium.org wrote: On Wed, Jul

Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?

2010-07-07 Thread Devdatta Akhawe
hmm, I think I quoted the wrong part of your email. I wanted to ask why would it be undesirable to make CORS GET requests cookie-less. It seems the argument here is reduction of implementation work. Is this the only one? Note that even AnonXmlHttpRequest intends to make GET requests cookie-less.

Re: [cors] Allow-Credentials vs Allow-Origin: * on image elements?

2010-07-07 Thread Devdatta Akhawe
.  Is there a proposal or discussion about this somewhere? In the mean time, the canvas tainting example in the spec seems difficult to achieve. Charlie On Wed, Jul 7, 2010 at 5:05 PM, Devdatta Akhawe dev.akh...@gmail.com wrote: hmm, I think I quoted the wrong part of your email. I wanted to ask