Kathleen, can you schedule some time with me and Alina to talk about the plan for this feature? It'd be best if whoever is designing & implementing this is also present, as we're going to want to talk about the UI/opt-in/notice plans in detail.
Hi Kathleen, Just wanted to follow up as I didn't see your response. Have you talked with anyone about this yet? If not, could we schedule some time this week to discuss? Thanks, Alina
Hi Alina, I don't know who will be designing/implementing this yet, so nothing to discuss at the moment. Thanks, Kathleen
We're beginning to work on the SSL Error Reporting mechanism. https://wiki.mozilla.org/Security/Features/SSL_Error_Reporting We have a few privacy-related questions that we would like to discuss with you before we get to far along in the design. For instance: - Do we need the user's permission to send us the data? - Do we need to tell the user what data will be sent to Mozilla? As a description? Or the specific data? - Can the user opt-in once, and then always have their untrusted error connections sent to Mozilla? I would like to setup a Vidyo meeting with you, the developer, and the UX designer. Who from the privacy team should be included in this meeting?
From Gerv: My meta-suggestion is that we should tie this as closely as possible to the existing practices and permission grants around telemetry and/or crash data. http://www.mozilla.org/en-US/legal/privacy/firefox.html Crash-Reporting Feature - opt-in - personal info (e.g. IP address and URL of site) are additional opt-in Usage Statistics (also known as Telemetry) - opt-in (on/off via preference) - transmitted via SSL
Actually, I think there are two things here. Firstly, we have a desire to gather info about SSL errors in general. We should tie that in to the telemetry permission - that's the sort of thing it is, feedback on browser performance. Secondly, we really, really want to know about pin violations, because they are indicative of MITMing. I think that in that case, even if the user has not opted in to automatic data transmission, the pin violation error should have a "Report this to Mozilla" button. (And if that reporting fails, we should warn the user that the reporting mechanism may be being blocked, and put the info into a file that the user can email or submit via some other way.) Gerv
We need someone from the privacy team, really. Although I work for Alex, I'm not going to put myself forward for that (although he may nominate me :-). Gerv
Actually, I now see that this bug is already assigned to Alina, and she's commented earlier in its life. So she seems like the right person to start with. Alina? Gerv
(In reply to Tom Lowenthal [:StrangeCharm] from comment #10) > In the mean time, it'd probably be a good idea to start working on the UX > and implementation. As new details, questions, and issues emerge during the > implementation, it would be prudent to check-in with Alina to make sure that > things are still in line with our privacy principles OK. We've requested the UX wireframes for this approach. Thanks.
Gerv / Tom - Thanks for flagging this. Kathleen - Are you free to discuss this week?
(In reply to Gervase Markham [:gerv] from comment #6) > Actually, I think there are two things here. Firstly, we have a desire to > gather info about SSL errors in general. We should tie that in to the > telemetry permission - that's the sort of thing it is, feedback on browser > performance. We already gather telemetry on the types of SSL errors that our users encounter. We don't collect info like which sites, but we do measure the frequency of each type of error. Are you suggesting we collect site info too? > even if the user has > not opted in to automatic data transmission, the pin violation error should > have a "Report this to Mozilla" button. Yes, this. Lets do that.
(In reply to Sid Stamm [:geekboy or :sstamm] from comment #13) > (In reply to Gervase Markham [:gerv] from comment #6) > > Actually, I think there are two things here. Firstly, we have a desire to > > gather info about SSL errors in general. We should tie that in to the > > telemetry permission - that's the sort of thing it is, feedback on browser > > performance. > > We already gather telemetry on the types of SSL errors that our users > encounter. We don't collect info like which sites, but we do measure the > frequency of each type of error. > > Are you suggesting we collect site info too? No, not under the telemetry permission. I was obviously arguing for something we already do. Stats link? :-) Gerv
see bug 767676 and bug 707275. I was wrong about the cert error telemetry, but we gather a little bit about what errors people see (bug 767676). It's hard to link into the Telemetry dashboard, but the histogram for the UI measurements is SECURITY_UI. We should probably try to finish 707275 to understand more about types of certs encountered.
I just spoke with Mika - she said that the Privacy Notice changes need to go through Governance review, which she will post in the next few days. She estimates that WebDev will make the updates to the website in a couple weeks.
Current UI mockup: http://cl.ly/image/2F0d2e2K061v The text "Reporting the address and certificate information for this site..." and the "Learn More..." link to https://support.mozilla.org/kb/secure-website-certificate tell the user what information they would be sending to Mozilla.
(In reply to Kathleen Wilson from comment #19) > Current UI mockup: http://cl.ly/image/2F0d2e2K061v This mockup has a "Retry" button. In what circumstances do we think that the Retry button will ever produce a different result to the first try? Certainly if the cert is marked as revoked, and we retry, and for some reason we make a successful connection, that's probably bad! This mockup says "please contact the website owners to inform them of this problem", and it also has a "Report problem" link which does not contact the website owners (it contacts us). We should perhaps remove the text about the site owners, or clarify that there are two entities the user may wish to contact. Also, "please contact the website owners to inform them of this problem" is bad advice because they can't get through to the website, so how could they possibly do that? There are more wording things we should fix. What does "Peer's certificate" mean? It talks about "the authenticity of the received data", but if the cert was revoked, then we never received any data. "Automatically report errors in the future" should be "Automatically report similar errors in future", so it doesn't seem too broad in scope as a permission. Having said all that, the new part looks pretty good, and it's an awesome feature :-) Gerv
Created attachment 8439263 [details] Certerror-spec.png The latest spec for the new part with some modifications and clarifications. Gerv, the issues you mention all sound very reasonable to me, but they really should be a separate bug.
(In reply to Philipp Sackl [:phlsa] from comment #21) > Gerv, the issues you mention all sound very reasonable to me, but they > really should be a separate bug. Some of them, perhaps, but others are caused by the new UI because they are about the interactions between it and the old text. E.g.: "This mockup says "please contact the website owners to inform them of this problem", and it also has a "Report problem" link which does not contact the website owners (it contacts us). We should perhaps remove the text about the site owners, or clarify that there are two entities the user may wish to contact." Also, the last one was about the new UI specifically. Gerv
Current UI plan: http://cl.ly/image/1f3k0Q1R0l2Q
Just so you know, I've also added: Version (of the report format) BuildID Product, and Channel (is the user release, aurora, etc) at bsmedberg's request (see also bug 846489)
Is there anything left to do here?
SSL Error Reporting landed in Firefox 36, per Bug #846489.