Re: Status of deprecating non-secure HTTP

[Boris Zbarsky]

On 9/25/17 11:45 AM, L. David Baron wrote:

So I don't think this requires any new *features* to be spec'd in
CSS (since @supports would work, and is the right thing to use),
although it probably does require a small amount of new spec prose
to explain how it works.


Well, it would need spec text somewhere that explains how to determine 
whether a stylesheet is a "secure context".


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

Re: Intent to require `mach try` for submitting to Try

[Aki Sasaki]

On 9/16/17 6:43 AM, Eric Rescorla wrote:

> 2. There are a lot more people writing code for Firefox than developing the
> internal tools, so in general, costs on those people should be avoided.



On Mon, Sep 18, 2017 at 5:16 AM, Eric Rescorla  wrote:

> And having something complex and scary on the server
> side is (at least to me) obviously better than having something complex and
>  scary (and did I mention constantly out of date) on the client side,
> because it's all in one place and externally just looks like the thing the
> client is expecting. Note that we already have half of this because we have
> one-way synching to gecko-dev on the server side. Perhaps one could also
> rip off some of the servo-gecko synching stuff here, but I don't know much
> about how that's architected.
>

I might be reading the first statement wrong: I see that as an argument to
avoid putting more costs on the people who develop and maintain internal
tools, because it's a smaller group. If this is an accurate reading, then
the second paragraph appears to be contradictory: moving the pain and
complexity around git from all Firefox developers onto this smaller group
will increase costs for that smaller group. From my perspective, gecko-dev
conversions have largely been as smooth as can be expected for the past
number of years, but we're seeing more timeouts, and it may only be a
matter of time before we either need to sink significant internal tools
development time into the conversion script, or we hit an issue that causes
significant downtime.

If I'm reading wrong, and you're saying we need to avoid putting costs on
the larger Firefox development group, then the two statements are
non-contradictory. I do think expecting supporting 2 VCSes as seamlessly as
one is a large ask of the smaller team; do many other software projects
support multiple official VCSes and workflows?

Originals to end.


On Mon, Sep 18, 2017 at 5:16 AM, Eric Rescorla  wrote:

> On Mon, Sep 18, 2017 at 2:56 AM, James Graham 
> wrote:
>
> > On 18/09/17 04:05, Eric Rescorla wrote:
> >
> > But that's just a general observation; if you look at this specific case,
> >>> it might not be much effort to support native git for richer/future try
> >>> pushing. But that's very different from requiring all the tools to
> >>> support
> >>> native git on an equal basis. And it seems reasonable to evaluate the
> >>> utility of this specific support via a poll, even one known to be
> biased.
> >>>
> >>>
> >> I don't think that's true, for the reasons I indicated above. Rather,
> >> there's a policy decision about whether we are going to have Git as a
> >> first-class thing or whether we are going to continue force everyone who
> >> uses Git to fight with inadequate workflows. We know there are plenty of
> >> people who use Git.
> >>
> >
> > I don't entirely understand what concrete thing is being proposed here.
> As
> > far as I can tell the git-hg parameter space contains the following
> points:
> >
> >  1. Use hg on the server and require all end users to use it
> >  2. Use git on the server and require all end users to use it
> >  3. Use hg on the server side and use client-side tooling to allow git
> > users to interact with the repository
> >  4. Use git on the server side and use client-side tooling to allow hg
> > users to interact with the repository
> >  5. Provide some server side magic to present both git and hg to clients
> > (with git, hg, or something else, as the on-disk format)
> >
> > These all seem to have issues relative to the goal of "vanilla git with
> no
> > custom code":
> >
> >  1. Doesn't allow git to be used at all.
> >  2. Requires a multi-year transition away from hg. Probably not popular
> > with hg fans.
> >  3. The status quo. Requires using a library for converting between hg
> and
> > git (i.e. cinnabar) or some mozilla-specific custom scripts (the old
> > moz-git-tools)
> >  4. Like 3. but with an additional multi-year transition and different
> > custom tooling.
> >  5. Allows vanilla git and hg on the client side, but requires something
> > complex, custom, and scary on the server side to allow pushing to either
> > repo. Could be possible if we eliminate ~all manual pushes (i.e.
> everything
> > goes via autoland), but cinnabar or similar is still there in the
> > background.
> >
>
> This is what I meant. And having something complex and scary on the server
> side is (at least to me) obviously better than having something complex and
>  scary (and did I mention constantly out of date) on the client side,
> because it's all in one place and externally just looks like the thing the
> client is expecting. Note that we already have half of this because we have
> one-way synching to gecko-dev on the server side. Perhaps one could also
> rip off some of the servo-gecko synching stuff here, but I don't know much
> about how that's architected.
>
>
> Given none of those options seem 

Re: Status of deprecating non-secure HTTP

[L. David Baron]

On Monday 2017-09-25 09:12 -0400, Boris Zbarsky wrote:
> On 9/25/17 9:01 AM, Anne van Kesteren wrote:
> > It does not seem hard to come up with solutions to those problems, if
> > we're actually committed to going down this path.
> 
> If we are, yes.  We need to decide whether we are...
> 
> > (E.g., just like globals have isSecureContext,
> > there could be a media query that can be used from CSS for the same
> > purpose. Or @supports could be used if we make parsing fail.)
> 
> Right, so we could block worklets on new CSS features to be specced in the
> CSSWGs copious free time.  ;)  I say this tongue-in-cheek, but the CSS
> editing situation is pretty horrible.  We _still_ don't have a spec for
>  at all, in any meaningful sense.  :(

I don't think this is a big deal.  What I proposed in
https://github.com/w3ctag/design-principles/pull/75 (which I think
the TAG will have a full discussion of this week) was that the
secure context restriction apply at the points where major features are
commonly added, and when they're feature-detectable.  So for new CSS
features restricted to a secure context, they wouldn't parse in a
non-secure context, and @supports would do the right thing.

So I don't think this requires any new *features* to be spec'd in
CSS (since @supports would work, and is the right thing to use),
although it probably does require a small amount of new spec prose
to explain how it works.

-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: CSP directive worker-src

[Daniel Veditz]

I'm not sure I agree with my own comment -- that's an insane fall-back
path. Might ease some backwards compatibility problems, but we don't know
how many of those there will be. But then we have to live with the insanity
forever.

-Dan Veditz

On Mon, Sep 25, 2017 at 1:01 AM, Christoph Kerschbaumer 
wrote:

>
> On Sep 22, 2017, at 10:27 PM, Daniel Veditz  wrote:
> ​Christoph said
>
>> For backwards compatibility child-src will still be enforced for:
>>   * workers (if worker-src is not explicitly specified)
>>
>
> ​But the spec says the fallback is script-src. Surely anyone who uses
> child-src will also have a script-src so how is this going to work? How
> does Chrome work?
>
>
> It’s too confusing, but that’s why I initially filed
> https://github.com/w3c/webappsec-csp/issues/238, because the spec still
> mentioned that child-src will govern workers in the absence of worker-src.
>
>
> Filed https://github.com/w3c/webappsec-csp/issues/239 to remove the
> worker mentions from child-src since the rest of the spec (including the
> algorithm in that section) implies that's incorrect.
>
>
> Ultimately I agree with your comment in issue 238. Probably the fallback
> should be, worker-src, child-src, and then script-src, default-src. Either
> way, I think we can find a solution within issue 239, thanks for filing.
>
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Containers graduation from Test Pilot - we still care about 57+

[Ben Kelly]

Thanks Jonathan.

Also, it seems the link to the web extension version of the container addon
is broken above.  This one works for me:

https://github.com/mozilla/multi-account-containers/releases/latest

On Sat, Sep 23, 2017 at 9:52 AM, Jonathan Kingston  wrote:

> Hi All,
>
> TL;DR - containers is going well, we made it a web extension and it will
> continue on addons.mozilla.org
>
> I just wanted to highlight that we have graduated our extension of Test
> Pilot Containers to be on AMO: https://addons.mozilla.org/en-GB/firefox/
> addon/multi-account-containers/
>
> We have had a few confused users about what is happening with containers.
>
> There is confusion around why the addon doesn't work in 57+ which is due to
> it being a legacy addon to support 56, the extension can now be fully
> WebExtensions after 57 and to install there you can use:
> https://github.com/
> mozilla/multi-account-containers/releases/latest the addons team is
> working
> on a fix for the website to allow Beta/Nightly users to download there.
>
> We have also removed in Nightly the ability to use the drawer icon which
> was native to nightly as it was a subset of features that were provided by
> the extension.
>
> To open a container:
> - Long press on the + button
> - Use the file menu (alt+f)
> - Use the extension above (ctrl+period)
> - Right click links with the context menu
>
> :bkelly suggested I email here in this bug: https://bugzilla.mozilla
> .org/show_bug.cgi?id=1402342 which provides further clarification.
>
> We have exciting posts coming soon to explain further, I just wanted to
> highlight we aren't dropping containers just clearing up experiences for
> when 57 is stable.
>
> Any user of >57 can actually install any container addon to enable
> containers:
> https://addons.mozilla.org/en-GB/firefox/collections/jkt/container-addons/
>
> In Beta and Stable releases containers is still disabled by default,
> installing a container addon will enable them. To reduce confusion here I
> have raised: https://bugzilla.mozilla.org/show_bug.cgi?id=1402608 to allow
> users of beta/stable to enable containers through about:preferences also.
>
> If in doubt feel free to reach out to: contain...@mozilla.com
>
> Thanks
> Jonathan
> ___
> 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: Status of deprecating non-secure HTTP

[Boris Zbarsky]

On 9/25/17 9:01 AM, Anne van Kesteren wrote:

It does not seem hard to come up with solutions to those problems, if
we're actually committed to going down this path.


If we are, yes.  We need to decide whether we are...


(E.g., just like globals have isSecureContext,
there could be a media query that can be used from CSS for the same
purpose. Or @supports could be used if we make parsing fail.)


Right, so we could block worklets on new CSS features to be specced in 
the CSSWGs copious free time.  ;)  I say this tongue-in-cheek, but the 
CSS editing situation is pretty horrible.  We _still_ don't have a spec 
for  at all, in any meaningful sense.  :(


-Boris

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

Re: Status of deprecating non-secure HTTP

[Anne van Kesteren]

On Mon, Sep 25, 2017 at 2:47 PM, Boris Zbarsky  wrote:
> On 9/25/17 3:18 AM, Anne van Kesteren wrote:
>> But it would also be good if we could all communicate this on behalf
>> of Mozilla without caveats. E.g., Chrome might ship worklets soon and
>> being able to object to that happening (specification-wise) on
>> insecure contexts on behalf of Mozilla would be good.
>
> The Chrome intent to shop thread for CSS paint raises some good concerns
> about what exactly it would mean to not support paint worklets in insecure
> contexts.  Do they still parse but just fail to paint?  Do the not parse?
> Note that a _stylesheet_ doesn't have a concept of secure or insecure
> context right now

It does not seem hard to come up with solutions to those problems, if
we're actually committed to going down this path. Especially if we're
all aligned that the goal is restrict as many new features to secure
contexts as possible. (E.g., just like globals have isSecureContext,
there could be a media query that can be used from CSS for the same
purpose. Or @supports could be used if we make parsing fail.)


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

Re: Status of deprecating non-secure HTTP

[Boris Zbarsky]

On 9/25/17 3:18 AM, Anne van Kesteren wrote:

But it would also be good if we could all communicate this on behalf
of Mozilla without caveats. E.g., Chrome might ship worklets soon and
being able to object to that happening (specification-wise) on
insecure contexts on behalf of Mozilla would be good.


The Chrome intent to shop thread for CSS paint raises some good concerns 
about what exactly it would mean to not support paint worklets in 
insecure contexts.  Do they still parse but just fail to paint?  Do the 
not parse?  Note that a _stylesheet_ doesn't have a concept of secure or 
insecure context right now


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

Signaling Devices Market Growth Set to Surge Significantly during 2017 - 2025

[sayalitip]

Get Flat 25% Discount in This Report at 
http://www.theinsightpartners.com/discount/TIPTE10382 (Offer available up 
to October 15, 2017)
The Signaling Devices market accounted for US$ 1520.0 million in 2016 and is 
expected to grow during the forecast period 2017 – 2025, to account for US$ 
2675.3 million in 2025. Every year more than 37,000 fire and explosion 
accidents occurs in industries and manufacturing areas, leading to loss of 
property and life. Costly breakdowns, material shortages or manufacturing 
environment safety are some of the concerns need to be addressed with signaling 
devices installation in industries. Signaling devices by geography is segmented 
as North America, Europe, APAC, SAM and MEA. North America and Europe being 
most developed region globally and are also having strict government safety 
regulations, therefore is expected to account around 60% of the total signaling 
devices market. Many of the industrial, mining, oil & gas plants as well as 
commercial segment across the globe are facing serious issues related to 
explosion and accidents due to lack of on-time hazardous warning. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Status of deprecating non-secure HTTP

[Anne van Kesteren]

It seems that with Richard leaving Mozilla we dropped the ball on
requiring HTTPS more often:

  https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/

At least I can't find any follow-up with an agreed upon date and we're
still rather hit-or-miss when it comes to using [SecureContext] on new
APIs. Let alone non-IDL-driven features. We have made some modest
progress on the second action item however.

David Baron has made some efforts to more require this to pass a W3C TAG review:

  https://github.com/w3ctag/design-principles/pull/75

But it would also be good if we could all communicate this on behalf
of Mozilla without caveats. E.g., Chrome might ship worklets soon and
being able to object to that happening (specification-wise) on
insecure contexts on behalf of Mozilla would be good.


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

[Firefox Desktop] Issues found: September 18th to September 22nd

[Cornel Ionce]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *September 18 - September 22* (week 38).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
none

*BETA CHANNEL
*
ID  Summary Product Component   Is a regression 
Assigned to
1401122 
	The favicon of a pinned tab displays glitches when hovered or brought 
to focus

Firefox
Tabbed Browser
	YES 
 
	NOBODY

1402345 
Cancelling the Firefox installer can be confusing
Firefox
Installer
NO  NOBODY
1402353 
	The user should be able to dismiss the "For some reason, we could not 
install Firefox" pop-up message

Firefox
Installer
NO  NOBODY


*NIGHTLY CHANNEL**
*
ID  Summary Product Component   Is a regression 
Assigned to
1401164 
	[Form Autofill] Name on Card does not trigger credit card autofill and 
expiry date is auto-filled wrong on groupon.com

Tech Evangelism
Desktop
NO  NOBODY


*ESR CHANNEL*
none


Regards,
Cornel (:cornel_ionce)
Desktop Release QA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform