Re: Enabled CRLite in Nightly

2020-11-11 Thread Martin Thomson
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

Re: Intent To Ship: backdrop-filter

2020-06-09 Thread Martin Thomson
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

Re: Intent to implement: AVIF (AV1 Image Format) support

2020-01-16 Thread Martin Thomson
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

Re: Proposed W3C Charter: Service Workers Working Group

2019-12-06 Thread Martin Thomson
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

Re: Intent to unship: TLS 1.0 and TLS 1.1

2019-12-06 Thread Martin Thomson
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 < >

Re: Intent to unship: DTLS 1.0 for WebRTC

2019-11-13 Thread Martin Thomson
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

Re: Intent to unship: TLS 1.0 and TLS 1.1

2019-10-09 Thread Martin Thomson
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

Re: WebIDL Reviewers Group

2019-09-20 Thread Martin Thomson
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

Re: Intent to unship: TLS 1.0 and TLS 1.1

2019-09-12 Thread Martin Thomson
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

Intent to unship: TLS 1.0 and TLS 1.1

2019-09-11 Thread Martin Thomson
(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

Re: Intent to Implement- Double-keyed HTTP cache

2019-08-21 Thread Martin Thomson
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

Re: Intent to ship: restrict access to request notification permissions from cross-origin iframes

2019-08-09 Thread Martin Thomson
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

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

2019-03-22 Thread Martin Thomson
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

Re: Intent to ship: Dynamic module imports (JS 'import()' syntax)

2019-03-07 Thread Martin Thomson
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 Jon might w

Re: Intent to ship: Dynamic module imports (JS 'import()' syntax)

2019-03-07 Thread Martin Thomson
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 { >

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

2019-02-25 Thread Martin Thomson
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

Re: Intent to require Secure Context for Web Notifications

2019-02-25 Thread Martin Thomson
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

Re: Cookie policy/permission in live documents - proposal

2019-01-24 Thread Martin Thomson
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

Re: Cookie policy/permission in live documents - proposal

2019-01-23 Thread Martin Thomson
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

Re: How do we land `./mach vendor rust` patches, these days?

2019-01-20 Thread Martin Thomson
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,

Re: nasm will soon become a build dependency

2018-12-20 Thread Martin Thomson
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

Re: Intent to implement and ship: UTF-8 autodetection for HTML and plain text loaded from file: URLs

2018-12-12 Thread Martin Thomson
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

Re: Intent to implement and ship: UTF-8 autodetection for HTML and plain text loaded from file: URLs

2018-12-10 Thread Martin Thomson
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

Re: Plan for Sunsetting MozReview

2018-09-05 Thread Martin Thomson
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

Re: DNS Rebinding protection

2018-06-27 Thread Martin Thomson
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

Re: How to request documentation for new features or report problems on MDN

2018-05-16 Thread Martin Thomson
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

Re: Intent to unship: URL.createObjectURL(MediaStream)

2018-04-24 Thread Martin Thomson
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

Re: Intent To Require Manifests For Vendored Code In mozilla-central

2018-04-10 Thread Martin Thomson
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

Re: Intent To Require Manifests For Vendored Code In mozilla-central

2018-04-09 Thread Martin Thomson
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

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

2018-03-19 Thread Martin Thomson
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

Re: Chrome will start marking HTTP pages as "Not secure"

2018-02-08 Thread Martin Thomson
+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

Re: Intent to implement and ship navigator.webdriver

2018-02-05 Thread Martin Thomson
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

Re: Requiring secure contexts for new features

2018-01-16 Thread Martin Thomson
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

Re: Device Orientation API future

2018-01-11 Thread Martin Thomson
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

Re: Device Orientation API future

2018-01-10 Thread Martin Thomson
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

Re: Device Orientation API future

2018-01-10 Thread Martin Thomson
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

Re: Proposed W3C Charter: Second Screen Working Group

2018-01-06 Thread Martin Thomson
>> > > improve on this situation. We 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

Re: Device Orientation API future

2018-01-04 Thread Martin Thomson
s used. > > But, 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 Tho

Re: Device Orientation API future

2018-01-04 Thread Martin Thomson
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 – >

Re: Device Orientation API future

2018-01-04 Thread Martin Thomson
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

Re: Proposed W3C Charter: Second Screen Working Group

2018-01-03 Thread Martin Thomson
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

Re: Device Orientation API future

2018-01-03 Thread Martin Thomson
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

Re: Device Orientation API future

2018-01-03 Thread Martin Thomson
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

Re: Device Orientation API future

2018-01-01 Thread Martin Thomson
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

Re: Follow up on clang-format

2017-09-26 Thread Martin Thomson
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

Re: Follow up on clang-format

2017-09-26 Thread Martin Thomson
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

Re: Coding style: Placement of binary operators when breaking a long line

2017-09-07 Thread Martin Thomson
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

Re: Device Memory header and JS API

2017-09-07 Thread Martin Thomson
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

Re: Device Memory header and JS API

2017-09-06 Thread Martin Thomson
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

Re: Coding style: Argument alignment

2017-08-30 Thread Martin Thomson
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

Re: Coding style: Argument alignment

2017-08-30 Thread Martin Thomson
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

Re: Restricting the Notifications API to secure contexts

2017-08-07 Thread Martin Thomson
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

Re: Extensions and Gecko specific APIs

2017-07-25 Thread Martin Thomson
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

Re: Phabricator Update, July 2017

2017-07-11 Thread Martin Thomson
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

Re: Phabricator Update, July 2017

2017-07-11 Thread Martin Thomson
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

Re: Improving visibility of compiler warnings

2017-05-24 Thread Martin Thomson
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

Re: Intent to ship: NetworkInformation

2017-05-21 Thread Martin Thomson
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,

Re: Improving visibility of compiler warnings

2017-05-20 Thread Martin Thomson
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

Re: Intent to ship: SharedArrayBuffer and Atomics

2017-05-11 Thread Martin Thomson
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,

Re: Ambient Light Sensor API

2017-04-27 Thread Martin Thomson
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 >

Re: Ambient Light Sensor API

2017-04-26 Thread Martin Thomson
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

Re: Ambient Light Sensor API

2017-04-24 Thread Martin Thomson
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

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

2017-02-19 Thread Martin Thomson
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

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

2017-02-16 Thread Martin Thomson
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 >

Re: Exposing SSLStatus to WebExtensions (and possibly extending it)

2017-01-29 Thread Martin Thomson
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 -

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

2017-01-18 Thread Martin Thomson
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

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

2017-01-18 Thread Martin Thomson
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

Re: Intent to implement: HTML5 element

2016-12-23 Thread Martin Thomson
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

Re: Intent to implement: HTML5 element

2016-12-22 Thread Martin Thomson
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

Re: Intent to ship: NetworkInformation

2016-12-19 Thread Martin Thomson
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

Re: Intent to ship: NetworkInformation

2016-12-15 Thread Martin Thomson
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

Re: Proposed W3C Charter: Verifiable Claims Working Group

2016-12-12 Thread Martin Thomson
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

Re: Proposed W3C Charter: Automotive Working Group

2016-11-24 Thread Martin Thomson
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 >

Re: W3C Proposed Recommendation: Webmention

2016-11-03 Thread Martin Thomson
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

Re: Removing navigator.buildID?

2016-11-01 Thread Martin Thomson
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

Re: Windows XP and Vista Long Term Support Plan

2016-10-22 Thread Martin Thomson
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

Intent to ship: TLS 1.3 draft

2016-10-19 Thread Martin Thomson
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

Re: Proposed W3C Charter: Automotive Working Group

2016-10-17 Thread Martin Thomson
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

Re: Proposed W3C Charter: Web of Things Working Group

2016-10-12 Thread Martin Thomson
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

Re: Proposed W3C Charter: Web of Things Working Group

2016-10-12 Thread Martin Thomson
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

Re: Proposed W3C Charter: Web of Things Working Group

2016-10-11 Thread Martin Thomson
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

Re: Intent to put Permission API's .revoke() method behind a pref

2016-08-17 Thread Martin Thomson
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

Re: Intent to put Permission API's .revoke() method behind a pref

2016-08-17 Thread Martin Thomson
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

Re: Intent to put Permission API's .revoke() method behind a pref

2016-08-17 Thread Martin Thomson
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

Re: Checkin-needed requests - Please include complete information in the commit message :)

2016-07-11 Thread Martin Thomson
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

Re: Checkin-needed requests - Please include complete information in the commit message :)

2016-07-10 Thread Martin Thomson
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

Re: MXR permanently offline, please transition to DXR

2016-06-30 Thread Martin Thomson
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

Re: Proposed W3C Charter: Web of Things Interest Group

2016-06-23 Thread Martin Thomson
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.

Re: Generating Visual Studio project files by default

2016-05-24 Thread Martin Thomson
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? ___

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

2016-04-26 Thread Martin Thomson
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.

Re: Intent to (sort of) unship SSLKEYLOGFILE logging

2016-04-26 Thread Martin Thomson
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

Intent to (sort of) unship SSLKEYLOGFILE logging

2016-04-25 Thread Martin Thomson
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

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

2016-04-21 Thread Martin Thomson
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

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

2016-04-21 Thread Martin Thomson
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

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

2016-04-16 Thread Martin Thomson
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

Re: Announcing MozillaBuild 2.2.0 Release

2016-03-29 Thread Martin Thomson
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.

Re: Old XUL, deprecated Error Console

2016-03-23 Thread Martin Thomson
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.

Re: Intent to implement: W3C WebAppSec credentialmanagement API

2016-03-14 Thread Martin Thomson
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,

Re: Intent to implement: W3C WebAppSec credentialmanagement API

2016-03-13 Thread Martin Thomson
Now that is a frightening observation. Is this creating a more persistent (pernicious?) tracking mechanism? In that case, credentials stored by a site should last no longer than cookies. Credentials created by a user maybe can live longer. On 12 Mar 2016 04:41, "Anne van Kesteren"

Re: Intent to implement: W3C WebAppSec credentialmanagement API

2016-03-13 Thread Martin Thomson
On 12 Mar 2016 7:28 PM, "Anne van Kesteren" wrote: > It should be identical to password manager integration. But it is not, though I suppose that a password manager might be exploited to store state. I hope that isn't possible... (note to self, attempt this attack) > > In

  1   2   3   >