For apps like Facebook, when ever you browse from news-feed and click an external link, it opens the link within it’s own browser.
When PWA’s are run in standalone mode (without browser UI), a Facebook like PWA might decide to link user to a web page in the news feed which it might want to open in its own frame without making user launch Chrome, because that reduces the time in App. Native apps have this competitive advantage. The browser inside the Apps can decide what code to run into the framed page inside the app.
A hacky way around for the web think is to simply reverse proxy the page and make changes server side before serving to the client.
The web needs a way to embed pages, even those that do now allow framing because native apps allow them.
In my prototype, we have to reverse proxy every page, and then cache for certain time period server side if it is not dynamic. We plan to make a browser extension in the meanwhile to fully support the required behavior.
A solution would be an additional attribute to iframe tag. When 3rd party cookies are not loaded as parent, iframe element must have the ability to embed pages even if headers say no, because that is the equivalent to the ability of native apps. And ability to have containerized cookies, so that users can login to external websites from the frame in our PWA. That containerized iframe must also have the ability to manipulate the cookies, scripts, css of the embedded page.
Also this will allow us to block ads in the frame, and require publishers to pay like 30% to allow ads to be viewed, just like the model of the brave browser or AdBlock Plus, which does the same thing. In case they refuse, it is no loss to us or the user.
None of what I stated is impossible possible now, just that it requires proxying. Any malicious/bad actor will always be able to phish, therefore this measure is useless, and prevents legitimate use cases.
If I’m missing something, please explain me.