Re: Removal of NPAPI plugin support in Firefox 85

This is amazing news. -Ekr On Fri, Nov 13, 2020 at 10:10 AM Jim Mathies wrote: > Hey all, > > I am happy to announce that NPAPI plugin support will end in Firefox 85. > At the start of the 85 cycle the Plugins Team plans to land changes that > disable NPAPI plugin loading and display. We'll

Re: A new testing policy for code landing in mozilla-central

On Tue, Sep 15, 2020 at 9:28 AM Andrew McCreight wrote: > On Tue, Sep 15, 2020 at 8:03 AM Brian Grinstead > wrote: > > > (This is a crosspost from firefox-dev) > > > > Hi all, > > > > We’re rolling out a change to the review process to put more focus on > > automated testing. This will affect

Re: Intent to ship: accept spaces and tabs in unquoted values (of e.g. "filename") used in Content-Disposition parameterized header pairs to to align with other browsers

Ugh. This does seem like the right thing to do in a bad situation. Thanks and thanks to Anne for working to get the spec updated. -Ekr On Wed, Aug 19, 2020 at 10:10 AM Gijs Kruitbosch wrote: > It's been pointed out to me that I neglected to merge the "intent to > prototype" requirements into

Re: Proposed W3C Charter: Decentralized Identifier (DID) Working Group

I tend to agree with you. Is there a reason not to formally object? On Wed, Aug 28, 2019 at 3:30 PM L. David Baron wrote: > The W3C is proposing a new charter for: > > Decentralized Identifier (DID) Working Group > https://www.w3.org/2019/08/did-wg-charter.html >

Re: [C++] Intent to eliminate: `using namespace std; ` at global scope

+1. This::sounds::like::a::great::change. -Ekr On Thu, Aug 29, 2019 at 12:13 PM Nathan Froyd wrote: > Hi all, > > In working on upgrading our C++ support to C++17 [1], we've run into > some issues [2] surrounding the newly-introduced `std::byte` [3], > various Microsoft headers that pull in

Re: Extension to integrate Searchfox features in Phabricator

This is great. Thanks! -Ekr On Tue, Oct 2, 2018 at 7:04 AM Kartikaya Gupta wrote: > Neat! I took a quick peek at your addon source and the stuff it's > relying on seems ok for now. At least, it's not anything we plan to > change anytime soon. If there are changes to searchfox that would make

Re: PSA: Automated code analysis now also in Phabricator

This is amazing and looks super-useful. Really looking forward to seeing what else we can add in this area! -Ekr On Tue, Jul 17, 2018 at 6:22 AM, Jan Keromnes wrote: > TL;DR -- “reviewbot” is now enabled in Phabricator. It reports potential > defects in pending patches for Firefox. > > Last

Re: open socket and read file inside Webrtc

On Wed, Jul 4, 2018 at 5:24 AM, wrote: > Hi, > I'm very new with firefox (as developer, of course). > I need to open a file and tcp sockets inside webrtc. > I read the following link > https://wiki.mozilla.org/Security/Sandbox#File_System_Restrictions > there is the sandbox that does not permit

Re: Rust crate approval

On Sun, Jul 1, 2018 at 4:56 PM, Xidorn Quan wrote: > On Mon, Jul 2, 2018, at 9:03 AM, Eric Rescorla wrote: > > On Sat, Jun 30, 2018 at 9:35 AM, Lars Bergstrom > > wrote: > > > > > On Fri, Jun 29, 2018 at 8:33 AM, Tom Ritter wrote: > > > > > > &g

Re: Rust crate approval

On Sat, Jun 30, 2018 at 9:35 AM, Lars Bergstrom wrote: > ​ > > On Fri, Jun 29, 2018 at 8:33 AM, Tom Ritter wrote: > > > > > I know that enumerating badness is never a comprehensive solution; but > > maybe there could be a wiki page we could point people to for things that > > indicate something

Re: Proposed W3C Charter: Devices and Sensors Working Group

LGTM -Ekr On Fri, May 25, 2018 at 5:23 PM, L. David Baron wrote: > OK, sorry to not get this drafted until too close to the deadline to > be likely to get feedback, but here's what I currently have for > proposed comments that I'll submit on the charter. (If you happen >

Re: Removing tinderbox-builds from archive.mozilla.org

On Fri, May 11, 2018 at 4:06 PM, Gregory Szorc wrote: > On Wed, May 9, 2018 at 11:01 AM, Ted Mielczarek > wrote: > > > On Wed, May 9, 2018, at 1:11 PM, L. David Baron wrote: > > > > mozregression won't be able to bisect into inbound branches then, > but I

Re: Is super-review still a thing?

On Fri, Apr 20, 2018 at 7:03 PM, Dave Townsend wrote: > Presumably it supports multiple reviews for a patch, in which case I think > we're fine. > It does. -Ekr > On Fri, Apr 20, 2018 at 3:03 PM Gregory Szorc wrote: > > > On Fri, Apr 20, 2018 at 2:51

Re: Commit messages in Phabricator

On Mon, Feb 12, 2018 at 6:09 AM, Boris Zbarsky wrote: > On 2/11/18 3:57 PM, Emilio Cobos Álvarez wrote: > >> Arc wants to use something like: >> > > So from my point of view, having the bug# easily linked from various > places where the short summary is all that's shown

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

On Tue, Jan 30, 2018 at 8:49 AM, J.C. Jones wrote: > Summary: Support already-enrolled U2F devices with Google Accounts for Web > Authentication > > Web Authentication is on-track to ship in Firefox 60 [1], and contains > within it support for already-deployed USB-connected

Re: Password autofilling

On Tue, Jan 9, 2018 at 8:43 AM, Gervase Markham wrote: > On 01/01/18 20:08, Jonathan Kingston wrote: > > A recent research post[1] have highlighted the need for Firefox to > disable > > autofilling of credentials. The research post suggests web trackers are > > using

Re: Proposed W3C Charter: Second Screen Working Group

LGTM! On Thu, Jan 4, 2018 at 9:56 PM, L. David Baron wrote: > So I think Martin, Peter, and I share similar concerns here, and I'm > inclined to turn those concerns into an objection to this charter. > > So how does this sound for proposed comments on the charter > (submitted

Re: Hiding 'new' statements - Good or Evil?

On Mon, Nov 27, 2017 at 6:41 PM, Xidorn Quan <m...@upsuper.org> wrote: > On Tue, Nov 28, 2017, at 11:45 AM, Eric Rescorla wrote: > > On Mon, Nov 27, 2017 at 4:07 PM, smaug <sm...@welho.com> wrote: > > > And auto makes code reading harder. It hides important i

Re: Hiding 'new' statements - Good or Evil?

On Mon, Nov 27, 2017 at 4:07 PM, smaug wrote: > On 11/28/2017 12:53 AM, Jeff Gilbert wrote: > >> ranged-for issues are the same as those for doing manual iteration, >> > It is not, in case you iterate using > for (i = 0; i < foo.length(); ++i) > And that is the case which has

Re: Hiding 'new' statements - Good or Evil?

On Thu, Nov 23, 2017 at 4:00 PM, smaug wrote: > On 11/23/2017 11:54 PM, Botond Ballo wrote: > >> I think it makes sense to hide a 'new' call in a Make* function when >> you're writing an abstraction that handles allocation *and* >> deallocation. >> >> So MakeUnique makes sense,

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

On Tue, Sep 19, 2017 at 10:21 AM, Eric Rescorla <e...@rtfm.com> wrote: > > On Tue, Sep 19, 2017 at 9:20 AM, Andrew McCreight <amccrei...@mozilla.com> > wrote: > >> On Tue, Sep 19, 2017 at 8:49 AM, Eric Rescorla <e...@rtfm.com> wrote: >> >> > G

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

On Tue, Sep 19, 2017 at 9:20 AM, Andrew McCreight <amccrei...@mozilla.com> wrote: > On Tue, Sep 19, 2017 at 8:49 AM, Eric Rescorla <e...@rtfm.com> wrote: > > > Generally no, but this is an unfortunate consequence of Mozilla's > decision > > a while ago to pi

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

On Tue, Sep 19, 2017 at 8:40 AM, Aki Sasaki <asas...@mozilla.com> wrote: > 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 a

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

On Mon, Sep 18, 2017 at 2:56 AM, James Graham <ja...@hoppipolla.co.uk> 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

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

On Mon, Sep 18, 2017 at 1:10 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > On Mon, Sep 18, 2017 at 6:05 AM, Eric Rescorla <e...@rtfm.com> wrote:> > I don't think that's true, for the reasons I indicated above. Rather, > > there's a policy decision about wheth

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

On Sun, Sep 17, 2017 at 12:09 PM, Steve Fink <sf...@mozilla.com> wrote: > On 9/16/17 6:43 AM, Eric Rescorla wrote: > >> On Fri, Sep 15, 2017 at 9:25 PM, Gregory Szorc <g...@mozilla.com> wrote: >> >> >> I'd prefer to take a data-driven approach to

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

On Fri, Sep 15, 2017 at 9:25 PM, Gregory Szorc <g...@mozilla.com> wrote: > On Fri, Sep 15, 2017 at 8:37 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> >> >> On Fri, Sep 15, 2017 at 8:33 PM, Gregory Szorc <g...@mozilla.com> wrote: >> >>> On F

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

On Fri, Sep 15, 2017 at 8:33 PM, Gregory Szorc <g...@mozilla.com> wrote: > On Fri, Sep 15, 2017 at 7:44 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> What happens if you are using git? >> > > git-cinnabar is already supported. > Supported how? Do I have to

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

What happens if you are using git? -Ekr On Fri, Sep 15, 2017 at 3:30 PM, Gregory Szorc wrote: > The Try Service ("Try") is a mechanism that allows developers to schedule > tasks in automation. The main API for that service is "Try Syntax" (e.g. > "try: -b o -p linux -u

Re: Coding style: `else for` or `else { for... }`?

On Wed, Aug 30, 2017 at 4:41 PM, Jeff Gilbert wrote: > IMO: Never else-for. (or else-while) > > Else-if is a reasonable continuation of concept: "Well it wasn't that, > what if it's this instead?" > Else-for is just shorthand for "well it wasn't that, so let's loop > over

Re: Implementing a Chrome DevTools Protocol server in Firefox

On Wed, Aug 30, 2017 at 3:55 PM, Michael Smith wrote: > Hi everyone, > > Mozilla DevTools is exploring implementing parts of the Chrome DevTools > Protocol ("CDP") [0] in Firefox. This is an HTTP, WebSockets, and JSON > based protocol for automating and inspecting running

Re: Coding style: Argument alignment

On Wed, Aug 30, 2017 at 9:29 AM, Sylvestre Ledru <sle...@mozilla.com> wrote: > Le 30/08/2017 à 17:25, Eric Rescorla a écrit : > > > > On Wed, Aug 30, 2017 at 1:21 AM, Sylvestre Ledru <sle...@mozilla.com> > wrote: > >> >> Le 30/08/2017 à 0

Re: Coding style: Argument alignment

On Wed, Aug 30, 2017 at 1:21 AM, Sylvestre Ledru wrote: > > Le 30/08/2017 à 08:53, Henri Sivonen a écrit : > > Regardless of the outcome of this particular style issue, where are we > > in terms of clang-formatting all the non-third-party C++ in the tree? > > We have been

Re: Proposed W3C Charter: WebVR Working Group

nd out more and get > > > something > > > > to dbaron by tomorrow. I'm not familiar with the inner workings of > the > > > W3C, > > > > but I find it hard to imagine how things will go well with none of > the > > > > current spec contributo

Re: Proposed W3C Charter: WebVR Working Group

On Wed, Aug 16, 2017 at 5:18 PM, Daniel Veditz wrote: > On Wed, Aug 16, 2017 at 3:51 PM, L. David Baron wrote: > > > I still think opposing this charter because the group should still > > be in the incubation phase would be inconsistent with our shipping

Re: Restricting the Notifications API to secure contexts

This seems fine. -Ekr On Mon, Aug 7, 2017 at 6:45 AM, Anne van Kesteren wrote: > Chrome wants to restrict the Notifications API > https://notifications.spec.whatwg.org/ to secure contexts: > > https://github.com/whatwg/notifications/issues/93 >

Re: Improving visibility of compiler warnings

I'd like to second Ehsan's point, but also expand upon it into a more general observation. As it becomes progressively more difficult to build Firefox without mach, it becomes increasingly important that mach respect people's workflows. For those of us who were comfortable with make and the

Re: Race Cache With Network experiment on Nightly

What's the state of pref experiments? I thought they were not yet ready. -Ekr On Thu, May 25, 2017 at 7:15 AM, Benjamin Smedberg wrote: > Is there a particular reason this is landing directly to nightly rather > than using a pref experiment? A pref experiment is going

Re: Improving visibility of compiler warnings

On Sat, May 20, 2017 at 1:16 PM, Kris Maglione wrote: > On Sat, May 20, 2017 at 08:36:13PM +1000, Martin Thomson wrote: > >> On Sat, May 20, 2017 at 4:55 AM, Kris Maglione >> wrote: >> >>> Can we make some effort to get clean warnings output at the

Re: Using references vs. pointers in C++ code

As Henri indicates, I think the use of references is consistent with the style guide. It's also worth noting that if you are using boxed pointers, then you almost certainly want to use references to pass them around. I.e., foo(const RefPtr& mPtr); // avoids useless ref count

Re: Ambient Light Sensor API

On Thu, Apr 27, 2017 at 11:02 PM, Frederik Braun wrote: > On 28.04.2017 05:56, Ehsan Akhgari wrote: > > On 04/27/2017 08:09 AM, Frederik Braun wrote: > >> On 27.04.2017 13:56, smaug wrote: > >>> On 04/25/2017 04:38 PM, Ehsan Akhgari wrote: > On 04/24/2017 06:04 PM,

Re: Ambient Light Sensor API

On Wed, Apr 26, 2017 at 2:01 AM, Gervase Markham <g...@mozilla.org> wrote: > On 25/04/17 16:46, Eric Rescorla wrote: > > This suggests that maybe we could just turn it off > > It would be sad to remove a capability from the web platform which > native apps have. I

Re: Ambient Light Sensor API

formation theft pretty seriously. -Ekr > On Wed, Apr 26, 2017 at 1:30 AM, Eric Rescorla <e...@rtfm.com> wrote: > >> >> >> On Tue, Apr 25, 2017 at 3:40 PM, Salvador de la Puente < >> sdelapue...@mozilla.com> wrote: >> >>> The

Re: Ambient Light Sensor API

This suggests that maybe we could just turn it off On Tue, Apr 25, 2017 at 7:25 AM, Andrew Overholt <overh...@mozilla.com> wrote: > On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla <e...@rtfm.com> wrote: > >> Going back to Jonathan's (I think) question. Doe

Re: Ambient Light Sensor API

Going back to Jonathan's (I think) question. Does anyone use this at all in the field? -Ekr On Tue, Apr 25, 2017 at 6:10 AM, Kurt Roeckx wrote: > On 2017-04-25 00:04, Martin Thomson wrote: > > I think that 60Hz is too high a rate for this. > > > > I suggest that we restrict

Re: Quantum Flow Engineering Newsletter #5

On Tue, Apr 18, 2017 at 4:19 AM, Jack Moffitt wrote: > > Another really nice effort that is starting to unfold and I'm super > excited > > about is the new Photon performance project > > , which is a > focused > > effort on

Re: Enabling Pointer Events in Firefox (desktop) Nightly on Mac and Linux

On Thu, Apr 6, 2017 at 5:26 AM, Ehsan Akhgari wrote: > On Thu, Apr 6, 2017 at 12:57 AM, L. David Baron wrote: > > > On Thursday 2017-04-06 00:33 -0400, Ehsan Akhgari wrote: > > > In general, I should also say that designing features with > > >

Re: Revocation protocol idea

On Fri, Mar 31, 2017 at 4:20 AM, Salvador de la Puente < sdelapue...@mozilla.com> wrote: > Hi Eric > > On Wed, Mar 22, 2017 at 6:11 AM, Eric Rescorla <e...@rtfm.com> wrote: > >> There seem to be three basic ideas here: >> >> 0. Blacklisting at the

Re: Revocation protocol idea

There seem to be three basic ideas here: 0. Blacklisting at the level of API rather than site. 1. Some centralized but democratic mechanism for building a list of misbehaving sites. 2. A mechanism for distributing the list of misbehaving sites to clients. As Jonathan notes, Firefox already has

Re: The future of commit access policy for core Firefox

On Mon, Mar 13, 2017 at 12:22 AM, Frederik Braun wrote: > On 12.03.2017 04:08, Cameron Kaiser wrote: > > On 3/10/17 4:38 AM, Masatoshi Kimura wrote: > >> On 2017/03/10 6:53, Mike Connor wrote: > >>> - Two-factor auth must be a requirement for all users approving or > >>>

Re: The future of commit access policy for core Firefox

On Fri, Mar 10, 2017 at 9:03 PM, L. David Baron <dba...@dbaron.org> wrote: > On Friday 2017-03-10 19:33 -0800, Eric Rescorla wrote: > > We have been using Phabricator for our reviews in NSS and its interdiffs > > work pretty well > > (modulo rebases, which are not so

Re: The future of commit access policy for core Firefox

On Fri, Mar 10, 2017 at 7:23 PM, smaug via governance < governa...@lists.mozilla.org> wrote: > On 03/10/2017 12:59 AM, Bobby Holley wrote: > >> At a high level, I think the goals here are good. >> >> However, the tooling here needs to be top-notch for this to work, and the >> standard approach of

Re: The future of commit access policy for core Firefox

On Thu, Mar 9, 2017 at 3:11 PM, wrote: > On Friday, March 10, 2017 at 10:53:50 AM UTC+13, Mike Connor wrote: > > (please direct followups to dev-planning, cross-posting to governance, > > firefox-dev, dev-platform) > > > > > > Nearly 19 years after the creation of

Re: Please write good commit messages before asking for code review

On Thu, Mar 9, 2017 at 2:53 PM, Ben Kelly <bke...@mozilla.com> wrote: > > > On Thu, Mar 9, 2017 at 5:48 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> >> >> On Thu, Mar 9, 2017 at 2:43 PM, Ben Kelly <bke...@mozilla.com> wrote: >> >>>

Re: The future of commit access policy for core Firefox

First, let me state that I am generally in support of this type of change. More comments below. On Thu, Mar 9, 2017 at 1:53 PM, Mike Connor wrote: > (please direct followups to dev-planning, cross-posting to governance, > firefox-dev, dev-platform) > > > Nearly 19 years

Re: Please write good commit messages before asking for code review

On Thu, Mar 9, 2017 at 2:43 PM, Ben Kelly wrote: > On Thu, Mar 9, 2017 at 5:35 PM, Mike Hommey wrote: > > > On Thu, Mar 09, 2017 at 02:46:53PM -0500, Ehsan Akhgari wrote: > > > I review a large number of patches on a typical day, and usually I have > > to

Re: Please write good commit messages before asking for code review

I'm in favor of good commit messages, but I would note that current m-c convention really pushes against this, because people seem to feel that commit messages should be one line. Not sure what to do about that, but thought I would mention it. -Ekr On Thu, Mar 9, 2017 at 12:10 PM, Boris Zbarsky

Re: Should &&/|| really be at the end of lines?

On Thu, Feb 16, 2017 at 11:39 PM, David Major wrote: > One thing I like about trailing operators is that they tend to match > what you'd find in bullet-point prose. Here's a made-up example: > > You can apply for a refund of your travel insurance policy if: > * You cancel

Re: Redirecting http://hg.mozilla.org/ to https://

Yes. Kill it with fire! -Ekr On Fri, Jan 27, 2017 at 7:17 AM, Gregory Szorc wrote: > It may be surprising, but hg.mozilla.org is still accepting plain text > connections via http://hg.mozilla.org/ and isn't redirecting them to > https://hg.mozilla.org/. > > On February 1

Re: A reminder about MOZ_MUST_USE and [must_use]

What would actually be very helpful would be a way to selectively turn on checking of *all* return values in a given file/subdirectory. Is there some mechanism/plan for that? Thanks, -Ekr On Thu, Jan 19, 2017 at 2:09 PM, Nicholas Nethercote wrote: > Hi, > > We have

Re: Intent to Implement and Ship: Large-Allocation Header

On Wed, Jan 18, 2017 at 12:21 PM, Michael Layzell wrote: > Summary: > Games implemented on the web platform using WASM or asm.js use large > contiguous blocks of allocated memory as their backing store for game > memory. For complex games, these allocations can be quite

Re: Proposed W3C Charter: Verifiable Claims Working Group

On Wed, Dec 28, 2016 at 3:52 PM, L. David Baron wrote: > Here's an attempt to write up comments to submit on this charter. > I'm not sure I understood ekr's reply to mt, though. So corrections > and clarifications are certainly welcome. > > Sorry for the delay circling back

Re: Intent to ship: NetworkInformation

On Thu, Dec 22, 2016 at 10:31 PM, <mcace...@mozilla.com> wrote: > On Wednesday, December 21, 2016 at 12:51:10 AM UTC+11, Eric Rescorla wrote: > > I'm not really following this argument. Usually when a document has been > > floating > > around a long time but clea

Re: Intent to deprecate: Insecure HTTP

On Tue, Dec 20, 2016 at 10:28 AM, Cody Wohlers wrote: > Absolutely! Let's Encrypt sounds awesome, super-easy, and the price is > right. > > But I'm thinking of cases like Lavabit where a judge forced the site > operator to release the private key. Or the opposite -

Re: Intent to ship: NetworkInformation

On Mon, Dec 19, 2016 at 10:58 PM, wrote: > On Friday, December 16, 2016 at 8:33:48 AM UTC+11, Tantek Çelik wrote: > > On Thu, Dec 15, 2016 at 11:51 AM, Boris Zbarsky <> wrote: > > > On 12/15/16 12:20 PM, Ben Kelly wrote: > > >> > > >> Its more information than nothing. > >

Re: Intent to ship: NetworkInformation

It seems pretty premature in this process to trying to hack around the API not expressing what we wanted to make. If what we want to express is "is this link free" then let's make the API say that. -Ekr On Thu, Dec 15, 2016 at 4:17 PM, Martin Thomson wrote: > On Fri, Dec 16,

Re: Intent to ship: NetworkInformation

On Thu, Dec 15, 2016 at 6:42 AM, Boris Zbarsky wrote: > On 12/15/16 3:28 AM, Andrea Marchesini wrote: > >> Spec: https://w3c.github.io/netinfo/ >> > > Is there any plan to have this turned into an actual spec, complete with > IPR commitments, testcases, wider review, etc? > >

Re: Proposed W3C Charter: Verifiable Claims Working Group

On Mon, Dec 12, 2016 at 6:37 PM, Martin Thomson <m...@mozilla.com> wrote: > On Tue, Dec 13, 2016 at 5:56 AM, Eric Rescorla <e...@rtfm.com> wrote: > > Following up to myself: if the plan is really that people will have a > > single identity that they then present to ev

Re: Proposed W3C Charter: Verifiable Claims Working Group

Following up to myself: if the plan is really that people will have a single identity that they then present to everyone and that claims hang off, I think W3C should not standardize that. -Ekr On Mon, Dec 12, 2016 at 8:48 AM, Eric Rescorla <e...@rtfm.com> wrote: > I took a q

Re: Proposed W3C Charter: Verifiable Claims Working Group

I took a quick look at this material and it's very hard to tell what the actual privacy properties are: "From a privacy perspective it is important that information that is intended to remain private is handled appropriately. Maintaining the trust of a verifiable claims ecosystem is important.

Re: Proposed W3C Charter: Automotive Working Group

LGTM On Fri, Nov 4, 2016 at 5:22 PM, L. David Baron wrote: > OK, here's a reformulation that takes a somewhat stronger position > (mainly by checking the other box, and adding the paragraph at the > end). > > -David > > > [X] opposes this Charter and requests that this group

Re: Proposed W3C Charter: Automotive Working Group

ll the same reasons > > apply), and list the new items that Martin and Ekr provided. I suggest > > we cc this response to www-archive as well. > > > > Thanks, > > > > Tantek > > > > > > > > On Tue, Oct 18, 2016 at 3:10 AM, Eric Rescorla <e.

Re: Removing navigator.buildID?

On Tue, Nov 1, 2016 at 3:53 PM, Martin Thomson wrote: > On Tue, Nov 1, 2016 at 11:15 PM, Aryeh Gregor wrote: > > Taking a step back: is fingerprinting really a solvable problem in > > practice? At this point, are there a significant fraction of users > > who

Re: Intent to ship: TLS 1.3 draft

Yes. On Sat, Oct 29, 2016 at 4:40 AM, wrote: > On Wednesday, October 19, 2016 at 4:49:43 PM UTC-7, Martin Thomson wrote: > > > > As of Firefox 52 I intend to turn TLS 1.3 on by default. ... > > > > ... > > > > ... Since this is a draft version of the spec going

Re: Intent to restrict to secure contexts: navigator.geolocation

On Wed, Oct 26, 2016 at 7:17 AM, Daniel Minor <dmi...@mozilla.com> wrote: > > > On Tue, Oct 25, 2016 at 3:30 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> On Wed, Oct 26, 2016 at 6:17 AM, Chris Peterson <cpeter...@mozilla.com> >> wrote: >>

Re: Intent to restrict to secure contexts: navigator.geolocation

On Wed, Oct 26, 2016 at 6:17 AM, Chris Peterson <cpeter...@mozilla.com> wrote: > On 10/25/2016 11:43 AM, Eric Rescorla wrote: > >> Setting aside the policy question, the location API for mobile devices >> generally >> gives a much more precise estimate of your

Re: Intent to restrict to secure contexts: navigator.geolocation

On Wed, Oct 26, 2016 at 5:24 AM, Aryeh Gregor wrote: > > In this specific case, it seems that the usual candidates for MITMing > (compromised Wi-Fi, malicious ISP) will already know the user's > approximate location, because they're the ones who set up the Internet > connection,

Re: Windows XP and Vista Long Term Support Plan

This seems to assume facts not in evidence, namely that people will stop using those machines rather than just living with whatever the last version we updated them to. Do we have any data that shows that that's true? -Ekr On Mon, Oct 24, 2016 at 1:12 AM, Gervase Markham

Re: Proposed W3C Charter: Automotive Working Group

I share Martin's concerns here... There's fairly extensive evidence of security vulnerabilities in vehicular systems that can lead to serious safety issues (see: http://www.autosec.org/publications.html), so more than usual attention needs to be paid to security in this context. In fairness, a

Re: W3C Proposed Recommendation: WebIDL Level 1

Speaking as someone who is at best a consumer of WebIDL, what's the argument for doing a snapshot at this time? -Ekr On Mon, Oct 10, 2016 at 11:24 PM, Anne van Kesteren wrote: > On Tuesday, 11 October 2016, L. David Baron wrote: > > > But given that it is

Re: PSA: mozilla/unused.h renamed to mozilla/Unused.h

On Sat, Aug 27, 2016 at 8:53 AM, Gregory Szorc wrote: > > > > On Aug 27, 2016, at 07:09, Kan-Ru Chen wrote: > > > >> On Sat, Aug 27, 2016, at 11:35 AM, Gregory Szorc wrote: > >>> On Fri, Aug 26, 2016 at 8:27 PM, Steve Fink wrote: > >>>

Re: New [must_use] property in XPIDL

thing that I wanted to use originally. > Unfortunately, we have not been able to make that work: this is primarily > because compilers often remove the cast-to-void as part of the parsing > phase, so it's not visible in the parse tree for static checkers. > > --BDS > > On T

Re: New [must_use] property in XPIDL

I'm indifferent to this particular case, but I think that rkent's point about static checking is a good one. Given that C++ has existing annotations that say: - This does not produce a useful return value (return void) - I am explicitly ignoring the return value (cast to void) And that we have

Re: WebRTC connections do not trigger content policies. Should they?

On Tue, Jun 21, 2016 at 12:30 PM, Daniel Veditz <dved...@mozilla.com> wrote: > On Sat, Jun 18, 2016 at 6:37 AM, Eric Rescorla <e...@rtfm.com> wrote: > > > instead of having it sourced from the > > ​ ​ > > advertiser's > > ​ ​ > > origin, t

Re: WebRTC connections do not trigger content policies. Should they?

On Sat, Jun 18, 2016 at 4:55 PM, Anne van Kesteren <ann...@annevk.nl> wrote: > On Sat, Jun 18, 2016 at 2:37 PM, Eric Rescorla <e...@rtfm.com> wrote: > > The priority of this proposed feature seems to depend rather a lot on > > whether enough > > advertisers are us

Re: WebRTC connections do not trigger content policies. Should they?

The priority of this proposed feature seems to depend rather a lot on whether enough advertisers are using WebRTC to deliver ads to make it worth some ad blocker being interest in adding such a blocker. Do we have any evidence on this front? It's worth noting that from a security and tracking

Re: Return-value-optimization when return type is RefPtr

3, but is supported in 2015. See > https://bugzilla.mozilla.org/show_bug.cgi?id=1280295 > > On Thu, Jun 16, 2016 at 12:27 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> Is it worth reconsidering removing implicit conversion from RefPtr to >> T*? >> >> -Ekr >&g

Re: Return-value-optimization when return type is RefPtr

Is it worth reconsidering removing implicit conversion from RefPtr to T*? -Ekr On Thu, Jun 16, 2016 at 9:50 AM, Boris Zbarsky wrote: > On 6/16/16 3:15 AM, jww...@mozilla.com wrote: > >> I think that is the legacy when we don't have move semantics. Returning >> RefPtr won't

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

Also, perhaps function name (__func__) or one of the pretty versions. -Ekr On Tue, May 31, 2016 at 1:20 PM, Jeff Gilbert wrote: > On Tue, May 31, 2016 at 6:18 AM, Gabriele Svelto > wrote: > > On 31/05/2016 13:26, Gijs Kruitbosch wrote: > >> We could

Re: All about crashes

On Wed, May 25, 2016 at 8:53 AM, Steve Fink <sf...@mozilla.com> wrote: > On 05/25/2016 06:09 AM, Eric Rescorla wrote: > >> Under "Ways to prevent" you suggest >> "Ways to prevent (by making them impossible)" and rewriting in JS or Rust, >> using s

Re: All about crashes

Under "Ways to prevent" you suggest "Ways to prevent (by making them impossible)" and rewriting in JS or Rust, using smart pointers, etc. This may prevent crashes in the narrow sense that it prevents SEGVs, etc. but it does not make runtime errors that lead to program shutdown impossible. To take

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

On the topic of debugging, it's worth noting that TLS 1.3 is going to be quite a bit harder to debug from just network traces (without keying material) than TLS 1.2 was because more of the traffic is encrypted. -Ekr On Tue, Apr 26, 2016 at 6:30 AM, Patrick McManus wrote:

Re: Out parameters, References vs. Pointers (was: Proposal: use nsresult& outparams in constructors to represent failure)

I agree with this. FWIW, the Google style guide requires that reference params be const. https://google.github.io/styleguide/cppguide.html#Reference_Arguments -Ekr On Thu, Apr 21, 2016 at 9:51 PM, Jeff Gilbert wrote: > Pointers are prefereable for outparams because it

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 7:57 AM, Nicholas Nethercote <n.netherc...@gmail.com > wrote: > On Thu, Apr 21, 2016 at 3:05 PM, Eric Rescorla <e...@rtfm.com> wrote: > > The general problem that > > it doesn't alleviate is that failure to check the return value leaves you &

Re: Proposal: use nsresult& outparams in constructors to represent failure

I'm sympathetic to the desire to have a single fallible construction function (this is generally how I structure things in C code), but I'm not sure that this is really the right design for it. The general problem that it doesn't alleviate is that failure to check the return value leaves you with

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

This seems like the right question. -Ekr On Thu, Apr 14, 2016 at 9:17 AM, Kyle Huey wrote: > Why should we be the ones to take the web compat hit on this? > > - Kyle > On Apr 14, 2016 1:55 AM, "Chris Peterson" wrote: > > > Summary: Treat cookies set

Re: Triage Plan for Firefox Components

Hmm.. Well, whether platform adopts this universally or not seems like a question for Doug and Johnny. Though, I'm sure they'll take your input seriously. Doug, do you have any thoughts on how long an evaluation period you think is appropriate here? -Ekr On Fri, Apr 8, 2016 at 3:25 PM, Emma

Re: Triage Plan for Firefox Components

Sorry to be dense, but if I understand correctly, you'd like to: 1. Have a policy that all of Gecko needs to triage bugs in a certain way. 2. Redefine how everyone defines priorities? And you think that 24 hours is enough time to get consensus on that. Do I have that right? -Ekr On Wed, Apr

Re: Triage Plan for Firefox Components

On Tue, Apr 5, 2016 at 9:27 PM, Emma Humphries wrote: > It's been a week since I asked for your comments on the plan for triage, > thank you. > > I'm going reply to some general comments on the plan, and outline next > steps. > > Ekt and others said that up to now, individual

Re: Why is Mozreview hassling me about squashed commits?

On Mon, Apr 4, 2016 at 10:26 PM, Mark Côté <mc...@mozilla.com> wrote: > On 2016-04-04 8:41 PM, Eric Rescorla wrote: > > On Mon, Apr 4, 2016 at 9:23 PM, Mark Côté <mc...@mozilla.com> wrote: > >> To answer the original question, though, at this time we have no pl

  1   2   3   >