https://wiki.mozilla.org/api.php?action=feedcontributions&user=MrElvey&feedformat=atomMozillaWiki - User contributions [en]2024-03-28T09:20:35ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=User_talk:MrElvey&diff=1228293User talk:MrElvey2020-06-21T04:12:22Z<p>MrElvey: Created page with "Hi! I'm MrElvey. How are you?"</p>
<hr />
<div>Hi! I'm MrElvey. How are you?</div>MrElveyhttps://wiki.mozilla.org/index.php?title=User_talk:Wthayer&diff=1224884User talk:Wthayer2020-03-10T00:09:31Z<p>MrElvey: /* "contractually agreed"?? */ To-Do</p>
<hr />
<div>'''Welcome to ''MozillaWiki''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:SpikeUK1|SpikeUK1]] ([[User talk:SpikeUK1|talk]]) 19:41, 28 November 2017 (UTC)<br />
<br />
== "contractually agreed"?? ==<br />
<br />
Re. [https://wiki.mozilla.org/index.php?title=Security/DOH-resolver-policy&diff=1221445&oldid=1218678 your edit]. I see ''promises'' in the policies. I don't see anything ''contractually agreed'' to; there's [https://www.google.com/search?client=firefox-b-1-d&q=%22contract+law%22+privacy+policy no contract]. Agreed? Or are there contracts <nowiki>({{fact}})</nowiki>? --[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 23:27, 3 January 2020 (UTC)<br />
<br />
:There are legal contracts executed between Mozilla and those listed providers.<br />
<br />
:: And that's documented? Let's add links? I'd guess the documentation is in bugzilla; I recall that's where the documentation re CAs (Certificate Authorities) is found.--[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 08:04, 6 January 2020 (UTC)<br />
::I couldn't find any. Also, if documented, then network.trr.resolvers should be updated in the mainline to include the two providers.--[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 23:09, 9 March 2020 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=User_talk:Wthayer&diff=1224881User talk:Wthayer2020-03-09T23:09:31Z<p>MrElvey: /* "contractually agreed"?? */ ?</p>
<hr />
<div>'''Welcome to ''MozillaWiki''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:SpikeUK1|SpikeUK1]] ([[User talk:SpikeUK1|talk]]) 19:41, 28 November 2017 (UTC)<br />
<br />
== "contractually agreed"?? ==<br />
<br />
Re. [https://wiki.mozilla.org/index.php?title=Security/DOH-resolver-policy&diff=1221445&oldid=1218678 your edit]. I see ''promises'' in the policies. I don't see anything ''contractually agreed'' to; there's [https://www.google.com/search?client=firefox-b-1-d&q=%22contract+law%22+privacy+policy no contract]. Agreed? Or are there contracts <nowiki>({{fact}})</nowiki>? --[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 23:27, 3 January 2020 (UTC)<br />
<br />
:There are legal contracts executed between Mozilla and those listed providers.<br />
<br />
:: And that's documented? Let's add links? I'd guess the documentation is in bugzilla; I recall that's where the documentation re CAs (Certificate Authorities) is found.--[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 08:04, 6 January 2020 (UTC)<br />
::I couldn't find any.--[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 23:09, 9 March 2020 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Security/DOH-resolver-policy&diff=1224880Security/DOH-resolver-policy2020-03-09T23:08:09Z<p>MrElvey: /* Conforming Resolvers */ We can't find or obtain documentation of this.</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/commitment-to-privacy/privacy-policy/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>MrElveyhttps://wiki.mozilla.org/index.php?title=User_talk:Wthayer&diff=1221836User talk:Wthayer2020-01-06T08:05:07Z<p>MrElvey: /* "contractually agreed"?? */ r/?</p>
<hr />
<div>'''Welcome to ''MozillaWiki''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:SpikeUK1|SpikeUK1]] ([[User talk:SpikeUK1|talk]]) 19:41, 28 November 2017 (UTC)<br />
<br />
== "contractually agreed"?? ==<br />
<br />
Re. [https://wiki.mozilla.org/index.php?title=Security/DOH-resolver-policy&diff=1221445&oldid=1218678 your edit]. I see ''promises'' in the policies. I don't see anything ''contractually agreed'' to; there's [https://www.google.com/search?client=firefox-b-1-d&q=%22contract+law%22+privacy+policy no contract]. Agreed? Or are there contracts <nowiki>({{fact}})</nowiki>? --[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 23:27, 3 January 2020 (UTC)<br />
<br />
:There are legal contracts executed between Mozilla and those listed providers.<br />
<br />
:: And that's documented? Let's add links? I'd guess the documentation is in bugzilla; I recall that's where the documentation re CAs (Certificate Authorities) is found.--[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 08:04, 6 January 2020 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Trusted_Recursive_Resolver&diff=1221835Trusted Recursive Resolver2020-01-06T08:01:15Z<p>MrElvey: "typically the same speed..." != improved. Add more info.</p>
<hr />
<div>DNS-over-HTTPS (DoH) allows DNS to be resolved with enhanced privacy, secure<br />
transfers and [https://blog.mozilla.org/futurereleases/2019/07/31/dns-over-https-doh-update-detecting-managed-networks-and-user-choice/ comparable] performance. This page describes Firefox configuration settings related to DoH in detail, and offers some explanation of internal operations of the implementation.<br />
<br />
Mozilla operates a Trusted Recursive Resolver program, whose requirements are documented at [[Security/DOH-resolver-policy]]. All TRRs offered by Firefox conform to the requirements described in the policy, but not vice versa(<!--NextDNS not 'offered' but I understand that it conforms.-->).<br />
<br />
For more information, we've created [https://support.mozilla.org/en-US/kb/firefox-dns-over-https documentation about DoH and our plans for deployment]. We also have an [https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs FAQ], and instructions for [https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https network operators who wish to disable DoH on their networks]. <br />
<br />
== DNS-over-HTTPS Settings in Firefox ==<br />
<br />
All preferences for the DNS-over-HTTPS functionality in Firefox are located under the `network.trr` prefix (TRR == Trusted Recursive Resolver). The support for these were added in Firefox 62.<br />
<br />
=== network.trr.mode ===<br />
The resolver mode. You should not change the mode manually, instead use the UI in the Network Settings section of about:preferences<br />
<br />
* 0 - Off (default). use standard native resolving only (don't use TRR at all)<br />
* 1 - Reserved (used to be Race mode)<br />
* 2 - First. Use TRR first, and only if the name resolve fails use the native resolver as a fallback.<br />
* 3 - Only. Only use TRR. Never use the native (This mode also requires the bootstrapAddress pref to be set)<br />
* 4 - Reserved (used to be Shadow mode)<br />
* 5 - Off by choice. This is the same as 0 but marks it as done by choice and not done by default.<br />
<br />
=== network.trr.uri ===<br />
<br />
(default: none) set the URI for your DoH server. That's the URL Firefox will issue its HTTP request to. It must be a HTTPS URL. If "useGET" is enabled, Firefox will append "?dns=...." to the URI when it makes its HTTP requests. For the default POST requests, they will be issued to exactly the specified URI.<br />
<br />
Publicly announced servers include:<br />
* https://mozilla.cloudflare-dns.com/dns-query<br />
* https://dns.google/dns-query<br />
<br />
For more servers, see this unofficial list of DoH servers: https://github.com/curl/curl/wiki/DNS-over-HTTPS.<br />
<br />
===network.trr.credentials===<br />
<br />
(default: none) set credentials that will be used in the HTTP requests to the DoH end-point. It is the right-hand side content, the value, sent in the Authorization: request header.<br />
<br />
=== network.trr.wait-for-portal ===<br />
<br />
(default: false) set this boolean to **true** to tell Firefox to wait for the captive portal detection before TRR is used. (on Android, this will default to **false** since the captive portal handling is done outside of Firefox, by the OS itself.)<br />
<br />
=== network.trr.allow-rfc1918 ===<br />
<br />
(default: false) set this to true to allow RFC 1918 private addresses in TRR responses. When set to false, any such response will be considered invalid and won't be used.<br />
<br />
=== network.trr.useGET ===<br />
<br />
(default: false) When the browser issues a request to the DoH server to resolve host names, it can do that using POST or GET. By default Firefox will use POST, but by toggling this you can enforce GET to be used instead.<br />
<br />
=== network.trr.confirmationNS ===<br />
<br />
(default: example.com) Firefox will check an NS entry at startup to verify that TRR works to ensure proper configuration. This preference sets which domain to check. The verification only checks for a positive answer, it doesn't actually care what the response data says. Set this to `skip` to completely avoid confirmation.<br />
<br />
=== network.trr.bootstrapAddress ===<br />
<br />
(default: none) by setting this field to the IP address of the host name used in "network.trr.uri", you can bypass using the system native resolver for it.<br />
Use this to get the IPs of the cloudflare server: https://dns.google/query?name=mozilla.cloudflare-dns.com<br />
<br />
=== network.trr.blacklist-duration ===<br />
<br />
(default: 60) is the number of seconds a name will be kept in the TRR blacklist until it expires and then will be tried with TRR again. The default duration is one minute.<br />
<br />
Entries are added to the TRR blacklist when the resolution fails with TRR but works with the native resolver, or if the subsequent connection with a TRR resolved host name fails but works with a retry that is resolved natively. When a hostname is added to the TRR, its domain gets checked in the background to see if the whole domain should be blacklisted to ensure a smoother ride going forward.<br />
<br />
=== network.trr.request_timeout_ms ===<br />
<br />
(default: 1500) is the number of milliseconds a request and the corresponding response from the DoH server is allowed to take until considered failed and discarded.<br />
<br />
=== network.trr.request_timeout_mode_trronly_ms ===<br />
<br />
(default: 30000) is the number of milliseconds a request and the corresponding response from the DoH server is allowed to take until considered failed and discarded in TRR-only mode.<br />
<br />
=== network.trr.early-AAAA ===<br />
<br />
(default: false) For each normal name resolution, Firefox issues one HTTP request for A entries and another for AAAA entries. The responses come back separately and can come in any order. If the A records arrive first, Firefox will—as an optimization— continue and use them without waiting for the second response. If the AAAA records arrive first, Firefox will only continue and use them immediately if this option is set to **true**.<br />
<br />
=== network.trr.skip-AAAA-when-not-supported ===<br />
<br />
(default: true) If Firefox detects that your system does not have IPv6 connectivity, it will not request IPv6 addresses from the DoH server.<br />
<br />
=== network.trr.max-fails ===<br />
<br />
(default: 5) If this many DoH requests fail in a row, consider TRR broken and go back to verify-NS state. This is meant to detect situations when the DoH server dies.<br />
<br />
=== network.trr.disable-ECS ===<br />
<br />
(default: true) If set, TRR asks the resolver to disable ECS (EDNS Client Subnet: the method where the resolver passes on the subnet of the client asking the question). Some resolvers will use ECS to the upstream if this request is not passed on to them.<br />
<br />
=== network.trr.excluded-domains ===<br />
<br />
(default: ``) Comma separated list of domain names to be resolved using the native resolver instead of TRR. Users may add domains they wish to exclude from TRR to this pref.<br />
<br />
<br />
=== network.trr.builtin-excluded-domains ===<br />
<br />
(default: `localhost,local`) Comma separated list of domain names to be resolved using the native resolver instead of TRR. The host of the captive portal detection is also added to the exclusion list internally, in order to be able to detect local captive portals. Users should change this pref as it may get overwritten by changes to the default values.<br />
<br />
== Dynamic Blacklist ==<br />
<br />
To keep the failure rate at a minimum, the TRR system manages a dynamic<br />
persistent blacklist for host names that can't be resolved with DOH but works<br />
with the native resolver. Blacklisted entries will not be retried over DOH for<br />
a couple of days. "localhost" and names in the ".local" TLD will never be<br />
resolved via DOH.<br />
<br />
When TRR starts up, it will first verify that it works by first checking a<br />
"confirmation" domain name. This confirmation domain is a pref by default set<br />
to "example.com".<br />
<br />
== Notes ==<br />
<br />
=== DNS ===<br />
<br />
TRR bypasses system DNS so you might not be using any 'enhanced' DNS services provided by your default DNS server which may include Web Content Filtering or basic Malware Protection, phishing protection.<br />
<br />
== See also ==<br />
<br />
* Initial ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1434852<br />
* The DNS-over-HTTPS spec: https://tools.ietf.org/html/rfc8484<br />
<br />
* https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https</div>MrElveyhttps://wiki.mozilla.org/index.php?title=User_talk:Wthayer&diff=1221814User talk:Wthayer2020-01-03T23:27:28Z<p>MrElvey: /* "contractually agreed"?? */ new section</p>
<hr />
<div>'''Welcome to ''MozillaWiki''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:SpikeUK1|SpikeUK1]] ([[User talk:SpikeUK1|talk]]) 19:41, 28 November 2017 (UTC)<br />
<br />
== "contractually agreed"?? ==<br />
<br />
Re. [https://wiki.mozilla.org/index.php?title=Security/DOH-resolver-policy&diff=1221445&oldid=1218678 your edit]. I see ''promises'' in the policies. I don't see anything ''contractually agreed'' to; there's [https://www.google.com/search?client=firefox-b-1-d&q=%22contract+law%22+privacy+policy no contract]. Agreed? Or are there contracts <nowiki>({{fact}})</nowiki>? --[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 23:27, 3 January 2020 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Media/WebRTC/Privacy&diff=1221810Media/WebRTC/Privacy2020-01-03T23:16:26Z<p>MrElvey: /* Address leakage and VPNs */</p>
<hr />
<div>This page gathers information related to privacy in WebRTC. This is a Work-In-Progress and more categories need to be added.<br />
<br />
Note: this page is for documenting options, not for discussion.<br />
<br />
==Address leakage and VPNs==<br />
<br />
===Undocumented===<br />
A lot has yet to be documented, and a lot has been and has yet to be implemented.<br />
In the vacuum, prefs like media.peerconnection.ice.proxy_only_if_behind_proxy are getting 'documented' like [https://www.reddit.com/r/firefox/comments/8hjh3h/google_voice_psa_if_you_have_been_recently_having/ this].<br />
<br />
===Test===<br />
* a [https://diafygi.github.io/webrtc-ips/ test for WebRTC leaks] (partial?)<br />
<br />
===Prefs that control ICE Candidate generation===<br />
All of these can be set from about:config, or controlled via an extension<br />
* '''media.peerconnection.ice.force_interface''' -- string (default "") -- interface name to match for ICE (Firefox 43, uplifted to 42, requested for 41) -- {{Bug|1189040}}<br />
** If set, and there is no interface that matches exactly, '''NO''' candidates will be generated<br />
** If set and there is a match, that interface will be used solely for ICE. Local (LAN) and external IP addresses for that interface will be used for ICE candidates. This can be pointed at a single external interface to hide/ignore internal (VM) interfaces, unconnected interfaces or VPNs (e.g. work VPNs). It can also be set to a VPN interface, and then ICE will only use the VPN (and if the VPN is down, ICE will fail).<br />
* '''media.peerconnection.ice.relay_only''' - boolean (default false) -- only generate relay (TURN) candidates for ICE (Firefox 42) -- {{Bug|1189030}}<br />
** This can be used to block all local (LAN) and external IP addresses from being generated as candidates.<br />
** An example use-case would be avoiding exposing your external IP address to a caller (such as when avoiding disclosing you're in town Xxxxx when having a call with someone you have a protection order against; roughly the equivalent of blocking outgoing caller-id on the PSTN bug *-whatever)<br />
** NOTE: does not hide your external IP address from the TURN server itself (see use_document_iceservers and default_iceservers to restrict to a TURN of your choice).<br />
* '''media.peerconnection.use_document_iceservers''' -- boolean (default true) -- use STUN/TURN servers provided by the page (all recent Firefox versions)<br />
** If set to false and '''media.peerconnection.default_iceservers''' is set to the server(s) you want to use, only those servers will be used, and no server provided by the page will be used.<br />
** This can be useful for corporate 'gateway' TURN servers, or for a TURN server hosted by a VPN provider.<br />
* '''media.peerconnection.ice.default_address_only''' -- boolean (default false) -- limit ICE candidates to the default interface only (Firefox 43, uplifted to 42) -- {{Bug|1189041}}<br />
** The default interface used for general routing is identified and only that address is used for candidate generation<br />
** LAN IP addresses are not generated, the external IP address for that interface is (for a VPN, the exit portal of the VPN)<br />
** If your router does not support 'hairpinning', a within-LAN call will end up being routed through an external TURN server<br />
* '''media.peerconnection.ice.no_host''' -- boolean (default false) -- eliminate all local addresses from the candidates (Firefox 51) -- {{Bug|1297416}}<br />
* '''media.peerconnection.enabled''' -- boolean (default true) -- enables/disabled ability to create RTCPeerConnection objects (all recent Firefox versions)<br />
<br />
For easier comparison of the different options:<br />
{| class="wikitable"<br />
|-<br />
! Pref !! Local candidates !! External candidates !! Relay candidates !! No candidates !! Interfaces gathered<br />
|-<br />
| force_interface || Yes || Yes || Yes || If pointing to non-existing interface || Only the configured interface<br />
|-<br />
| relay_only || No || No || Yes || If no TURN server is provided || All interfaces will be used to try to connect to the relay<br />
|-<br />
| use_document_iceservers || Yes || Yes || Yes || N/A || All interfaces will be used to try to connect to the relay<br />
|-<br />
| default_address_only || Yes || Yes || Yes || N/A || Only the interface with the default route<br />
|-<br />
| no_host || No || Yes || Yes || N/A || All interfaces will be used<br />
|-<br />
| peerconnection.enabled || No || No || No || Always || N/A<br />
|}<br />
Note 1: the comments in the table assume that the pref in each row has been altered from its default value.<br /><br />
Note 2: 'External candidates = Yes' always requires a STUN server to be configured. <br /><br />
Note 3: 'Relay candidate = Yes' always a TURN server to be configured. <br /><br />
<br />
===Hooks to control access to createOffer/createAnswer===<br />
With the removal of old-style add-ons in Firefox 57, the following information is no longer applicable. An equivalent WebExtensions API is under development, but not yet complete. See {{Bug|1281833}} for details.<br />
<br />
<s>Firefox 43 (uplifted to 42) supports hooks that allow an extension to allow or deny calls to createOffer and createAnswer -- {{Bug|1189060}}<br />
<nowiki><br />
// Add-ons can override stock permission behavior by doing:<br />
//<br />
// var stockObserve = WebrtcUI.observe;<br />
//<br />
// webrtcUI.observe = function(aSubject, aTopic, aData) {<br />
// switch (aTopic) {<br />
// case "PeerConnection:request": {<br />
// // new code.<br />
// break;<br />
// ...<br />
// default:<br />
// return stockObserve.call(this, aSubject, aTopic, aData);<br />
//<br />
// See browser/modules/webrtcUI.jsm for detail</nowiki><br />
<br />
Example extension: http://hancke.name/tmp/verhueterli.xpi (source: https://github.com/fippo/plumber). Note: unsigned extensions require flipping a pref to use (and can't be used in Beta 41).</s></div>MrElveyhttps://wiki.mozilla.org/index.php?title=Media/WebRTC&diff=1221807Media/WebRTC2020-01-03T23:00:18Z<p>MrElvey: /* Contacts and Useful Links */</p>
<hr />
<div>WebRTC is a free, open project that brings peer-to-peer real-time audio, video and data to the web without plugins, using open web [[standards]]. Checkout the [http://www.webrtc.org/ WebRTC project page] set up by Google for interesting links and details. <br />
<br />
==Releases & Notes==<br />
*[https://wiki.mozilla.org/RapidRelease/Calendar Firefox Release Schedule Calendar]<br />
*[https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes Firefox WebRTC & Web Audio Release Notes]<br />
<br />
===Triage Guidelines===<br />
The Product Backlog is continually maintained to ensure relative priorities are understood. <br />
<br />
* Priorities follow the Firefox Desktop Standard:<br />
Go to [https://wiki.mozilla.org/Media/Bugs#WebRTC_Bugzilla_Queries WebRTC bugs] to search for all open WebRTC bugs (including untriaged and unconfirmed bugs).<br />
<br />
** Priority 1 - Blocker, must-fix before shipping. Almost by definition of P1, the "affected" flags and "tracking" flags for the bug should be set when it's triaged. <br />
** Priority 2 - High priority backlog (bugs we are currently working on or will be working on next)<br />
** Priority 3 - Lower priority backlog <br />
** Priority 4 - Bugs we will accept patches for<br />
** Priority 5 - Parking lot (Bugs we do not plan to spend any time on)<br />
<br />
*RANK: The Rank field lets us prioritize bugs within a priority bucket (P2, P3, etc) in bugzilla. To have some rhyme/reason to the order - Rank should relate to Priority. The "Ranking" number does not need to be unique. Unless there is a reason to for a bug to be considered before (or after) others in the Priority bucket - the triager will default to mid-range value.<br />
** P1 Rank options=0-9, default 5<br />
** P2 Rank options=10-19, default 15<br />
** P3 Rank options=20-29, default 25<br />
** P4 Rank options=30-39, default 35<br />
** P5 Rank options=40-49, default 45<br />
*** Note: P5 and "parking-lot"-labelled bugs are treated identically. We no longer use "parking-lot"; it is a legacy classification.<br />
<br />
<p> </p><br />
*QE-Verify is a flag that developers should be setting. QE uses to filter which bugs they check.<br />
**"+" means that QE should look at the bug and it can be verified with human eyes<br />
**"-" means QE should not look at<br />
***Typically QE-verify"-" goes with "in-testsuite" being set to "+", to show testing via another method.<br />
<br />
===Filing a bug===<br />
* Open a bug under Product:"Core" || Component: "WebRTC, WebRTC:Audio, WebRTC:Network or WebRTC:Signaling"<br />
** After triage, bugs will be marked "firefox-blocking", with a Priority, and a Rank<br />
*If there is a bug that should be considered for taking ASAP - you can mark "firefox-backlog"+<br />
**Before it can be given a Rank it should:<br />
*** be in an actionable state<br />
*** for defects, the problem is ready for Engineering or UX: diagnosis, measurement, design, or fixing<br />
*** for feature requests or enhancements, it means that there's a clear problem statement or suggestion<br />
*** has a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months<br />
<p> </p><br />
<br />
'''Contributor Engagement'''<br />
* Add Whiteboard tag of [well filed] to the well filed bugs to acknowledge that we appreciate the effort and thoroughness<br />
* Add Whiteboard tag of [good first bug] for contributors to pick up<br />
<br />
==Project Status ==<br />
*[https://mozilla.aha.io/published/b40393012432847d857ee68299a8a82f?page=2 Detailed Roadmap], noting that the further out the more lose the targets are]<br />
<br />
==Contacts and Useful Links==<br />
*[https://mozilla.github.io/webrtc-landing/gum_test.html Click here] to try WebRTC features in the Firefox browser<br />
*[https://wiki.mozilla.org/Webrtc/contacts Contacts for WebRTC]<br />
*[https://wiki.mozilla.org/Webrtc/links Useful Links for WebRTC]<br />
*[https://wiki.mozilla.org/Media/WebRTC/Tests Running tests for WebRTC in Firefox]<br />
*[https://wiki.mozilla.org/Media/WebRTC/Logging Getting WebRTC logs in Firefox]<br />
*[https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04 IETF Draft: "Using ''Multicast DNS'' to protect '''privacy''' when exposing ''ICE'' candidates"] (AKA mDNS; Interactive Connectivity Establishment (ICE) [RFC 5245] protocol)<br />
*[[Media/WebRTC/Privacy]] <br />
*[[Media/WebRTC/Architecture]] <br />
*[https://wiki.mozilla.org/index.php?search=Media%2FWebRTC%2F&title=Special%3ASearch&fulltext=1 etc.]<br />
<br />
==Meetings==<br />
<p> </p><br />
{| class="wikitable"<br />
|-<br />
! Meeting !! Day of week !! Pacific Time !! Eastern Time !! Central European Time !! Vidyo Room !! Notes<br />
|-<br />
| "Weekly Stand-up" || Wednesday || 6:00AM - 6:30AM & 1:30 - 2:00 PM || 9:00AM - 9:30PM & 4:30 - 5:00 PM || 3:00PM - 3:30PM & - 10:30PM-11:00PM || webRTC-Apps || [https://etherpad.mozilla.org/webrtcweekly etherpad]<br />
|-<br />
|}<br />
* Stand-up = 2 minutes on what have you been working on, planning to work on, and are you blocked. Bring-up topics for longer Discussion at end if needed.<br />
** Developers and active contributors only need to attend one of the two sessions each week. We have 2 sessions due to the number of very different time zones throughout the team.<br />
** please update the [https://etherpad.mozilla.org/webrtcweekly Stand-up Notes etherpad] if you cannot make the meeting (even if it's just to say you're on PTO)<br />
* [http://ietf.org/ IETF Standards Meetings]<br />
<br />
==Archived==<br />
===Notes===<br />
*[https://wiki.mozilla.org/Media/WebRTC/archived Archived notes]<br />
<br />
<br />
<br />
----</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Media/WebRTC&diff=1221805Media/WebRTC2020-01-03T22:58:44Z<p>MrElvey: Seems like we should link to these - activity ongoing, e.g. Lots of Bug 1544770 activity. Documentation, etc needed re. privacy - incl. competitive advantage.</p>
<hr />
<div>WebRTC is a free, open project that brings peer-to-peer real-time audio, video and data to the web without plugins, using open web [[standards]]. Checkout the [http://www.webrtc.org/ WebRTC project page] set up by Google for interesting links and details. <br />
<br />
==Releases & Notes==<br />
*[https://wiki.mozilla.org/RapidRelease/Calendar Firefox Release Schedule Calendar]<br />
*[https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes Firefox WebRTC & Web Audio Release Notes]<br />
<br />
===Triage Guidelines===<br />
The Product Backlog is continually maintained to ensure relative priorities are understood. <br />
<br />
* Priorities follow the Firefox Desktop Standard:<br />
Go to [https://wiki.mozilla.org/Media/Bugs#WebRTC_Bugzilla_Queries WebRTC bugs] to search for all open WebRTC bugs (including untriaged and unconfirmed bugs).<br />
<br />
** Priority 1 - Blocker, must-fix before shipping. Almost by definition of P1, the "affected" flags and "tracking" flags for the bug should be set when it's triaged. <br />
** Priority 2 - High priority backlog (bugs we are currently working on or will be working on next)<br />
** Priority 3 - Lower priority backlog <br />
** Priority 4 - Bugs we will accept patches for<br />
** Priority 5 - Parking lot (Bugs we do not plan to spend any time on)<br />
<br />
*RANK: The Rank field lets us prioritize bugs within a priority bucket (P2, P3, etc) in bugzilla. To have some rhyme/reason to the order - Rank should relate to Priority. The "Ranking" number does not need to be unique. Unless there is a reason to for a bug to be considered before (or after) others in the Priority bucket - the triager will default to mid-range value.<br />
** P1 Rank options=0-9, default 5<br />
** P2 Rank options=10-19, default 15<br />
** P3 Rank options=20-29, default 25<br />
** P4 Rank options=30-39, default 35<br />
** P5 Rank options=40-49, default 45<br />
*** Note: P5 and "parking-lot"-labelled bugs are treated identically. We no longer use "parking-lot"; it is a legacy classification.<br />
<br />
<p> </p><br />
*QE-Verify is a flag that developers should be setting. QE uses to filter which bugs they check.<br />
**"+" means that QE should look at the bug and it can be verified with human eyes<br />
**"-" means QE should not look at<br />
***Typically QE-verify"-" goes with "in-testsuite" being set to "+", to show testing via another method.<br />
<br />
===Filing a bug===<br />
* Open a bug under Product:"Core" || Component: "WebRTC, WebRTC:Audio, WebRTC:Network or WebRTC:Signaling"<br />
** After triage, bugs will be marked "firefox-blocking", with a Priority, and a Rank<br />
*If there is a bug that should be considered for taking ASAP - you can mark "firefox-backlog"+<br />
**Before it can be given a Rank it should:<br />
*** be in an actionable state<br />
*** for defects, the problem is ready for Engineering or UX: diagnosis, measurement, design, or fixing<br />
*** for feature requests or enhancements, it means that there's a clear problem statement or suggestion<br />
*** has a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months<br />
<p> </p><br />
<br />
'''Contributor Engagement'''<br />
* Add Whiteboard tag of [well filed] to the well filed bugs to acknowledge that we appreciate the effort and thoroughness<br />
* Add Whiteboard tag of [good first bug] for contributors to pick up<br />
<br />
==Project Status ==<br />
*[https://mozilla.aha.io/published/b40393012432847d857ee68299a8a82f?page=2 Detailed Roadmap], noting that the further out the more lose the targets are]<br />
<br />
==Contacts and Useful Links==<br />
*[https://mozilla.github.io/webrtc-landing/gum_test.html Click here] to try WebRTC features in the Firefox browser<br />
*[https://wiki.mozilla.org/Webrtc/contacts Contacts for WebRTC]<br />
*[https://wiki.mozilla.org/Webrtc/links Useful Links for WebRTC]<br />
*[https://wiki.mozilla.org/Media/WebRTC/Tests Running tests for WebRTC in Firefox]<br />
*[https://wiki.mozilla.org/Media/WebRTC/Logging Getting WebRTC logs in Firefox]<br />
*[https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04 IETF Draft: "Using Multicast DNS to protect '''privacy''' when exposing ICE candidates"] (AKA mDNS; Interactive Connectivity<br />
Establishment (ICE) [RFC5245] protocol)<br />
*[[Media/WebRTC/Privacy]] <br />
*[[Media/WebRTC/Architecture]] <br />
*[https://wiki.mozilla.org/index.php?search=Media%2FWebRTC%2F&title=Special%3ASearch&fulltext=1 etc.]<br />
<br />
<br />
==Meetings==<br />
<p> </p><br />
{| class="wikitable"<br />
|-<br />
! Meeting !! Day of week !! Pacific Time !! Eastern Time !! Central European Time !! Vidyo Room !! Notes<br />
|-<br />
| "Weekly Stand-up" || Wednesday || 6:00AM - 6:30AM & 1:30 - 2:00 PM || 9:00AM - 9:30PM & 4:30 - 5:00 PM || 3:00PM - 3:30PM & - 10:30PM-11:00PM || webRTC-Apps || [https://etherpad.mozilla.org/webrtcweekly etherpad]<br />
|-<br />
|}<br />
* Stand-up = 2 minutes on what have you been working on, planning to work on, and are you blocked. Bring-up topics for longer Discussion at end if needed.<br />
** Developers and active contributors only need to attend one of the two sessions each week. We have 2 sessions due to the number of very different time zones throughout the team.<br />
** please update the [https://etherpad.mozilla.org/webrtcweekly Stand-up Notes etherpad] if you cannot make the meeting (even if it's just to say you're on PTO)<br />
* [http://ietf.org/ IETF Standards Meetings]<br />
<br />
==Archived==<br />
===Notes===<br />
*[https://wiki.mozilla.org/Media/WebRTC/archived Archived notes]<br />
<br />
<br />
<br />
----</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Labs/Ubiquity&diff=1218693Labs/Ubiquity2019-10-07T19:46:33Z<p>MrElvey: +archive Abi, Zach. (was looking for spam, found these instead, so added)</p>
<hr />
<div>Back to [[Labs]].<br />
<br />
= What is Ubiquity? =<br />
<br />
Ubiquity was a Mozilla Labs experiment that was in development from 2008 to 2009. Its purpose was to explore whether a radically different type of interface to the Web — a task-centric, natural-language-based command line — could help us get common Web tasks done faster.<br />
<br />
Development is currently on indefinite hiatus. We will most likely revisit the experiment at some point in the future. In the meantime, the Ubiquity extension for Firefox is still available for download (see below). Also, some of the ideas from Ubiquity are being implemented in [[Labs/Jetpack|Jetpack]].<br />
<br />
You can learn more about Ubiquity by reading Atul's blog post entitled [http://www.toolness.com/wp/?p=54 Ubiquitous Interfaces, Ubiquitous Functionality], or try it out via the [[Labs/Ubiquity/Latest Ubiquity User Tutorial|User Tutorial]].<br />
<br />
Other informative blog posts about Ubiquity include:<br />
# [http://www.toolness.com/wp/?p=64 Trusting Functionality] by Atul<br />
# [http://www.azarask.in/blog/post/can-ubiquity-be-used-only-with-the-mouse/ Mouse-Based Ubiquity]<br />
# [http://azarask.in/blog/post/sharing-streamable-functionality/ Sharing Streamable Functionality] by Aza<br />
# [http://jonoscript.wordpress.com/2008/07/21/language-based-interfaces-part-1-the-problem/ Language-Based Interfaces, part 1: The Problem] by Jono<br />
# [http://jonoscript.wordpress.com/2008/07/25/our-presentation-at-labs-night/ Our Presentation at Labs Night] by Jono<br />
# [http://jonoscript.wordpress.com/2008/07/26/why-verbs/ Why Verbs?] by Jono<br />
# [[Labs/Ubiquity/Selected Press|Selected Press]]<br />
<br />
= Install =<br />
<br />
== For Firefox 14.0 and up ==<br />
<br />
[https://addons.mozilla.org/addon/9527 Install Ubiquity 0.6.2 for Firefox 14 and up]<br />
<br />
[https://bitbucket.org/satyr/ubiquity/downloads/tip.xpi Install the latest beta of Ubiquity] - Maintained by community member Satyr<br />
<br />
<br />
== For Older Versions of Firefox ==<br />
<br />
[https://ubiquity.mozilla.com/xpi/ubiquity-latest.xpi Install latest version of Ubiquity for Firefox 3.5]<br />
<br />
[https://ubiquity.mozilla.com/xpi/ubiquity-latest-beta.xpi Install the latest beta of Ubiquity for Firefox 3.5]<br />
<br />
[https://ubiquity.mozilla.com/xpi/ Install older versions (if the current version is breaking for you)]<br />
<br />
= Participation =<br />
# [http://groups.google.com/group/ubiquity-firefox General Google Group/mailing list] - Useful for discussion of command development, user interface, feature suggestions, and other high-level discussions.<br />
# [http://groups.google.com/group/ubiquity-core Core Google Group/mailing list] - Discussion of low-level internals of Ubiquity.<br />
# [http://getsatisfaction.com/mozilla/products/mozilla_ubiquity Get Satisfaction - Ideas, Complaints, Forum, and "Customer Service"]<br />
# [irc://irc.mozilla.org/ubiquity #ubiquity irc.mozilla.org] - Live internet relay chat discussion.<br />
# [http://ubiquity.mozilla.com/trac/search?q=good-for-beginners Good-for-beginners bugs] - bug tickets which may be good for a Ubiquity beginner to attack<br />
# [[Labs/Ubiquity/Frequently Encountered Bugs|Frequently Encountered Bugs]] - bugs that get reported a lot on the [http://groups.google.com/group/ubiquity-firefox mailing list] and [http://getsatisfaction.com/mozilla/products/mozilla_ubiquity Get Satisfaction] that would make lots of people happy if they got fixed<br />
# [[Labs/Ubiquity/Commands In The Wild|Commands In The Wild]] Add links to your commands here.<br />
# [https://ubiquity.mozilla.com/trac/report/1 Issue Tracker] - Used to report/discuss bugs and submit patches for Ubiquity.<br />
# [[Labs/Ubiquity/Trac Components and Keywords|Trac Components and Keywords]] - Keywords and categories to use when filing Trac tickets.<br />
# [https://ubiquity.mozilla.com/hg/ubiquity-firefox/ Ubiquity HG Repository] - The Mercurial source code repository for Ubiquity.<br />
# [http://ubiquity.mozilla.com/buildbot/ Buildbot] - Continuous integration that runs Ubiquity unit tests after every commit. If the tests fail, they're reported immediately to the mailing list.<br />
# [[Labs/Ubiquity/Credits|Credits]]<br />
<br />
= Meetings =<br />
<br />
* [[Labs/Ubiquity/Meetings|Meeting notes & times]]<br />
<br />
= Documentation =<br />
# [[Labs/Ubiquity/Latest Ubiquity User Tutorial|Ubiquity User Tutorial]] <br />
# The latest [[Labs/Ubiquity/Ubiquity_Source_Tip_Author_Tutorial|Command Authoring Tutorial]] (for command authors using a Ubiquity source checkout); or the frozen [[Labs/Ubiquity/Ubiquity 0.5_Author_Tutorial|Ubiquity 0.5 Command Authoring Tutorial]] for those using version 0.5 of the extension.<br />
# [[Labs/Ubiquity/Parser_2_API_Conversion_Tutorial|Command Update Tutorial]] for how to take a command written for Ubiquity 0.1 and make it work in Ubiquity 0.5.<br />
# [[Labs/Ubiquity/Locked-Down_Feed_Tutorial|Locked-Down Feed Tutorial]]<br />
# [[Labs/Ubiquity/Secure_Coding_Practices|Secure Coding Practices]]<br />
# [[Labs/Ubiquity/Skins_v0.5|Skinning Ubiquity Tutorial]]<br />
# [https://ubiquity.mozilla.com/hg/ubiquity-firefox/raw-file/tip/ubiquity/index.html Ubiquity Code Documentation] - Generated from the latest source code via [http://code.google.com/p/code-illuminated Code Illuminated].<br />
# [[Labs/Ubiquity/Ubiquity 0.1_Development_Tutorial|Contributing to Core Development]]<br />
# [[Labs/Ubiquity/Parser_2/Localization_Tutorial|Localizing Ubiquity to Your Language]]<br />
# [[Labs/Ubiquity/Ubiquity_0.5_Command_Localization_Tutorial|Localizing Commands to Your Language]]<br />
# [[Labs/Ubiquity/Ubiquity 0.1_Nountypes_Reference|Noun-types Reference]]<br />
# [[Labs/Ubiquity/Bundled Libraries|Bundled libraries]]<br />
# [[Labs/Ubiquity/jQuery in Ubiquity|Using jQuery in Ubiquity]]<br />
# [https://developer.mozilla.org/en/JavaScript_style_guide JavaScript style guide]<br />
# [[Labs/Ubiquity/Ubiquity_0.1.3_Architecture|Ubiquity 0.1.3 Architecture]]<br />
# [[Labs/Ubiquity/Parser_Documentation]]<br />
# [[Labs/Ubiquity/Parser_Interface]]<br />
# [[Labs/Ubiquity/0.5_Documentation|Help Document the 0.5 code here]] - working copies of the wiki documentation for the latest source version<br />
# [[Labs/Ubiquity/Command_Documentation_Workspace|Help us improve the built-in command documentation by editing this page]]<br />
# [[Labs/Ubiquity/Interactive_Tutorial_Workspace|Help us improve the interactive tutorial by editing this page]]<br />
<br />
= Blogs =<br />
<br />
# [http://ubiquity.mozilla.com/planet Planet Ubiquity]<br />
# [http://www.azarask.in/blog/ Aza]<br />
# [http://www.toolness.com/ Atul]<br />
# [http://blog.reybango.com/ Rey]<br />
# [http://jonoscript.wordpress.com/ Jono]<br />
# [http://web.archive.org/web/20130928165103/http://abcdefu.wordpress.com/ Abi]<br />
# [http://web.archive.org/web/20090415165647/http://www.indolering.com:80/indolering.com/Ubiquity_Blog/Ubiquity_Blog.html Zach]<br />
# [http://mitcho.com/blog/ mitcho] (see also his [[User:Mitcho/ResearchTopics|future topics to blog on]])<br />
# [http://geeksbynature.dk cers]<br />
<br />
= Twitter =<br />
# [http://twitter.com/mozillaubiquity @mozillaubiquity]: The main source of news & info about the Ubiquity project via Twitter. Be sure to follow.<br />
# [http://twitter.com/azaaza @azaaza]: Mozilla's co-lead developer for the Ubiquity project<br />
# [http://twitter.com/toolness @toolness]: Mozilla's co-lead developer for the Ubiquity project<br />
# [http://twitter.com/reybango @reybango]: Evangelist for the Ubiquity project<br />
# [http://twitter.com/theunfocused @theunfocused]: Fellow Mozillian Blair McBride<br />
# [http://twitter.com/_abi_ @_abi_]: Created the Devo Firefox extension which provided a keyboard command launcher similar to what Ubiquity is today.<br />
# [http://twitter.com/fernando_takai @fernando_takai]: Major supporter of Ubiquity.<br />
# [http://twitter.com/mitchoyoshitaka @mitchoyoshitaka]: Resident linguist<br />
# [http://twitter.com/bpung @bpung]: Mozilla labs intern, developer for Ubiquity<br />
# [http://twitter.com/ChristianSonne @ChristianSonne]: Developer for Ubiquity<br />
<br />
= The Herd =<br />
The Herd keeps track of all Ubiquity scripts. For more information, see the following links:<br />
# [http://ubiquity.mozilla.com/hg/ubiquity-site/ Herd HG Repository]<br />
# [http://ubiquity.mozilla.com/hg/ubiquity-site/file/tip/README Herd Developer FAQ]<br />
# [http://wiki.apache.org/couchdb/HttpViewApi CouchDB] - database used for Herd<br />
# [https://ubiquity.mozilla.com/herd/ The Herd]-The Herd Itself.<br />
<br />
= Proposals =<br />
<br />
# [[Labs/Ubiquity/Roadmap|Ubiquity Roadmap]] - from 0.5 to 1.0<br />
# [[Labs/Ubiquity/Ubiquity Command Suggestions|Command Suggestions]] - use this page to suggest new Ubiquity commands you'd like to see.<br />
# [[Labs/Ubiquity/Nouns | Proposals for New Nouns]]<br />
# [[Labs/Ubiquity/Magic_Words | Proposals for new "Magic Words"]]<br />
# [[Labs/Ubiquity/Ubiquity_Commands_Center | Ubiquity Commands Center]] - an idea for a web-panel that maintains a database of Ubiquity scripts.<br />
# [[Labs/Ubiquity/TrustNetwork | Ubiquity Trust Network]] - a proposal for a distributed trust network<br />
# [[Labs/Ubiquity/Thunderbird | Ubiquity In Thunderbird]] - let's make Ubiquity work in Thunderbird!<br />
# [[Labs/Ubiquity/0.2 Roadmap Proposals | 0.2 Roadmap Proposals]] - Brainstorming on possible directions to go for Ubiquity 0.2.<br />
# [[Labs/Ubiquity/0.2 Design: UI and Security Extensibility|0.2 Design: UI and Security Extensibility]] - Design-related thoughts on how to make Ubiquity extensible in regards to security/command-execution and access by other Firefox UIs.<br />
# [[Labs/Ubiquity/0.2 Proposed Uplift Commands| Proposed commands for uplift into Ubiquity 0.2]]<br />
# [http://mitcho.com/blog/projects/writing-commands-with-semantic-roles/ Writing commands with semantic roles] - would enable commands to be automagically localized<br />
# [[Labs/Ubiquity/The Great Renaming|The Great Renaming]] -- proposal for renaming all built-in commands for consistency and to work with the Overlord Verbs system.<br />
<br />
= Internationalization and Localization =<br />
<br />
# [[Labs/Ubiquity/i18n|internationalization and localization pages]]<br />
# [http://groups.google.com/group/ubiquity-i18n Ubiquity i18n Google Group/mailing list] for discussion of internationalization and localization topics<br />
# [[Labs/Ubiquity/Ubiquity_0.5_Command_Localization_Tutorial|Command Localization Tutorial]] for how to translate commands to your language<br />
<br />
= Release Notes =<br />
# [[Labs/Ubiquity/Ubiquity_0.5.4_Release_Notes|Ubiquity 0.5.4 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.5.3_Release_Notes|Ubiquity 0.5.3 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.5.2_Release_Notes|Ubiquity 0.5.2 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.5.1_Release_Notes|Ubiquity 0.5.1 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.5_Release_Notes|Ubiquity 0.5 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.1.9_Release_Notes|Ubiquity 0.1.9 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.1.8_Release_Notes|Ubiquity 0.1.8 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.1.7_Release_Notes|Ubiquity 0.1.7 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.1.6_Release_Notes|Ubiquity 0.1.6 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.1.5_Release_Notes|Ubiquity 0.1.5 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity 0.1.3 Release Notes|Ubiquity 0.1.3 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity 0.1.2 Release Notes (Raging Stream)|Ubiquity 0.1.2 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity 0.1.1 Release Notes|Ubiquity 0.1.1 Release Notes]]</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Labs/Jetpack/Weekly_Meeting/2011-10-18&diff=1218685Labs/Jetpack/Weekly Meeting/2011-10-182019-10-07T19:20:21Z<p>MrElvey: rv old spam</p>
<hr />
<div>= Agenda =<br />
* FlightDeck<br />
* SDK<br />
** 1.2 Release today!<br />
** Need to replace translate docs examples, brain-storming etherpad: https://jetpack.etherpad.mozilla.org/replace-gtranslate-example<br />
* Bugs<br />
* Roundtable<br />
** (dcm) Our goals have to change thanks to Mobile UI shift:<br />
***Goals for end of Q4<br />
l10n - Build an API that allows devs to localize js strings<br />
l10n - Have a plan for localizing html files <br />
e10s - Build a prototype SDK that supports content processes on desktop<br />
e10s - Build a prototype SDK that can build add-ons that run in their own process <br />
mobile - Build a prototype SDK that can build add-ons that use non-UI based features for Fennec<br />
** SDK Hack Day update<br />
<br />
= Attendees =<br />
<br />
* canuckistani<br />
* dcm<br />
* mossop<br />
* kwierso<br />
* warner<br />
* myk<br />
* gozala<br />
* ochameau<br />
* wbamberg<br />
* ejpbruel<br />
* dhorner<br />
* krizsa<br />
* zalewa<br />
* dbuc<br />
* arron<br />
* jorge<br />
<br />
= Minutes =<br />
<br />
== SDK 1.2 ==<br />
<br />
* dcm: SDK 1.2 to be released today!<br />
<br />
* Jeff: need to replace Google Translate example by December 1<br />
* have some ideas, have etherpad for brainstorming<br />
* https://jetpack.etherpad.mozilla.org/replace-gtranslate-example<br />
* dcm: ask forum for ideas<br />
<br />
* myk: saw references to addon.mozilla.org, but current docs are at addons.mozilla.org<br />
* want to make sure docs expect to be at correct URL<br />
* wbamberg: some references to one, some to the other<br />
* but docs correctly expect to be at addons.mozilla.org<br />
<br />
== FlightDeck ==<br />
<br />
* dbuc: repacker changes pushing to production on Wednesday<br />
* new SDK will be made available once it is released today<br />
* frontend and backend changes happening (new template system)<br />
* search template being redone<br />
<br />
* would like to meet this week to discuss docs and hosting examples<br />
* -> wbamberg to set up meeting<br />
<br />
== Roundtable ==<br />
<br />
* dcm: mobile team deciding to switch to native ui on android<br />
* this impacts timeline<br />
* adjusted Q4 goals for team<br />
* mobile goal at risk<br />
* other stuff we should be able to do by end of quarter<br />
<br />
* ejpbruel: does this mean e10s work is only relevant on desktop for now?<br />
* all: yes<br />
* ejpbruel: potential opportunity to do platform work on new native interface?<br />
* dcm: probably best discussed with mossop<br />
<br />
* myk: keep in mind that a future version of android will have better support for multi-process<br />
* and current android has support for multi-thread, which we could take advantage of<br />
* dbuc: android 4 announced soon, should have support for multi-process<br />
<br />
* canuckistani: hack day venue has changed<br />
* r2d2/c3po not available (mobile war room), we're going to do it in 10forward<br />
* single track instead of dual track<br />
* room booked, catering booked<br />
<br />
* canuckistani: how do developers test on mobile fennec?<br />
* ...<br />
<br />
* ochameau: update on mozcamp?<br />
* canuckistani: we're doing a talk<br />
* dcm: canuckistani got arky to give talk at kuala lumpur mozcamp<br />
* canuckistani: he'll also be in berlin and is localization coordinator for southeast asia region<br />
<br />
* ochameau: any plan to simplify xpis? would be useful for uploading xpis to localization service<br />
* warner: i think we should do it; i'll help<br />
* ochameau: any particular simplifications in mind?<br />
* warner: general idea is to have only one resource protocol mapping and break the directory whose name has several components (like the package name) into individual directories<br />
* ochameau: i have a patch that does some simplification<br />
* gozala: my "no runtime search" patch depends on it<br />
* ochameaeu: i'll keep in touch with daniel to make sure repacks continue to work<br />
<br />
* dcm: we decided to do repacks for all addons again for 1.2, as we did for 1.1<br />
* partly because we don't yet have way of distinguishing between Builder and local addons<br />
* will also allow people to digest our change to not do repacks for local addons<br />
* dcm: also myk says we might not need to repack for 1.3<br />
<br />
* myk: yes, 1.2 currently passes tests on aurora, central branches<br />
* which means compatibility with firefox 9, 10<br />
* 10 compatibility can change nightly, but 9 compatibility is less likely to change<br />
* and if we make it through aurora period, it probably won't change<br />
<br />
* dbuc: we have a flag in AMO to identify addons that shouldn't be updated<br />
* we could expose this better to developers and let them decide<br />
* gozala: what about the addon that checked that box and got repacked anyway?<br />
* dbuc: yes, the flag wasn't being respected but will be</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Security/DOH-resolver-policy&diff=1218678Security/DOH-resolver-policy2019-10-07T18:43:59Z<p>MrElvey: Per talk page consensus.</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.</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Talk:Security/DOH-resolver-policy&diff=1218677Talk:Security/DOH-resolver-policy2019-10-07T18:42:49Z<p>MrElvey: /* Violations */ r</p>
<hr />
<div>If there is a list of resolvers that Mozilla determines meet this policy, it would be useful for this page to link to that list.<br />
<br />
-[[User:Paulehoffman]]<br />
<br />
=== Violations ===<br />
<br />
[[User:Merwin]]: Can the "may" be made stronger in "We may publicly document violations of this Policy and take additional actions if necessary."?<br />
<br />
::::::::::Perhaps: "We intend to publicly document violations of this Policy and take additional actions as necessary."?<br />
<br />
--[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 15:52, 8 May 2019 (UTC)<br />
<br />
:No response, so making it so.--[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 18:42, 7 October 2019 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=User_talk:Valentin.gosu&diff=1218676User talk:Valentin.gosu2019-10-07T18:41:01Z<p>MrElvey: Respond to summary attack.</p>
<hr />
<div>Don't make dickish edits,or accuse me of worse, which you, Valentin.gosu just did. If you don't want me to mention google, opendns or cisco, fine, but now the edit, as I've restored it, is less useful. Be constructive. --[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 18:41, 7 October 2019 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Trusted_Recursive_Resolver&diff=1218675Trusted Recursive Resolver2019-10-07T18:37:54Z<p>MrElvey: Don't be a dick, Valentin.gosu. If you don't want me to mention opendns or cisco fine, but now the edit is less useful.</p>
<hr />
<div>Firefox provides an optional resolver mechanism using a dedicated DNS-over-HTTPS server.<br />
<br />
DNS-over-HTTPS (DOH) allows DNS resolves with enhanced privacy, secure<br />
transfers and improved performance.<br />
<br />
== DNS-over-HTTPS Settings in Firefox ==<br />
<br />
All preferences for the DNS-over-HTTPS functionality in Firefox are located under the `network.trr` prefix (TRR == Trusted Recursive Resolver). The support for these were added in Firefox 62.<br />
<br />
=== network.trr.mode ===<br />
The resolver mode. You should not change the mode manually, instead use the UI in the Network Settings section of about:preferences<br />
<br />
* 0 - Off (default). use standard native resolving only (don't use TRR at all)<br />
* 1 - Reserved (used to be Race mode)<br />
* 2 - First. Use TRR first, and only if the name resolve fails use the native resolver as a fallback.<br />
* 3 - Only. Only use TRR. Never use the native (This mode also requires the bootstrapAddress pref to be set)<br />
* 4 - Reserved (used to be Shadow mode)<br />
* 5 - Off by choice. This is the same as 0 but marks it as done by choice and not done by default.<br />
<br />
=== network.trr.uri ===<br />
<br />
(default: none) set the URI for your DoH server. That's the URL Firefox will issue its HTTP request to. It must be a HTTPS URL. If "useGET" is enabled, Firefox will append "?dns=...." to the URI when it makes its HTTP requests. For the default POST requests, they will be issued to exactly the specified URI.<br />
<br />
Publicly announced servers include:<br />
* https://mozilla.cloudflare-dns.com/dns-query<br />
* https://dns.google/dns-query<br />
<br />
For more servers, see this unofficial list of DoH servers: https://github.com/curl/curl/wiki/DNS-over-HTTPS.<br />
<br />
===network.trr.credentials===<br />
<br />
(default: none) set credentials that will be used in the HTTP requests to the DoH end-point. It is the right-hand side content, the value, sent in the Authorization: request header.<br />
<br />
=== network.trr.wait-for-portal ===<br />
<br />
(default: false) set this boolean to **true** to tell Firefox to wait for the captive portal detection before TRR is used. (on Android, this will default to **false** since the captive portal handling is done outside of Firefox, by the OS itself.)<br />
<br />
=== network.trr.allow-rfc1918 ===<br />
<br />
(default: false) set this to true to allow RFC 1918 private addresses in TRR responses. When set to false, any such response will be considered invalid and won't be used.<br />
<br />
=== network.trr.useGET ===<br />
<br />
(default: false) When the browser issues a request to the DoH server to resolve host names, it can do that using POST or GET. By default Firefox will use POST, but by toggling this you can enforce GET to be used instead.<br />
<br />
=== network.trr.confirmationNS ===<br />
<br />
(default: example.com) Firefox will check an NS entry at startup to verify that TRR works to ensure proper configuration. This preference sets which domain to check. The verification only checks for a positive answer, it doesn't actually care what the response data says. Set this to `skip` to completely avoid confirmation.<br />
<br />
=== network.trr.bootstrapAddress ===<br />
<br />
(default: none) by setting this field to the IP address of the host name used in "network.trr.uri", you can bypass using the system native resolver for it.<br />
Use this to get the IPs of the cloudflare server: https://dns.google/query?name=mozilla.cloudflare-dns.com<br />
<br />
=== network.trr.blacklist-duration ===<br />
<br />
(default: 60) is the number of seconds a name will be kept in the TRR blacklist until it expires and then will be tried with TRR again. The default duration is one minute.<br />
<br />
Entries are added to the TRR blacklist when the resolution fails with TRR but works with the native resolver, or if the subsequent connection with a TRR resolved host name fails but works with a retry that is resolved natively. When a hostname is added to the TRR, its domain gets checked in the background to see if the whole domain should be blacklisted to ensure a smoother ride going forward.<br />
<br />
=== network.trr.request-timeout ===<br />
<br />
(default: 3000) is the number of milliseconds a request and the corresponding response from the DoH server is allowed to take until considered failed and discarded.<br />
<br />
=== network.trr.early-AAAA ===<br />
<br />
(default: false) For each normal name resolution, Firefox issues one HTTP request for A entries and another for AAAA entries. The responses come back separately and can come in any order. If the A records arrive first, Firefox will—as an optimization— continue and use them without waiting for the second response. If the AAAA records arrive first, Firefox will only continue and use them immediately if this option is set to **true**.<br />
<br />
=== network.trr.skip-AAAA-when-not-supported ===<br />
<br />
(default: true) If Firefox detects that your system does not have IPv6 connectivity, it will not request IPv6 addresses from the DoH server.<br />
<br />
=== network.trr.max-fails ===<br />
<br />
(default: 5) If this many DoH requests fail in a row, consider TRR broken and go back to verify-NS state. This is meant to detect situations when the DoH server dies.<br />
<br />
=== network.trr.disable-ECS ===<br />
<br />
(default: true) If set, TRR asks the resolver to disable ECS (EDNS Client Subnet: the method where the resolver passes on the subnet of the client asking the question). Some resolvers will use ECS to the upstream if this request is not passed on to them.<br />
<br />
=== network.trr.excluded-domains ===<br />
<br />
(default: ``) Comma separated list of domain names to be resolved using the native resolver instead of TRR. Users may add domains they wish to exclude from TRR to this pref.<br />
<br />
<br />
=== network.trr.builtin-excluded-domains ===<br />
<br />
(default: `localhost,local`) Comma separated list of domain names to be resolved using the native resolver instead of TRR. The host of the captive portal detection is also added to the exclusion list internally, in order to be able to detect local captive portals. Users should change this pref as it may get overwritten by changes to the default values.<br />
<br />
== Dynamic Blacklist ==<br />
<br />
To keep the failure rate at a minimum, the TRR system manages a dynamic<br />
persistent blacklist for host names that can't be resolved with DOH but works<br />
with the native resolver. Blacklisted entries will not be retried over DOH for<br />
a couple of days. "localhost" and names in the ".local" TLD will never be<br />
resolved via DOH.<br />
<br />
When TRR starts up, it will first verify that it works by first checking a<br />
"confirmation" domain name. This confirmation domain is a pref by default set<br />
to "example.com".<br />
<br />
== Gotchas ==<br />
<br />
=== Security ===<br />
Warning: if you were relying on an 'enhanced' DNS service for Web Content Filtering or basic Malware/Botnet Protection, phishing protection, or RFC 1918 filtering, you won't be using it anymore (at least in Firefox) if you enable TRR.<br />
<br />
== See also ==<br />
<br />
* Initial ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1434852<br />
* The DNS-over-HTTPS spec: https://tools.ietf.org/html/rfc8484<br />
* https://support.mozilla.org/en-US/kb/firefox-dns-over-https<br />
* https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https<br />
<br />
== Acknowledgements ==<br />
* [https://daniel.haxx.se/ Daniel Stenberg] wrote the initial implementation of TRR in Firefox<br />
* [https://www.ducksong.com/ Patrick McManus] edited the RFC and reviewed the TRR code</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Trusted_Recursive_Resolver&diff=1218668Trusted Recursive Resolver2019-10-07T17:32:32Z<p>MrElvey: /* Dynamic Blacklist */ To some this won't be obvious.</p>
<hr />
<div>Firefox provides an optional resolver mechanism using a dedicated DNS-over-HTTPS server.<br />
<br />
DNS-over-HTTPS (DOH) allows DNS resolves with enhanced privacy, secure<br />
transfers and improved performance.<br />
<br />
== DNS-over-HTTPS Settings in Firefox ==<br />
<br />
All preferences for the DNS-over-HTTPS functionality in Firefox are located under the `network.trr` prefix (TRR == Trusted Recursive Resolver). The support for these were added in Firefox 62.<br />
<br />
=== network.trr.mode ===<br />
The resolver mode. You should not change the mode manually, instead use the UI in the Network Settings section of about:preferences<br />
<br />
* 0 - Off (default). use standard native resolving only (don't use TRR at all)<br />
* 1 - Reserved (used to be Race mode)<br />
* 2 - First. Use TRR first, and only if the name resolve fails use the native resolver as a fallback.<br />
* 3 - Only. Only use TRR. Never use the native (This mode also requires the bootstrapAddress pref to be set)<br />
* 4 - Reserved (used to be Shadow mode)<br />
* 5 - Off by choice. This is the same as 0 but marks it as done by choice and not done by default.<br />
<br />
=== network.trr.uri ===<br />
<br />
(default: none) set the URI for your DoH server. That's the URL Firefox will issue its HTTP request to. It must be a HTTPS URL. If "useGET" is enabled, Firefox will append "?dns=...." to the URI when it makes its HTTP requests. For the default POST requests, they will be issued to exactly the specified URI.<br />
<br />
Publicly announced servers include:<br />
* https://mozilla.cloudflare-dns.com/dns-query<br />
* https://dns.google/dns-query<br />
<br />
For more servers, see this unofficial list of DoH servers: https://github.com/curl/curl/wiki/DNS-over-HTTPS.<br />
<br />
===network.trr.credentials===<br />
<br />
(default: none) set credentials that will be used in the HTTP requests to the DoH end-point. It is the right-hand side content, the value, sent in the Authorization: request header.<br />
<br />
=== network.trr.wait-for-portal ===<br />
<br />
(default: false) set this boolean to **true** to tell Firefox to wait for the captive portal detection before TRR is used. (on Android, this will default to **false** since the captive portal handling is done outside of Firefox, by the OS itself.)<br />
<br />
=== network.trr.allow-rfc1918 ===<br />
<br />
(default: false) set this to true to allow RFC 1918 private addresses in TRR responses. When set to false, any such response will be considered invalid and won't be used.<br />
<br />
=== network.trr.useGET ===<br />
<br />
(default: false) When the browser issues a request to the DoH server to resolve host names, it can do that using POST or GET. By default Firefox will use POST, but by toggling this you can enforce GET to be used instead.<br />
<br />
=== network.trr.confirmationNS ===<br />
<br />
(default: example.com) Firefox will check an NS entry at startup to verify that TRR works to ensure proper configuration. This preference sets which domain to check. The verification only checks for a positive answer, it doesn't actually care what the response data says. Set this to `skip` to completely avoid confirmation.<br />
<br />
=== network.trr.bootstrapAddress ===<br />
<br />
(default: none) by setting this field to the IP address of the host name used in "network.trr.uri", you can bypass using the system native resolver for it.<br />
Use this to get the IPs of the cloudflare server: https://dns.google/query?name=mozilla.cloudflare-dns.com<br />
<br />
=== network.trr.blacklist-duration ===<br />
<br />
(default: 60) is the number of seconds a name will be kept in the TRR blacklist until it expires and then will be tried with TRR again. The default duration is one minute.<br />
<br />
Entries are added to the TRR blacklist when the resolution fails with TRR but works with the native resolver, or if the subsequent connection with a TRR resolved host name fails but works with a retry that is resolved natively. When a hostname is added to the TRR, its domain gets checked in the background to see if the whole domain should be blacklisted to ensure a smoother ride going forward.<br />
<br />
=== network.trr.request-timeout ===<br />
<br />
(default: 3000) is the number of milliseconds a request and the corresponding response from the DoH server is allowed to take until considered failed and discarded.<br />
<br />
=== network.trr.early-AAAA ===<br />
<br />
(default: false) For each normal name resolution, Firefox issues one HTTP request for A entries and another for AAAA entries. The responses come back separately and can come in any order. If the A records arrive first, Firefox will—as an optimization— continue and use them without waiting for the second response. If the AAAA records arrive first, Firefox will only continue and use them immediately if this option is set to **true**.<br />
<br />
=== network.trr.skip-AAAA-when-not-supported ===<br />
<br />
(default: true) If Firefox detects that your system does not have IPv6 connectivity, it will not request IPv6 addresses from the DoH server.<br />
<br />
=== network.trr.max-fails ===<br />
<br />
(default: 5) If this many DoH requests fail in a row, consider TRR broken and go back to verify-NS state. This is meant to detect situations when the DoH server dies.<br />
<br />
=== network.trr.disable-ECS ===<br />
<br />
(default: true) If set, TRR asks the resolver to disable ECS (EDNS Client Subnet: the method where the resolver passes on the subnet of the client asking the question). Some resolvers will use ECS to the upstream if this request is not passed on to them.<br />
<br />
=== network.trr.excluded-domains ===<br />
<br />
(default: ``) Comma separated list of domain names to be resolved using the native resolver instead of TRR. Users may add domains they wish to exclude from TRR to this pref.<br />
<br />
<br />
=== network.trr.builtin-excluded-domains ===<br />
<br />
(default: `localhost,local`) Comma separated list of domain names to be resolved using the native resolver instead of TRR. The host of the captive portal detection is also added to the exclusion list internally, in order to be able to detect local captive portals. Users should change this pref as it may get overwritten by changes to the default values.<br />
<br />
== Dynamic Blacklist ==<br />
<br />
To keep the failure rate at a minimum, the TRR system manages a dynamic<br />
persistent blacklist for host names that can't be resolved with DOH but works<br />
with the native resolver. Blacklisted entries will not be retried over DOH for<br />
a couple of days. "localhost" and names in the ".local" TLD will never be<br />
resolved via DOH.<br />
<br />
When TRR starts up, it will first verify that it works by first checking a<br />
"confirmation" domain name. This confirmation domain is a pref by default set<br />
to "example.com".<br />
<br />
== Gotchas ==<br />
<br />
=== Security ===<br />
Note: if you were relying on an 'enhanced' DNS service such as one from OpenDNS (now perhaps better known as umbrella.cisco.com) for Web Content Filtering <small>(categories can include any of: Academic Fraud, Adult Themes, Adware, Alcohol, Anime/Manga/Webcomic, Auctions, Automotive, Blogs, Business Services, Chat, Classifieds, Dating, Drugs, Ecommerce/Shopping, Educational Institutions, File Storage, Financial Institutions, Forums/Message boards, Gambling, Games, German Youth Protection, Government, Hate/Discrimination, Health and Fitness, Humor, Instant Messaging, Jobs/Employment, Lingerie/Bikini, Movies, Music, News/Media, Non-Profits, Nudity, P2P/File sharing, Parked Domains, Photo Sharing, Podcasts, Politics, Pornography, Portals, Proxy/Anonymizer, Radio, Religious, Research/Reference, Search Engines, Sexuality, Social Networking, Software/Technology, Sports, Tasteless, Television, Tobacco, Travel, Video Sharing, Visual Search Engines, Weapons, Web Spam, Webmail <br />
)</small> or basic Malware/Botnet Protection, phishing protection, or RFC 1918 filtering, you won't be using it anymore (at least in Firefox) if you enable TRR.<br />
<br />
== See also ==<br />
<br />
* Initial ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1434852<br />
* The DNS-over-HTTPS spec: https://tools.ietf.org/html/rfc8484<br />
* https://support.mozilla.org/en-US/kb/firefox-dns-over-https<br />
* https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https<br />
<br />
== Acknowledgements ==<br />
* [https://daniel.haxx.se/ Daniel Stenberg] wrote the initial implementation of TRR in Firefox<br />
* [https://www.ducksong.com/ Patrick McManus] edited the RFC and reviewed the TRR code</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Talk:Security/DOH-resolver-policy&diff=1212007Talk:Security/DOH-resolver-policy2019-05-08T20:59:03Z<p>MrElvey: /* Violations */</p>
<hr />
<div>If there is a list of resolvers that Mozilla determines meet this policy, it would be useful for this page to link to that list.<br />
<br />
-[[User:Paulehoffman]]<br />
<br />
=== Violations ===<br />
<br />
[[User:Merwin]]: Can the "may" be made stronger in "We may publicly document violations of this Policy and take additional actions if necessary."?<br />
<br />
::::::::::Perhaps: "We intend to publicly document violations of this Policy and take additional actions as necessary."?<br />
<br />
--[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 15:52, 8 May 2019 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Talk:Security/DOH-resolver-policy&diff=1211996Talk:Security/DOH-resolver-policy2019-05-08T15:55:29Z<p>MrElvey: whoops</p>
<hr />
<div>If there is a list of resolvers that Mozilla determines meet this policy, it would be useful for this page to link to that list.<br />
<br />
-[[User:Paulehoffman]]<br />
<br />
=== Violations ===<br />
<br />
[[User:Merwin]]: Can the "may" be made stronger in "We may publicly document violations of this Policy and take additional actions if necessary."?<br />
<br />
Perhaps "We intend to publicly document violations of this Policy and may take additional actions if necessary."?<br />
<br />
--[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 15:52, 8 May 2019 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Talk:Security/DOH-resolver-policy&diff=1211995Talk:Security/DOH-resolver-policy2019-05-08T15:52:58Z<p>MrElvey: Violations:</p>
<hr />
<div>=== Violations ===<br />
<br />
[[User:Merwin]]: Can the "may" be made stronger in "We may publicly document violations of this Policy and take additional actions if necessary."?<br />
<br />
Perhaps "We intend to publicly document violations of this Policy and may take additional actions if necessary."?<br />
<br />
--[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 15:52, 8 May 2019 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Labs/Ubiquity&diff=1209377Labs/Ubiquity2019-03-22T15:25:30Z<p>MrElvey: Undo revision 342560 by Mozzes1290 (talk) rv spam. Admin: Block this spammer. Also removed more spam and a dead URL. And probably left some behind.</p>
<hr />
<div>Back to [[Labs]].<br />
<br />
= What is Ubiquity? =<br />
<br />
Ubiquity was a Mozilla Labs experiment that was in development from 2008 to 2009. Its purpose was to explore whether a radically different type of interface to the Web — a task-centric, natural-language-based command line — could help us get common Web tasks done faster.<br />
<br />
Development is currently on indefinite hiatus. We will most likely revisit the experiment at some point in the future. In the meantime, the Ubiquity extension for Firefox is still available for download (see below). Also, some of the ideas from Ubiquity are being implemented in [[Labs/Jetpack|Jetpack]].<br />
<br />
You can learn more about Ubiquity by reading Atul's blog post entitled [http://www.toolness.com/wp/?p=54 Ubiquitous Interfaces, Ubiquitous Functionality], or try it out via the [[Labs/Ubiquity/Latest Ubiquity User Tutorial|User Tutorial]].<br />
<br />
Other informative blog posts about Ubiquity include:<br />
# [http://www.toolness.com/wp/?p=64 Trusting Functionality] by Atul<br />
# [http://www.azarask.in/blog/post/can-ubiquity-be-used-only-with-the-mouse/ Mouse-Based Ubiquity]<br />
# [http://azarask.in/blog/post/sharing-streamable-functionality/ Sharing Streamable Functionality] by Aza<br />
# [http://jonoscript.wordpress.com/2008/07/21/language-based-interfaces-part-1-the-problem/ Language-Based Interfaces, part 1: The Problem] by Jono<br />
# [http://jonoscript.wordpress.com/2008/07/25/our-presentation-at-labs-night/ Our Presentation at Labs Night] by Jono<br />
# [http://jonoscript.wordpress.com/2008/07/26/why-verbs/ Why Verbs?] by Jono<br />
# [[Labs/Ubiquity/Selected Press|Selected Press]]<br />
<br />
= Install =<br />
<br />
== For Firefox 14.0 and up ==<br />
<br />
[https://addons.mozilla.org/addon/9527 Install Ubiquity 0.6.2 for Firefox 14 and up]<br />
<br />
[https://bitbucket.org/satyr/ubiquity/downloads/tip.xpi Install the latest beta of Ubiquity] - Maintained by community member Satyr<br />
<br />
<br />
== For Older Versions of Firefox ==<br />
<br />
[https://ubiquity.mozilla.com/xpi/ubiquity-latest.xpi Install latest version of Ubiquity for Firefox 3.5]<br />
<br />
[https://ubiquity.mozilla.com/xpi/ubiquity-latest-beta.xpi Install the latest beta of Ubiquity for Firefox 3.5]<br />
<br />
[https://ubiquity.mozilla.com/xpi/ Install older versions (if the current version is breaking for you)]<br />
<br />
= Participation =<br />
# [http://groups.google.com/group/ubiquity-firefox General Google Group/mailing list] - Useful for discussion of command development, user interface, feature suggestions, and other high-level discussions.<br />
# [http://groups.google.com/group/ubiquity-core Core Google Group/mailing list] - Discussion of low-level internals of Ubiquity.<br />
# [http://getsatisfaction.com/mozilla/products/mozilla_ubiquity Get Satisfaction - Ideas, Complaints, Forum, and "Customer Service"]<br />
# [irc://irc.mozilla.org/ubiquity #ubiquity irc.mozilla.org] - Live internet relay chat discussion.<br />
# [http://ubiquity.mozilla.com/trac/search?q=good-for-beginners Good-for-beginners bugs] - bug tickets which may be good for a Ubiquity beginner to attack<br />
# [[Labs/Ubiquity/Frequently Encountered Bugs|Frequently Encountered Bugs]] - bugs that get reported a lot on the [http://groups.google.com/group/ubiquity-firefox mailing list] and [http://getsatisfaction.com/mozilla/products/mozilla_ubiquity Get Satisfaction] that would make lots of people happy if they got fixed<br />
# [[Labs/Ubiquity/Commands In The Wild|Commands In The Wild]] Add links to your commands here.<br />
# [https://ubiquity.mozilla.com/trac/report/1 Issue Tracker] - Used to report/discuss bugs and submit patches for Ubiquity.<br />
# [[Labs/Ubiquity/Trac Components and Keywords|Trac Components and Keywords]] - Keywords and categories to use when filing Trac tickets.<br />
# [https://ubiquity.mozilla.com/hg/ubiquity-firefox/ Ubiquity HG Repository] - The Mercurial source code repository for Ubiquity.<br />
# [http://ubiquity.mozilla.com/buildbot/ Buildbot] - Continuous integration that runs Ubiquity unit tests after every commit. If the tests fail, they're reported immediately to the mailing list.<br />
# [[Labs/Ubiquity/Credits|Credits]]<br />
<br />
= Meetings =<br />
<br />
* [[Labs/Ubiquity/Meetings|Meeting notes & times]]<br />
<br />
= Documentation =<br />
# [[Labs/Ubiquity/Latest Ubiquity User Tutorial|Ubiquity User Tutorial]] <br />
# The latest [[Labs/Ubiquity/Ubiquity_Source_Tip_Author_Tutorial|Command Authoring Tutorial]] (for command authors using a Ubiquity source checkout); or the frozen [[Labs/Ubiquity/Ubiquity 0.5_Author_Tutorial|Ubiquity 0.5 Command Authoring Tutorial]] for those using version 0.5 of the extension.<br />
# [[Labs/Ubiquity/Parser_2_API_Conversion_Tutorial|Command Update Tutorial]] for how to take a command written for Ubiquity 0.1 and make it work in Ubiquity 0.5.<br />
# [[Labs/Ubiquity/Locked-Down_Feed_Tutorial|Locked-Down Feed Tutorial]]<br />
# [[Labs/Ubiquity/Secure_Coding_Practices|Secure Coding Practices]]<br />
# [[Labs/Ubiquity/Skins_v0.5|Skinning Ubiquity Tutorial]]<br />
# [https://ubiquity.mozilla.com/hg/ubiquity-firefox/raw-file/tip/ubiquity/index.html Ubiquity Code Documentation] - Generated from the latest source code via [http://code.google.com/p/code-illuminated Code Illuminated].<br />
# [[Labs/Ubiquity/Ubiquity 0.1_Development_Tutorial|Contributing to Core Development]]<br />
# [[Labs/Ubiquity/Parser_2/Localization_Tutorial|Localizing Ubiquity to Your Language]]<br />
# [[Labs/Ubiquity/Ubiquity_0.5_Command_Localization_Tutorial|Localizing Commands to Your Language]]<br />
# [[Labs/Ubiquity/Ubiquity 0.1_Nountypes_Reference|Noun-types Reference]]<br />
# [[Labs/Ubiquity/Bundled Libraries|Bundled libraries]]<br />
# [[Labs/Ubiquity/jQuery in Ubiquity|Using jQuery in Ubiquity]]<br />
# [https://developer.mozilla.org/en/JavaScript_style_guide JavaScript style guide]<br />
# [[Labs/Ubiquity/Ubiquity_0.1.3_Architecture|Ubiquity 0.1.3 Architecture]]<br />
# [[Labs/Ubiquity/Parser_Documentation]]<br />
# [[Labs/Ubiquity/Parser_Interface]]<br />
# [[Labs/Ubiquity/0.5_Documentation|Help Document the 0.5 code here]] - working copies of the wiki documentation for the latest source version<br />
# [[Labs/Ubiquity/Command_Documentation_Workspace|Help us improve the built-in command documentation by editing this page]]<br />
# [[Labs/Ubiquity/Interactive_Tutorial_Workspace|Help us improve the interactive tutorial by editing this page]]<br />
<br />
= Blogs =<br />
<br />
# [http://ubiquity.mozilla.com/planet Planet Ubiquity]<br />
# [http://www.azarask.in/blog/ Aza]<br />
# [http://www.toolness.com/ Atul]<br />
# [http://blog.reybango.com/ Rey]<br />
# [http://jonoscript.wordpress.com/ Jono]<br />
# [http://abcdefu.wordpress.com/ Abi]<br />
# [http://www.indolering.com/indolering.com/Ubiquity_Blog/Ubiquity_Blog.html Zach]<br />
# [http://mitcho.com/blog/ mitcho] (see also his [[User:Mitcho/ResearchTopics|future topics to blog on]])<br />
# [http://geeksbynature.dk cers]<br />
<br />
= Twitter =<br />
# [http://twitter.com/mozillaubiquity @mozillaubiquity]: The main source of news & info about the Ubiquity project via Twitter. Be sure to follow.<br />
# [http://twitter.com/azaaza @azaaza]: Mozilla's co-lead developer for the Ubiquity project<br />
# [http://twitter.com/toolness @toolness]: Mozilla's co-lead developer for the Ubiquity project<br />
# [http://twitter.com/reybango @reybango]: Evangelist for the Ubiquity project<br />
# [http://twitter.com/theunfocused @theunfocused]: Fellow Mozillian Blair McBride<br />
# [http://twitter.com/_abi_ @_abi_]: Created the Devo Firefox extension which provided a keyboard command launcher similar to what Ubiquity is today.<br />
# [http://twitter.com/fernando_takai @fernando_takai]: Major supporter of Ubiquity.<br />
# [http://twitter.com/mitchoyoshitaka @mitchoyoshitaka]: Resident linguist<br />
# [http://twitter.com/bpung @bpung]: Mozilla labs intern, developer for Ubiquity<br />
# [http://twitter.com/ChristianSonne @ChristianSonne]: Developer for Ubiquity<br />
<br />
= The Herd =<br />
The Herd keeps track of all Ubiquity scripts. For more information, see the following links:<br />
# [http://ubiquity.mozilla.com/hg/ubiquity-site/ Herd HG Repository]<br />
# [http://ubiquity.mozilla.com/hg/ubiquity-site/file/tip/README Herd Developer FAQ]<br />
# [http://wiki.apache.org/couchdb/HttpViewApi CouchDB] - database used for Herd<br />
# [https://ubiquity.mozilla.com/herd/ The Herd]-The Herd Itself.<br />
<br />
= Proposals =<br />
<br />
# [[Labs/Ubiquity/Roadmap|Ubiquity Roadmap]] - from 0.5 to 1.0<br />
# [[Labs/Ubiquity/Ubiquity Command Suggestions|Command Suggestions]] - use this page to suggest new Ubiquity commands you'd like to see.<br />
# [[Labs/Ubiquity/Nouns | Proposals for New Nouns]]<br />
# [[Labs/Ubiquity/Magic_Words | Proposals for new "Magic Words"]]<br />
# [[Labs/Ubiquity/Ubiquity_Commands_Center | Ubiquity Commands Center]] - an idea for a web-panel that maintains a database of Ubiquity scripts.<br />
# [[Labs/Ubiquity/TrustNetwork | Ubiquity Trust Network]] - a proposal for a distributed trust network<br />
# [[Labs/Ubiquity/Thunderbird | Ubiquity In Thunderbird]] - let's make Ubiquity work in Thunderbird!<br />
# [[Labs/Ubiquity/0.2 Roadmap Proposals | 0.2 Roadmap Proposals]] - Brainstorming on possible directions to go for Ubiquity 0.2.<br />
# [[Labs/Ubiquity/0.2 Design: UI and Security Extensibility|0.2 Design: UI and Security Extensibility]] - Design-related thoughts on how to make Ubiquity extensible in regards to security/command-execution and access by other Firefox UIs.<br />
# [[Labs/Ubiquity/0.2 Proposed Uplift Commands| Proposed commands for uplift into Ubiquity 0.2]]<br />
# [http://mitcho.com/blog/projects/writing-commands-with-semantic-roles/ Writing commands with semantic roles] - would enable commands to be automagically localized<br />
# [[Labs/Ubiquity/The Great Renaming|The Great Renaming]] -- proposal for renaming all built-in commands for consistency and to work with the Overlord Verbs system.<br />
<br />
= Internationalization and Localization =<br />
<br />
# [[Labs/Ubiquity/i18n|internationalization and localization pages]]<br />
# [http://groups.google.com/group/ubiquity-i18n Ubiquity i18n Google Group/mailing list] for discussion of internationalization and localization topics<br />
# [[Labs/Ubiquity/Ubiquity_0.5_Command_Localization_Tutorial|Command Localization Tutorial]] for how to translate commands to your language<br />
<br />
= Release Notes =<br />
# [[Labs/Ubiquity/Ubiquity_0.5.4_Release_Notes|Ubiquity 0.5.4 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.5.3_Release_Notes|Ubiquity 0.5.3 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.5.2_Release_Notes|Ubiquity 0.5.2 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.5.1_Release_Notes|Ubiquity 0.5.1 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.5_Release_Notes|Ubiquity 0.5 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.1.9_Release_Notes|Ubiquity 0.1.9 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.1.8_Release_Notes|Ubiquity 0.1.8 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.1.7_Release_Notes|Ubiquity 0.1.7 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.1.6_Release_Notes|Ubiquity 0.1.6 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity_0.1.5_Release_Notes|Ubiquity 0.1.5 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity 0.1.3 Release Notes|Ubiquity 0.1.3 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity 0.1.2 Release Notes (Raging Stream)|Ubiquity 0.1.2 Release Notes]]<br />
# [[Labs/Ubiquity/Ubiquity 0.1.1 Release Notes|Ubiquity 0.1.1 Release Notes]]</div>MrElveyhttps://wiki.mozilla.org/index.php?title=EngineeringProductivity/Meetings/2011-12-12&diff=1209371EngineeringProductivity/Meetings/2011-12-122019-03-22T15:10:23Z<p>MrElvey: Undo revision 500045 by Ionutpop (talk) rv spam</p>
<hr />
<div>== The Overview ==<br />
''Add items from project overview here''<br />
<br />
=== Bugzilla ===<br />
* Employee Incident bug entry form deployed for mcoates<br />
* Working on Recovery Key form also for mcoates<br />
* Email to IT asking for current backup/recovery plan for BMO in wake of email meltdown<br />
* Bringing old test scripts up to speed with latest Bugzilla 4.2 code<br />
* Some minor work on REST/testing<br />
<br />
=== Bughunter ===<br />
* site test assertions, unittest assertions and unittest valgrind ui done to a first approximation<br />
* finished implementing view collections. This feature allows a user to open a set of data views that work together, they are defined in a JSON structure<br />
* migration to the cluster has been halted due to networking problems in phx<br />
<br />
=== Eideticker ===<br />
* Eideticker has a new, much simpler harness and tests are much easier to write<br />
* reworked the capture analysis API to use numpy behind the scenes<br />
* added the beginnings of a web interface for browsing captures and doing visualizations on them<br />
* See also: http://masalalabs.ca/<br />
<br />
=== Marionette ===<br />
* jgriffin and mdas in Taipei<br />
* gave a short talk on Marionette on Thursday, and it was well received<br />
* desktop support for marionette has been added this week with simpletest-like functionality<br />
* Documentation was also updated and added, notably https://wiki.mozilla.org/Auto-tools/Projects/Marionette#Writing_Tests and Marionette client api page(https://wiki.mozilla.org/Auto-tools/Projects/Marionette/Marionette_Client_API)<br />
* working on adding support for JS-only tests, landing Marionette in the master B2G repo, working out a few kinks in the continuous integration framework we wrote, and getting the emulator to work with the gonk (b2g) backend<br />
<br />
=== Mobile Automation ===<br />
* keeping fennec reftest patch up to date (jmaher)<br />
<br />
=== Mozbase ===<br />
* working on a better URL dispatching system for mozhttpd <br />
* mozbase now has unified unit tests; need to coordinate with ManifestDestiny's doctests<br />
* coordinating getting CI (buildbot) working with jgriffin, mcote, and wlach<br />
* documentation improvements to Mozbase and Mozilla python general: https://developer.mozilla.org/en/Python (Still tons to do)<br />
<br />
=== Peptest ===<br />
* the make target landed (run make peptest to try it out)<br />
* looked into adding a profiler, have some work in an experimental branch, but going to wait until it lands and gets some better docs<br />
<br />
=== Robocop ===<br />
* close to a reviewable patch to m-c to add robocop to the toolchain<br />
* starting to figure out a solution for running robotium in talos as well as in releng<br />
* next week there will be a patch to integrate to the make system<br />
<br />
=== Tegra Pool ===<br />
Nothing to see here move along.<br />
<br />
=== Talos ===<br />
* Bug 707218 - write a script to create a talos.zip file with the dependencies from mozbase; ready and tested on A*Team staging (needs releng testing + approval)<br />
* BYK plans to finish https://bugzilla.mozilla.org/show_bug.cgi?id=673132 :)<br />
<br />
=== Speedtests ===<br />
* Nothing to see here move along.<br />
<br />
=== Mozmill ===<br />
* Nothing to see here move along.<br />
<br />
=== WebRTC ===<br />
* Nothing to see here move along.<br />
<br />
=== War On Orange ===<br />
<br />
Nothing to see here, move along<br />
<br />
== Upcoming Events == <br />
''All times Pacific Time, click on link to find your timezone''<br />
* Platform Meeting (all platform engineers) [http://www.timeanddate.com/worldclock/fixedtime.html?iso=20111101T11&p1=283 Tuesday at 11AM], Conf # 8605.<br />
* Mobile Test Automation [http://www.timeanddate.com/worldclock/fixedtime.html?iso=20111102T1030&p1=283 Wednesday at 10:30AM] #304<br />
* Marionette/Eideticker Meeting [http://www.timeanddate.com/worldclock/fixedtime.html?iso=20111104T10&p1=283 Thursday at 10AM] Conf # 304<br />
* Trevor doing a presentation on his term on Wednesday at Noon.<br />
<br />
== Round Table ==<br />
''Put your questions and things to raise with the entire team here''<br />
* (from ctalbert): We have only two weeks left in the quarter. And those weeks include christmas and new year's. So, ensure all things that are on track are really on track. If there's anything that isn't you should have let me know a week ago. If something has changed, let me know, call my cell (it's in the phonebook).<br />
** I've marked status on our [https://wiki.mozilla.org/Auto-tools/Goals/2011Q4 goals, feel free to update].<br />
<br />
== Misc ==<br />
''Find something you think is cool, interesting, funny, or exciting and put it here''<br />
* A couple links for Trevor's last week:<br />
** His [http://www.youtube.com/watch?v=ZMEtqj2Fa4s soon-to-be-favorite-song ;)]<br />
** His [http://people.mozilla.org/~ctalbert/personal/pics/2011-11-30_21-54-33_813.jpg Christmas outfit]<br />
* A few links from Clint's trip:<br />
** [http://people.mozilla.org/~ctalbert/personal/pics/2011-12-09_16-03-50_157.jpg Across the mojave desert]<br />
** [http://people.mozilla.org/~ctalbert/personal/pics/IMGP4552.jpg High Desert of AZ covered in snow]<br />
** [http://people.mozilla.org/~ctalbert/personal/pics/uptoredriver.jpg Toward Red River NM]<br />
** [http://people.mozilla.org/~ctalbert/personal/pics/eaglesnestlake_sunset.jpg Sunset on the Western Side of the Enchanted Circle, over Eagles Nest Lake]<br />
** In Lubbock this morning, full steam to Austin. See y'all soon.</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Data_Collection&diff=1209370Data Collection2019-03-22T15:05:10Z<p>MrElvey: Not so recent.</p>
<hr />
<div><br />
At Mozilla, like at many other organizations, we rely on data to make product decisions. But here, unlike many other organizations, we balance our goal of collecting useful, high-quality data with our goal to give users meaningful choice and control over their own data. The Firefox data collection program was created to ensure we achieve both goals whenever we make a change to how we collect data in our products. <br />
<br />
In [https://wiki.mozilla.org/index.php?title=Firefox/Data_Collection&diff=1183319&oldid=1181872 November 2017], we revised the program to make our policies clearer and easier to understand and our processes simpler and easier to follow. These changes are designed to reflect our commitment to data collection grounded in: <br />
<br />
* Necessity - We collect only as much data as is necessary when we can demonstrate a clear business case for that data<br />
* Privacy - We give users meaningful choices and control over their own data<br />
* Transparency - We make our decisions about data collection public and accessible<br />
* Accountability - We assign accountability for the design, approval, and implementation of data collection <br />
<br />
Owner: [https://mozillians.org/en-US/u/rweiss/ Rebecca Weiss]<br />
<br />
Data Stewards: <br />
* [https://mozillians.org/u/liuche/ Chenxia Liu] (:liuche) - Mobile frontend<br />
* [https://mozillians.org/u/chutten/ :chutten] - Firefox Telemetry<br />
* [https://mozillians.org/u/rrayborn/ Rob Rayborn] :rrayborn- Experiments<br />
* [https://mozillians.org/u/kennylong/ Kenny Long] - Pocket<br />
* [https://mozillians.org/u/maxmaxmax/ Max Weiner] - Pocket<br />
* [https://mozillians.org/u/harraton/ Janice Tsai] - Emerging Technology<br />
* [https://mozillians.org/u/nevin/ Nevin Chen] - Firefox Lite<br />
* [https://mozillians.org/u/tdsmith/ :tdsmith]<br />
* [https://mozillians.org/en-US/u/bmiroglio/ Ben Miroglio] - Data Science<br />
<br />
Group email: [mailto:fx-datastewards@mozilla.com fx-datastewards@mozilla.com]<br />
<br />
''Note: The data stewards aren't responsible for showing teams how to collect data, although they might be able to provide some guidance if they have time. But the Firefox data engineering team has prepared [http://docs.telemetry.mozilla.org/ data documentation] which can help!''<br />
<br />
Most assets involved in data review can be found [https://github.com/mozilla/data-review in this repository]. References to who fills out a form when are covered in the documentation below.<br />
<br />
<br />
= Key Roles for Data Collection =<br />
<br />
While the number of people involved in data collection can vary by product or project, there are two roles necessary for any project: <br />
<br />
* Data requester - the person requesting data to be collected<br />
* Data steward - the person who ensures the data collection process is followed and that requested data complies with Mozilla policies <br />
<br />
In some cases a data steward may escalate concerns to the Trust and Legal teams. They are the teams responsible for defining Firefox data collection policies and can field questions about internal policy and laws governing user privacy<br />
<br />
= Requesting Data Collection =<br />
== Step 1: Submit Request ==<br />
To request a review for new or changed Data Collection in Firefox, Data Review requesters are required to provide the following:<br />
* A completed Request Form, documenting what data is to be collected, why Mozilla needs to collect this data, how much data will be collected, and for how long it will be collected: <br />
** Take [https://github.com/mozilla/data-review/blob/master/request.md this request] and fill it out completely.<br />
* A bug to attach the completed Request Form to: <br />
** If you already have a bug filed to add the collection code, attach the form to that one. <br />
** If you don't already have a bug, file a new one in your own component, or Firefox::Untriaged if you don't have a component (e.g. if your code's in GitHub).<br />
** Tell Bugzilla that your form's extension is <tt>.txt</tt> so it can render it inline and so your Data Steward can review it more easily.<br />
* A notification so the Data Steward knows it's time to review your Request Form: <br />
** Flag the attached, completed Request Form for <tt>data-review</tt>.<br />
** If your chosen Data Steward doesn't get to your review within a couple of days, please [mailto:fx-datastewards@mozilla.com email the list].<br />
<br />
== Step 2: Request is reviewed == <br />
Data stewards review each request to ensure that it is documented fully and to assign the data collection to one of our 4 privacy categories as described here. tiers. The detailed steps in this process are:<br />
<br />
* Data stewards receive a <tt>data-review?</tt> on a file in a bug<br />
* Data stewards complete the [https://github.com/mozilla/data-review/blob/master/review.md data review form] based on the information provided in the data collection request. They ensure that the request:<br />
** Follows Lean Data Practices & Guidelines<br />
** The basic mechanics of what is being measured is documented publicly.<br />
** Our need and justification for the data collection is documented for the record; e.g. there are complete and appropriate answers to questions on the request form. <br />
** The request aligns with user consent and control mechanisms outlined in the data collection categories listed below<br />
<br />
Data stewards document the outcome of their review in the bug with a <tt>data-review+</tt> or <tt>data-review-</tt> and their completed form. Typical outcomes include:<br />
* Unapproved requests are returned to data requesters for changes or clarification. <br />
* Simple requests that fall within Category 1 or 2 are often approved quickly. <br />
* Complex requests that pose broader policy and legal implications may be escalated to the Trust and Legal teams. (See Step 3) <br />
<br />
== Step 3: (Optional) Escalated Response ==<br />
More complex requests, like those that call for a new data collection mechanism or require changes to the privacy notice, often require one or more of the following additional reviews: <br />
* Privacy analysis: Feedback from the mozilla.dev.privacy mailing list and/or privacy experts within and outside of Mozilla to discuss the feature and its privacy impact.<br />
* Policy compliance review: An assessment from the Mozilla data compliance team to determine if the request matches the Mozilla data compliance policies and documents.<br />
* Legal review: An assessment from Mozilla’s legal team.<br />
<br />
Data stewards participate in these discussion and will document the outcome in the same bug used for the collection request.<br />
<br />
= Data Collection Categories =<br />
<br />
There are four "categories" of data collection that apply to Firefox:<br />
<br />
; '''Category 1 “Technical data”'''<br />
: Information about the machine or Firefox itself. Examples include OS, available memory, crashes and errors, outcome of automated processes like updates, safebrowsing, activation, version #s, and buildid. This also includes compatibility information about features and APIs used by websites, addons, and other 3rd-party software that interact with Firefox during usage. <br />
<br />
; '''Category 2 “Interaction data”'''<br />
: Information about the user’s direct engagement with Firefox. Examples include how many tabs, addons, or windows a user has open; uses of specific Firefox features; session length, scrolls and clicks; and the status of discrete user preferences.<br />
<br />
; '''Category 3 “Web activity data”'''<br />
: Information about user web browsing that could be considered sensitive. Examples include users’ specific web browsing history; general information about their web browsing history (such as TLDs or categories of webpages visited over time); and potentially certain types of interaction data about specific webpages visited.<br />
<br />
; '''Category 4 “Highly sensitive data”'''<br />
: Information that directly identifies a person, or if combined with other data could identify a person. Examples include e-mail, usernames, identifiers such as google ad id, apple id, fxaccount, city or country (unless small ones are explicitly filtered out), or certain cookies. It may be embedded within specific website content, such as memory contents, dumps, captures of screen data, or DOM data.<br />
<br />
== Eligibility for Default on Data Collection ==<br />
* Categories 1 & 2 (Technical & Interaction data)<br />
** Pre-Release & Release: Data may default on, provided the data is exclusively in these categories (it cannot be in any other category). In Release, an opt-out must be available for most types of Technical and Interaction data. Teams may limit data collection to pre-release populations if appropriate for testing/validation, cost reduction, or risk mitigation.<br />
<br />
* Category 3 (Web activity data)<br />
** Pre-Release: May be eligible for default on data collection, provided there is an opt-out.<br />
** Release: Default off.<br />
*** On a case-by-case basis collections may be eligible to be "default on" if mitigations are identified. Mitigations may include UX changes that make users aware of additional risk, technical mechanisms that remove the risk, or a risk assessment done of a case-by-case basis that determines the risk is limited.<br />
<br />
* Category 4 (Highly Sensitive data)<br />
** Pre-Release: Default off. May be eligible for opt-in data collection by specific users, provided there is (i) advance user notice (ii) consent and (iii) an opt-out.<br />
** Release: Default off. May be eligible for opt-in data collection by specific users, provided there is (i) advance user notice (ii) consent and (iii) an opt-out.<br />
<br />
== Other Practices ==<br />
<br />
Every year, the data collection owner and peers will survey all of the existing data collection systems with Firefox. This survey has the following goals:<br />
<br />
* To ensure that it is still necessary and useful to collect a piece of data.<br />
* To re-identify who is responsible for the collection, monitoring, and reporting of collected data.</div>MrElveyhttps://wiki.mozilla.org/index.php?title=MozillaWiki_talk:Spam&diff=1200209MozillaWiki talk:Spam2018-08-29T04:36:19Z<p>MrElvey: :-)</p>
<hr />
<div>Are any admins monitoring this page for new spam reports to deal with?<br />
[[User:SpikeUK1|SpikeUK1]] ([[User talk:SpikeUK1|talk]]) 23:19, 7 January 2015 (PST)<br />
:Well, now you're an admin... :-) --[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 04:36, 29 August 2018 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=User_talk:Callek&diff=1200208User talk:Callek2018-08-29T04:33:58Z<p>MrElvey: Help, please. (Don't delete *this* page.</p>
<hr />
<div>thx for your note on en:WP. I would prefer to keep the page and explain how bugs are handled. I wrote why I don't use bugzilla. [[User:Tobias Conradi|Tobias Conradi]] 06:39, 30 May 2006 (PDT)<br />
<br />
http://wiki.mozilla.org/index.php?title=User_talk%3ATobias_Conradi&diff=27045&oldid=27038<br />
[[User:Tobias Conradi|Tobias Conradi]] 06:38, 1 June 2006 (PDT)<br />
<br />
== answer ==<br />
<br />
see my answer at [[User talk:Tsahi]] [[User:Tsahi|Tsahi]] 14:32, 12 June 2006 (PDT)<br />
<br />
== templates to delete ==<br />
<br />
why don't you delete the two templates in the [[:category:delete|delete category]]? if you think they shouldn't be deleted (and it seems like you have authority here) take them out of the category, but i see no point in leaving them there and not deleting them, while you delete other articles i mark for deletion. [[User:Tsahi|Tsahi]] 11:43, 18 June 2006 (PDT)<br />
<br />
== Bugmenot ==<br />
<br />
Bugmenot.com -- 'nough said. [[User:Reed|reed]] 21:48, 18 April 2007 (PDT)<br />
<br />
== Spam, spammer ==<br />
<br />
Spammer:Probably needs to be blocked, and all edits reverted: https://wiki.mozilla.org/Special:Contributions/Ionutpop<br />
<br />
Spam: I'm posting here cuz I didn't find anything (at Help, Community portal,... to suggest a better response.) <br />
:(update) Aha: [[Report_Spam]] would be the place, if an admin was watching it, that is.--[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 10:12, 20 August 2013 (PDT)<br />
<br />
:: {{spam}} Admin cleanup still needed.--[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 04:33, 29 August 2018 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Session_Restore&diff=1200207Session Restore2018-08-29T04:23:27Z<p>MrElvey: Undo revision 490066 by Ionutpop (talk)</p>
<hr />
<div>''Please comment in the Talk page (use the Discussion tab above)''<br />
<br />
= Goals & Objectives =<br />
<br />
After a forced restart, restore the user's workspace exactly as it was.<br />
<br />
= Overview =<br />
<br />
The state of various window, tab and user-data will be saved, and reloaded upon application start. The feature will be passive, reacting only to forced-restarts such as extension installation and crashes. This minimal implementation provides an unobtrusive user-experience while meeting the broadest use-cases. The API will provide a stable and intuitive base which power-user oriented extensions, or expanded features in future releases, can build upon.<br />
<br />
= Features =<br />
<br />
* Save data for each window and tab (P1)<br />
* Automatically restore the session data upon restarting from a forced closure (P1)<br />
* If post-crash, allow the user to choose whether to restore (P1)<br />
* Allow the user to "undo" closing a tab or window (P2)<br />
<br />
= UI =<br />
<br />
* Prompt for restore upon application start, post-crash.<br />
<center><br />
http://static.flickr.com/51/143165490_72557bc74c.jpg<br />
</center><br />
<br />
= Usage and Configuration =<br />
<br />
The default settings will restore the session after a crash and previous history will be restored to a certain point.<br />
<br />
== Preferences ==<br />
<br />
See [http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js#750 the source] for currently available settings and their default values.<br />
<br />
* browser.sessionstore.enabled (bool) - Activate the service. Default is true. May not appear in about:config until changed. Valid for Firefox 2 and 3, superseded since Version 3.5.<br />
* browser.sessionstore.interval (integer) - minimal interval between saving operations in milliseconds. Default is 10000.<br />
* browser.sessionstore.max_resumed_crashes (integer) - Number of crashes that can occur before the about:sessionrestore page is displayed. Default is 1. So the user is asked after the second crash which pages he wants to restore.<br />
* browser.sessionstore.resume_from_crash (bool) - Resume sessions post-crash. Default is true.<br />
* browser.sessionstore.resume_session_once (bool) - Resume session at the next application start, but not again. Default is false. This is used for restarting the browser after application updates and extension installation.<br />
* browser.startup.page (int) - What is displayed when Browser starts: 0 = blank page; 1 = homepage; 3 = previous session. Default is 1. (Note: Firefox exposes this preference in the Startup section of the Main pane of the Options/Preferences dialog.)<br />
<br />
= Technical Design =<br />
<br />
== Implementation ==<br />
<br />
The feature is implemented as an XPCOM service. It registers for events such as windows and tab open/close, collects the current state of the browser, and periodically writes that state to disk.<br />
<br />
* Code location: http://lxr.mozilla.org/seamonkey/source/browser/components/sessionstore/<br />
* Data location: File sessionstore.js in profile directory, backup in sessionstore.bak<br />
<br />
== Data to be saved ==<br />
<br />
* All open windows and tabs<br />
* Width, height, and position of each window<br />
* Scroll position within each scrollable area in each window<br />
* Tab histories<br />
* Cookies<br />
* Text typed in forms<br />
* Restart downloads<br />
<br />
== API ==<br />
<br />
The API should allow session information to be easily accessed by extensions. An extension could store session info on a remote server, and allow users to restore the same session from multiple computers. This is currently a feature of the SessionSaver extension that doesn't really fit into the core browser.<br />
<br />
The API details and discussion are at [[SessionRestoreAPI]].<br />
<br />
= Privacy =<br />
<br />
Currently, the saved session data is cleared at shutdown, except in scenarios where the feature has been directed to intentionally save it, which are:<br />
<br />
* The application crashed<br />
* A forced restart, such as extension install or application update<br />
* The user has chosen to always resume sessions<br />
<br />
The saved session data is also cleared upon receiving the "browser:purge-session-history" notification.<br />
<br />
The data is stored on disk as a serialized javascript data structure (though it's possible that it will be converted to JSON once that becomes natively supported by Gecko/Spidermonkey). An open question is to whether this should be encrypted in some manner. See the Discussion page for more ideas about this.<br />
<br />
= To-do =<br />
<br />
* Implement undo close window<br />
* Implement user saving/loading of sessions<br />
* Can we use FastBack data to speed up undo close tab/window?<br />
<br />
= Unresolved Questions =<br />
<br />
* Storing cookies: Is it okay to persist cookies that are supposed to expire when the session ends? What about SSL cookies?<br />
<br />
* If we store cookies, should they also be stored when the user manually saves a session?<br />
<br />
* GET URLs: Bad things can happen if we reload a URL with a GET request that has side-effects. This has definitely been a problem for Google Web Accelerator.<br />
<br />
* <s>Do we ever want to store cached copies of the pages (i.e. for offline access) or do we just store the URLs and load them all? Loading from cache would be snappier. If any caching is done, should obey whatever caching directives.</s> - Pages are currently pulled from the browser cache, if available.<br />
<br />
* <s>Make sure that if the state of the current session crashes the browser, it doesn't reload at startup and crash over and over again. Look into how SessionSaver and Total Recall detect this.</s> - If the previous session crashed, the user is prompted with a choice as to whether to reload it.<br />
<br />
* If there are multiple windows open, how do we decide what was the last session? The last window closed, or the last group of windows?<br />
<br />
* Should form state include saving checkbox and selectbox state as well as text input?<br />
<br />
= User-friendly documentation =<br />
<br />
See this Knowledge Base entry: http://support.mozilla.com/en-US/kb/Session+Restore<br />
<br />
== Relevant Bugs ==<br />
<br />
Current implementation:<br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=356050 bz356050]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=328154 bz328154] - Tracking bug for feature inclusion in Fx2<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=343876 Session restore when all last sessions tabs were closed should obey user homepage choice for the initial blank tab]<br />
Older:<br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=19454 bz19454]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=36810 bz36810]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=63094 bz63094]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=159357 bz159357]<br />
<br />
== Relevant Extensions==<br />
<br />
* MultiZilla's Tab Session Manager<br />
** http://multizilla.mozdev.org/features/session-manager.html<br />
* Session-Saver<br />
** http://forums.mozillazine.org/viewtopic.php?t=47184<br />
** http://kb.mozillazine.org/SessionSaver<br />
* [http://tmp.garyr.net/ Tab Mix Plus]<br />
* [http://forums.mozillazine.org/viewtopic.php?t=164513 Crash Recovery] / [http://forums.mozillazine.org/viewtopic.php?t=380534 Session Manager]<br />
* [http://recall.mozdev.org/ Total Recall]<br />
<br />
= Other Features =<br />
<br />
Some features that should be either P2, FF3 or left to extensions:<br />
<br />
* Allow the user to �save�? a particular session at any time, and load saved sessions either by default at startup or from a menu<br />
* Allow the user to choose which pages to restore, post-crash</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Labs/Jetpack/Weekly_Meeting/2011-10-18&diff=1200206Labs/Jetpack/Weekly Meeting/2011-10-182018-08-29T04:22:53Z<p>MrElvey: Undo revision 498527 by Ionutpop (talk)</p>
<hr />
<div>= Agenda =<br />
* FlightDeck<br />
* SDK<br />
** 1.2 Release today!<br />
** Need to replace translate docs examples, brain-storming etherpad: https://jetpack.etherpad.mozilla.org/replace-gtranslate-example<br />
* Bugs<br />
* Roundtable<br />
** (dcm) Our goals have to change thanks to Mobile UI shift:<br />
***Goals for end of Q4<br />
l10n - Build an API that allows devs to localize js strings<br />
l10n - Have a plan for localizing html files <br />
e10s - Build a prototype SDK that supports content processes on desktop<br />
e10s - Build a prototype SDK that can build add-ons that run in their own process <br />
mobile - Build a prototype SDK that can build add-ons that use non-UI based features for Fennec<br />
** SDK Hack Day update<br />
<br />
= Attendees =<br />
<br />
* canuckistani<br />
* dcm<br />
* mossop<br />
* kwierso<br />
* warner<br />
* myk<br />
* gozala<br />
* ochameau<br />
* wbamberg<br />
* ejpbruel<br />
* dhorner<br />
* krizsa<br />
* zalewa<br />
* dbuc<br />
* arron<br />
* jorge<br />
<br />
= Minutes =<br />
<br />
== SDK 1.2 ==<br />
<br />
* dcm: SDK 1.2 to be released today!<br />
<br />
* Jeff: need to replace Google Translate example by December 1<br />
* have some ideas, have etherpad for brainstorming<br />
* https://jetpack.etherpad.mozilla.org/replace-gtranslate-example<br />
* http://nopalax.com - nopalax Jetpack event<br />
* dcm: ask forum for ideas<br />
<br />
* myk: saw references to addon.mozilla.org, but current docs are at addons.mozilla.org<br />
* want to make sure docs expect to be at correct URL<br />
* wbamberg: some references to one, some to the other<br />
* but docs correctly expect to be at addons.mozilla.org<br />
<br />
== FlightDeck ==<br />
<br />
* dbuc: repacker changes pushing to production on Wednesday<br />
* new SDK will be made available once it is released today<br />
* frontend and backend changes happening (new template system)<br />
* search template being redone<br />
<br />
* would like to meet this week to discuss docs and hosting examples<br />
* -> wbamberg to set up meeting<br />
<br />
== Roundtable ==<br />
<br />
* dcm: mobile team deciding to switch to native ui on android<br />
* this impacts timeline<br />
* adjusted Q4 goals for team<br />
* mobile goal at risk<br />
* other stuff we should be able to do by end of quarter<br />
<br />
* ejpbruel: does this mean e10s work is only relevant on desktop for now?<br />
* all: yes<br />
* ejpbruel: potential opportunity to do platform work on new native interface?<br />
* dcm: probably best discussed with mossop<br />
<br />
* myk: keep in mind that a future version of android will have better support for multi-process<br />
* and current android has support for multi-thread, which we could take advantage of<br />
* dbuc: android 4 announced soon, should have support for multi-process<br />
<br />
* canuckistani: hack day venue has changed<br />
* r2d2/c3po not available (mobile war room), we're going to do it in 10forward<br />
* single track instead of dual track<br />
* room booked, catering booked<br />
<br />
* canuckistani: how do developers test on mobile fennec?<br />
* ...<br />
<br />
* ochameau: update on mozcamp?<br />
* canuckistani: we're doing a talk<br />
* dcm: canuckistani got arky to give talk at kuala lumpur mozcamp<br />
* canuckistani: he'll also be in berlin and is localization coordinator for southeast asia region<br />
<br />
* ochameau: any plan to simplify xpis? would be useful for uploading xpis to localization service<br />
* warner: i think we should do it; i'll help<br />
* ochameau: any particular simplifications in mind?<br />
* warner: general idea is to have only one resource protocol mapping and break the directory whose name has several components (like the package name) into individual directories<br />
* ochameau: i have a patch that does some simplification<br />
* gozala: my "no runtime search" patch depends on it<br />
* ochameaeu: i'll keep in touch with daniel to make sure repacks continue to work<br />
<br />
* dcm: we decided to do repacks for all addons again for 1.2, as we did for 1.1<br />
* partly because we don't yet have way of distinguishing between Builder and local addons<br />
* will also allow people to digest our change to not do repacks for local addons<br />
* dcm: also myk says we might not need to repack for 1.3<br />
<br />
* myk: yes, 1.2 currently passes tests on aurora, central branches<br />
* which means compatibility with firefox 9, 10<br />
* 10 compatibility can change nightly, but 9 compatibility is less likely to change<br />
* and if we make it through aurora period, it probably won't change<br />
<br />
* dbuc: we have a flag in AMO to identify addons that shouldn't be updated<br />
* we could expose this better to developers and let them decide<br />
* gozala: what about the addon that checked that box and got repacked anyway?<br />
* dbuc: yes, the flag wasn't being respected but will be</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Talk:Firefox/Shield/Heartbeat&diff=1200205Talk:Firefox/Shield/Heartbeat2018-08-29T04:20:27Z<p>MrElvey: add'l comment.</p>
<hr />
<div>==Jargon, actual usage==<br />
Lots of jargon. Should, for example, 'User Voice' link to a definition? To https://www.uservoice.com/? I'd guess yes, but https://ffdevtools.uservoice.com/ is dead... Agree? Make it so. <br />
<br />
Also, it's being used for other things. E.g. to let folks know about [https://screenshots.firefox.com/?source=heartbeat&surveyversion=56&updateChannel=release&fxVersion=61.0.2&isDefaultBrowser=1&searchEngine=google-2018&syncSetup=1&utm_source=firefox&utm_medium=show-heartbeat&utm_campaign=Youcaneasilyscreenshotandshareanywebsite&type=button&flowId=munged Firefox screenshots beta]. --[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 04:15, 29 August 2018 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Talk:Firefox/Shield/Heartbeat&diff=1200202Talk:Firefox/Shield/Heartbeat2018-08-29T04:15:19Z<p>MrElvey: Created page with "==Jargon== Lots of jargon. Should, for example, 'User Voice' link to a definition? To https://www.uservoice.com/? I'd guess yes, but https://ffdevtools.uservoice.com/ is de..."</p>
<hr />
<div>==Jargon==<br />
Lots of jargon. Should, for example, 'User Voice' link to a definition? To https://www.uservoice.com/? I'd guess yes, but https://ffdevtools.uservoice.com/ is dead... Agree? Make it so. --[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 04:15, 29 August 2018 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=User_talk:Callek&diff=697245User talk:Callek2013-08-20T17:12:39Z<p>MrElvey: /* Spam, spammer */ new section</p>
<hr />
<div>thx for your note on en:WP. I would prefer to keep the page and explain how bugs are handled. I wrote why I don't use bugzilla. [[User:Tobias Conradi|Tobias Conradi]] 06:39, 30 May 2006 (PDT)<br />
<br />
http://wiki.mozilla.org/index.php?title=User_talk%3ATobias_Conradi&diff=27045&oldid=27038<br />
[[User:Tobias Conradi|Tobias Conradi]] 06:38, 1 June 2006 (PDT)<br />
<br />
== answer ==<br />
<br />
see my answer at [[User talk:Tsahi]] [[User:Tsahi|Tsahi]] 14:32, 12 June 2006 (PDT)<br />
<br />
== templates to delete ==<br />
<br />
why don't you delete the two templates in the [[:category:delete|delete category]]? if you think they shouldn't be deleted (and it seems like you have authority here) take them out of the category, but i see no point in leaving them there and not deleting them, while you delete other articles i mark for deletion. [[User:Tsahi|Tsahi]] 11:43, 18 June 2006 (PDT)<br />
<br />
== Bugmenot ==<br />
<br />
Bugmenot.com -- 'nough said. [[User:Reed|reed]] 21:48, 18 April 2007 (PDT)<br />
<br />
== Spam, spammer ==<br />
<br />
Spammer:Probably needs to be blocked, and all edits reverted: https://wiki.mozilla.org/Special:Contributions/Ionutpop<br />
<br />
Spam: I'm posting here cuz I didn't find anything (at Help, Community portal,... to suggest a better response.) --[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 10:07, 20 August 2013 (PDT)<br />
<br />
== Spam, spammer ==<br />
<br />
Spammer:Probably needs to be blocked, and all edits reverted: https://wiki.mozilla.org/Special:Contributions/Ionutpop<br />
<br />
Spam: I'm posting here cuz I didn't find anything (at Help, Community portal,... to suggest a better response.) <br />
:(update) Aha: [[Report_Spam]] would be the place, if an admin was watching it, that is.--[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 10:12, 20 August 2013 (PDT)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=User_talk:Callek&diff=697240User talk:Callek2013-08-20T17:07:49Z<p>MrElvey: /* Spam, spammer */ new section</p>
<hr />
<div>thx for your note on en:WP. I would prefer to keep the page and explain how bugs are handled. I wrote why I don't use bugzilla. [[User:Tobias Conradi|Tobias Conradi]] 06:39, 30 May 2006 (PDT)<br />
<br />
http://wiki.mozilla.org/index.php?title=User_talk%3ATobias_Conradi&diff=27045&oldid=27038<br />
[[User:Tobias Conradi|Tobias Conradi]] 06:38, 1 June 2006 (PDT)<br />
<br />
== answer ==<br />
<br />
see my answer at [[User talk:Tsahi]] [[User:Tsahi|Tsahi]] 14:32, 12 June 2006 (PDT)<br />
<br />
== templates to delete ==<br />
<br />
why don't you delete the two templates in the [[:category:delete|delete category]]? if you think they shouldn't be deleted (and it seems like you have authority here) take them out of the category, but i see no point in leaving them there and not deleting them, while you delete other articles i mark for deletion. [[User:Tsahi|Tsahi]] 11:43, 18 June 2006 (PDT)<br />
<br />
== Bugmenot ==<br />
<br />
Bugmenot.com -- 'nough said. [[User:Reed|reed]] 21:48, 18 April 2007 (PDT)<br />
<br />
== Spam, spammer ==<br />
<br />
Spammer:Probably needs to be blocked, and all edits reverted: https://wiki.mozilla.org/Special:Contributions/Ionutpop<br />
<br />
Spam: I'm posting here cuz I didn't find anything (at Help, Community portal,... to suggest a better response.) --[[User:MrElvey|MrElvey]] ([[User talk:MrElvey|talk]]) 10:07, 20 August 2013 (PDT)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Features/Firefox/Network_Installer&diff=353618Features/Firefox/Network Installer2011-09-30T20:12:45Z<p>MrElvey: per Corey Shields at Bug 687783; currently, installs are normally insecure.</p>
<hr />
<div>{{FeatureStatus<br />
|Feature name=Network Installer<br />
|Feature stage=Design<br />
|Feature status=In progress<br />
|Feature health=OK<br />
}}<br />
{{FeatureTeam<br />
|Feature product manager=Kev Needham<br />
|Feature feature manager=Kev Needham<br />
|Feature lead engineer=Rob Strong<br />
|Feature security lead=TBD<br />
|Feature privacy lead=TBD<br />
|Feature localization lead=TBD<br />
|Feature accessibility lead=TBD<br />
|Feature qa lead=TBD<br />
|Feature ux lead=Alex Faaborg<br />
|Feature product marketing lead=Laura Mesa<br />
|Feature additional members=IT Required for Infra Impact<br />
}}<br />
{{FeaturePageBody<br />
|Feature overview=The Mozilla Network Installer will be a lightweight, fully localized Windows and OSX installer allows a user to select Mozilla applications and/or related components which are then downloaded in the background and installed. The download and installation process should survive unexpected terminations of the installation process, and be able to include Mozilla applications, addons, and/or third-party components.<br />
<br />
In addition to the default shipping applications, the installer should be configurable to download a specific, Mozilla-authorized customization package which would be applied post-installation of the Mozilla app prior to first-run. This would help simplify the administration overhead of customized repacks, and provide additional methods of distributing Firefox to end-users.<br />
|Feature users and use cases=* Installation of default versions of Mozilla products (Firefox, Thunderbird)<br />
* Installation of default versions of Mozilla products plus authorized addon(s) (combinations of extensions, search plugins, themes, and/or personas)<br />
* Installation of default versions of Mozilla products bundled with authorized, secondary installer(s) (e.g. Network installer functions as a meta installer)<br />
* Installation of authorized, customized versions of Mozilla products (e.g. product plus contents of distribution directory, with option for secondary installer(s))<br />
|Feature dependencies=* Latest MozillaBuild with NSIS 2.46 unicode<br />
* l10n strings/support<br />
|Feature requirements=* Small footprint<br />
* Fully localized<br />
* Digitally signed<br />
* Command line options for silent operation<br />
* Use https for all network requests<br />
* Auto-detect 32/64-bit Windows OS and download appropriate components<br />
* Can be used with a pre-stuffed cache as a full installer<br />
|Feature non-goals=* Replacement of existing installers<br />
* Linux support<br />
* Peer-to-peer download supports<br />
|Feature functional spec=UI Mockup for initial stub installer is in {{bug|651965}} as a [https://bug651965.bugzilla.mozilla.org/attachment.cgi?id=543348 1.3MB attachment]<br />
|Feature ux design=* Work like any other installer<br />
* Provide estimated download times<br />
* Allow for pause/resume, including resumption when process terminated<br />
|Feature security review=The installer will be downloaded securely and then itself ensure the integrity of the binaries.<br />
}}<br />
{{FeatureInfo<br />
|Feature priority=P3<br />
|Feature roadmap=User Engagement<br />
|Feature list=Desktop<br />
|Feature engineering team=Desktop front-end<br />
}}<br />
{{FeatureTeamStatus}}<br />
<h2>Related Information</h2><br />
<br />
* {{bug|322206}} Firefox net / stub installer (Original bug from Firefox 2.0)<br />
* {{bug|675970}} [Tracking Bug] Stub Installer Project<br />
* {{bug|651965}} Installer user interface rewrite<br />
* [[User:Beltzner/Specification_of_Stub_Installer_User_Interface|Original Stub Installer UI Spec]] (from Beltzner)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Talk:Session_Restore&diff=229939Talk:Session Restore2010-06-11T05:00:37Z<p>MrElvey: /* A possibly better way to secure the data */ resume_from_crash setting exists.</p>
<hr />
<div>== Tab Mix? ==<br />
I'm not sure if regular old me is allowed to edit the main page even for this, so I'm just going to mention it here. AFAIK, it's [http://tmp.garyr.com/ Tab Mix Plus] that does session saving and whatnot, not regular Tab Mix. -- [[User:Peng|Matt Nordhoff]] [[User talk:Peng|(talk)]] 00:34, 9 Feb 2006 (PST)<br />
<br />
<br />
<br />
== Security of saved data ==<br />
Just as a precaution, the data that is saved in order to restore the session should be safe from potential reading. For example, you have several tabs open and some form information filled in on one, including your banking details. The session saver saves these details in order to restart Firefox, but afterwards when the user is finished and they close the browser, is this information left laying about on the hard disk, that could potentially be stolen by rogue software or exploits.<br />
<br />
Also what would happen if after a restart by session saver, you cleared the history with Ctrl+Alt+Del. Even though the history would be removed from the browser cache, would the session saver cache be removed also to ensure that URLs and Form text were not left behind?<br />
:[[User:Kroc|Kroc]] 01:32, 9 Feb 2006 (PST)<br />
<br />
A robust solution would be that encryption was performed with a key that was created at random each time a session save occurred, and kept in config, or otherwise in the same manner all passwords are kept. It's not fully secure, but provided it's read-only and not read-write, it covers the basics: a session can be re-read by FF, the encryption key can't easily be pushed into FF by a user to read an old session, and when the key is overwritten at the point a new session is saved, the old key becomes permanently unreadable.<br />
<br />
The algorithm I'm thinking goes something like this:<br />
# Session files have timestamp or incremental ID in their filename - "SavedSession03102006054627"<br />
# The ID and encryption key pair for the last <n> saved sessions is held. ("n", so that users can keep up to 3 or 5 previous state backups in case one or more become corrupted in a crash)<br />
# On restart, FF identifies the most recent saved session that it can decrypt and which has full integrity, and works with that backup. It also deletes any that it couldn't decrypt or which appear corrupted, and any key entries that don't appear to relate to actual valid saved session files.<br />
# When a new session backup is made, FF creates a random 256 bit key, encrypts the backup with that, and saves the new backup timestamp/decryption key pair for future use.<br />
# When the backup is confirmed saved, then if there are more than <n> backups held, the file and key for the oldest one(s) are deleted.<br />
# If the key file ID and key are held in a place the user can see within FF, there is code to prevent copy or pasting of that data.<br />
<br />
I don't think you can do much better. Any code FF used to access the saved states on restart could be emulated by a rogue user or software. What this does is ensure that the files by themselves are harmless, that one key (if obtained) does not give access to any older backed up session files, and that a user cannot just copy and use the key to open a file. Any better security would require a user password on starting FF or similar, as well as all FF saved data and cache to be encrypted; it can't easily be done by FF alone.<br />
<br />
As an amateur newcomer to FF this would seem to cover many of the bases, and deal with the main problems identified above. [[User:Foxxen2|Foxxen2]] 08:57, 30 March 2006 (PST)<br />
<br />
About the password, that's not a bad idea!<br />
Assuming secret data will be sent over a secure connection, firefox could, when the users exits with a https site open, ask if it has to encrypt the data, and if so, ask to give a password to reopen it. If the password can't be supplied the encrypted data will be lost, which will mostly not be a serious problem.<br />
<br />
If a website doesn't use https, it is open to much more ways to get the information, so I don't think it is firefox's task to protect the data in that case.<br />
<br />
--[[User:FrederikVds|FrederikVds]] 15:04, 6 April 2006 (PDT)<br />
<br />
=== An opposing view ===<br />
These suggestions seem over-designed, to me. The same logic would apply to any sensitive information stored on your computer. What about email addresses in your mail program? Financial accounting information for your company? By the same logic, all this should be encrypted too.<br />
<br />
One problem with encrypting the information is that it's unrecoverable if you forget the password, or if there's a tiny data error through hardware faults that corrupt a bit. Nor can you dive in with a text editor and delete the saved URL that's causing your browser to crash. The session data is a black box, uneditable. On the design side, I argue that it goes against the Unix philosophy of modular easily-connected components. If you want encryption, save it to an encrypted file system, or encrypt the files with PGP or something.<br />
<br />
IMHO, the file format for the saved session should be XML or even plain text. The most I'd suggest as far as security would be to avoid storing cookies or form data or passwords. Let the browser request fresh cookies, and the user re-enter their passwords etc., upon reload.<br />
<br />
--[[User:LukeKendall|LukeKendall]] 10:30, 18 July 2006 (EST)<br />
<br />
== Restoring after voluntary exit not optional ==<br />
<br />
The main page currently (2006-02-13) lists this as an optional (P2,<br />
FF3 or left to extensions) feature:<br />
<br />
"Allow session restoration after voluntary application closure"<br />
<br />
From my point of view, this is not an optional feature. The only time<br />
I ever make Firefox exit is to work around some bug (e.g., using too<br />
much memory, incapable of handling new extensions without restart,<br />
etc.). Otherwise my invocation of Firefox would run forever. Thus,<br />
for me, every manual exit of Firefox is undesired and equivalent to a<br />
forced crash. Generally I have dozens of tabs representing weeks or<br />
months of work that I definitely do not want to lose! If this feature was missing I would have to continue using SessionSaver, which would be undesirable.<br />
<br />
Joe<br />
--[[User:Sllewbj|Sllewbj]] 05:27, 13 Feb 2006 (PST)<br />
<br />
<br />
Agree 100%! I came to SessionSaver for the crash recovery, but stayed for the non-crash session saving. It's incredibly useful when having to reboot your OS (e.g. because you installed a new piece of software, or applied OS or third-party software patches), or when having to shut down your laptop because you're on the go, to be able to save your work in Firefox the same way you can in document-oriented software applications, and be able to pick right back up where you left off after you've restarted and logged back in. It would be silly not to implement this and would just mean lots of people would be forcibly killing their own browsers in order to save their sessions.<br />
<br />
-- [http://harkless.org/dan/ Dan Harkless], 23:17, 16 Feb 2006 (PST)<br />
<br />
Agreed this is the right default but there still needs to be a mechanism to bypass restoration in case the browser is crashing or just browsed p0rn at work accidentally. SessionSaver has a detection for a crashing set for the first purpose. For the second, you might check for holding down Shift during startup, like a Macintosh for not loading extensions.<br />
<br />
--[[User:BillMcGonigle|BillMcGonigle]] 10:48, 21 Feb 2006 (PST)<br />
<br />
I'd say this feature is contrary to the privacy settings. I set firefox to clear private data when closing Firefox, yet this code circumvents that - when I restart, browsing history, etc, is there for all the world to see. At very least it should be switchable on/off by a user preferences option.<br />
<br />
== DOM restore vs. URL restore ==<br />
<br />
What if we serialized and restored the current DOM (including event handlers and such) for each tab, instead of storing the URLs? That would solve all of the problems with reloading of non-idempotent GETs, as well as POST cases, and properly restore the state of apps like gmail. (If we don't do this, then we need to be very careful about restoring form state against a possibly-different form when we restore the session and reload the page. There have been attacks related to changing an input from type=hidden to type=file on reload which I think we would prefer to not revisit.)<br />
<br />
: [[User:Shaver|Shaver]] 09:33, 13 Feb 2006 (PST)<br />
<br />
I agree that a DOM restore would be preferrable, as otherwise all POSTed pages would be lost.<br />
Also a DOM restore would be clearly faster if you have a slow internet connection.<br />
<br />
--[[User:FrederikVds|FrederikVds]] 16:19, 18 Mar 2006 (PST)<br />
<br />
What about sessions on web servers if you do storing of DOM? If we save URL then going by the link on restoring would probably load a page with notice that session is expired. Saving DOM, one could start putting data into a form, like doing long e-mail message and then during submit find out that the session is expired.<br />
<br />
--[[User:Sofoz|Sofoz]] 07:01, 15 July 2006 (PDT)<br />
<br />
I'm not sure if expired server sessions should be much of a concern. After all, the expiry would happen if you left the browser open or if you hibernated the OS. Trying to ensure fresh information in session restore case seems trying too hard and wouldn't be very consistent.<br />
<br />
--[[User:Aapo Laitinen|Aapo Laitinen]] 22:36, 18 July 2006 (PDT)<br />
<br />
== Use-cases for Session Restoration ==<br />
<br />
* Corporate environments: "Most have a policy which states that you have to turn off your computer when you leave for the night. Now assuming that not every employee stays at work in the evening until all work is done, I consider it reasonable for the user to expect to be able to start in the morning right where he has left in the evening, although the machine was switched off over the night."<br />
<br />
* "A second scenario is, that, unfortunately, since even FF is not bug free, one has to restart it occasionally when it starts to behave oddly. This is not a crash, it's a user requested quit, but I expect to start work again at exactly the point where I have left."<br />
<br />
* consultants/travelers: people who involuntarily shut down the browser many times each day<br />
<br />
* admins: people who log onto their user account at many other people's boxes, many times during the day, such as IT/helpdesk workers at large organizations<br />
<br />
* mobile: people who load FF, or their profile, off of a usb key.<br />
<br />
* Mozilla Testers!: Now that we have auto-updates in testing code, with real Session Restore I can just click 'Restart Now' and always be testing the latest nightly. This is a dream for quality of bug reports. --[[User:BillMcGonigle|BillMcGonigle]] 10:45, 21 Feb 2006 (PST)<br />
<br />
== Things Not to Do ==<br />
<br />
There are some things you don't want to do when restoring a session, as evidenced by bitter tastes from Session Saver.<br />
<br />
* Don't re-POST forms. Session Saver will do this. I had 5 duplicate bugzilla bugs once before I realized what was happening. Imagine if I was using a poor shopping cart! --[[User:BillMcGonigle|BillMcGonigle]] 10:54, 21 Feb 2006 (PST)<br />
** If you can trust the maxim 'GET for actions without side effects, POST for actions with side effects' you could simply refuse to do POST on session restore. You can't actually trust that a web developer hasn't just decided to use POST for everything because "long URL's are ugly" but maybe it's the right thing to do anyway. --[[User:BillMcGonigle|BillMcGonigle]] 10:54, 21 Feb 2006 (PST)<br />
<br />
== Unresolved questions ==<br />
<br />
''Do we ever want to store cached copies of the pages (i.e. for offline access) or do we just store the urls and load them all? Loading from cache would be snappier.''<br />
* Well, there's multiple strategies:<br />
*# Don't load more than <n> pages at a time, giving the focussed tab 1st priority, allowing the user to work, and then giving priority to tabs the user is working on, as one tab loads, start another so there are always <n> tabs loading until it's recovered.<br />
*#:Advantages - user can work immediately, system is kept under moderate load, restore is probably transparent since any page the user works on is given priority.<br />
*# Load all from cache, then update as visited<br />
*#: Advantages - with luck the cached version should be what the user saw. But if it is we'll only know it if we reload, if it isn't then its misleading, and in any case since we then probably reload pages anyhow does the user benefit from loading the cached version of pages first?<br />
*# Check latest update times of all pages quickly (a lower bandwidth job), and those that have update times matching the cache entry, assume the cache is up to date, otherwise load from web as per (1).<br />
*#: Advantages - many pages will be up to date, so this saves reloading pages other than those changed. In theory this, compbined with (1) for loading web pages that do need reloading, should work. But would it?<br />
: [[User:Foxxen2|Foxxen2]] 09:24, 30 March 2006 (PST)<br />
<br />
<br />
''Make sure that if the state of the current session crashes the browser, it doesn�t reload at startup and crash over and over again. Look into how SessionSaver and Total Recall detect this.''<br />
* Whats really helpful would be a FF extension and page processing calls log that can be relied upon to note extension calls made (and their successful return) and page render or page processing calls made (and their successful completion). In theory when it crashes, very few extensions or pages will actually have commenced a call but not completed. Those will likely be the problem ones. beyond that its a problem with FF core code, and a safe start or debug session. The core of the problem is having a way to narrow down problematic pages and extensions. Perhaps if it crashes during a restore it offers to switch to a "safe restore" mode (as opposed to "safe mode"), where extensions are loaded one by one, then pages loaded one by one, and the cause of the crash identified and reported for debugging? Ie a fallback mode for restore where the user gets a slower restore, that keeps as many pages and extensions as it can alive. [[User:Foxxen2|Foxxen2]] 09:24, 30 March 2006 (PST)<br />
<br />
<br />
''Should form state include saving checkbox and selectbox state as well as text input?''<br />
* Yes. See above, re text box contents, same applies. [[User:Foxxen2|Foxxen2]] 09:24, 30 March 2006 (PST)<br />
<br />
''If there are multiple windows open, how do we decide what was the last session? The last window closed, or the last group of windows?''<br />
* If they're all exited together, by quitting from FF, the answer is clearly that all should be saved.<br />
* But I think better would be to have an explicit Save Session and Restore Session function. Then the semantics can simply be to hold the session for auto reload (or prompted reload) after a crash; but normally to require an explicit Restore Session action by the user.<br />
[[User:LukeKendall|LukeKendall]] 10:20, 18 July 2006 (EST)<br />
<br />
''There should be an option to disable 'cookie restore'. I don't like the feeling that after crash or shut down any body can come on pc and login to my gmail and other accounts. Yes I can disable the sessions entirely but this will remove the feature entirely. I like session restoration in Opera but in FireFox it is less secure.<br />
<br />
== Crash Recovery and Session Manager have good code ==<br />
<br />
[http://forums.mozillazine.org/viewtopic.php?t=164513 Crash Recovery] and [http://forums.mozillazine.org/viewtopic.php?t=380534 Session Manager], both developed by zeniko, have good code.<br />
<br />
They're both listed under [[Session_Restore#Relevant_Extensions Relevant Extensions]] on the Session Restore page.<br />
<br />
Crash Recovery only runs when your browser crashes, not on every restart.<br />
Session Manager allows the user to restore session on every restart.<br />
<br />
It also includes the following features and more:<br />
* Session Management (Saving, Renaming, Deleting, Overriding)<br />
* Session Loading Options<br />
* POSTDATA, cookies, and form data saving<br />
* Reopen Closed Tab / Window<br />
* Restore closed tab / window list on startup<br />
<br />
-- [[User:Desertfox|Frank (DesertFox)]] [[User talk:Desertfox|(talk)]] 21:58, 8 Apr 2006 (CDT)<br />
<br />
= UI =<br />
(moved from front page)<br />
* Prompt for restore upon application start, post-crash.<br />
<br />
For reference, this is a screenshot of the similar feature in the Gnome web-browser, Epiphany:<br />
<br />
http://actsofvolition.com/images/screenshots/firefox/epiphany-session-restore.png<br />
<br />
= Privacy =<br />
[moved from front page]<br />
<br />
Are there any privacy issues? Doesn't seem to be, as most (all?) of this information is already stored somewhere already, eg: history, cookies, etc.<br />
<br />
There are most certainly privacy issues, just as there are with history, cookies etc. Hence the proliferation of utilities that remove tracking footprints.<br />
<br />
Privacy can be an issue. Saving the detailed session includes elements of<br />
history, bookmarks. cookies, typed form information, etc.. and all of these<br />
have purge functions to erase tracks already implemented. The concept of<br />
saving session infos would seem to conflict with the desire for privacy. But<br />
need there be such a conflict?<br />
<br />
What about encrypting the saved session info, so that the files containing the data are not 'in plain language', readable in notepad. After a crash, perhaps a password would be required to re-open the last known session. Without the password, it opens to about:blank.<br />
<br />
= Comment from an Ordinary User =<br />
<br />
There is, in some people's opinion, a serious and potentially dangerous security and privacy risk. This is caused by the fact that if the Cache is stored in RAM (a disk drive created in RAM whose contents 'disappear' when the power is removed), material to restore pages is then saved on conventional hard disk. As at Firefox version 2.0 the last viewed web pages are reproduced perfectly without a connection being re-established with the remote server. This is done when the Cache was on RAM disk and after the computer's power had been turned-off for 12 hours!<br />
<br />
Firefox's restore session ability must be loved and admired by Big Brother throughout the world. With anti-virus checkers deliberately ignoring "official" security service bugs and trojans and users becoming more aware of all the data Microsoft and its Internet Explorer saves about them, its probably inevitable that Mozilla, for whatever reason, started saving in secret information about its user's browsing habits!<br />
<br />
It is a material consideration that Firefox does not permit ordinary users the ability to turn-off this security and privacy violating feature. If this feature is genuinely for the good of Firefox users, then Firefox ought to allow users to opt out easily and, of course, effectively and permanently. The fact that no such easily available disabling facility exists in Firefox clearly suggests the personal privacy and security of Firefox users was not adequately considered by Firefox's team. Why not?<br />
<br />
A Mozilla User, 24 December 2006.<br />
<br />
{Another user (wsanders): <br />
<br />
Forget about the security and all that, it's an annoying feature since I and probably a bunch of other users normally exit by powering off the computer, exiting X/Gnome/KDE with Ctrl-Alt-Delete, or typing "init 0". All these make Firefox 2 think it has crashed, and annoy with a startup message next time it's launched. One should be able to at least disable this feature in about:config.<br />
<br />
'''never''' - Never save closed tabs in sessions and delete all closed tabs when the browser is shutdown. Also closed tabs will not be restored from saved sessions that had been saved with closed tabs.<br />
<br />
[http://sessionmanager.mozdev.org/documentation.html http://sessionmanager.mozdev.org/documentation.html]<br />
<br />
= Understanding the Structure of sessionstore.js file =<br />
<br />
Hello all,<br />
<br />
Sorry to intrude on your work, but I have a question that I just cannot find an authoritative answer on and I'm not sure that this is the appropriate place to ask, but here goes... <br />
<br />
I am in law enforcement and currently looking at a fragment of data from unallocated space that *appears* to be in the same format as the a/n file. I need to determine what the nature of the fields are. I have a pretty good idea on most of them, but not all.<br />
<br />
For example, let's say this information excerpt:<br />
<br />
<br />
"... title"Hotmail", cacheKey:0, ID:1291, scroll:"0,0"}], index:1, zoom:1, disallow:"", xultab:""....."<br />
<br />
I can see from other pages on this wiki what some of these items do/store, for example scroll stores scroll bar position, but ID, where is the 1291 obtained from? Is this the 1291st browsing instance since the browser was started? I can't tell very well from the source code, but I'm not super fluent in js.<br />
<br />
Any help would be GREATLY appreciated. If this isn't the correct location for this, please let me know where I should ask.<br />
<br />
--[[User:G-man|G-man]] 12:22, 1 May 2008 (PDT)<br />
<br />
== Disable session restore ==<br />
<br />
I don't like the feature of Firefox that it tries to revisit or reload the webpages that caused my browser to crash. ... I desperatly want an option for NO session restore, ever.<br />
<br />
Set ''browser.sessionstore.max_resumed_crashes'' to 0. Firefox will ask after a crash which windows/tabs to restore. See more [[Session_Restore#Preferences|Preferences]] on front page. [[User:Hbbb|Hbbb]] 07:22, 27 October 2009 (UTC)<br />
<br />
== A possibly better way to secure the data ==<br />
<br />
One way that Firefox could secure the session restore automatically is using a hybrid asymmetric (like RSA, DSA, or ElGamal) and symmetric (like AES, Blowfish, Twofish, 3DES, or Serpent) encryption setup like what SSL, TLS, and PGP use. <br />
<br />
All it needs to do is create a asymmetric key pair with a password encrypted "Private Key" the first time Firefox opens and then whenever you load up Firefox it quickly creates a temporary symmetric key which it uses for that session to encrypt the session restore data with and it encrypts the temporary symmetric key with your asymmetric "Public Key". So then if you ever need to restore your session you will need your private key and the password the private keys encrypted with to decrypt the sessions temporary symmetric key. <br />
<br />
With asymmetric encryption you have a key pair with 2 keys a "Private Key" and a "Public Key" and you can give everyone your public key and when you encrypt something with someones "Public Key" the only way to decrypt the data is with that persons "Private Key" and the password the private key is encrypted with (technically it is possible to create a "Private Key" that isn't encrypted with a password then all you need is the "Private Key" to decrypt the data)<br />
<br />
:I'm with LukeKendall. Full Disk Encryption, or OS-level stuff like TrueCrypt, BitLocker and FileVault are the solution to this issue; no need to try and re-solve this problem. ''{But I'm going to add some of the info from http://www.blogsdna.com/4318/how-to-get-back-firefox-35-session-restore-page.htm and on sessionstore.js, which I think is key. (err, never mind about the latter; http://support.mozilla.com/en-US/kb/Session+Restore is the place for documentation.)}'' --[[User:MrElvey|MrElvey]] 04:47, 11 June 2010 (UTC)<br />
<br />
:Oh, and there's browser.sessionstore.resume_from_crash which is a partial fix to this issue for those who feel Firefox itself needs to be more careful with this sensitive/private info. --[[User:MrElvey|MrElvey]] 05:00, 11 June 2010 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Session_Restore&diff=229938Session Restore2010-06-11T04:56:46Z<p>MrElvey: rm ancient cruft. Link to KB dox.</p>
<hr />
<div>''Please comment in the Talk page (use the Discussion tab above)''<br />
<br />
= Goals & Objectives =<br />
<br />
After a forced restart, restore the user's workspace exactly as it was.<br />
<br />
= Overview =<br />
<br />
The state of various window, tab and user-data will be saved, and reloaded upon application start. The feature will be passive, reacting only to forced-restarts such as extension installation and crashes. This minimal implementation provides an unobtrusive user-experience while meeting the broadest use-cases. The API will provide a stable and intuitive base which power-user oriented extensions, or expanded features in future releases, can build upon.<br />
<br />
= Features =<br />
<br />
* Save data for each window and tab (P1)<br />
* Automatically restore the session data upon restarting from a forced closure (P1)<br />
* If post-crash, allow the user to choose whether to restore (P1)<br />
* Allow the user to "undo" closing a tab or window (P2)<br />
<br />
= UI =<br />
<br />
* Prompt for restore upon application start, post-crash.<br />
<center><br />
http://static.flickr.com/51/143165490_72557bc74c.jpg<br />
</center><br />
<br />
= Usage and Configuration =<br />
<br />
The default settings will restore the session after a crash and previous history will be restored to a certain point.<br />
<br />
== Preferences ==<br />
<br />
See [http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js#750 the source] for currently available settings and their default values.<br />
<br />
* browser.sessionstore.enabled (bool) - Activate the service. Default is true. May not appear in about:config until changed. Valid for Firefox 2 and 3, superseded since Version 3.5.<br />
* browser.sessionstore.interval (integer) - minimal interval between saving operations in milliseconds. Default is 10000.<br />
* browser.sessionstore.max_resumed_crashes (integer) - Number of crashes that can occur before the about:sessionrestore page is displayed. Default is 1. So the user is asked after the second crash which pages he wants to restore.<br />
* browser.sessionstore.resume_from_crash (bool) - Resume sessions post-crash. Default is true.<br />
* browser.sessionstore.resume_session_once (bool) - Resume session at the next application start, but not again. Default is false. This is used for restarting the browser after application updates and extension installation.<br />
* browser.startup.page (int) - What is displayed when Browser starts: 0 = blank page; 1 = homepage; 3 = previous session. Default is 1. (Note: Firefox exposes this preference in the Startup section of the Main pane of the Options/Preferences dialog.)<br />
<br />
= Technical Design =<br />
<br />
== Implementation ==<br />
<br />
The feature is implemented as an XPCOM service. It registers for events such as windows and tab open/close, collects the current state of the browser, and periodically writes that state to disk.<br />
<br />
* Code location: http://lxr.mozilla.org/seamonkey/source/browser/components/sessionstore/<br />
* Data location: File sessionstore.js in profile directory, backup in sessionstore.bak<br />
<br />
== Data to be saved ==<br />
<br />
* All open windows and tabs<br />
* Width, height, and position of each window<br />
* Scroll position within each scrollable area in each window<br />
* Tab histories<br />
* Cookies<br />
* Text typed in forms<br />
* Restart downloads<br />
<br />
== API ==<br />
<br />
The API should allow session information to be easily accessed by extensions. An extension could store session info on a remote server, and allow users to restore the same session from multiple computers. This is currently a feature of the SessionSaver extension that doesn't really fit into the core browser.<br />
<br />
The API details and discussion are at [[SessionRestoreAPI]].<br />
<br />
= Privacy =<br />
<br />
Currently, the saved session data is cleared at shutdown, except in scenarios where the feature has been directed to intentionally save it, which are:<br />
<br />
* The application crashed<br />
* A forced restart, such as extension install or application update<br />
* The user has chosen to always resume sessions<br />
<br />
The saved session data is also cleared upon receiving the "browser:purge-session-history" notification.<br />
<br />
The data is stored on disk as a serialized javascript data structure (though it's possible that it will be converted to JSON once that becomes natively supported by Gecko/Spidermonkey). An open question is to whether this should be encrypted in some manner. See the Discussion page for more ideas about this.<br />
<br />
= To-do =<br />
<br />
* Implement undo close window<br />
* Implement user saving/loading of sessions<br />
* Can we use FastBack data to speed up undo close tab/window?<br />
<br />
= Unresolved Questions =<br />
<br />
* Storing cookies: Is it okay to persist cookies that are supposed to expire when the session ends? What about SSL cookies?<br />
<br />
* If we store cookies, should they also be stored when the user manually saves a session?<br />
<br />
* GET URLs: Bad things can happen if we reload a URL with a GET request that has side-effects. This has definitely been a problem for Google Web Accelerator.<br />
<br />
* <s>Do we ever want to store cached copies of the pages (i.e. for offline access) or do we just store the URLs and load them all? Loading from cache would be snappier. If any caching is done, should obey whatever caching directives.</s> - Pages are currently pulled from the browser cache, if available.<br />
<br />
* <s>Make sure that if the state of the current session crashes the browser, it doesn't reload at startup and crash over and over again. Look into how SessionSaver and Total Recall detect this.</s> - If the previous session crashed, the user is prompted with a choice as to whether to reload it.<br />
<br />
* If there are multiple windows open, how do we decide what was the last session? The last window closed, or the last group of windows?<br />
<br />
* Should form state include saving checkbox and selectbox state as well as text input?<br />
<br />
= User-friendly documentation =<br />
<br />
See this Knowledge Base entry: http://support.mozilla.com/en-US/kb/Session+Restore<br />
<br />
== Relevant Bugs ==<br />
<br />
Current implementation:<br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=356050 bz356050]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=328154 bz328154] - Tracking bug for feature inclusion in Fx2<br />
<br />
Older:<br />
<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=19454 bz19454]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=36810 bz36810]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=63094 bz63094]<br />
* [https://bugzilla.mozilla.org/show_bug.cgi?id=159357 bz159357]<br />
<br />
== Relevant Extensions==<br />
<br />
* MultiZilla's Tab Session Manager<br />
** http://multizilla.mozdev.org/features/session-manager.html<br />
* Session-Saver<br />
** http://forums.mozillazine.org/viewtopic.php?t=47184<br />
** http://kb.mozillazine.org/SessionSaver<br />
* [http://tmp.garyr.net/ Tab Mix Plus]<br />
* [http://forums.mozillazine.org/viewtopic.php?t=164513 Crash Recovery] / [http://forums.mozillazine.org/viewtopic.php?t=380534 Session Manager]<br />
* [http://recall.mozdev.org/ Total Recall]<br />
<br />
= Other Features =<br />
<br />
Some features that should be either P2, FF3 or left to extensions:<br />
<br />
* Allow the user to �save�? a particular session at any time, and load saved sessions either by default at startup or from a menu<br />
* Allow the user to choose which pages to restore, post-crash</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Talk:Session_Restore&diff=229937Talk:Session Restore2010-06-11T04:50:04Z<p>MrElvey: /* A possibly better way to secure the data */ err...</p>
<hr />
<div>== Tab Mix? ==<br />
I'm not sure if regular old me is allowed to edit the main page even for this, so I'm just going to mention it here. AFAIK, it's [http://tmp.garyr.com/ Tab Mix Plus] that does session saving and whatnot, not regular Tab Mix. -- [[User:Peng|Matt Nordhoff]] [[User talk:Peng|(talk)]] 00:34, 9 Feb 2006 (PST)<br />
<br />
<br />
<br />
== Security of saved data ==<br />
Just as a precaution, the data that is saved in order to restore the session should be safe from potential reading. For example, you have several tabs open and some form information filled in on one, including your banking details. The session saver saves these details in order to restart Firefox, but afterwards when the user is finished and they close the browser, is this information left laying about on the hard disk, that could potentially be stolen by rogue software or exploits.<br />
<br />
Also what would happen if after a restart by session saver, you cleared the history with Ctrl+Alt+Del. Even though the history would be removed from the browser cache, would the session saver cache be removed also to ensure that URLs and Form text were not left behind?<br />
:[[User:Kroc|Kroc]] 01:32, 9 Feb 2006 (PST)<br />
<br />
A robust solution would be that encryption was performed with a key that was created at random each time a session save occurred, and kept in config, or otherwise in the same manner all passwords are kept. It's not fully secure, but provided it's read-only and not read-write, it covers the basics: a session can be re-read by FF, the encryption key can't easily be pushed into FF by a user to read an old session, and when the key is overwritten at the point a new session is saved, the old key becomes permanently unreadable.<br />
<br />
The algorithm I'm thinking goes something like this:<br />
# Session files have timestamp or incremental ID in their filename - "SavedSession03102006054627"<br />
# The ID and encryption key pair for the last <n> saved sessions is held. ("n", so that users can keep up to 3 or 5 previous state backups in case one or more become corrupted in a crash)<br />
# On restart, FF identifies the most recent saved session that it can decrypt and which has full integrity, and works with that backup. It also deletes any that it couldn't decrypt or which appear corrupted, and any key entries that don't appear to relate to actual valid saved session files.<br />
# When a new session backup is made, FF creates a random 256 bit key, encrypts the backup with that, and saves the new backup timestamp/decryption key pair for future use.<br />
# When the backup is confirmed saved, then if there are more than <n> backups held, the file and key for the oldest one(s) are deleted.<br />
# If the key file ID and key are held in a place the user can see within FF, there is code to prevent copy or pasting of that data.<br />
<br />
I don't think you can do much better. Any code FF used to access the saved states on restart could be emulated by a rogue user or software. What this does is ensure that the files by themselves are harmless, that one key (if obtained) does not give access to any older backed up session files, and that a user cannot just copy and use the key to open a file. Any better security would require a user password on starting FF or similar, as well as all FF saved data and cache to be encrypted; it can't easily be done by FF alone.<br />
<br />
As an amateur newcomer to FF this would seem to cover many of the bases, and deal with the main problems identified above. [[User:Foxxen2|Foxxen2]] 08:57, 30 March 2006 (PST)<br />
<br />
About the password, that's not a bad idea!<br />
Assuming secret data will be sent over a secure connection, firefox could, when the users exits with a https site open, ask if it has to encrypt the data, and if so, ask to give a password to reopen it. If the password can't be supplied the encrypted data will be lost, which will mostly not be a serious problem.<br />
<br />
If a website doesn't use https, it is open to much more ways to get the information, so I don't think it is firefox's task to protect the data in that case.<br />
<br />
--[[User:FrederikVds|FrederikVds]] 15:04, 6 April 2006 (PDT)<br />
<br />
=== An opposing view ===<br />
These suggestions seem over-designed, to me. The same logic would apply to any sensitive information stored on your computer. What about email addresses in your mail program? Financial accounting information for your company? By the same logic, all this should be encrypted too.<br />
<br />
One problem with encrypting the information is that it's unrecoverable if you forget the password, or if there's a tiny data error through hardware faults that corrupt a bit. Nor can you dive in with a text editor and delete the saved URL that's causing your browser to crash. The session data is a black box, uneditable. On the design side, I argue that it goes against the Unix philosophy of modular easily-connected components. If you want encryption, save it to an encrypted file system, or encrypt the files with PGP or something.<br />
<br />
IMHO, the file format for the saved session should be XML or even plain text. The most I'd suggest as far as security would be to avoid storing cookies or form data or passwords. Let the browser request fresh cookies, and the user re-enter their passwords etc., upon reload.<br />
<br />
--[[User:LukeKendall|LukeKendall]] 10:30, 18 July 2006 (EST)<br />
<br />
== Restoring after voluntary exit not optional ==<br />
<br />
The main page currently (2006-02-13) lists this as an optional (P2,<br />
FF3 or left to extensions) feature:<br />
<br />
"Allow session restoration after voluntary application closure"<br />
<br />
From my point of view, this is not an optional feature. The only time<br />
I ever make Firefox exit is to work around some bug (e.g., using too<br />
much memory, incapable of handling new extensions without restart,<br />
etc.). Otherwise my invocation of Firefox would run forever. Thus,<br />
for me, every manual exit of Firefox is undesired and equivalent to a<br />
forced crash. Generally I have dozens of tabs representing weeks or<br />
months of work that I definitely do not want to lose! If this feature was missing I would have to continue using SessionSaver, which would be undesirable.<br />
<br />
Joe<br />
--[[User:Sllewbj|Sllewbj]] 05:27, 13 Feb 2006 (PST)<br />
<br />
<br />
Agree 100%! I came to SessionSaver for the crash recovery, but stayed for the non-crash session saving. It's incredibly useful when having to reboot your OS (e.g. because you installed a new piece of software, or applied OS or third-party software patches), or when having to shut down your laptop because you're on the go, to be able to save your work in Firefox the same way you can in document-oriented software applications, and be able to pick right back up where you left off after you've restarted and logged back in. It would be silly not to implement this and would just mean lots of people would be forcibly killing their own browsers in order to save their sessions.<br />
<br />
-- [http://harkless.org/dan/ Dan Harkless], 23:17, 16 Feb 2006 (PST)<br />
<br />
Agreed this is the right default but there still needs to be a mechanism to bypass restoration in case the browser is crashing or just browsed p0rn at work accidentally. SessionSaver has a detection for a crashing set for the first purpose. For the second, you might check for holding down Shift during startup, like a Macintosh for not loading extensions.<br />
<br />
--[[User:BillMcGonigle|BillMcGonigle]] 10:48, 21 Feb 2006 (PST)<br />
<br />
I'd say this feature is contrary to the privacy settings. I set firefox to clear private data when closing Firefox, yet this code circumvents that - when I restart, browsing history, etc, is there for all the world to see. At very least it should be switchable on/off by a user preferences option.<br />
<br />
== DOM restore vs. URL restore ==<br />
<br />
What if we serialized and restored the current DOM (including event handlers and such) for each tab, instead of storing the URLs? That would solve all of the problems with reloading of non-idempotent GETs, as well as POST cases, and properly restore the state of apps like gmail. (If we don't do this, then we need to be very careful about restoring form state against a possibly-different form when we restore the session and reload the page. There have been attacks related to changing an input from type=hidden to type=file on reload which I think we would prefer to not revisit.)<br />
<br />
: [[User:Shaver|Shaver]] 09:33, 13 Feb 2006 (PST)<br />
<br />
I agree that a DOM restore would be preferrable, as otherwise all POSTed pages would be lost.<br />
Also a DOM restore would be clearly faster if you have a slow internet connection.<br />
<br />
--[[User:FrederikVds|FrederikVds]] 16:19, 18 Mar 2006 (PST)<br />
<br />
What about sessions on web servers if you do storing of DOM? If we save URL then going by the link on restoring would probably load a page with notice that session is expired. Saving DOM, one could start putting data into a form, like doing long e-mail message and then during submit find out that the session is expired.<br />
<br />
--[[User:Sofoz|Sofoz]] 07:01, 15 July 2006 (PDT)<br />
<br />
I'm not sure if expired server sessions should be much of a concern. After all, the expiry would happen if you left the browser open or if you hibernated the OS. Trying to ensure fresh information in session restore case seems trying too hard and wouldn't be very consistent.<br />
<br />
--[[User:Aapo Laitinen|Aapo Laitinen]] 22:36, 18 July 2006 (PDT)<br />
<br />
== Use-cases for Session Restoration ==<br />
<br />
* Corporate environments: "Most have a policy which states that you have to turn off your computer when you leave for the night. Now assuming that not every employee stays at work in the evening until all work is done, I consider it reasonable for the user to expect to be able to start in the morning right where he has left in the evening, although the machine was switched off over the night."<br />
<br />
* "A second scenario is, that, unfortunately, since even FF is not bug free, one has to restart it occasionally when it starts to behave oddly. This is not a crash, it's a user requested quit, but I expect to start work again at exactly the point where I have left."<br />
<br />
* consultants/travelers: people who involuntarily shut down the browser many times each day<br />
<br />
* admins: people who log onto their user account at many other people's boxes, many times during the day, such as IT/helpdesk workers at large organizations<br />
<br />
* mobile: people who load FF, or their profile, off of a usb key.<br />
<br />
* Mozilla Testers!: Now that we have auto-updates in testing code, with real Session Restore I can just click 'Restart Now' and always be testing the latest nightly. This is a dream for quality of bug reports. --[[User:BillMcGonigle|BillMcGonigle]] 10:45, 21 Feb 2006 (PST)<br />
<br />
== Things Not to Do ==<br />
<br />
There are some things you don't want to do when restoring a session, as evidenced by bitter tastes from Session Saver.<br />
<br />
* Don't re-POST forms. Session Saver will do this. I had 5 duplicate bugzilla bugs once before I realized what was happening. Imagine if I was using a poor shopping cart! --[[User:BillMcGonigle|BillMcGonigle]] 10:54, 21 Feb 2006 (PST)<br />
** If you can trust the maxim 'GET for actions without side effects, POST for actions with side effects' you could simply refuse to do POST on session restore. You can't actually trust that a web developer hasn't just decided to use POST for everything because "long URL's are ugly" but maybe it's the right thing to do anyway. --[[User:BillMcGonigle|BillMcGonigle]] 10:54, 21 Feb 2006 (PST)<br />
<br />
== Unresolved questions ==<br />
<br />
''Do we ever want to store cached copies of the pages (i.e. for offline access) or do we just store the urls and load them all? Loading from cache would be snappier.''<br />
* Well, there's multiple strategies:<br />
*# Don't load more than <n> pages at a time, giving the focussed tab 1st priority, allowing the user to work, and then giving priority to tabs the user is working on, as one tab loads, start another so there are always <n> tabs loading until it's recovered.<br />
*#:Advantages - user can work immediately, system is kept under moderate load, restore is probably transparent since any page the user works on is given priority.<br />
*# Load all from cache, then update as visited<br />
*#: Advantages - with luck the cached version should be what the user saw. But if it is we'll only know it if we reload, if it isn't then its misleading, and in any case since we then probably reload pages anyhow does the user benefit from loading the cached version of pages first?<br />
*# Check latest update times of all pages quickly (a lower bandwidth job), and those that have update times matching the cache entry, assume the cache is up to date, otherwise load from web as per (1).<br />
*#: Advantages - many pages will be up to date, so this saves reloading pages other than those changed. In theory this, compbined with (1) for loading web pages that do need reloading, should work. But would it?<br />
: [[User:Foxxen2|Foxxen2]] 09:24, 30 March 2006 (PST)<br />
<br />
<br />
''Make sure that if the state of the current session crashes the browser, it doesn�t reload at startup and crash over and over again. Look into how SessionSaver and Total Recall detect this.''<br />
* Whats really helpful would be a FF extension and page processing calls log that can be relied upon to note extension calls made (and their successful return) and page render or page processing calls made (and their successful completion). In theory when it crashes, very few extensions or pages will actually have commenced a call but not completed. Those will likely be the problem ones. beyond that its a problem with FF core code, and a safe start or debug session. The core of the problem is having a way to narrow down problematic pages and extensions. Perhaps if it crashes during a restore it offers to switch to a "safe restore" mode (as opposed to "safe mode"), where extensions are loaded one by one, then pages loaded one by one, and the cause of the crash identified and reported for debugging? Ie a fallback mode for restore where the user gets a slower restore, that keeps as many pages and extensions as it can alive. [[User:Foxxen2|Foxxen2]] 09:24, 30 March 2006 (PST)<br />
<br />
<br />
''Should form state include saving checkbox and selectbox state as well as text input?''<br />
* Yes. See above, re text box contents, same applies. [[User:Foxxen2|Foxxen2]] 09:24, 30 March 2006 (PST)<br />
<br />
''If there are multiple windows open, how do we decide what was the last session? The last window closed, or the last group of windows?''<br />
* If they're all exited together, by quitting from FF, the answer is clearly that all should be saved.<br />
* But I think better would be to have an explicit Save Session and Restore Session function. Then the semantics can simply be to hold the session for auto reload (or prompted reload) after a crash; but normally to require an explicit Restore Session action by the user.<br />
[[User:LukeKendall|LukeKendall]] 10:20, 18 July 2006 (EST)<br />
<br />
''There should be an option to disable 'cookie restore'. I don't like the feeling that after crash or shut down any body can come on pc and login to my gmail and other accounts. Yes I can disable the sessions entirely but this will remove the feature entirely. I like session restoration in Opera but in FireFox it is less secure.<br />
<br />
== Crash Recovery and Session Manager have good code ==<br />
<br />
[http://forums.mozillazine.org/viewtopic.php?t=164513 Crash Recovery] and [http://forums.mozillazine.org/viewtopic.php?t=380534 Session Manager], both developed by zeniko, have good code.<br />
<br />
They're both listed under [[Session_Restore#Relevant_Extensions Relevant Extensions]] on the Session Restore page.<br />
<br />
Crash Recovery only runs when your browser crashes, not on every restart.<br />
Session Manager allows the user to restore session on every restart.<br />
<br />
It also includes the following features and more:<br />
* Session Management (Saving, Renaming, Deleting, Overriding)<br />
* Session Loading Options<br />
* POSTDATA, cookies, and form data saving<br />
* Reopen Closed Tab / Window<br />
* Restore closed tab / window list on startup<br />
<br />
-- [[User:Desertfox|Frank (DesertFox)]] [[User talk:Desertfox|(talk)]] 21:58, 8 Apr 2006 (CDT)<br />
<br />
= UI =<br />
(moved from front page)<br />
* Prompt for restore upon application start, post-crash.<br />
<br />
For reference, this is a screenshot of the similar feature in the Gnome web-browser, Epiphany:<br />
<br />
http://actsofvolition.com/images/screenshots/firefox/epiphany-session-restore.png<br />
<br />
= Privacy =<br />
[moved from front page]<br />
<br />
Are there any privacy issues? Doesn't seem to be, as most (all?) of this information is already stored somewhere already, eg: history, cookies, etc.<br />
<br />
There are most certainly privacy issues, just as there are with history, cookies etc. Hence the proliferation of utilities that remove tracking footprints.<br />
<br />
Privacy can be an issue. Saving the detailed session includes elements of<br />
history, bookmarks. cookies, typed form information, etc.. and all of these<br />
have purge functions to erase tracks already implemented. The concept of<br />
saving session infos would seem to conflict with the desire for privacy. But<br />
need there be such a conflict?<br />
<br />
What about encrypting the saved session info, so that the files containing the data are not 'in plain language', readable in notepad. After a crash, perhaps a password would be required to re-open the last known session. Without the password, it opens to about:blank.<br />
<br />
= Comment from an Ordinary User =<br />
<br />
There is, in some people's opinion, a serious and potentially dangerous security and privacy risk. This is caused by the fact that if the Cache is stored in RAM (a disk drive created in RAM whose contents 'disappear' when the power is removed), material to restore pages is then saved on conventional hard disk. As at Firefox version 2.0 the last viewed web pages are reproduced perfectly without a connection being re-established with the remote server. This is done when the Cache was on RAM disk and after the computer's power had been turned-off for 12 hours!<br />
<br />
Firefox's restore session ability must be loved and admired by Big Brother throughout the world. With anti-virus checkers deliberately ignoring "official" security service bugs and trojans and users becoming more aware of all the data Microsoft and its Internet Explorer saves about them, its probably inevitable that Mozilla, for whatever reason, started saving in secret information about its user's browsing habits!<br />
<br />
It is a material consideration that Firefox does not permit ordinary users the ability to turn-off this security and privacy violating feature. If this feature is genuinely for the good of Firefox users, then Firefox ought to allow users to opt out easily and, of course, effectively and permanently. The fact that no such easily available disabling facility exists in Firefox clearly suggests the personal privacy and security of Firefox users was not adequately considered by Firefox's team. Why not?<br />
<br />
A Mozilla User, 24 December 2006.<br />
<br />
{Another user (wsanders): <br />
<br />
Forget about the security and all that, it's an annoying feature since I and probably a bunch of other users normally exit by powering off the computer, exiting X/Gnome/KDE with Ctrl-Alt-Delete, or typing "init 0". All these make Firefox 2 think it has crashed, and annoy with a startup message next time it's launched. One should be able to at least disable this feature in about:config.<br />
<br />
'''never''' - Never save closed tabs in sessions and delete all closed tabs when the browser is shutdown. Also closed tabs will not be restored from saved sessions that had been saved with closed tabs.<br />
<br />
[http://sessionmanager.mozdev.org/documentation.html http://sessionmanager.mozdev.org/documentation.html]<br />
<br />
= Understanding the Structure of sessionstore.js file =<br />
<br />
Hello all,<br />
<br />
Sorry to intrude on your work, but I have a question that I just cannot find an authoritative answer on and I'm not sure that this is the appropriate place to ask, but here goes... <br />
<br />
I am in law enforcement and currently looking at a fragment of data from unallocated space that *appears* to be in the same format as the a/n file. I need to determine what the nature of the fields are. I have a pretty good idea on most of them, but not all.<br />
<br />
For example, let's say this information excerpt:<br />
<br />
<br />
"... title"Hotmail", cacheKey:0, ID:1291, scroll:"0,0"}], index:1, zoom:1, disallow:"", xultab:""....."<br />
<br />
I can see from other pages on this wiki what some of these items do/store, for example scroll stores scroll bar position, but ID, where is the 1291 obtained from? Is this the 1291st browsing instance since the browser was started? I can't tell very well from the source code, but I'm not super fluent in js.<br />
<br />
Any help would be GREATLY appreciated. If this isn't the correct location for this, please let me know where I should ask.<br />
<br />
--[[User:G-man|G-man]] 12:22, 1 May 2008 (PDT)<br />
<br />
== Disable session restore ==<br />
<br />
I don't like the feature of Firefox that it tries to revisit or reload the webpages that caused my browser to crash. ... I desperatly want an option for NO session restore, ever.<br />
<br />
Set ''browser.sessionstore.max_resumed_crashes'' to 0. Firefox will ask after a crash which windows/tabs to restore. See more [[Session_Restore#Preferences|Preferences]] on front page. [[User:Hbbb|Hbbb]] 07:22, 27 October 2009 (UTC)<br />
<br />
== A possibly better way to secure the data ==<br />
<br />
One way that Firefox could secure the session restore automatically is using a hybrid asymmetric (like RSA, DSA, or ElGamal) and symmetric (like AES, Blowfish, Twofish, 3DES, or Serpent) encryption setup like what SSL, TLS, and PGP use. <br />
<br />
<br />
All it needs to do is create a asymmetric key pair with a password encrypted "Private Key" the first time Firefox opens and then whenever you load up Firefox it quickly creates a temporary symmetric key which it uses for that session to encrypt the session restore data with and it encrypts the temporary symmetric key with your asymmetric "Public Key". So then if you ever need to restore your session you will need your private key and the password the private keys encrypted with to decrypt the sessions temporary symmetric key. <br />
<br />
With asymmetric encryption you have a key pair with 2 keys a "Private Key" and a "Public Key" and you can give everyone your public key and when you encrypt something with someones "Public Key" the only way to decrypt the data is with that persons "Private Key" and the password the private key is encrypted with (technically it is possible to create a "Private Key" that isn't encrypted with a password then all you need is the "Private Key" to decrypt the data)<br />
<br />
:I'm with LukeKendall. Full Disk Encryption, or OS-level stuff like TrueCrypt, BitLocker and FileVault are the solution to this issue; no need to try and re-solve this problem. ''{But I'm going to add some of the info from http://www.blogsdna.com/4318/how-to-get-back-firefox-35-session-restore-page.htm and on sessionstore.js, which I think is key. (err, never mind about the latter; http://support.mozilla.com/en-US/kb/Session+Restore is the place for documentation.)}'' --[[User:MrElvey|MrElvey]] 04:47, 11 June 2010 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=Talk:Session_Restore&diff=229936Talk:Session Restore2010-06-11T04:47:02Z<p>MrElvey: /* A possibly better way to secure the data */ comment; sessionstore.js; about:sessionrestore</p>
<hr />
<div>== Tab Mix? ==<br />
I'm not sure if regular old me is allowed to edit the main page even for this, so I'm just going to mention it here. AFAIK, it's [http://tmp.garyr.com/ Tab Mix Plus] that does session saving and whatnot, not regular Tab Mix. -- [[User:Peng|Matt Nordhoff]] [[User talk:Peng|(talk)]] 00:34, 9 Feb 2006 (PST)<br />
<br />
<br />
<br />
== Security of saved data ==<br />
Just as a precaution, the data that is saved in order to restore the session should be safe from potential reading. For example, you have several tabs open and some form information filled in on one, including your banking details. The session saver saves these details in order to restart Firefox, but afterwards when the user is finished and they close the browser, is this information left laying about on the hard disk, that could potentially be stolen by rogue software or exploits.<br />
<br />
Also what would happen if after a restart by session saver, you cleared the history with Ctrl+Alt+Del. Even though the history would be removed from the browser cache, would the session saver cache be removed also to ensure that URLs and Form text were not left behind?<br />
:[[User:Kroc|Kroc]] 01:32, 9 Feb 2006 (PST)<br />
<br />
A robust solution would be that encryption was performed with a key that was created at random each time a session save occurred, and kept in config, or otherwise in the same manner all passwords are kept. It's not fully secure, but provided it's read-only and not read-write, it covers the basics: a session can be re-read by FF, the encryption key can't easily be pushed into FF by a user to read an old session, and when the key is overwritten at the point a new session is saved, the old key becomes permanently unreadable.<br />
<br />
The algorithm I'm thinking goes something like this:<br />
# Session files have timestamp or incremental ID in their filename - "SavedSession03102006054627"<br />
# The ID and encryption key pair for the last <n> saved sessions is held. ("n", so that users can keep up to 3 or 5 previous state backups in case one or more become corrupted in a crash)<br />
# On restart, FF identifies the most recent saved session that it can decrypt and which has full integrity, and works with that backup. It also deletes any that it couldn't decrypt or which appear corrupted, and any key entries that don't appear to relate to actual valid saved session files.<br />
# When a new session backup is made, FF creates a random 256 bit key, encrypts the backup with that, and saves the new backup timestamp/decryption key pair for future use.<br />
# When the backup is confirmed saved, then if there are more than <n> backups held, the file and key for the oldest one(s) are deleted.<br />
# If the key file ID and key are held in a place the user can see within FF, there is code to prevent copy or pasting of that data.<br />
<br />
I don't think you can do much better. Any code FF used to access the saved states on restart could be emulated by a rogue user or software. What this does is ensure that the files by themselves are harmless, that one key (if obtained) does not give access to any older backed up session files, and that a user cannot just copy and use the key to open a file. Any better security would require a user password on starting FF or similar, as well as all FF saved data and cache to be encrypted; it can't easily be done by FF alone.<br />
<br />
As an amateur newcomer to FF this would seem to cover many of the bases, and deal with the main problems identified above. [[User:Foxxen2|Foxxen2]] 08:57, 30 March 2006 (PST)<br />
<br />
About the password, that's not a bad idea!<br />
Assuming secret data will be sent over a secure connection, firefox could, when the users exits with a https site open, ask if it has to encrypt the data, and if so, ask to give a password to reopen it. If the password can't be supplied the encrypted data will be lost, which will mostly not be a serious problem.<br />
<br />
If a website doesn't use https, it is open to much more ways to get the information, so I don't think it is firefox's task to protect the data in that case.<br />
<br />
--[[User:FrederikVds|FrederikVds]] 15:04, 6 April 2006 (PDT)<br />
<br />
=== An opposing view ===<br />
These suggestions seem over-designed, to me. The same logic would apply to any sensitive information stored on your computer. What about email addresses in your mail program? Financial accounting information for your company? By the same logic, all this should be encrypted too.<br />
<br />
One problem with encrypting the information is that it's unrecoverable if you forget the password, or if there's a tiny data error through hardware faults that corrupt a bit. Nor can you dive in with a text editor and delete the saved URL that's causing your browser to crash. The session data is a black box, uneditable. On the design side, I argue that it goes against the Unix philosophy of modular easily-connected components. If you want encryption, save it to an encrypted file system, or encrypt the files with PGP or something.<br />
<br />
IMHO, the file format for the saved session should be XML or even plain text. The most I'd suggest as far as security would be to avoid storing cookies or form data or passwords. Let the browser request fresh cookies, and the user re-enter their passwords etc., upon reload.<br />
<br />
--[[User:LukeKendall|LukeKendall]] 10:30, 18 July 2006 (EST)<br />
<br />
== Restoring after voluntary exit not optional ==<br />
<br />
The main page currently (2006-02-13) lists this as an optional (P2,<br />
FF3 or left to extensions) feature:<br />
<br />
"Allow session restoration after voluntary application closure"<br />
<br />
From my point of view, this is not an optional feature. The only time<br />
I ever make Firefox exit is to work around some bug (e.g., using too<br />
much memory, incapable of handling new extensions without restart,<br />
etc.). Otherwise my invocation of Firefox would run forever. Thus,<br />
for me, every manual exit of Firefox is undesired and equivalent to a<br />
forced crash. Generally I have dozens of tabs representing weeks or<br />
months of work that I definitely do not want to lose! If this feature was missing I would have to continue using SessionSaver, which would be undesirable.<br />
<br />
Joe<br />
--[[User:Sllewbj|Sllewbj]] 05:27, 13 Feb 2006 (PST)<br />
<br />
<br />
Agree 100%! I came to SessionSaver for the crash recovery, but stayed for the non-crash session saving. It's incredibly useful when having to reboot your OS (e.g. because you installed a new piece of software, or applied OS or third-party software patches), or when having to shut down your laptop because you're on the go, to be able to save your work in Firefox the same way you can in document-oriented software applications, and be able to pick right back up where you left off after you've restarted and logged back in. It would be silly not to implement this and would just mean lots of people would be forcibly killing their own browsers in order to save their sessions.<br />
<br />
-- [http://harkless.org/dan/ Dan Harkless], 23:17, 16 Feb 2006 (PST)<br />
<br />
Agreed this is the right default but there still needs to be a mechanism to bypass restoration in case the browser is crashing or just browsed p0rn at work accidentally. SessionSaver has a detection for a crashing set for the first purpose. For the second, you might check for holding down Shift during startup, like a Macintosh for not loading extensions.<br />
<br />
--[[User:BillMcGonigle|BillMcGonigle]] 10:48, 21 Feb 2006 (PST)<br />
<br />
I'd say this feature is contrary to the privacy settings. I set firefox to clear private data when closing Firefox, yet this code circumvents that - when I restart, browsing history, etc, is there for all the world to see. At very least it should be switchable on/off by a user preferences option.<br />
<br />
== DOM restore vs. URL restore ==<br />
<br />
What if we serialized and restored the current DOM (including event handlers and such) for each tab, instead of storing the URLs? That would solve all of the problems with reloading of non-idempotent GETs, as well as POST cases, and properly restore the state of apps like gmail. (If we don't do this, then we need to be very careful about restoring form state against a possibly-different form when we restore the session and reload the page. There have been attacks related to changing an input from type=hidden to type=file on reload which I think we would prefer to not revisit.)<br />
<br />
: [[User:Shaver|Shaver]] 09:33, 13 Feb 2006 (PST)<br />
<br />
I agree that a DOM restore would be preferrable, as otherwise all POSTed pages would be lost.<br />
Also a DOM restore would be clearly faster if you have a slow internet connection.<br />
<br />
--[[User:FrederikVds|FrederikVds]] 16:19, 18 Mar 2006 (PST)<br />
<br />
What about sessions on web servers if you do storing of DOM? If we save URL then going by the link on restoring would probably load a page with notice that session is expired. Saving DOM, one could start putting data into a form, like doing long e-mail message and then during submit find out that the session is expired.<br />
<br />
--[[User:Sofoz|Sofoz]] 07:01, 15 July 2006 (PDT)<br />
<br />
I'm not sure if expired server sessions should be much of a concern. After all, the expiry would happen if you left the browser open or if you hibernated the OS. Trying to ensure fresh information in session restore case seems trying too hard and wouldn't be very consistent.<br />
<br />
--[[User:Aapo Laitinen|Aapo Laitinen]] 22:36, 18 July 2006 (PDT)<br />
<br />
== Use-cases for Session Restoration ==<br />
<br />
* Corporate environments: "Most have a policy which states that you have to turn off your computer when you leave for the night. Now assuming that not every employee stays at work in the evening until all work is done, I consider it reasonable for the user to expect to be able to start in the morning right where he has left in the evening, although the machine was switched off over the night."<br />
<br />
* "A second scenario is, that, unfortunately, since even FF is not bug free, one has to restart it occasionally when it starts to behave oddly. This is not a crash, it's a user requested quit, but I expect to start work again at exactly the point where I have left."<br />
<br />
* consultants/travelers: people who involuntarily shut down the browser many times each day<br />
<br />
* admins: people who log onto their user account at many other people's boxes, many times during the day, such as IT/helpdesk workers at large organizations<br />
<br />
* mobile: people who load FF, or their profile, off of a usb key.<br />
<br />
* Mozilla Testers!: Now that we have auto-updates in testing code, with real Session Restore I can just click 'Restart Now' and always be testing the latest nightly. This is a dream for quality of bug reports. --[[User:BillMcGonigle|BillMcGonigle]] 10:45, 21 Feb 2006 (PST)<br />
<br />
== Things Not to Do ==<br />
<br />
There are some things you don't want to do when restoring a session, as evidenced by bitter tastes from Session Saver.<br />
<br />
* Don't re-POST forms. Session Saver will do this. I had 5 duplicate bugzilla bugs once before I realized what was happening. Imagine if I was using a poor shopping cart! --[[User:BillMcGonigle|BillMcGonigle]] 10:54, 21 Feb 2006 (PST)<br />
** If you can trust the maxim 'GET for actions without side effects, POST for actions with side effects' you could simply refuse to do POST on session restore. You can't actually trust that a web developer hasn't just decided to use POST for everything because "long URL's are ugly" but maybe it's the right thing to do anyway. --[[User:BillMcGonigle|BillMcGonigle]] 10:54, 21 Feb 2006 (PST)<br />
<br />
== Unresolved questions ==<br />
<br />
''Do we ever want to store cached copies of the pages (i.e. for offline access) or do we just store the urls and load them all? Loading from cache would be snappier.''<br />
* Well, there's multiple strategies:<br />
*# Don't load more than <n> pages at a time, giving the focussed tab 1st priority, allowing the user to work, and then giving priority to tabs the user is working on, as one tab loads, start another so there are always <n> tabs loading until it's recovered.<br />
*#:Advantages - user can work immediately, system is kept under moderate load, restore is probably transparent since any page the user works on is given priority.<br />
*# Load all from cache, then update as visited<br />
*#: Advantages - with luck the cached version should be what the user saw. But if it is we'll only know it if we reload, if it isn't then its misleading, and in any case since we then probably reload pages anyhow does the user benefit from loading the cached version of pages first?<br />
*# Check latest update times of all pages quickly (a lower bandwidth job), and those that have update times matching the cache entry, assume the cache is up to date, otherwise load from web as per (1).<br />
*#: Advantages - many pages will be up to date, so this saves reloading pages other than those changed. In theory this, compbined with (1) for loading web pages that do need reloading, should work. But would it?<br />
: [[User:Foxxen2|Foxxen2]] 09:24, 30 March 2006 (PST)<br />
<br />
<br />
''Make sure that if the state of the current session crashes the browser, it doesn�t reload at startup and crash over and over again. Look into how SessionSaver and Total Recall detect this.''<br />
* Whats really helpful would be a FF extension and page processing calls log that can be relied upon to note extension calls made (and their successful return) and page render or page processing calls made (and their successful completion). In theory when it crashes, very few extensions or pages will actually have commenced a call but not completed. Those will likely be the problem ones. beyond that its a problem with FF core code, and a safe start or debug session. The core of the problem is having a way to narrow down problematic pages and extensions. Perhaps if it crashes during a restore it offers to switch to a "safe restore" mode (as opposed to "safe mode"), where extensions are loaded one by one, then pages loaded one by one, and the cause of the crash identified and reported for debugging? Ie a fallback mode for restore where the user gets a slower restore, that keeps as many pages and extensions as it can alive. [[User:Foxxen2|Foxxen2]] 09:24, 30 March 2006 (PST)<br />
<br />
<br />
''Should form state include saving checkbox and selectbox state as well as text input?''<br />
* Yes. See above, re text box contents, same applies. [[User:Foxxen2|Foxxen2]] 09:24, 30 March 2006 (PST)<br />
<br />
''If there are multiple windows open, how do we decide what was the last session? The last window closed, or the last group of windows?''<br />
* If they're all exited together, by quitting from FF, the answer is clearly that all should be saved.<br />
* But I think better would be to have an explicit Save Session and Restore Session function. Then the semantics can simply be to hold the session for auto reload (or prompted reload) after a crash; but normally to require an explicit Restore Session action by the user.<br />
[[User:LukeKendall|LukeKendall]] 10:20, 18 July 2006 (EST)<br />
<br />
''There should be an option to disable 'cookie restore'. I don't like the feeling that after crash or shut down any body can come on pc and login to my gmail and other accounts. Yes I can disable the sessions entirely but this will remove the feature entirely. I like session restoration in Opera but in FireFox it is less secure.<br />
<br />
== Crash Recovery and Session Manager have good code ==<br />
<br />
[http://forums.mozillazine.org/viewtopic.php?t=164513 Crash Recovery] and [http://forums.mozillazine.org/viewtopic.php?t=380534 Session Manager], both developed by zeniko, have good code.<br />
<br />
They're both listed under [[Session_Restore#Relevant_Extensions Relevant Extensions]] on the Session Restore page.<br />
<br />
Crash Recovery only runs when your browser crashes, not on every restart.<br />
Session Manager allows the user to restore session on every restart.<br />
<br />
It also includes the following features and more:<br />
* Session Management (Saving, Renaming, Deleting, Overriding)<br />
* Session Loading Options<br />
* POSTDATA, cookies, and form data saving<br />
* Reopen Closed Tab / Window<br />
* Restore closed tab / window list on startup<br />
<br />
-- [[User:Desertfox|Frank (DesertFox)]] [[User talk:Desertfox|(talk)]] 21:58, 8 Apr 2006 (CDT)<br />
<br />
= UI =<br />
(moved from front page)<br />
* Prompt for restore upon application start, post-crash.<br />
<br />
For reference, this is a screenshot of the similar feature in the Gnome web-browser, Epiphany:<br />
<br />
http://actsofvolition.com/images/screenshots/firefox/epiphany-session-restore.png<br />
<br />
= Privacy =<br />
[moved from front page]<br />
<br />
Are there any privacy issues? Doesn't seem to be, as most (all?) of this information is already stored somewhere already, eg: history, cookies, etc.<br />
<br />
There are most certainly privacy issues, just as there are with history, cookies etc. Hence the proliferation of utilities that remove tracking footprints.<br />
<br />
Privacy can be an issue. Saving the detailed session includes elements of<br />
history, bookmarks. cookies, typed form information, etc.. and all of these<br />
have purge functions to erase tracks already implemented. The concept of<br />
saving session infos would seem to conflict with the desire for privacy. But<br />
need there be such a conflict?<br />
<br />
What about encrypting the saved session info, so that the files containing the data are not 'in plain language', readable in notepad. After a crash, perhaps a password would be required to re-open the last known session. Without the password, it opens to about:blank.<br />
<br />
= Comment from an Ordinary User =<br />
<br />
There is, in some people's opinion, a serious and potentially dangerous security and privacy risk. This is caused by the fact that if the Cache is stored in RAM (a disk drive created in RAM whose contents 'disappear' when the power is removed), material to restore pages is then saved on conventional hard disk. As at Firefox version 2.0 the last viewed web pages are reproduced perfectly without a connection being re-established with the remote server. This is done when the Cache was on RAM disk and after the computer's power had been turned-off for 12 hours!<br />
<br />
Firefox's restore session ability must be loved and admired by Big Brother throughout the world. With anti-virus checkers deliberately ignoring "official" security service bugs and trojans and users becoming more aware of all the data Microsoft and its Internet Explorer saves about them, its probably inevitable that Mozilla, for whatever reason, started saving in secret information about its user's browsing habits!<br />
<br />
It is a material consideration that Firefox does not permit ordinary users the ability to turn-off this security and privacy violating feature. If this feature is genuinely for the good of Firefox users, then Firefox ought to allow users to opt out easily and, of course, effectively and permanently. The fact that no such easily available disabling facility exists in Firefox clearly suggests the personal privacy and security of Firefox users was not adequately considered by Firefox's team. Why not?<br />
<br />
A Mozilla User, 24 December 2006.<br />
<br />
{Another user (wsanders): <br />
<br />
Forget about the security and all that, it's an annoying feature since I and probably a bunch of other users normally exit by powering off the computer, exiting X/Gnome/KDE with Ctrl-Alt-Delete, or typing "init 0". All these make Firefox 2 think it has crashed, and annoy with a startup message next time it's launched. One should be able to at least disable this feature in about:config.<br />
<br />
'''never''' - Never save closed tabs in sessions and delete all closed tabs when the browser is shutdown. Also closed tabs will not be restored from saved sessions that had been saved with closed tabs.<br />
<br />
[http://sessionmanager.mozdev.org/documentation.html http://sessionmanager.mozdev.org/documentation.html]<br />
<br />
= Understanding the Structure of sessionstore.js file =<br />
<br />
Hello all,<br />
<br />
Sorry to intrude on your work, but I have a question that I just cannot find an authoritative answer on and I'm not sure that this is the appropriate place to ask, but here goes... <br />
<br />
I am in law enforcement and currently looking at a fragment of data from unallocated space that *appears* to be in the same format as the a/n file. I need to determine what the nature of the fields are. I have a pretty good idea on most of them, but not all.<br />
<br />
For example, let's say this information excerpt:<br />
<br />
<br />
"... title"Hotmail", cacheKey:0, ID:1291, scroll:"0,0"}], index:1, zoom:1, disallow:"", xultab:""....."<br />
<br />
I can see from other pages on this wiki what some of these items do/store, for example scroll stores scroll bar position, but ID, where is the 1291 obtained from? Is this the 1291st browsing instance since the browser was started? I can't tell very well from the source code, but I'm not super fluent in js.<br />
<br />
Any help would be GREATLY appreciated. If this isn't the correct location for this, please let me know where I should ask.<br />
<br />
--[[User:G-man|G-man]] 12:22, 1 May 2008 (PDT)<br />
<br />
== Disable session restore ==<br />
<br />
I don't like the feature of Firefox that it tries to revisit or reload the webpages that caused my browser to crash. ... I desperatly want an option for NO session restore, ever.<br />
<br />
Set ''browser.sessionstore.max_resumed_crashes'' to 0. Firefox will ask after a crash which windows/tabs to restore. See more [[Session_Restore#Preferences|Preferences]] on front page. [[User:Hbbb|Hbbb]] 07:22, 27 October 2009 (UTC)<br />
<br />
== A possibly better way to secure the data ==<br />
<br />
One way that Firefox could secure the session restore automatically is using a hybrid asymmetric (like RSA, DSA, or ElGamal) and symmetric (like AES, Blowfish, Twofish, 3DES, or Serpent) encryption setup like what SSL, TLS, and PGP use. <br />
<br />
<br />
All it needs to do is create a asymmetric key pair with a password encrypted "Private Key" the first time Firefox opens and then whenever you load up Firefox it quickly creates a temporary symmetric key which it uses for that session to encrypt the session restore data with and it encrypts the temporary symmetric key with your asymmetric "Public Key". So then if you ever need to restore your session you will need your private key and the password the private keys encrypted with to decrypt the sessions temporary symmetric key. <br />
<br />
With asymmetric encryption you have a key pair with 2 keys a "Private Key" and a "Public Key" and you can give everyone your public key and when you encrypt something with someones "Public Key" the only way to decrypt the data is with that persons "Private Key" and the password the private key is encrypted with (technically it is possible to create a "Private Key" that isn't encrypted with a password then all you need is the "Private Key" to decrypt the data)<br />
<br />
:I'm with LukeKendall. Full Disk Encryption, or OS-level stuff like TrueCrypt, BitLocker and FileVault are the solution to this issue; no need to try and re-solve this problem. But I'm going to add some of the info from http://www.blogsdna.com/4318/how-to-get-back-firefox-35-session-restore-page.htm and on sessionstore.js, which I think is key. --[[User:MrElvey|MrElvey]] 04:47, 11 June 2010 (UTC)</div>MrElveyhttps://wiki.mozilla.org/index.php?title=QA/Talkback/FAQ&diff=24466QA/Talkback/FAQ2006-04-23T14:51:17Z<p>MrElvey: /* How can I induce a hung mozilla program to report via Talkback? */</p>
<hr />
<div>== What does it mean when I see the following error when submitting a crash incident: "The Agent is unable to connect to the server. Please check your Proxy Server settings or try again later."? ==<br />
This error message is misleading. It does not always indicate a proxy related problem or mean that your incident has not been submitted to the Talkback Server.<br />
<br />
We do know that a lot of people with slower connections (dialup, isdn) sometimes have timing issues and do not get a response from the Talkback server saying that their crash was successfully processed and stored. If you open up talkback.exe, find an Incident ID, and look it up with FastFind, chances are you will find your crash.<br />
<br />
For more info, see [https://bugzilla.mozilla.org/show_bug.cgi?id=210251#c70 Bug 210251, Comment 70].<br />
<br />
== How do I disable Talkback? (not recommended) ==<br />
If you are having problems submitting crash incidents and continue to see the error discussed above, you can disable Talkback:<br />
* Firefox/Thunderbird 1.5.x: Run talkback.exe (launches the Talkback Client) in the extensions directory (<application dir>/extensions/talkback@mozilla.org/components) and select Settings->Turn Agent Off.<br />
* Firefox/Thunderbird 1.0.x: Run talkback.exe in the components directory (<application dir>/components) and select Settings->Turn Agent Off.<br />
<br />
== What data is sent with my crash incident? ==<br />
There are a number of things that are included in the crash incident that is submitted to us. For more info, see [http://www.mozilla.org/quality/qfa.html the Old QFA page on mozilla.org] (a bit outdated, but it shows you how to check what data will be sent with the Talkback Client after you crash). As far as I know, there is no other way to get a complete list until you trigger Talkback with a crash...at that point, clicking on the Details button will show you everything you might want to know (and allow you to uncheck items you don't want to send).<br />
<br />
== What additional information should I specify when submitting a crash incident? ==<br />
Aside from the data collected automatically by Talkback, the crash dialog allows you to specify your email address, a URL, and comments about your crash. It is important that you provide us with as much useful information as you can to improve our ability to debug the issue. This includes the website you were visiting, any plugins or extensions you think might be related to the crash, what you were doing, etc. If you have been able to crash consistently, exact steps to reproduce the crash would be ideal!<br />
* NOTE: If you submit your email address, it will be kept private (only Mozilla will be able to see that data). Personal information like IP and email addresses will not show up in public Talkback reports or query results.<br />
* TIP: If you want to easily look up your own incidents, you can always add a unique string that you will remember in the URL or Comments field and then query for it with QuickSearch<br />
** e.g. in the Comments field I might enter something like: "Crash submitting a from at http://someurl [jpcrash20060130]" - that way, I could go search for "jpcrash" and get all of my incidents in one easy query.)<br />
<br />
== As a developer for Mozilla's SVG code I'd like to learn how to narrow crash results to crashes occuring on SVG content. ==<br />
There are a number of ways to narrow down your query results to find specific types of crashes. For this case we'll look at SVG, but the same approach can be taken for any part of the code, feature, or component. Using the QuickSearch query tool at [http://talkback-public.mozilla.org/talkback/fastfind.jsp http://talkback-public.mozilla.org/talkback/fastfind.jsp]<br />
, you can try the following:<br />
* Search by a keyword in the Comments field (e.g. "svg"). This might not give you exactly what you want, but should provide a good number of crashes from people that were looking at SVG content...and from those results, you will be able to find some good URLs and comments to help look into SVG crashes.<br />
* Search by a function in the code in the Stack Signature field (e.g. "nsSVGGradientFrame::GetNextGradient", "NPSVG3.dll"). You can even search for substrings (just make sure to select the proper pull down item for where in the complete string to search, like "Contains", "Begins With", etc.).<br />
* Search by a website in the URL field (e.g. "http://www.w3.org/Graphics/SVG/"). This probably isn't the best option, unless you already know of a website that people have been crashing on consistently...but it can allow you to see what types of crashes are happening at certain popular websites.<br />
<br />
<br />
== Will you be looking at feedback from old builds? E.g. will you be looking at crash data from Firefox 1.5 in a month? Or is it only crashes in recent builds that are interesting? ==<br />
This is a great question and the answer will explain exactly why we need more help from the community. To get a better understanding of which builds need to be looked at, you first need to understand which development branches exist and which product/project releases come off of them:<br />
* Mozilla Trunk (FirefoxTrunk, ThunderbirdTrunk, MozillaTrunk [SeaMonkey])<br />
* Mozilla 1.7/1.0 Aviary Branch (Firefox10, Thunderbird10, Mozilla17)<br />
* Mozilla 1.8.0 Branch (Firefox15, Thunderbird15, SeaMonkey10)<br />
* Mozilla 1.8 Branch (Firefox2, Thunderbird2, SeaMonkey11)<br />
<br />
Looking at that list, I'll try to explain what type of crash analysis needs to be done for each:<br />
<br />
1. The Trunk branches are the latest bleeding edge builds with a lot of new features and changes being checked in. These builds are great to look at to find regressions quickly and get them fixed right away. Since those trees are almost always open to the community of developers, people are encouraged to check in patches there first (possible fixes for various branches make their way to the Trunk first, bake for a while, and if things look good, they are ported to the branches that need the fix). We will always need more eyes on Trunk builds...since that is where most of the work is happening (but not necessarily where most of the Mozilla Corporation QA team spends it's time).<br />
<br />
2. The Mozilla 1.0 Aviary branch is on it's way out since most of our users are switching to Firefox/Thunderbird 1.5.x (Mozilla 1.8.0 branch). People don't need to spend too much time looking at the crash data for builds/releases from this branch. However, we still support it and therefore need to look at it closely before and after any security point release. Firefox/Thunderbird 1.0.8 and Mozilla 1.7.13 are going to be the next releases, so it will be good to double check that they don't introduce any obvious regressions or bring down the overall stability when compared to Firefox/Thunderbird 1.0.7 and Mozilla 1.7.12.<br />
<br />
3. The Mozilla 1.8.0 branch is perhaps the most important right now to focus our time on, since it is what most of our users are using (therefore more Talkback crash data to help us do better analysis). Firefox/Thunderbird 1.5 and all their future security releases (e.g Firefox 1.5.0.1 coming out soon) will be released off this branch, and therefore a lot of work is happening there. Since it just recently came out, now is the time for us to identify and log as many critical crash bugs we can find. There is no guarantee that they will be fixed right away, but we still need to work hard to dig for them, create testcases, find steps to reproduce, and work with the developers and community to find a fix. Chances are, if we find a fix soon, and it is a safe patch, it might get into the next security release. If people decide it's too risky for a security release, it will surely be fixed on the Trunk and most likely on the next release branch as well (Mozilla 1.8 branch).<br />
<br />
4. The Mozilla 1.8 branch is for the next major version: Firefox/Thunderbird 2. While we continue to make Firefox/Thunderbird 1.5 more stable and secure, a lot of work is shifted over to this new branch. So, like the Trunk, this branch is where a lot of work is happening. It is another great place to watch crash data daily to catch any regressions and make sure we address new crashes as soon as possible. With Firefox/Thunderbird 1.5 reaching critical mass, this new 2.0 branch will become our main focus very soon. That means taking everything we have learned/gathered from Talkback crash data for 1.5 and trying to reproduce with 2.0 and see if the bug is still there, and if it is, try to get it fixed as soon as possible. Some crashes in 1.5 might not still be around in 2.0 (since a lot of code might have changed), so we need to make sure we identify what has carried over and what is new. This is perhaps the most challenging task, but by working together, we can make it a lot easier. :-)<br />
<br />
As you can see, there are plenty of things to keep track of... and since I have not been able to keep up with everything on my own, I can use all the help I can get. A few people already do a lot of crash analysis on their own, but we can always use more eyes! If you have any questions, feel free to contact me. You can find me on IRC in #qa. Also, take some time to query for crash bugs in Bugzilla by looking for the "crash" and "topcrash" keywords...that should give you a good idea of what is out there now.<br />
<br />
<br />
== If there is a backlog of incidents waiting to be processed on [http://talkback-public.mozilla.org/talkback/fastfind.jsp http://talkback-public.mozilla.org/talkback/fastfind.jsp], can I look at the crash info for my recent incidents on my computer? ==<br />
Unfortunatly, the data is not in a human-readable format on your local machine so there is no easy way to view it. You have to wait until the Talkback Server has processed your incident before looking it up by Incident ID or finding it in any query results.<br />
<br />
<br />
<br />
== I'd love to know if there is any trend analysis and/or reporting that I could do to help the coders identify the most common and/or problematic issues. Can I access the data and do analysis from my web browser? ==<br />
Yes! There are already a number of reports for the various development branches and official releases that already organize the crash data and sort it by total number of incidents. This not only helps us focus our work on the most critical crashes, but allows you to easily browse the data to do whatever type of crash analysis you want. There are also query tools for you to create your own reports on the fly. All of this can be found at [http://talkback-public.mozilla.org/talkback/fastfind.jsp http://talkback-public.mozilla.org/talkback/fastfind.jsp].<br />
* I will be writing up in more detail which reports are useful for different type of crash analysis soon. So keep an eye on the Talkback wiki page.<br />
<br />
<br />
== Does Talkback send what extensions/plugins you have installed? If not, should we list them in the comments? ==<br />
No, Talkback does no automatically send us information about your particular extensions or plugins. Therefore, it is a great idea to include that type of information in the comments field when you're submitting a crash report (but usually only if you believe your crash is related or due to some extension or plugin). The comment field is for you to enter as much data as you want about the crash, so feel free to include anything and everything you care to tell us about. :-)<br />
<br />
==How can I induce a hung mozilla program to report via Talkback?==<br />
[Edit - partially answering my own question...]<br />
In Terminal.app, I tried guessing something and it worked:<br />
<pre>kill -ABRT <PID></pre><br />
where I found the <PID> with <br />
<pre>ps -auxww|grep "PID\|thunderbird-bin"|grep -v grep</pre><br />
and it worked. Example:<br />
<pre>MrE:~ elvey$ ps -auxww|grep thunderbird-bin<br />
elvey 15276 0.1 2.4 200164 31572 ?? Ss 10:17AM 0:07.92 /Applications/Thunderbird1.5RC2.app/Contents/MacOS/thunderbird-bin -psn_0_45744129<br />
elvey 15382 0.0 0.0 27804 4 p4 R+ 10:24AM 0:00.00 grep thunderbird-bin<br />
MrE:~ elvey$ kill -ABRT 15276<br />
</pre><br />
My Thunderbird has been hanging frequently (spinning wheel, Force Quit shows 'not responding'), but not crashing. Is there a kill signal I can send Thunderbird to get it to report what's up, i.e. a crashlog? HUP? INT? QUIT? ABRT? KILL? ALRM? TERM? (I'm on Mac OS X 10.4.6, Thunderbird 1.5.)<br />
:Whether doing this results in a useful talkback report is TBD. Having looked at what talkback planned to report, I'm guessing it won't be; the stack trace was empty.<br />
::Hmm. Thunderbird hung again, and I kill -ABRTed it, but this time talkback did nothing. :(</div>MrElveyhttps://wiki.mozilla.org/index.php?title=QA/Talkback/FAQ&diff=24260QA/Talkback/FAQ2006-04-19T17:28:28Z<p>MrElvey: /* Can I induce a hung mozilla program to report via Talkback? */</p>
<hr />
<div>== What does it mean when I see the following error when submitting a crash incident: "The Agent is unable to connect to the server. Please check your Proxy Server settings or try again later."? ==<br />
This error message is misleading. It does not always indicate a proxy related problem or mean that your incident has not been submitted to the Talkback Server.<br />
<br />
We do know that a lot of people with slower connections (dialup, isdn) sometimes have timing issues and do not get a response from the Talkback server saying that their crash was successfully processed and stored. If you open up talkback.exe, find an Incident ID, and look it up with FastFind, chances are you will find your crash.<br />
<br />
For more info, see [https://bugzilla.mozilla.org/show_bug.cgi?id=210251#c70 Bug 210251, Comment 70].<br />
<br />
== How do I disable Talkback? (not recommended) ==<br />
If you are having problems submitting crash incidents and continue to see the error discussed above, you can disable Talkback:<br />
* Firefox/Thunderbird 1.5.x: Run talkback.exe (launches the Talkback Client) in the extensions directory (<application dir>/extensions/talkback@mozilla.org/components) and select Settings->Turn Agent Off.<br />
* Firefox/Thunderbird 1.0.x: Run talkback.exe in the components directory (<application dir>/components) and select Settings->Turn Agent Off.<br />
<br />
== What data is sent with my crash incident? ==<br />
There are a number of things that are included in the crash incident that is submitted to us. For more info, see [http://www.mozilla.org/quality/qfa.html the Old QFA page on mozilla.org] (a bit outdated, but it shows you how to check what data will be sent with the Talkback Client after you crash). As far as I know, there is no other way to get a complete list until you trigger Talkback with a crash...at that point, clicking on the Details button will show you everything you might want to know (and allow you to uncheck items you don't want to send).<br />
<br />
== What additional information should I specify when submitting a crash incident? ==<br />
Aside from the data collected automatically by Talkback, the crash dialog allows you to specify your email address, a URL, and comments about your crash. It is important that you provide us with as much useful information as you can to improve our ability to debug the issue. This includes the website you were visiting, any plugins or extensions you think might be related to the crash, what you were doing, etc. If you have been able to crash consistently, exact steps to reproduce the crash would be ideal!<br />
* NOTE: If you submit your email address, it will be kept private (only Mozilla will be able to see that data). Personal information like IP and email addresses will not show up in public Talkback reports or query results.<br />
* TIP: If you want to easily look up your own incidents, you can always add a unique string that you will remember in the URL or Comments field and then query for it with QuickSearch<br />
** e.g. in the Comments field I might enter something like: "Crash submitting a from at http://someurl [jpcrash20060130]" - that way, I could go search for "jpcrash" and get all of my incidents in one easy query.)<br />
<br />
== As a developer for Mozilla's SVG code I'd like to learn how to narrow crash results to crashes occuring on SVG content. ==<br />
There are a number of ways to narrow down your query results to find specific types of crashes. For this case we'll look at SVG, but the same approach can be taken for any part of the code, feature, or component. Using the QuickSearch query tool at [http://talkback-public.mozilla.org/talkback/fastfind.jsp http://talkback-public.mozilla.org/talkback/fastfind.jsp]<br />
, you can try the following:<br />
* Search by a keyword in the Comments field (e.g. "svg"). This might not give you exactly what you want, but should provide a good number of crashes from people that were looking at SVG content...and from those results, you will be able to find some good URLs and comments to help look into SVG crashes.<br />
* Search by a function in the code in the Stack Signature field (e.g. "nsSVGGradientFrame::GetNextGradient", "NPSVG3.dll"). You can even search for substrings (just make sure to select the proper pull down item for where in the complete string to search, like "Contains", "Begins With", etc.).<br />
* Search by a website in the URL field (e.g. "http://www.w3.org/Graphics/SVG/"). This probably isn't the best option, unless you already know of a website that people have been crashing on consistently...but it can allow you to see what types of crashes are happening at certain popular websites.<br />
<br />
<br />
== Will you be looking at feedback from old builds? E.g. will you be looking at crash data from Firefox 1.5 in a month? Or is it only crashes in recent builds that are interesting? ==<br />
This is a great question and the answer will explain exactly why we need more help from the community. To get a better understanding of which builds need to be looked at, you first need to understand which development branches exist and which product/project releases come off of them:<br />
* Mozilla Trunk (FirefoxTrunk, ThunderbirdTrunk, MozillaTrunk [SeaMonkey])<br />
* Mozilla 1.7/1.0 Aviary Branch (Firefox10, Thunderbird10, Mozilla17)<br />
* Mozilla 1.8.0 Branch (Firefox15, Thunderbird15, SeaMonkey10)<br />
* Mozilla 1.8 Branch (Firefox2, Thunderbird2, SeaMonkey11)<br />
<br />
Looking at that list, I'll try to explain what type of crash analysis needs to be done for each:<br />
<br />
1. The Trunk branches are the latest bleeding edge builds with a lot of new features and changes being checked in. These builds are great to look at to find regressions quickly and get them fixed right away. Since those trees are almost always open to the community of developers, people are encouraged to check in patches there first (possible fixes for various branches make their way to the Trunk first, bake for a while, and if things look good, they are ported to the branches that need the fix). We will always need more eyes on Trunk builds...since that is where most of the work is happening (but not necessarily where most of the Mozilla Corporation QA team spends it's time).<br />
<br />
2. The Mozilla 1.0 Aviary branch is on it's way out since most of our users are switching to Firefox/Thunderbird 1.5.x (Mozilla 1.8.0 branch). People don't need to spend too much time looking at the crash data for builds/releases from this branch. However, we still support it and therefore need to look at it closely before and after any security point release. Firefox/Thunderbird 1.0.8 and Mozilla 1.7.13 are going to be the next releases, so it will be good to double check that they don't introduce any obvious regressions or bring down the overall stability when compared to Firefox/Thunderbird 1.0.7 and Mozilla 1.7.12.<br />
<br />
3. The Mozilla 1.8.0 branch is perhaps the most important right now to focus our time on, since it is what most of our users are using (therefore more Talkback crash data to help us do better analysis). Firefox/Thunderbird 1.5 and all their future security releases (e.g Firefox 1.5.0.1 coming out soon) will be released off this branch, and therefore a lot of work is happening there. Since it just recently came out, now is the time for us to identify and log as many critical crash bugs we can find. There is no guarantee that they will be fixed right away, but we still need to work hard to dig for them, create testcases, find steps to reproduce, and work with the developers and community to find a fix. Chances are, if we find a fix soon, and it is a safe patch, it might get into the next security release. If people decide it's too risky for a security release, it will surely be fixed on the Trunk and most likely on the next release branch as well (Mozilla 1.8 branch).<br />
<br />
4. The Mozilla 1.8 branch is for the next major version: Firefox/Thunderbird 2. While we continue to make Firefox/Thunderbird 1.5 more stable and secure, a lot of work is shifted over to this new branch. So, like the Trunk, this branch is where a lot of work is happening. It is another great place to watch crash data daily to catch any regressions and make sure we address new crashes as soon as possible. With Firefox/Thunderbird 1.5 reaching critical mass, this new 2.0 branch will become our main focus very soon. That means taking everything we have learned/gathered from Talkback crash data for 1.5 and trying to reproduce with 2.0 and see if the bug is still there, and if it is, try to get it fixed as soon as possible. Some crashes in 1.5 might not still be around in 2.0 (since a lot of code might have changed), so we need to make sure we identify what has carried over and what is new. This is perhaps the most challenging task, but by working together, we can make it a lot easier. :-)<br />
<br />
As you can see, there are plenty of things to keep track of... and since I have not been able to keep up with everything on my own, I can use all the help I can get. A few people already do a lot of crash analysis on their own, but we can always use more eyes! If you have any questions, feel free to contact me. You can find me on IRC in #qa. Also, take some time to query for crash bugs in Bugzilla by looking for the "crash" and "topcrash" keywords...that should give you a good idea of what is out there now.<br />
<br />
<br />
== If there is a backlog of incidents waiting to be processed on [http://talkback-public.mozilla.org/talkback/fastfind.jsp http://talkback-public.mozilla.org/talkback/fastfind.jsp], can I look at the crash info for my recent incidents on my computer? ==<br />
Unfortunatly, the data is not in a human-readable format on your local machine so there is no easy way to view it. You have to wait until the Talkback Server has processed your incident before looking it up by Incident ID or finding it in any query results.<br />
<br />
<br />
<br />
== I'd love to know if there is any trend analysis and/or reporting that I could do to help the coders identify the most common and/or problematic issues. Can I access the data and do analysis from my web browser? ==<br />
Yes! There are already a number of reports for the various development branches and official releases that already organize the crash data and sort it by total number of incidents. This not only helps us focus our work on the most critical crashes, but allows you to easily browse the data to do whatever type of crash analysis you want. There are also query tools for you to create your own reports on the fly. All of this can be found at [http://talkback-public.mozilla.org/talkback/fastfind.jsp http://talkback-public.mozilla.org/talkback/fastfind.jsp].<br />
* I will be writing up in more detail which reports are useful for different type of crash analysis soon. So keep an eye on the Talkback wiki page.<br />
<br />
<br />
== Does Talkback send what extensions/plugins you have installed? If not, should we list them in the comments? ==<br />
No, Talkback does no automatically send us information about your particular extensions or plugins. Therefore, it is a great idea to include that type of information in the comments field when you're submitting a crash report (but usually only if you believe your crash is related or due to some extension or plugin). The comment field is for you to enter as much data as you want about the crash, so feel free to include anything and everything you care to tell us about. :-)<br />
<br />
==How can I induce a hung mozilla program to report via Talkback?==<br />
[Edit - answering my own question...]<br />
In Terminal.app, I tried guessing something and it worked:<br />
<pre>kill -ABRT <PID></pre><br />
where I found the <PID> with <br />
<pre>ps -auxww|grep "PID\|thunderbird-bin"|grep -v grep</pre><br />
and it worked. Example:<br />
<pre>MrE:~ elvey$ ps -auxww|grep thunderbird-bin<br />
elvey 15276 0.1 2.4 200164 31572 ?? Ss 10:17AM 0:07.92 /Applications/Thunderbird1.5RC2.app/Contents/MacOS/thunderbird-bin -psn_0_45744129<br />
elvey 15382 0.0 0.0 27804 4 p4 R+ 10:24AM 0:00.00 grep thunderbird-bin<br />
MrE:~ elvey$ kill -ABRT 15276<br />
</pre><br />
My Thunderbird has been hanging frequently (spinning wheel, Force Quit shows 'not responding'), but not crashing. Is there a kill signal I can send Thunderbird to get it to report what's up, i.e. a crashlog? HUP? INT? QUIT? ABRT? KILL? ALRM? TERM? (I'm on Mac OS X 10.4.6, Thunderbird 1.5.)<br />
:Whether doing this results in a useful talkback report is TBD. Having looked at what talkback planned to report, I'm guessing it won't be; the stack trace was empty.</div>MrElveyhttps://wiki.mozilla.org/index.php?title=QA/Talkback/FAQ&diff=24259QA/Talkback/FAQ2006-04-19T17:08:51Z<p>MrElvey: How Can I trigger (kill signal) a hung program to report via Talkback?</p>
<hr />
<div>== What does it mean when I see the following error when submitting a crash incident: "The Agent is unable to connect to the server. Please check your Proxy Server settings or try again later."? ==<br />
This error message is misleading. It does not always indicate a proxy related problem or mean that your incident has not been submitted to the Talkback Server.<br />
<br />
We do know that a lot of people with slower connections (dialup, isdn) sometimes have timing issues and do not get a response from the Talkback server saying that their crash was successfully processed and stored. If you open up talkback.exe, find an Incident ID, and look it up with FastFind, chances are you will find your crash.<br />
<br />
For more info, see [https://bugzilla.mozilla.org/show_bug.cgi?id=210251#c70 Bug 210251, Comment 70].<br />
<br />
== How do I disable Talkback? (not recommended) ==<br />
If you are having problems submitting crash incidents and continue to see the error discussed above, you can disable Talkback:<br />
* Firefox/Thunderbird 1.5.x: Run talkback.exe (launches the Talkback Client) in the extensions directory (<application dir>/extensions/talkback@mozilla.org/components) and select Settings->Turn Agent Off.<br />
* Firefox/Thunderbird 1.0.x: Run talkback.exe in the components directory (<application dir>/components) and select Settings->Turn Agent Off.<br />
<br />
== What data is sent with my crash incident? ==<br />
There are a number of things that are included in the crash incident that is submitted to us. For more info, see [http://www.mozilla.org/quality/qfa.html the Old QFA page on mozilla.org] (a bit outdated, but it shows you how to check what data will be sent with the Talkback Client after you crash). As far as I know, there is no other way to get a complete list until you trigger Talkback with a crash...at that point, clicking on the Details button will show you everything you might want to know (and allow you to uncheck items you don't want to send).<br />
<br />
== What additional information should I specify when submitting a crash incident? ==<br />
Aside from the data collected automatically by Talkback, the crash dialog allows you to specify your email address, a URL, and comments about your crash. It is important that you provide us with as much useful information as you can to improve our ability to debug the issue. This includes the website you were visiting, any plugins or extensions you think might be related to the crash, what you were doing, etc. If you have been able to crash consistently, exact steps to reproduce the crash would be ideal!<br />
* NOTE: If you submit your email address, it will be kept private (only Mozilla will be able to see that data). Personal information like IP and email addresses will not show up in public Talkback reports or query results.<br />
* TIP: If you want to easily look up your own incidents, you can always add a unique string that you will remember in the URL or Comments field and then query for it with QuickSearch<br />
** e.g. in the Comments field I might enter something like: "Crash submitting a from at http://someurl [jpcrash20060130]" - that way, I could go search for "jpcrash" and get all of my incidents in one easy query.)<br />
<br />
== As a developer for Mozilla's SVG code I'd like to learn how to narrow crash results to crashes occuring on SVG content. ==<br />
There are a number of ways to narrow down your query results to find specific types of crashes. For this case we'll look at SVG, but the same approach can be taken for any part of the code, feature, or component. Using the QuickSearch query tool at [http://talkback-public.mozilla.org/talkback/fastfind.jsp http://talkback-public.mozilla.org/talkback/fastfind.jsp]<br />
, you can try the following:<br />
* Search by a keyword in the Comments field (e.g. "svg"). This might not give you exactly what you want, but should provide a good number of crashes from people that were looking at SVG content...and from those results, you will be able to find some good URLs and comments to help look into SVG crashes.<br />
* Search by a function in the code in the Stack Signature field (e.g. "nsSVGGradientFrame::GetNextGradient", "NPSVG3.dll"). You can even search for substrings (just make sure to select the proper pull down item for where in the complete string to search, like "Contains", "Begins With", etc.).<br />
* Search by a website in the URL field (e.g. "http://www.w3.org/Graphics/SVG/"). This probably isn't the best option, unless you already know of a website that people have been crashing on consistently...but it can allow you to see what types of crashes are happening at certain popular websites.<br />
<br />
<br />
== Will you be looking at feedback from old builds? E.g. will you be looking at crash data from Firefox 1.5 in a month? Or is it only crashes in recent builds that are interesting? ==<br />
This is a great question and the answer will explain exactly why we need more help from the community. To get a better understanding of which builds need to be looked at, you first need to understand which development branches exist and which product/project releases come off of them:<br />
* Mozilla Trunk (FirefoxTrunk, ThunderbirdTrunk, MozillaTrunk [SeaMonkey])<br />
* Mozilla 1.7/1.0 Aviary Branch (Firefox10, Thunderbird10, Mozilla17)<br />
* Mozilla 1.8.0 Branch (Firefox15, Thunderbird15, SeaMonkey10)<br />
* Mozilla 1.8 Branch (Firefox2, Thunderbird2, SeaMonkey11)<br />
<br />
Looking at that list, I'll try to explain what type of crash analysis needs to be done for each:<br />
<br />
1. The Trunk branches are the latest bleeding edge builds with a lot of new features and changes being checked in. These builds are great to look at to find regressions quickly and get them fixed right away. Since those trees are almost always open to the community of developers, people are encouraged to check in patches there first (possible fixes for various branches make their way to the Trunk first, bake for a while, and if things look good, they are ported to the branches that need the fix). We will always need more eyes on Trunk builds...since that is where most of the work is happening (but not necessarily where most of the Mozilla Corporation QA team spends it's time).<br />
<br />
2. The Mozilla 1.0 Aviary branch is on it's way out since most of our users are switching to Firefox/Thunderbird 1.5.x (Mozilla 1.8.0 branch). People don't need to spend too much time looking at the crash data for builds/releases from this branch. However, we still support it and therefore need to look at it closely before and after any security point release. Firefox/Thunderbird 1.0.8 and Mozilla 1.7.13 are going to be the next releases, so it will be good to double check that they don't introduce any obvious regressions or bring down the overall stability when compared to Firefox/Thunderbird 1.0.7 and Mozilla 1.7.12.<br />
<br />
3. The Mozilla 1.8.0 branch is perhaps the most important right now to focus our time on, since it is what most of our users are using (therefore more Talkback crash data to help us do better analysis). Firefox/Thunderbird 1.5 and all their future security releases (e.g Firefox 1.5.0.1 coming out soon) will be released off this branch, and therefore a lot of work is happening there. Since it just recently came out, now is the time for us to identify and log as many critical crash bugs we can find. There is no guarantee that they will be fixed right away, but we still need to work hard to dig for them, create testcases, find steps to reproduce, and work with the developers and community to find a fix. Chances are, if we find a fix soon, and it is a safe patch, it might get into the next security release. If people decide it's too risky for a security release, it will surely be fixed on the Trunk and most likely on the next release branch as well (Mozilla 1.8 branch).<br />
<br />
4. The Mozilla 1.8 branch is for the next major version: Firefox/Thunderbird 2. While we continue to make Firefox/Thunderbird 1.5 more stable and secure, a lot of work is shifted over to this new branch. So, like the Trunk, this branch is where a lot of work is happening. It is another great place to watch crash data daily to catch any regressions and make sure we address new crashes as soon as possible. With Firefox/Thunderbird 1.5 reaching critical mass, this new 2.0 branch will become our main focus very soon. That means taking everything we have learned/gathered from Talkback crash data for 1.5 and trying to reproduce with 2.0 and see if the bug is still there, and if it is, try to get it fixed as soon as possible. Some crashes in 1.5 might not still be around in 2.0 (since a lot of code might have changed), so we need to make sure we identify what has carried over and what is new. This is perhaps the most challenging task, but by working together, we can make it a lot easier. :-)<br />
<br />
As you can see, there are plenty of things to keep track of... and since I have not been able to keep up with everything on my own, I can use all the help I can get. A few people already do a lot of crash analysis on their own, but we can always use more eyes! If you have any questions, feel free to contact me. You can find me on IRC in #qa. Also, take some time to query for crash bugs in Bugzilla by looking for the "crash" and "topcrash" keywords...that should give you a good idea of what is out there now.<br />
<br />
<br />
== If there is a backlog of incidents waiting to be processed on [http://talkback-public.mozilla.org/talkback/fastfind.jsp http://talkback-public.mozilla.org/talkback/fastfind.jsp], can I look at the crash info for my recent incidents on my computer? ==<br />
Unfortunatly, the data is not in a human-readable format on your local machine so there is no easy way to view it. You have to wait until the Talkback Server has processed your incident before looking it up by Incident ID or finding it in any query results.<br />
<br />
<br />
<br />
== I'd love to know if there is any trend analysis and/or reporting that I could do to help the coders identify the most common and/or problematic issues. Can I access the data and do analysis from my web browser? ==<br />
Yes! There are already a number of reports for the various development branches and official releases that already organize the crash data and sort it by total number of incidents. This not only helps us focus our work on the most critical crashes, but allows you to easily browse the data to do whatever type of crash analysis you want. There are also query tools for you to create your own reports on the fly. All of this can be found at [http://talkback-public.mozilla.org/talkback/fastfind.jsp http://talkback-public.mozilla.org/talkback/fastfind.jsp].<br />
* I will be writing up in more detail which reports are useful for different type of crash analysis soon. So keep an eye on the Talkback wiki page.<br />
<br />
<br />
== Does Talkback send what extensions/plugins you have installed? If not, should we list them in the comments? ==<br />
No, Talkback does no automatically send us information about your particular extensions or plugins. Therefore, it is a great idea to include that type of information in the comments field when you're submitting a crash report (but usually only if you believe your crash is related or due to some extension or plugin). The comment field is for you to enter as much data as you want about the crash, so feel free to include anything and everything you care to tell us about. :-)<br />
<br />
==Can I induce a hung mozilla program to report via Talkback?==<br />
My Thunderbird has been hanging frequently (spinning wheel, Force Quit shows 'not responding'), but not crashing. Is there a kill signal I can send Thunderbird to get it to report what's up, i.e. a crashlog? HUP? INT? QUIT? ABRT? KILL? ALRM? TERM? (I'm on Mac OS X 10.4.6, Thunderbird 1.5.)</div>MrElvey