* Create a mdn page about the Mixed Content Blocker (developer doc?) * Personal blog post about Mixed Content Blocker and its various phases * Blog post from Mozilla Security Blog * Create sumo help pages about the Mixed Content Blocker - explaining what it is, what it looks like, the impact of disabling it, and how to disable it. * Update https://developer.mozilla.org/en-US/docs/Security/MixedContent to include the Mixed Content blocked messages and more about the Mixed Content Blocker.

I guess I should also blog about the design...

Make sure to include the information in: https://bugzilla.mozilla.org/show_bug.cgi?id=838359#c22 https://bugzilla.mozilla.org/show_bug.cgi?id=836459#c13

I'll be very happy to help on the MDN documentation side. Feel free to ping me for a review if you write the doc or to send me the raw material so I put it in shape.

(In reply to David Bruant from comment #3) > I'll be very happy to help on the MDN documentation side. Feel free to ping > me for a review if you write the doc or to send me the raw material so I put > it in shape. Thanks David! I think the first step is to write the "Learn More" documentation (bug 822373 - http://support.mozilla.org/en-US/kb/how-does-content-isnt-secure-affect-my-safety). Also, I wrote a blog post on the feature and I think a lot of the mdn documentation can be extracted from that: https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/

Status Update Done: * Personal blog post about Mixed Content Blocker and its various phases https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/ * Create sumo help pages about the Mixed Content Blocker - explaining what it is, what it looks like, the impact of disabling it, and how to disable it. http://support.mozilla.org/en-US/kb/how-does-content-isnt-secure-affect-my-safety In Progress: * Blog post from Mozilla Security Blog Not Done: * Create a mdn page about the Mixed Content Blocker (developer doc?) * Update https://developer.mozilla.org/en-US/docs/Security/MixedContent to include the Mixed Content blocked messages and more about the Mixed Content Blocker.

Hi David, Do you think you could start a rough draft of the MDN documentation by extracting out and reordering content from here: https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/ http://support.mozilla.org/en-US/kb/how-does-content-isnt-secure-affect-my-safety The above links contain all the information needed for an MDN doc. With the exception for a "How to Fix your Site" section, which we can add on in a later draft.

Status Update Done: * Personal blog post about Mixed Content Blocker and its various phases https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/ * Create sumo help pages about the Mixed Content Blocker - explaining what it is, what it looks like, the impact of disabling it, and how to disable it. http://support.mozilla.org/en-US/kb/how-does-content-isnt-secure-affect-my-safety * Blog post from Mozilla Security Blog - https://blog.mozilla.org/security/2013/05/16/mixed-content-blocking-in-firefox-aurora/ * Update https://developer.mozilla.org/en-US/docs/Security/MixedContent to include the Mixed Content blocked messages. (Thanks Garrett for your help!) Not Done: 1) Create a mdn page about the Mixed Content Blocker feature - Describe the feature and technical details. Most of this can be found from https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/ 2) Create A How-To-Fix-My-Site Guide on mdn - Teach developers how to identify Mixed Content issues on their website (look at developer tools) and how to fix them (replace http:// resources with their https:// equivalents) 3) Update https://developer.mozilla.org/en-US/docs/Security/MixedContent to include more about the Mixed Content Blocker. This page doesn't talk about the Mixed Content Blocker much. Once the mdn page for Mixed Content Blocker is done, we should link to that 4) Future of Firefox blog most when Mixed Content Blocker moves from Aurora to Beta.

So during the doc sprint I worked on: * https://developer.mozilla.org/en-US/docs/Security/MixedContent I've mostly been detailing how active and passive content relate to what web devs can expect. * https://developer.mozilla.org/en-US/docs/Security/MixedContent/fix_website_with_mixed_content A short page on how to fix a website. Everything isn't finished yet, but it's a good start I believe. Thanks Tanvi for all the content on your blog! I have a bunch of questions: * I guessed and wrote that all cases when a url value is used in CSS are considered as active content. Is it the case? If not, could you detail which is and which isn't (and why) * Regarding the <link> element, are all requests considered active content or just those with @rel="stylesheet"? I'm thinking of @rel="prefetch" for instance which sends an HTTP request, often for the purpose of putting something in cache. If done through HTTP, a danger exists. However, maybe some other values of @rel could be harmless. * I felt a bit dumb when I wrote the "how to fix your website" part: "For other domains, use the site's HTTPS version if available. If HTTPS is not available, there is not much you can do." If a different domain doesn't have an HTTPS version and the browser prevents HTTP-based communication with this domain, then, we've lost a bit of functionality. I feel that to some extent, it should be allowed as it is unreasonable to believe that everyone will move to or start with HTTPS even if they should. And until they do, they're unreachable from HTTPS websites (unless the HTTPS website proxies the HTTP service which is barely better). Getting content from a third-party is a leap of faith anyway since the thrid-party may be down or corrupted (buggy or attacked). I feel that third-party mixed content should be allowed. Although there are some websites broken by mixed content blocking here and there, I feel it's going to make it to the main release channel. This will make 3 major browser implementing mixed content blocking. I feel it isn't crazy to talk about a de facto standard. Have you considered talking to standard people so that it becomes standard? It would be a good occasion for the different browsers to discuss in order to eventually agree where they currently disagree https://bugzilla.mozilla.org/show_bug.cgi?id=844556#c11 and have that agreement formalized.

Hi David, Thank you so much for your help with this! You have done a great job updating https://developer.mozilla.org/en-US/docs/Security/MixedContent. I've changed a handful of words and submitted a new edit (diff is here - https://developer.mozilla.org/en-US/docs/Security/MixedContent$compare?to=424529&from=423121). In this comment, I will attempt to answer your questions relating to this article. I will comment on the "How to fix" page in a separate comment. > * I guessed and wrote that all cases when a url value is used in CSS are > considered as active content. Is it the case? If not, could you detail which > is and which isn't (and why) HTTP stylesheets are considered Mixed Content. If an HTTP stylesheet is included on page, it will be blocked. But if the stylesheet is HTTPS, it will be included. An HTTPS stylesheet may include an HTTP url. If that HTTP url is for a font, it will be blocked as Mixed Active Content. If it is for an image, then it is categorized as Mixed Passive and loaded. Hence, there is no general rule for urls embedded in CSS. It depends on the content-type of the load. If it is in background-image, the browser will expect and image and consider the load TYPE_IMAGE. If it is in a font-face, the browser will consider the load TYPE_FONT. Here is a breakout of Mixed Passive/Mixed Active in terms of content types. I'm not sure it is going to be useful though. It may not be feasible to define active content by html tags and attributes. Passive: * TYPE_IMAGE - <img> or background-url, and a slew of other css options. * TYPE_MEDIA - <audio> or <video> * TYPE_OBJECT_SUBREQUEST - requests made by <object>'s * TYPE_PING - this is turned off by default in Firefox, so we don't need to worry about it or mention it. Active: * TYPE_CSP_REPORT: the csp report url is specified in a header and not in the HTML of the page * TYPE_DTD - specified in <!DOCTYPE * TYPE_FONT - specified in font-face and perhaps other places? * TYPE_OBJECT - <object> tags * TYPE_SCRIPT - <script> tags. Script can also be included from other script. * TYPE_STYLESHEET - As far as I know, these are just <link rel="stylesheet" ...>. Some of the other options for rel will fall into different categories. for example rel=icon would be TYPE_IMAGE. * TYPE_SUBDOCUMENT - <iframe> * TYPE_XBL - -moz-binding: url in CSS * TYPE_XMLHTTPREQUEST - Ajax requests * TYPE_OTHER - we don't really know what falls into this category (really nothing should; a new content type should be created). Looking in mxr, there is only one place it is used for a content load - http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#1113 > * Regarding the <link> element, are all requests considered active content > or just those with @rel="stylesheet"? I'm thinking of @rel="prefetch" for > instance which sends an HTTP request, often for the purpose of putting > something in cache. If done through HTTP, a danger exists. > However, maybe some other values of @rel could be harmless. See above. I haven't gone through all the rel options (there are ~15) and figured out if they map to a content type, but we could. prefetch is an interesting case. I wonder what content-type a prefetch load falls into. I don't think the browser knows whether it is prefetching an <img> or a <script>. Either way, an HTTP prefetch is a mixed content fetch - even if the content isn't loaded yet, the HTTP headers are sent along with the user's cookies. I'll have to look into prefetch specifically. For the rest of the rel options, do you think it's worth going through them and categorizing them? If so, I'll look at those too. > Although there are some websites broken by mixed content blocking here and > there, I feel it's going to make it to the main release channel. This will > make 3 major browser implementing mixed content blocking. I feel it isn't > crazy to talk about a de facto standard. Have you considered talking to > standard people so that it becomes standard? It would be a good occasion for > the different browsers to discuss in order to eventually agree where they > currently disagree https://bugzilla.mozilla.org/show_bug.cgi?id=844556#c11 > and have that agreement formalized. We have discussed this in the webappsec working group. So far it has just been a discussion, but the other browser vendors are also interested in standardizing this. In fact, Chrome is planning on changing some of their classifications for active vs. passive to align more closely with ours. Thanks again! This has been a great help!

(In reply to David Bruant from comment #8) The "How to fix" page looks good! I made a few edits: https://developer.mozilla.org/en-US/docs/Security/MixedContent/fix_website_with_mixed_content$compare?to=424919&from=423735 One thing to note, I removed "You can also consider using HSTS so that browsers that support it will fix the HTTP links for you in case you forget.". This is because both Chrome and Firefox will currently block HTTP links on HSTS HTTPS pages, even though the links would have been upgraded to HTTPS. There is more discussion on this in bug 838395 and here https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/#Appendix. I replaced that sentence with some more guidance. > * I felt a bit dumb when I wrote the "how to fix your website" part: > "For other domains, use the site's HTTPS version if available. If HTTPS is > not available, there is not much you can do." > If a different domain doesn't have an HTTPS version and the browser prevents > HTTP-based communication with this domain, then, we've lost a bit of > functionality. I feel that to some extent, it should be allowed as it is > unreasonable to believe that everyone will move to or start with HTTPS even > if they should. And until they do, they're unreachable from HTTPS websites > (unless the HTTPS website proxies the HTTP service which is barely better). > Getting content from a third-party is a leap of faith anyway since the > thrid-party may be down or corrupted (buggy or attacked). > I feel that third-party mixed content should be allowed. > > Third party mixed active content is just as dangerous as mixed active content from the domain itself. Making an exception for third party mixed content puts the user at risk. If websites want to embed third parties that don't use HTTPS (via iframes, for example), they should consider only including this content on the HTTP version of their site. If the third party is a partner or if the website has some sort of relationship with the third party, they could talk to the third party and ask them to provide an ssl version. In some cases, the third party might have an SSL cert and certain content on HTTPS. In those cases, the domain would just have to ask for one more piece of content (or one category of content) to be moved to the SSL server. For now, I've changed this part of the mdn page to say the following. We can keep iterating. "For other domains, use the site's HTTPS version if available. If HTTPS is not available, you can try contacting the domain and asking them if they can make the content available via HTTPS."

Thanks for the edits and the comments, Tanvi! (In reply to Tanvi Vyas [:tanvi] from comment #10) > Third party mixed active content is just as dangerous as mixed active > content from the domain itself. Making an exception for third party mixed > content puts the user at risk. If websites want to embed third parties that > don't use HTTPS (via iframes, for example), they should consider only > including this content on the HTTP version of their site. This isn't a very satisfactory solution. It means that the user has to navigate back and forth between HTTP and HTTPS within the same website; or, in the case of an MITM attack, navigate from HTTPS to HTTP and being stucked there if only following links. Staying on HTTPS at all time is an important feature for user security... now that I said that, I realize that there is indeed no solution to have third-party HTTP services securely embedded on an HTTPS page. > If the third > party is a partner or if the website has some sort of relationship with the > third party, they could talk to the third party and ask them to provide an > ssl version. > > In some cases, the third party might have an SSL cert and certain content on > HTTPS. In those cases, the domain would just have to ask for one more piece > of content (or one category of content) to be moved to the SSL server. Asking really is a leap of faith and I'm not a big fan of these, but I guess that can work. Also, maybe that 3rd party HTTP services not working in HTTPS websites on modern browsers will be enough of an incentive for these services to move to HTTPS. > For now, I've changed this part of the mdn page to say the following. We > can keep iterating. Sounds good. Thanks!

David, do you think we need another mdn page (or a subsection of the Mixed Content page) that talks about the UI? The blog goes through and details each UI option. Maybe we don't need this in MDN because it is sort of covered in this sumo page (https://support.mozilla.org/en-US/kb/how-does-content-isnt-secure-affect-my-safety). Just want to check to make sure that between these three pages, we have sufficient documentation of the Mixed Content Blocker. Do you think we've covered everything we need to? https://developer.mozilla.org/en-US/docs/Security/MixedContent https://developer.mozilla.org/en-US/docs/Security/MixedContent/fix_website_with_mixed_content https://support.mozilla.org/en-US/kb/how-does-content-isnt-secure-affect-my-safety Thanks!

(In reply to Tanvi Vyas [:tanvi] from comment #12) > David, do you think we need another mdn page (or a subsection of the Mixed > Content page) that talks about the UI? The blog goes through and details > each UI option. Maybe we don't need this in MDN because it is sort of > covered in this sumo page MDN is developer oriented (either web/app devs or Mozilla product devs). * I don't think webdevs need to worry about Firefox UI, because they really have no control over it. The distinction about active and passive content is important because it affects what's blocked or not and explains the new messages in the console. * It might be worthwhile documenting internal Firefox features regarding mixed content so that other Firefox devs and addon devs can plug can (re)use the existing mixed content infrastructure (pop the dialog for add-on specific resources for instance). I'll let to those with expertise with mixed content infrastructure and Firefox/addon development to make that call, but I'll be happy to help if I can. > (https://support.mozilla.org/en-US/kb/how-does-content-isnt-secure-affect-my- > safety). I think support.m.o is the right channel to talk about Mixed Content UI-related aspects. > Just want to check to make sure that between these three pages, we have > sufficient documentation of the Mixed Content Blocker. Do you think we've > covered everything we need to? > > https://developer.mozilla.org/en-US/docs/Security/MixedContent > https://developer.mozilla.org/en-US/docs/Security/MixedContent/ > fix_website_with_mixed_content > https://support.mozilla.org/en-US/kb/how-does-content-isnt-secure-affect-my- > safety Yeah, I feel non-dev users and webdevs needs are mostly covered. Maybe addon devs and Firefox devs may need some additional documentation.

Hi David, Have you had a chance to incorporate my answers in comment 9 to https://developer.mozilla.org/en-US/docs/Security/MixedContent. Specifically, the "Active Content List" at the bottom of the page. This section is tricky, since it is probably impossible to include all html tags where mixed active content can occur. Thanks! ~Tanvi

(In reply to Tanvi Vyas [:tanvi] from comment #14) > Hi David, > > Have you had a chance to incorporate my answers in comment 9 to > https://developer.mozilla.org/en-US/docs/Security/MixedContent. Not yet. Assigning myself so it stays on my radar and I address it soon.

https://developer.mozilla.org/en-US/docs/Security/MixedContent For now, I have changed - This section lists all types of HTTP requests which are considered active content: to This section lists some types of HTTP requests which are considered active content: So that it is clear that it is not an all-inclusive list.

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.