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
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",
>
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
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
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,
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
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
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.
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,
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:
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
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
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
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.
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
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;>`);
>>
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
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 =
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",
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
20 matches
Mail list logo