Re: Target Milestone field in bugzilla

On 1/9/2014 9:47 AM, Gavin Sharp wrote: In theory (mine at least), the field is free to be used for planning which release you want the bug fixed in, before the bug is fixed. After the bug is fixed, it should be used as you describe. Some groups do use the field this way, for example the NSS

Re: Overriding the CSP for privileged protocols

On 6/5/2014 8:50 AM, Boris Zbarsky wrote: On 6/5/14, 11:39 AM, Matthew Gertner wrote: The problem is that on sites the enforce their own CSP, the resources may not be loaded. For example, github.com has script-src set to 'self' so it won't load stylesheets via our protocol. Is there any way

Alternative add-on signing proposal

Many of you may have seen the earlier add-on file registration and signing discussions. I have posted a revised proposal that requires all add-ons to be signed (AMO-hosted add-ons will be signed automatically) to the mozilla.addons.user-experience group/list. If you're interested in this

Re: Intent to implement: Disabling auto-play videos on mobile networks/devices?

On 8/24/2014 6:21 PM, Eric Rescorla wrote: FWIW, to the best of my knowledge WebRTC calls do not require a click. But you have to click on the door-hanger to share camera/mic (or be on a site you have already trusted not to abuse the permissions). -Dan Veditz

Re: Restricting gUM to authenticated origins only

On 9/8/2014 2:16 AM, Mounir Lamouri wrote: On Sun, 7 Sep 2014, at 04:56, Martin Thomson wrote: It's more the case that a persistent positive grant from permission manager would be ignored for non-secure origins and non-secure origins would not show any option to persist. I don't know the

Re: Intent to Implement: webview

On 10/13/2014 9:15 AM, Jonas Sicking wrote: This will only be exposed to privileged and certified apps, right? Other content that does createElement(webview) will simply get a HTMLUnknownElement, right? What does an unprivileged app get if it tries to use iframe mozbrowser? Probably not an

Re: Breakdown of Firefox full installer

On 10/13/2014 9:25 PM, Chris Peterson wrote: Going forward, it would be interesting to see a dashboard track Firefox installer size every day (or show every changeset's delta on Treeherder). We used to have http://arewesmallyet.com -- I found references to it as late as a year ago but it seems

Re: Breakdown of Firefox full installer

On 10/13/2014 4:54 PM, Chris More wrote: For example, the win32 installer for Firefox 32 is 34MB. Remember the days when Asa would jump all over people for breaking the 5Mb barrier? https://wiki.mozilla.org/Download_Size -Dan Veditz ___ dev-platform

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

On Thu, Jan 29, 2015 at 10:32 PM, L. David Baron dba...@dbaron.org wrote: There are a number of problematic aspects to this charter to which we object: (1) The Confinement with Origin Web Labels deliverable is described in a way that makes it unclear what the deliverable would do. It

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

On Wed, Feb 11, 2015 at 2:02 AM, Mike West mk...@google.com wrote: https://mikewest.github.io/internetdrafts/origin-cookies/draft-west-origin-cookies-00.html https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-00.html Not many people are interested

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

A new version of the charter has been uploaded that hopefully addresses these objections On Thu, Jan 29, 2015 at 10:32 PM, L. David Baron dba...@dbaron.org wrote: (1) The Confinement with Origin Web Labels deliverable is described in a way that makes it unclear what the deliverable would

Re: Intent to deprecate: Insecure HTTP

On Tue, Apr 14, 2015 at 3:29 AM, Henri Sivonen hsivo...@hsivonen.fi wrote: I think we should make ​ ​ the UI designation of plain http undesirable once x% the sites that ​ ​ users encounter on a daily basis are https. Since users don't interact ​ ​ with the whole Web equally, this means

Re: No more binary components in extensions

The patch in the bug removes it from the shared manifest parser, Thunderbird and SeaMonkey are out of luck unless they fork this. -Dan Veditz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Voting in BMO

On Thu, Jun 11, 2015 at 1:18 PM, Mike Hoye mh...@mozilla.com wrote: The word vote implies that the act of voting has a direct effect on the outcome, which is clearly not the case here and really shouldn't be. But that's probably the root of a lot of community frustration. ​Forums like Reddit

Re: Firefox still blocks the (fixed) Java Deployment Toolkit click-to-play popup displays wrong item repeatedly

The Java Deployment Kit can be used to force the use of a down-rev vulnerable version of Java if it's installed and even prompt for its installation (which a large number of users will fall for, even if a small percent). It's an enterprise feature and an enterprise-managed deployment of Firefox

Re: FYI: e10s will be enabled in beta 44/45

On Mon, Dec 7, 2015 at 4:36 AM, Kurt Roeckx wrote: > On 2015-12-04 19:43, jmath...@mozilla.com wrote: > >> Not an issue since initial rollout to beta and release will be to users >> who do not have addons installed. >> > > Is it even possible to have no addons installed? Firefox

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

On Sat, Jun 18, 2016 at 6:37 AM, Eric Rescorla wrote: > instead of having it sourced from the > ​ ​ > advertiser's > ​ ​ > origin, they instead stand > up ".publisher.example.com" > ​ ​ > and > ​ ​ > point > ​ ​ > it at the advertiser's > IP addresses (via an A record to the

Re: Triage Plan for Firefox Components

On Thu, Mar 31, 2016 at 12:28 PM, Milan Sreckovic wrote: > I’m going to start and keep arguing that we do not want to have an > explicit name for that largest bucket of “wishlist” bugs, and should > instead have it marked by the absence of a tag. ​What distinguishes a

Re: Moving XP to ESR?

On 4/20/16 11:53 AM, Armen Zambrano G. wrote: > Would it make more sense to have a relbranch instead of using ESR? Oh lordy, no! It's hard enough diverting engineering work to supporting a single ESR 9 months after the fork. Why would we do two of them? How would a relbranch differ from ESR? >

Intent to Implement and ship: cookie prefixes

The "Cookie prefix" adds restrictions to how cookies with two specific prefixes may be used. This addresses some of the Weak Confidentiality and Weak Integrity concerns noted by RFC 6265 ( https://tools.ietf.org/html/rfc6265#section-8.5). Cookies whose names start with "__Secure-" or "__Host-"

Re: HTML spec changes about data: URIs and origins

On Tue, Sep 13, 2016 at 12:25 PM, Boris Zbarsky wrote: > Probably; we know they get created; what we don't know is how they're used. ​Since Gecko is the only engine that behaves this way we can be reasonably sure we won't find public "must use Firefox" web sites depending on

Re: W3C Proposed Recommendation: CSP2 (Content Security Policy 2)

We have implemented CSP2 and are in support of it's adoption as a standard. -Dan Veditz On Mon, Nov 7, 2016 at 10:07 PM, L. David Baron wrote: > A W3C Proposed Recommendation is available for the membership of W3C > (including Mozilla) to vote on, before it proceeds to the

Re: Expanding regular regression triage to include crashes?

On Mon, Dec 19, 2016 at 10:00 PM, Kan-Ru Chen wrote: > I think the most important is to identify whether the crash bugs are > regressions so they can be tracked accordingly. I would guess that crash bugs filed by project Uptime are going to be (or at least look like)

Re: Better download security through browsers

Most people working on sub-resource integrity has wanted to extend SRI to downloads, it was even in the initial version of the spec but foundered in the weeds of edge cases iirc. I don't see an open issue for it though: looks like it got lost in the transition from our old repo to the new one.

Re: Better download security through browsers

On Mon, Mar 27, 2017 at 1:22 AM, Frederik Braun wrote: > UI hooks, for the SafeBrowsing > ​ ​ > malicious file checks, where we really, > ​ ​ > really discourage you from using > ​ ​ > the downloaded file but you can still click around that with lots of > ​ ​ > left-clicking.

Re: Third Party Library Alert Service

On Fri, Mar 17, 2017 at 3:26 PM, Ehsan Akhgari wrote: > We have library imports that are forks, for example > ​ ​ > dom/media/webaudio/blink, as the README file explains. That should > probably be removed from that list. > ​Forks are tricky. Just because we can't

Re: Intent to change editor newline behavior

On Wed, Apr 5, 2017 at 7:14 AM, Aryeh Gregor wrote: > > really help. :-( But to me it seems like the kind of thing that we'd > > want to be able to quickly turn off on the release channel through > > shipping a hotfix add-on that sets a pref if something goes wrong... > >

Re: Retaining Nightly users after disabling of legacy extensions

Don't do (c) -- its pointless. You won't be helping us test nightly changes and will miss any important fixes (especially security ones). Go ahead and switch to beta if you have to. Your extensions will work, you'll be helping us ship a good 56, and you'll get security fixes. Hate to lose nightly

Re: Phabricator and confidential reviews

On Wed, Aug 9, 2017 at 12:20 AM, Axel Hecht wrote: > I think we should strive to have as few people as possible with general > access to security bugs. ​We do. We've reduced the number of people with access, and split the "client" security group into ~10 sub groups so that

Re: Phabricator and confidential reviews

On Tue, Aug 8, 2017 at 5:30 PM, Mark Côté wrote: > I am not sure how often CCed users are involved with confidential bugs' > patches > ​[​ > ​] Anecdotally I have been told that a lot of the time users are CCed > just to be informed of the problem, e.g. a manager might

Re: Removal of deprecated apis

On Fri, Aug 11, 2017 at 2:19 PM, Frank-Rainer Grahl wrote: > Great that you are so zealous to remove deprecated apis from the tree. I > just wish I would see the same amount of work put into fixing web > extensions shortcomings. If you're not seeing that we've put multiples of

Re: Phabricator Update, July 2017

On Wed, Jul 12, 2017 at 8:54 AM, Byron Jones wrote: > Consider that we are talking about "turning off" mozreview now. Will all >> the bugzilla links to those reviews go dead? Or do we have to maintain a >> second service in read-only mode forever? >> > > the patches will be

Re: Phabricator and confidential reviews

On Tue, Aug 8, 2017 at 11:38 PM, Nicolas B. Pierron < nicolas.b.pier...@mozilla.com> wrote: > However, users outside of the security group(s) can see confidential bugs >> if they are involved with them in some way. Frequently the CC field is >> used as a way to include outsiders in a bug. > > >

Re: nsIURI API changes - punycode domain names

On Wed, Aug 9, 2017 at 9:57 AM, Valentin Gosu wrote: > This is a definite improvement in terms of web-compat. document.origin, > location.href, etc will from now on return punycode. > ​What do web pages do if they want to reflect a pretty URL into their page? Will

Re: Phabricator and confidential reviews

On Wed, Aug 9, 2017 at 11:32 AM, Mark Côté wrote: > I actually like Gijs's proposal, to mirror *from* Phabricator *to* BMO. > That way, if you're looking at the bug and want to pull someone in, you CC > them; if you're looking at the fix and want to involve someone, you add >

Re: Intent to ship: Treating 'data:' documents as unique, opaque origins

On Tue, Aug 8, 2017 at 6:12 AM, Christoph Kerschbaumer wrote: > compliant with the behavior of other browsers which all have been shipping > that behavior for a long time. > No other browser has _ever_ treated data: the way we do. The spec at one time said they should

Re: Intent to ship version 4 of the Safe Browsing protocol

On Wed, Aug 16, 2017 at 7:20 AM, Enrico Weigelt, metux IT consult < enrico.weig...@gr13.net> wrote: > Regarding CID vs CONTRACTID - still haven't understood why CIDs are > random numbers, instead of human-readable names ​Someone in 1999 or 2000 thought it was a good idea and set the pattern.​

Re: Proposed W3C Charter: WebVR Working Group

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 > and promotion of WebVR. > ​I agree that would be exceptionally odd and require a

Re: Intent to unship: Top-level Navigations to a data: URI

Just to clear up the headline: we intend to unship "top level navigations to data:" (currently allowed) by blocking them. The body of the message was clear, just fixing the subject for people (and twitter bots) that don't get that far. -Dan Veditz ___

Re: Intent to ship: CSP directive worker-src

On Fri, Sep 22, 2017 at 7:24 AM, Anne van Kesteren wrote: > > We plan to ship the CSP directive worker-src within Firefox 58. > > Will we also start enforcing script-src for workers? It seems good > that if you restrict script it actually stops all scripts. > ​Yes. That's what

Re: Changes to tab min-width

On Fri, Oct 6, 2017 at 12:57 AM, Lars Hansen wrote: > even if I don't exactly remember the > ​ ​ > ID I'm looking for I can narrow it down to one or two tabs and then hover > ​ ​ > if I need to. > ​ ​ > Many other sites also have tabs that can be distinguished > ​ ​ > from

Re: Changes to tab min-width

On Fri, Oct 6, 2017 at 12:15 PM, Randell Jesup wrote: > There's "publish an extension that > ​ ​ > lets you fiddle the width" (doable today). ​WebExtensions can't manipulate prefs other than the ones explicitly exposed via a WebExtension API. Only "system add-ons" have

Re: Important changes to account security on bugzilla.mozilla.org

On Fri, Sep 8, 2017 at 2:42 PM, Frank-Rainer Grahl wrote: > > who can see confidential or secure bugs > > This is a bit vague. If I am cced to a secure bug does this apply if I > only have editbugs otherwise? ​There's a missing ".. by default" there. Only applies if your account

Re: Device Memory header and JS API

On Thu, Sep 7, 2017 at 11:28 AM, Enrico Weigelt, metux IT consult < enrico.weig...@gr13.net> wrote: > Optimally, the browser should tell nothing about the client - web > content should written in a way that it works independent from the > actual client. At least that's how the web originally was

Re: OS/2 still supported ?

​On Tue, Jul 25, 2017 at 1:04 AM, Enrico Weigelt, metux IT consult < enrico.weig...@gr13.net> wrote: > On 25.07.2017 02:04, Kris Maglione wrote: > > The only remaining in-tree references to the XP_OS2 macros are in NSPR >> and NSS, which are technically separate projects, and have their own >>

Re: Device Memory header and JS API

On Tue, Sep 5, 2017 at 10:13 AM, Shubhie Panicker via dev-platform < dev-platform@lists.mozilla.org> wrote: > Boris expressed privacy concern with the API and suggested starting a > thread here to get some concrete feedback. ​It's great that you agreed to send this (and other client hints?)

Re: Intermittent oranges and when to disable the related test case - a simplified policy

On Wed, Sep 6, 2017 at 4:53 PM, Emma Humphries wrote: > This begs the question, why was that whiteboard tag being used that way? > ​Surely there are other reasons to disable tests, and people might want to track those too. If you want to restrict your new keyword to just

Re: Intent to ship: CSP directive worker-src

Kerschbaumer <ckers...@gmail.com> wrote: > > On Sep 22, 2017, at 10:27 PM, Daniel Veditz <dved...@mozilla.com> wrote: > ​Christoph said > >> For backwards compatibility child-src will still be enforced for: >> * workers (if worker-src is not explicitly specified) &g

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Fri, Sep 29, 2017 at 8:33 PM, Boris Zbarsky wrote: > On 9/29/17 3:32 PM, Kris Maglione wrote: > >> For instance, the following should all capture the caller principal for >> the `src` URL at call time: >> >> document.write(`http://example.com/favicon.ico;>`); >>

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Mon, Oct 2, 2017 at 8:17 AM, Boris Zbarsky wrote: > The fact is, direct DOM manipulation with no parser involved is really > annoying to use. > ​Fair enough. Could we propose improvements to the API​s that would make them more usable? For example an object argument to

Re: We need better canaries for JS code

On Wed, Oct 18, 2017 at 4:51 AM, Mark Banner wrote: > I did an experiment, and the only way I got an error out was to have > "javascript.options.strict" on and > ​Why isn't it a code-style/review requirement that our own internal JS include "use strict"? As a quick check I

Re: Intent to ship: CSP Violation DOM Events

On Fri, Nov 17, 2017 at 2:01 AM, James Graham wrote: > Do we have cross-browser (i.e. web-platform) tests covering this feature? We fail many of the existing CSP web platform tests, despite having implemented most of the features, because they were written to use the

Re: Intent to ship: CSP Violation DOM Events

On Fri, Nov 17, 2017 at 9:25 AM, James Graham <ja...@hoppipolla.co.uk> wrote: > On 17/11/17 16:06, Daniel Veditz wrote: > >> We fail many of the existing CSP web platform tests, despite having >> implemented most of the features, because they were written to use the >

Re: Intent to ship: Do not allow a http-auth prompt requested by an image resource loaded from a cross-origin

On Tue, Dec 5, 2017 at 1:29 PM, Xidorn Quan wrote: > Would this affect authentication from proxy? For example, if the > cross-origin image is on a domain which PAC decides to use proxy for, > and the proxy requires authentication, would the dialog prompt for it be > suppressed

Re: Intent to ship: Do not allow a http-auth prompt requested by an image resource loaded from a cross-origin

On Wed, Dec 6, 2017 at 9:13 AM, Dragana Damjanovic wrote: > Bug 1423522 should fix this. > ​That doesn't fix it, that reenables the phishing risk. There's no reason the phisher's server can't pretend to be a proxy if that's what it takes to get a spoofy auth prompt to

Re: Reviews for in-tree documentation (was: Builds docs on MDN)

On Thu, Oct 19, 2017 at 9:30 AM, smaug wrote: > (Hoping the r=documentation flag won't be misused ;)) ​I hope there will be some kind of hook making sure files touched in that manner are all actually documentation files and not other parts of the repo. - ​Dan Veditz​

Re: Intent to Implement: canvas-imagedata permission

On Wed, Jan 10, 2018 at 12:32 PM, L. David Baron wrote: > Is stopping canvas fingerprinting actually a substantial reduction > in available entropy, or is it just removing a convenient source > that happens to combine a bunch of sources of entropy that are also > available

Re: Intent to unship: remote jar: protocol pref

On Fri, Jan 12, 2018 at 2:12 PM, Gijs Kruitbosch wrote: > the most likely group of people to have enabled this (given 0 public > reports on breakage so far, as far as I'm aware) are people on ESR or > otherwise in enterprise environments > ​Or those trying to run

Re: Intent to unship: navigator.registerContentHandler()

On Wed, Jan 10, 2018 at 5:35 PM, Tantek Çelik wrote: > Also good methodology worth repeating: >"thinking ... through all the way up to and including the user > ​​ > experience, makes for a much more viable approach" > ​Including, of course, "how will 4chan trolls

Re: u2f

On Fri, Jan 26, 2018 at 6:06 PM, greyhorseman wrote: > question is when, if ever, Firefox is going to support this standard fully > and allow me to use my ubikeys? > https://hacks.mozilla.org/2018/01/using-hardware-token-based-2fa-with-the-webauthn-api/

Re: u2f

On Sat, Jan 27, 2018 at 6:35 PM, greyhorseman wrote: > so we're talking 2 full releases and maybe 6-7 months? Am I at at least > close to correct. > If your question was truly "allow ME to use my ubikeys?" (emphasis mine) then you can do that since Firefox 57, by changing

Re: Device Orientation API future

On Wed, Jan 3, 2018 at 7:48 AM, Jonathan Kingston wrote: > For GPS we only ever talk about "location", I still don't think that is a > far stretch from head/position tracking. > ​Users aren't going to understand why their tilt-the-tablet labyrinth game needs to know they're in

Re: PSA: Major preference service architecture changes inbound

On Tue, Jul 17, 2018 at 9:23 PM, Nicholas Nethercote wrote: > This is a good example of how prefs is a far more general mechanism than I > would like, leading to all manner of use and abuse. "All I want is a > key-value store, with fast multi-threaded access, where the keys aren't > known ahead

Re: Intent to implement and ship: same-site cookies

On Mon, Apr 9, 2018 at 11:56 PM, Anne van Kesteren wrote: > We keep > ​ ​ > trying to find ways to limit cookies transmitted over HTTP (and > limiting HTTP in general). Offering better cookies over HTTPS seems > like a good incentive for sites to migrate. > To me "better

Re: Checking if an nsIURI came from a resource: URL

I'm afraid to ask why you want to treat these differently. Do you have a channel or a principal? By itself nsIURI only describes the url itself, not its effective origin nor its redirect history. On Fri, Dec 7, 2018, 8:08 AM Henri Sivonen It appears that my the time resource: URLs reach the HTML

Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements

On Wed, Nov 21, 2018 at 7:08 AM Alex Gaynor wrote: > Do we have any sense of how large the breakage will be, and do we have any > docs for developers who are impacted? (I assume rel=opener is the fix?) > "opener" doesn't exist, and we shouldn't need it. You'd specify a target name other than

Re: Cookie policy/permission in live documents - proposal

On Mon, Jan 28, 2019 at 12:57 AM Andrea Marchesini wrote: > If we try to apply the new cookie policy immediately, 3rd party trackers > in opened tabs should switch to a first-party-isolation storage, but they > could also have already data in memory (user-tokens), and populate the new > cookie

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

Neither of the words "security" or "privacy" appear in this spec (most w3 web specs have at least a token attempt at a "Privacy and Security Considerations" section). At a surface glance this appears to add additional fingerprinting exposure. Have you talked to the privacy team about ways to

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

I support this recharter (disclaimer: I'm a co-chair so of course I do). -Dan Veditz On Fri, Feb 22, 2019 at 5:29 PM L. David Baron wrote: > The W3C is proposing a revised charter for: > > Web Application Security (WebAppSec) Working Group >

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

On Thu, Mar 14, 2019 at 11:25 AM Alex Gaynor wrote: > one overriding concern: phishing, particularly moderately-sophisticated > phishing which can handle forms of 2FA such as TOTP, SMS, or push, is a > scourge. TOTP was never much defense against phishing, just password compromise (shoulder

Re: Improving our usage of Bugzilla

On Tue, Mar 12, 2019 at 3:55 AM Sylvestre Ledru wrote: > 2) Bug type - new field > 3) Adding a new field called “Regressed by” > Will the new fields be searchable using quicksearch? ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Improving our usage of Bugzilla

On Tue, Mar 12, 2019 at 4:50 AM Honza Bambas wrote: > I wanted to suggest (but never done that) to have specific fields (text > areas) in the bug form for following information: > - explanation of the cause of the defect or rational for the bug > - overview explanation of the fix for the defect

Re: Improving our usage of Bugzilla

On Tue, Mar 12, 2019 at 10:53 AM Kohei Yoshino wrote: > The User Story field will be soon removed from the new bug page. > https://bugzilla.mozilla.org/show_bug.cgi?id=1525376 Without a replacement that would be unfortunate. People have been asking for what Honza described for more than 20

Re: Cookie policy/permission in live documents - proposal

Your description equating cookies and storage within a document lifetime makes sense. Is this intended to also apply to network requests? The first-party document already has no access to 3rd party cookies so it shouldn't matter at that level if Necko's rules change "live". If I'm on

Re: Proposed W3C Charter: Media Working Group

There was supposed to be a a discussion about whether the charter 1) excluded EME, 2) included EME, or 3) included EME with protection for security researchers. I didn't see much discussion, then the charter was simply changed to option 2. https://github.com/w3c/charter-media-wg/issues/2 I think

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

On Thu, Apr 25, 2019 at 1:58 PM Bobby Holley wrote: > As long as we're certain that we won't ship Fennec past ESR68, > The timeline was left vague. Ideally I assume we'd like to migrate Fennec folks to Fenix before ESR68 EOL, but if it's not ready there's no reason we have to stop shipping a

Re: Intent to Ship - Support XCTO: nosniff for navigations

On Thu, Sep 5, 2019 at 6:21 AM Sebastian Streich wrote: > Link to standard: > https://fetch.spec.whatwg.org/#x-content-type-options-header That bit of the standard doesn't describe this behavior--it still only talks about scripts and style. Is there an issue or PR to update the spec to

Re: Intent to ship: Event-based form participation

On Fri, Sep 6, 2019 at 3:07 AM John Dai wrote: > Is this feature enabled by default in sandboxed iframes? No. > But it's not specifically disabled in sandboxed frames or behind a non-default preference setting, right? If a sandboxed frame has allow-forms then this event is available along with

Re: The sec-approval process makes users safer

On Tue, Sep 10, 2019 at 9:35 AM Boris Zbarsky wrote: > On 9/10/19 12:30 PM, Boris Zbarsky wrote: > > I just checked, and there are currently 826 bugs that have > > "in-testsuite?" set on them where I am the flag requester. > > And overall there seem to be ~7300 bugs that have that flag set. >

Re: Workers no longer working on file URLs?

See https://bugzilla.mozilla.org/show_bug.cgi?id=file-fallout and the 3 bugs it depends on. This is fallout from fixing the file:// issue in Fx68. Unsure if we're going to fix local workers since they also don't work in other browsers, but local fonts seem to be a big deal. -Dan Veditz On Wed,

Re: Intent to Ship: Require user interaction for notification permission prompts

You could, but we're making this change because our user studies show users respond negatively to unexpected and unwanted prompts. If the users don't associate their triggering interaction with a desire to accomplish the task for which you're requesting permission they're still going to say "No"

Re: Intent to ship: CSS subgrid

>From my (personal) security-team perspective this is a fine pragmatic approach. Our overriding primary concern is whether exposing these new CSS features over insecure transport puts our users at additional risk. I don't see any meaningful privacy exposure here since these new features will be in

Re: Intent to ship: CSS subgrid

On Fri, Oct 18, 2019 at 4:27 PM Tantek Çelik wrote: > Based on your reasoning, and our consistent intent emails and shipping > behavior, I think we should consider updating the blog post on this > matter regarding all CSS features (cc: annevk), or posting a separate > update post accordingly,

Re: Intent to Deploy: ThreadSanitizer

On Thu, Feb 6, 2020 at 6:12 AM Christian Holler wrote: > Furthermore, data races are undefined behavior and can lead to > unforeseeable code behavior once compilers exploit this fact for better > optimizations. We have evidence that data races can cause intermittent > crashes and use-after-free

Re: Intent to ship: Autodiscovery of WebExtension search engines

On Fri, Feb 14, 2020 at 11:50 AM Dale Harvey wrote: > We’re proposing a new mime-type [...]: “x-xpinstall” for WebExtension > search > engines. Example: /" some authors will tend to fill in the "missing" bit and get it wrong, and others will complain that the syntax is non-standard and broken.

Re: Intent to ship: Autodiscovery of WebExtension search engines

On Wed, Feb 19, 2020 at 2:10 PM Dale Harvey wrote: > > If you _do_ invent a new one shared with other browser vendors, please > > don't use an "x-" prefix in anything new. > > Thanks, I got notice of others concerns about this as well and have been > looped in to discuss this more with standards

Land your tests for now-public security bugs

tl;dr: If you've ever landed a security fix please check-in your public testcases . We've long worried that if we landed tests along with our security fixes

Re: Intent to implement: Cookie SameSite=lax by default and SameSite=none only if secure

On Tue, Sep 15, 2020 at 10:13 AM Michael Reeps wrote: > Thank you for the prompt response to my email. I guess I interpreted the > standard to mean only when the cookie was intended for cross-site delivery, > which these are not: > If the bug carries the SameSite=None attribute how could the

Re: Intent to implement: Cookie SameSite=lax by default and SameSite=none only if secure

On Mon, Sep 14, 2020 at 10:00 AM Michael Reeps wrote: > I am seeing this warning now, even when I am in a first party context: > > Cookie "xxx” will be soon rejected because it has the “SameSite” attribute > set to “None” or an invalid value, without the “secure” attribute. The > cookies in

Re: Intent to deprecate: Insecure HTTP

You're replying to a 4 year old thread. Don't do that: you're jumping over 4 years of other conversations, and tagged on the end of an old thread whatever arguments you're making will unseen by a lot of people depending on how their mail readers work. Your arguments about HTTPS overhead on poor