You can tackle bits of this problem by assigning different subdomains
either per-permission set or per-client.
AFAIU, the settings should be stored independently.
With more and more permissions coming to the web, the numbers of
combinations might grow exponentially though.
On 27.04.2015 12:50,
Hi,
Thank you for your feedback. Please see the archives for previous
iterations of this discussion, e.g.
https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0084.html
(and click next in thread).
On 29.01.2015 21:04, LOUIFI, Bruno wrote:
Hi,
I am really disappointed when I saw in
On 02.10.2014 21:34, Jonas Sicking wrote:
On Thu, Oct 2, 2014 at 11:31 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Oct 2, 2014 at 8:27 PM, John Mellor joh...@google.com wrote:
This seems to either require a somewhat stronger trust signal from the user,
or a very easy mechanism for
On 04.06.2014 11:00, Anne van Kesteren wrote:
On Tue, Jun 3, 2014 at 7:20 PM, Oda, Terri terri@intel.com wrote:
Perhaps it would make sense to also require explicit allowing of imports via
CSP? Scripts are allowed when no CSP is provided for historical
compatibility so you'd need to make
On 12.05.2014 18:41, Jonas Sicking wrote:
(new URL(url)).origin should work, no?
It does not work for blob URIs in Firefox.
On 09.05.2014 23:29, Arun Ranganathan wrote:
..
So this is problematic: we don’t have a common syntax on the web, and
even implementations which share code don’t do it exactly the same. Of
course, blob: URLs aren’t supposed to be human readable, or really
viewed by the developer. But not
On 03.02.2014 21:58, Hajime Morrita wrote:
Parser-made script means the script tags and its contents that are
written in HTML bytestream, not given by DOM mutation calls from
scripts. As HTML Imports doesn't allow document.write(), it seems safe
to assume that these scripts are statically
On 31.01.2014 06:43, Hajime Morrita wrote:
Generally I prefer master-CSP model than the own CSP model due to its
simplicity but I agree that unsafe-script kills the conciseness of Imports.
To make inline scripts work with imports, we might want another CSP
directive like safe-script, which
On 30.01.2014 19:53, Scott Miles wrote: I'm hoping there are some
constraints we can impose on imports to allow
them to contain inline scripts to exist under CSP.
That's interesting. Wouldn't this violate the CSP spec?
Imported scripts still have access to the same origin as the master
document,
On 10.01.2014 03:52, Hajime Morrita wrote:
Hi Frederik,
Thanks for bringing it up!
As you pointed out, CSP of imported documents essentially extends the
set of allowed domains. I thought I was useful for component authors to
specify their own domains, like one of their own CDN.
Well the
On 10.01.2014 14:51, Nick Krempel wrote:
To clarify: your example is supposed to be an attack on imported.com
http://imported.com, not example.com http://example.com (we can
assume the attacker has control over example.com http://example.com)?
Nick
Yes, imagine an XSS vulnerability on
Hi,
I have subscribed to this list because my colleague Gabor (CC) and I
found a few issues with Content Security Policies applied to HTML imports.
The current draft
(http://w3c.github.io/webcomponents/spec/imports/#imports-and-csp, Jan
9) suggests that import loading is restricted through a
12 matches
Mail list logo
