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, Anne van Kesteren ann...@annevk.nl wrote:
 On Tue, Feb 17, 2015 at 8:18 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
 Individual resources should not be able to declare policy for the whole
 server, ...

 With HSTS we gave up on that.


 HTTP/1.1 rather has `OPTIONS *` for that, which would require a
 new kind of preflight request. And if the whole server is fine with
 cross-origin requests, I am not sure there is much of a point trying to
 lock it down by restricting request headers or methods.

 Yeah, I wasn't sure whether those should all be listed. Maybe simply
 declaring you're fluent in CORS in a unique way is sufficient.


 --
 https://annevankesteren.nl/




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 model.
Whether we achieve this via origins, COWLs, or origin+key as the
identifier, is a separate question, but Chris' high level bit remains true.

cheers
dev



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 activity by default.  A set/clear pair means that you
 have to explicitly check for existing data and handle it in a way that
 isn't completely trivial.

I am not saying remove append - I am saying that just also have set,
with the semantics that if you use set, its equivalent to clear;append

 Attempting to relegate same-name params to second-tier status isn't a
 good idea.  It's very useful for far more than the old services that
 are also accessed via basic HTML forms that you stated earlier.


I am not sure about that - I think a modern API design would be to
just send multiple values as an array (maybe CSV or TSV). Consider how
JSON values are encoded - do you have multiple values to denote
arrays? neither is this the case in XML (afaik). This semantic of
multiple yet different values for the same parameter is just
confusing, and as you said a mess for server side. I am less
optimistic than you are that it will be fixed.

cheers
devdtta


 ~TJ




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 want the setParameter method - appendParameter now requires
the developer to know what someone might have done in the past with
the URL object. this can be a cause of trouble as the web application
might do something that the developer doesn't expect , so I
specifically want the developer to opt-in to using appendParameters.

I know clearParameter is a method - but this is not the clear
separation between the '2 APIs' that we talked about earlier in the
thread.

I remember reading about how some web application frameworks combine
?q=aq=b to q=ab at the server side, whereas some will only 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 added a reference to my
 work-in-progress draft about parsing and canonicalizing URLs.

 Adam


 On Tue, Sep 21, 2010 at 3:40 PM, Ojan Vafai o...@chromium.org wrote:
 appendParameter/clearParameter seems fine to me.
 On Wed, Sep 22, 2010 at 2:53 AM, Tab Atkins Jr. jackalm...@gmail.com
 wrote:

 On Mon, Sep 20, 2010 at 11:56 PM, Adam Barth w...@adambarth.com wrote:
  Ok.  I'm sold on having an API for constructing query parameters.
  Thoughts on what it should look like?  Here's what jQuery does:
 
  http://api.jquery.com/jQuery.get/
 
  Essentially, you supply a JSON object containing the parameters.  They
  also have some magical syntax for specifying multiple 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.

 jQuery's syntax isn't magical - the example they give using the query
 param name of 'choices[]' is doing that because PHP requires a [] at
 the end of the query param name to signal it that you want multiple
 values.  It's opaque, though - you could just as easily have left off
 the '[]' and it would have worked the same.

 The switch is just whether you pass an array or a string (maybe they
 support numbers too?).

 I recommend the method be called append*, so you can use it both for
 first sets and later additions (this is particularly useful if you're
 just looping through some data).  This obviously would then need a
 clear functionality as well.

 ~TJ







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 Fisher da...@chromium.org wrote:
 On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.com
 wrote:

 On 9/20/10, Julian Reschke julian.resc...@gmx.de wrote:
  On 20.09.2010 18:56, Garrett Smith wrote:
 [...]
  Requests that don't have lot of parameters are often simple one-liners:
 
  url = /getShipping/?zip= + zip + pid= + pid;
 
  That's exactly the kind of code that will fail once pid and zip
  contain things you don't expecz.
 
  What XHRs have complicated URL with a lot of query parameters?
 
  What XHRs?
 
 IOW, what are the cases where an XHR instance wants to use a lot o query
 params?


 Probably when speaking to a HTTP server designed to take input from an HTML
 form.
 -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.  I'm sold on having an API for constructing query parameters.
 Thoughts on what it should look like?  Here's what jQuery does:

 http://api.jquery.com/jQuery.get/

 Essentially, you supply a JSON object containing the parameters.  They
 also have some magical syntax for specifying multiple 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 
 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 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 Fisher da...@chromium.org wrote:
 On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.com
 wrote:

 On 9/20/10, Julian Reschke julian.resc...@gmx.de wrote:
  On 20.09.2010 18:56, Garrett Smith wrote:
 [...]
  Requests that don't have lot of parameters are often simple one-liners:
 
  url = /getShipping/?zip= + zip + pid= + pid;
 
  That's exactly the kind of code that will fail once pid and zip
  contain things you don't expecz.
 
  What XHRs have complicated URL with a lot of query parameters?
 
  What XHRs?
 
 IOW, what are the cases where an XHR instance wants to use a lot o query
 params?


 Probably when speaking to a HTTP server designed to take input from an HTML
 form.
 -Darin






Re: A URL API

2010-09-21 Thread Devdatta Akhawe
On 21 September 2010 00:47, Ojan Vafai o...@chromium.org wrote:
 How about setParameter(name, value...) that takes var_args number of values?
 Alternately, it could take either a DOMString or an ArrayDOMString for the
 value. I prefer the var_args.

What happens when I do
setParameter('x','a','b','c');

and now want to add another - I will have to do weird things like
getting the parameter via getAllParameter and then append to the array
and function.call or something like that

doesn't look very nice according to me - I like the separation into 2
APIs because I think that makes the common 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 case, so I'm OK with it for making the
 common case less wordy.
 Ojan
 On Tue, Sep 21, 2010 at 4:56 PM, Adam Barth w...@adambarth.com wrote:

 Ok.  I'm sold on having an API for constructing query parameters.
 Thoughts on what it should look like?  Here's what jQuery does:

 http://api.jquery.com/jQuery.get/

 Essentially, you supply a JSON object containing the parameters.  They
 also have some magical syntax for specifying multiple 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
 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 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 Fisher da...@chromium.org wrote:
  On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith
  dhtmlkitc...@gmail.com
  wrote:
 
  On 9/20/10, Julian Reschke julian.resc...@gmx.de wrote:
   On 20.09.2010 18:56, Garrett Smith wrote:
  [...]
   Requests that don't have lot of parameters are often simple
   one-liners:
  
   url = /getShipping/?zip= + zip + pid= + pid;
  
   That's exactly the kind of code that will fail once pid and zip
   contain things you don't expecz.
  
   What XHRs have complicated URL with a lot of query parameters?
  
   What XHRs?
  
  IOW, what are the cases where an XHR instance wants to use a lot o
  query
  params?
 
 
  Probably when speaking to a HTTP server designed to take input from an
  HTML
  form.
  -Darin
 
 






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 behavior than what Location and HTMLAnchorElement
 do; they unescape various componenents. Is the benefit worth the divergence?

 As a side note, an out-of-document HTMLAnchorElement already provides most
 of the functionality of this interface. Things it can't do:
 - Resolve a relative URL against no base at all (probably not very useful
 since the interface can only represent an absolute URL).
 - Resolve against an arbitrary base (maybe you could do it awkwardly using
 base tag tricks).
 - Read or write the lastPathComponent or origin without further parsing
 (should origin really be writable? That's kind of weird...)
 - Read search parameters conveniently without parsing.

 It might be nice to provide the parts of this that make sense on
 HTMLAnchorElement and Location, then see if a new interface really pulls its
 weight.


 I idea too. I would rather extend Location to include these features, so
 they would be immediately available in links and the location object. And
 make Location into a constructor new Location(url, base)





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 want to support assigning to the
 attribute.  In particular, it doesn't seems particularly meaningful to
 assign the string null to the attribute even though that's a
 perfectly reasonable value for the attribute to return.

 3) I've added definitions for what the interface actually does.

 In response to folks who think we should add these APIs to
 HTMLAnchorElement and Location, I agree.  Currently, the draft is
 written to refer to HTML5 for the definitions of the common elements,
 but we could easily reverse that dependency or incorporate this API
 into HTML5.

 Adam





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. Cursory, dismissive and
 thoughtless replies are as inappropriate and counterproductive as
 flippant messages I'm seeing in my inbox. And I'm not about to be
 pigeonholed or scapegoated into being the bad guy here. Make sense?

 That said, Garrett's right.

 My arguments are supported by the reasons that I provided; nothing
 more, nothing less.

 Garrett





[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 wrong) summary of the attack
facebook.com loads content using the stuff after a '#' in a URL, thus
facebook.com/#profile.php loads content from facebook.com/profile.php
using XHR.
a URL like facebook.com/#evil.com/evil.php , with evil.com configured
to AccessControlAllowOrigin * could result in HTML injection.

It seems that over here facebook is a benign server that some time in
the past assumed that XHR can only be same origin, and with the
introduction of cross origin XHR is suddenly vulnerable to XSS. In
general, a client needs to 'add' stuff to its js to be safe after the
introduction 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 7, 2010 at 4:04 PM, Mark S. Miller erig...@google.com wrote:

 On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis cr...@chromium.org wrote:
 [...]

 That's unfortunate-- at least for now, that prevents servers from echoing
 the origin in the Access-Control-Allow-Origin header, so servers cannot host
 public images that don't taint canvases.  The same problem likely exists
 for other types of requests that might adopt CORS, like fonts, etc.

 Why would public images or fonts need credentials?

 Because it's undesirable to prevent the browser from sending cookies on an
 img request, and the user might have cookies for the image's site.  It's
 typical for the browser to send cookies on such requests, and those are
 considered a type of credentials by CORS.
 Charlie




 I believe the plan is to change HTML5 once CORS is somewhat more stable
 and use it for various pieces of infrastructure there. At that point we can
 change img to transmit an Origin header with an origin. We could also
 decide to change CORS and allow the combination of * and the credentials
 flag being true. I think * is not too different from echoing back the value
 of a header.


 I would second the proposal to allow * with credentials.  It seems
 roughly equivalent to echoing back the Origin header, and it would allow
 CORS to work on images and other types of requests without changes to HTML5.
 Thanks,
 Charlie



 --
     Cheers,
     --MarkM





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.

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 agents shouldn't send cookies
 at all on third party subresources, I'm ok with that, but I imagine there
 would be pushback on that sort of proposal-- it would likely affect
 compatibility with existing web sites.  I haven't gathered any data on it,
 though.
 The benefit to allowing * with credentials is that it lets CORS work with
 the existing browser request logic for images and other subresources, where
 cookies are currently sent with the request.
 Charlie


 On 7 July 2010 16:11, Charlie Reis cr...@chromium.org wrote:
 
 
  On Wed, Jul 7, 2010 at 4:04 PM, Mark S. Miller erig...@google.com
  wrote:
 
  On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis cr...@chromium.org
  wrote:
  [...]
 
  That's unfortunate-- at least for now, that prevents servers from
  echoing
  the origin in the Access-Control-Allow-Origin header, so servers
  cannot host
  public images that don't taint canvases.  The same problem likely
  exists
  for other types of requests that might adopt CORS, like fonts, etc.
 
  Why would public images or fonts need credentials?
 
  Because it's undesirable to prevent the browser from sending cookies on
  an
  img request, and the user might have cookies for the image's site.
   It's
  typical for the browser to send cookies on such requests, and those are
  considered a type of credentials by CORS.
  Charlie
 
 
 
 
  I believe the plan is to change HTML5 once CORS is somewhat more
  stable
  and use it for various pieces of infrastructure there. At that point
  we can
  change img to transmit an Origin header with an origin. We could
  also
  decide to change CORS and allow the combination of * and the
  credentials
  flag being true. I think * is not too different from echoing back the
  value
  of a header.
 
 
  I would second the proposal to allow * with credentials.  It seems
  roughly equivalent to echoing back the Origin header, and it would
  allow
  CORS to work on images and other types of requests without changes to
  HTML5.
  Thanks,
  Charlie
 
 
 
  --
      Cheers,
      --MarkM
 
 





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

2010-07-07 Thread Devdatta Akhawe
 It's not just implementation effort-- as I mentioned, it's potentially a
 compatibility question.  If you are proposing not sending cookies on any
 cross-origin images (or other potential candidates for CORS), do you have
 any data about which sites that might affect?

Its not clear to me on how 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.  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
 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.

 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 agents shouldn't send
  cookies
  at all on third party subresources, I'm ok with that, but I imagine
  there
  would be pushback on that sort of proposal-- it would likely affect
  compatibility with existing web sites.  I haven't gathered any data on
  it,
  though.
  The benefit to allowing * with credentials is that it lets CORS work
  with
  the existing browser request logic for images and other subresources,
  where
  cookies are currently sent with the request.
  Charlie
 
 
  On 7 July 2010 16:11, Charlie Reis cr...@chromium.org wrote:
  
  
   On Wed, Jul 7, 2010 at 4:04 PM, Mark S. Miller erig...@google.com
   wrote:
  
   On Wed, Jul 7, 2010 at 1:09 PM, Charlie Reis cr...@chromium.org
   wrote:
   [...]
  
   That's unfortunate-- at least for now, that prevents servers from
   echoing
   the origin in the Access-Control-Allow-Origin header, so servers
   cannot host
   public images that don't taint canvases.  The same problem likely
   exists
   for other types of requests that might adopt CORS, like fonts, etc.
  
   Why would public images or fonts need credentials?
  
   Because it's undesirable to prevent the browser from sending cookies
   on
   an
   img request, and the user might have cookies for the image's site.
    It's
   typical for the browser to send cookies on such requests, and those
   are
   considered a type of credentials by CORS.
   Charlie
  
  
  
  
   I believe the plan is to change HTML5 once CORS is somewhat more
   stable
   and use it for various pieces of infrastructure there. At that
   point
   we can
   change img to transmit an Origin header with an origin. We could
   also
   decide to change CORS and allow the combination of * and the
   credentials
   flag being true. I think * is not too different from echoing back
   the
   value
   of a header.
  
  
   I would second the proposal to allow * with credentials.  It seems
   roughly equivalent to echoing back the Origin header, and it would
   allow
   CORS to work on images and other types of requests without changes
   to
   HTML5.
   Thanks,
   Charlie
  
  
  
   --
       Cheers,
       --MarkM