Re: Proposed W3C Charter: Web Payments Working Group

[Tantek Çelik]

On Fri, Feb 2, 2018 at 11:40 AM, Peter Saint-Andre  wrote:
> On 2/2/18 11:57 AM, Anne van Kesteren wrote:
>> On Fri, Feb 2, 2018 at 7:49 PM, Peter Saint-Andre  
>> wrote:
>>> What you have seems fine (modulo s/Web Auth/Web Authentcation/). The
>>> first comment is just housekeeping, whereas the second comment is
>>> substantive and concerning. Phrasing it as a formal objection might
>>> result in greater attention to the seemingly significant overlap. I'd be
>>> curious what other folks here think (Marcos, Tantek, Anne, etc.).
>>
>> I'd lean towards objecting as otherwise you might get a group of
>> people with lots of different objectives and nobody really getting
>> what they want.
>
> That's where we're heading at the moment.

Given that "Payments" has some history with that in the early days
(different groups trying to pull things in different directions), I
think that's a real threat that needs addressing up front.


>> (Both 1.2 and 1.3 are pretty concerning, and 1.2
>> sounds like the thing that made the Web Crypto effort somewhat
>> dysfunctional.)
>
> Agreed.

Also agreed (that we should make this an FO right?).

Thanks for your analysis on this Peter. That's exactly the kind of
precise feedback we need to give to help present a good case for an
objection (and the changes to address it).

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New prefs parser has landed

[Boris Zbarsky]

On 2/2/18 4:57 PM, Nicholas Nethercote wrote:

It shouldn't be too hard, because the prefs grammar is very simple. I would
just implement "panic mode" recovery, which scans for a synchronizing token
like ';' or 'pref' and then continues from there.


OK.  I think that would address my concerns, for sure.

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New prefs parser has landed

[Nicholas Nethercote]

On Sat, Feb 3, 2018 at 12:42 AM, Boris Zbarsky  wrote:

>
> Perhaps I should implement error recovery, so that ill-formed prefs won't
>> cause subsequent prefs to be lost.
>>
>
> You mean pick up parsing again after hitting an error?   That sounds
> complicated...
>

It shouldn't be too hard, because the prefs grammar is very simple. I would
just implement "panic mode" recovery, which scans for a synchronizing token
like ';' or 'pref' and then continues from there. It's not foolproof but
works well in many cases.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Array.prototype.values

[Emilio Cobos Álvarez]

On 02/02/2018 03:27 PM, Andrew Overholt wrote:
> On Fri, Feb 2, 2018 at 8:45 AM, Tom Schuster  > wrote:
> 
> Chrome seems to
> want to add a kill pref for this,  from my experience more difficult
> for us with the way we define methods in SpiderMonkey. Should that be
> a requirement for shipping?
> 
> 
> If it's not too difficult it does make it a lot easier to fix things if
> it causes major breakage. I think we can even do a pref flip without
> shipping an update which is pretty nice.
> 
> Is there a way to do per-site pref changes? Did we do this for Stylo,
> Emilio?

We did, but it required a fair amount of machinery. The code for the
stylo domain blocklist was removed very recently in bug 1426223.

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Payments Working Group

[Peter Saint-Andre]

On 2/2/18 11:57 AM, Anne van Kesteren wrote:
> On Fri, Feb 2, 2018 at 7:49 PM, Peter Saint-Andre  wrote:
>> What you have seems fine (modulo s/Web Auth/Web Authentcation/). The
>> first comment is just housekeeping, whereas the second comment is
>> substantive and concerning. Phrasing it as a formal objection might
>> result in greater attention to the seemingly significant overlap. I'd be
>> curious what other folks here think (Marcos, Tantek, Anne, etc.).
> 
> I'd lean towards objecting as otherwise you might get a group of
> people with lots of different objectives and nobody really getting
> what they want. 

That's where we're heading at the moment.

> (Both 1.2 and 1.3 are pretty concerning, and 1.2
> sounds like the thing that made the Web Crypto effort somewhat
> dysfunctional.)

Agreed.

Peter




signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Payments Working Group

[Anne van Kesteren]

On Fri, Feb 2, 2018 at 7:49 PM, Peter Saint-Andre  wrote:
> What you have seems fine (modulo s/Web Auth/Web Authentcation/). The
> first comment is just housekeeping, whereas the second comment is
> substantive and concerning. Phrasing it as a formal objection might
> result in greater attention to the seemingly significant overlap. I'd be
> curious what other folks here think (Marcos, Tantek, Anne, etc.).

I'd lean towards objecting as otherwise you might get a group of
people with lots of different objectives and nobody really getting
what they want. (Both 1.2 and 1.3 are pretty concerning, and 1.2
sounds like the thing that made the Web Crypto effort somewhat
dysfunctional.)


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster gecko builds with IceCC on Mac and Linux

[Jean-Yves Avenard]

Hi

> On 17 Jan 2018, at 12:38 am, Gregory Szorc  wrote:
> 
> On an EC2 c5.17xlarge (36+36 CPUs) running Ubuntu 17.10 and using Clang 5.0, 
> 9be7249e74fd does a clobber but configured `mach build` in 7:34. Rust is very 
> obviously the long pole in this build, with C++ compilation (not linking) 
> completing in ~2 minutes.
> 
> If I enable sccache for just Rust by setting "mk_add_options "export 
> RUSTC_WRAPPER=sccache" in my mozconfig, a clobber build with populated cache 
> for Rust completes in 3:18. And Rust is still the long pole - although only 
> by a few seconds. It's worth noting that CPU time for this build remains in 
> the same ballpark. But overall CPU utilization increases from ~28% to ~64%. 
> There's still work to do improving the efficiency of the overall build 
> system. But these are mostly in parts only touched by clobber builds. If you 
> do `mach build binaries` after touching compiled code, our CPU utilization is 
> terrific.
> 
> From a build system perspective, C/C++ scales up to dozens of cores just fine 
> (it's been this way for a few years). Rust is becoming a longer and longer 
> long tail (assuming you have enough CPU cores that the vast amount of C/C++ 
> completes before Rust does).

After playing with the iMac Pro and loving its performance (though I’ve 
returned it now)

I was thinking of testing this configuration

Intel i9-7980XE
Asus Prime X299-Deluxe
Samsung 960 Pro SSD
G.Skill F4-3200OC16Q-32GTZR x 2 (allowing 64GB in quad channels)
Corsair AX1200i PSU
Corsair H100i water cooloer
Cooler Master Silencio 652S

Aim is for the fastest and most silent PC (if such thing exists)
The price on Amazon is 4400 euros which is well below the iMac Pro cost (less 
than half for similar core count) or the Lenovo P710.

The choice of the motherboard is that there’s successful report on the 
hackintosh forum to run macOS High Sierra (though no wifi support)

Any ideas when the updated Lenovo P710 will come out?

Anandtech had a nice article about the i9-7980EX in regards to clock speed 
according to the number of core in use… It clearly shows that base frequency 
matters very little as the turbo frequencies almost make them all equal.

JY

smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Payments Working Group

[Peter Saint-Andre]

On 2/2/18 1:25 AM, L. David Baron wrote:
> On Thursday 2018-01-18 19:05 -0700, Peter Saint-Andre wrote:
>> On 1/8/18 10:17 PM, mcace...@mozilla.com wrote:
>>>
>>>
 On Jan 9, 2018, at 4:29 AM, L. David Baron  wrote:

 Please reply to this thread if you think there's something we should
 say as part of this charter review, or if you think we should
 support or oppose it.  (Given our involvement, we should almost
 certainly say something.)
>>>
>>> Fyi, I sent feedback before TPAC (all of which was addressed, including 
>>> dropping HTTP Payments, which can be addressed by the Fetch API). I’m 
>>> personally supportive of current direction and the reduced work items on 
>>> which the group is focused on. This includes incrementally supporting the 
>>> whole gamut of payment systems: from credit cards, tokenized payments, to 
>>> crypto currencies. 
>>>
>>> I’d personally like to see Mozilla continue to support the working group, 
>>> particularly as we continue to open up (and see continued innovation in) 
>>> the payments ecosystems over the next 5-10 years.
>>
>> Overall I agree with Marcos.
>>
>> There are two aspects of the charter that could use some clarification.
>>
>> §1.2 states that the WG might develop "an encryption module for one or
>> more payment methods"; however, WG members do not necessarily have the
>> expertise to do this work. At the least, it would be helpful to mention
>> the parties (e.g., Web Cryptography WG or Web Application Security WG)
>> that will be consulted to ensure the security of any such encryption module.
>>
>> §1.3 suggests that work might happen around "the relationship of Payment
>> Request API to EMVCo 3D Secure" (and in fact a 3DS Task Force has been
>> spun up). My very early impression is that such work might involve
>> two-factor authentication methods that do not use a standardized
>> technology such as what's being developed within the Web Authentication
>> Working Group. If the outcome is that browsers need to support both a
>> 3DS method and a Web Auth method, I would be concerned about duplication
>> of effort, architectural confusion, and differential security profiles.
>> I'd prefer it if we could nudge the WG and W3C in the direction of
>> settling on one method for user identification and authentication.
> 
> So how does the following response to the charter sound:
> 
> (X)  suggests changes to this Charter, but supports the proposal
>  whether or not the changes are adopted (your details below).
> 
> Comments (which are just a slightly reworded version of Peter's
> above):
> 
> §1.2 states that the WG might develop "an encryption module for one or
> more payment methods"; however, WG members do not necessarily have the
> expertise to do this work. At the least, it would be helpful to mention
> the parties (e.g., Web Cryptography WG or Web Application Security WG)
> that will be consulted to ensure the security of any such encryption module.
> 
> §1.3 suggests that work might happen around "the relationship of Payment
> Request API to EMVCo 3D Secure" (and in fact a 3DS Task Force has been
> spun up). Our very early impression is that such work might involve
> two-factor authentication methods that do not use a standardized
> technology such as what's being developed within the Web Authentication
> Working Group. If the outcome is that browsers need to support both a
> 3DS method and a Web Auth method, we would be concerned about duplication
> of effort, architectural confusion, and differential security profiles.
> We'd prefer that these W3C working groups move in the direction of
> settling on one method for user identification and authentication.
> 
> 
> 
> Or do you think one or both of these comments should constitute a
> formal objection?

What you have seems fine (modulo s/Web Auth/Web Authentcation/). The
first comment is just housekeeping, whereas the second comment is
substantive and concerning. Phrasing it as a formal objection might
result in greater attention to the seemingly significant overlap. I'd be
curious what other folks here think (Marcos, Tantek, Anne, etc.).

Peter




signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Array.prototype.values

[Tom Schuster]

I talked to   Jan de Mooij and it's feasible to add a pref for this,
so we are definitely going to do this.

Array.prototype.values has always been enabled on Nightly. Based on
where the breakage occurred, internal company webpages, I would not
expect EARLY_BETA_OR_EARLIER to shake out any additional problems.

On Fri, Feb 2, 2018 at 4:17 PM, Mike Taylor  wrote:
> On Feb 2, 2018, at 7:45 AM, Tom Schuster  wrote:
>> Any additional ideas how to mitigate the risk here? Chrome seems to
>> want to add a kill pref for this,  from my experience more difficult
>> for us with the way we define methods in SpiderMonkey. Should that be
>> a requirement for shipping?
>
> Add a pref enabling it for EARLY_BETA_OR_EARLIER, and false otherwise, and 
> let’s see what Nightly/Beta shakes out for a few releases. Then we have time 
> to attempt outreach or other such hacks before burning our release users.
>
> --
> Mike Taylor
> Web Compat, Mozilla
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Array.prototype.values

[Mike Taylor]

On Feb 2, 2018, at 7:45 AM, Tom Schuster  wrote:
> Any additional ideas how to mitigate the risk here? Chrome seems to
> want to add a kill pref for this,  from my experience more difficult
> for us with the way we define methods in SpiderMonkey. Should that be
> a requirement for shipping?

Add a pref enabling it for EARLY_BETA_OR_EARLIER, and false otherwise, and 
let’s see what Nightly/Beta shakes out for a few releases. Then we have time to 
attempt outreach or other such hacks before burning our release users.

--
Mike Taylor
Web Compat, Mozilla


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Unship: Application Cache over Insecure Contexts

[Jonathan Kingston]

This has now landed into central and appears to be sticking:
https://www.fxsitecompat.com/en-CA/docs/2018/support-for-application-cache-on-insecure-sites-has-been-deprecated/

I have filed a follow up bug to remove "OfflineResourceList" interface we
use: https://bugzilla.mozilla.org/show_bug.cgi?id=1435261

Also Anne filed a bug on the standard as it appears other browsers are
interested now in doing the same: https://github.com/whatwg/html/issues/3440

This also means we can move the tests into Web Platform Tests to ensure all
browsers implement the same.


On Fri, Jan 19, 2018 at 6:55 PM, Jonathan Kingston  wrote:

> > Its been suggested before that we could leave the applicationCache
> global in place, but just make it do nothing in insecure contexts.
>
> I did see this idea of keeping the applicationCache global in one of the
> bugs, I think if we have breakage we could try this as a follow up piece of
> work along with other approaches like expiring the cache more often.
>
> On Fri, Jan 19, 2018 at 5:47 PM, Ben Kelly  wrote:
>
>> On Fri, Jan 19, 2018 at 12:26 PM, Mike Taylor  wrote:
>>
>>> > When the pref is set to false the API will be removed:
>>> >
>>> >   -
>>> >
>>> >   window.applicationCache will be removed
>>> >   -
>>> >
>>> >   The cache service Firefox implements for AppCache will be disabled
>>> over
>>> >   Insecure Contexts
>>> >
>>> >
>>> > When the pref is set to true the code will produce an additional
>>> developer
>>> > console warning about the removal timeline.
>>> >
>>> > In Nightly and Early beta for 60; the pref will be set to false
>>> removing
>>> > the API.
>>>
>>> It will be interesting to see if we get reports of pages (that don’t
>>> feature test) throwing with the missing applicationCache global. A few
>>> years (and laptops) ago I had done some site corpus grepping — I’ll see if
>>> I can find any of that data.
>>>
>>
>> Its been suggested before that we could leave the applicationCache global
>> in place, but just make it do nothing in insecure contexts.
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Array.prototype.values

[Lars Hansen]

On Fri, Feb 2, 2018 at 2:45 PM, Tom Schuster  wrote:

> Any additional ideas how to mitigate the risk here? Chrome seems to
> want to add a kill pref for this,  from my experience more difficult
> for us with the way we define methods in SpiderMonkey. Should that be
> a requirement for shipping?
>

​Don't we need that type of availability mechanism to support
HTTPS-everywhere anyway?  "All new features..."

--lars
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Array.prototype.values

[Boris Zbarsky]

On 2/2/18 8:45 AM, Tom Schuster wrote:

Should that be a requirement for shipping?


Imo, yes, given the history of trying to ship this in the past (had to 
be backed out for web compat fail twice, etc).


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Array.prototype.values

[Andrew Overholt]

On Fri, Feb 2, 2018 at 8:45 AM, Tom Schuster  wrote:

> Chrome seems to
> want to add a kill pref for this,  from my experience more difficult
> for us with the way we define methods in SpiderMonkey. Should that be
> a requirement for shipping?
>

If it's not too difficult it does make it a lot easier to fix things if it
causes major breakage. I think we can even do a pref flip without shipping
an update which is pretty nice.

Is there a way to do per-site pref changes? Did we do this for Stylo,
Emilio?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ci, Cr, Cc, and Cu are now automatically defined in all chrome scopes

[Eric Shepherd (Sheppy)]

That's... brilliant. How did it take this many years for that to come up? :)

Sheppy

On Thu, Feb 1, 2018 at 5:11 PM, Andrew McCreight 
wrote:

> Bug 767640 just merged to mozilla-central. This patch makes it so that Ci,
> Cr, Cc, and Cu are automatically defined in any chrome scope that has a
> Components object. Rejoice, because you no longer need to add "var Ci =
> Components.interfaces" into every file.
>
> I have a followup bug, bug 1432992, that removes almost all of the existing
> definitions of these variables.
>
> Andrew
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New prefs parser has landed

[David Teller]

Pretty complicated in the general case but might be simple in the case
of number overflow.

Also, while we shouldn't depend on the UI in libpref, could we send some
kind of event or observer notification that the UI could use to display
a detailed error message? It would be a shame if Firefox was broken and
impossible-to-diagnose because of a number overflow, for instance.

On 02/02/2018 14:42, Boris Zbarsky wrote:
> You mean pick up parsing again after hitting an error?   That sounds
> complicated...
> 
> -Boris
> ___
> 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

Intent to ship: Array.prototype.values

[Tom Schuster]

We already tried to ship Array.prototype.values before in Firefox 48,
but this broke
Microsoft Dynamics CRM 2011
(https://bugzilla.mozilla.org/show_bug.cgi?id=1299593). We are however
aware this might have caused other breakages as well.

The compatibility risk for this change is high.
However Chrome is going to try shipping this again (third time!)
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/yX4U__z67xo

Edge and Safari already ship this feature.

Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1420101

Any additional ideas how to mitigate the risk here? Chrome seems to
want to add a kill pref for this,  from my experience more difficult
for us with the way we define methods in SpiderMonkey. Should that be
a requirement for shipping?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New prefs parser has landed

[Boris Zbarsky]

On 2/1/18 10:27 PM, Nicholas Nethercote wrote:

On Fri, Feb 2, 2018 at 12:50 PM, Boris Zbarsky  wrote:

OK.  I assume we've double-checked that?  And that this was the case all
along, for prefs extensions or about:config might have set in the past?
(Especially the no-embedded-null thing.)



I don't know what you mean by "prefs extensions".


"Prefs extensions might have set".  If anything set via our pref APIs 
was fine, good.



Perhaps I should implement error recovery, so that ill-formed prefs won't
cause subsequent prefs to be lost.


You mean pick up parsing again after hitting an error?   That sounds 
complicated...


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ci, Cr, Cc, and Cu are now automatically defined in all chrome scopes

[Ted Mielczarek]

On Thu, Feb 1, 2018, at 5:11 PM, Andrew McCreight wrote:
> Bug 767640 just merged to mozilla-central. This patch makes it so that Ci,
> Cr, Cc, and Cu are automatically defined in any chrome scope that has a
> Components object. Rejoice, because you no longer need to add "var Ci =
> Components.interfaces" into every file.
> 
> I have a followup bug, bug 1432992, that removes almost all of the existing
> definitions of these variables.

Nice! I can't believe it took this long for someone to realize this was a good 
idea. :)

-Ted
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Changes to JSM import APIs (or, Death to Cu.import)

[Kris Maglione]

On Fri, Feb 02, 2018 at 10:25:17AM +0100, Marco Bonardo wrote:

Hi Kris, this change is awesome.

Is it ok to continue use defineLazyModuleGetters (plural), since it
internally now uses chromeUtils.defineModuleGetter? Any downsides?


It's probably fine for now.

There is a downside, though, when you call it from outside a JSM or 
component. In that case, XPCOMUtils.jsm gets a cross-compartment wrapper 
for the object you're defining the getters on, which means the getter 
property itself is defined on the original object as a cross-compartment 
wrapper, and the whole process requires jumping back and forth across 
compartment boundaries several times.


That was one of the reasons XPCOMUtils.defineLazyModuleGetter was 
expensive to begin with. And it's possible that the extra overhead of 
that outweighs the better JIT optimization of the loop. I won't be sure 
until I have time to profile.



On Fri, Feb 2, 2018 at 7:48 AM, Ed Lee  wrote:

Great to see these types of broad changes getting wins, so if there's
a good way to keep up to date and ahead of these types of incoming
changes, that would be great. I learned of these changes from this
week's biweekly Firefox meeting the morning that they were already
inbound. Activity Stream is still in the process of getting automation
passing with these changes, but I don't think we should over-rotate as
this is a pretty unique type of change to our special development
process.

On Thu, Feb 1, 2018 at 10:01 PM, Kris Maglione  wrote:

a new ESLint rule has been added to prevent new instances.

In particular, eslint-plugin-mozilla required changes to support this
new way of adding globals, and Standard8 was able to publish the new
version within a day of the changes breaking
outside-of-mozilla-central repositories that were touched by the
automatic rewrite and have dependencies on the plugin. I believe for
this particular change, the eslint-plugin-mozilla additions could have
been published sooner (except for the part of turning the rule on by
default).

Separate from that, Activity Stream has JSMs that get converted to
commonjs for testing and esmodules for building (as an intermediary
step to combine and optimize with our other esmodules for export to
mozilla-central). These particular changes broke our tooling to do
those conversions, but it's relatively straightforward to fix up. As I
mentioned earlier, probably nothing really major to change in terms of
process because of this, so mostly just making a note of this as a
potential type of breakage that could happen again in the future.

Ed Lee

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: HTML injection in chrome documents is now automatically sanitized

[Gijs Kruitbosch]

FWIW, if you're running into this with the usecase "I have a localized 
string that needs to have links (or other markup) in it" and were 
formerly using getFormattedString combined with innerHTML, we now have a 
utility method that can help a little bit. Rather than hand-rolling 
splitting the string etc., on nightly you can use 
BrowserUtils.getLocalizedFragment as a replacement. Given a document, 
raw string (fetch using getString / GetStringFromName instead of the 
"formatted" APIs), and DOM nodes to insert, it'll produce a 
DocumentFragment that you can appendChild/insertBefore etc., take care 
of splitting your strings for you, and will work with both indexed 
(%1$S) and non-indexed (%S) replacement points in the localized string. 
In the further future, I expect this type of problem will go away 
entirely because of Fluent.


~ Gijs

On 02/02/2018 07:13, Kris Maglione wrote:
As of bug 1432966, any HTML injected into chrome-privileged 
documents[1] is automatically sanitized to remove any possibility of 
script execution. The sanitization is whitelist-based, and only allows 
a limited set of HTML elements and attributes. All scripts, XUL nodes, 
or privileged URLs will automatically be removed. This change has been 
uplifted all the way to 58 release.


If you're thinking about writing new code that injects HTML strings 
into chrome-privileged documents, please think again. Unless it's 
extremely simple, it probably won't be compatible with these changes 
(and will also be rejected by our default ESLint rules).


Existing HTML injection in chrome documents is being gradually 
removed. Once that's done, the sanitization may be replaced with an 
outright prohibition.



-Kris

[1]: Using the usual HTML fragment creation methods such as 
`innerHTML`, `outerHTML`, `insertAdjacentHTML`, and 
`createContextualFragment`. Not, notably, when using document.write().

___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: HTML injection in chrome documents is now automatically sanitized

[Johann Hofmann]

I don't think these rewrites fit the definition of a good first bug.

I'm all for working with volunteers on this, since these are good
isolated, non-time-sensitive projects to tackle, but I can't think of an
innerHTML example in our codebase that matches the low difficulty we
usually apply to good-first-bugs (some of them are indeed very hard to
do without innerHTML, which is why it's there in the first place). I'd
be happy if someone can prove me wrong about this, though.

Thank you Kris for the great work, let's get rid of innerHTML once and
for all!

Johann

Frederik Braun wrote:
> Now would be a great time to file good first bugs.
> 
> New contributors could rewrite innerHTML and friends into code that uses
> safer alternatives.
> 
> 
> 
> On 02.02.2018 08:13, Kris Maglione wrote:
>> As of bug 1432966, any HTML injected into chrome-privileged documents[1]
>> is automatically sanitized to remove any possibility of script
>> execution. The sanitization is whitelist-based, and only allows a
>> limited set of HTML elements and attributes. All scripts, XUL nodes, or
>> privileged URLs will automatically be removed. This change has been
>> uplifted all the way to 58 release.
>>
>> If you're thinking about writing new code that injects HTML strings into
>> chrome-privileged documents, please think again. Unless it's extremely
>> simple, it probably won't be compatible with these changes (and will
>> also be rejected by our default ESLint rules).
>>
>> Existing HTML injection in chrome documents is being gradually removed.
>> Once that's done, the sanitization may be replaced with an outright
>> prohibition.
>>
>>
>> -Kris
>>
>> [1]: Using the usual HTML fragment creation methods such as `innerHTML`,
>> `outerHTML`, `insertAdjacentHTML`, and `createContextualFragment`. Not,
>> notably, when using document.write().
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Changes to JSM import APIs (or, Death to Cu.import)

[Marco Bonardo]

Hi Kris, this change is awesome.

Is it ok to continue use defineLazyModuleGetters (plural), since it
internally now uses chromeUtils.defineModuleGetter? Any downsides?

On Fri, Feb 2, 2018 at 7:48 AM, Ed Lee  wrote:
> Great to see these types of broad changes getting wins, so if there's
> a good way to keep up to date and ahead of these types of incoming
> changes, that would be great. I learned of these changes from this
> week's biweekly Firefox meeting the morning that they were already
> inbound. Activity Stream is still in the process of getting automation
> passing with these changes, but I don't think we should over-rotate as
> this is a pretty unique type of change to our special development
> process.
>
> On Thu, Feb 1, 2018 at 10:01 PM, Kris Maglione  wrote:
>> a new ESLint rule has been added to prevent new instances.
> In particular, eslint-plugin-mozilla required changes to support this
> new way of adding globals, and Standard8 was able to publish the new
> version within a day of the changes breaking
> outside-of-mozilla-central repositories that were touched by the
> automatic rewrite and have dependencies on the plugin. I believe for
> this particular change, the eslint-plugin-mozilla additions could have
> been published sooner (except for the part of turning the rule on by
> default).
>
> Separate from that, Activity Stream has JSMs that get converted to
> commonjs for testing and esmodules for building (as an intermediary
> step to combine and optimize with our other esmodules for export to
> mozilla-central). These particular changes broke our tooling to do
> those conversions, but it's relatively straightforward to fix up. As I
> mentioned earlier, probably nothing really major to change in terms of
> process because of this, so mostly just making a note of this as a
> potential type of breakage that could happen again in the future.
>
> Ed Lee
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: HTML injection in chrome documents is now automatically sanitized

[Frederik Braun]

Now would be a great time to file good first bugs.

New contributors could rewrite innerHTML and friends into code that uses
safer alternatives.



On 02.02.2018 08:13, Kris Maglione wrote:
> As of bug 1432966, any HTML injected into chrome-privileged documents[1]
> is automatically sanitized to remove any possibility of script
> execution. The sanitization is whitelist-based, and only allows a
> limited set of HTML elements and attributes. All scripts, XUL nodes, or
> privileged URLs will automatically be removed. This change has been
> uplifted all the way to 58 release.
> 
> If you're thinking about writing new code that injects HTML strings into
> chrome-privileged documents, please think again. Unless it's extremely
> simple, it probably won't be compatible with these changes (and will
> also be rejected by our default ESLint rules).
> 
> Existing HTML injection in chrome documents is being gradually removed.
> Once that's done, the sanitization may be replaced with an outright
> prohibition.
> 
> 
> -Kris
> 
> [1]: Using the usual HTML fragment creation methods such as `innerHTML`,
> `outerHTML`, `insertAdjacentHTML`, and `createContextualFragment`. Not,
> notably, when using document.write().
> ___
> 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

Re: Proposed W3C Charter: Web Payments Working Group

[L. David Baron]

On Thursday 2018-01-18 19:05 -0700, Peter Saint-Andre wrote:
> On 1/8/18 10:17 PM, mcace...@mozilla.com wrote:
> > 
> > 
> >> On Jan 9, 2018, at 4:29 AM, L. David Baron  wrote:
> >>
> >> Please reply to this thread if you think there's something we should
> >> say as part of this charter review, or if you think we should
> >> support or oppose it.  (Given our involvement, we should almost
> >> certainly say something.)
> > 
> > Fyi, I sent feedback before TPAC (all of which was addressed, including 
> > dropping HTTP Payments, which can be addressed by the Fetch API). I’m 
> > personally supportive of current direction and the reduced work items on 
> > which the group is focused on. This includes incrementally supporting the 
> > whole gamut of payment systems: from credit cards, tokenized payments, to 
> > crypto currencies. 
> > 
> > I’d personally like to see Mozilla continue to support the working group, 
> > particularly as we continue to open up (and see continued innovation in) 
> > the payments ecosystems over the next 5-10 years.
> 
> Overall I agree with Marcos.
> 
> There are two aspects of the charter that could use some clarification.
> 
> §1.2 states that the WG might develop "an encryption module for one or
> more payment methods"; however, WG members do not necessarily have the
> expertise to do this work. At the least, it would be helpful to mention
> the parties (e.g., Web Cryptography WG or Web Application Security WG)
> that will be consulted to ensure the security of any such encryption module.
> 
> §1.3 suggests that work might happen around "the relationship of Payment
> Request API to EMVCo 3D Secure" (and in fact a 3DS Task Force has been
> spun up). My very early impression is that such work might involve
> two-factor authentication methods that do not use a standardized
> technology such as what's being developed within the Web Authentication
> Working Group. If the outcome is that browsers need to support both a
> 3DS method and a Web Auth method, I would be concerned about duplication
> of effort, architectural confusion, and differential security profiles.
> I'd prefer it if we could nudge the WG and W3C in the direction of
> settling on one method for user identification and authentication.

So how does the following response to the charter sound:

(X)  suggests changes to this Charter, but supports the proposal
 whether or not the changes are adopted (your details below).

Comments (which are just a slightly reworded version of Peter's
above):

§1.2 states that the WG might develop "an encryption module for one or
more payment methods"; however, WG members do not necessarily have the
expertise to do this work. At the least, it would be helpful to mention
the parties (e.g., Web Cryptography WG or Web Application Security WG)
that will be consulted to ensure the security of any such encryption module.

§1.3 suggests that work might happen around "the relationship of Payment
Request API to EMVCo 3D Secure" (and in fact a 3DS Task Force has been
spun up). Our very early impression is that such work might involve
two-factor authentication methods that do not use a standardized
technology such as what's being developed within the Web Authentication
Working Group. If the outcome is that browsers need to support both a
3DS method and a Web Auth method, we would be concerned about duplication
of effort, architectural confusion, and differential security profiles.
We'd prefer that these W3C working groups move in the direction of
settling on one method for user identification and authentication.



Or do you think one or both of these comments should constitute a
formal objection?

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship - Support already-enrolled U2F devices with Google Accounts for Web Authentication

[Henri Sivonen]

On Tue, Jan 30, 2018 at 6:49 PM, J.C. Jones  wrote:
> I also recognize that Google
> Accounts is the largest player in existing U2F device enrollments.
...
> If we choose not to do this, Google Accounts users who currently have U2F
> enabled will not be able to authenticate using Firefox until their existing
> U2F tokens are re-enrolled using Web Authentication -- meaning not only
> will Google need to change to the Web Authentication API, they will also
> have to prompt users to go back through the enrollment ceremony. This
> process is likely to take several years.

This seems like a necessary practical reason to make a special
accommodation for user's of Google Accounts.

> After discussions with appropriate Googlers confirmed that the “
> www.gstatic.com” origin used in U2F is being retired as part of their
> change-over to Web Authentication, I propose to hard-code support in Gecko
> to permit Google Accounts’ cross-origin U2F behavior, the same way as
> Chrome has. I propose to do this for a period of 5 years, until 2023, and

Given that users may use their current token for many years, why do we
have to set any particular expiration date for this exception? After
implementing the exception in the first place has become a sunk cost,
is there a reason to believe it will have a large ongoing maintenance
burden?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform