On 02.10.2017 18:43, Anne van Kesteren wrote:
> On Mon, Oct 2, 2017 at 6:09 PM, Boris Zbarsky wrote:
>> On 10/2/17 12:03 PM, Daniel Veditz wrote:
>>> Fair enough. Could we propose improvements to the APIs that would make
>>> them more usable? For example an object argument to createElement() tha
On 02.10.2017 18:03, Daniel Veditz wrote:
> Fair enough. Could we propose improvements to the APIs that would make
> them more usable? For example an object argument to createElement() that
> contained attribute/value pairs?
>
> var div = document.createElement("div", null, {"id":"foo",
> "cla
On Wed, Oct 04, 2017 at 12:42:22AM -0400, Boris Zbarsky wrote:
On 10/2/17 9:50 PM, Kris Maglione wrote:
For the pretty simple micro-benchmark below, here are the
in-document and out-of-document numbers for three runs without the
subject principal:
Sorry, I should have been clearer: I meant nu
On 10/2/17 9:50 PM, Kris Maglione wrote:
For the pretty simple micro-benchmark below, here are the in-document
and out-of-document numbers for three runs without the subject principal:
Sorry, I should have been clearer: I meant numbers for "inserted into
the document" and "not inserted into th
On Mon, Oct 02, 2017 at 09:07:09PM -0400, Boris Zbarsky wrote:
On 10/2/17 5:35 PM, Kris Maglione wrote:
So far it doesn't look like there's any significant difference on
any talos test from adding [NeedsCallerPrincipal] to
setAttribute/setAttributeNS/Attr.value,
OK. That's a minimum bar, obv
On 10/2/17 5:35 PM, Kris Maglione wrote:
So far it doesn't look like there's any significant difference on any
talos test from adding [NeedsCallerPrincipal] to
setAttribute/setAttributeNS/Attr.value,
OK. That's a minimum bar, obviously, but I would still like us to
measure what the (presumab
On Mon, Oct 02, 2017 at 11:39:21AM -0700, Kris Maglione wrote:
On Mon, Oct 02, 2017 at 11:13:20AM -0400, Boris Zbarsky wrote:
Passing along a JSContext would work. We could have something like
"null means no scripted caller, otherwise caller's compartment is
the part that matters". This relie
On Sun, Oct 01, 2017 at 12:54:26PM -0700, Luke Crouch wrote:
On Friday, September 29, 2017 at 2:32:57 PM UTC-5, Kris Maglione wrote:
Security & privacy concerns:
This change will allow extensions to inject content into sites which can
(and probably will) cause security and privacy issues. Howev
On Mon, Oct 02, 2017 at 11:13:20AM -0400, Boris Zbarsky wrote:
Passing along a JSContext would work. We could have something like
"null means no scripted caller, otherwise caller's compartment is the
part that matters". This relies on no one on the setattr path messing
with the compartment, b
On Mon, Oct 02, 2017 at 07:50:41AM -0700, Daniel Veditz wrote:
On Fri, Sep 29, 2017 at 8:33 PM, Boris Zbarsky wrote:
On 9/29/17 3:32 PM, Kris Maglione wrote:
For instance, the following should all capture the caller principal for
the `src` URL at call time:
document.write(`http://exampl
On Mon, Oct 2, 2017 at 6:09 PM, Boris Zbarsky wrote:
> On 10/2/17 12:03 PM, Daniel Veditz wrote:
>> Fair enough. Could we propose improvements to the APIs that would make
>> them more usable? For example an object argument to createElement() that
>> contained attribute/value pairs?
>
> This has de
On 10/2/17 12:03 PM, Daniel Veditz wrote:
Fair enough. Could we propose improvements to the APIs that would make
them more usable? For example an object argument to createElement() that
contained attribute/value pairs?
This has definitely been proposed before. Worth checking with Anne to
se
On Mon, Oct 2, 2017 at 8:17 AM, Boris Zbarsky wrote:
> The fact is, direct DOM manipulation with no parser involved is really
> annoying to use.
>
Fair enough. Could we propose improvements to the APIs that would make
them more usable? For example an object argument to createElement() that
con
On 10/2/17 10:50 AM, Daniel Veditz wrote:
As long as direct DOM manipulation works, and is easier
than overwriting (or removing) the page's CSP, can't we just encourage
people to use that mechanism?
The fact is, direct DOM manipulation with no parser involved is really
annoying to use. Compar
On 9/30/17 12:19 AM, Kris Maglione wrote:
I still haven't settled on the details, but I it will probably have to
involve capturing the caller principal from SetAttr hooks. Which would
involve either changing that machinery to pass along a JS context when
invoked by a scripted caller, or using s
On Fri, Sep 29, 2017 at 8:33 PM, Boris Zbarsky wrote:
> On 9/29/17 3:32 PM, Kris Maglione wrote:
>
>> For instance, the following should all capture the caller principal for
>> the `src` URL at call time:
>>
>> document.write(`http://example.com/favicon.ico";>`);
>> div.innerHTML = `http:
On Friday, September 29, 2017 at 2:32:57 PM UTC-5, Kris Maglione wrote:
> Security & privacy concerns:
>
> This change will allow extensions to inject content into sites which can
> (and probably will) cause security and privacy issues. However, it's
> already quite easy for malicious or badly-
On Fri, Sep 29, 2017 at 11:33:08PM -0400, Boris Zbarsky wrote:
On 9/29/17 3:32 PM, Kris Maglione wrote:
For instance, the following should all capture the caller principal
for the `src` URL at call time:
document.write(`http://example.com/favicon.ico";>`);
div.innerHTML = `http://example
On 9/29/17 3:32 PM, Kris Maglione wrote:
For instance, the following should all capture the
caller principal for the `src` URL at call time:
document.write(`http://example.com/favicon.ico";>`);
div.innerHTML = `http://example.com/favicon.ico";>`;
img.setAttribute("src", "http://exam
Summary:
All content injected into web content pages is currently subject to the
same Content Security Policy, regardless of who injected it. For
privileged callers, such as extension content scripts, this means that
some functionality can behave erratically, depending on the page they're
run
20 matches
Mail list logo
