-
Notifications
You must be signed in to change notification settings - Fork 130
How we could use the safer BrowserWindow
instead of webviewTag
?
#152
Comments
Can you give the exact reference please? As far as I know webview are perfectly safe if you keep The BrowserView VS webview debate is not about security but stability and performance. See: https://slack.engineering/growing-pains-migrating-slacks-desktop-app-to-browserview/
I guess you meant BrowserView? I may be wrong, but I think we can't switch to BrowserView unless rewriting the whole electron-tab library. BrowserView is not a part of the DOM, so we can not manage it with a web component as we do in electron-tabs. So if you want to use BrowserView for your tabs I'm afraid you will have to write your own implementation from scratch. |
I'm closing this issue. I would reopen it if you demonstrate that webview is intrinsically insecure. |
@brrd I actually was misleaded by the |
This question is out of the scope of electron-tabs. You should probably ask the Electron community. |
@brrd Hi Thomas! I asked the This is the interesting answer I got: `"Hey @raphael10-collab, thanks for asking this! The honest answer to your question is "we don't know." As of this time, there aren't any plans to remove webviewTag on Electron's side. However, webviewTag is is part of the deprecated Chrome Apps platform - as such, Chrome could decide to remove it or drop support at any time. According to this timeline outlined by Chrome itself, Chrome is planning to end support for Chrome Apps for all customers next month, June 2022: https://blog.chromium.org/2020/01/moving-forward-from-chrome-apps.html This isn't a guarantee that the element will be removed then, but I think it should be seen as a warning. My recommendation to you would be to remove any chrome.webviewTag dependencies in your apps as soon as possible, while the API is deprecated, but still available. Chrome included a migration guide for appis using the Chrome Apps platform API here: https://developer.chrome.com/docs/apps/migration/ I hope this helps you! Since this issue doesn't represent a task needing to be completed, I'm going to close it, but please feel free to ask in our Discord if you have more questions - we have many active help channels and mentors, as well as fellow devs, who can help you out."` |
Thank you for the information. I just rewrote electron-tabs a few days ago using web components. Moving to BrowserView would require a new rewriting of the whole library which I'm not willing to do right now (electron-tabs is a volunteer project, I can't spend my full time on it unfortunately). We obviously don't know anything about Chrome short term plans, so let's wait and see until we get some new information. The current API is still perfectly working with current versions of Electron, which is the important thing IMO. |
From the
electron
docs https://www.electronjs.org/docs/v14-x-y/api/browser-window :webviewTag Boolean (optional) - Whether to enable the [<webview> tag](https://www.electronjs.org/docs/v14-x-y/api/webview-tag). Defaults to false. Note: The preload script configured for the <webview> will have node integration enabled when it is executed so you should ensure remote/untrusted content is not able to create a <webview> tag with a possibly malicious preload script. You can use the will-attach-webview event on [webContents](https://www.electronjs.org/docs/v14-x-y/api/web-contents) to strip away the preload script and to validate or alter the <webview>'s initial setting
Based on what we read in the electron docs,
webviewTag
set totrue
doesn't seem to be secure and safe.I tried to use
BrowserView
instead, but didn't succeed in showing the webpages up:demo/app.js
:How we could use then the safer
BrowserWindow
instead ofwebviewTag
?The text was updated successfully, but these errors were encountered: