Talk:MHTML

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).

Websites: Computing Low‑importance

	This article is part of WikiProject Websites, an attempt to create and link together articles about the major websites on the web. To participate, you can edit the article attached to this page, or visit the project page.WebsitesWikipedia:WikiProject WebsitesTemplate:WikiProject WebsitesWebsites articles
Low	This article has been rated as Low-importance on the importance scale.
	This article is supported by WikiProject Computing.

IE problem[edit]

Here is an interesting cross domain leackage hack, that is implemented using mhtml

IE6.0 and IE7.0 Vulnerable to Complete Cross Domain Leakage

This is some of the worst ownage I’ve seen in a long time. Secunia announced a really nasty cross domain leak for Internet Explorer. This allows anyone with control over a webserver to control anything you do with any page you can connect to. It’s interesting that Secunia marked it as a “less critical” threat, as this pretty much gives any attacker read access to any domain anywhere as long as you are using Internet Explorer 6.0 or 7.0.

The only saving grace here is that it does require access to a server where you can write HTTP headers (or somewhere that you can do header injection/redirection) as you need to force the browser to go to a certain URL which then redirects to another URL. Here’s what the header’s look like:

   telnet secunia.com 80
   Trying 213.150.41.226…
   Connected to secunia.com.
   Escape character is ‘^]’.
   GET /ie_redir_test_2 HTTP/1.0

   HTTP/1.1 302 Found
   Date: Thu, 19 Oct 2006 15:39:00 GMT
   Server: Apache
   Location: http://news.google.com/
   Connection: close
   Content-Type: text/html

At this point the client is redirected to the server as you (with your credentials) and it is returned as a cachable mhtml file that can be read via XMLHttpRequest since it “appears” to your browser to be located on the machine that did the redirection. Pretty clever. I’ve played around with these sorts of things before but was never successful (obviously I never tried mhtml). It seems to me that someone was saving this one.

And remember our nonces we were using to protect against CSRF? Well forget it, they’re readable by the cross domain leakage now. I don’t know why anyone would say this is a less critical risk as this is complete ownage of the entire internet for users of Internet Explorer. Hopefully Microsoft will patch this one quickly.

This entry was posted on Thursday, October 19th, 2006 at 8:49 am and is filed under XSS, Webappsec. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site. One Response to “IE6.0 and IE7.0 Vulnerable to Complete Cross Domain Leakage”

firefox support[edit]

Edit: 04/02/2008 (U.S. date format). This has changed. According to the previously mentioned bug (#18764) Firefox has supported MHT/MHTML since at least 2004-03-21 (see https://bugzilla.mozilla.org/show_bug.cgi?id=18764#c38). More specifically, the changelog shows: vladd@bugzilla.org 2004-04-08 03:20:05 PDT Summary RFE: Full rfc2557 MHTML multipart/related support in BROWSER Full rfc2557 MHTML multipart/related support in BROWSER.

However, the bug does still show as open as of this date, so perhaps full functionality is not present or maybe someone just needs to verify the fix and close the bug. The writer lacks the skill and experience to do so.

--05:08, 3 April 2008 216.84.63.194

Information on Firefox 3 should be included. 82.41.15.93 (talk) 02:50, 12 May 2008 (UTC)[reply]

Having researched this further I found I was able to add functionality to FF3b5(and all current versions it seems) by using an add-on, MAF, and changing it slightly. Should this be mentioned, or is it too obscure?82.41.15.93 (talk) 03:49, 12 May 2008 (UTC)[reply]

I can confirm that Firefox, using UnMHT, can open without any problem MHT files saved with Microsoft OneNote containing images, text and ink. (Epgui (talk) 23:25, 14 September 2008 (UTC))[reply]

I think it's stupid to waste so many words on browsers that don't support them. This is Wikipedia, not a howto to get around browsers' lack of a feature.84.197.139.54 (talk) 07:12, 26 October 2010 (UTC)[reply]

Roland Bouman, 2011-02-18: I would like to add that Firefox supports the jar: uri scheme, which allows resources like images, css and script files as well as regular HTML documents to be saved in a single archive.

Jacosi, 2012-03-01: This section seems outdated. Firefox 10.0.2 seems to open mht file OK, without installation of any extension. Could someone who knows more about it check and update the info accordingly? — Preceding unsigned comment added by Jacosi (talk • contribs) 14:31, 1 March 2012 (UTC)[reply]

Editing support[edit]

Hi, fellow Wikipedians

I rewrote the Editing Support section of this article. However, in order to provide verification I used the software program itself as the source and reference for verification, adding links to publicly-available trial versions wherever possible.

Now, using a software program as a source in Wikipedia, as far as I know, is legal: Many computer game articles (e.g. Final Fantasy X-2) are already doing this, referring to a specific dialog in a specific part of a computer game.

However, I understand that this type of source is, shall we say, expensive to verify. Therefore, if someone has better sources, please do not hesitate to modify current sources. In the meantime, please do not remove these sources if you do not have a better replacement, unless there is a change in Wikipedia rules. Fleet Command (talk) 09:25, 15 April 2008 (UTC)[reply]

I just removed the editing support section. It had a heavy bias on Microsoft products and isn't really noteworthy. It's just HTML with base64. A text editor can do it in theory and there are 1000s of text editors. — Preceding unsigned comment added by 109.145.165.125 (talk) 22:39, 3 August 2012 (UTC)[reply]

Templates[edit]

I removed the opera template because it has nothing to do with opera except that opera support mhtml.
I didn't remove the ie template, because ms is the inventor(and/or it is already in the template itself)
I add the web browsers template, because it is a possible feature and it is a standard and it is only used in web browsers (because it is a browser related format!)

and now? mabdul 20:37, 14 May 2009 (UTC)[reply]

Hrmmm... OK, after reading your points, it seemed to me we simply had different ideas on the point of Navboxes. After reading up on WP:Policy on them it seems they should be placed wherever the links within the Navbox would "help the reader in reading up on related topics". IE and Office contain "Technologies" sections but Opera does not, so remove it.ox would be useful if it did contain such a "Technologies" section... _ɹəə pıɔnı 22:56, 14 May 2009 (UTC)[reply]

mmh, again what I said: why should we add this format to the opera template? we could alo add http and html to both templates o.O

and wouldn't the reader helped to have a short navigation to web browser related template? mabdul 07:14, 15 May 2009 (UTC)[reply]

IE 4 & IE5[edit]

OK, right now I'm editing the article and found two interesting "bugs". source 1: [1] says IE 5 add mhtml file support! source 2: [2] says IE4 add support for mhtml.

what is right? can somebody test it? mabdul 18:42, 15 May 2009 (UTC)[reply]

According to Wikipedia, MHTML support was was added in IE5: Internet Explorer 5#Overview. In know that Wikipedia can not be used as a reference for itself, but I think this is correct. Ghettoblaster (talk) 19:10, 15 May 2009 (UTC)[reply]

Security Risk?[edit]

What if any security risk does this file format pose? I feel like a user could be prompted to download this and not think to be as cautious as they would be with, say, an exe. Can things wrapped in MIME HTML execute locally, for instance? If so, this should be documented. —Preceding unsigned comment added by 158.104.165.243 (talk) 00:19, 21 January 2010 (UTC)[reply]

Wikipedia is not a forum. If you have a particular source of information you feel should be added to the article that's fine, but otherwise... _ɹəə pıɔnı 08:14, 21 January 2010 (UTC)[reply]

Google Chrome[edit]

Google Chrome 15 won't support MHTML. I saw those sources, but the fact is that simple: there is no support of MHTML in stable user versions of Chrome yet. — Preceding unsigned comment added by 109.227.209.240 (talk) 10:37, 27 October 2011 (UTC)[reply]

Cleaned up article[edit]

I've just removed all the pointless, trivial details from the browser support section. Please refrain from making this article feature-complete with all the unnecessary, intricate compatibility concerns and references to "known issues" in bug trackers. This is an encyclopaedia, not a archive of pointless details. — Preceding unsigned comment added by 109.145.165.125 (talk) 22:35, 3 August 2012 (UTC)[reply]

Saving vs Parsing Support[edit]

The section regarding browser support addresses only support for "Save As", whereas there is a seperate issue of whether or not the browser supports content served in this format, which are not necessarily one and the same. Webpages can use mhtml to serve content such as encoded images, which is certainly supported by IE, but I'm unsure if it is supported by other browsers. If someone can find definitive resource on this then that would be an important addition that should be included. 199.44.231.8 (talk) 23:03, 31 July 2013 (UTC)[reply]

Stackoverflow as a source?[edit]

This article links to a StackOverflow question as a source, which in turn links back to this article. StackOverflow is not a valid source, nor is a bug report for an open source program. I removed the offending paragraph. — Preceding unsigned comment added by 74.94.126.121 (talk) 19:24, 23 August 2013 (UTC)[reply]

Needed clarifications[edit]

My update...
Having read in a forum that LibreOffice should not implement a MHTML export plugin because a MHTML file is not a document (with reference to this article), I thought that that world designer missed something and that a slight rephrasing would be welcome.
Also, the interchangeability of the Web archive with an e-mail message file is something that almost nobody knows.
The aticle should probably mention the capabilities of MUAs to load/save such files.

Are you sure Opera 22.0 (Chromium-based) or Opera 15.0/16.0 and above really support MHTML?[edit]

I'm using Opera 22.0 now and until now I still can't save nor load MHT file from/to this Chromium-based Opera (may be in the future versions, but this current one certainly does NOT!). The article writer should recheck his bloated unsync-ed opera webfantasies again.

>>Opera has supported MHTML since version 16. It's undocumented, but if you use the configuration line included in the main article, it will activate it. Vivaldi supports it the same way(disabled by default, but possible to enable it through built-in configurations). Also, "bloated unsync-ed opera webfantasies" is not a very professional way to discuss what you believe to be incorrect facts in the article.

AFAIK, only Opera 12.xx and below (Presto-based) support MHTML file load/save with ultimate compatibility+compactness besides fast load/save, and that's far-stunning than MSIE can do (MSIE 7.0).

— Preceding unsigned comment added by 112.215.66.77 (talk) 10:30, 2 August 2014 (UTC)[reply]

Blocked?[edit]

I'm noticing I can view an MHTML file locally (the page displays), but if I put it on a webserver, when I view it, I see the raw source. (If I save it off the webserver and view that file locally - the page displays too; not surprising, the files are byte-for-byte identical.) I'm guessing this is because the security issues have led (some) browsers to only process local MHTML files. Something the article could cover. (Reading between the lines, it seems support has been declining.)

(PS: A comparison with Webarchive and Web ARChive would be helpful too.)

--50.201.195.170 (talk) 21:22, 30 July 2020 (UTC)[reply]