Re: Intent to implement and ship: same-site cookies
On 09/04/18 07:25 PM, Francois Marier wrote: > We intend to ship same-site cookies in Firefox 61. This has now been uplifted and will be shipping in Firefox 60. Status can be tracked on https://wiki.mozilla.org/Security/SameSiteCookies. Francois ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: same-site cookies
We intend to ship same-site cookies in Firefox 61. This new cookie attribute allows sites to prevent cross-site requests from using those cookies which provides a mechanism for web sites to protect themselves against Cross-Site Request Forgery (CSRF) attacks. Specification (cookies): https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02 Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=795346 Platform coverage: all Gating preference: network.cookie.same-site.enabled Devtools support: https://bugzilla.mozilla.org/show_bug.cgi?id=1452715 Developer documentation: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Directives Web Platform Tests: http://rfc6265.biz/tests/ (until https://github.com/w3c/web-platform-tests/issues/8581 is fixed) Secure contexts: not restricted to secure contexts since cookies are already available in non-secure contexts Other browsers: - Chrome shipped this feature in 51. - Safari: https://bugs.webkit.org/show_bug.cgi?id=159464 - Edge: https://github.com/MicrosoftEdge/Status/issues/201 Francois and Christoph ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship version 4 of the Safe Browsing protocol
After a year's worth of development, bug fixes, and integration testing, we are now ready to enable the latest version [1] of the Safe Browsing API in Firefox 56, two releases ahead of schedule and only a few weeks behind Chrome. We do not expect any user-visible changes, but will be running an experiment [2] on beta to compare crash rates between the two versions of the API. After that, the feature will be rolled out to the release population in stages [3]. I want to take this opportunity to thank Dimi Lee, Henry Chang and Thomas Nguyen for spending so much time refactoring and eliminating ancient code (some of it dating back to when Safe Browsing was a Google extension for Firefox [4] or part of the Google Toolbar [5]). Thanks to their hard work, we have not only eliminated crashes and fixed intermittent test failures that have been around for many years, we now also have a stable codebase and two new module peers [6] with deep knowledge of this code. Big thanks to the other Taipei folks who helped make this happen: Ethan Tseng, Engineering Manager; Wesly Huang, EPM; and Cynthia Tang, QA Engineer. Without the work of all of these people, we would not have been able to complete the migration in time for Google's shutdown of the old servers. Francois [1] https://security.googleblog.com/2016/05/evolving-safe-browsing-api.html [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1377267 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1387651 [4] https://web.archive.org/web/20051218171531/http://www.google.com/tools/firefox/safebrowsing/index.html [5] https://web.archive.org/web/20060412192055/http://tools.google.com/firefox/toolbar/ [6] https://groups.google.com/d/topic/mozilla.governance/cF9MwHoQ09M/discussion ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement version 4 of the Safe Browsing protocol
The Safe Browsing service we rely on for protection against malware and deceptive sites is migrating to a new version of the Safe Browsing protocol. Version 4 will enable Google to quickly send the most relevant list entries to clients (based on platform and locale for example) as well as deal with false positives in a more efficient way. Meta bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1167038 Implementation plan: https://wiki.mozilla.org/Security/Safe_Browsing/V4_Implementation Link to specification: https://developers.google.com/safe-browsing/v4/update-api Platform coverage: Desktop and Android Estimated or target release: We'll be rolling it out slowly in the pre-release channels and monitoring it closely via Telemetry before we switch over. We intend to have the existing V2 code running in parallel with the V4 code for a little while. Google has agreed to run the old servers until we have released an ESR which uses the version 4 servers (most likely ESR 59). Preference behind which this will be implemented: urlclassifier.phishTable and urlclassifier.malwareTable https://wiki.mozilla.org/Security/Safe_Browsing/V4_Implementation#Notes Do other browser engines implement this? Chromium is working on it. They have landed large parts of it, but it hasn't shipped to users yet. Tests: Our existing tests for version 2 of the protocol will be extended to support version 4 too. We are also adding V4-specific tests. https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/url-classifier/tests https://hg.mozilla.org/mozilla-central/file/tip/testing/firefox-ui/tests/functional/security https://hg.mozilla.org/mozilla-central/file/tip/browser/components/safebrowsing/content/test + manual smoke tests Security and Privacy concerns: The privacy characteristics of the new protocol are essentially the same as the old protocol. https://support.mozilla.org/en-US/kb/how-does-phishing-and-malware-protection-work#w_what-information-is-sent-to-mozilla-or-its-partners-when-phishing-and-malware-protection-are-enabled For more information about Safe Browsing, see the wiki: https://wiki.mozilla.org/Security/Safe_Browsing ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies
On 15/04/16 03:58 AM, Tanvi Vyas wrote: > So how about a preference that treats all cookies set in a third party > context as session cookies. We could restrict this to HTTP, or even > apply it to third party HTTPS cookies. We seem to have this already: network.cookie.thirdparty.sessionOnly Francois ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: Subresource Integrity (SRI)
On 30/12/14 09:40 PM, Francois Marier wrote: > Summary: Allow web authors to add integrity checks to sub-resources. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=992096 > > Spec: http://www.w3.org/TR/SRI/ > > Platforms: all > > Estimated or target release: Q1 of 2015 > > Preference behind which this will be implemented: > security.subResourceIntegrity.enable This landed pref'ed off on Nightly in August. I intend to pref it on in Firefox 43. We pass all of the W3C web-platform tests, the spec is almost finalized and Chrome has already shipped this pref'ed ON (Chrome 45). Francois ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AdBlock Plus as a ServiceWorker?
On 21/05/15 07:01, David Rajchenbach-Teller wrote: So is there something that ABP developers can do at the moment to reimplement their code without CPOWs co? And is it documented anywhere on MDN? There's nothing like that at the moment, but I'd be happy to work with a blocklist add-on developer to try and make it work. Francois ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AdBlock Plus as a ServiceWorker?
On 08/05/15 19:42, Frederik Braun wrote: I thought that the APIs we brought into Firefox by implementing Tracking Protection were supposed to provide a better (canonical?) way to hook your own blocker into Firefox. Yes, as long as they're willing to stand up a server [1] that serves their lists in a different format [2]. Francois [1] https://github.com/mozilla-services/shavar [2] https://developers.google.com/safe-browsing/developers_guide_v2 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
On 09/04/15 15:39, Seth Fowler wrote: Sounds like yet another reason to build support and UI for this stuff directly into the browser. On that note, Bram from UX has some ideas about what it could look like: https://wiki.mozilla.org/Security/Contextual_Identity_Project/User_Profiles Francois ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Dropping support for MSVC2012
On 04/01/15 19:28, Philip Chee wrote: To me, the default answer to whether we should keep supporting MinGW is no, merely because it will require time and effort that will not directly benefit our users as we do not use that compiler to release Firefox. That is, without someone coming up with a good reason otherwise, we should drop it. And not having it locally installed is not a good reason. :-) I believe the Tor project uses it for reproducible builds on Windows: https://air.mozilla.org/why-and-how-of-reproducible-builds-distrusting-our-own-infrastructure-for-safer-software-releases/ Francois ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Sub-resource Integrity (SRI)
On 31/12/14 19:00, Johnny Stenback wrote: LGTM, what's the status wrt other browsers supporting this? Chromium has implemented the same subset of the spec as us (which is roughly what Level 1 is shaping up to be). It has already landed in Canary, not sure when they plan on pushing it to the release channel. I haven't heard anything about other browsers. Francois ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Sub-resource Integrity (SRI)
On 31/12/14 19:09, L. David Baron wrote: Spec: http://www.w3.org/TR/SRI/ The TR draft of that spec looks a bit out-of-date. Will you be referring to the editor's draft, and tracking the progress in the working group, or be in touch with others who are? Yes, I'm working off of the editor's draft: https://github.com/w3c/webappsec/blob/master/specs/subresourceintegrity/spec.markdown I'm also collaborating with Freddy Braun and the other editors to fix the remaining problems with the spec. It looks like perhaps an early-ish draft. Does the working group believe it's stable enough to implement and ship? Or is the plan to implement and hold off on shipping until it's more stable? At TPAC, the working group decided to keep the stable parts for level 1 and leave the things which aren't ready for a later version. I believe it's still on track for a last call draft in early 2015. (And presumably you're also implementing http://tools.ietf.org/html/rfc6920 , but that looks more stable.) For now, I'm only implementing the parts of that spec that we need for SRI, but thanks for pointing it out, SRI uses the URI format defined in that RFC. Francois ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Sub-resource Integrity (SRI)
On 31/12/14 21:42, Ms2ger wrote: What's the testing story? Do we pass the web-platform tests (https://github.com/w3c/web-platform-tests/tree/master/subresource-integrity)? We do, except for one which relies on ambiguity in the spec and is currently being discussed [1] in the working group. I will update our code as needed once that discussion has concluded. Do we run them in automation? Do we intend to extend the tests to a level where we can be confident about interoperability with other browsers? I've got a few mochitests [2] already, but I've got a few more I want to add to cover all of the corner cases in the spec. In terms of interop with other browsers, I'm thinking of expanding the w3c tests and then running those against Chromium to ensure that we've made the same assumptions. The Chromium developers responsible for the SRI implementation are also involved in the working group. If you have any other suggestions to improve our testing, I'd love to hear them. Francois [1] http://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0242.html [2] https://bugzilla.mozilla.org/attachment.cgi?id=8542512 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: Sub-resource Integrity (SRI)
Summary: Allow web authors to add integrity checks to sub-resources. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=992096 Spec: http://www.w3.org/TR/SRI/ Platforms: all Estimated or target release: Q1 of 2015 Preference behind which this will be implemented: security.subResourceIntegrity.enable Background: The best way to explain this is through an example. If you have the following: script src=https://code.jquery.com/jquery-1.10.2.min.js; integrity=ni:///sha-256;C6CB9UYIS9UJeqinPHWTHVqh_E1uhG5Twh-Y5qFQmYg?ct=application/javascript then the browser will refuse to execute the script if someone has gained access to the jQuery servers and has replaced the script with a malicious one (the hash won't match the expected one). Our initial implementation will be limited to integrity checks for script tags and stylesheets. While the spec is still evolving, we expect to cover everything that ends up in level 1 of the spec. Feel free to contact me if you have any questions. Francois ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
