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
consider q=a and some will only consider q=b. This is such a mess - the developer should have to specifically opt-in to this. cheers devdatta 3) I've added a clearParameter method. Defining these methods required some low-level URL manipulation that's not actually defined anywhere (AFAIK), so I've

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
+1 for 2 APIs - this whole multiple parameters with the same value is too annoying imho and unnecessary for new web services . It should be there only for old services that are also accessed via basic HTML forms cheers devdatta On 20 September 2010 23:56, Adam Barth w...@adambarth.com wrote: Ok

Re: A URL API

2010-09-21 Thread Devdatta Akhawe
case of single parameter values clean and robust cheers devdatta Also, getParameterByName and getAllParametersByName seem unnecessarily wordy. How about getParameter/getParameterAll to match querySelector/querySelectorAll? Putting All at the end is admittedly awkward, but this is the uncommon

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
of XHR. This isn't ideal. Regards devdatta [1] http://m-austin.com/blog/?p=19

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
. Regards devdatta I meant undesirable in that it will require much deeper changes to browsers. I wouldn't mind making it possible to request an image or other subresource without cookies, but I don't think there's currently a mechanism for that, is there?  And if there's consensus that user

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

2010-07-07 Thread Devdatta Akhawe
it would affect sites. It would be like the user cleared his cache and made a request. regards devdatta Personally, I would love to see cross-origin subresource requests change to not using cookies, but that could break existing web sites that include subresources from partner sites, etc

Re: CORS Header Filtering?

2010-05-12 Thread Devdatta
IIRC HTTP-WG has asked this WG to change this behavior from a whitelist to a blacklist. There was a huge discussion about this a while back -- maybe this could be an example of why CORS should follow the HTTP-WG's recommendations. -devdatta On 12 May 2010 11:50, Nathan nat...@webr3.org wrote

Re: UMP / CORS: Implementor Interest

2010-05-12 Thread Devdatta
informative. He could also cite UMP as a possible option for those worried about security. Cheers devdatta On 12 May 2010 12:26, Tyler Close tyler.cl...@gmail.com wrote: On Wed, May 12, 2010 at 11:17 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, May 12, 2010 at 9:01 AM, Tyler Close tyler.cl

Re: CORS Header Filtering?

2010-05-12 Thread Devdatta
Do you have real examples of someone in a later stage adding headers but expecting it to be protected by Same Origin Policy (in that they are fine with SOP script accessing the headers ) ? Regards devdatta On 12 May 2010 12:51, Tyler Close tyler.cl...@gmail.com wrote: On Wed, May 12, 2010 at 12

Re: [UMP] Server opt-in

2010-01-12 Thread Devdatta
a nonce/permission token can lose confidentiality or have any security costs of CORS just by doing Access-Control-Allow-Origin: * ? Regards Devdatta

Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

2009-12-16 Thread Devdatta
. Are there examples for CORS which can't be done by UM/XDR ? Cheers devdatta 2009/12/16 Ian Hickson i...@hixie.ch: On Wed, 16 Dec 2009, Kenton Varda wrote: Without the benefit of full context (I only started following this list recently), I'd like cautiously to suggest that the UM solution

Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

2009-12-16 Thread Devdatta
hmm.. just a XDR GET on the file at hixie.ch which allows access only if the request is from damowmow.com ? I am not sure -- is there anything special about XBL bindings which would result in this not working ? Cheers devdatta 2009/12/16 Ian Hickson i...@hixie.ch: On Wed, 16 Dec 2009, Devdatta

Re: CORS versus Uniform Messaging?

2009-12-14 Thread Devdatta
easier and quicker. Cheers devdatta

Re: CSRF vulnerability in Tyler's GuestXHR protocol?

2009-11-13 Thread Devdatta
that of a user going to Site B (an event's site) and adding stuff to his calendar at A ? In such a scenario, the complete protocol should ideally start with B. Thanks devdatta

Re: CSRF vulnerability in Tyler's GuestXHR protocol?

2009-11-12 Thread Devdatta
to be marked as a GuestXHR 3 The 'secret123' token : Does it expire? If yes when/how ? Also, if it expires, will the user have to again confirm the grant from A ? Thanks Devdatta 2009/11/10 Tyler Close tyler.cl...@gmail.com: I've elaborated on the example at: http://sites.google.com/site

Re: STS and lockCA

2009-11-11 Thread Devdatta
take your site offline) Cheers Devdatta 2009/11/11 Adam Barth w...@adambarth.com: On Tue, Nov 10, 2009 at 7:40 PM, Bil Corry b...@corry.biz wrote: Gervase Markham wrote on 10/01/2009 5:51 PM: I therefore propose a simple extension to the STS standard; a single token to be appended to the end