PDF content blocked by Chrome

rgaudin commented 1 year ago

When opening a PDF in a ZIM in the kiwix-serve viewer, on Chrome, there is an unrecoverable error message. This looks like a regression.

Go to https://dev.library.kiwix.org/viewer#lilote_fr_fo_2023-03/xay-va-%C3%A0-la-p%C3%AAche then click the Lire l'histoire button.

rgaudin commented 1 year ago

Might be related to #604

mgautierfr commented 1 year ago

I have no problem with firefox, chrome and chromium.

rgaudin commented 1 year ago

@Popolechien reported it ; I can reproduce on latest Chrome

rgaudin commented 1 year ago

Sorry the link is incorrect ; you have to use the viewer. I need to open a ticket about that as well

rgaudin commented 1 year ago

https://dev.library.kiwix.org/viewer#lilote_fr_fo_2023-03/xay-va-%C3%A0-la-p%C3%AAche

mgautierfr commented 1 year ago

Indeed. Removing the sandbox attribute solves the problem. This is probably introduced by https://github.com/kiwix/libkiwix/pull/906 (issue https://github.com/kiwix/kiwix-tools/issues/604)

Jaifroid commented 1 year ago

The code I give in that issue works around this specific problem with the pdf viewer in Chrome/Edge. It is not recognised by the browser as same origin, hence PDFs must be opened in a new window or tab. https://github.com/kiwix/kiwix-tools/issues/604#issuecomment-1470013026

rgaudin commented 1 year ago

That's quite a consequence in term of UI. If it's not possible to render it in the same iframe, maybe we should use an in-zim pdf.js but that's not as convenient

Jaifroid commented 1 year ago

Personally I think this is a Chromium bug, because the in-browser PDF viewer should clearly be same-origin when loading a PDF from the same origin. Or maybe it's a feature because PDFs can have active content that can contact external servers (?).

I didn't find any other workaround in Kiwix JS than to make click on a PDF open a new window/tab. Having said that, the new window uses the same in-built PDF viewer, so it's not too big a deal. Epubs have to be downloaded anyway because no browser provides a custom viewer.

It's a balance between the security of the iframe (in terms of not leaking info out: a particular concern with Zimit archives) and (in)convenience... Otherwise, there's really nothing to stop a script in the iframe navigating elsewhere.

NB sandboxing the iframe doesn't stop a determined malicious attacker, but it stops accidental redirects, accidental (or well intentioned) attempts by scripts to break out of iframes, and accidental contacting of external sites for font files, images and (potentially) scripts.

mgautierfr commented 1 year ago

See https://github.com/whatwg/html/issues/3958 which give some information.

PDF viewer is implemented as a plugin in chrome and it is deactivated in sandboxed iframe.

danielzgtg commented 1 year ago

Please also add allow-downloads. Some people may have a Firefox setup where "Settings > General > Files and Applications > Applications > Portable Document Format (PDF)" is set to "Save File" instead of "Open in Firefox". I heard there was a recent proposal to use ZIMs for serving .apk files, and this would be necessary to support their use case.

The sandbox attribute needs to stay to stop the Wiktionary zim from breaking. What's wrong with pdf.js? It would only make the experience more consistent across platforms.

veloman-yunkan commented 1 year ago

I guess that a fix addressing #912 but not this ticket doesn't make much sense. On the other hand, I think that a fix to this issue should also automatically fix #912.

Jaifroid commented 1 year ago

This is what we went for in Kiwix JS (for the sandbox attribute of iframe, or can be served as part of CSP response header):

allow-same-origin allow-scripts allow-modals allow-forms allow-popups allow-downloads

Jaifroid commented 1 year ago

@veloman-yunkan Is this sandbox attribute actually in force at library.kiwix.org yet? Because if you go to https://library.kiwix.org/viewer#wiktionary_en_all_nopic_2023-02 , you clearly see that a top-level navigation occurs and the iframe is destroyed..., and if I inspect the iframe just before the offending script runs that breaks out of it, I see what's in the screenshot below.

Now, if the sandbox isn't implemented at library.kiwix.org, it means that the issues with the PDF viewer are not directly down to #906, unless I'm missing something (or my browser cache is VERY persistent, despite clearing it)...

(Though I do think #906 will block PDFs in Chrome, because I already had to patch that in Kiwix JS.) Confused 😖...

Jaifroid commented 1 year ago

And, btw, that referrerpolicy should probably be none, rather than same-origin.

veloman-yunkan commented 1 year ago

@Jaifroid https://library.kiwix.org runs the latest release of kiwix-serve. #906 has not been released yet. Its side effects are currently demonstrated at https://dev.library.kiwix.org (to which this ticket refers).

Jaifroid commented 1 year ago

@veloman-yunkan Thank you for clearing that up!

veloman-yunkan commented 1 year ago

If it's not possible to render it in the same iframe, maybe we should use an in-zim pdf.js but that's not as convenient

@rgaudin Another option is to embed pdf.js in kwix-serve. However, I wonder what kind of inconvenience you referred to and whether it applies to the proposed solution too.

Jaifroid commented 1 year ago

Personally, I'd say there's no real inconvenience in the simplest solution of opening the PDF in a new tab or window. In many ways, it's better UX, because the user can keep that tab to read later and carry on browsing in the iframe. It also parallels the experience with EPUBs, which download separately rather than opening in the iframe. But I get that people have different opinions about such things!

rgaudin commented 1 year ago

Bundling pdf.js inside a ZIM means displaying PDF ourselves, via pdf.js. It means creating a host webpage which won't feel exactly as the in-browser pdf.js. Also, for those with other PDF reader configured, it means rendering in PDF.js then potentially downloading (pdf.js allows this) to trigger the default PDF reader. It's far from being as comfortable as the normal situation.

As for including pdf.js in kiwix-serve, I don't see how that would help… Do you want to add a kiwix-serve specific API to use it? Do you want to intercept application/pdf responses and render them as text/html with pdf.js ?

Then you have the SW discussion all over again (reader-ZIM dependency that's not part of the spec)

rgaudin commented 1 year ago

But I get that people have different opinions about such things!

Exactly.

We can look at this from both angles though:

ZIM creator decides how he wants his content to be used.
Reader creator has control over its reader UX and doesn't have to follow Web conventions.

The trick is that kiwix-serve is both a first-class reader and a Web party so boundaries are blurred.

I don't care much about the outcome of the tab thing but I am worried that we may be starting to drop support for regular web features. @kelson42 @Popolechien what do you think?

Jaifroid commented 1 year ago

For anyone coming to this longish thread at this point, the executive summary is as follows:

There is a vulnerability in Kiwix Serve and Kiwix JS related to the use of iframes to display articles: scripts in these articles can accidentally (or on purpose) navigate to remote sites and leak user data to remote servers, or they can break out of the iframe and destroy the app's controls;
A sandbox has therefore been added to the iframe to plug this vulnerability. This sandbox will not stop a purposefully malicious ZIM, but it will stop accidental navigation (as happens with recent Wiktionary), or accidental leakage (as happens when downloading remote fonts or, occasionally, images);
However, adding this sandbox proves to have a side effect that in Chromium browsers, the built-in PDF viewer is untrusted (by design, because PDFs can have active content), and PDFs are therefore blocked from rendering in a sandboxed iframe;
It is proposed instead that if a user clicks on a PDF link, the PDF will be opened in a new tab or window (not subject to sandboxing);
This is not the behaviour the creator of the ZIM may have intended, so there is a balance to be struck between security and respect for the intentions of the ZIM creator / trusted web resource.

mgautierfr commented 1 year ago

There is a vulnerability in Kiwix Serve and Kiwix JS related to the use of iframes to display articles: scripts in these articles can accidentally (or on purpose) navigate to remote sites and leak user data to remote servers, or they can break out of the iframe and destroy the app's controls;

No. The vulnerability is that we display a "falsely offline" version of website which can still phone home and leak user data to remote servers. This is how web works and except by blocking all connections to server, it can always append.

Before iframe, kiwix-serve was simply displaying the content in the top frame. "falsely offline" websites were obviously able to phone home. And as we were inserting the top bar in the content of the page, it was even simpler for the website to break out the app's controls. The iframe is the occasion to add some kind of protection against accidentally "falsely offline" website when it was impossible to do before. The change to iframe is not the source of the leak. However, we have exchange the website css breaking the css of the app controls against links with target=_top breaking the app controls.

There is no more user data leak than before. You can use the "no viewier/iframe" with the /content/zim_name/path/to/article to see that website can phone home all the time.

Blocking this requests was never a goal of kiwix-serve. It may change, but if it became a purpose, the solution is probably more in service worker (to control all connection going out of the displayed website) than in iframe.

This is not the behaviour the creator of the ZIM may have intended, so there is a balance to be struck between security and respect for the intentions of the ZIM creator / trusted web resource.

There is a balance between adding a new security level and not inferring in the website content (in chrome browser)

Blocking any link with target=_top (with sandboxed iframe) may not be a good idea neither. A website may be internally composed of several iframes. On iframe may display a menu with links changing the top iframe content. Allowing target=_top link breaks the (viewer) ui, but at least the website is usable. And this is difficulty patchable as other player than kiwix-serve/kiwix-js don't use iframe and so target=_top is totally valid. It would be to the viewer itself to dynamically patch (or intercept) links with target=_top and replace them with target=framename.

However, if the target=_top is not really needed, we can consider that as a bug in the scrappers and they should remove it.

Jaifroid commented 1 year ago

@mgautierfr in https://github.com/kiwix/kiwix-tools/issues/604#issuecomment-1460035994 I suggested that instead of using the sandbox attribute on the iframe, Kiwix Serve can serve all content with a CSP sandbox response header. I agree with you that this would be conceptually more elegant. However, we would still have this issue with PDF content not being rendered in Chromium browsers in the iframe, and also the issue with external links being blocked. Like in Kiwix Android, these will still have to be intercepted and opened in an external window. Adding the sandbox attribute in the response header or adding it in the iframe are exactly equivalent in terms of functionality (I've tested this in the PWA).

EDIT: It might be possible to serve only HTML with a CSP sandbox response header, but not serve PDFs with this header. It would need testing as to whether this would allow them to render in the iframe.

danielzgtg commented 1 year ago

No. The vulnerability

There are multiple versions of the bug. There is more information on Slack.

website css breaking the css of the app controls

Shadow DOM was designed for this problem.

a balance between adding a new security level and not inferring in the website content (in chrome browser)

And between fixing the website content (in Wiktionary)

A website may be internally composed of several iframes

Have we seen how archive.org does it? archive.org edits the HTML of all webpages to insert its header with the controls. It rewrites links, and this is to ensure multimedia paths work and external links are intercepted. With that strategy, we can either use the CSP HTTP header like you suggested, or we can inject a <meta> tag. archive.org does not edit the data of multimedia such as images, so PDFs should be rendered properly if we switch to that strategy.

Jaifroid commented 1 year ago

@danielzgtg I used to use only a <meta> tag CSP in Kiwix JS PWA, but unfortunately you can't use the sandbox attribute in <meta http-equiv...>. See Content-Security-Policy/sandbox:

This directive is not supported in the <meta> element or by the Content-Security-policy-Report-Only header field.

And without sandbox we can't stop top-level navigation. The other disadvantage of CSPs via <meta> is that you have to alter the HTML to inject the tag, whereas adding a CSP response header or iframe sandbox does not require altering the HTML in any way.

Rewriting links isn't necessary if you intercept the user's click on the iframe and inspect the target.

mgautierfr commented 1 year ago

There are multiple versions of the bug. There is more information on Slack.

Please put it somewhere on github (here or on https://github.com/kiwix/kiwix-tools/issues/604) has we need trace of the discussion. Slack is not public.

Shadow DOM was designed for this problem.

Give me more

Have we seen how archive.org does it? archive.org edits the HTML of all webpages to insert its header with the controls. It rewrites links, and this is to ensure multimedia paths work and external links are intercepted. With that strategy, we can either use the CSP HTTP header like you suggested, or we can inject a tag. archive.org does not edit the data of multimedia such as images, so PDFs should be rendered properly if we switch to that strategy.

We were modifying the content in kiwix-serve but we changed that especially to not modifying it. The idea is to interfere the less possible with the content in the zim file as this content should be "just working". (If not, fix the scrapper).

danielzgtg commented 1 year ago

There are multiple versions of the bug

Please put it somewhere on github

The 3 versions I had in mind are:

Wiktionary not working. A zim was changing window.top.location. CLOSED FIXED by adding <iframe sandbox="[everything except allow-top-navigation]">.
poc2 from https://github.com/kiwix/kiwix-js-windows/issues/377 . The <meta> wasn't being inserted if <head> is missing (possibly also affects svg or xslt if someone goes and tests) due to the regex not considering that. CLOSED FIXED by repeating the <meta> in the <head> outside the `</li> <li>poc1. The completely generalized form of the bug. I made a test zim that intentionally does bad things with <code>window.top</code>. CLOSED WONTFIX. It would be too hard, and the workaround is <a href="https://github.com/kiwix/kiwix-js/issues/974">https://github.com/kiwix/kiwix-js/issues/974</a></li> </ol> <details> <summary>The relevant chat logs are requested</summary> Jaifroid: Regarding the vulnerability @ Daniel T kindly reported in Kiwix JS (which also affects any JS that places ZIM contents in an iframe, including KJSWL and Kiwix Serve), the best that can be done in my opinion is to maximize browser-provided protections on the iframe such as adding the sandbox attribute (as @ Daniel T has suggested) and injecting a CSP into article HTML. The issue is that malicious code in a ZIM can break the iframe and cause seamless navigation to an external website that might phish user data. As far as I can tell, there is no possibility of a ZIM running system-level code on a user's machine because content from a ZIM cannot do any more harm than content on the open Web can do, because browsers do not allow any kind of system-level access unless the user has given explicit permission (as in picking a file from the hard drive). The main vulnerability is not technical but psychological IMHO: a user might expect a ZIM to be safe and trusted, and may lower their natural suspicion.The Electron framework does provide APIs for system access that could be misused by malicious actors, but I follow best security practices in isolating the rendering process, the browser window, and the main process in Electron, and only communicating between them via messaging. So I do not believe there is any low-level vulnerability there.Sandboxing is effective in preventing accidental top-level access by contents in a ZIM and also in preventing scripts in the ZIM from "phoning home" (whether accidentally or on purpose). However, it is not possible to stop ZIM contents from modifying the sandbox because we have to allow-scripts and allow-same-origin, or else the app simply can't access anything in the iframe and the app will be completely broken.So the issue really boils down to one of trust in terms of ZIM archives that Kiwix publishes. Zimit is a concern here, because we don't do any active vetting of content that goes into a ZIM via [youzim.it](http://youzim.it/).I have added the sandbox attribute to the test PWA, and version 2.4.0 will have this hardened (but not invulnerable) security. I'll do the same for Kiwix JS. I believe Kiwix Serve should also use sandboxing on the iframe. To see how Kiwix Serve is affected by the same vulnerability, visit https://library.kiwix.org/content/wiktionary_en_all_nopic_2023-02/A/Wiktionary:Offline and notice how a poorly coded script in the latest Wiktionary destroys the iframe page controls. I'll open an issue for this on Kiwix Serve. Kelson: @ Jaifroid looking to that topic from very far away… but a link to a ticket might help the audience to better know where you come from Jaifroid: I just created https://github.com/kiwix/kiwix-tools/issues/604 which has links to the principal tickets. Daniel T: So here's the story: Wiktionary 2023 comes out and I open it. Kiwix JS breaks from the zim containing a redirect and I thought it was only a minor annoyance rather than a vulnerability. I investigated why, fixed it locally with a userscript while I waited, and thought that was it. Thanks @ Jaifroid for fixing this in Kiwix PWA staging. He then introduced me to the PWA. He said there was a rigorous sandbox. So, you know, I haven't played capture-the-flag for a year and was bored, so I took that as a fun challenge. I generalized the redirect problem into running any code in the controls (poc1_2023-03.zim). I also looked at the CSP code and found a separate problem (poc2_2023-03.zim). This shouldn't affect most people who download exclusively from the trusted download.kiwix.org, but in an ideal world people should be free to download from anywhere Jaifroid: Just to confirm that the best fix I currently have is now in the latest release -- 2.4.0 -- of the PWA, UWP, NWJS and Electron versions (released about an hour ago), and I'll backport what is feasible to Kiwix JS for its next release. We're limited by what browsers provide in terms of sandboxing while allowing legitimate and required code to run. But as mentioned above, the browser itself provides pretty rigorous security, so the main risk here is of a ZIM abusing a user's trust, collecting information under false pretences and phoning home with it. Also the information is kind of scattered across many GitHub issues, so it might be necessary to recursively click on linked GitHub issues </details> <blockquote> <blockquote> <p>Shadow DOM was designed for this problem</p> </blockquote> <p>Give me more</p> </blockquote> <p>There is a good shorter-than-1-page demonstration at <a href="https://javascript.info/shadow-dom#encapsulation">https://javascript.info/shadow-dom#encapsulation</a> . We could do that for the controls instead of the <code><iframe></code> and still keep the our Kiwix style intact and isolated from the page. But that would require a minor modification to the page, which you said you don't want.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/mgautierfr"><img src="https://avatars.githubusercontent.com/u/86161?v=4" />mgautierfr</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <blockquote> <p>There is a good shorter-than-1-page demonstration at <a href="https://javascript.info/shadow-dom#encapsulation">javascript.info/shadow-dom#encapsulation</a> .</p> </blockquote> <p>I new world opens to me. Thanks for the link. It would have been nice to know about that few years ago</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Jaifroid"><img src="https://avatars.githubusercontent.com/u/4304337?v=4" />Jaifroid</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>On Shadow DOM, remember we need to support a wide range of browsers on possibly quite old devices, given where Kiwix Serve needs to be deployed, and although shadow DOM is now quite widely supported, that wasn't the case a few years ago, and it's still the case that support is patchy on mobile device browsers, for example. For maximum compatibility, I think we're still stuck with iframes. See <a href="https://caniuse.com/shadowdomv1">https://caniuse.com/shadowdomv1</a> .</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/danielzgtg"><img src="https://avatars.githubusercontent.com/u/25646384?v=4" />danielzgtg</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <blockquote> <p>wide range of browsers on possibly quite old devices, [...] on mobile device browsers</p> </blockquote> <p>Old mobile devices aren't a problem. Chrome is evergreen/autoupdatingo for Android 5+. My Firefox Nightly is Android 5+. It's evergreen too, and the only non-evergreen Firefox is Firefox ESR, but by its version number, it supports Shadow DOM too. Opera Mini is not a concern because it requires internet access to Opera servers. The only concern might be Android Browser / Android Webview. That is tied to the OS and used when the phone does not have Google Play Services.</p> <blockquote> <p>we need to support a wide range of browsers</p> </blockquote> <p>IE11 is the only problematic browser left. If that's the case we can include a shadow DOM polyfill. A quick Google search led me to <a href="https://github.com/webcomponents/polyfills/tree/master/packages/shadydom">https://github.com/webcomponents/polyfills/tree/master/packages/shadydom</a> and <a href="https://github.com/tuespetre/shadow-dom">https://github.com/tuespetre/shadow-dom</a> .</p> <p>@Jaifroid Can you commit a <code>.browserslistrc</code> file somewhere? I tried looking for it in kiwix-js, kiwix-js-windows, libkiwix, and kiwix-tools. kiwix-js only describes it in informal text and the versions written there seem to be higher than what you mean by "quite old devices". Both developers and automated tools can understand the <a href="https://github.com/browserslist/browserslist">https://github.com/browserslist/browserslist</a> standard. Having that file would bring everyone onto the same page about what browsers are need to be supported.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/rgaudin"><img src="https://avatars.githubusercontent.com/u/57929?v=4" />rgaudin</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <blockquote> <p>Old mobile devices aren't a problem. Chrome is evergreen/autoupdatingo for Android 5+</p> </blockquote> <p>This assumes Internet access which lack is precisely why we deploy Kiwix</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Jaifroid"><img src="https://avatars.githubusercontent.com/u/4304337?v=4" />Jaifroid</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>Coming back to the main purpose of this issue, I think I have a solution that allows us to sandbox ZIM articles and does not interfere with loading PDFs into the iframe. It is the one I outlined above, i.e. that we serve articles from the ZIM with a CSP sandbox response header, but not PDFs, and we remove the sandbox attribute from the iframe. I have a proof-of-concept here using the Kiwix JS browser extension's test PWA:</p> <ul> <li><a href="https://kiwix.github.io/kiwix-js/www/index.html">https://kiwix.github.io/kiwix-js/www/index.html</a></li> </ul> <p>Please ensure this is showing version 3.7.3 (if it's not, wait around 10 seconds for a notification that 3.7.3 is ready to load). This version correctly blocks the attempt at top-level navigation by the February English Wiktionary ZIM, but allows PDFs to load in the iframe. These are the settings used (some incidental things are specific to Kiwix JS):</p> <h3>Response headers</h3> <pre><code>// Set Content-Security-Policy to sandbox the content (prevent XSS attacks from malicious ZIMs) headers.set('Content-Security-Policy', "default-src 'self' data: blob: about: chrome-extension: https://moz-extension.kiwix.org https://kiwix.github.io 'unsafe-inline' 'unsafe-eval'; sandbox allow-scripts allow-same-origin allow-modals allow-popups allow-forms allow-downloads;"); headers.set('Referrer-Policy', 'no-referrer');</code></pre> <h3>Iframe</h3> <p><code><iframe id="articleContent" class="articleIFrame" src="article.html" referrerpolicy="no-referrer"></iframe></code></p> <h3>Meta http-equiv CSP (in the HTML document that contains the iframe)</h3> <pre><code><meta http-equiv="Content-Security-Policy" content="default-src 'self' data: https://download.kiwix.org https://master.download.kiwix.org https://moz-extension.kiwix.org https://kiwix.github.io 'unsafe-inline' 'unsafe-eval'; frame-src 'self' moz-extension: chrome-extension:; object-src 'none';"></code></pre> <p>I hope this is helpful in resolving this long-winded issue and also <a href="https://github.com/kiwix/kiwix-tools/issues/604">kiwix-tools#604</a> / #906.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/kelson42"><img src="https://avatars.githubusercontent.com/u/1029718?v=4" />kelson42</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>Thank you @Jaifroid for trying to wrap-up. I have a hard time to get a ckear picture myself. But is seems to me to be the best path. Anybody has a better alternative in mind?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Jaifroid"><img src="https://avatars.githubusercontent.com/u/4304337?v=4" />Jaifroid</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>Since he did #906, maybe @veloman-yunkan could kindly try a dev implementation of <a href="https://github.com/kiwix/libkiwix/issues/916#issuecomment-1483102716">the above</a> for Kiwix Serve, removing the Kiwix JS specific code, and setting the CSP/sandbox response header in the server code (not via a Service Worker). My test implementation (done with Kiwix JS) doesn't test the case of Zimit archives, because the Kiwix JS browser extension doesn't run those yet, so it would be important to test those thoroughly. The question of opening external links in a new tab/window may also need to be handled if Kiwix Serve doesn't already have a way of doing this, but it's not difficult and there is some suggested code in <a href="https://github.com/kiwix/kiwix-tools/issues/604#issuecomment-1470013026">https://github.com/kiwix/kiwix-tools/issues/604#issuecomment-1470013026</a> (NB the part of that code dealing with PDFs should be removed).</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/veloman-yunkan"><img src="https://avatars.githubusercontent.com/u/11933502?v=4" />veloman-yunkan</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>@Jaifroid I don't understand the mechanics of your solution but I implemented it in kiwix-serve (though without any host URLs like <code>https://moz-extension.kiwix.org</code> included in the <code>default-src</code> list). PDFs are still blocked in chromium. While trying to test your PWA at <a href="https://kiwix.github.io/kiwix-js/www/index.html">https://kiwix.github.io/kiwix-js/www/index.html</a> the displayed version is 3.7.2 and no notification about 3.7.3 being ready shows up.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/veloman-yunkan"><img src="https://avatars.githubusercontent.com/u/11933502?v=4" />veloman-yunkan</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <blockquote> <p>I don't understand the mechanics of your solution</p> </blockquote> <p>@Jaifroid By above I meant that I don't see why the described setup should enable the chrome PDF extension (that is not same-origin) being loaded in an iframe that only allows same-origin content.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Jaifroid"><img src="https://avatars.githubusercontent.com/u/4304337?v=4" />Jaifroid</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>@veloman-yunkan The test implementation was erased yesterday by a push to master of a completed PR. However, I've just restored it, so if you visit that address again, and wait 10s or so, it should offer you v3.7.3 (<del>see screenshot</del>). To load, exit the browser and then re-visit that page. It should then show 3.7.3 and allow you to test.</p> <p>Regarding setting the headers in Kiwix Serve, how are you doing this? And are you setting response headers only for HTML? I suspect you need to set different headers (or none) for a PDF, but I don't know that for sure without testing empirically.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Jaifroid"><img src="https://avatars.githubusercontent.com/u/4304337?v=4" />Jaifroid</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <blockquote> <blockquote> <p>I don't understand the mechanics of your solution</p> </blockquote> <p>@Jaifroid By above I meant that I don't see why the described setup should enable the chrome PDF extension (that is not same-origin) being loaded in an iframe that only allows same-origin content.</p> </blockquote> <p>Because you will no longer be setting a sandbox on the iframe. You will be setting it only in the HTTP response headers.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Jaifroid"><img src="https://avatars.githubusercontent.com/u/4304337?v=4" />Jaifroid</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>Here is top-level navigation (English Wiktionary) being blocked by 3.7.3, and below that is a PDF (Greek Gutenberg) showing in the iframe in Edge (Chromium) also on 3.7.3:</p> <p><img src="https://user-images.githubusercontent.com/4304337/228007070-4e6885db-fbda-4881-a6a4-1bdbea3a3bf0.png" alt="image" /></p> <p><img src="https://user-images.githubusercontent.com/4304337/228007216-7625761f-1b28-40a2-a727-fac4cca5ade0.png" alt="image" /></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/veloman-yunkan"><img src="https://avatars.githubusercontent.com/u/11933502?v=4" />veloman-yunkan</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <blockquote> <p>@veloman-yunkan The test implementation was erased yesterday by a push to master of a completed PR. However, I've just restored it, so if you visit that address again, and wait 10s or so, it should offer you v3.7.3 (~see screenshot~). To load, exit the browser and then re-visit that page. It should then show 3.7.3 and allow you to test.</p> </blockquote> <p>@Jaifroid Thanks. The 3.7.3 PWA doesn't load PDFs in the iframe either (when using chromium).</p> <blockquote> <p>Regarding setting the headers in Kiwix Serve, how are you doing this? And are you setting response headers only for HTML? I suspect you need to set different headers (or none) for a PDF, but I don't know that for sure without testing empirically.</p> </blockquote> <p>Let's dig into this after you confirm that the PWA works for you using this ZIM file: <a href="https://master.download.kiwix.org/zim/.hidden/dev/lilote_fr_test_2023-01.zim">https://master.download.kiwix.org/zim/.hidden/dev/lilote_fr_test_2023-01.zim</a></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Jaifroid"><img src="https://avatars.githubusercontent.com/u/4304337?v=4" />Jaifroid</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <blockquote> <p>@Jaifroid Thanks. The 3.7.3 PWA doesn't load PDFs in the iframe either (when using chromium).</p> </blockquote> <p>Works for me in Edge Chromium (see screenshots posted above)... I'll try your ZIM.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Jaifroid"><img src="https://avatars.githubusercontent.com/u/4304337?v=4" />Jaifroid</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>Working fine with that ZIM. Are you sure the app is showing 3.7.3 in top-left corner?</p> <p><img src="https://user-images.githubusercontent.com/4304337/228009004-b7a4eef7-3ab7-4454-8bd5-04d15afc1f11.png" alt="image" /></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Jaifroid"><img src="https://avatars.githubusercontent.com/u/4304337?v=4" />Jaifroid</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>Also working in Chrome 110 (previous screenshots were Edge Chromium 111):</p> <p><img src="https://user-images.githubusercontent.com/4304337/228013549-039890bb-eb95-4197-aea2-fbe83a14d5e5.png" alt="image" /></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/veloman-yunkan"><img src="https://avatars.githubusercontent.com/u/11933502?v=4" />veloman-yunkan</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>Doesn't work with Chromium Version 90.0.4430.212 (installed on Ubuntu 20.04 using <a href="https://askubuntu.com/a/1206153">these instructions</a>)</p> <p><img src="https://user-images.githubusercontent.com/11933502/228033123-afeda931-6381-4950-a27b-5026b8d12ca2.png" alt="Screenshot from 2023-03-27 22-26-04" /></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Jaifroid"><img src="https://avatars.githubusercontent.com/u/4304337?v=4" />Jaifroid</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>OK, I'll see if I can reproduce and debug with Chrome 90 on Windows.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/kelson42"><img src="https://avatars.githubusercontent.com/u/1029718?v=4" />kelson42</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>Thx for investogating this in details, but pretty possible that a bug in Chrome has been fixed between versions 90 and 110.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Jaifroid"><img src="https://avatars.githubusercontent.com/u/4304337?v=4" />Jaifroid</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>Yes, I've just checked on Browser Stack, and I confirm that the bug is present in Chrome 90, but it was fixed in Chrome 91 (pictured below) and later. Chrome 90 doesn't recognize the PDF loaded as being of origin 'self'.</p> <p><img src="https://user-images.githubusercontent.com/4304337/228217686-e505f70f-c932-4d93-a471-549f0e80ac26.png" alt="image" /></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/rgaudin"><img src="https://avatars.githubusercontent.com/u/57929?v=4" />rgaudin</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>FYI Chrome 91 was introduced in <a href="https://chromereleases.googleblog.com/2021/05/stable-channel-update-for-desktop_25.html">May 2021</a></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/Jaifroid"><img src="https://avatars.githubusercontent.com/u/4304337?v=4" />Jaifroid</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>Yes, it's pretty recent, but it's actually quite hard to stay on Chrome 90, because Google updates it almost as soon as you install it. Of course that wouldn't be the case with Chromium on Linux.</p> <p>I haven't spent a long time trying to find out if there's a workaround for Chrome 90, but I did try specifying the site (<a href="https://kiwix.github.io">https://kiwix.github.io</a>) as an allowed frame-src and even tried deleting the mtea http-equiv CSP, but the bug persists. The error in DevTools just confirms the block.</p> <p><img src="https://user-images.githubusercontent.com/4304337/228221488-b4d08a98-64bb-49dd-a554-9cc270c5e084.png" alt="image" /></p> <hr /> <p>Bottom line, unless someone has a specific patch for Chrome <=90's behaviour, it seems to me we have these choices:</p> <ol> <li>Revert sandboxing added in #906, leaving the Kiwix Serve iframe vulnerable to top-level navigation like in the February Wiktionary (which started all this!) and XSS;</li> <li>Adopt the fix we're testing here (needs further careful testing with different ZIMs), but advise users of Chrome <= 90 that they will need to upgrade if they want to view PDFs;</li> <li>Add the workaround which opens any PDF in a separate tab or window (sample code provided here: <a href="https://github.com/kiwix/kiwix-tools/issues/604#issuecomment-1470013026">https://github.com/kiwix/kiwix-tools/issues/604#issuecomment-1470013026</a>). NB workaround is only for PDFs opened with a user gesture.</li> </ol> <p>In Kiwix JS we decided to adopt 3 (actually version 2 + 3), as it is the most universal solution, even if it doesn't mimic precisely what the original web site developers may have intended. Users are forced to open EPUBs in a separate app, so opening PDFs in a separate tab is not so much of a sacrifice IMHO.</p> </div> </div> <div class="page-bar-simple"> <a href="/kiwix/libkiwix/916?page=2" class="next">Next</a> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>

kiwix / libkiwix

PDF content blocked by Chrome #916