Great news JC.
I've been watching this with interest. It's one of those rare cases
where we get a win-win-win. Faster page loads, better security
through more reliable revocation information, and better privacy.
It's taken a lot of effort, but it's definitely worth it.
On Thu, Nov 12, 2020 at
On Wed, Jun 10, 2020 at 8:01 AM L. David Baron wrote:
> It's also something that I think we shouldn't be doing, at least not
> without a clear and relatively short timeline for having the feature
> available across all graphics backends (whether by implementing it
> for more backends or by no long
This sounds good. In the interests of transparency, it might be good to
get this (and AV1 even) added to our standards positions repo (
https://mozilla.github.io/standards-positions/). I don't know if this
necessarily rises to "important" in the same way that AV1 does, but it
would be good to hav
I agree with this assessment. Maintaining accountability when sites don't
have a window to attribute activity to is a recurrent issue that this group
has never properly resolved. Asking for permission seems to be the defense
of choice, but that only prevents the initiation of unaccountable
activi
On Fri, Dec 6, 2019 at 5:08 AM wrote:
> >> … Safari, Firefox, Edge and Chrome are removing support for TLS 1.0 and
> 1.1 in March of 2020. …
>
> Is that (timeline) still a _shared_ intent – for all four browsers?
>
I recently confirmed this, yes.
> Re: the screenshot at <
> https://user-images
This is somewhat more aggressive than our plans for HTTPS. The usage rate
is significantly higher (that's about 3x) and we don't have DTLS 1.3 yet,
though the spec is now close to publication.
On balance, this is still justifiable given the nature of this feature.
On Fri, Nov 8, 2019 at 5:29 PM
On Sun, Oct 6, 2019 at 6:35 PM wrote:
> I would agree that these changes and changes that have already occurred
> over the last year or so, have broken access to admin consoles of older
> networking kit. I had to pull a WinXP machine out of storage recently to
> manage an HP 2610 switch.
>
For t
Hi Nika, this is great. Is there a documented process for setting up and
maintaining the alias?
On Sat, Sep 21, 2019 at 1:37 AM Nika Layzell wrote:
> As of yesterday, a phabricator reviewers group for WebIDL has been created.
> If your patch needs review for WebIDL changes, you can tag this gro
On Thu, Sep 12, 2019 at 5:50 PM Henri Sivonen wrote:
> Do we know what the situation looks like for connections to RFC 1918
> addresses?
>
That's a hard one to even speculate about, and that's all we really have
there. Our telemetry doesn't really allow us to gain insight into that.
The big que
(We’ve had a couple of blog postings about this [1][2], but this list
hasn’t received an explicit intent notice. Now that we’re starting to make
changes, it seems like a good time to correct that oversight.)
TLS 1.0 and 1.1 are old. They are also broken in myriad subtle ways. [3]
explains in mor
Hi Sebastian,
I'm glad to see us moving toward having better isolation in this way.
In discussions of this sort of keying strategy, the guidance I repeatedly
hear is that "double-keying" isn't sufficient and that you need to key on
the chain of origins. That is, if A frames B and C, and B in tur
This is a great move for improving transparency and accountability of
sites. Good work to all those who helped get us this far.
On Sat, 10 Aug. 2019, 01:02 Ehsan Akhgari, wrote:
> Hi everyone,
>
> We currently allow cross-origin iframes to request notification
> permissions. This is problematic
On Thu, Mar 21, 2019 at 1:11 PM Tom Ritter wrote:
> Okay, good, not making this data available until the user activity
> engages with the gamepad/VR controller (mostly) assuages my concerns
> on this component. My remaining concern is around the sensitivity of
> axis movement. If I have my contro
Thanks. (And ugh, but that's how these things go.)
On Fri, Mar 8, 2019 at 2:40 PM Boris Zbarsky wrote:
> On 3/7/19 10:27 PM, Martin Thomson wrote:
> > Is there a way that doesn't rely on eval or eval-like mechanisms?
>
> I suspect the only detectable thing here (and J
Is there a way that doesn't rely on eval or eval-like mechanisms?
On Fri, Mar 8, 2019 at 1:55 PM Boris Zbarsky wrote:
> On 3/7/19 6:14 PM, rekt...@gmail.com wrote:
> > Is there any way to feature detect support for import() syntax?
>
> In Firefox, yes, as far as I can tell:
>
>try {
> n
To add to Dan's comments here...
Assuming that I'm reading this correctly [1], the fingerprinting risks are
pretty extreme here. In the touch spec, we have a monotonically increasing
counter that doesn't appear to be origin-bound in any way. What is the
purpose of this identifier? In the light
Thanks for doing this Johann.
On Tue, Feb 26, 2019 at 12:31 AM Johann Hofmann
wrote:
> The Notifications API [0] allows websites to show notifications outside of
> the browser viewport, integrating into the native OS-like notification
> system. In combination with service workers this can be use
Thanks for the piece about StoragePrincipal. I think that motivates this
well for me. Changing principal is not something we can do trivially (or
not something we should even contemplate ideally).
I do want to pick out one comment you made, which is probably off-topic for
the thread, but I think
On Thu, Jan 24, 2019 at 8:33 AM Andrea Marchesini
wrote:
> With my proposal, you will have 2 tabs, loading the same origin with 2
> different cookie behaviors.
> Let's assume that one is BEHAVIOR_ACCEPT and the other one BEHAVIOR_REJECT,
> doesn't matter the order.
> The 2 tabs will not be able t
On Sat, Jan 19, 2019 at 7:42 AM Emilio Cobos Álvarez
wrote:
> For others (assuming you're hitting the max_post_size limit) I think
> you're out of luck and need to submit them via splinter[2].
>
When vendoring NSS, which we do often, we've sometimes resorted to asking
for review for a script, or
On Fri, Dec 21, 2018 at 3:01 PM Cameron McCormack wrote:
> On Fri, Dec 21, 2018, at 11:05 AM, Thomas Daede wrote:
> > nasm is now required for building on Linux.
>
> Is there a minimum version required? I am getting errors like this
> building:
>
The OP said >= 2.10. But you appear to have tha
On Thu, Dec 13, 2018 at 1:14 AM Henri Sivonen wrote:
> I changed the limit to 4 MB.
SGTM.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
This seems reasonable, but 50M is a pretty large number. Given the
odds of UTF-8 detection failing, I would have thought that this could
be much lower. What is the number in Chrome?
I assume that other local sources like chrome: are expected to be
annotated properly.
On Mon, Dec 10, 2018 at 11:2
On Wed, Sep 5, 2018 at 4:42 PM Mark Banner wrote:
> A couple of things that may help with the scrolling & finding, that
> people may or may not have found yet...
The keyboard shortcuts are more accessible (type ? to see the list
[1]), though in my experience they interact poorly with concurrent
m
On Thu, Jun 28, 2018 at 1:21 AM Benjamin Francis wrote:
> On 25 June 2018 at 16:50, Brannon Dorsey wrote:
>
> > As far as I see it, a
> > domain name should never be allowed to respond with a private IP address
> > moments after it first responded with a public IP address.
> >
>
> If I understand
Hi Chris,
I assume that "just fix it" is still a viable alternative to the processes
you describe. For small things, that might be easier for all involved.
On Thu, May 17, 2018 at 5:39 AM Chris Mills wrote:
> Hi all,
> I am sending a mail around to explain how to request MDN documentation
for
This seems like it's about time. bz's numbers aren't awe-inspiring,
but low enough that I think we'll manage.
I checked, and there was a question about reviving this in the spec,
but that resolved over a year ago (just before when the deprecated
message was added in Firefox, perhaps coincidentall
On Tue, Apr 10, 2018 at 6:41 AM, glob wrote:
>> You don't permit the use of a tag for vendoring, is that intentional?
>
> to echo gps and mike's responses use of a sha to is preferred over tags.
Maybe. We currently use tags.
Think about the usage model. If the process is to author the YAML,
th
This seems like a good idea.
Please consider adding hg.mozilla.org to your list of things you will
clone from. That will allow us to remove some ugly hacks from the
tree for vendoring NSS and NSPR. (libffi uses the same script, but it
seems to be on GitHub now, so that seems like an easy win ass
Yes, it pays to remember that this is Nightly.
The precautions Henri suggests are good, but more appropriate to
experiments we would do on Release. For TLS 1.3, we did that sort of
thing so that we could get measurements from Release; we just flipped
the switch to "on" for Nightly.
I don't know
+ffxdev
There's a tangible difference between text saying "Not Secure" and a
broken lock icon. I think that we're close, but we'd be making a
stronger statement than Chrome if we did this.
On Fri, Feb 9, 2018 at 8:17 AM, Chris Peterson wrote:
> Chrome will start marking HTTP pages as "Not secur
On Tue, Feb 6, 2018 at 3:37 AM, Andreas Tolfsen wrote:
> Motivation:
> To give web authors a way to infer if user agent is controlled by
> automation, so the document can take alternate code paths when under
> test.
Can you speak more about why this is a good idea? I've poor
experience with "thi
Great news. Thanks to all those involved for getting to this point.
Anne, your posting suggests an exception is likely if:
* other browsers already ship the feature insecurely
* it can be demonstrated that requiring secure contexts results in
undue implementation complexity.
Either of these cri
As Anne said, I don't know why you would define a new API rather than
enhancing the existing one, other than NIH. But I guess the damage is
now done.
On Fri, Jan 12, 2018 at 4:48 AM, Blair MacIntyre wrote:
>> On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre
>> wrote:
>>> First, this discussion
On Thu, Jan 11, 2018 at 3:39 PM, Chris Van Wiemeersch wrote:
> Anne and Martin, can you think of changes to request for the Sensor API that
> we would resolve or reasonably improve the existing fingerprinting concerns?
In general, we can't improve the situation by adding more
functionality. That
What Anne said. None of these actions help address the primary concern.
On Wed, Jan 10, 2018 at 2:23 PM, wrote:
> Exciting to hear, Kyle!
>
> As mentioned earlier, Chrome for Android M63+ has shipped an implementation
> (disabled by default, with an Origin Trial) of the Generic Sensor API, but
hope it will allow for interoperable
> >> > > discovery of, identification of, and communication with presentation
> >> > > displays. However, we're deeply concerned about chartering a second
> >> > > iteration of the work that continues building
t, perhaps this is too confusing.
>
> For the perms API, I imagined it might just work with devicemotion: setting
> up the callback could trigger a perms request, and the data would only start
> flowing on acceptance.
>
>> On Jan 3, 2018, at 11:52 PM, Martin Thomson wrote:
>>
On Thu, Jan 4, 2018 at 9:06 PM, chris wrote:
> Thanks for the clarification, Martin. Providing that the UA persists
> permissions (based on user action –or perhaps also leveraging Google’s Safe
> Browsing API which Firefox and all other browsers already rely upon –
> revoked and prompted -> denied
On Thu, Jan 4, 2018 at 5:50 PM, wrote:
> FYI: As implemented in Chrome, permission is automatically granted to use the
> Generic Sensor API (`chrome://flags/#enable-generic-sensor`) in secure
> contexts (e.g., HTTPS, localhost).
Requiring secure contexts is not a security feature. It's necess
Without the protocol pieces, this remains vendor-specific. We should
comment on this and make it clear that we think that definition of a
generic protocol for interacting with the second display has not been
given sufficient priority. Allowing this to proceed without a generic
protocol would be b
On Thu, Jan 4, 2018 at 1:09 PM, Blair MacIntyre wrote:
> We could chat about it, sure; how do you envision it working without
> breaking old websites?
With the understanding that this is purely spitballing...
We would stop providing events (or provide them with extremely low
frequency [1]), bu
On Thu, Jan 4, 2018 at 2:52 AM, Blair MacIntyre wrote:
> I was more concerned about the idea (or, at least what I though might be
> suggested) that you only get orientation if they give location permission.
> This seems overkill: even if I know what the data means, I can see uses of
> orientation
The suggestion that was made in the past was to tie orientation to
geolocation. I think that this would be obvious enough to pass.
Orientation is basically a refinement of position. It clearly makes
sense for AR applications. Pure VR applications might only care about
relative orientation and so
On Wed, Sep 27, 2017 at 7:34 AM, Mike Hommey wrote:
> And then you end up with something like:
>
> class Foo {
> Type MethodA() { do_something(); }
> Type MethodB()
> {
> do_something_that_happens_to_be_long_enough_not_to_fit_on_the_same_line();
> }
> Type MethodC() { do_something_el
On Tue, Sep 26, 2017 at 10:49 PM, Sylvestre Ledru
wrote:
>> clang-format messes up really badly many macros.
>> For example nsElementTable.cpp becomes unreadable.
>
> Yeah, for this kind of structure & presentation layout, we should just
ignore the formatting on these.
>
> It is hard for reformatt
On Fri, Sep 8, 2017 at 1:08 AM, Ehsan Akhgari wrote:
> The great majority of code changing is quite expected for any project
> switching to clang-format, since as it turns out automated tools are much
> better at doing this grunt work than humans are. The reason projects choose
> to switch to usi
On Fri, Sep 8, 2017 at 5:32 AM, Tom Ritter wrote:
> On Thu, Sep 7, 2017 at 1:09 PM, Shubhie Panicker via dev-platform
> wrote:
>> Curious - are there concerns with implementing Client Hints in general?
>
> Yes. But the fingerprinting team (specifically, I'm not sure what
> other teams have done)
Why do the numbers need to be standardized? Could we give browsers
the ability to change the value in response to their understanding of
the current situation.
Surely an Android device is easily identifiable as such, so we could
choose values that reflect our Android population at the current
mom
On Wed, Aug 30, 2017 at 5:21 PM, Sylvestre Ledru wrote:
> Could you report a bug? We wrote a few patches upstream to improve
> the support of our coding style.
This isn't a bug either, but I've noticed that alignment anywhere can
cause collateral changes. `clang-format -style=Mozilla -dump-confi
On Wed, Aug 30, 2017 at 12:07 PM, L. David Baron wrote:
> I think I do this because (b) has the disadvantage that more code
> changes require touching additional lines, which is both changes
> blame and is extra work (although it's not extra work if we're using
> clang-format tree-wide). Option (
More than fine, this is an overdue change :)
Notifications being available on http:// origins is a source of a
small amount of pain for web push, because the two share the same
permission.
On Tue, Aug 8, 2017 at 2:24 AM, Eric Rescorla wrote:
> This seems fine.
>
> -Ekr
>
>
> On Mon, Aug 7, 2017
On Wed, Jul 26, 2017 at 6:20 AM, Andrew Overholt wrote:
> On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote:
>> Should we moz-prefix moz-specific extensions?
>
> We have been trying not to do that for Web-exposed APIs but maybe the
> extensions case is different?
I don't think that it is. If
On Wed, Jul 12, 2017 at 1:34 PM, Byron Jones wrote:
> instead of disabling splinter for phabricator backed products, we could make
> it a read-only patch viewer.
Given the number of bugs that exist with patches attached, that would
be greatly appreciated. I would also assume that attaching patch
On Wed, Jul 12, 2017 at 6:41 AM, Mark Côté wrote:
> * MozReview and Splinter turned off in early December.
Is this bugzilla-wide? I know that other project use splinter still.
Will those projects be able to use phabricator for their projects?
For instance, NSS uses a separate instance of phabri
On Thu, May 25, 2017 at 6:03 AM, Nathan Froyd wrote:
> Where does NSS do this? Cloning the NSS tree and grepping for
> sign-compare turns up no disabling of -Wsign-compare, except perhaps
> in XCode for gtest itself.
My bad, -Wsign-compare is in -Wextra, and we don't enable anything
extra. We d
On Sat, May 20, 2017 at 2:05 AM, Ben Kelly wrote:
> Can the people who have concerns about the NetworkInformation API please
> provide the feedback to google on this blink-dev thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/UVfNMH50aaQ/FEQNujAuBgAJ
In short, I don't think that t
On Sat, May 20, 2017 at 4:55 AM, Kris Maglione wrote:
> Can we make some effort to get clean warnings output at the end of standard
> builds? A huge chunk of the warnings come from NSS and NSPR, and should be
> easily fixable.
Hmm, these are all -Wsign-compare issues bar one, which is fixed
upstr
On Thu, May 11, 2017 at 5:57 PM, Lars Hansen wrote:
> We do think there are
> architectural improvements that hardware manufacturers, operating systems,
> and browsers can make [19], and we intend to investigate them.
I think that the work you cite is promising. However, listening to
this presen
On Fri, Apr 28, 2017 at 1:56 PM, Ehsan Akhgari wrote:
>> While it does not address the attack, it should be limited to secure
>> context, if we keep the API. It's actually in the spec.
>
> Why is that an advantage? Any attacker can use a secure context. The word
> "secure" here relates to the sec
On Wed, Apr 26, 2017 at 10:26 PM, Eric Rescorla wrote:
>> Surely we can avoid this problem without being so
>> drastic?
>
>
> Perhaps, but actually designing such security measures is expensive, so
> absent some argument that this is in wide use, probably doesn't
> pass a cost/benefit test.
Yeah,
I think that 60Hz is too high a rate for this.
I suggest that we restrict this to top-level, foreground, and secure
contexts. Note that foreground is a necessary precondition for the
attack, so that restriction doesn't really help here. Critically,
rate limit access much more than the 60Hz recom
On Mon, Feb 20, 2017 at 3:18 AM, smaug wrote:
> I don't care too much about &&/|| coding style, though the current style
> does feel easier to
> read, per the reasoning dmajor gave.
I suspect that a lot of people think this way. While it's tempting to
suggest that arguments like "that's the way
On Sat, Feb 18, 2017 at 9:28 AM, Bobby Holley wrote:
>> If our main repository is going to always be under the control of some
>> official clang-format style, it should be possible for anybody to pull the
>> repository, and use a different formatter locally with their favorite
>> style. And when p
On Fri, Feb 17, 2017 at 10:39 AM, Robert O'Callahan
wrote:
>> Using clang-format on the entire tree has the massive value of:
>
> Also, it's very liberating not having to think about formatting while
> writing code, knowing it will be automatically fixed up later. This is
> especially helpful for
I think that it is reasonable to expose this sort of information to
web extensions, and - for some things - possibly even to the web.
I don't think that we should start with nsISSLStatus directly. Though
it does have some relevant values, we should be careful to specify -
and justify - individual
On Thu, Jan 19, 2017 at 10:17 AM, Michael Layzell
wrote:
> @Martin There is a pref (dom.ipc.processCount.webLargeAllocation - default
> 2) which controls the maximum number of processes which may be allocated to
> Large-Allocation processes. Any requests past that number (firefox-globally)
> will
On Thu, Jan 19, 2017 at 9:21 AM, Michael Layzell
wrote:
> Security & Privacy Concerns: none
I doubt that this is true. You have provided a way for sites to gain
a whole process to themselves, on request. Denial of service seems
like something that would need to be considered if you intend to sh
On Fri, Dec 23, 2016 at 6:20 PM, Boris Zbarsky wrote:
>> I mean, the attribute is probably a lost cause
>
> Why? Is there significant usage, or at least wide implementation, of that
> part of the API already? The original intent said that only Chrome is
> shipping this.
Fair point. I guess the
On Fri, Dec 23, 2016 at 7:14 AM, Boris Zbarsky wrote:
> Note that I expect that this spec was written before Promise was a thing.
> The setup where we return a value in an attribute of the element (!) is
> pretty bizarre...
Is this irredeemable? I mean, the attribute is probably a lost cause,
bu
On Mon, Dec 19, 2016 at 8:23 PM, Gervase Markham wrote:
> We already do network change detection now, ISTR; could we pop a
> doorhanger when we get a network change event, of the form of something
> like "maintain 'expensive data' status Y/N?"...?
No more doorhangers please. I have no issue with
On Fri, Dec 16, 2016 at 10:28 AM, Boris Zbarsky wrote:
> 2) Figure out a way to map the one bit of information we actually want to
> expose into some sort of values that look like the existing API. Change the
> spec as needed to allow tweaks we want to make here (e.g. to allow having
> the max sp
On Tue, Dec 13, 2016 at 5:56 AM, Eric Rescorla wrote:
> 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.
A lot hinges on the nature of that identifier, bu
I'm not going to respond in detail, but I think that this quote cuts to the nub.
On Thu, Nov 24, 2016 at 10:09 PM, wrote:
> [W3C Auto] A number of Automotive Manufacturers and Tier 1 suppliers have
> contributed to the ideas in the specification which focusses on exposing
> vehicle signals and
On Fri, Nov 4, 2016 at 1:25 PM, L. David Baron wrote:
> W3C Editor's draft: https://webmention.net/draft/
Wow, that is an extraordinarily wordy document for something that does
so little. It's the first I've heard of this, but it's remarkably
similar to (albeit much narrower than):
https://ww
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 can't be fingerprinted pretty reliably? Inevitably, the more
> features we add to the platform, the
On Sat, Oct 22, 2016 at 8:16 PM, wrote:
> My concern is that by killing digital certificate updates and TLS updates,
> still in use machines whose main purpose is Internet access are essentially
> bricked.
Yep, I just designated a relatives machine to recycling on that basis.
I could have upda
As of Firefox 52 I intend to turn TLS 1.3 on by default. TLS 1.3 has
been developed using the existing security.tls.version.max preference
to control maximum version.
TLS 1.3 is the next version of TLS, the protocol that secures the web.
TLS 1.3 removes old and unsafe cryptographic primitives, it
This seems to be a more specific instance of WoT. As such, the goals
are much clearer here. While some of the concerns with the WoT
charter apply (security in particular!), here are a few additional
observations:
Exposing the level of information that they claim to want to expose
needs more priv
On Thu, Oct 13, 2016 at 11:26 AM, Tantek Çelik wrote:
> Security is the number one problem for anything "ot" (iot, wot,
> wotever),
I agree with this sentiment, but I don't think that we need to insist
that a new W3C group solve these issues. I'm very much concerned with
the question of how a ne
On Thu, Oct 13, 2016 at 6:21 AM, Benjamin Francis wrote:
> Much more compelling is the member submission from EVRYTHNG which also forms
> the basis of the book, Building the Web of Things.
Yes, that is a much clearer articulation of a vision. It starts going
off the rails in a few places as it g
On Tue, Oct 11, 2016 at 12:52 PM, L. David Baron wrote:
> My initial reaction would be to worry about whether there's
> properly-incubated material here that's appropriate to charter a
> working group for, or whether this is more of a (set of?) research
> projects. W3C has an existing Interest Gr
On Wed, Aug 17, 2016 at 5:34 PM, Anne van Kesteren wrote:
> Interesting, I guess I didn't realize that covered more than just
> query(). If we ship a subset of an API it probably would help to be
> clear, indeed.
Well, it only mentioned .query() explicitly, but then said "other
parts will be impl
On Wed, Aug 17, 2016 at 5:02 PM, Anne van Kesteren wrote:
> The main problem with query as I see it is that since we haven't
> agreed on what permissions are keyed on, an application cannot really
> do anything with the answer it gets from query. E.g., communicating
> the answer with other open ta
Sounds like a good plan.
(For those who might be wondering: .request() was never exposed.)
On Wed, Aug 17, 2016 at 2:48 PM, wrote:
> Summary: It seems we prematurely shipped the .revoke() method on the
> Permissions API before it was stable or deciding if we even wanted it in the
> platform.
On Mon, Jul 11, 2016 at 2:18 PM, Xidorn Quan wrote:
> Isn't it still necessary for people who don't yet have permission to
> push?
That suggests to me that there are missing safeguards on autoland.
Otherwise we could just enable it even for those with try access.
> I also use checkin-needed for
Is now the right time to start talking about retiring checkin-needed,
or is it still heavily used?
On Sat, Jul 9, 2016 at 4:58 AM, Gregory Szorc wrote:
> On Fri, Jul 8, 2016 at 11:39 AM, Felipe G wrote:
>
>> Is there a way to make the checkin-needed flag generate a template comment
>> (like the
On Fri, Jul 1, 2016 at 9:55 AM, Robert O'Callahan wrote:
> In theory responses 301 and 308 mean "permanent redirect" so the browser
> could do that for those responses.
Those would only work for as long as the 3xx is remembered, and it
wouldn't work for /x if you have only seen /y redirect.
To g
On Thu, Jun 23, 2016 at 3:19 AM, Anne van Kesteren wrote:
> We should just let them do their thing and do our thing elsewhere.
This seems like a reasonable plan. Unless and until someone thinks
that a course correction is feasible, or decides that it's worth
trying.
_
On Tue, May 24, 2016 at 7:29 PM, Jeff Gilbert wrote:
> What's the build-time impact of this?
The implicit question being, if this impact is non-zero, can I turn it
off? Also, does it make any sense to do this on try machines?
___
dev-platform mailing l
On Tue, Apr 26, 2016 at 6:08 PM, Jonas Sicking wrote:
> Limiting this to aurora builds might make the most sense here since
> that's what we're pushing as the build that developers should use.
I'm OK with that; that's why I asked here.
https://bugzilla.mozilla.org/show_bug.cgi?id=1188657
___
On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan wrote:
> Could we probably restrict it to non-release builds (aurora and nightly)
> rather than restrict them to debug builds only? Debug builds are harder to
> get, and are slow.
That was suggested, but we decided against it in bug 1188657. I think
t
In NSS, we have landed bug 1183318 [1], which I expect will be part of
Firefox 48.
This disables the use of the SSLKEYLOGFILE environment variable in
optimized builds of NSS. That means all released Firefox channels
won't have this feature as it rides the trains.
This feature is sometimes used t
On Fri, Apr 22, 2016 at 1:05 AM, Nicholas Nethercote
wrote:
> The third example I looked at was CycleCollectedJSRuntime. Again
> problems, specifically this line in Init():
>
> mOwningThread->SetScriptObserver(this);
Others have already said what I would have here generally, but this
example is
I prefer the fallible, if failed return null else return new pattern
myself also. With a little RAII, it keeps manual cleanup to a
minimum.
On Thu, Apr 21, 2016 at 8:24 PM, Nicholas Nethercote
wrote:
> - It doesn't appear to work with stack-allocated objects?
The advantage with a heap-allocated
On 17 Apr 2016 2:37 AM, "Haik Aftandilian" wrote:
>
> Sites might depend on a combination of https and non-https cookies and
then
> act strangely when a user returns to the site with only the https cookies.
This is also known as a security vulnerability. See
https://www.usenix.org/conference/usen
I would like to see other browsers on board before taking on these risks.
And a lot more testing.
For instance, is there a way to collect telemetry on the impact of
such a change without actually implementing it? Does restricting it
to 3rd party requests change things?
On Fri, Apr 15, 2016 at 1
On Wed, Mar 30, 2016 at 12:41 PM, Xidorn Quan wrote:
> I'd suggest you use https instead, it seems to work with ftp.mozilla.org :)
Indeed. Don't drop the scheme entirely either, since Firefox attempts
to use FTP, which isn't available on that server.
_
On Wed, Mar 23, 2016 at 10:59 PM, Philip Chee wrote:
> Thunderbird cannot migrate (easily). The only functionality in Devtools
> that they currently can use is the Debugger (as a remote client).
If they are alone, then maybe they might consider adoption.
__
I don't think that there was any misunderstanding in what it is that
is being proposed, just disagreement about cost-benefit.
On Mon, Mar 14, 2016 at 8:02 PM, Mike West wrote:
> Websites use passwords today. While I agree that we can and should be
> working on something better, I don't think that
1 - 100 of 262 matches
Mail list logo
