https://wiki.mozilla.org/api.php?action=feedcontributions&user=Stpeter&feedformat=atomMozillaWiki - User contributions [en]2024-03-29T08:12:33ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=Security/DOH-resolver-policy&diff=1240378Security/DOH-resolver-policy2022-02-01T15:51:41Z<p>Stpeter: Added Shaw to Conforming Resolvers</p>
<hr />
<div>== Mozilla Policy Requirements for DNS over HTTPs Partners ==<br />
<br />
This document describes the minimum set of policy requirements that a party must satisfy to be considered as a potential partner for Mozilla’s Trusted Recursive Resolver (TRR) program. It specifically describes data collection and retention, transparency, and blocking policies and is in addition to any contractual, technical or operational requirements necessary to operate the resolver service. <br />
<br />
==== Privacy Requirements ====<br />
<br />
Mozilla’s TRR is intended to provide better, minimum privacy guarantees to Firefox users than current, ad hoc provisioning of DNS services. As such, resolvers must strictly limit data collection and sharing from the resolver. More specifically:<br />
<br />
::1. The resolver may retain user data (including identifiable data, data associated with user IP addresses, and any non-aggregate anonymized data) but should do so only for the purpose of operating the service and must not retain that data for longer than 24 hours. <br />
:::* Only aggregate data that does not identify individual users or requests may be retained beyond 24 hours. <br />
::2. The resolver must not retain, sell, or transfer to any third party (except as may be required by law) any personal information, IP addresses or other user identifiers, or user query patterns from the DNS queries sent from the Firefox browser.<br /><br />
<br />
::3. The resolver must not combine the data that it collects from queries with any other data in any way that can be used to identify individual end users.<br /><br />
<br />
::4. The resolver must not sell, license, sublicense, or grant any rights to user data to any other person or entity.<br /><br />
<br />
::5. The resolver must support DNS Query Name Minimisation as defined in RFC 7816.<br /><br />
<br />
::6. The resolver must not propagate unnecessary information about queries to authoritative name servers. In particular, the client subnet DNS extension in RFC 7871 must not be sent to servers unless the connection to the authoritative server is encrypted and only to authoritative name servers operated by the domain owner directly or by a DNS provider pursuant to its contract with the domain owner.<br /><br />
<br />
==== Transparency Requirements ====<br />
<br />
The party operating the resolver must be transparent about any data collection and sharing that does occur in accordance with the above requirements. More specifically:<br />
<br />
::1. Privacy Notice. There must be a public privacy notice specifically for the resolver service that documents the specific fields for data that will be retained for 24 hours and that documents specific fields for aggregate data that will be retained beyond 24 hours. The notice should also attest to requirements 2 - 4 above. <br /><br />
<br />
::2. Transparency Report. There must be a transparency report published at least yearly that documents the policy for how the party operating the resolver will handle law enforcement requests for user data and that documents the types and number of requests received and answered, except to the extent such disclosure is prohibited by law.<br />
<br />
==== Blocking & Modification Prohibitions ==== <br />
<br />
::1. The party operating the resolver should not by default block or filter domains unless specifically required by law in the jurisdiction in which the resolver operates. Mozilla will generally seek to work with DNS resolvers that provide unfiltered DNS responses and, at its discretion, may remove from consideration resolvers subject to legal filtering obligations, depending on the scope and nature of those obligations. <br />
:::* Resolvers may block or filter content with the user’s explicit consent.<br />
::2. For any filtering that does occur under the above requirement, the party must maintain public documentation of all domains that are blocked and a log of when particular domains are added and removed from any blocklist.<br /><br />
<br />
::3. When a domain requested by the user is not present, the party operating the resolver should provide an accurate NXDOMAIN response and must not modify the response or provide inaccurate responses that direct the user to alternative content. <br />
<br />
== Enforcement ==<br />
The decision of who to include in (or remove from) Mozilla’s Trusted Recursive Resolver (TRR) program is at Mozilla’s sole discretion, and we may evaluate additional factors such as abusive practices or other security concerns not specifically identified here. We intend to publicly document violations of this Policy and take additional actions if necessary.<br />
<br />
== Conforming Resolvers ==<br />
The following providers have contractually agreed to abide by these policy requirements:<br />
<br />
{| class="wikitable"<br />
|CIRA || [https://www.cira.ca/cybersecurity-services/canadian-shield/privacy Privacy policy] || https://private.canadianshield.cira.ca/dns-query<br />
|-<br />
|Cloudflare || [https://developers.cloudflare.com/1.1.1.1/privacy/firefox/ Privacy policy] || https://mozilla.cloudflare-dns.com/dns-query<br />
|-<br />
|Comcast || [https://www.xfinity.com/privacy/policy/dns Privacy policy] || https://doh.xfinity.com/dns-query <br />
|-<br />
|NextDNS || [https://nextdns.io/privacy Privacy policy] || https://firefox.dns.nextdns.io <br />
|-<br />
|Shaw || [https://www.shaw.ca/dns-statement Privacy policy] || https://dns.shaw.ca/dns-query <br />
|}<br />
<br />
(Per [https://wiki.mozilla.org/index.php?title=User_talk:Wthayer&oldid=1221836 Wthayer] for Cloudflare and NextDNS; per [https://wiki.mozilla.org/index.php?title=User_talk:Stpeter Stpeter] for CIRA, Comcast, and Shaw.)</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Standards/w3c-interest-community-groups&diff=1237183Standards/w3c-interest-community-groups2021-08-09T21:53:52Z<p>Stpeter: added Privacy CG</p>
<hr />
<div>{{stub}}<br />
<br />
This page tracks [[W3C]] Interest Groups (IGs) and Community Groups (CGs) that Mozillians participate in. Specifically these are IGs and CGs without a related Working Group (WG).<br />
<br />
See the main '''[[Standards]]''' page for WGs and their directly related IGs & CGs (if any).<br />
<br />
== W3C ==<br />
* See [[Standards]] for W3C Working Groups that Mozillians participate in.<br />
<br />
=== Color on the Web Community Group ===<br />
https://www.w3.org/community/colorweb/<br />
* <span class="h-card">[[User:Jgilbert|Jeff Gilbert]]</span><br />
<br />
=== Federated Identity Community Group ===<br />
https://www.w3.org/community/fed-id/<br />
* <span class="h-card">[[User:Stpeter|Peter Saint-Andre]]</span><br />
<br />
=== Games Community Group ===<br />
http://www.w3.org/community/games/<br />
* <span class="h-card">[[User:Dmose|Dan Mosedale]]</span><br />
<br />
=== Immersive Web Community Group ===<br />
https://github.com/immersive-web/proposals - [https://www.w3.org/blog/2018/01/towards-the-immersive-web/ previously known] as [http://www.w3.org/community/webvr/ WebVR Community Group]<br />
* <span class="h-card">[[User:Jgilbert|Jeff Gilbert]]</span><br />
Documents:<br />
* [https://immersive-web.github.io/webxr/ WebXR Device API Editor's Draft]<br />
* [https://immersive-web.github.io/webxr/charter/ draft charter] (towards a WG)<br />
<br />
=== Open UI Community Group ===<br />
https://www.w3.org/community/open-ui/<br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span><br />
<br />
=== Privacy Community Group ===<br />
https://github.com/privacycg/<br />
* Tanvi Vyas (co-chair)<br />
* Peter Saint-Andre<br />
* Johann Hofmann<br />
* Anne van Kesteren<br />
<br />
=== Web Education Community Group ===<br />
http://www.w3.org/community/webed/<br />
* <span class="h-card">[[User:Espressive|Schalk Neethling]]</span><br />
<br />
== See Also ==<br />
* [[Standards]]<br />
* [[Standards/emeritus]] - past Mozilla participants in Community Groups</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Standards&diff=1237182Standards2021-08-09T21:51:26Z<p>Stpeter: /* IETF */ added ADD, UTA, RSOC, etc.</p>
<hr />
<div>Welcome to Mozilla's standards participation page.<br />
<br />
This is a directory of standards organizations and their working groups, listing who at Mozilla is working with each.<br />
<br />
For a technology summary see the [[standards/technologies|technologies]] page, for Mozilla’s positions on particular specifications, see:<br />
* https://mozilla.github.io/standards-positions/<br />
Current discussions of Mozilla positions:<br />
* https://github.com/mozilla/standards-positions/issues<br />
<br />
The lists below are organized alphabetically by standards body and working group (if any), with Mozilla participants and specifications they edit/author/contribute to.<br />
<br />
If you’re a Mozillian actively & directly participating in a standards body (working group email list, IRC, wiki, and/or f2f meetings), please add yourself to the specific standards body / working group if any), linking to your wiki User: page. If you’re working in multiple working groups or standards organizations, add yourself to each.<br />
<br />
Thanks!<br />
<br />
— [[User:Tantek|Tantek]]<br />
<br />
= Web Standards Coordination =<br />
<br />
== General Participation Guidelines ==<br />
If you'd like to participate in some of these groups, or at least watch, learn, get up to speed, you can almost always do so by lurking on the public IRC channels and mailing lists that the groups use. Many (most?) standards mailing lists can often be overwhelming in quantity, depth so start with IRC as that's often lighter-weight and easier to watch for quick bits of info/knowledge.<br />
<br />
* Follow the instructions on the [[Matrix|Matrix wiki page]] to:<br />
** Set up a connection to and nickname for <code>chat.mozilla.org</code>. <br />
** Join the Standards channel<br />
* Follow the instructions on the [[IRC|IRC wiki page]] to:<br />
** Set up a connection to and nickname for <code>irc.w3.org</code> but specifically port 6665 (unprotected, no nickname registration).<br />
*** You may also use W3C IRC’s Web UI: http://irc.w3.org/<br />
** Set up a connection to and nickname for <code>irc.freenode.net</code> for participation in #[[whatwg]] and other standards communities (#[[microformats]], #[[indieweb]])<br />
*** You may also use Freenode's Web UI: https://webchat.freenode.net/<br />
* See each standards section below for which IRC channel(s) tend(s) to be used by folks working in each group.<br />
<br />
== [https://www.ecma-international.org/ Ecma International] ==<br />
<br />
=== [https://tc39.es// TC39] ===<br />
* <span class="h-card">[[User:Ystartsev|Yulia Startsev]]</span> - voting delegate, former chair (currently advising)<br />
<br />
Specifications: ECMAScript 5, 5.1, 6, Harmony, etc.<br />
<br />
== [https://ietf.org/ IETF] ==<br />
<br />
=== [https://datatracker.ietf.org/wg/add/about/ ADD] ===<br />
* Martin Thomson<br />
* Eric Rescorla<br />
<br />
=== [https://datatracker.ietf.org/wg/calext/about/ CALEXT] (iCalendar) ===<br />
* <span class="h-card">Philipp Kewisch</span><br />
<br />
=== [https://datatracker.ietf.org/wg/dispatch/about/ DISPATCH] ===<br />
* Martin Thomson<br />
* Eric Rescorla<br />
<br />
=== [https://httpwg.github.io/ HTTPbis] ===<br />
* <span class="h-card">Martin Thomson</span><br />
* <span class="h-card">Dragana Damjanovic</span><br />
<br />
=== [https://quicwg.github.io/ QUIC] ===<br />
* <span class="h-card">Martin Thomson</span><br />
* Eric Rescorla<br />
<br />
=== [https://datatracker.ietf.org/wg/rtcweb/about/ RTCWEB] / [https://datatracker.ietf.org/wg/mmusic/about/ MMUSIC] ===<br />
* <span class="h-card">Randell Jesup</span><br />
* <span class="h-card">Eric Rescorla (<span class="p-nickname">EKR</span>)</span><br />
* <span class="h-card">Martin Thomson</span><br />
* <span class="h-card">Maire Reavy</span><br />
<br />
=== [https://datatracker.ietf.org/wg/stir/about/ STIR] ===<br />
* Eric Rescorla<br />
<br />
=== [http://tlswg.github.io/ TLS] (SSL) ===<br />
* <span class="h-card">Martin Thomson</span><br />
* Eric Rescorla<br />
<br />
=== [https://datatracker.ietf.org/wg/uta/about/ UTA] ===<br />
* <span class="h-card">Peter Saint-Andre</span><br />
<br />
=== [https://datatracker.ietf.org/wg/webpush/about/ WebPush] ===<br />
* <span class="h-card">Martin Thomson</span><br />
<br />
=== ISOC Advisory Council ===<br />
Please contact <span class="h-card">Martin Thomson</span> for any inquiries.<br />
<br />
=== RFC Editor Future Development Program ===<br />
Please contact <span class="h-card">Peter Saint-Andre</span> for any inquiries.<br />
<br />
=== RFC Series Oversight Committee ===<br />
Please contact <span class="h-card">Peter Saint-Andre</span> for any inquiries.<br />
<br />
== Khronos ==<br />
[http://www.khronos.org/webgl/ WebGL]<br />
* <span class="h-card">[[User:Jgilbert|Jeff Gilbert]]</span> (:jgilbert)<br />
<br />
== microformats ==<br />
https://microformats.org/ and [https://microformats.org/wiki microformats wiki]<br />
* irc://irc.freenode.net/microformats (https://chat.indieweb.org/microformats)<br />
Community participants:<br />
* <span class="h-card"><span class="p-name">[[User:Tantek|Tantek Çelik]]</span> (<span class="p-role">founder</span>, <span class="p-role">admin</span>)</span><br />
* <span class="h-card">Michael Kaply</span><br />
Specifications: <br />
* [[hCard]] - implemented in Firefox DOM<br />
* [[hCalendar]] - implemented in Firefox DOM<br />
* ... and many others.<br />
<br />
== OWF ==<br />
http://openwebfoundation.org/<br />
* <span class="h-card"><span class="p-name">[[User:Tantek|Tantek Çelik]]</span> (<span class="role">elected board member</span>)</span><br />
<br />
Specifications: <br />
* [http://openwebfoundation.org/legal/agreement/ Open Web Foundation Agreement] (OWFa) - used and recommended by [[Standards/license]]<br />
<br />
== W3C ==<br />
The [http://w3.org/ W3C] (World Wide Web Consortium) has Working Groups (WGs), Interest Groups (IGs), and Community Groups (CGs). See below for details and please add any/all of such groups here in alphabetical order by working group name.<br />
* [[Standards/Participating in a W3C Working Group|Participating in a W3C Working Group]]<br />
* [[Standards/W3C Charter Development and Review|W3C Charter Development and Review]]<br />
* [https://www.w3.org/2000/09/dbwg/participants?org=35507&order=group Member-confidential (unfortunately) list of groups Mozilla participates in]<br />
** list of [https://www.w3.org/2000/09/dbwg/groups all W3C Working Groups]<br />
<br />
For the sake of focus and brevity, only W3C WGs are listed here inline, along with any complementary IGs or CGs that are paired with them.<br />
<br />
For other W3C IGs or CGs not tied directly to an active WG, see:<br />
* [[Standards/w3c-interest-community-groups]]<br />
<br />
=== Advisory Board ===<br />
[http://www.w3.org/wiki/AB W3C Advisory Board] (AB) — elected members<br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span> (2013-2018,2020-)<br />
The AB drives W3C process improvements in the:<br />
==== Process Community Group ====<br />
[https://www.w3.org/community/w3process/ W3C Process Community Group] publicly discusses ([https://www.w3.org/wiki/W3Process wiki], [https://github.com/w3c/w3process/ GitHub repo], [https://lists.w3.org/Archives/Public/public-w3process/ list]), proposes, and makes changes to the W3C Process. Delegated authority from the AB (some members of which overlap with the CG), which retains overall (dis)approval of W3C Process iterations before proposing to the AC.<br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span><br />
<br />
=== Advisory Committee ===<br />
* <span class="fn h-card">[[User:Tantek|Tantek Çelik]]</span> - Advisory Committee (AC) representative<br />
See [https://www.w3.org/Member/ACList Advisory Committee Representative Directory] for who else is an AC Rep from which other organizations.<br />
<br />
=== Audio Working Group ===<br />
* http://www.w3.org/2011/audio/<br />
[https://www.w3.org/2000/09/dbwg/details?group=46884&public=1&order=org#_MozillaFoundation Participants]:<br />
* <span class="h-card">Matthew Gregan</span><br />
* <span class="h-card">Paul Adenot</span> (Spec Editor)<br />
* <span class="h-card">Ehsan Akhgari</span><br />
The Audio Working Group works in conjuction with the Audio Community Group:<br />
==== Audio Community Group ====<br />
* https://www.w3.org/community/audio-comgp/ <br />
* <span class="h-card">Paul Adenot</span> (Chair)<br />
<br />
=== Media Working Group ===<br />
* https://www.w3.org/groups/wg/media<br />
* <span class="h-card">Paul Adenot</span><br />
* <span class="h-card">Jean-Yves Avenard</span><br />
<br />
=== Browser Testing and Tools Working Group ===<br />
[https://www.w3.org/testing/browser/ Browser Testing and Tools Working Group homepage], [https://www.w3.org/2011/08/browser-testing-charter.html Charter], [mailto:public-browser-tools-testing@w3.org Mailing list], [https://lists.w3.org/Archives/Public/public-browser-tools-testing/ Mailing list archive]<br />
* <span class="h-card">[[User:Jgraham|James Graham]]</span><br />
<br />
Specifications:<br />
* [http://w3c.github.io/webdriver/webdriver-spec.html WebDriver] - APIs for remote controlling web browsers<br />
* (link?) APIs for use in debugging of web applications<br />
<br />
=== CSS Working Group ===<br />
[https://www.w3.org/Style/CSS/members Cascading Style Sheets Working Group (CSSWG)], [https://www.w3.org/Style/CSS/members members], [irc://irc.w3.org:6665/css irc], [http://lists.w3.org/Archives/Public/www-style/ email list]<br />
* Looking for where we prioritize our CSS development? See: '''[[CSS#Priorities|CSS:Priorities]]'''<br />
Working group members participating on behalf of Mozilla (also on w3c-css-wg)<br />
* <span class="h-card">[[User:Emilio|Emilio Cobos Álvarez]]</span><br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span><br />
* <span class="h-card">[[User:Dholbert|Daniel Holbert]]</span><br />
* <span class="h-card">[[User:Masayuki|Masayuki Nakano]]</span><br />
* <span class="h-card">[[User:SimonSapin|Simon Sapin]]</span><br />
* <span class="h-card">[[User:Mstange|Markus Stange]]</span><br />
Additional www-style list participants related to Mozilla (anyone is welcome to join)<br />
* <span class="h-card">[[User:Hsivonen|Henri Sivonen]]</span><br />
* ...<br />
Specifications: <br />
* [[CSS21]], [[CSS3]]<br />
For more details see: [[CSS]]<br />
<br />
=== GPU for the Web WG/[https://www.w3.org/community/gpu/ CG] (WebGPU) ===<br />
https://github.com/gpuweb/gpuweb<br />
* <span class="h-card">[[User:Jgilbert|Jeff Gilbert]]</span> (:jgilbert, jdashg) (WGSL Chair)<br />
* <span class="h-card">[[User:Kvark|Dzmitry Malyshau]]</span> (:kvark) (WGSL Spec Editor)<br />
<br />
=== Immersive Web [https://www.w3.org/immersive-web/ WG]/[https://www.w3.org/community/immersive-web/ CG] (WebXR) ===<br />
* <span class="h-card">[[User:Jgilbert|Jeff Gilbert]]</span> (:jgilbert, jdashg)<br />
<br />
=== Internationalization Working Group ===<br />
[https://w3c.github.io/i18n-activity/i18n-wg/ Internationalization Working Group] ([https://www.w3.org/2000/09/dbwg/details?group=32113 members]), part of [http://w3.org/International/ Internationalization Activity (i18n)]<br />
* <span class="h-card">[[User:Stpeter|Peter Saint-Andre]]</span><br />
<br />
=== Pointer Events Working Group ===<br />
[http://www.w3.org/2012/pointerevents/ Pointer Events Working Group home page] ([https://www.w3.org/2000/09/dbwg/details?group=59096&public=1 members]).<br />
Participants:<br />
* <span class="h-card">Olli Pettay</span><br />
<br />
=== SVG Working Group ===<br />
[https://w3.org/SVG/ SVG (Scalable Vector Graphics) Working Group], [https://www.w3.org/Graphics/SVG/2014/new-charter charter expired and WG in-limbo], [https://www.w3.org/2000/09/dbwg/details?group=19480&public=1 members]<br />
* <span class="h-card">Jonathan Watt</span><br />
Specifications: SVG 1.1, SVG 2.0<br />
<br />
=== Web Applications Security Working Group ===<br />
* Eric Rescorla<br />
* Daniel Veditz<br />
* Tanvi Vyas<br />
* Frederik Braun<br />
* Christoph Kerschbaumer<br />
<br />
Specifications: CSP, HSTS Priming, SRI<br />
<br />
=== Web Applications Working Group ===<br />
[https://www.w3.org/2019/webapps/ WebApps WG home page] — ([https://www.w3.org/groups/wg/webapps/participants?sortaff=1 members])<br />
* <span class="h-card"><span class="p-name">[[User:Tantek|Tantek Çelik]]</span> <br />
* <span class="h-card">Andrew Sutherland</span><br />
* <span class="h-card">Martin Thomson</span><br />
<br />
Related incubator group: [https://www.w3.org/community/wicg/ Web Platform Incubator Community Group]<br />
<br />
=== [https://www.w3.org/wasm/ WebAssembly Working Group] ===<br />
WASM:<br />
* [https://www.w3.org/2017/08/wasm-charter charter 2017-08-03 … 2018-07-31]<br />
* [https://www.w3.org/2000/09/dbwg/details?group=101196&order=org&public=1 members]<br />
* Ryan Hunt<br />
<br />
==== WebAssembly Community Group ====<br />
https://www.w3.org/community/webassembly/ ([https://www.w3.org/community/webassembly/participants members])<br />
* Lars Hansen<br />
* Ryan Hunt<br />
<br />
=== Web Authentication Working Group ===<br />
[https://www.w3.org/blog/webauthn/ WebAuthn homepage]<br />
* <span class="h-card">[[User:Jcjones|J.C. Jones]]</span> (editor)<br />
* Dan Veditz<br />
<br />
=== Web Fonts Working Group ===<br />
[https://www.w3.org/Fonts/WG/ Web Fonts Working Group homepage] ([https://www.w3.org/2000/09/dbwg/details?group=44556 members])<br />
* <span class="h-card">Jonathan Kew</span> (editor)<br />
<br />
=== Web Payments Working Group ===<br />
[https://www.w3.org/Payments/WG/ Web Payments Working Group homepage] ([https://www.w3.org/2000/09/dbwg/details?group=83744 members])<br />
* <span class="h-card">[[User:Stpeter|Peter Saint-Andre]]</span><br />
<br />
=== Web Performance Working Group ===<br />
https://www.w3.org/webperf/<br />
* <span class="h-card">Benjamin De Kosnik</span><br />
* <span class="h-card">Sean Feng</span><br />
<br />
Specifications: Navigation Timing, Paint Timing, Event Timing, Element Timing<br />
* <span class="h-card">Olli Pettay</span><br />
<br />
Specifications: DOM-adjacent<br />
Specifications: Timing control for script-based animations (requestAnimationFrame)<br />
<br />
=== WebRTC Working Group ===<br />
[[WebRTC]] (Web Real Time Communications) Working Group<br />
* <span class="h-card">Maire Reavy</span><br />
* <span class="h-card"><span class="p-name">Eric Rescorla</span> (<span class="p-nickname">EKR</span>)</span><br />
* <span class="h-card">Randell Jesup (:jesup)</span><br />
<br />
Specifications: Media capture & [http://www.w3.org/2011/04/webrtc-charter.html streaming APIs]<br />
<br />
Specifications: Media Capture Stream with Worker Extensions [https://w3c.github.io/mediacapture-worker/ mediacapture-worker APIs]<br />
<br />
=== Second Screen Working Group ===<br />
http://www.w3.org/2014/secondscreen/ ([https://www.w3.org/2000/09/dbwg/details?group=74168&public=1 members])<br />
=== Technical Architecture Group ===<br />
=== Tracking Protection Working Group ===<br />
http://www.w3.org/2011/tracking-protection/<br />
* No current Mozilla participants.<br />
Please contact <span class="h-card">[[User:Tantek|Tantek Çelik]]</span> if you have specific needs here and I’ll route your request as needed. -t<br />
<br />
== WHATWG ==<br />
{{main|WHATWG}}<br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span><br />
* <span class="h-card">[[User:Hsivonen|Henri Sivonen]]</span><br />
* <span class="h-card">[[User:Annevk|Anne van Kesteren]]</span><br />
* <span class="h-card">[[User:Pettay|Olli Pettay]]</span> (:smaug)<br />
* <span class="h-card">[[User:Fbraun|Frederik Braun]]</span> (aka mozfreddyb, freddy, freddyb)<br />
* <span class="h-card">[[User:Jgilbert|Jeff Gilbert]]</span> (jgilbert/jdashg on WhatWG/Canvas)<br />
<br />
= other =<br />
<br />
== Alliance for Open Media ==<br />
The [http://aomedia.org/ Alliance for Open Media] develops next-generation media formats, codecs, and technologies. See also [[#NETVC]].<br />
* No one from Mozilla currently. <br />
Please contact <span class="h-card">[[User:Tantek|Tantek Çelik]]</span> if you have specific needs here and I’ll route your request as needed. -t<br />
<br />
== CA/Browser Forum ==<br />
The [http://cabforum.org/ CA/Browser Forum] produces standards in the area of best practice and validation for certificate authorities.<br />
* <span class="h-card">Kathleen Wilson</span><br />
* <span class="h-card">Ben Wilson</span><br />
* <span class="h-card">[[User:Jcjones|J.C. Jones]]</span><br />
<br />
== CalConnect ==<br />
Mozilla is a member of [http://www.calconnect.org/ CalConnect], The Calendaring and Scheduling Consortium, which is not actually affiliated w/ IETF or W3C but in practice drives development and interoperability testing of IETF specs:<br />
* RFC 5545 iCalendar (obsoletes RFC 2445).<br />
* RFC 4791 CalDAV Access protocol<br />
See their [http://www.calconnect.org/CD1104_Calendaring_Standards.shtml Index to Calendaring and Scheduling Standards] for other specific standards that CalConnect is involved with.<br />
<br />
== eIDAS Regulation ==<br />
The [https://ec.europa.eu/digital-single-market/en/discover-eidas eIDAS Regulation] places requirements on electronic identification and trust services. [https://blog.mozilla.org/netpolicy/2020/10/08/the-eus-current-approach-to-qwacs-qualified-website-authentication-certificates-will-undermine-security-on-the-open-web/ Our goal] is to keep the TLS requirements/framework separate and independent from eIDAS and Qualified Website Authentication Certificates ([https://ec.europa.eu/futurium/en/blog/commission-runs-pilot-project-qualified-web-authentication-certificates-qwacs QWACs]).<br />
<br />
* <span class="h-card">Ben Wilson</span><br />
* <span class="h-card">Kathleen Wilson</span><br />
* <span class="h-card">Raegan MacDonald</span><br />
* <span class="h-card">Thyla van der Merwe</span><br />
* <span class="h-card">Udbhav Tiwari</span><br />
<br />
== OASIS ==<br />
* No current Mozilla point of contact<br />
<br />
== XMPP ==<br />
Mozilla is not formally associated with the XSF but has representation indirectly. http://xmpp.org/<br />
* No direct involvement by any current Mozillian<br />
<br />
== C++ ==<br />
C++ is standardized by [http://www.open-std.org/jtc1/sc22/wg21/ ISO/IEC JTC1/SC22/WG21] (informally, the "C++ Standards Committee"). All proposals are publically available [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/ here].<br />
<br />
[https://mozillians.org/en-US/u/bballo/ Botond Ballo] is a member of Canada's delegation to the Committee, and has been attending meetings regularly since September 2013. If you have any feedback about any existing proposal, or would like to explore the idea of putting forth a new proposal, please post to dev-platform and cc Botond.<br />
<br />
== FIDO Alliance ==<br />
Mozilla is a member of the FIDO Alliance, which produces hardware specifications for Web Authentication.<br />
* <span class="h-card">[[User:Jcjones|J.C. Jones]]</span><br />
<br />
== Orgless specs ==<br />
* [[APNG_Specification]]<br />
** fork: [https://gist.github.com/SoniEx2/c679e771d506210378a5 MPNGPNG - Multi-PNG PNG spec]<br />
<br />
= Emeritus =<br />
{{main|Standards/emeritus}}<br />
See: [[Standards/emeritus]] for lists of former Mozillians who worked on standards, and former standards groups or organizations.<br />
<br />
= subpages of {{FULLPAGENAME}}=<br />
{{Special:PrefixIndex/{{FULLPAGENAME}}/}}<br />
<br />
= See Also =<br />
* [[CSS]]<br />
* [[DOM]]<br />
* [[Events]] - which include web standards-related events.<br />
* [[SEO/Standards]] - how to use standards to improve/optimize search results<br />
* [[Standards/license]] - what license Mozilla prefers for standards specifications<br />
* https://platform-status.mozilla.org/</div>Stpeterhttps://wiki.mozilla.org/index.php?title=User:Stpeter&diff=1237181User:Stpeter2021-08-09T21:37:24Z<p>Stpeter: updates</p>
<hr />
<div>Although I mostly help to manage Mozilla's technical partnerships, I'm also active in Internet standards work at the IETF and W3C.</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Standards/w3c-interest-community-groups&diff=1237180Standards/w3c-interest-community-groups2021-08-09T21:34:10Z<p>Stpeter: /* W3C */ added Federated Identity Community Group</p>
<hr />
<div>{{stub}}<br />
<br />
This page tracks [[W3C]] Interest Groups (IGs) and Community Groups (CGs) that Mozillians participate in. Specifically these are IGs and CGs without a related Working Group (WG).<br />
<br />
See the main '''[[Standards]]''' page for WGs and their directly related IGs & CGs (if any).<br />
<br />
== W3C ==<br />
* See [[Standards]] for W3C Working Groups that Mozillians participate in.<br />
<br />
=== Color on the Web Community Group ===<br />
https://www.w3.org/community/colorweb/<br />
* <span class="h-card">[[User:Jgilbert|Jeff Gilbert]]</span><br />
<br />
=== Federated Identity Community Group ===<br />
https://www.w3.org/community/fed-id/<br />
* <span class="h-card">[[User:Stpeter|Peter Saint-Andre]]</span><br />
<br />
=== Games Community Group ===<br />
http://www.w3.org/community/games/<br />
* <span class="h-card">[[User:Dmose|Dan Mosedale]]</span><br />
<br />
=== Immersive Web Community Group ===<br />
https://github.com/immersive-web/proposals - [https://www.w3.org/blog/2018/01/towards-the-immersive-web/ previously known] as [http://www.w3.org/community/webvr/ WebVR Community Group]<br />
* <span class="h-card">[[User:Jgilbert|Jeff Gilbert]]</span><br />
Documents:<br />
* [https://immersive-web.github.io/webxr/ WebXR Device API Editor's Draft]<br />
* [https://immersive-web.github.io/webxr/charter/ draft charter] (towards a WG)<br />
<br />
=== Open UI Community Group ===<br />
https://www.w3.org/community/open-ui/<br />
* <span class="h-card">[[User:Tantek|Tantek Çelik]]</span><br />
<br />
=== Web Education Community Group ===<br />
http://www.w3.org/community/webed/<br />
* <span class="h-card">[[User:Espressive|Schalk Neethling]]</span><br />
<br />
== See Also ==<br />
* [[Standards]]<br />
* [[Standards/emeritus]] - past Mozilla participants in Community Groups</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Security/DOH-resolver-policy&diff=1236497Security/DOH-resolver-policy2021-07-08T14:00:20Z<p>Stpeter: Added CIRA</p>
<hr />
<div>== Mozilla Policy Requirements for DNS over HTTPs Partners ==<br />
<br />
This document describes the minimum set of policy requirements that a party must satisfy to be considered as a potential partner for Mozilla’s Trusted Recursive Resolver (TRR) program. It specifically describes data collection and retention, transparency, and blocking policies and is in addition to any contractual, technical or operational requirements necessary to operate the resolver service. <br />
<br />
==== Privacy Requirements ====<br />
<br />
Mozilla’s TRR is intended to provide better, minimum privacy guarantees to Firefox users than current, ad hoc provisioning of DNS services. As such, resolvers must strictly limit data collection and sharing from the resolver. More specifically:<br />
<br />
::1. The resolver may retain user data (including identifiable data, data associated with user IP addresses, and any non-aggregate anonymized data) but should do so only for the purpose of operating the service and must not retain that data for longer than 24 hours. <br />
:::* Only aggregate data that does not identify individual users or requests may be retained beyond 24 hours. <br />
::2. The resolver must not retain, sell, or transfer to any third party (except as may be required by law) any personal information, IP addresses or other user identifiers, or user query patterns from the DNS queries sent from the Firefox browser.<br /><br />
<br />
::3. The resolver must not combine the data that it collects from queries with any other data in any way that can be used to identify individual end users.<br /><br />
<br />
::4. The resolver must not sell, license, sublicense, or grant any rights to user data to any other person or entity.<br /><br />
<br />
::5. The resolver must support DNS Query Name Minimisation as defined in RFC 7816.<br /><br />
<br />
::6. The resolver must not propagate unnecessary information about queries to authoritative name servers. In particular, the client subnet DNS extension in RFC 7871 must not be sent to servers unless the connection to the authoritative server is encrypted and only to authoritative name servers operated by the domain owner directly or by a DNS provider pursuant to its contract with the domain owner.<br /><br />
<br />
==== Transparency Requirements ====<br />
<br />
The party operating the resolver must be transparent about any data collection and sharing that does occur in accordance with the above requirements. More specifically:<br />
<br />
::1. Privacy Notice. There must be a public privacy notice specifically for the resolver service that documents the specific fields for data that will be retained for 24 hours and that documents specific fields for aggregate data that will be retained beyond 24 hours. The notice should also attest to requirements 2 - 4 above. <br /><br />
<br />
::2. Transparency Report. There must be a transparency report published at least yearly that documents the policy for how the party operating the resolver will handle law enforcement requests for user data and that documents the types and number of requests received and answered, except to the extent such disclosure is prohibited by law.<br />
<br />
==== Blocking & Modification Prohibitions ==== <br />
<br />
::1. The party operating the resolver should not by default block or filter domains unless specifically required by law in the jurisdiction in which the resolver operates. Mozilla will generally seek to work with DNS resolvers that provide unfiltered DNS responses and, at its discretion, may remove from consideration resolvers subject to legal filtering obligations, depending on the scope and nature of those obligations. <br />
:::* Resolvers may block or filter content with the user’s explicit consent.<br />
::2. For any filtering that does occur under the above requirement, the party must maintain public documentation of all domains that are blocked and a log of when particular domains are added and removed from any blocklist.<br /><br />
<br />
::3. When a domain requested by the user is not present, the party operating the resolver should provide an accurate NXDOMAIN response and must not modify the response or provide inaccurate responses that direct the user to alternative content. <br />
<br />
== Enforcement ==<br />
The decision of who to include in (or remove from) Mozilla’s Trusted Recursive Resolver (TRR) program is at Mozilla’s sole discretion, and we may evaluate additional factors such as abusive practices or other security concerns not specifically identified here. We intend to publicly document violations of this Policy and take additional actions if necessary.<br />
<br />
== Conforming Resolvers ==<br />
The following providers have contractually agreed to abide by these policy requirements:<br />
<br />
{| class="wikitable"<br />
|CIRA || [https://www.cira.ca/cybersecurity-services/canadian-shield/privacy Privacy policy] || https://private.canadianshield.cira.ca/dns-query<br />
|-<br />
|Cloudflare || [https://developers.cloudflare.com/1.1.1.1/privacy/firefox/ Privacy policy] || https://mozilla.cloudflare-dns.com/dns-query<br />
|-<br />
|Comcast || [https://www.xfinity.com/privacy/policy/dns Privacy policy] || https://doh.xfinity.com/dns-query <br />
|-<br />
|NextDNS || [https://nextdns.io/privacy Privacy policy] || https://firefox.dns.nextdns.io <br />
|}<br />
<br />
(Per [https://wiki.mozilla.org/index.php?title=User_talk:Wthayer&oldid=1221836 Wthayer] for Cloudflare and NextDNS; per [https://wiki.mozilla.org/index.php?title=User_talk:Stpeter Stpeter] for CIRA and Comcast.)</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Security/DNS_Over_HTTPS&diff=1229233Security/DNS Over HTTPS2020-07-17T19:34:44Z<p>Stpeter: text tweak: enabled => available</p>
<hr />
<div>This article describes the various mechanics of Firefox's DNS over HTTPS (DoH) frontend. See [[Trusted Recursive Resolver]] for details on TRR implementation in necko.<br />
<br />
'''Implementation:''' https://searchfox.org/mozilla-central/source/browser/components/doh<br />
<br />
== Flow Diagram ==<br />
<br />
[[File:DoH Controller Flow Diagram.png|750px|frameless|DoH Frontend Flow Diagram]]<br />
<br />
== Rollout ==<br />
<br />
* The DoH frontend and its sub-features are gated behind prefs that are set to true via Normandy Rollouts, which allows us to target specific regions and control population size and growth so we can manage risk. <br />
* The pref `doh-rollout.enabled`, serves as a blanket gate. Every mechanism described below depends on this pref being set to true.<br />
* Individual mechanisms may be additionally gated behind their own prefs. This is indicated where relevant.<br />
<br />
See also:<br />
# https://bugzilla.mozilla.org/show_bug.cgi?id=1571543<br />
<br />
== Heuristics ==<br />
<br />
* We run various heuristics to determine whether the network is (un)suitable to enable DoH.<br />
* The heuristics are run at startup and upon network changes.<br />
* DoH is enabled on the network if all heuristics pass, and disabled otherwise.<br />
* Main article: [[Security/DNS Over HTTPS/Heuristics]].<br />
<br />
== Respecting User-choice ==<br />
<br />
* If we detect that the user changed their DoH settings in about:preferences, we permanently turn off our heuristics and other mechanisms. The user-set values are obeyed.<br />
* This holds for prefs that were set prior to enrollment in the rollout.<br />
<br />
== Enterprise Policy ==<br />
<br />
* In order to avoid interfering with enterprise-configured network behaviors, we disable our heuristics and other mechanisms if any policy is active on the client.<br />
* This is true whether the policy is configured on the local machine or propagated by the network e.g. via Group Policy.<br />
* If a DNSOverHTTPS policy to turn on DoH is in effect, this is respected and heuristics and other mechanisms will be enabled.<br />
<br />
== Default Provider Selection ==<br />
<br />
* Before running heuristics for the first time, we attempt to choose one of the available providers as the default for the profile.<br />
* The chosen default is used whenever DoH is enabled, via the pref `doh-rollout.uri`.<br />
* A network-provided endpoint, if detected, will take precedence over the default provider when on that network. (See Provider Steering below)<br />
* This feature is controlled by the prefs `doh-rollout.trr-selection.enabled`.<br />
* Choice of provider is made by using each available provider to do lookup several popular domains as well as random subdomains of `firefox-dns-perf-test.net`.<br />
<br />
See also:<br />
# https://searchfox.org/mozilla-central/source/browser/components/doh/TRRPerformance.jsm<br />
<br />
==== Dry-Run Mechanism ====<br />
<br />
* Default provider selection is done in two phases: a dry-run followed by committing the result.<br />
* By default, this feature is dry-run-only, and records the result in a pref `doh-rollout.trr-selection.dry-run-result`.<br />
* Committing the result is enabled by another pref `doh-rollout.trr-selection.commit-result`. If this is true, then after the dry-run step, the `dry-run-result` will be copied into `doh-rollout.uri`.<br />
<br />
[[File:DoH automatic provider selection flow.png|600px|frameless|DoH automatic provider selection flow]]<br />
<br />
== Provider Steering ==<br />
<br />
* Some providers supply their own DoH endpoints which we want to use if indicated.<br />
* This capability is discovered via the CNAME response when looking up the domain `doh.test`.<br />
* Discovery is only attempted if all heuristics are passing on the network.<br />
* A DoH endpoint discovered in this manner takes precedence over the automatically chosen default provider (see Default Provider Selection above).<br />
* A provider (endpoint + expected CNAME for discovery) must be explicitly supported for this mechanism to work.<br />
* Currently, Comcast is the only supported provider.<br />
* This feature is controlled by the pref `doh-rollout.provider-steering.enabled`.<br />
<br />
[[File:DoH provider steering flow.png|700px|frameless|DoH Provider Steering Flow]]<br />
<br />
See also:<br />
# https://datatracker.ietf.org/doc/draft-rescorla-doh-cdisco/<br />
<br />
== Opt-out Doorhanger ==<br />
<br />
[[File:Cfr.png|frameless|DoH CFR message screenshot]]<br />
<br />
* When the client is first enrolled in the rollout, we show a doorhanger popup to let the user know that DoH is available.<br />
* This doorhanger offers an option to opt-out, which results in permanently disabling heuristics and other mechanisms.<br />
* The doorhanger is shown only if the rollout is "successful" - i.e. the user did not already have custom DoH preferences or active enterprise policy.<br />
* The doorhanger is implemented as a CFR message, gated behind the relevant prefs.<br />
<br />
See also:<br />
# https://bugzilla.mozilla.org/show_bug.cgi?id=1643651<br />
<br />
== Telemetry ==<br />
<br />
* Interaction and functional data is collected in the form of two telemetry Events.<br />
* A ''state'' event is sent when the DoHController's state changes, e.g. when DoH is enabled or disabled on the network, when a user-choice results in disabling heuristics, when a rollback is detected, etc.<br />
* A ''heuristics'' event is sent whenever we run heuristics, containing the result of each heuristic as its payload, along with the trigger (e.g. startup, network change) and the provider steering status.<br />
<br />
See also:<br />
# https://searchfox.org/mozilla-central/rev/1b95a0179507a4dc7d4b0c94c2df420dc1a72885/toolkit/components/telemetry/Events.yaml#2097-2158<br />
<br />
== Migrations ==<br />
<br />
* We have several migrations to support users upgrading from older versions of Firefox as well as the rollout when they upgrade to newer versions.<br />
* Two of the migrations work on the format of stored state (local storage and prefs)<br />
* During a dry-run-only test of Default Provider Selection, an underlying bug was triggered that caused clients to effectively DDoS NextDNS's endpoint. In the aftermath, a new endpoint was set up and we have a migration to convert occurrences of the old endpoint in stored URI values to the new one.<br />
<br />
== Prefs ==<br />
<br />
* TODO: list all involved prefs and semantics.</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Security/DOH-resolver-policy&diff=1228624Security/DOH-resolver-policy2020-06-29T20:35:57Z<p>Stpeter: Add Comcast, update NextDNS endpoint</p>
<hr />
<div>== Mozilla Policy Requirements for DNS over HTTPs Partners ==<br />
<br />
This document describes the minimum set of policy requirements that a party must satisfy to be considered as a potential partner for Mozilla’s Trusted Recursive Resolver (TRR) program. It specifically describes data collection and retention, transparency, and blocking policies and is in addition to any contractual, technical or operational requirements necessary to operate the resolver service. <br />
<br />
==== Privacy Requirements ====<br />
<br />
Mozilla’s TRR is intended to provide better, minimum privacy guarantees to Firefox users than current, ad hoc provisioning of DNS services. As such, resolvers must strictly limit data collection and sharing from the resolver. More specifically:<br />
<br />
::1. The resolver may retain user data (including identifiable data, data associated with user IP addresses, and any non-aggregate anonymized data) but should do so only for the purpose of operating the service and must not retain that data for longer than 24 hours. <br />
:::* Only aggregate data that does not identify individual users or requests may be retained beyond 24 hours. <br />
::2. The resolver must not retain, sell, or transfer to any third party (except as may be required by law) any personal information, IP addresses or other user identifiers, or user query patterns from the DNS queries sent from the Firefox browser.<br /><br />
<br />
::3. The resolver must not combine the data that it collects from queries with any other data in any way that can be used to identify individual end users.<br /><br />
<br />
::4. The resolver must not sell, license, sublicense, or grant any rights to user data to any other person or entity.<br /><br />
<br />
::5. The resolver must support DNS Query Name Minimisation as defined in RFC 7816.<br /><br />
<br />
::6. The resolver must not propagate unnecessary information about queries to authoritative name servers. In particular, the client subnet DNS extension in RFC 7871 must not be sent to servers unless the connection to the authoritative server is encrypted and only to authoritative name servers operated by the domain owner directly or by a DNS provider pursuant to its contract with the domain owner.<br /><br />
<br />
==== Transparency Requirements ====<br />
<br />
The party operating the resolver must be transparent about any data collection and sharing that does occur in accordance with the above requirements. More specifically:<br />
<br />
::1. Privacy Notice. There must be a public privacy notice specifically for the resolver service that documents the specific fields for data that will be retained for 24 hours and that documents specific fields for aggregate data that will be retained beyond 24 hours. The notice should also attest to requirements 2 - 4 above. <br /><br />
<br />
::2. Transparency Report. There must be a transparency report published at least yearly that documents the policy for how the party operating the resolver will handle law enforcement requests for user data and that documents the types and number of requests received and answered, except to the extent such disclosure is prohibited by law.<br />
<br />
==== Blocking & Modification Prohibitions ==== <br />
<br />
::1. The party operating the resolver should not by default block or filter domains unless specifically required by law in the jurisdiction in which the resolver operates. Mozilla will generally seek to work with DNS resolvers that provide unfiltered DNS responses and, at its discretion, may remove from consideration resolvers subject to legal filtering obligations, depending on the scope and nature of those obligations. <br />
:::* Resolvers may block or filter content with the user’s explicit consent.<br />
::2. For any filtering that does occur under the above requirement, the party must maintain public documentation of all domains that are blocked and a log of when particular domains are added and removed from any blocklist.<br /><br />
<br />
::3. When a domain requested by the user is not present, the party operating the resolver should provide an accurate NXDOMAIN response and must not modify the response or provide inaccurate responses that direct the user to alternative content. <br />
<br />
== Enforcement ==<br />
The decision of who to include in (or remove from) Mozilla’s Trusted Recursive Resolver (TRR) program is at Mozilla’s sole discretion, and we may evaluate additional factors such as abusive practices or other security concerns not specifically identified here. We intend to publicly document violations of this Policy and take additional actions if necessary.<br />
<br />
== Conforming Resolvers ==<br />
The following providers have contractually agreed to abide by these policy requirements:<br />
<br />
{| class="wikitable"<br />
|Cloudflare || [https://developers.cloudflare.com/1.1.1.1/privacy/firefox/ Privacy policy] || https://mozilla.cloudflare-dns.com/dns-query<br />
|-<br />
|Comcast || [https://www.xfinity.com/privacy/policy/dns Privacy policy] || https://doh.xfinity.com/dns-query <br />
|-<br />
|NextDNS || [https://nextdns.io/privacy Privacy policy] || https://firefox.dns.nextdns.io <br />
|}<br />
<br />
(Per [https://wiki.mozilla.org/index.php?title=User_talk:Wthayer&oldid=1221836| Wthayer] for Cloudflare and NextDNS; per [https://wiki.mozilla.org/index.php?title=User_talk:Stpeter| Stpeter] for Comcast.)</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Security/DOH-resolver-policy&diff=1225766Security/DOH-resolver-policy2020-04-02T17:25:19Z<p>Stpeter: Updated the URL for the Cloudflare privacy policy</p>
<hr />
<div>== Mozilla Policy Requirements for DNS over HTTPs Partners ==<br />
<br />
This document describes the minimum set of policy requirements that a party must satisfy to be considered as a potential partner for Mozilla’s Trusted Recursive Resolver (TRR) program. It specifically describes data collection and retention, transparency, and blocking policies and is in addition to any contractual, technical or operational requirements necessary to operate the resolver service. <br />
<br />
==== Privacy Requirements ====<br />
<br />
Mozilla’s TRR is intended to provide better, minimum privacy guarantees to Firefox users than current, ad hoc provisioning of DNS services. As such, resolvers must strictly limit data collection and sharing from the resolver. More specifically:<br />
<br />
::1. The resolver may retain user data (including identifiable data, data associated with user IP addresses, and any non-aggregate anonymized data) but should do so only for the purpose of operating the service and must not retain that data for longer than 24 hours. <br />
:::* Only aggregate data that does not identify individual users or requests may be retained beyond 24 hours. <br />
::2. The resolver must not retain, sell, or transfer to any third party (except as may be required by law) any personal information, IP addresses or other user identifiers, or user query patterns from the DNS queries sent from the Firefox browser.<br /><br />
<br />
::3. The resolver must not combine the data that it collects from queries with any other data in any way that can be used to identify individual end users.<br /><br />
<br />
::4. The resolver must not sell, license, sublicense, or grant any rights to user data to any other person or entity.<br /><br />
<br />
::5. The resolver must support DNS Query Name Minimisation as defined in RFC 7816.<br /><br />
<br />
::6. The resolver must not propagate unnecessary information about queries to authoritative name servers. In particular, the client subnet DNS extension in RFC 7871 must not be sent to servers unless the connection to the authoritative server is encrypted and only to authoritative name servers operated by the domain owner directly or by a DNS provider pursuant to its contract with the domain owner.<br /><br />
<br />
==== Transparency Requirements ====<br />
<br />
The party operating the resolver must be transparent about any data collection and sharing that does occur in accordance with the above requirements. More specifically:<br />
<br />
::1. Privacy Notice. There must be a public privacy notice specifically for the resolver service that documents the specific fields for data that will be retained for 24 hours and that documents specific fields for aggregate data that will be retained beyond 24 hours. The notice should also attest to requirements 2 - 4 above. <br /><br />
<br />
::2. Transparency Report. There must be a transparency report published at least yearly that documents the policy for how the party operating the resolver will handle law enforcement requests for user data and that documents the types and number of requests received and answered, except to the extent such disclosure is prohibited by law.<br />
<br />
==== Blocking & Modification Prohibitions ==== <br />
<br />
::1. The party operating the resolver should not by default block or filter domains unless specifically required by law in the jurisdiction in which the resolver operates. Mozilla will generally seek to work with DNS resolvers that provide unfiltered DNS responses and, at its discretion, may remove from consideration resolvers subject to legal filtering obligations, depending on the scope and nature of those obligations. <br />
:::* Resolvers may block or filter content with the user’s explicit consent.<br />
::2. For any filtering that does occur under the above requirement, the party must maintain public documentation of all domains that are blocked and a log of when particular domains are added and removed from any blocklist.<br /><br />
<br />
::3. When a domain requested by the user is not present, the party operating the resolver should provide an accurate NXDOMAIN response and must not modify the response or provide inaccurate responses that direct the user to alternative content. <br />
<br />
== Enforcement ==<br />
The decision of who to include in (or remove from) Mozilla’s Trusted Recursive Resolver (TRR) program is at Mozilla’s sole discretion, and we may evaluate additional factors such as abusive practices or other security concerns not specifically identified here. We intend to publicly document violations of this Policy and take additional actions if necessary.<br />
<br />
== Conforming Resolvers ==<br />
The following providers have contractually agreed to abide by these policy requirements ([https://wiki.mozilla.org/index.php?title=User_talk:Wthayer&oldid=1221836| per Wthayer]):<br />
<br />
{| class="wikitable"<br />
|Cloudflare || [https://developers.cloudflare.com/1.1.1.1/privacy/firefox/ Privacy policy] || https://mozilla.cloudflare-dns.com/dns-query<br />
|-<br />
|NextDNS || [https://nextdns.io/privacy Privacy policy] || https://dns.nextdns.io <br />
|}</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Add-ons/Expired-Certificate-Technical-Report&diff=1214987Add-ons/Expired-Certificate-Technical-Report2019-07-12T17:55:29Z<p>Stpeter: duplicate words</p>
<hr />
<div>== Firefox Add-On Outage Technical Report: Analysis and Recommendations ==<br />
<br />
Authors: [https://mozillians.org/en-US/u/stpeter/ Peter Saint-Andre], [https://mozillians.org/u/m_and_m/ Matthew A. Miller]<br />
<br />
Last updated: 2019-07-02<br />
<br />
=== Introduction ===<br />
On May 3, 2019, the intermediate certificate used to sign all deployed add-ons expired. Although this expiration was not unexpected (in fact, plans were in place to deploy a replacement certificate, which had already been generated), the consequences were unforeseen: almost all deployed add-ons stopped working for millions of Firefox users. This report summarizes our findings regarding the technical aspects of this incident and provides recommendations for avoiding or mitigating such incidents in the future.<br />
<br />
=== Root Causes ===<br />
On the face of it, the root cause might seem simple: a signing certificate expired and we didn’t renew it in time. If we just fix our monitoring tools and pay attention in the future, this won’t happen again. Right?<br />
<br />
Unfortunately, it’s not that simple.<br />
<br />
Yes, a signing certificate expired. But this would not necessarily cause Firefox to treat existing add-ons as invalid. Would it be good enough for the signature to be valid at the time the add-on was signed? Should we really need to re-sign all existing add-ons whenever we generate a new signing certificate (even if this were feasible), or would we use a new cert only for newly-issued add-ons? How would we handle add-ons for long-lived releases like ESR? And so on.<br />
<br />
A combination of factors was involved here: (1) the expiration of a signing cert and (2) runtime code for checking the date of that signing cert during add-on validation. Thus the primary root cause was more about differing assumptions than a failure to monitor or update. Specifically:<br />
<br />
* The server-side teams whose systems (e.g., Autograph) generate signatures knew the certificate was expiring, but did not see a problem because they had reason to believe that signing certificate dates were not checked by the client.<br />
* The client-side teams whose code performs add-on validation knew that dates were not checked for end-entity certificates (we modified this behavior in [https://bugzilla.mozilla.org/show_bug.cgi?id=1267318 a previous outage]), but might not have realized that dates for intermediate certificates were still checked when invoking the [https://searchfox.org/mozilla-central/rev/7556a400affa9eb99e522d2d17c40689fa23a729/security/manager/ssl/nsIX509CertDB.idl#230-266 nsIX509CertDB] function in the core SSL library.<br />
* The crypto teams who maintain that SSL library simply provide an API and aren’t responsible for how client-side code uses that API.<br />
* The testing teams who ensure the quality of Firefox weren’t aware of the need for test coverage of expiring intermediate certificates.<br />
<br />
These various teams did not cross-check their underlying assumptions and understandings, or engage in “what-if” scenario planning and future testing. Thus the broader Firefox team did not have a firm grasp on the functioning of a complex system with the potential to impact the entire Firefox user base.<br />
<br />
Our conclusion is that this incident was not the fault of any individual or team, but was the result of having an interlocking set of complex systems that were not well understood across all the relevant teams.<br />
<br />
=== Secondary Complications ===<br />
The various teams mentioned above, and many others, responded quickly, professionally, and thoroughly once the scope and impact of the incident were realized. The effort involved was truly impressive.<br />
<br />
However, several aspects of the response were hindered by secondary complications, and it is helpful to understand these in addition to the root causes.<br />
<br />
First, we have a very large number of deployment targets, not all of which can be handled in the same way, and we had several techniques (hotfixes, dot releases, etc.) available for pushing changes out to different platforms and versions. Lack of understanding and documentation about these targets and techniques caused some delays in deployment of fixes.<br />
<br />
Second, because the initial hotfix involved Normandy (which required users to voluntarily enable Telemetry if they had it turned off), we gathered more data than we ordinarily do, and lost legitimate data in the process purging this over-gathered data. Additionally, other Normandy studies were temporarily disrupted which could have impacted their outcomes.<br />
<br />
Third, lack of documentation and experience with emergency processes led to some confusion and delay in responding (e.g., responsibilities are not always well understood before incidents occur and emergency contact procedures and methods were not well established).<br />
<br />
Fourth, the lack of in-house or on-call QA resources caused delays in testing proposed fixes across various platforms because our external teams at Softvision were not immediately available through normal channels (in fact, engaging with individual Softvision team members could have introduced legal complications and the potential for data leakage).<br />
<br />
=== Recommendations ===<br />
Spurred by this incident, teams from many areas of Mozilla have already been thinking about opportunities for improvement in our systems, processes, documentation, and operations. At a high level, we suggest a focus on the following areas. This fuller remediation does have a deadline; the newly created intermediate certificate that resolved this incident is set to expire in 2025.<br />
<br />
Most fundamentally, the full Firefox team does not have a common understanding of the role, function, and operation of cryptographic signatures for Firefox add-ons. For instance, although there are several good reasons for signing add-ons (monitoring add-ons not hosted on AMO, blocklisting malicious add-ons, providing cryptographic assurance by chaining add-ons to the Mozilla root), there is no shared consensus on the fundamental rationale for doing so. In addition, maintaining a full public key infrastructure (PKI) is a complex task and we do not necessarily have a firm grasp of the engineering and business tradeoffs involved. More complete documentation of the overall system (and the role of each sub-system therein) is critically important, as is communication about that architecture to all relevant teams and training of new team members. This documentation should include accurate, up-to-date information about all relevant inputs, outputs, dependencies, APIs, protocols, formats (e.g., subject and issuer identities), tooling, monitoring, operations, and responsible teams and/or individuals.<br />
<br />
Second, if we are committed to the current PKI and add-on signing approach, we should make improvements to our certificate management processes, especially our key rollover strategies. This will involve clear procedures for handling revoked and expiring intermediate and root certificates, including the impact on existing add-ons, updated add-ons, and new add-ons for the full range of both add-ons (web extensions, themes, language packs, etc.) and current/legacy release channels. Expectations need to be set and communicated for all aspects of key rollover, including but not limited to management of the offline hardware security module (HSM), interactions with the cloud HSM, monitoring of expiration times for the full set of deployed certificates, client-side validation of the full certificate chain (end-entity, intermediate, and root), acceptable expiry ranges, and extensive testing and future-proofing (such as setting system clocks to future times on selected test rigs).<br />
<br />
Third, we need to rationalize and improve our code delivery mechanisms. This involves several things. For instance, we need a much better and communicated “map” of the full range of our deployment targets: not just current desktop targets (Nightly, Beta, Dev Edition, Release, ESR) but also mobile and mixed reality as well as legacy versions which we judge important enough to update even if they are not officially supported. We need a clear understanding of hotfix techniques (e.g., Balrog vs. Normandy or a more special-purpose tool) and dot-release requirements across those deployment targets. We need to decouple our update mechanisms from data gathering mechanisms. And we need to set clear expectations internally, with end users, and with partners.</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Add-ons/Expired-Certificate-Technical-Report&diff=1214985Add-ons/Expired-Certificate-Technical-Report2019-07-12T17:54:07Z<p>Stpeter: corrected text about checking of certificate expiration</p>
<hr />
<div>== Firefox Add-On Outage Technical Report: Analysis and Recommendations ==<br />
<br />
Authors: [https://mozillians.org/en-US/u/stpeter/ Peter Saint-Andre], [https://mozillians.org/u/m_and_m/ Matthew A. Miller]<br />
<br />
Last updated: 2019-07-02<br />
<br />
=== Introduction ===<br />
On May 3, 2019, the intermediate certificate used to sign all deployed add-ons expired. Although this expiration was not unexpected (in fact, plans were in place to deploy a replacement certificate, which had already been generated), the consequences were unforeseen: almost all deployed add-ons stopped working for millions of Firefox users. This report summarizes our findings regarding the technical aspects of this incident and provides recommendations for avoiding or mitigating such incidents in the future.<br />
<br />
=== Root Causes ===<br />
On the face of it, the root cause might seem simple: a signing certificate expired and we didn’t renew it in time. If we just fix our monitoring tools and pay attention in the future, this won’t happen again. Right?<br />
<br />
Unfortunately, it’s not that simple.<br />
<br />
Yes, a signing certificate expired. But this would not necessarily cause Firefox to treat existing add-ons as invalid. Would it be good enough for the signature to be valid at the time the add-on was signed? Should we really need to re-sign all existing add-ons whenever we generate a new signing certificate (even if this were feasible), or would we use a new cert only for newly-issued add-ons? How would we handle add-ons for long-lived releases like ESR? And so on.<br />
<br />
A combination of factors was involved here: (1) the expiration of a signing cert and (2) runtime code for checking the date of that signing cert during add-on validation. Thus the primary root cause was more about differing assumptions than a failure to monitor or update. Specifically:<br />
<br />
* The server-side teams whose systems (e.g., Autograph) generate signatures knew the certificate was expiring, but did not see a problem because they had reason to believe that signing certificate dates were not checked by the client.<br />
* The client-side teams whose code performs add-on validation knew that dates were not checked for end-entity certificates (we modified this behavior in a previous [https://bugzilla.mozilla.org/show_bug.cgi?id=1267318 a previous outage]), but might not have realized that dates for intermediate certificates were still checked when invoking the [https://searchfox.org/mozilla-central/rev/7556a400affa9eb99e522d2d17c40689fa23a729/security/manager/ssl/nsIX509CertDB.idl#230-266 nsIX509CertDB] function in the core SSL library.<br />
* The crypto teams who maintain that SSL library simply provide an API and aren’t responsible for how client-side code uses that API.<br />
* The testing teams who ensure the quality of Firefox weren’t aware of the need for test coverage of expiring intermediate certificates.<br />
<br />
These various teams did not cross-check their underlying assumptions and understandings, or engage in “what-if” scenario planning and future testing. Thus the broader Firefox team did not have a firm grasp on the functioning of a complex system with the potential to impact the entire Firefox user base.<br />
<br />
Our conclusion is that this incident was not the fault of any individual or team, but was the result of having an interlocking set of complex systems that were not well understood across all the relevant teams.<br />
<br />
=== Secondary Complications ===<br />
The various teams mentioned above, and many others, responded quickly, professionally, and thoroughly once the scope and impact of the incident were realized. The effort involved was truly impressive.<br />
<br />
However, several aspects of the response were hindered by secondary complications, and it is helpful to understand these in addition to the root causes.<br />
<br />
First, we have a very large number of deployment targets, not all of which can be handled in the same way, and we had several techniques (hotfixes, dot releases, etc.) available for pushing changes out to different platforms and versions. Lack of understanding and documentation about these targets and techniques caused some delays in deployment of fixes.<br />
<br />
Second, because the initial hotfix involved Normandy (which required users to voluntarily enable Telemetry if they had it turned off), we gathered more data than we ordinarily do, and lost legitimate data in the process purging this over-gathered data. Additionally, other Normandy studies were temporarily disrupted which could have impacted their outcomes.<br />
<br />
Third, lack of documentation and experience with emergency processes led to some confusion and delay in responding (e.g., responsibilities are not always well understood before incidents occur and emergency contact procedures and methods were not well established).<br />
<br />
Fourth, the lack of in-house or on-call QA resources caused delays in testing proposed fixes across various platforms because our external teams at Softvision were not immediately available through normal channels (in fact, engaging with individual Softvision team members could have introduced legal complications and the potential for data leakage).<br />
<br />
=== Recommendations ===<br />
Spurred by this incident, teams from many areas of Mozilla have already been thinking about opportunities for improvement in our systems, processes, documentation, and operations. At a high level, we suggest a focus on the following areas. This fuller remediation does have a deadline; the newly created intermediate certificate that resolved this incident is set to expire in 2025.<br />
<br />
Most fundamentally, the full Firefox team does not have a common understanding of the role, function, and operation of cryptographic signatures for Firefox add-ons. For instance, although there are several good reasons for signing add-ons (monitoring add-ons not hosted on AMO, blocklisting malicious add-ons, providing cryptographic assurance by chaining add-ons to the Mozilla root), there is no shared consensus on the fundamental rationale for doing so. In addition, maintaining a full public key infrastructure (PKI) is a complex task and we do not necessarily have a firm grasp of the engineering and business tradeoffs involved. More complete documentation of the overall system (and the role of each sub-system therein) is critically important, as is communication about that architecture to all relevant teams and training of new team members. This documentation should include accurate, up-to-date information about all relevant inputs, outputs, dependencies, APIs, protocols, formats (e.g., subject and issuer identities), tooling, monitoring, operations, and responsible teams and/or individuals.<br />
<br />
Second, if we are committed to the current PKI and add-on signing approach, we should make improvements to our certificate management processes, especially our key rollover strategies. This will involve clear procedures for handling revoked and expiring intermediate and root certificates, including the impact on existing add-ons, updated add-ons, and new add-ons for the full range of both add-ons (web extensions, themes, language packs, etc.) and current/legacy release channels. Expectations need to be set and communicated for all aspects of key rollover, including but not limited to management of the offline hardware security module (HSM), interactions with the cloud HSM, monitoring of expiration times for the full set of deployed certificates, client-side validation of the full certificate chain (end-entity, intermediate, and root), acceptable expiry ranges, and extensive testing and future-proofing (such as setting system clocks to future times on selected test rigs).<br />
<br />
Third, we need to rationalize and improve our code delivery mechanisms. This involves several things. For instance, we need a much better and communicated “map” of the full range of our deployment targets: not just current desktop targets (Nightly, Beta, Dev Edition, Release, ESR) but also mobile and mixed reality as well as legacy versions which we judge important enough to update even if they are not officially supported. We need a clear understanding of hotfix techniques (e.g., Balrog vs. Normandy or a more special-purpose tool) and dot-release requirements across those deployment targets. We need to decouple our update mechanisms from data gathering mechanisms. And we need to set clear expectations internally, with end users, and with partners.</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Add-ons/Expired-Certificate&diff=1214906Add-ons/Expired-Certificate2019-07-10T22:30:08Z<p>Stpeter: spelling correction</p>
<hr />
<div>== Add-ons Incident Retrospective Summary ==<br />
<br />
Authored by: [https://mozillians.org/en-US/u/smooney/ Sheila Mooney]<br />
<br />
=== Overall Status === <br />
We have spoken to many of the individuals directly involved in the response as well as the teams working directly with the certificate management and add-on signing systems. We have a list of opportunities for improvement and next steps are to prioritize and find owners to drive some of these investigations and changes forward. <br />
<br />
=== Problem Statement === <br />
On May 4th, 2019 at midnight UTC, the intermediate certificate used as part of the add-on signing process expired. The result was that every add-on signed using this certificate could not be loaded into Firefox. For many of our users, the internet was broken and their experience was severely impacted. Approximately 40 to 50 percent of our users have add-ons. Eric Rescorla published a [https://hacks.mozilla.org/2019/05/technical-details-on-the-recent-firefox-add-on-outage/ blog post] shortly following the incident summarizing in more detail what happened.<br />
<br />
=== Response & Timeline ===<br />
Our users reported the issue on Twitter, Reddit and other social channels. We mobilized our incident response, tweeted to let our users know we were aware of the issue and worked on solutions for the problem. Approximately 6 hours post-incident we published a fix via a Normandy study to delay regular add-on signature update checks. Within 9 hours of the issue, we shipped a new certificate, also via Normandy, with an updated validity window. Dot releases for both Desktop, Fennec and ESR were released within 48 hrs and a number of follow-on fixes went out to support users on older versions of Firefox. Our last fix was deployed on May 24th. A timeline of remediations can be seen below.<br />
<br />
[[File:Armagaddon-timeline.png|1100px]]<br />
<br />
=== Post Mortem ===<br />
Hundreds of staff and volunteers came together to respond to the incident. We could not interview all of them but we did speak to over 30 individuals to understand how this happened, how we responded and what we can improve going forward. <br />
<br />
=== Root Cause === <br />
This situation wasn’t as simple as “we let a certificate expire before it could be renewed”. We were aware of the expiry date when the certificate was issued 2 years ago. Peter Saint-Andre and Matthew Miller put together a more detailed [[Add-ons/Expired-Certificate-Technical-Report|technical report]] on the root cause. Next steps for helping protect us against this in the future involve a more detailed review of how we handle add-on security in general.<br />
<br />
=== Opportunities for Improvement === <br />
One of the most important aspects of a post mortem are the learnings and opportunities for improvement and discussion. The Firefox organization will be working through the following list of improvements and spinning up projects to investigate further and drive them forward.<br />
<br />
{| class="wikitable"<br />
|-<br />
! '''Opportunity''' !! '''Next Steps'''<br />
|-<br />
| Tuning our Incident Command Process by looking at some of the following areas to create a more structured playbook:<br />
* Crisis levels and descriptions.<br />
* Phone numbers, back-ups and contact protocols.<br />
* Clear owners and roles.<br />
* Clear processes for incident kickoff, handoffs and documentation.<br />
* Template support responses that can be customized for each situation.<br />
* Documented safety response procedures.<br />
* Protocols to ensure we have things like passwords for social media accounts.<br />
* What are all the blogs and communication channels we have and when to use them.<br />
|| Work has already started on this. We are capturing some improvements. Next steps are to review what we have and identify gaps. <br />
|-<br />
| A full map of all the various deployment channels we can use to ship code to users for all our products<br />
* Balrog, Normandy, Dot Releases etc.<br />
* Clear understanding of how many users we reach.<br />
* Process and decisions for using a particular channel.<br />
* Trade offs and impact analysis.<br />
* Clear decision makers and owners for each channel.<br />
* Shipping checklist and process.<br />
|| Confusion around our deployment channels surfaced in many of the post mortem discussions. Next steps are to find a lead and team to tackle this project. Pieces of this are underway already.<br />
|-<br />
| Investigate a plan for deploying a “real” hotfix to everybody (big red button) in a similar emergency. We had to deploy multiple dot releases and other remediations just to get everybody running again. || Identify a team of people to talk about a strategy and approach. Some discussions happening already but we need to craft a formal project around them.<br />
|-<br />
| As we attempted to deploy remediations we kept running into a number of bugs and edge cases to handle. We recommend that we map out a full failure cascade in detail to understand if there are improvements we can make for the future. || Talk to QA/Relman about an owner for this exercise.<br />
|-<br />
| Detailed audit of anything with an expiry date so we understand what other time bombs might be out there. [https://bugzilla.mozilla.org/show_bug.cgi?id=1555978 Bug logged]. || We have logged a bug already. Next steps are to find an owner.<br />
|-<br />
| Plan for the certificate that will expire in 2025. [https://bugzilla.mozilla.org/show_bug.cgi?id=1549018 Bug logged]. || We have logged a bug already. Next steps are to find an owner.<br />
|-<br />
| Now that we understand the importance of add-on support for mobile (ratings plummeted during the incident), we might want to reconsider that strategy/priority for Fenix. || Product discussion and decision to make here.<br />
|-<br />
| Solution for QA support on the weekend and during an incident of this level. This can be broader and cover how we handle incidents outside of the more normal business hours. || Raised with Engineering Leadership. Look at next steps for prioritizing.<br />
|-<br />
| <br />
Detailed post mortem to look at events and decisions that caused us to delete a week’s worth of Telemetry data for all Desktop users.<br />
Investigate some broadcast mechanism in our product so we can let our users know that we are aware of an issue. We used many channels, responded to threads directly. This was time consuming.<br />
|| <br />
To be scheduled post Whistler all-hands.<br />
Needs to be prioritized in the context of other investigations.<br />
<br />
|-<br />
| Deeper investigation into the systems involved for handling add-ons and security.<br />
* Better understanding of how the add-on signing system works and more complete documentation of the entire system.<br />
* Improvements to our certificate management process and key rollover strategies<br />
|| Project is underway to investigate this further. Will likely break out into multiple sub projects.<br />
|-<br />
| Explore diversity in the configurations that we run in continuous integration. || Working with Engineering to determine if there is a project here that should be prioritized.<br />
|-<br />
|}<br />
<br />
=== Conclusion and Next Steps === <br />
In addition to distributing this document internally, we will be working on a public blog post talking about improvements we want to put in place so this doesn’t happen again. The Firefox leadership team will be tackling the opportunities for improvement and looking to spin up a number of projects in the coming weeks and months.</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Add-ons/Expired-Certificate-Technical-Report&diff=1214846Add-ons/Expired-Certificate-Technical-Report2019-07-10T02:26:14Z<p>Stpeter: Change terminology to remove incident nickname</p>
<hr />
<div>== Firefox Add-On Outage Technical Report: Analysis and Recommendations ==<br />
<br />
Authors: [https://mozillians.org/en-US/u/stpeter/ Peter Saint-Andre], [https://mozillians.org/u/m_and_m/ Matthew A. Miller]<br />
<br />
Last updated: 2019-07-02<br />
<br />
=== Introduction ===<br />
On May 3, 2019, the intermediate certificate used to sign all deployed add-ons expired. Although this expiration was not unexpected (in fact, plans were in place to deploy a replacement certificate, which had already been generated), the consequences were unforeseen: almost all deployed add-ons stopped working for millions of Firefox users. This report summarizes our findings regarding the technical aspects of this incident and provides recommendations for avoiding or mitigating such incidents in the future.<br />
<br />
=== Root Causes ===<br />
On the face of it, the root cause might seem simple: a signing certificate expired and we didn’t renew it in time. If we just fix our monitoring tools and pay attention in the future, this won’t happen again. Right?<br />
<br />
Unfortunately, it’s not that simple.<br />
<br />
Yes, a signing certificate expired. But this would not necessarily cause Firefox to treat existing add-ons as invalid. Would it be good enough for the signature to be valid at the time the add-on was signed? Should we really need to re-sign all existing add-ons whenever we generate a new signing certificate (even if this were feasible), or would we use a new cert only for newly-issued add-ons? How would we handle add-ons for long-lived releases like ESR? And so on.<br />
<br />
A combination of factors was involved here: (1) the expiration of a signing cert and (2) runtime code for checking the date of that signing cert during add-on validation. Thus the primary root cause was more about differing assumptions than a failure to monitor or update. Specifically:<br />
<br />
* The server-side teams whose systems (e.g., Autograph) generate signatures knew the certificate was expiring, but did not see a problem because they had reason to believe that signing certificate dates were not checked by the client.<br />
* The client-side teams whose code performs add-on validation knew the dates were checked for end-entity certificates (we learned and mitigated this from [https://bugzilla.mozilla.org/show_bug.cgi?id=1267318 a previous outage]), but might not have realized that intermediate certificates were checked when invoking the [https://searchfox.org/mozilla-central/rev/7556a400affa9eb99e522d2d17c40689fa23a729/security/manager/ssl/nsIX509CertDB.idl#230-266 nsIX509CertDB] function in the core SSL library.<br />
* The crypto teams who maintain that SSL library simply provide an API and aren’t responsible for how client-side code uses that API.<br />
* The testing teams who ensure the quality of Firefox weren’t aware of the need for test coverage of expiring intermediate certificates.<br />
<br />
These various teams did not cross-check their underlying assumptions and understandings, or engage in “what-if” scenario planning and future testing. Thus the broader Firefox team did not have a firm grasp on the functioning of a complex system with the potential to impact the entire Firefox user base.<br />
<br />
Our conclusion is that this incident was not the fault of any individual or team, but was the result of having an interlocking set of complex systems that were not well understood across all the relevant teams.<br />
<br />
=== Secondary Complications ===<br />
The various teams mentioned above, and many others, responded quickly, professionally, and thoroughly once the scope and impact of the incident were realized. The effort involved was truly impressive.<br />
<br />
However, several aspects of the response were hindered by secondary complications, and it is helpful to understand these in addition to the root causes.<br />
<br />
First, we have a very large number of deployment targets, not all of which can be handled in the same way, and we had several techniques (hotfixes, dot releases, etc.) available for pushing changes out to different platforms and versions. Lack of understanding and documentation about these targets and techniques caused some delays in deployment of fixes.<br />
<br />
Second, because the initial hotfix involved Normandy (which required users to voluntarily enable Telemetry if they had it turned off), we gathered more data than we ordinarily do, and lost legitimate data in the process purging this over-gathered data. Additionally, other Normandy studies were temporarily disrupted which could have impacted their outcomes.<br />
<br />
Third, lack of documentation and experience with emergency processes led to some confusion and delay in responding (e.g., responsibilities are not always well understood before incidents occur and emergency contact procedures and methods were not well established).<br />
<br />
Fourth, the lack of in-house or on-call QA resources caused delays in testing proposed fixes across various platforms because our external teams at Softvision were not immediately available through normal channels (in fact, engaging with individual Softvision team members could have introduced legal complications and the potential for data leakage).<br />
<br />
=== Recommendations ===<br />
Spurred by this incident, teams from many areas of Mozilla have already been thinking about opportunities for improvement in our systems, processes, documentation, and operations. At a high level, we suggest a focus on the following areas. This fuller remediation does have a deadline; the newly created intermediate certificate that resolved this incident is set to expire in 2025.<br />
<br />
Most fundamentally, the full Firefox team does not have a common understanding of the role, function, and operation of cryptographic signatures for Firefox add-ons. For instance, although there are several good reasons for signing add-ons (monitoring add-ons not hosted on AMO, blocklisting malicious add-ons, providing cryptographic assurance by chaining add-ons to the Mozilla root), there is no shared consensus on the fundamental rationale for doing so. In addition, maintaining a full public key infrastructure (PKI) is a complex task and we do not necessarily have a firm grasp of the engineering and business tradeoffs involved. More complete documentation of the overall system (and the role of each sub-system therein) is critically important, as is communication about that architecture to all relevant teams and training of new team members. This documentation should include accurate, up-to-date information about all relevant inputs, outputs, dependencies, APIs, protocols, formats (e.g., subject and issuer identities), tooling, monitoring, operations, and responsible teams and/or individuals.<br />
<br />
Second, if we are committed to the current PKI and add-on signing approach, we should make improvements to our certificate management processes, especially our key rollover strategies. This will involve clear procedures for handling revoked and expiring intermediate and root certificates, including the impact on existing add-ons, updated add-ons, and new add-ons for the full range of both add-ons (web extensions, themes, language packs, etc.) and current/legacy release channels. Expectations need to be set and communicated for all aspects of key rollover, including but not limited to management of the offline hardware security module (HSM), interactions with the cloud HSM, monitoring of expiration times for the full set of deployed certificates, client-side validation of the full certificate chain (end-entity, intermediate, and root), acceptable expiry ranges, and extensive testing and future-proofing (such as setting system clocks to future times on selected test rigs).<br />
<br />
Third, we need to rationalize and improve our code delivery mechanisms. This involves several things. For instance, we need a much better and communicated “map” of the full range of our deployment targets: not just current desktop targets (Nightly, Beta, Dev Edition, Release, ESR) but also mobile and mixed reality as well as legacy versions which we judge important enough to update even if they are not officially supported. We need a clear understanding of hotfix techniques (e.g., Balrog vs. Normandy or a more special-purpose tool) and dot-release requirements across those deployment targets. We need to decouple our update mechanisms from data gathering mechanisms. And we need to set clear expectations internally, with end users, and with partners.</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Add-ons/Expired-Certificate-Technical-Report&diff=1214527Add-ons/Expired-Certificate-Technical-Report2019-07-02T21:12:36Z<p>Stpeter: fix mozillians.org URL</p>
<hr />
<div>== Armagaddon Technical Report: Analysis and Recommendations ==<br />
<br />
Authors: [https://mozillians.org/en-US/u/stpeter/ Peter Saint-Andre], [https://mozillians.org/u/m_and_m/ Matthew A. Miller]<br />
<br />
Last updated: 2019-07-02<br />
<br />
=== Introduction ===<br />
On May 3, 2019, the intermediate certificate used to sign all deployed add-ons expired. Although this expiration was not unexpected (in fact, plans were in place to deploy a replacement certificate, which had already been generated), the consequences were unforeseen: almost all deployed add-ons stopped working for millions of Firefox users. This report summarizes our findings regarding the technical aspects of this incident and provides recommendations for avoiding or mitigating such incidents in the future.<br />
<br />
=== Root Causes ===<br />
On the face of it, the root cause might seem simple: a signing certificate expired and we didn’t renew it in time. If we just fix our monitoring tools and pay attention in the future, this won’t happen again. Right?<br />
<br />
Unfortunately, it’s not that simple.<br />
<br />
Yes, a signing certificate expired. But this would not necessarily cause Firefox to treat existing add-ons as invalid. Would it be good enough for the signature to be valid at the time the add-on was signed? Should we really need to re-sign all existing add-ons whenever we generate a new signing certificate (even if this were feasible), or would we use a new cert only for newly-issued add-ons? How would we handle add-ons for long-lived releases like ESR? And so on.<br />
<br />
A combination of factors was involved here: (1) the expiration of a signing cert and (2) runtime code for checking the date of that signing cert during add-on validation. Thus the primary root cause was more about differing assumptions than a failure to monitor or update. Specifically:<br />
<br />
* The server-side teams whose systems (e.g., Autograph) generate signatures knew the certificate was expiring, but did not see a problem because they had reason to believe that signing certificate dates were not checked by the client.<br />
* The client-side teams whose code performs add-on validation knew the dates were checked for end-entity certificates (we learned and mitigated this from [https://bugzilla.mozilla.org/show_bug.cgi?id=1267318 Armagaddon 1.0]), but might not have realized that intermediate certificates were checked when invoking the [https://searchfox.org/mozilla-central/rev/7556a400affa9eb99e522d2d17c40689fa23a729/security/manager/ssl/nsIX509CertDB.idl#230-266 nsIX509CertDB] function in the core SSL library.<br />
* The crypto teams who maintain that SSL library simply provide an API and aren’t responsible for how client-side code uses that API.<br />
* The testing teams who ensure the quality of Firefox weren’t aware of the need for test coverage of expiring intermediate certificates.<br />
<br />
These various teams did not cross-check their underlying assumptions and understandings, or engage in “what-if” scenario planning and future testing. Thus the broader Firefox team did not have a firm grasp on the functioning of a complex system with the potential to impact the entire Firefox user base.<br />
<br />
Our conclusion is that this incident was not the fault of any individual or team, but was the result of having an interlocking set of complex systems that were not well understood across all the relevant teams.<br />
<br />
=== Secondary Complications ===<br />
The various teams mentioned above, and many others, responded quickly, professionally, and thoroughly once the scope and impact of the incident were realized. The effort involved was truly impressive.<br />
<br />
However, several aspects of the response were hindered by secondary complications, and it is helpful to understand these in addition to the root causes.<br />
<br />
First, we have a very large number of deployment targets, not all of which can be handled in the same way, and we had several techniques (hotfixes, dot releases, etc.) available for pushing changes out to different platforms and versions. Lack of understanding and documentation about these targets and techniques caused some delays in deployment of fixes.<br />
<br />
Second, because the initial hotfix involved Normandy (which required users to voluntarily enable Telemetry if they had it turned off), we gathered more data than we ordinarily do, and lost legitimate data in the process purging this over-gathered data. Additionally, other Normandy studies were temporarily disrupted which could have impacted their outcomes.<br />
<br />
Third, lack of documentation and experience with emergency processes led to some confusion and delay in responding (e.g., responsibilities are not always well understood before incidents occur and emergency contact procedures and methods were not well established).<br />
<br />
Fourth, the lack of in-house or on-call QA resources caused delays in testing proposed fixes across various platforms because our external teams at Softvision were not immediately available through normal channels (in fact, engaging with individual Softvision team members could have introduced legal complications and the potential for data leakage).<br />
<br />
=== Recommendations ===<br />
Spurred by this incident, teams from many areas of Mozilla have already been thinking about opportunities for improvement in our systems, processes, documentation, and operations. At a high level, we suggest a focus on the following areas. This fuller remediation does have a deadline; the newly created intermediate certificate that resolved this incident is set to expire in 2025.<br />
<br />
Most fundamentally, the full Firefox team does not have a common understanding of the role, function, and operation of cryptographic signatures for Firefox add-ons. For instance, although there are several good reasons for signing add-ons (monitoring add-ons not hosted on AMO, blocklisting malicious add-ons, providing cryptographic assurance by chaining add-ons to the Mozilla root), there is no shared consensus on the fundamental rationale for doing so. In addition, maintaining a full public key infrastructure (PKI) is a complex task and we do not necessarily have a firm grasp of the engineering and business tradeoffs involved. More complete documentation of the overall system (and the role of each sub-system therein) is critically important, as is communication about that architecture to all relevant teams and training of new team members. This documentation should include accurate, up-to-date information about all relevant inputs, outputs, dependencies, APIs, protocols, formats (e.g., subject and issuer identities), tooling, monitoring, operations, and responsible teams and/or individuals.<br />
<br />
Second, if we are committed to the current PKI and add-on signing approach, we should make improvements to our certificate management processes, especially our key rollover strategies. This will involve clear procedures for handling revoked and expiring intermediate and root certificates, including the impact on existing add-ons, updated add-ons, and new add-ons for the full range of both add-ons (web extensions, themes, language packs, etc.) and current/legacy release channels. Expectations need to be set and communicated for all aspects of key rollover, including but not limited to management of the offline hardware security module (HSM), interactions with the cloud HSM, monitoring of expiration times for the full set of deployed certificates, client-side validation of the full certificate chain (end-entity, intermediate, and root), acceptable expiry ranges, and extensive testing and future-proofing (such as setting system clocks to future times on selected test rigs).<br />
<br />
Third, we need to rationalize and improve our code delivery mechanisms. This involves several things. For instance, we need a much better and communicated “map” of the full range of our deployment targets: not just current desktop targets (Nightly, Beta, Dev Edition, Release, ESR) but also mobile and mixed reality as well as legacy versions which we judge important enough to update even if they are not officially supported. We need a clear understanding of hotfix techniques (e.g., Balrog vs. Normandy or a more special-purpose tool) and dot-release requirements across those deployment targets. We need to decouple our update mechanisms from data gathering mechanisms. And we need to set clear expectations internally, with end users, and with partners.</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Add-ons/Expired-Certificate-Technical-Report&diff=1214526Add-ons/Expired-Certificate-Technical-Report2019-07-02T21:08:46Z<p>Stpeter: add mozillians link</p>
<hr />
<div>== Armagaddon Technical Report: Analysis and Recommendations ==<br />
<br />
Authors: [https://mozillians.org/en-US/ Peter Saint-Andre], [https://mozillians.org/u/m_and_m/ Matthew A. Miller]<br />
<br />
Last updated: 2019-07-02<br />
<br />
=== Introduction ===<br />
On May 3, 2019, the intermediate certificate used to sign all deployed add-ons expired. Although this expiration was not unexpected (in fact, plans were in place to deploy a replacement certificate, which had already been generated), the consequences were unforeseen: almost all deployed add-ons stopped working for millions of Firefox users. This report summarizes our findings regarding the technical aspects of this incident and provides recommendations for avoiding or mitigating such incidents in the future.<br />
<br />
=== Root Causes ===<br />
On the face of it, the root cause might seem simple: a signing certificate expired and we didn’t renew it in time. If we just fix our monitoring tools and pay attention in the future, this won’t happen again. Right?<br />
<br />
Unfortunately, it’s not that simple.<br />
<br />
Yes, a signing certificate expired. But this would not necessarily cause Firefox to treat existing add-ons as invalid. Would it be good enough for the signature to be valid at the time the add-on was signed? Should we really need to re-sign all existing add-ons whenever we generate a new signing certificate (even if this were feasible), or would we use a new cert only for newly-issued add-ons? How would we handle add-ons for long-lived releases like ESR? And so on.<br />
<br />
A combination of factors was involved here: (1) the expiration of a signing cert and (2) runtime code for checking the date of that signing cert during add-on validation. Thus the primary root cause was more about differing assumptions than a failure to monitor or update. Specifically:<br />
<br />
* The server-side teams whose systems (e.g., Autograph) generate signatures knew the certificate was expiring, but did not see a problem because they had reason to believe that signing certificate dates were not checked by the client.<br />
* The client-side teams whose code performs add-on validation knew the dates were checked for end-entity certificates (we learned and mitigated this from [https://bugzilla.mozilla.org/show_bug.cgi?id=1267318 Armagaddon 1.0]), but might not have realized that intermediate certificates were checked when invoking the [https://searchfox.org/mozilla-central/rev/7556a400affa9eb99e522d2d17c40689fa23a729/security/manager/ssl/nsIX509CertDB.idl#230-266 nsIX509CertDB] function in the core SSL library.<br />
* The crypto teams who maintain that SSL library simply provide an API and aren’t responsible for how client-side code uses that API.<br />
* The testing teams who ensure the quality of Firefox weren’t aware of the need for test coverage of expiring intermediate certificates.<br />
<br />
These various teams did not cross-check their underlying assumptions and understandings, or engage in “what-if” scenario planning and future testing. Thus the broader Firefox team did not have a firm grasp on the functioning of a complex system with the potential to impact the entire Firefox user base.<br />
<br />
Our conclusion is that this incident was not the fault of any individual or team, but was the result of having an interlocking set of complex systems that were not well understood across all the relevant teams.<br />
<br />
=== Secondary Complications ===<br />
The various teams mentioned above, and many others, responded quickly, professionally, and thoroughly once the scope and impact of the incident were realized. The effort involved was truly impressive.<br />
<br />
However, several aspects of the response were hindered by secondary complications, and it is helpful to understand these in addition to the root causes.<br />
<br />
First, we have a very large number of deployment targets, not all of which can be handled in the same way, and we had several techniques (hotfixes, dot releases, etc.) available for pushing changes out to different platforms and versions. Lack of understanding and documentation about these targets and techniques caused some delays in deployment of fixes.<br />
<br />
Second, because the initial hotfix involved Normandy (which required users to voluntarily enable Telemetry if they had it turned off), we gathered more data than we ordinarily do, and lost legitimate data in the process purging this over-gathered data. Additionally, other Normandy studies were temporarily disrupted which could have impacted their outcomes.<br />
<br />
Third, lack of documentation and experience with emergency processes led to some confusion and delay in responding (e.g., responsibilities are not always well understood before incidents occur and emergency contact procedures and methods were not well established).<br />
<br />
Fourth, the lack of in-house or on-call QA resources caused delays in testing proposed fixes across various platforms because our external teams at Softvision were not immediately available through normal channels (in fact, engaging with individual Softvision team members could have introduced legal complications and the potential for data leakage).<br />
<br />
=== Recommendations ===<br />
Spurred by this incident, teams from many areas of Mozilla have already been thinking about opportunities for improvement in our systems, processes, documentation, and operations. At a high level, we suggest a focus on the following areas. This fuller remediation does have a deadline; the newly created intermediate certificate that resolved this incident is set to expire in 2025.<br />
<br />
Most fundamentally, the full Firefox team does not have a common understanding of the role, function, and operation of cryptographic signatures for Firefox add-ons. For instance, although there are several good reasons for signing add-ons (monitoring add-ons not hosted on AMO, blocklisting malicious add-ons, providing cryptographic assurance by chaining add-ons to the Mozilla root), there is no shared consensus on the fundamental rationale for doing so. In addition, maintaining a full public key infrastructure (PKI) is a complex task and we do not necessarily have a firm grasp of the engineering and business tradeoffs involved. More complete documentation of the overall system (and the role of each sub-system therein) is critically important, as is communication about that architecture to all relevant teams and training of new team members. This documentation should include accurate, up-to-date information about all relevant inputs, outputs, dependencies, APIs, protocols, formats (e.g., subject and issuer identities), tooling, monitoring, operations, and responsible teams and/or individuals.<br />
<br />
Second, if we are committed to the current PKI and add-on signing approach, we should make improvements to our certificate management processes, especially our key rollover strategies. This will involve clear procedures for handling revoked and expiring intermediate and root certificates, including the impact on existing add-ons, updated add-ons, and new add-ons for the full range of both add-ons (web extensions, themes, language packs, etc.) and current/legacy release channels. Expectations need to be set and communicated for all aspects of key rollover, including but not limited to management of the offline hardware security module (HSM), interactions with the cloud HSM, monitoring of expiration times for the full set of deployed certificates, client-side validation of the full certificate chain (end-entity, intermediate, and root), acceptable expiry ranges, and extensive testing and future-proofing (such as setting system clocks to future times on selected test rigs).<br />
<br />
Third, we need to rationalize and improve our code delivery mechanisms. This involves several things. For instance, we need a much better and communicated “map” of the full range of our deployment targets: not just current desktop targets (Nightly, Beta, Dev Edition, Release, ESR) but also mobile and mixed reality as well as legacy versions which we judge important enough to update even if they are not officially supported. We need a clear understanding of hotfix techniques (e.g., Balrog vs. Normandy or a more special-purpose tool) and dot-release requirements across those deployment targets. We need to decouple our update mechanisms from data gathering mechanisms. And we need to set clear expectations internally, with end users, and with partners.</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Modules/Firefox_Technical_Leadership&diff=1202981Modules/Firefox Technical Leadership2018-10-26T22:47:54Z<p>Stpeter: Add contact address</p>
<hr />
<div>===Scope and Operation===<br />
<br />
The Firefox Technical Leadership module (FTLM) is responsible for engineering coordination and escalation among the modules that make up Firefox, including ownership of the [[Modules/All#mozilla-toplevel|top-level module]]. The FTLM generally tries to avoid day-to-day involvement in operation of lower-level modules, but gets involved with decisions that are explicitly cross-module and with issues that cannot be resolved at lower levels, such as:<br />
<br />
* Resolution of decisions that do not fall clearly into any specific module or set of modules<br />
* Escalation of disputes beyond the module owner level<br />
<br />
In addition, the [[Modules/Activities#Module_Ownership_System|Module Ownership module]] delegates its responsibilities for the modules that make up Firefox to the FTLM. This delegated authority includes topics such as those listed below, which would otherwise escalate to the [[Modules/Activities#Module_Ownership_System|Module Ownership module]]:<br />
<br />
* Filling vacant roles where appropriate<br />
* Ensuring module owners are fulfilling their responsibilities, and replacing those who are not<br />
* Creating and staffing new modules where new parts of the project evolve<br />
* Figuring out what to do if a module isn't getting enough attention<br />
* Resolving conflicts among module owners<br />
<br />
The FTLM decision making process attempts to form consensus among stakeholders, with the committee empowered to resolve disputes when that consensus cannot be reached, and the chair empowered when consensus cannot be reached within the committee.<br />
<br />
===Structure===<br />
<br />
The FTLM is governed by the Technical Leadership Module Committee (TLMC). The TLMC consists of the CTO and VP of Engineering from the Mozilla Firefox organization, plus additional members that reflect the technical leadership of the project. The additional members are selected as needed to reach a six member minimum and ensure broad coverage of domain knowledge. In most cases, we would expect those leaders to be more or less full-time on the project. These additional members will serve two-year terms. As of 2018, the current members are:<br />
<br />
* Eric Rescorla (Firefox CTO) - Chair<br />
* Dave Camp (Vice President, Firefox Engineering)<br />
* Boris Zbarsky<br />
* David Baron<br />
* Dave Townsend<br />
* Luke Wagner<br />
<br />
The owner of the [[Modules/Activities#Module_Ownership_System|Module Ownership module]] (currently Mitchell Baker) is expected to revisit these membership criteria upon any substantial changes to the management structures or the relationships to corporate entities with the project.<br />
<br />
===List of Applicable Modules===<br />
<br />
For purposes of defining the scope of the TLMC's responsibility, the modules that make up Firefox are as follows:<br />
<br />
* [[Modules/Firefox|Firefox]]<br />
* [[Modules/Toolkit|Toolkit]]<br />
* [[Modules/Core|Core]]<br />
* [[Modules/All#Submodules|Submodules]]<br />
* [[Modules/All#Browser|Browser]]<br />
* [[Modules/All#Tier_1_Platforms|Tier 1 Platforms]]<br />
* Other:<br />
** [[Modules/All#Add-on_SDK|Add-On SDK]]<br />
** [[Modules/All#Android_Background_Services|Android Background Services]]<br />
** [[Modules/All#Firefox_for_Metro|Firefox for Metro]]<br />
** [[Modules/All#BrowserID|BrowserID]]<br />
** [[Modules/All#Firefox_Accounts|Firefox Accounts]]<br />
** [[Modules/All#DevTools|Devtools]]<br />
** [[Modules/All#Firefox_for_iOS_.28Fennec.29|Fennec]]<br />
** [[Modules/All#Sync|Sync]]<br />
** [[Modules/All#Mozilla_Location_Service_.28MLS.29|Mozilla Location Service]]<br />
** [[Modules/All#Mozilla_Stumbler_.28.22MozStumbler.22.29|Mozstumbler]]<br />
** [[Modules/All#URL_Classifier|URL Classifier]]<br />
** [[Modules/All#Tree_Sheriffs|Tree Sheriffs]]<br />
* Governance<br />
** [[Modules/All#Security_Policy|Security Policy]]<br />
** [[Modules/All#Mozilla_CA_Certificate_Policy|CA Certificate Policy]]<br />
** [[Modules/All#Code_Review_Policy|Code Review Policy]]<br />
** [[Modules/All#Performance_Regression_Policy|Performance Regression Policy]]<br />
** [[Modules/All#CA_Certificates|CA Certificates]]<br />
** [[Modules/All#Commit_Access_Policy|Commit Access Policy]]<br />
<br />
===Contact===<br />
<br />
The Technical Leadership Module Committee can be contacted at at tlmc [at] mozilla [dot] com.</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Modules&diff=1202980Modules2018-10-26T22:46:38Z<p>Stpeter: Change TLMC email address from .org to .com while IT fix is being processed</p>
<hr />
<div>Mozilla operates under a [http://www.mozilla.org/hacking/module-ownership.html module ownership governance system]. A '''module''' is a discrete unit of code or activity. An '''owner''' is the person in charge of a module or sub-module. A '''peer''' is a person whom the owner has appointed to help them. A module may have multiple peers and, very occasionally, multiple owners.<br />
<br />
The system is overseen by the owner and peers of the [[Modules/Activities#Module_Ownership_System|Module Ownership module]]. For the modules that make up Firefox, oversight is provided by the [[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership module]]. Owners may add and remove peers from their modules as they wish, without reference to anyone else. <br />
<br />
===Creating A New Module===<br />
<br />
Ideally, a Module should exist for all significant chunks of work or code in the Mozilla project. Who you talk to about this depends on the area of the project concerned.<br />
<br />
For many areas, the ability to create, alter ownership of and destroy sub-modules has been delegated to the owner of the module whose broad scope covers that area. This is true for Firefox, Thunderbird, and all of the other areas listed below except for [[Modules/Core|Core]], [[Modules/Activities|Activities]] and [[Modules/Other|Other]]. The controlling module is the first one listed on the page. Please contact that person about getting new modules created.<br />
<br />
For the modules that make up Firefox, ultimate oversight is provided by the [[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership module]]. Therefore, please post your inquiry in the mozilla.governance newsgroup, cc'ing the owner and peers of the [[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership module]] at tlmc [at] mozilla [dot] com. If there is something sensitive about your inquiry that you aren't comfortable writing in the newsgroup, or in case of uncertainty, please send it to tlmc [at] mozilla [dot] com.<br />
<br />
For all other modules (e.g., [[Modules/Activities|Activities]] and the non-Firefox modules in the [[Modules/Other|Other]] category), please post your inquiry in the mozilla.governance newsgroup, cc'ing the owner and peers of the [[Modules/Activities#Module_Ownership_System|Module Ownership module]] at module-ownership [at] mozilla [dot] org. If there is something sensitive about your inquiry that you aren't comfortable writing in the newsgroup, or in case of uncertainty, please send it to module-ownership [at] mozilla [dot] org.<br />
<br />
===Module Lists===<br />
<br />
These pages list the owners and their peers for all Mozilla modules, broken down by different areas of the project-.<br />
<br />
* [[Modules/All|All in one big list]]<br />
* [[Modules/Firefox|Firefox]]<br />
* [[Modules/Thunderbird|Thunderbird]]<br />
* [[Modules/SeaMonkey|SeaMonkey]]<br />
* [[Modules/Calendar|Calendar]]<br />
* [[Modules/Toolkit|Toolkit]]<br />
* [[Modules/Core|Core]]<br />
* [[Modules/MailNews_Core|MailNews Core]]<br />
* [[Modules/Chat|Chat]]<br />
* [[Modules/Bugzilla|Bugzilla]] - the Bugzilla software itself<br />
* [[Modules/bugzilla.mozilla.org|bugzilla.mozilla.org]] - the particular Bugzilla installation run by the Mozilla project<br />
* [[Modules/Other|Other]] (code modules which aren't in any of the above categories)<br />
* [[Modules/Activities|Activities]] (non-code)<br />
* [[Modules/Mozilla Reps|Mozilla Reps]]<br />
* [[Modules/Mozilla Websites|Mozilla Websites]]</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Modules&diff=1202977Modules2018-10-26T22:19:42Z<p>Stpeter: Per discussion on mozilla.governance, point to the Firefox Technical Leadership module for the modules that make up Firefox.</p>
<hr />
<div>Mozilla operates under a [http://www.mozilla.org/hacking/module-ownership.html module ownership governance system]. A '''module''' is a discrete unit of code or activity. An '''owner''' is the person in charge of a module or sub-module. A '''peer''' is a person whom the owner has appointed to help them. A module may have multiple peers and, very occasionally, multiple owners.<br />
<br />
The system is overseen by the owner and peers of the [[Modules/Activities#Module_Ownership_System|Module Ownership module]]. For the modules that make up Firefox, oversight is provided by the [[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership module]]. Owners may add and remove peers from their modules as they wish, without reference to anyone else. <br />
<br />
===Creating A New Module===<br />
<br />
Ideally, a Module should exist for all significant chunks of work or code in the Mozilla project. Who you talk to about this depends on the area of the project concerned.<br />
<br />
For many areas, the ability to create, alter ownership of and destroy sub-modules has been delegated to the owner of the module whose broad scope covers that area. This is true for Firefox, Thunderbird, and all of the other areas listed below except for [[Modules/Core|Core]], [[Modules/Activities|Activities]] and [[Modules/Other|Other]]. The controlling module is the first one listed on the page. Please contact that person about getting new modules created.<br />
<br />
For the modules that make up Firefox, ultimate oversight is provided by the [[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership module]]. Therefore, please post your inquiry in the mozilla.governance newsgroup, cc'ing the owner and peers of the [[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership module]] at tlmc [at] mozilla [dot] org. If there is something sensitive about your inquiry that you aren't comfortable writing in the newsgroup, or in case of uncertainty, please send it to tlmc [at] mozilla [dot] org.<br />
<br />
For all other modules (e.g., [[Modules/Activities|Activities]] and the non-Firefox modules in the [[Modules/Other|Other]] category), please post your inquiry in the mozilla.governance newsgroup, cc'ing the owner and peers of the [[Modules/Activities#Module_Ownership_System|Module Ownership module]] at module-ownership [at] mozilla [dot] org. If there is something sensitive about your inquiry that you aren't comfortable writing in the newsgroup, or in case of uncertainty, please send it to module-ownership [at] mozilla [dot] org.<br />
<br />
===Module Lists===<br />
<br />
These pages list the owners and their peers for all Mozilla modules, broken down by different areas of the project-.<br />
<br />
* [[Modules/All|All in one big list]]<br />
* [[Modules/Firefox|Firefox]]<br />
* [[Modules/Thunderbird|Thunderbird]]<br />
* [[Modules/SeaMonkey|SeaMonkey]]<br />
* [[Modules/Calendar|Calendar]]<br />
* [[Modules/Toolkit|Toolkit]]<br />
* [[Modules/Core|Core]]<br />
* [[Modules/MailNews_Core|MailNews Core]]<br />
* [[Modules/Chat|Chat]]<br />
* [[Modules/Bugzilla|Bugzilla]] - the Bugzilla software itself<br />
* [[Modules/bugzilla.mozilla.org|bugzilla.mozilla.org]] - the particular Bugzilla installation run by the Mozilla project<br />
* [[Modules/Other|Other]] (code modules which aren't in any of the above categories)<br />
* [[Modules/Activities|Activities]] (non-code)<br />
* [[Modules/Mozilla Reps|Mozilla Reps]]<br />
* [[Modules/Mozilla Websites|Mozilla Websites]]</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1202975Modules/Core2018-10-26T22:00:23Z<p>Stpeter: Per discussion on mozilla.governance, change ownership of toplevel to the Firefox Technical Leadership module</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peers=[mailto:dbolter@mozilla.com David Bolter], [mailto:eitan@monotonous.org Eitan Isaacson], [mailto:jteh@mozilla.com James Teh], [mailto:mzehe@mozilla.com Marco Zehe], [mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal]<br />
|peersemeritus=[mailto:tbsaunde+mozbugs@tbsaunde.org Trevor Saunders], [mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Animation<br />
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.<br />
|owner=[mailto:bbirtles@mozilla.com Brian Birtles] (:birtles)<br />
|peers=[mailto:hiro@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)<br />
|group=dev-tech-layout<br />
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko<br />
|components=Core::DOM::Animation, Core::CSS Parsing and Computation (for CSS animations/transitions related bugs)<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:fabrice@mozilla.com Fabrice Desré]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)<br />
|peers=[mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:cmanchester@mozilla.com Chris Manchester](:chmanchester), [mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj), [mailto:dmajor@mozilla.com David Major] (:dmajor), [mailto:rgiles@mozilla.com Ralph Giles] (:rillian)<br />
|ownersemeritus=Ted Mielczarek (2008-[https://blog.mozilla.org/ted/2013/03/07/gregory-szorc-is-now-the-build-config-module-owner/ 2013]), Benjamin Smedberg (???-[http://benjamin.smedbergs.us/blog/2008-04-30/more-changing-of-the-guard-ted-mielczarek/ 2008]), <br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/footprint/, tools/jprof/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content HTTP Headers<br />
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)<br />
|owner=[mailto:gerv@mozilla.org Gervase Markham]<br />
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]<br />
|group=dev-platform<br />
|source_dirs= <br />
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features enforced in the ContentSecurityManager, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Subresource Integrity (SRI), Cross-Origin Resource Sharing (CORS) and top-level data: URI blocking.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peers=[mailto:francois@mozilla.com François Marier], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:jkt@mozilla.com Jonathan Kingston]<br />
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies and Permissions<br />
|description=<br />
|owner=Monica Chew<br />
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-tech-network<br />
|source_dirs=extensions/cookie/, netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=C++/Rust usage, tools, and style<br />
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise<br />
|owner=[mailto:nfroyd@mozilla.com Nathan Froyd] (while Ehsan is away)<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|source_dirs=non-third-party C++ and Rust code in the tree<br />
|components=Various components<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:sawang@mozilla.com Samael Wang]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback],[mailto:cbiesinger@gmail.com Christian Biesinger],[mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],<br />
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:kyle@nonpolynomial.com Kyle Machulis], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:nika@thelayzells.com Nika Layzell]<br />
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri (still active, but slower to respond than previously)], [mailto:me@kylehuey.com Kyle Huey], [mailto:wmccloskey@mozilla.com Bill McCloskey], [ben@wanderview.com Ben Kelly]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=DOM File<br />
|description=DOM Blob, File and FileSystem APIs <br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:olli@pettay.fi Olli Pettay]<br />
|group=dev-platform<br />
|source_dirs=dom/file, dom/filesystem<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: File<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:sshih@mozilla.com Stone Shih]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::Event Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:baku@mozilla.com Andrea Marchesini]<br />
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:asuth@mozilla.com Andrew Sutherland]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:btseng@mozilla.com Bevis Tseng], [mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:baku@mozilla.com Andrea Marchesini]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Embedding<br />
|description=Gecko embedding APIs and frameworks<br />
|owner=[mailto:myk@mykzilla.org Myk Melez]<br />
|ownersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:bdahl@mozilla.com Brendan Dahl], [mailto:tbsaunde@tbsaunde.org Trevor Saunders]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-platform<br />
|source_dirs=embedding/<br />
|url=<br />
|components=Core::Embedding: APIs<br />
}}<br />
<br />
{{Module<br />
|name=Find As You Type<br />
|description=Find As You Type (formerly called Type Ahead Find) is a feature that allows quick web page navigation when you type a succession of characters in the body of the displayed page (not in an edit box of or drop down list). Currently seeks new owner.<br />
|owner=<br />
|peers=<br />
|group=dev-accessibility<br />
|source_dirs=extensions/typeaheadfind/<br />
|url=http://www.mozilla.org/access/type-ahead/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Gecko Profiler<br />
|description=Gecko's built-in profiler<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:nnethercote@mozilla.com Nicholas Nethercote], [mailto:jseward@mozilla.com Julian Seward] (LUL), [mailto:kvijayan@mozilla.com Kannan Vijayan] (JS integration), [mailto:shu@mozilla.com Shu-yu Guo] (JS integration), [mailto:tlee@mozilla.com Thinker Lee] (TaskTracer), [mailto:cyu@mozilla.com Cervantes Yu] (TaskTracer), [mailto:b56girard@gmail.com Benoit Girard].<br />
|group=dev-platform<br />
|source_dirs=tools/profiler/<br />
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler<br />
|components=Core::Gecko Profiler<br />
}}<br />
<br />
{{Module<br />
|name=Geolocation<br />
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.<br />
|owner=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner], Garvan Keeley<br />
|peers=<br />
|group=dev-tech-dom<br />
|source_dirs=dom/geolocation, dom/system/, netwerk/wifi<br />
|url=https://developer.mozilla.org/En/Using_geolocation<br />
|components=Core::Geolocation<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=Aaron Leventhal<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/xbl/builtin/<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:george@mozilla.com George Wright](Canvas2D), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:clord@mozilla.com Christopher Lord], [mailto:mstange@themasta.com Markus Stange](OS X), [mailto:lsalzman@mozilla.com Lee Salzman](Skia), [mailto:mchang@mozilla.com Mason Chang], [mailto:dvander@mozilla.com David Anderson], [mailto:rhunt@mozilla.com Ryan Hunt]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:dvander@mozilla.com David Anderson], [mailto:mstange@mozilla.com Markus Stange]<br />
|group=dev-platform<br />
|source=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@jwatt.org Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands]<br />
|peers=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=[mailto:wchen@mozilla.com William Chen]<br />
|group=dev-platform<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|peers=[mailto:aosmond@mozilla.com Andrew Osmond], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar]<br />
|peersemeritus=[mailto:seth.bugzilla@blackhail.net Seth Fowler], [mailto:netzen@gmail.com Brian Bondy], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Native message-passing between threads and processes<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:jld@mozilla.com Jed Davis], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:amccreight@mozilla.com Andrew McCreight]<br />
|peersemeritus=[mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:danderson@mozilla.com David Anderson], [mailto:kchen@mozilla.com Kan-Ru Chen], [mailto:btseng@mozilla.com Bevis Tseng]<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:jdemooij@mozilla.com Jan de Mooij], André Bargull, [mailto:tcampbell@mozilla.com Ted Campbell], [mailto:jcoppeard@mozilla.com Jon Coppeard], [mailto:sphink@gmail.com Steve Fink], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:khyperia@mozilla.com Ashley Hauck], [mailto:evilpies@gmail.com Tom Schuster], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:jwalden@mit.edu Jeff Walden], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit], [mailto:efaust@mozilla.com Eric Faust], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:luke@mozilla.com Luke Wagner], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], Andreas Gal<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=[mailto:bbouvier@mozilla.com Benjamin Bouvier], [mailto:tcampbell@mozilla.com Ted Campbell], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|peersemeritus=[mailto:danderson@mozilla.com David Anderson], [mailto:hv1989@gmail.com Hannes Verschore]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript Debugger Backend<br />
|description=JavaScript debugging hooks<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]<br />
|group=dev-apps-js-debugger<br />
|source_dirs=js/jsd/<br />
|url=http://www.mozilla.org/js/jsd<br />
|components=Other Applications::Venkman JS Debugger<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: HTML Frames, Core::Layout: Images, Core::Layout: Misc Code, Core::Layout: R & A Pos, Core::Layout: Tables, Core::Layout: Text, Core::Print Preview, Core::Printing: Output<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:mwu@mozilla.com Michael Wu]<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]<br />
|peers=[mailto:kinetik@flim.org Matthew Gregan], [mailto:bvandyk@mozilla.com Bryce Van Dyk], [mailto:jolin@mozilla.com John Lin], [mailto:alwu@mozilla.com Alastor Wu], [mailto:jwwang@mozilla.com JW Wang]<br />
|group=dev-media<br />
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd] (mozglue/linker), [mailto:kgupta@mozilla.com Kartikaya Gupta] (mozglue/android), [mailto:nchen@mozilla.com Jim Chen] (mozglue/android), [mailto:aklotz@mozilla.com Aaron Klotz] (Windows Dll Blocklist/Interceptor)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership module]]<br />
|ownersemeritus=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MSCOM<br />
|description=Integration with Microsoft Distributed COM<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|group=dev-platform<br />
|source_dirs=ipc/mscom/%<br />
|url=<br />
|components=Core::IPC: MSCOM}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:dd.mozilla@gmail.com Dragana Damjanovic]<br />
|peers= [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:hurley@mozilla.com Nick Hurley], [mailto:dd.mozilla@gmail.com Dragana Damjanovic ], [mailto:valentin.gosu@gmail.com Valentin Gosu], [mailto:daniel@haxx.se Daniel Stenberg ], [mailto:jduell.mcbugs@gmail.com Jason Duell] <br />
|ownersemeritus=[mailto:mcmanus@ducksong.com Patrick McManus], [mailto:cbiesinger@gmail.com Christian Biesinger] |peersemeritus= Shih-Chiang Chien, [mailto:bzbarsky@mit.edu Boris Zbarsky], Steve Workman <br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:kaie@kuix.de Kai Engert]<br />
|peers=[mailto:wtc@google.com Wan-Teh Chang], [mailto:mh@glandium.org Mike Hommey]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=Chris Jones, Andreas Gal<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas]<br />
|peersemeritus=[mailto:john@pointysoftware.net John Schoenick], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:jstenback@gmail.com Johnny Stenback], Benjamin Smedberg<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:felipe@mozilla.com Felipe Gomes], [mailto:glandium@mozilla.com Mike Hommey], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:josh@joshmatthews.net Josh Matthews] (while Ehsan is away)<br />
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owners=<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:lina@mozilla.com Lina Cambridge], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]<br />
|peersemeritus=[mailto:nsm.nikhil@gmail.com Nikhil Marathe]<br />
|group=<br />
|source_dirs=dom/push<br />
|url=<br />
|components=Core::DOM: Push Notifications<br />
}}<br />
<br />
{{Module<br />
|name=PyXPCOM<br />
|description=The Python to XPCOM bridge.<br />
|owner=Todd Whiteman<br />
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]<br />
|group=<br />
|source_dirs=extension/python<br />
|url=https://developer.mozilla.org/en/PyXPCOM<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=RDF<br />
|description=<br />
|owner=[mailto:axel@pike.org Axel Hecht]<br />
|peers=<br />
|group=dev-tech-rdf<br />
|source_dirs=rdf/<br />
|url=http://www.mozilla.org/rdf/doc/<br />
|components=Core::RDF<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:martin.thomson@gmail.com Martin Thomson]<br />
|ownersemeritus=[mailto:ttaubert@mozilla.com Tim Taubert]<br />
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:wtc@google.com Wan-Teh Chang], [mailto:dueno@redhat.com Daiki Ueno]<br />
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]<br />
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell] (while Ehsan is away)<br />
|peers=[mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:birunthan@mohanathas.com Birunthan Mohanathas], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:andi@mozilla.com Andi-Bogdan Postelnicu]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner= [mailto:cam@mcc.id.au Cameron McCormack]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=Tamarin<br />
|description=VM for ActionScript and JavaScript<br />
|owner=Edwin Smith, [mailto:jodyer@adobe.com Jeff Dyer]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tamarin<br />
|url=http://www.mozilla.org/projects/tamarin/<br />
http://wiki.mozilla.org/tamarin/<br />
http://hg.mozilla.org/tamarin-central/<br />
http://hg.mozilla.org/tamarin-tracing/<br />
|components=Tamarin<br />
}}<br />
<br />
{{Module<br />
|name=Test Harness<br />
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill, Marionette, Firefox UI Tests. Requests for new harnesses should go to Testing::General.<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), Rob Campbell (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (Marionette, Firefox UI tests), [mailto:ato@mozilla.com Andreas Tolfsen] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette), [mailto:dminor@mozilla.com Dan Minor], [mailto:mjzffr@gmail.com Maja Frydrychowicz] (Marionette, Firefox UI tests), <br />
<br />
|group=dev-quality<br />
|source_dirs=/testing<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js<br />
}}<br />
<br />
{{Module<br />
|name=Testing Infrastructure<br />
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker<br />
|owner=[mailto:jmaher@mozilla.com Joel Maher]<br />
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], Rob Campbell, [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]<br />
|group=dev-quality<br />
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::Infrastructure<br />
}}<br />
<br />
{{Module<br />
|name=JS Marionette<br />
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)<br />
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye><br />
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk><br />
|source_dirs=gaia/tests/jsmarionette<br />
|components=Testing::JSMarionette<br />
|group=dev-gaia<br />
}}<br />
<br />
{{Module<br />
|name=XPCShell Test Harness<br />
|description=The XPCShell Harness<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|peers=[mailto:jmaher@mozilla.com Joel Maher]<br />
|source_dirs=testing/xpcshell<br />
|components=Testing::XPCShell Harness<br />
}}<br />
<br />
{{Module<br />
|name=Update Service<br />
|description=server code for Mozilla Update services (aus, addons, pfs)<br />
|owner=Mike Morgan<br />
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]<br />
|group=dev-amo<br />
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/<br />
|url=http://wiki.mozilla.org/wiki/AMO<br />
|components=AUS::Administration, AUS::Systems<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=Web Painting<br />
|description=painting, display lists, and layer construction<br />
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]<br />
|group=dev-tech-layout<br />
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout: Web Painting<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC Networking<br />
}}<br />
<br />
{{Module<br />
|name=WebVR<br />
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration<br />
|owner=[mailto:kgilbert@mozilla.com Kip Gilbert]<br />
|peers=[mailto:dmu@mozilla.com Daosheng Mu]<br />
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=dom/vr, gfx/vr<br />
|url=https://mozvr.com/<br />
|components=Core::WebVR<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=<br />
|owner=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=The Android Port<br />
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|peers=[mailto:jwillcox@mozilla.com James Willcox]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=supported X widgetry and gfx<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= Gecko's OS X compatibility layer.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl], [mailto:smichaud@pobox.com Steven Michaud]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widgets and desktop integration<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|peersemeritus=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XBL<br />
|description=eXtensible Binding Language<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|ownersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=dom/xbl/<br />
|url=http://www.mozilla.org/projects/xbl/<br />
|components=Core::XBL<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|ownersemeritus=Benjamin Smedberg<br />
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPInstall<br />
|description=<br />
|owner=[mailto:dveditz@mozilla.com Dan Veditz]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpinstall<br />
|source_dirs=xpinstall/<br />
|url=<br />
|components=Core::Installer: XPInstall Engine<br />
}}<br />
<br />
{{Module<br />
|name=XPToolkit<br />
|description=Cross-platform user interface toolkit<br />
|owner=<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Jan.Varga@gmail.com Jan Varga]<br />
|group=dev-tech-xul<br />
|source_dirs=dom/xul/, layout/xul/<br />
|url=http://www.mozilla.org/xpfe/<br />
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)<br />
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux<br />
|description=Sandboxing for the Linux platform<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]<br />
|peers=Same as Build Config<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Build Config - Taskgraph<br />
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.<br />
|owner=[mailto:dustin@mozilla.com Dustin Mitchell]<br />
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood], [mailto:mozilla@hocat.ca Tom Prince]<br />
|components=Firefox Build System::Task Configuration<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson], <br />
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Find Backend<br />
Core::General<br />
Core::HTML: Form Submission<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::Localization<br />
Core::Networking: Domain Lists<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::X-remote<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Stpeterhttps://wiki.mozilla.org/index.php?title=Modules/Technical_Leadership_Module_Committee&diff=1202974Modules/Technical Leadership Module Committee2018-10-26T21:50:35Z<p>Stpeter: Redirect to corrected URL</p>
<hr />
<div>Moved to https://wiki.mozilla.org/Modules/Firefox_Technical_Leadership</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Modules/Firefox_Technical_Leadership&diff=1202973Modules/Firefox Technical Leadership2018-10-26T21:49:54Z<p>Stpeter: Correction of page name and move from https://wiki.mozilla.org/Modules/Technical_Leadership_Module_Committee</p>
<hr />
<div>===Scope and Operation===<br />
<br />
The Firefox Technical Leadership module (FTLM) is responsible for engineering coordination and escalation among the modules that make up Firefox, including ownership of the [[Modules/All#mozilla-toplevel|top-level module]]. The FTLM generally tries to avoid day-to-day involvement in operation of lower-level modules, but gets involved with decisions that are explicitly cross-module and with issues that cannot be resolved at lower levels, such as:<br />
<br />
* Resolution of decisions that do not fall clearly into any specific module or set of modules<br />
* Escalation of disputes beyond the module owner level<br />
<br />
In addition, the [[Modules/Activities#Module_Ownership_System|Module Ownership module]] delegates its responsibilities for the modules that make up Firefox to the FTLM. This delegated authority includes topics such as those listed below, which would otherwise escalate to the [[Modules/Activities#Module_Ownership_System|Module Ownership module]]:<br />
<br />
* Filling vacant roles where appropriate<br />
* Ensuring module owners are fulfilling their responsibilities, and replacing those who are not<br />
* Creating and staffing new modules where new parts of the project evolve<br />
* Figuring out what to do if a module isn't getting enough attention<br />
* Resolving conflicts among module owners<br />
<br />
The FTLM decision making process attempts to form consensus among stakeholders, with the committee empowered to resolve disputes when that consensus cannot be reached, and the chair empowered when consensus cannot be reached within the committee.<br />
<br />
===Structure===<br />
<br />
The FTLM is governed by the Technical Leadership Module Committee (TLMC). The TLMC consists of the CTO and VP of Engineering from the Mozilla Firefox organization, plus additional members that reflect the technical leadership of the project. The additional members are selected as needed to reach a six member minimum and ensure broad coverage of domain knowledge. In most cases, we would expect those leaders to be more or less full-time on the project. These additional members will serve two-year terms. As of 2018, the current members are:<br />
<br />
* Eric Rescorla (Firefox CTO) - Chair<br />
* Dave Camp (Vice President, Firefox Engineering)<br />
* Boris Zbarsky<br />
* David Baron<br />
* Dave Townsend<br />
* Luke Wagner<br />
<br />
The owner of the [[Modules/Activities#Module_Ownership_System|Module Ownership module]] (currently Mitchell Baker) is expected to revisit these membership criteria upon any substantial changes to the management structures or the relationships to corporate entities with the project.<br />
<br />
===List of Applicable Modules===<br />
<br />
For purposes of defining the scope of the TLMC's responsibility, the modules that make up Firefox are as follows:<br />
<br />
* [[Modules/Firefox|Firefox]]<br />
* [[Modules/Toolkit|Toolkit]]<br />
* [[Modules/Core|Core]]<br />
* [[Modules/All#Submodules|Submodules]]<br />
* [[Modules/All#Browser|Browser]]<br />
* [[Modules/All#Tier_1_Platforms|Tier 1 Platforms]]<br />
* Other:<br />
** [[Modules/All#Add-on_SDK|Add-On SDK]]<br />
** [[Modules/All#Android_Background_Services|Android Background Services]]<br />
** [[Modules/All#Firefox_for_Metro|Firefox for Metro]]<br />
** [[Modules/All#BrowserID|BrowserID]]<br />
** [[Modules/All#Firefox_Accounts|Firefox Accounts]]<br />
** [[Modules/All#DevTools|Devtools]]<br />
** [[Modules/All#Firefox_for_iOS_.28Fennec.29|Fennec]]<br />
** [[Modules/All#Sync|Sync]]<br />
** [[Modules/All#Mozilla_Location_Service_.28MLS.29|Mozilla Location Service]]<br />
** [[Modules/All#Mozilla_Stumbler_.28.22MozStumbler.22.29|Mozstumbler]]<br />
** [[Modules/All#URL_Classifier|URL Classifier]]<br />
** [[Modules/All#Tree_Sheriffs|Tree Sheriffs]]<br />
* Governance<br />
** [[Modules/All#Security_Policy|Security Policy]]<br />
** [[Modules/All#Mozilla_CA_Certificate_Policy|CA Certificate Policy]]<br />
** [[Modules/All#Code_Review_Policy|Code Review Policy]]<br />
** [[Modules/All#Performance_Regression_Policy|Performance Regression Policy]]<br />
** [[Modules/All#CA_Certificates|CA Certificates]]<br />
** [[Modules/All#Commit_Access_Policy|Commit Access Policy]]</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Modules/Technical_Leadership_Module_Committee&diff=1202972Modules/Technical Leadership Module Committee2018-10-26T21:35:33Z<p>Stpeter: Fixed broken links and formatting</p>
<hr />
<div>===Scope and Operation===<br />
<br />
The Firefox Technical Leadership Module Committee (TLMC) is responsible for engineering coordination and escalation among the modules that make up Firefox. The TLMC generally tries to avoid day-to-day involvement in module operation, but gets involved with decisions that are explicitly cross module or with issues that cannot be resolved at lower levels, such as:<br />
<br />
* Resolution of decisions that do not fall clearly into any specific module or set of modules<br />
* Escalation of disputes beyond the module owner level<br />
<br />
In addition, the [[Modules/Activities#Module_Ownership_System|Module Ownership module]] delegates its responsibilities for the modules that make up Firefox to the TLMC. This delegated authority includes topics such as those listed below, which would otherwise escalate to the [[Modules/Activities#Module_Ownership_System|Module Ownership module]]:<br />
<br />
* Filling vacant roles where appropriate<br />
* Ensuring module owners are fulfilling their responsibilities, and replacing those who are not<br />
* Creating and staffing new modules where new parts of the project evolve<br />
* Figuring out what to do if a module isn't getting enough attention<br />
* Resolving conflicts among module owners<br />
<br />
The TLMC decision making process attempts to form consensus among stakeholders, with the committee empowered to resolve disputes when that consensus cannot be reached, and the chair empowered when consensus cannot be reached within the committee.<br />
<br />
===Structure===<br />
<br />
Instead of a single owner, the leadership of the [[Modules/All#mozilla-toplevel|top-level module]] is governed by the<br />
Technical Leadership Module Committee (TLMC). The TLMC consists of the CTO and VP of Engineering from the Mozilla Firefox organization, plus additional members that reflect the technical leadership of the project. The additional members are selected as needed to reach a six member minimum and ensure broad coverage of domain knowledge. In most cases, we would expect those leaders to be more or less full-time on the project. These additional members will serve two-year terms. As of 2018, the current members are:<br />
<br />
* Eric Rescorla (Firefox CTO) - Chair<br />
* Dave Camp (Vice President, Firefox Engineering)<br />
* Boris Zbarsky<br />
* David Baron<br />
* Dave Townsend<br />
* Luke Wagner<br />
<br />
The owner of the [[Modules/Activities#Module_Ownership_System|Module Ownership module]] (currently Mitchell Baker) is expected to revisit these membership criteria upon any substantial changes to the management structures or the relationships to corporate entities with the project.<br />
<br />
===List of Applicable Modules===<br />
<br />
For purposes of defining the scope of the TLMC's responsibility, the modules that make up Firefox are as follows:<br />
<br />
* [[Modules/Firefox|Firefox]]<br />
* [[Modules/Toolkit|Toolkit]]<br />
* [[Modules/Core|Core]]<br />
* [[Modules/All#Submodules|Submodules]]<br />
* [[Modules/All#Browser|Browser]]<br />
* [[Modules/All#Tier_1_Platforms|Tier 1 Platforms]]<br />
* Other:<br />
** [[Modules/All#Add-on_SDK|Add-On SDK]]<br />
** [[Modules/All#Android_Background_Services|Android Background Services]]<br />
** [[Modules/All#Firefox_for_Metro|Firefox for Metro]]<br />
** [[Modules/All#BrowserID|BrowserID]]<br />
** [[Modules/All#Firefox_Accounts|Firefox Accounts]]<br />
** [[Modules/All#DevTools|Devtools]]<br />
** [[Modules/All#Firefox_for_iOS_.28Fennec.29|Fennec]]<br />
** [[Modules/All#Sync|Sync]]<br />
** [[Modules/All#Mozilla_Location_Service_.28MLS.29|Mozilla Location Service]]<br />
** [[Modules/All#Mozilla_Stumbler_.28.22MozStumbler.22.29|Mozstumbler]]<br />
** [[Modules/All#URL_Classifier|URL Classifier]]<br />
** [[Modules/All#Tree_Sheriffs|Tree Sheriffs]]<br />
* Governance<br />
** [[Modules/All#Security_Policy|Security Policy]]<br />
** [[Modules/All#Mozilla_CA_Certificate_Policy|CA Certificate Policy]]<br />
** [[Modules/All#Code_Review_Policy|Code Review Policy]]<br />
** [[Modules/All#Performance_Regression_Policy|Performance Regression Policy]]<br />
** [[Modules/All#CA_Certificates|CA Certificates]]<br />
** [[Modules/All#Commit_Access_Policy|Commit Access Policy]]</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Modules/Technical_Leadership_Module_Committee&diff=1202961Modules/Technical Leadership Module Committee2018-10-26T18:20:22Z<p>Stpeter: Change members from "initial proposed" to current as of 2018</p>
<hr />
<div>===Scope and Operation===<br />
<br />
The Firefox Technical Leadership Module Committee (TLMC) is responsible for engineering coordination and escalation among the modules that make up Firefox. The TLMC generally tries to avoid day-to-day involvement in module operation, but gets involved with decisions that are explicitly cross module or with issues that cannot be resolved at lower levels, such as:<br />
<br />
* Resolution of decisions that do not fall clearly into any specific module or set of modules<br />
* Escalation of disputes beyond the module owner level<br />
<br />
In addition, the [[Modules/Activities#Module_Ownership_System|Module Ownership module]] delegates its responsibilities for the modules that make up Firefox to the TLMC. This delegated authority includes topics such as those listed below, which would otherwise escalate to the [[Modules/Activities#Module_Ownership_System|Module Ownership module]]:<br />
<br />
* Filling vacant roles where appropriate<br />
* Ensuring module owners are fulfilling their responsibilities, and replacing those who are not<br />
* Creating and staffing new modules where new parts of the project evolve<br />
* Figuring out what to do if a module isn't getting enough attention<br />
* Resolving conflicts among module owners<br />
<br />
The TLMC decision making process attempts to form consensus among stakeholders, with the committee empowered to resolve disputes when that consensus cannot be reached, and the chair empowered when consensus cannot be reached within the committee.<br />
<br />
===Structure===<br />
<br />
Instead of a single owner, the leadership of the [[Modules/All#mozilla-toplevel|top-level module] is governed by the<br />
Technical Leadership Module Committee (TLMC). The TLMC consists of the CTO and VP of Engineering from the Mozilla Firefox organization, plus additional members that reflect the technical leadership of the project. The additional members are selected as needed to reach a six member minimum and ensure broad coverage of domain knowledge. In most cases, we would expect those leaders to be more or less full-time on the project. These additional members will serve two-year terms. As of 2018, the current members are:<br />
<br />
* Eric Rescorla (Firefox CTO) - Chair<br />
* Dave Camp (Vice President, Firefox Engineering)<br />
* Boris Zbarsky<br />
* David Baron<br />
* Dave Townsend<br />
* Luke Wagner<br />
<br />
The owner of the [[Modules/Activities#Module_Ownership_System|Module Ownership module]] (currently Mitchell Baker) is expected to revisit these membership criteria upon any substantial changes to the management structures or the relationships to corporate entities with the project.<br />
<br />
===List of Applicable Modules===<br />
<br />
For purposes of defining the scope of the TLMC's responsibility, the modules that make up Firefox are as follows:<br />
<br />
* [[Modules/Firefox|Firefox]]<br />
* [[Modules/Toolkit|Toolkit]]<br />
* [[Modules/Core|Core]]<br />
* [[Modules/All#Submodules|Submodules]]<br />
* [[Modules/All#Browser|Browser]]<br />
* [[Modules/All#Tier_1_Platforms|Tier 1 Platforms]]<br />
* Other:<br />
- [[Modules/All#Add-on_SDK|Add-On SDK]]<br />
- [[Modules/All#Android_Background_Services|Android Background Services<br />
- [[Modules/All#Firefox_for_Metro|Firefox for Metro]]<br />
- [[Modules/All#BrowserID|BrowserID]]<br />
- [[Modules/All#Firefox_Accounts|Firefox Accounts]]<br />
- [[Modules/All#DevTools|Devtools]]<br />
- [[Modules/All#Firefox_for_iOS_.28Fennec.29|Fennec]]<br />
- [[Modules/All#Sync|Sync]]<br />
- [[Modules/All#Mozilla_Location_Service_.28MLS.29|Mozilla Location Service]]<br />
- [[Modules/All#Mozilla_Stumbler_.28.22MozStumbler.22.29|Mozstumbler]]<br />
- [[Modules/All#URL_Classifier|URL Classifier]]<br />
- [[Modules/All#Tree_Sheriffs|Tree Sheriffs]]<br />
* Governance<br />
- [[Modules/All#Security_Policy|Security Policy]]<br />
- [[Modules/All#Mozilla_CA_Certificate_Policy|CA Certificate Policy]]<br />
- [[Modules/All#Code_Review_Policy|Code Review Policy]]<br />
- [[Modules/All#Performance_Regression_Policy|Performance Regression Policy]]<br />
- [[Modules/All#CA_Certificates|CA Certificates]]<br />
- [[https://wiki.mozilla.org/Modules/All#Commit_Access_Policy|Commit Access Policy]]</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Modules/Technical_Leadership_Module_Committee&diff=1202960Modules/Technical Leadership Module Committee2018-10-26T18:13:47Z<p>Stpeter: Initial version derived from Dave Camp's post to mozilla.governance</p>
<hr />
<div>===Scope and Operation===<br />
<br />
The Firefox Technical Leadership Module Committee (TLMC) is responsible for engineering coordination and escalation among the modules that make up Firefox. The TLMC generally tries to avoid day-to-day involvement in module operation, but gets involved with decisions that are explicitly cross module or with issues that cannot be resolved at lower levels, such as:<br />
<br />
* Resolution of decisions that do not fall clearly into any specific module or set of modules<br />
* Escalation of disputes beyond the module owner level<br />
<br />
In addition, the [[Modules/Activities#Module_Ownership_System|Module Ownership module]] delegates its responsibilities for the modules that make up Firefox to the TLMC. This delegated authority includes topics such as those listed below, which would otherwise escalate to the [[Modules/Activities#Module_Ownership_System|Module Ownership module]]:<br />
<br />
* Filling vacant roles where appropriate<br />
* Ensuring module owners are fulfilling their responsibilities, and replacing those who are not<br />
* Creating and staffing new modules where new parts of the project evolve<br />
* Figuring out what to do if a module isn't getting enough attention<br />
* Resolving conflicts among module owners<br />
<br />
The TLMC decision making process attempts to form consensus among stakeholders, with the committee empowered to resolve disputes when that consensus cannot be reached, and the chair empowered when consensus cannot be reached within the committee.<br />
<br />
===Structure===<br />
<br />
Instead of a single owner, the leadership of the [[Modules/All#mozilla-toplevel|top-level module] is governed by the<br />
Technical Leadership Module Committee (TLMC). The TLMC consists of the CTO and VP of Engineering from the Mozilla Firefox organization, plus additional members that reflect the technical leadership of the project. The additional members are selected as needed to reach a six member minimum and ensure broad coverage of domain knowledge. In most cases, we would expect those leaders to be more or less full-time on the project. These additional members will serve two-year terms. The initial proposed members are:<br />
<br />
* Eric Rescorla (Firefox CTO) - Chair<br />
* Dave Camp (Vice President, Firefox Engineering)<br />
* Boris Zbarsky<br />
* David Baron<br />
* Dave Townsend<br />
* Luke Wagner<br />
<br />
The owner of the [[Modules/Activities#Module_Ownership_System|Module Ownership module]] (currently Mitchell Baker) is expected to revisit these membership criteria upon any substantial changes to the management structures or the relationships to corporate entities with the project.<br />
<br />
===List of Applicable Modules===<br />
<br />
For purposes of defining the scope of the TLMC's responsibility, the modules that make up Firefox are as follows:<br />
<br />
* [[Modules/Firefox|Firefox]]<br />
* [[Modules/Toolkit|Toolkit]]<br />
* [[Modules/Core|Core]]<br />
* [[Modules/All#Submodules|Submodules]]<br />
* [[Modules/All#Browser|Browser]]<br />
* [[Modules/All#Tier_1_Platforms|Tier 1 Platforms]]<br />
* Other:<br />
- [[Modules/All#Add-on_SDK|Add-On SDK]]<br />
- [[Modules/All#Android_Background_Services|Android Background Services<br />
- [[Modules/All#Firefox_for_Metro|Firefox for Metro]]<br />
- [[Modules/All#BrowserID|BrowserID]]<br />
- [[Modules/All#Firefox_Accounts|Firefox Accounts]]<br />
- [[Modules/All#DevTools|Devtools]]<br />
- [[Modules/All#Firefox_for_iOS_.28Fennec.29|Fennec]]<br />
- [[Modules/All#Sync|Sync]]<br />
- [[Modules/All#Mozilla_Location_Service_.28MLS.29|Mozilla Location Service]]<br />
- [[Modules/All#Mozilla_Stumbler_.28.22MozStumbler.22.29|Mozstumbler]]<br />
- [[Modules/All#URL_Classifier|URL Classifier]]<br />
- [[Modules/All#Tree_Sheriffs|Tree Sheriffs]]<br />
* Governance<br />
- [[Modules/All#Security_Policy|Security Policy]]<br />
- [[Modules/All#Mozilla_CA_Certificate_Policy|CA Certificate Policy]]<br />
- [[Modules/All#Code_Review_Policy|Code Review Policy]]<br />
- [[Modules/All#Performance_Regression_Policy|Performance Regression Policy]]<br />
- [[Modules/All#CA_Certificates|CA Certificates]]<br />
- [[https://wiki.mozilla.org/Modules/All#Commit_Access_Policy|Commit Access Policy]]</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1199277Firefox/Features/Web Payments/Privacy & Security Considerations2018-08-10T17:22:37Z<p>Stpeter: add pointer to secure storage metabug</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] (based on the [https://www.w3.org/TR/payment-request/ W3C Payment Request] and the [https://www.w3.org/TR/payment-method-basic-card/ W3C Basic Card Payment] specifications), the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Local Storage of User Information ("Data At Rest") ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* credit card expiration date<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox ''never'' stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see this [https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data profiles page]) for more details). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key (see {{bug|1463865|Bug 1463865}}); in the initial release this method will be used to protect credit card information, and in future releases might be used to protect other kinds of data as well.<br />
<br />
== Interaction with Merchant Website ("Data in Motion") ==<br />
<br />
The payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
== Information Leakage ==<br />
<br />
When the payment process is loaded in web content on a merchant website, it is easy for code running on that site (often third-party code that has not been vetted for privacy and security vulnerabilities) to engage in wholesale [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] (e.g., via form tracking and session replay scripts), to track the user's mouse movements, to trick the user into clicking malicious but ephemeral links (see [https://lcamtuf.blogspot.com/2010/08/on-designing-uis-for-non-robots.html this post] for related attacks), etc.<br />
<br />
By contrast, when the payment process is handled by trusted, standardized code in a browser dialog window, the user's form input (credit card number, shipping address, etc.) is protected against many of these attacks.<br />
<br />
In addition, we have instituted several policies to ensure that user data is not leaked to the merchant site:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the in-browser workflow (see {{bug|1443735|Bug 1443735}}). Before then, Firefox shares only the minimum information (country and postal code) needed to determine shipping viability and cost.<br />
<br />
* Although a merchant website could try to gather the user's country and postal code by calling the PaymentRequest.show() and .abort() functions in quick succession (even without the user noticing), to prevent abuse we have implemented a minimum amount of time (5 seconds) to display the payment dialog window, thus making it difficult for a website to trick a user into sharing this information (see {{bug|1447773|Bug 1447773}}).<br />
<br />
== Device Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Data Validation ==<br />
<br />
As part of the W3C Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* [https://www.w3.org/TR/payment-request/#dom-paymentitem-label PaymentItem labels] (e.g., products in a shopping cart)<br />
* The [https://tools.ietf.org/html/rfc6454 web origin] of the merchant website (which could include mixed scripts, bidirectional domain labels, confusable characters, etc.)<br />
* [https://www.w3.org/TR/payment-request/#dom-paymentdetailsupdate-error Error strings], especially the generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting their display length (e.g., truncate to 64 bytes or fewer, as is done for relying party names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]), always using UI elements to provide a clear boundary around these strings, not allowing these UI elements to overflow into other elements, etc.<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Process Separation and Sandboxing ==<br />
<br />
To help mitigate against [https://wiki.mozilla.org/Security/Sandbox sandbox] violations, cross-site scripting attacks, and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles sensitive user information such as credit card numbers (see {{bug|1460425|Bug 1460425}}), thus helping to prevent a compromised web content process from reading this data. <br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows (e.g. consider window.open features)?<br />
* It would be helpful to include diagrams of the UI workflow and protocol state machines.<br />
* It would be helpful to describe the process model or point to documentation on another page.<br />
* We need to add a more detailed discussion of fingerprinting attacks.<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card information is not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation as in [[Project_Fission|Project Fission]]).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196377Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T23:27:53Z<p>Stpeter: /* Open Issues */ add TODOs to open issues</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] (based on the [https://www.w3.org/TR/payment-request/ W3C Payment Request] and the [https://www.w3.org/TR/payment-method-basic-card/ W3C Basic Card Payment] specifications), the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Local Storage of User Information ("Data At Rest") ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* credit card expiration date<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox ''never'' stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see this [https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data profiles page]) for more details). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section (or a separate page on this wiki) once this new method is implemented.<br />
<br />
== Interaction with Merchant Website ("Data in Motion") ==<br />
<br />
The payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
== Information Leakage ==<br />
<br />
When the payment process is loaded in web content on a merchant website, it is easy for code running on that site (often third-party code that has not been vetted for privacy and security vulnerabilities) to engage in wholesale [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] (e.g., via form tracking and session replay scripts), to track the user's mouse movements, to trick the user into clicking malicious but ephemeral links (see [https://lcamtuf.blogspot.com/2010/08/on-designing-uis-for-non-robots.html this post] for related attacks), etc.<br />
<br />
By contrast, when the payment process is handled by trusted, standardized code in a browser dialog window, the user's form input (credit card number, shipping address, etc.) is protected against many of these attacks.<br />
<br />
In addition, we have instituted several policies to ensure that user data is not leaked to the merchant site:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the in-browser workflow (see {{bug|1443735|Bug 1443735}}). Before then, Firefox shares only the minimum information (country and postal code) needed to determine shipping viability and cost.<br />
<br />
* Although a merchant website could try to gather the user's country and postal code by calling the PaymentRequest.show() and .abort() functions in quick succession (even without the user noticing), to prevent abuse we have implemented a minimum amount of time (5 seconds) to display the payment dialog window, thus making it difficult for a website to trick a user into sharing this information (see {{bug|1447773|Bug 1447773}}).<br />
<br />
== Device Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Data Validation ==<br />
<br />
As part of the W3C Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* [https://www.w3.org/TR/payment-request/#dom-paymentitem-label PaymentItem labels] (e.g., products in a shopping cart)<br />
* The [https://tools.ietf.org/html/rfc6454 web origin] of the merchant website (which could include mixed scripts, bidirectional domain labels, confusable characters, etc.)<br />
* [https://www.w3.org/TR/payment-request/#dom-paymentdetailsupdate-error Error strings], especially the generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting their display length (e.g., truncate to 64 bytes or fewer, as is done for relying party names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]), always using UI elements to provide a clear boundary around these strings, not allowing these UI elements to overflow into other elements, etc.<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Process Separation and Sandboxing ==<br />
<br />
To help mitigate against [https://wiki.mozilla.org/Security/Sandbox sandbox] violations, cross-site scripting attacks, and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles sensitive user information such as credit card numbers (see {{bug|1460425|Bug 1460425}}), thus helping to prevent a compromised web content process from reading this data. <br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows (e.g. consider window.open features)?<br />
* It would be helpful to include diagrams of the UI workflow and protocol state machines.<br />
* It would be helpful to describe the process model or point to documentation on another page.<br />
* We need to add a more detailed discussion of fingerprinting attacks.<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card information is not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation as in [[Project_Fission|Project Fission]]).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196376Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T23:23:41Z<p>Stpeter: moved some content around</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] (based on the [https://www.w3.org/TR/payment-request/ W3C Payment Request] and the [https://www.w3.org/TR/payment-method-basic-card/ W3C Basic Card Payment] specifications), the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Local Storage of User Information ("Data At Rest") ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* credit card expiration date<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox ''never'' stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see this [https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data profiles page]) for more details). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section (or a separate page on this wiki) once this new method is implemented.<br />
<br />
== Interaction with Merchant Website ("Data in Motion") ==<br />
<br />
The payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
== Information Leakage ==<br />
<br />
When the payment process is loaded in web content on a merchant website, it is easy for code running on that site (often third-party code that has not been vetted for privacy and security vulnerabilities) to engage in wholesale [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] (e.g., via form tracking and session replay scripts), to track the user's mouse movements, to trick the user into clicking malicious but ephemeral links (see [https://lcamtuf.blogspot.com/2010/08/on-designing-uis-for-non-robots.html this post] for related attacks), etc.<br />
<br />
By contrast, when the payment process is handled by trusted, standardized code in a browser dialog window, the user's form input (credit card number, shipping address, etc.) is protected against many of these attacks.<br />
<br />
In addition, we have instituted several policies to ensure that user data is not leaked to the merchant site:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the in-browser workflow (see {{bug|1443735|Bug 1443735}}). Before then, Firefox shares only the minimum information (country and postal code) needed to determine shipping viability and cost.<br />
<br />
* Although a merchant website could try to gather the user's country and postal code by calling the PaymentRequest.show() and .abort() functions in quick succession (even without the user noticing), to prevent abuse we have implemented a minimum amount of time (5 seconds) to display the payment dialog window, thus making it difficult for a website to trick a user into sharing this information (see {{bug|1447773|Bug 1447773}}).<br />
<br />
== Device Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Data Validation ==<br />
<br />
As part of the W3C Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* [https://www.w3.org/TR/payment-request/#dom-paymentitem-label PaymentItem labels] (e.g., products in a shopping cart)<br />
* The [https://tools.ietf.org/html/rfc6454 web origin] of the merchant website (which could include mixed scripts, bidirectional domain labels, confusable characters, etc.)<br />
* [https://www.w3.org/TR/payment-request/#dom-paymentdetailsupdate-error Error strings], especially the generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting their display length (e.g., truncate to 64 bytes or fewer, as is done for relying party names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]), always using UI elements to provide a clear boundary around these strings, not allowing these UI elements to overflow into other elements, etc.<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Process Separation and Sandboxing ==<br />
<br />
To help mitigate against [https://wiki.mozilla.org/Security/Sandbox sandbox] violations, cross-site scripting attacks, and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles sensitive user information such as credit card numbers (see {{bug|1460425|Bug 1460425}}), thus helping to prevent a compromised web content process from reading this data. <br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card information is not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation as in [[Project_Fission|Project Fission]]).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196375Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T23:15:34Z<p>Stpeter: /* Data Validation */ add spec links</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] (based on the [https://www.w3.org/TR/payment-request/ W3C Payment Request] and the [https://www.w3.org/TR/payment-method-basic-card/ W3C Basic Card Payment] specifications), the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Local Storage of User Information ("Data At Rest") ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* credit card expiration date<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox ''never'' stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see this [https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data profiles page]) for more details). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section (or a separate page on this wiki) once this new method is implemented.<br />
<br />
== Interaction with Merchant Website ("Data in Motion") ==<br />
<br />
The payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
== Information Leakage ==<br />
<br />
When the payment process is loaded in web content on a merchant website, it is easy for code running on that site (often third-party code that has not been vetted for privacy and security vulnerabilities) to engage in wholesale [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] (e.g., via form tracking and session replay scripts), to track the user's mouse movements, to trick the user into clicking malicious but ephemeral links (see [https://lcamtuf.blogspot.com/2010/08/on-designing-uis-for-non-robots.html this post] for related attacks), etc.<br />
<br />
By contrast, when the payment process is handled by trusted, standardized code in a browser dialog window, the user's form input (credit card number, shipping address, etc.) is protected against many of these attacks.<br />
<br />
In addition, we have instituted several policies to ensure that user data is not leaked to the merchant site:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the in-browser workflow (see {{bug|1443735|Bug 1443735}}). Before then, Firefox shares only the minimum information (country and postal code) needed to determine shipping viability and cost.<br />
<br />
* Although a merchant website could try to gather the user's country and postal code by calling the PaymentRequest.show() and .abort() functions in quick succession (even without the user noticing), to prevent abuse we have implemented a minimum amount of time (5 seconds) to display the payment dialog window, thus making it difficult for a website to trick a user into sharing this information (see {{bug|1447773|Bug 1447773}}).<br />
<br />
== Device Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* [https://www.w3.org/TR/payment-request/#dom-paymentitem-label PaymentItem labels] (e.g., products in a shopping cart)<br />
* The [https://tools.ietf.org/html/rfc6454 web origin] of the merchant website (which could include mixed scripts, bidirectional domain labels, confusable characters, etc.)<br />
* [https://www.w3.org/TR/payment-request/#dom-paymentdetailsupdate-error Error strings], especially the generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting their display length (e.g., truncate to 64 bytes or fewer, as is done for relying party names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]), always using UI elements to provide a clear boundary around these strings, not allowing these UI elements to overflow into other elements, etc.<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196364Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T23:07:53Z<p>Stpeter: /* Data Validation */ added further guidelines</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] (based on the [https://www.w3.org/TR/payment-request/ W3C Payment Request] and the [https://www.w3.org/TR/payment-method-basic-card/ W3C Basic Card Payment] specifications), the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Local Storage of User Information ("Data At Rest") ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* credit card expiration date<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox ''never'' stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see this [https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data profiles page]) for more details). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section (or a separate page on this wiki) once this new method is implemented.<br />
<br />
== Interaction with Merchant Website ("Data in Motion") ==<br />
<br />
The payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
== Information Leakage ==<br />
<br />
When the payment process is loaded in web content on a merchant website, it is easy for code running on that site (often third-party code that has not been vetted for privacy and security vulnerabilities) to engage in wholesale [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] (e.g., via form tracking and session replay scripts), to track the user's mouse movements, to trick the user into clicking malicious but ephemeral links (see [https://lcamtuf.blogspot.com/2010/08/on-designing-uis-for-non-robots.html this post] for related attacks), etc.<br />
<br />
By contrast, when the payment process is handled by trusted, standardized code in a browser dialog window, the user's form input (credit card number, shipping address, etc.) is protected against many of these attacks.<br />
<br />
In addition, we have instituted several policies to ensure that user data is not leaked to the merchant site:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the in-browser workflow (see {{bug|1443735|Bug 1443735}}). Before then, Firefox shares only the minimum information (country and postal code) needed to determine shipping viability and cost.<br />
<br />
* Although a merchant website could try to gather the user's country and postal code by calling the PaymentRequest.show() and .abort() functions in quick succession (even without the user noticing), to prevent abuse we have implemented a minimum amount of time (5 seconds) to display the payment dialog window, thus making it difficult for a website to trick a user into sharing this information (see {{bug|1447773|Bug 1447773}}).<br />
<br />
== Device Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts, bidirectional domain labels, confusable characters, etc.)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting their display length (e.g., truncate to 64 bytes or fewer, as is done for relying party names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]), always using UI elements to provide a clear boundary around these strings, not allowing these UI elements to overflow into other elements, etc.<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196363Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T22:57:56Z<p>Stpeter: /* Information Leakage */ more clarifications</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] (based on the [https://www.w3.org/TR/payment-request/ W3C Payment Request] and the [https://www.w3.org/TR/payment-method-basic-card/ W3C Basic Card Payment] specifications), the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Local Storage of User Information ("Data At Rest") ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* credit card expiration date<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox ''never'' stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see this [https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data profiles page]) for more details). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section (or a separate page on this wiki) once this new method is implemented.<br />
<br />
== Interaction with Merchant Website ("Data in Motion") ==<br />
<br />
The payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
== Information Leakage ==<br />
<br />
When the payment process is loaded in web content on a merchant website, it is easy for code running on that site (often third-party code that has not been vetted for privacy and security vulnerabilities) to engage in wholesale [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] (e.g., via form tracking and session replay scripts), to track the user's mouse movements, to trick the user into clicking malicious but ephemeral links (see [https://lcamtuf.blogspot.com/2010/08/on-designing-uis-for-non-robots.html this post] for related attacks), etc.<br />
<br />
By contrast, when the payment process is handled by trusted, standardized code in a browser dialog window, the user's form input (credit card number, shipping address, etc.) is protected against many of these attacks.<br />
<br />
In addition, we have instituted several policies to ensure that user data is not leaked to the merchant site:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the in-browser workflow (see {{bug|1443735|Bug 1443735}}). Before then, Firefox shares only the minimum information (country and postal code) needed to determine shipping viability and cost.<br />
<br />
* Although a merchant website could try to gather the user's country and postal code by calling the PaymentRequest.show() and .abort() functions in quick succession (even without the user noticing), to prevent abuse we have implemented a minimum amount of time (5 seconds) to display the payment dialog window, thus making it difficult for a website to trick a user into sharing this information (see {{bug|1447773|Bug 1447773}}).<br />
<br />
== Device Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196359Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T22:46:07Z<p>Stpeter: /* Information Leakage */ more details and links</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] (based on the [https://www.w3.org/TR/payment-request/ W3C Payment Request] and the [https://www.w3.org/TR/payment-method-basic-card/ W3C Basic Card Payment] specifications), the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Local Storage of User Information ("Data At Rest") ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* credit card expiration date<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox ''never'' stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see this [https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data profiles page]) for more details). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section (or a separate page on this wiki) once this new method is implemented.<br />
<br />
== Interaction with Merchant Website ("Data in Motion") ==<br />
<br />
The payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
== Information Leakage ==<br />
<br />
Because the user's form input (credit card number, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
In addition, we have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the in-browser workflow (see {{bug|1443735|Bug 1443735}}). Before then, Firefox shares only the minimum information (country and postal code) needed to determine shipping viability and cost.<br />
<br />
* Although a merchant website could try to gather the user's country and postal code by calling the PaymentRequest.show() and .abort() functions in quick succession (see [https://lcamtuf.blogspot.com/2010/08/on-designing-uis-for-non-robots.html this post] for related attacks), to prevent abuse we have implemented a minimum amount of time (5 seconds) to display the payment dialog window, thus making it difficult for a website to trick a user into sharing this information (see {{bug|1447773|Bug 1447773}}).<br />
<br />
== Device Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196358Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T20:55:58Z<p>Stpeter: corrected links</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] (based on the [https://www.w3.org/TR/payment-request/ W3C Payment Request] and the [https://www.w3.org/TR/payment-method-basic-card/ W3C Basic Card Payment] specifications), the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Local Storage of User Information ("Data At Rest") ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* credit card expiration date<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox ''never'' stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see this [https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data profiles page]) for more details). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section (or a separate page on this wiki) once this new method is implemented.<br />
<br />
== Interaction with Merchant Website ("Data in Motion") ==<br />
<br />
The payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
== Information Leakage ==<br />
<br />
Because the user's form input (credit card number, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
In addition, we have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the in-browser workflow (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse have implemented a minimum amount of time to display the payment sheet, thus making it difficult for a website to trick a user into sharing this information (see {{bug|1447773|Bug 1447773}}).<br />
<br />
== Device Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196357Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T20:47:20Z<p>Stpeter: /* How Data is Secured on Device */ missing paren</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API W3C Payment Request API] and the [https://www.w3.org/TR/payment-method-basic-card/ W3C Basic Card Payment Method], the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Local Storage of User Information ("Data At Rest") ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* credit card expiration date<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox ''never'' stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see this [https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data profiles page]) for more details). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section (or a separate page on this wiki) once this new method is implemented.<br />
<br />
== Interaction with Merchant Website ("Data in Motion") ==<br />
<br />
The payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
== Information Leakage ==<br />
<br />
Because the user's form input (credit card number, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
In addition, we have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the in-browser workflow (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse have implemented a minimum amount of time to display the payment sheet, thus making it difficult for a website to trick a user into sharing this information (see {{bug|1447773|Bug 1447773}}).<br />
<br />
== Device Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196356Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T20:47:04Z<p>Stpeter: /* How Data is Secured on Device */ typo</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API W3C Payment Request API] and the [https://www.w3.org/TR/payment-method-basic-card/ W3C Basic Card Payment Method], the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Local Storage of User Information ("Data At Rest") ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* credit card expiration date<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox ''never'' stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see this [https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data profiles page] for more details). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section (or a separate page on this wiki) once this new method is implemented.<br />
<br />
== Interaction with Merchant Website ("Data in Motion") ==<br />
<br />
The payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
== Information Leakage ==<br />
<br />
Because the user's form input (credit card number, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
In addition, we have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the in-browser workflow (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse have implemented a minimum amount of time to display the payment sheet, thus making it difficult for a website to trick a user into sharing this information (see {{bug|1447773|Bug 1447773}}).<br />
<br />
== Device Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196355Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T20:46:39Z<p>Stpeter: /* How Data is Secured on Device */ add link to page about profiles</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API W3C Payment Request API] and the [https://www.w3.org/TR/payment-method-basic-card/ W3C Basic Card Payment Method], the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Local Storage of User Information ("Data At Rest") ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* credit card expiration date<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox ''never'' stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see this [https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data profiles page) for more details). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section (or a separate page on this wiki) once this new method is implemented.<br />
<br />
== Interaction with Merchant Website ("Data in Motion") ==<br />
<br />
The payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
== Information Leakage ==<br />
<br />
Because the user's form input (credit card number, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
In addition, we have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the in-browser workflow (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse have implemented a minimum amount of time to display the payment sheet, thus making it difficult for a website to trick a user into sharing this information (see {{bug|1447773|Bug 1447773}}).<br />
<br />
== Device Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196354Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T20:43:54Z<p>Stpeter: modify section name</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API W3C Payment Request API] and the [https://www.w3.org/TR/payment-method-basic-card/ W3C Basic Card Payment Method], the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Local Storage of User Information ("Data At Rest") ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* credit card expiration date<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox ''never'' stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]]. In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section (or a separate page on this wiki) once this new method is implemented.<br />
<br />
== Interaction with Merchant Website ("Data in Motion") ==<br />
<br />
The payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
== Information Leakage ==<br />
<br />
Because the user's form input (credit card number, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
In addition, we have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the in-browser workflow (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse have implemented a minimum amount of time to display the payment sheet, thus making it difficult for a website to trick a user into sharing this information (see {{bug|1447773|Bug 1447773}}).<br />
<br />
== Device Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196353Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T20:42:34Z<p>Stpeter: move around some text</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API W3C Payment Request API] and the [https://www.w3.org/TR/payment-method-basic-card/ W3C Basic Card Payment Method], the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Local Storage of User Information ("Data At Rest") ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* credit card expiration date<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox ''never'' stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]]. In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section (or a separate page on this wiki) once this new method is implemented.<br />
<br />
== Interaction with Merchant Website ("Data in Motion") ==<br />
<br />
The payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
== Information Leakage ==<br />
<br />
Because the user's form input (credit card number, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
In addition, we have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the in-browser workflow (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse have implemented a minimum amount of time to display the payment sheet, thus making it difficult for a website to trick a user into sharing this information (see {{bug|1447773|Bug 1447773}}).<br />
<br />
== Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196352Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T20:35:32Z<p>Stpeter: /* How It Works */ add link to basic card spec</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API W3C Payment Request API] and the [https://www.w3.org/TR/payment-method-basic-card/ W3C Basic Card Payment Method], the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Storage of User Data ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* credit card expiration date<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox ''never'' stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]]. In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section (or a separate page on this wiki) once this new method is implemented.<br />
<br />
== Data Exchange with Merchant Websites ==<br />
<br />
The Payment Request API has several security advantages over existing payment flows:<br />
<br />
* First, the payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
* Second, because the user's form input (credit card number, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
== Information Leakage ==<br />
<br />
We have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the process (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse we are implementing a minimum amount of time to display the payment sheet (thus making it extremely difficult for a website to trick a user into sharing this information).<br />
<br />
== Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196351Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T20:34:27Z<p>Stpeter: /* Storage of User Data */ add exp date</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API W3C Payment Request API], the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Storage of User Data ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* credit card expiration date<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox ''never'' stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]]. In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section (or a separate page on this wiki) once this new method is implemented.<br />
<br />
== Data Exchange with Merchant Websites ==<br />
<br />
The Payment Request API has several security advantages over existing payment flows:<br />
<br />
* First, the payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
* Second, because the user's form input (credit card number, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
== Information Leakage ==<br />
<br />
We have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the process (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse we are implementing a minimum amount of time to display the payment sheet (thus making it extremely difficult for a website to trick a user into sharing this information).<br />
<br />
== Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196350Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T20:29:30Z<p>Stpeter: small text corrections</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often in a workflow spread over several web pages. When the user has provided all required information and is satisfied with the final order details, the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant and can contain various security vulnerabilities.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API W3C Payment Request API], the web payments feature will present a standardized, more secure checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally directing Firefox to save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Storage of User Data ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox _never_ stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]]. In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section once this new method is implemented.<br />
<br />
== Data Exchange with Merchant Websites ==<br />
<br />
The Payment Request API has several security advantages over existing payment flows:<br />
<br />
* First, the payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
* Second, because the user's form input (credit card number, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
== Information Leakage ==<br />
<br />
We have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the process (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse we are implementing a minimum amount of time to display the payment sheet (thus making it extremely difficult for a website to trick a user into sharing this information).<br />
<br />
== Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196342Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T17:59:02Z<p>Stpeter: wiki syntax :-)</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often over the course of several web pages in a workflow. When the user has provided all required information and is satisfied with the final price and order details (e.g., shipping method), the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API W3C Payment Request API], the web payments feature will present a standardized checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
# At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
# The merchant website invokes the PaymentRequest.show() method in the browser.<br />
# Firefox presents a browser dialog window to complete the purchase.<br />
# In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally requesting that Firefox save the information locally for re-use in future transactions.<br />
# When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
# Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
# When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Storage of User Data ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox _never_ stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]]. In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section once this new method is implemented.<br />
<br />
== Data Exchange with Merchant Websites ==<br />
<br />
The Payment Request API has several security advantages over existing payment flows:<br />
<br />
* First, the payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
* Second, because the user's form input (credit card number, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
== Information Leakage ==<br />
<br />
We have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the process (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse we are implementing a minimum amount of time to display the payment sheet (thus making it extremely difficult for a website to trick a user into sharing this information).<br />
<br />
== Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196341Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T17:58:00Z<p>Stpeter: add How It Works section</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== How It Works ==<br />
<br />
Traditionally, the checkout process for an e-commerce website has been loaded in [https://en.wikipedia.org/wiki/Web_content web content]. As a result, the shopper has filled out payment-related details (credit card number, card expiration date, card security code, billing address, shipping address, etc.) at the merchant site, often over the course of several web pages in a workflow. When the user has provided all required information and is satisfied with the final price and order details (e.g., shipping method), the shopper clicks a button like "Place Order" and the shopper's payment instrument (e.g., a debit card) is authorized to pay the amount due. Although [[Firefox/Features/Form_Autofill|form autofill]] can make the checkout process somewhat less inconvenient, the user experience varies from merchant to merchant.<br />
<br />
By using the [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API W3C Payment Request API], the web payments feature will present a standardized checkout flow in a trusted browser dialog window. At a high level, the workflow is as follows:<br />
<br />
1. At the merchant website, the user chooses items to purchase and clicks a "Pay" button of some kind.<br />
2. The merchant website invokes the PaymentRequest.show() method in the browser.<br />
3. Firefox presents a browser dialog window to complete the purchase.<br />
4. In the browser dialog window, the user provides information requested by the merchant (credit card number, shipping address, etc.), optionally requesting that Firefox save the information locally for re-use in future transactions.<br />
5. When the user completes the in-browser workflow, the browser sends a PaymentResponse to the merchant website with the requested information.<br />
6. Optionally the merchant website might ask the user to correct an error (e.g., an invalid postal code) and would then call the PaymentRequest.retry() method; the user would then correct the error and finish the workflow.<br />
7. When the merchant website accepts the PaymentResponse, it calls the PaymentRequest.complete() method and Firefox closes the browser dialog window.<br />
<br />
== Storage of User Data ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox _never_ stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]]. In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section once this new method is implemented.<br />
<br />
== Data Exchange with Merchant Websites ==<br />
<br />
The Payment Request API has several security advantages over existing payment flows:<br />
<br />
* First, the payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
* Second, because the user's form input (credit card number, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
== Information Leakage ==<br />
<br />
We have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the process (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse we are implementing a minimum amount of time to display the payment sheet (thus making it extremely difficult for a website to trick a user into sharing this information).<br />
<br />
== Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196339Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T16:56:25Z<p>Stpeter: /* Fingerprinting */ Add proviso and link to EFF report</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce by presenting a standardized checkout flow in the browser (not loading it from a merchant website). This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== Storage of User Data ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox _never_ stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]]. In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section once this new method is implemented.<br />
<br />
== Data Exchange with Merchant Websites ==<br />
<br />
The [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] establishes a standardized payment flow, which is invoked by the merchant website and launched in the browser. This approach has several security advantages over existing payment flows:<br />
<br />
* First, the payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
* Second, because the user's form input (credit card number, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
== Information Leakage ==<br />
<br />
We have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the process (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse we are implementing a minimum amount of time to display the payment sheet (thus making it extremely difficult for a website to trick a user into sharing this information).<br />
<br />
== Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
Because fingerprinting attacks are extremely creative (see the EFF report [https://panopticlick.eff.org/static/browser-uniqueness.pdf How Unique Is Your Web Browser?]), it is possible that additional attack vectors might be enabled by the W3C Payment Request API, perhaps in combination with non-payment vectors; we are investigating this possibility.<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196338Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-27T16:41:47Z<p>Stpeter: /* Data Exchange with Merchant Websites */ add one word</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce by presenting a standardized checkout flow in the browser (not loading it from a merchant website). This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== Storage of User Data ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox _never_ stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]]. In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section once this new method is implemented.<br />
<br />
== Data Exchange with Merchant Websites ==<br />
<br />
The [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] establishes a standardized payment flow, which is invoked by the merchant website and launched in the browser. This approach has several security advantages over existing payment flows:<br />
<br />
* First, the payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
* Second, because the user's form input (credit card number, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
== Information Leakage ==<br />
<br />
We have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the process (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse we are implementing a minimum amount of time to display the payment sheet (thus making it extremely difficult for a website to trick a user into sharing this information).<br />
<br />
== Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196298Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-26T21:05:35Z<p>Stpeter: /* Private Browsing Mode */ typo</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce by presenting a standardized checkout flow in the browser (not loading it from a merchant website). This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== Storage of User Data ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox _never_ stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]]. In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section once this new method is implemented.<br />
<br />
== Data Exchange with Merchant Websites ==<br />
<br />
The [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] establishes a standardized payment flow, which is invoked by the merchant website and launched in the browser. This approach has several security advantages over existing payment flows:<br />
<br />
* First, the payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
* Second, because the user's form input (credit card, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
== Information Leakage ==<br />
<br />
We have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the process (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse we are implementing a minimum amount of time to display the payment sheet (thus making it extremely difficult for a website to trick a user into sharing this information).<br />
<br />
== Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|Private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196297Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-26T21:05:16Z<p>Stpeter: /* Private Browsing Mode */ corrections and link fix</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce by presenting a standardized checkout flow in the browser (not loading it from a merchant website). This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== Storage of User Data ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox _never_ stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]]. In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section once this new method is implemented.<br />
<br />
== Data Exchange with Merchant Websites ==<br />
<br />
The [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] establishes a standardized payment flow, which is invoked by the merchant website and launched in the browser. This approach has several security advantages over existing payment flows:<br />
<br />
* First, the payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
* Second, because the user's form input (credit card, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
== Information Leakage ==<br />
<br />
We have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the process (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse we are implementing a minimum amount of time to display the payment sheet (thus making it extremely difficult for a website to trick a user into sharing this information).<br />
<br />
== Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
== Private Browsing Mode ==<br />
<br />
[[Private_Browsing|private browsing mode]] is a method whereby Firefox prevents session data from being written to local storage and protects the session data from online tracking. Because this is an important privacy feature, Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is in force. In addition, several other protections are in place:<br />
<br />
* By default, Firefox does not save to local storage any information that the user enters (e.g., credit card data or shipping address when editing payment details). However, the user can override this default by clicking a checkbox in the appropriate screens.<br />
* Firefox does not automatically present in the user interface the last credit card and shipping address used at this website, even if that information is known to Firefox.<br />
* Firefox does not update storage metadata (e.g., the last-modified or last-used time for credit card data or shipping addresses).<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196294Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-26T20:36:04Z<p>Stpeter: /* How Data is Secured on Device */ remove link to incomplete privacy and security considerations</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce by presenting a standardized checkout flow in the browser (not loading it from a merchant website). This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== Storage of User Data ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox _never_ stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]]. In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section once this new method is implemented.<br />
<br />
== Data Exchange with Merchant Websites ==<br />
<br />
The [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] establishes a standardized payment flow, which is invoked by the merchant website and launched in the browser. This approach has several security advantages over existing payment flows:<br />
<br />
* First, the payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
* Second, because the user's form input (credit card, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
== Information Leakage ==<br />
<br />
We have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the process (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse we are implementing a minimum amount of time to display the payment sheet (thus making it extremely difficult for a website to trick a user into sharing this information).<br />
<br />
== Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
== Private Browsing Mode ==<br />
<br />
In [[Private_Browsing private browsing mode]], several additional protections are in place:<br />
<br />
* By default, Firefox does not save credit card data, shipping and billing addresses, etc.<br />
* Firefox does not remember the last credit card and shipping address used at this website.<br />
* Firefox does not send user data to the website without user consent.<br />
* Firefox does not update storage metadata.<br />
* Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is enabled.<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1196292Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-26T20:23:17Z<p>Stpeter: clarify store vs. sync</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce by presenting a standardized checkout flow in the browser (not loading it from a merchant website). This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== Storage of User Data ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., on the user's laptop computer). However, if a user has enabled the [[CloudServices/Sync|Sync feature]], then data might be synchronized across devices (strictly speaking, Sync is not a way to store user data but a way to securely share data among multiple devices).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox _never_ stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see the [[Firefox/Features/Form_Autofill/Privacy_%26_Security_Considerations|privacy and security considerations]] for form autofill). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section once this new method is implemented.<br />
<br />
== Data Exchange with Merchant Websites ==<br />
<br />
The [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] establishes a standardized payment flow, which is invoked by the merchant website and launched in the browser. This approach has several security advantages over existing payment flows:<br />
<br />
* First, the payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
* Second, because the user's form input (credit card, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
== Information Leakage ==<br />
<br />
We have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the process (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse we are implementing a minimum amount of time to display the payment sheet (thus making it extremely difficult for a website to trick a user into sharing this information).<br />
<br />
== Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
== Private Browsing Mode ==<br />
<br />
In [[Private_Browsing private browsing mode]], several additional protections are in place:<br />
<br />
* By default, Firefox does not save credit card data, shipping and billing addresses, etc.<br />
* Firefox does not remember the last credit card and shipping address used at this website.<br />
* Firefox does not send user data to the website without user consent.<br />
* Firefox does not update storage metadata.<br />
* Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is enabled.<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1195298Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-06T23:40:26Z<p>Stpeter: improved accuracy of several statements</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce by loading a standardized checkout flow in the browser. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== Storage of User Data ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., the user's laptop computer).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox _never_ stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see the [[Firefox/Features/Form_Autofill/Privacy_%26_Security_Considerations|privacy and security considerations]] for form autofill). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section once this new method is implemented.<br />
<br />
== Data Exchange with Merchant Websites ==<br />
<br />
The [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] establishes a standardized payment flow, which is invoked by the merchant website and launched in the browser. This approach has several security advantages over existing payment flows:<br />
<br />
* First, the payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
* Second, because the user's form input (credit card, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
== Information Leakage ==<br />
<br />
We have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the process (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse we are implementing a minimum amount of time to display the payment sheet (thus making it extremely difficult for a website to trick a user into sharing this information).<br />
<br />
== Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card), not on card networks (e.g., Visa or Amex).<br />
<br />
== Private Browsing Mode ==<br />
<br />
In [[Private_Browsing private browsing mode]], several additional protections are in place:<br />
<br />
* By default, Firefox does not save credit card data, shipping and billing addresses, etc.<br />
* Firefox does not remember the last credit card and shipping address used at this website.<br />
* Firefox does not send user data to the website without user consent.<br />
* Firefox does not update storage metadata.<br />
* Firefox takes several steps to prevent a website from using the Payment Request API to discover whether private browsing mode is enabled.<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeterhttps://wiki.mozilla.org/index.php?title=Firefox/Features/Web_Payments/Privacy_%26_Security_Considerations&diff=1195176Firefox/Features/Web Payments/Privacy & Security Considerations2018-06-05T22:48:44Z<p>Stpeter: Re-organized the page and added more content!</p>
<hr />
<div>== Introduction ==<br />
<br />
The [[Firefox/Features/Web_Payments|web payments feature]] enables a faster, more secure payment process for online commerce by loading a standardized checkout flow in the browser. This page describes the privacy and security characteristics of the initial release in Firefox, as well as a roadmap of future enhancements.<br />
<br />
== Storage of User Data ==<br />
<br />
If the user opts in to storage of user data (e.g., credit card numbers and shipping addresses) for convenience in future payment flows, Firefox stores that data on behalf of the user.<br />
<br />
This data is not stored "in the cloud" but only on the user's own device (e.g., the user's laptop computer).<br />
<br />
Depending on what the user enters and asks to be retained for future use, Firefox will store the following data locally:<br />
<br />
* credit card number<br />
* billing address<br />
* shipping address<br />
<br />
Note: Firefox _never_ stores the credit card security code (CVV/CCV). If requested by a merchant, the user always needs to provide this information in order to complete a payment.<br />
<br />
=== How Data is Secured on Device ===<br />
<br />
For release in Firefox Nightly (planned in Q3 2018), user data is stored as it currently is in [[Firefox/Features/Form_Autofill|form autofill]] (see the [[Firefox/Features/Form_Autofill/Privacy_%26_Security_Considerations|privacy and security considerations]] for form autofill). In parallel with development of the [[Firefox/Features/Web_Payments|web payments feature]], the Firefox team is building a new secure storage method that will use native operating system services to generate a device-specific key and then encrypt data at rest using that key. Further details will be added to this section once this new method is implemented.<br />
<br />
== Data Exchange with Merchant Websites ==<br />
<br />
The [https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API Payment Request API] establishes a standardized payment flow, which is invoked by the merchant website and launched in the browser. This approach has several security advantages over existing payment flows:<br />
<br />
* First, the payment request from merchant to browser and the payment response from browser to merchant are always protected by Transport Layer Security (HTTPS) because the Payment Request API can be used only in [https://www.w3.org/TR/secure-contexts/ secure contexts].<br />
<br />
* Second, because the user's form input (credit card, shipping address, etc.) is handled by trusted browser code instead of code (often third-party code) on a merchant website, it is much more difficult for unwanted [https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/ data exfiltration] to occur (e.g., via form tracking and session replay scripts).<br />
<br />
== Information Leakage ==<br />
<br />
We have instituted several policies to ensure that user data is not leaked:<br />
<br />
* Firefox does not share the user's full shipping address until the user approves the payment at the very end of the process (see {{bug|1443735|Bug 1443735}}).<br />
<br />
* Although a merchant website could gather the user's partial shipping address (country and postal code) by calling the Payment Request .show() and .abort() functions in quick succession, to prevent abuse we are implementing a minimum amount of time to display the payment sheet (thus making it impossible for a website to trick a user into sharing this information).<br />
<br />
== Fingerprinting ==<br />
<br />
During an [https://blog.lukaszolejnik.com/privacy-of-web-request-api/ early privacy review] of the Payment Request API, Lukasz Olejnik raised concerns about the ability of website scripts to "fingerprint" a user by repeatedly using the .canMakePayment() call to determine which payment methods and payment instruments the user has installed. To mitigate this risk, Firefox allows the .canMakePayment() call only in top-level browsing contexts and only after the user "gestures" to allow .show() from the website. Furthermore, Firefox matches only on installed payment handlers or supported payment methods (e.g., basic-card or Apple Pay), not on card networks (e.g., Visa or Amex).<br />
<br />
== Private Browsing Mode ==<br />
<br />
In [[Private_Browsing private browsing mode]], several additional protections are in place:<br />
<br />
* By default, Firefox does not save credit card data, shipping and billing addresses, etc.<br />
* Firefox does not remember the last credit card and shipping address used at this website.<br />
* Firefox does not send user data to the website without user consent.<br />
* Firefox does not update storage metadata.<br />
* Firefox does not allow the website to discover whether private browsing mode is enabled.<br />
<br />
== Process Separation ==<br />
<br />
To help mitigate against cross-site scripting attacks and Spectre-related vulnerabilities, care has been taken to implement the Payment Request dialog in a separate process from the process that handles credit card data (see {{bug|1460425|Bug 1460425}}).<br />
<br />
== Data Validation ==<br />
<br />
As part of the Payment Request API, the merchant website can provide certain untrusted strings to the browser; these include:<br />
<br />
* PaymentItem label values (e.g., products in a shopping cart)<br />
* The web origin of the merchant website (which could include mixed scripts or bidirectional domain labels)<br />
* Error strings, especially generic error message<br />
<br />
Firefox should validate and sanitize all untrusted strings, for instance by limiting the display length (e.g., truncate to 64 bytes or fewer, as is done for relying part names in the [https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API Web Authentication API]).<br />
<br />
== User Interaction ==<br />
<br />
Navigations away from a page showing a Payment Request dialog either should be prevented or the dialog should abort.<br />
<br />
We should prevent attacks where the user is tricked into interacting with the Payment Request dialog (e.g., clickjacking), probably by implementing a security delay on the "pay" button (i.e., the button that invokes the .show() call).<br />
<br />
An abusive website could repeatedly invoke the payment request dialog and thus hold the user hostage until they pay. To prevent this, the proposed design will allow the user to close the whole tab while the Payment Request dialog is open.<br />
<br />
== Open Issues ==<br />
<br />
* What happens if the dialog appears during DOM or UI fullscreen?<br />
* What happens if the dialog appears in different variants of popup windows? (consider window.open features)<br />
<br />
== Privacy and Security Roadmap ==<br />
<br />
Future features will likely include:<br />
<br />
* Support for tokenized credit card data (e.g., via the [https://w3c.github.io/webpayments-methods-tokenization/ W3C Tokenized Card Payment Method]) so that credit card numbers are not sent from the browser to the merchant; instead, the browser sends a payment authorization token.<br />
<br />
* Support for stronger encryption of payment requests and responses using a standardized approach such as the emerging [https://rawgit.com/w3c/webpayments-crypto/gh-pages/ W3C Payment Method Encryption] proposal.<br />
<br />
* Reliance on underlying adjustments in Firefox to address issues such as timing-related side channel attacks (e.g., using process-per-origin separation).</div>Stpeter