Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

[Luke Crouch]

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-implemented extensions to 
> create similar issues, and I don't think this change significantly 
> increases the risk. It may even mitigate it in some cases, since the 
> alternative of loading or evaling third-party scripts into the content 
> script sandbox would give them direct access to elevated privileges.
> 
> Per the CSP spec, those injections are assumed to be at the user's 
> behest, and should therefore take priority over the page author's 
> preferences.

+1 on this part.

As an add-on author, when I need to inject something the page CSP doesn't 
allow, I can already over-write the page CSP to allow it. But that feels more 
dangerous!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Argument alignment

[Gregory Szorc]

On Wed, Sep 27, 2017 at 11:58 AM, Gregory Szorc  wrote:

> On Tue, Sep 26, 2017 at 6:45 PM, Nicholas Hurley 
> wrote:
>
>> So I'm going to chime in on a formatting discussion for probably the
>> second
>> time in my life as a mozillian. (It's apparently that important to me.)
>>
>> On Tue, Sep 26, 2017 at 9:25 AM, Mats Palmgren  wrote:
>>
>> > 2. touching more lines than necessary when adding/removing params,
>> >making it harder to follow blame links
>> >
>> > Judging from my personal use of blame links, it's very rare that
>> > I want to find when a specific param was added to a signature.
>> > This is also something that tooling could solve (skip blame on
>> > lines that differ only by whitespace).
>> >
>>
>> This is probably half the time I annotate something (I refuse to use the b
>> word here). Use cases differ, and for a lot of what I find myself doing,
>> this would make it demonstrably worse.
>>
>
> Mercurial and Git both support a -w argument to ignore whitespace with
> annotate/blame.
>
> In addition, modern versions of Mercurial have `hg annotate --skip
> ` which allows you to specify a revset used to select revisions to
> skip over when annotating. The Chromium developer tools have
> git-hyper-blame (https://commondatastorage.googleapis.com/chrome-infra-
> docs/flat/depot_tools/docs/html/git-hyper-blame.html), which is similar.
>
> What both tools seem to lack is the ability to toggle whitespace and
> revision skipping via the web interface. This can certainly be implemented.
> Also, revision skipping is not an exact science and the results may not
> match expectations, so it shouldn't be seen as a cure-all.
>

Quick update: the next release of Mercurial (presumably 4.4) will have HTML
elements to control whitespace handling of annotate in the web interface.

Shoring up Mercurial's revision skipping in annotate was also discussed at
the Mercurial developer sprint this weekend. Someone is literally sitting
an arm's length away hacking on it as I type this.


>
>
>>
>>
>> > I think improved readability trumps all of the minor issues above.
>> >
>>
>> Readability is (to an extent) in the eye of the beholder. For example, I
>> have a difficult time following long gaps in things... so vertically
>> aligned parameters, where one of them has an extra-long type name (which
>> also seems to happen a lot in things I'm working with) become exceedingly
>> difficult for me to match type and name quickly. (Yes, there are editor
>> tricks to help with this, and yes I use them, but they still only get me
>> so
>> far when I'm quickly scanning code).
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform