On Sun, 15 Mar 2009 22:09:16 +0100, Hans Schmucker
hansschmuc...@gmail.com wrote:
Sorry, I didn't mean to make it sound like an attack, I really just
meant to say that this (for me) belongs more into HTML5, which deals
primarily with the user agent, than into the CORS spec, which more or
less
So, where would you put it? The problem for me is that there's no
logical grouping of elements that load offsite resources (like img,
script, link, video, ...) where one could add the necessary
attributes. All off them descend directly from HTMLElement. So there
would be two routes: Either
On Mon, 16 Mar 2009 14:07:38 +0100, Hans Schmucker
hansschmuc...@gmail.com wrote:
Why does the DOM need to get involved here?
Well it should be involved, although I don't think we can actually do
it. I think the CORS header response should be stored and be available
the same way across all
On Mon, Mar 16, 2009 at 2:43 PM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 16 Mar 2009 14:07:38 +0100, Hans Schmucker hansschmuc...@gmail.com
wrote:
Why does the DOM need to get involved here?
Well it should be involved, although I don't think we can actually do
it. I think the CORS
On Sat, Mar 14, 2009 at 3:11 PM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 13 Mar 2009 23:53:36 -, Hans Schmucker hansschmuc...@gmail.com
wrote:
Question is: what would be the best way to fix it? Of course the spec
could be changed for video and image, but wouldn't it be simpler
On Sun, 15 Mar 2009 20:45:17 +0100, Hans Schmucker
hansschmuc...@gmail.com wrote:
Thank you Anne, but I think this has to be dealt with primarily inside
the HTML5 spec.
Yes, hence me using the word aside...
Anyway, ...
The Access Control spec is already pretty clear on how
things are
Thank you Anne, but I think this has to be dealt with primarily inside
the HTML5 spec.
Yes, hence me using the word aside...
Sorry, I didn't mean to make it sound like an attack, I really just
meant to say that this (for me) belongs more into HTML5, which deals
primarily with the user agent,
On Sat, Mar 14, 2009 at 12:53 PM, Hans Schmucker hansschmuc...@gmail.comwrote:
Question is: what would be the best way to fix it? Of course the spec
could be changed for video and image, but wouldn't it be simpler to
update the defintion of origins to include patterns that can represent
allow
Doesn't that kind of defeat the purpose of access control to have fine
grained control over who is allowed access? Public resources are a
quick fix for most scenarios that I can imagine, but I think using
patterns would appear more consistent and logical to most users. It
may not be terribly
On Fri, 13 Mar 2009 23:53:36 -, Hans Schmucker
hansschmuc...@gmail.com wrote:
Question is: what would be the best way to fix it? Of course the spec
could be changed for video and image, but wouldn't it be simpler to
update the defintion of origins to include patterns that can represent
I think this is an excellent point. I've been playing with the Chroma-Key
replacement trick demonstrated in FireFox 3.1b3:
https://developer.mozilla.org/samples/video/chroma-key/index.xhtml
https://developer.mozilla.org/En/Manipulating_video_using_canvas
For my own experiments, I grabbed a
On Fri, Mar 13, 2009 at 9:24 AM, Hans Schmucker hansschmuc...@gmail.com wrote:
This problem recently became apparent while trying to process a public
video on tinyvid.tv:
In article 4.8.11.3 Security with canvas elements, the origin-clean
flag is only set depending on an element's origin.
Question is: what would be the best way to fix it? Of course the spec
could be changed for video and image, but wouldn't it be simpler to
update the defintion of origins to include patterns that can represent
allow rules?
13 matches
Mail list logo
