Feature required for next-gen PWA’s

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.

This sounds a lot like the browser element request from a few weeks ago.

@Garbee Yes that is correct. What they are describing sounds like exactly our use case. To frame a website inside our PWA that can be installed and run as a standalone.

There is no significant security risk involved as any of those ‘security’ measures can be easily circumvented as the guy quoted has said in the thread. This only prevents legitimate use cases.

If you want to continue further discussion it should probably happen in that thread. But, one point I did make in that thread is that browsers have spent years building up these security measures for a reason. Why should we now ask them to provide an element (or some system) to strip it all away? It’s literally saying years of security work in browsers is all for nothing.

I’m not saying, “It can be circumvented anyways so why bother?” like everyone wanting this seems to be. The question is where is it being circumvented? In the browser directly or in a system which an attacker is playing man-in-the-middle? MiTM attacks are far more intrusive and very difficult to work against. But general fly-by attacks in browsers is harder because of these measures. It would need to be a very compelling reason to strip the security structures away compared to “well it can be done anyways.”

The question is where is it being circumvented?

Assume that you are on example.com. You embed an iframe with

<iframe src="https:///www.google.com/">

The iframe fails to load because

"google.com" has set "X-FRAME-OPTIONS: SAMEORIGIN"

You can request the iframe to not have cookies from parent google.com, and even then it fails to load.

Here is a way to easily get around it this false limitation:

Set up a server (called iframe.example.com) that transfers resources between Google.com and example.com and strips the X-FRAME-OPTIONS header, and replaces requests destination with google.com/resource to iframe.example.com/get/www.google.com/resource.

In the end your iframe src looks like this: <iframe src="https://iframe.example.com/get/www.google.com/">

The page than successfully loads. The user is signed out from the google, because to the iframe src domain is iframe.example.com.

We are asking for the same behavior without any iframe.example.com. The element/attribute on the original iframe tag should allow us to modify anything on google.com (i.e: html, ecmascript, css) if the cookies for google.com are not loaded and compartmentalized under example.com.

There is no increase in security risk since all of this is possible now with relative ease.

Although, you make a point exactly like the previous discussion had. And all there is to that is… The point isn’t “something is capable of being bypassed already so let’s make it easy”. That’s actually exactly the point, we want to raise the bar and make attacks more difficult, costly, and time consuming to do. Just like Content Security Policy, it isn’t a sure thing. But it raises the bar to attack sites that properly implement it.

But, this should be continued in the previous thread. Along with a detailed understanding of why we should decrease user security by making phising attacks easier and removing origin isolation.

Well, security through obscurity isn’t exactly security. For PWA’s that customize the web pages to fit the app theme or would like to embed a website in the news feed, it becomes really difficult. AMP pages for example could be using custom fonts to fit the PWA’s theme. And stuff like that.

Native apps at-least on Android can do all of this, either via side loading or installing via Play Store. In my subjective opinion, the barrier to entry to bypass these “security measures” is not high enough, hence this only prevents legitimate use cases. A malicious webapp will always be able to do this no matter what, so why not increase the performance and load times for legitimate use cases?

Phishing is still possible with little to no difficulty. And its also bad for the embedded websites because if we cache their pages, they dont get to know the real analytics/stats.

If you still disagree, I’ll release the X-FRAME-OPTIONS stripper as open source for everyone to use. There is exactly zero security benefit. I would even go as far as to say this is an illusion of security.

Just by using a reverse proxy server to handle the Different-Origin-Problem we can get around this stupid limitation. Why not allow the web to be competitive?

Instead of whining about how it is “simple to bypass” and how “native can do it so the web should no problem” you should approach the situation with, “Here is how origin isolation doesn’t work to protect users so we should add features that ignore it.” Justify that you understand origin isolation and the impacts it has on security, as well as why it is more powerful and doesn’t decrease security to allow bypassing it. Then there can be a productive conversation to move this proposal forward.

Without a true justification beyond “native” or “proxy’s allow this” this isn’t going to fly. Native has a fundamentally different security structure. The web doesn’t work like that with how software is distributed and executed. And proxy’s are actually essentially conducting a man-in-the-middle attack, something that is aggressive to users, very dangerous, and once again, actively discouraged in the web to be used in the contexts you’ve provided. It is too easy for them to hand over sensitive access credentials or data to parties unknown.

Answer this… Why should any given site someone visits simply be able to include Facebook or Twitter in the background and instantly have access to the data stores within that page’s origin? This is a very serious security concern when you consider hidden on-the-fly attacks to collect data. Or find as much information as possible preparing for a phising attack.

So once again, prove you understand why origin isolation is implemented the way it is. From that, show why it simply doesn’t work and you should get this kind of access in the future. Thus far, you’ve only shown us that it doesn’t work for what you want to do in particular therefore it must be bad. Not that you’re understanding why it is this way at the foundation. If you understand that and the security model of the web, then you’d probably be just as paranoid as everyone else about opening this kind of access up.

OLS: what kind of user experiences are you trying to achieve? What are the benefits for users and content owners?

Have you looked into Web Package and Portals?

Why should any given site someone visits simply be able to include Facebook or Twitter in the background and instantly have access to the data stores within that page’s origin?

Because as long as cookies are compartmentalized there is no additional risk to not give. Malicious actors are easily able to do this using a reverse proxy. If the website owner wants to embed the Facebook newsfeed, which the API does not allow, he can simply do so on the will of the user. Just like an extension or a reverse proxy would provide the same experience. Giving the choice to the user is a good enough reason. I know what “reasons” are there against it, but since it is so easy to get around them that malicious actors will always be able to use it, than you should just give it away because it harms legitimate use cases as well.

So once again, prove you understand why origin isolation is implemented the way it is. From that, show why it simply doesn’t work and you should get this kind of access in the future.

To prevent XSS and phishing. XSS can not be prevented if the user gives away facebook login to a regular app. To make phishing harder as it makes copying the visual look of a site harder.

Well unless you shove up some image ML into the browser to block phishing (I doubt it will work), it will still work.

If you understand that and the security model of the web, then you’d probably be just as paranoid as everyone else about opening this kind of access up.

If you understand the 30% ransom based business model of the respective app stores of the two biggest companies in the world (Google, Apple), you’ll understand why we want it. If a user installs a PWA from the browser, at least then it makes sense to allow this.

If you understand that and the security model of the web, then you’d probably be just as paranoid as everyone else about opening this kind of access up.

Being paranoid does not solve the problem. If you are marketing the web as a platform to make universally cross platform apps, this is one of the basic use cases for an app. If a basic reverse proxy breaks the “security” model of the web means that the model is flawed. It means that that security model prevents legitimate use cases.

If an attacker can manipulate requests for another origin within the browser there is loads of extra risk. Including resource substitution attacks which give the including party access to the origin’s contents.

The difference between these and what you are asking is, consent. With extensions a user must opt-in to installing it to get what it offers. Same with a proxy, a user must set it up or do something explicit to allow the proxy to act on their behalf. Where with just having an element providing access to another origin in a browser means… They don’t need to consent to anything.

And on the note of the X-FRAME-OPTIONS header as well from before… That would also end up applying to these elements in browsers. So if say Twitter has that option set, the browsers wouldn’t allow it to be ran inside of these elements. Since, it is a frame and the site has requested they not be run in that kind of context. We can’t say, “Well you blocked iframing for a reason so we’ll just make a new element that you can’t block instead.” That’s not considerate at all.

Personally, I’m finished with this conversation since there is no effort to understand the security model. If it doesn’t fit your idea it is outright flawed by design and not fit for anything. No, the web isn’t perfect in security (nothing is) but, it’s what we have to try and protect users. What you’re advocating for though is browsers to openly allow man-in-the-middle attacks on any given site users visit by any other site. Which, generally those attacks aren’t too easy to pull off without something explicit happening on the users end (some form of consent clear or not.) Web standards attempt to reduce the surface area of attacks, not increase it.

Oh yea, there is one way, that I can think of, to achieve this given the web security model safely. But it has the downside of using more disk space on a users device. Which depending on how much this kind of thing would be used and in what way could end up being non-marginal and that could hurt users. Especially those with resource constrained devices. It could also lead to weirdness based on how developers write their web apps to operate if multiple versions are running at once for a user in various different origins. So, it’s not a clean solution for anyone except app developers or attackers who could use the API. Therefore, highly unlikely to be carried out.