Opening any website in Iframe within any Tab

[Sahebjot Singh]

My Chrome extension allows previewing any website in iframe within a Tab. Making it a split within a Tab.

I've seen some solutions about bypassing CSP, X-Frame-Options:Deny, Frame-Options etc

Is it possible to solve for all websites, all possible cases just by managing the Headers using for techniques mentioned here https://github.com/dotproto/extension-demos/blob/main/iframe-embedding/background.js and discussions in 
https://groups.google.com/a/chromium.org/g/chromium-extensions/c/v0srmN-1hg0/m/dXx1WrOhAAAJ

My main question is also around policy, can removing such headers break webstore policy and get the extension banned in some way?

Saheb

[Patrick Kettner]

The. Grime Web Store does not have any policy prohibiting the modification of headers. If it is being used for a legitimate purpose to provide user value and is not engaging in malicious activity, there shouldn't be any issue.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/16fff831-2bc3-47cd-9670-f2fab6a25aben%40chromium.org.

[Simeon Vincent]

I'd advise some caution here. While there aren't policies that specifically say you can't modify headers, CWS does have policies that require developers to securely handle user data and avoid vulnerabilities. Here are two sections of the policy that leap to mind.

Handling Requirements
1. If your product is associated with a security vulnerability that could be exploited to compromise another application, service, browser, or system, we may remove your product from the Chrome Web Store and take other measures to protect users. In such an event, you may be contacted about remediation steps required to restore the product. Chrome extension security vulnerabilities can be reported here.

Malicious and Prohibited Products
1. Don't transmit viruses, worms, defects, Trojan horses, malware, or any other products of a destructive nature.

Depending on the implementation, a developer implementing the feature you described could end up accidentally relaxing the browser's built in security in a way that poses a significant risk to the end user. In such a case, CWS has more-than-reasonable grounds on which to take action against the extension. To be clear, I'm not saying the implementation you have in mind violates CWS policy. I'm saying that what you're considering has the potential to pose significant risk and therefore I'd recommend proceeding with caution. 

Simeon - @dotproto

incremental.software

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAPAuxoCTdMUWv2t9wCNVNyEk0ki0eFU3z-i-SG-Pkytn%2B2P-wg%40mail.gmail.com.

[Cuyler Stuwe]

In general I’ve had a good track record when I relied on human judgment to correctly ascertain the intent of a tool.

Almost all technology that can be used for good can be used for bad. This is true even of something as simple as pen-and-paper. Mere potential for misuse isn’t really grounds for hindering technology.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CACA%3D7_bbAwyt_j5p%3DE_E2L1JwLAZGvjGzr7TOdD%2Bjrv2%2BLf0TA%40mail.gmail.com.

[Jackie Han]

Ideally, this problem would be solved if extensions supported webview (instead of iframe) and allowed to open any host permissions allowed webpages.

[wOxxOm]

webview for extension was denied multiple times over the past 10 years (e.g. https://crbug.com/422805), but there's an upcoming web thing that replicates the relevant aspect (embedding the site in top context): <controlledframe>, https://crbug.com/1448277

[Jackie Han]

1. Controlled Frame

I took a very cursory look at "Controlled Frame".

Controlled Frame is only available to IWAs, it will not be available to normal web pages. Isolated Web Apps (IWAs) are not hosted on live web servers and fetched over HTTPS, these applications are packaged into Web Bundles, signed by their developer ……

If so, it doesn't solve the problem here. 

2. webview in extensions

It was rejected in the past because of some concerns. But the motivation of that feature request was exactly the problem stated here. A few years ago, Chrome proposed a solution for Android - Trusted Web Activity. It requires the owner of the app to be the same as the owner of the website, which solves the trust issue. According to extensions security model, if you have a website's host permission, you can do whatever the website owner can do.

In summary, there is currently no ideal solution. I think browsers should be able to design a better solution for extensions.

[wOxxOm]

Indeed, the link I gave (https://crbug.com/1448277) is not a solution but a suggestion to enable such solution for extensions and hopefully it'd be a relatively simple task. I think this is our best (or only) chance of having a solution for extensions in the observable future.

[Sahebjot Singh]

Thank you all for your responses, it's really helpful.

I'm just building a productivity tool, nothing malicious. 

I wanted ability to preview another tool/app as a productivity feature for my users.

While researching this ability to open another website side by side I found lots of constraints being put on the iframe. I went with opening a popup window as a temporary solution.

I'll be fine with hacking around the headers to make sure things work well and making sure security is not compromised for my users, but for such legit use cases a more standard solution on the web would be valuable because as of now we do not have ability to add another website easily within a tab but very easy with a popup window where the issue is title bar cannot go away and it is a separate window.
For such legit use cases hopefully it will be easier in future :)

Thanks again. 

[Uladzimir Yankovich]

In addition, we must admit that changing the headers is a very unstable solution. Especially, if you want to load the site on a different host.

You received this message because you are subscribed to a topic in the Google Groups "Chromium Extensions" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-extensions/ccvoUp7bphw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/03995356-7fc5-4577-8485-08e08619ab63n%40chromium.org.

--

Uladzimir Yankovich,

Founder @ Manganum (manganum.app).

[Jackie Han]

but there's an upcoming web thing that replicates the relevant aspect (embedding the site in top context): <controlledframe>, https://crbug.com/1448277

Here you mentioned "Controlled Frame". There is another concept called "Fenced Frames". It also contains the concept of "top-level browsing context".

On Fri, Jun 30, 2023 at 1:35 PM wOxxOm <wox...@gmail.com> wrote:

[Jackie Han]

I tried Fenced Frames a bit. It solves the detection of `self===top`, but other problems still need to be dealt with, like removing CSP and X-Frame-Options headers.

{
  "id": 1,
  "priority": 1,
  "action": {
    "type": "modifyHeaders",
    "responseHeaders": [
      { "header": "Content-Security-Policy", "operation": "remove" },
      { "header": "X-Frame-Options", "operation": "remove" },
      { "header": "Supports-Loading-Mode", "operation": "set", "value": "fenced-frame" }
    ]
  },
  "condition": { "urlFilter": "*", "resourceTypes": ["main_frame", "sub_frame"] }
}

[wOxxOm]

>  solves the detection of `self===top`,

Awesome! This is the most pesky thing because it's impossible to fake the `top` global.

[Jackie Han]

There is a new discussion about this on WECG https://github.com/w3c/webextensions/issues/483