Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let websites framebust out of native apps

holovaty.com

Post reply on HN
Print view View original

21–30 of 158 posts

Re: Let websites framebust out of native apps

#21

Post by teakettle42 »

munk-a wrote: post #16
teakettle42 wrote: post #11

This proposal seems predicated on a fundamental misunderstanding of the security model of non-web applications. A WebView is fully under control of the application presenting it. Even if the built-in APIs were extended to respect X-Frame-Options, applications can simply: - Proxy the network requests on behalf of the webview API, stripping the X-Frame-Options header. - Modify the behavior of the webview (e.g. via priv…

At the same time Apple and Google have lists of hard requirements for applications that can be extended to include these - especially if part of this change over is presenting unified shared objects for apps to use to launch browsers.

That’s true, but I still don’t believe there exists a technical solution to this problem; I think this should be solved via:

(1) App Store policy, including requiring apps to disclose that they can/do capture embedded web browsing activity as part of their privacy disclosures.

(2) Privacy regulation. This is a very intentional dark-pattern used to violate users’ expectation of privacy, and should be addressed.

(3) User education — users should never trust an app-presented web view.

Re: Let websites framebust out of native apps

#22

Post by simscitizen »

teakettle42 wrote: post #11

This proposal seems predicated on a fundamental misunderstanding of the security model of non-web applications. A WebView is fully under control of the application presenting it. Even if the built-in APIs were extended to respect X-Frame-Options, applications can simply: - Proxy the network requests on behalf of the webview API, stripping the X-Frame-Options header. - Modify the behavior of the webview (e.g. via priv…

This is an incorrect understanding of how web views are implemented.

For SFSafariViewController, all the API allows you to do is essentially to present a full screen view that loads a particular URL. You can also register for callbacks for when a user dismisses the view or clicks the action button. There are no APIs that allow you to inject JS or read website data out of the view. The actual browsing logic powering the view is implemented out of process and you cannot modify the network requests that the view makes. If all your app wants to do is to display an in-app browser view, this is definitely the recommended path for security reasons.

For WKWebView, again most of the browsing and networking logic is handled out of process. However, because the API is designed to allow you to do pretty much anything you'd want to do with a web view up to and including implementing an entire browser, you get more power over what the view does. So you can do things like inject JS into the view.

However, it would be possible for the platform vendor to restrict use of the web view such that only certain more powerful APIs can be used by browser-style apps, while other less sensitive APIs can be used by all apps. This is because pretty much all of the APIs involve an IPC from the embedding process (e.g. an app under third party control) to another process that actually powers the view under the control of the browser engine (usually the content/renderer process). The content process can check that the embedding process has the proper permissions for each operation.

There is already precedence for limiting the power of web views. See https://webkit.org/blog/10882/app-bound-domains/ for instance, which allows a responsible app owner to allow their embedded web view to only load requests from particular domains.

Re: Let websites framebust out of native apps

#23

Post by mnutt »

toxicFork wrote: post #5

Can you somehow detect that you're in a webview and instruct users to press the "open in browser" button? Perhaps via the user agent, or some other way?

A few years ago I worked on a web-based augmented reality app intended to be shared by users through services that often displayed links in webviews. Newer SFSafariViewController worked fine but WKWebView failed silently in a way that was impossible to detect. There was no way to determine if you were in a WKWebView except: adding a hidden DOM node somewhere in the format “(123) 456-7890”, real safari would automatically turn it into a detectable phone number link, whereas WKWebView would not. With that ugly hack, we’d have to display a message asking the user to open in safari and hope the app had deigned to put a safari button somewhere.

Re: Let websites framebust out of native apps

#24

Post by DaiPlusPlus »

mnutt wrote: post #23
toxicFork wrote: post #5

Can you somehow detect that you're in a webview and instruct users to press the "open in browser" button? Perhaps via the user agent, or some other way?

A few years ago I worked on a web-based augmented reality app intended to be shared by users through services that often displayed links in webviews. Newer SFSafariViewController worked fine but WKWebView failed silently in a way that was impossible to detect. There was no way to determine if you were in a WKWebView except: adding a hidden DOM node somewhere in the format “(123) 456-7890”, real safari would automatic…

> There was no way to determine if you were in a WKWebView except: adding a hidden DOM node somewhere in the format “(123) 456-7890”, real safari would automatically turn it into a detectable phone number link

What about non-US users? And doesn't Android's browser do the same thing?

Also, what happens if the page has `` or `window.open`? Does it always open in the same frame/window/target?

Re: Let websites framebust out of native apps

#25

Post by teakettle42 »

simscitizen wrote: post #22
teakettle42 wrote: post #11

This proposal seems predicated on a fundamental misunderstanding of the security model of non-web applications. A WebView is fully under control of the application presenting it. Even if the built-in APIs were extended to respect X-Frame-Options, applications can simply: - Proxy the network requests on behalf of the webview API, stripping the X-Frame-Options header. - Modify the behavior of the webview (e.g. via priv…

This is an incorrect understanding of how web views are implemented. For SFSafariViewController, all the API allows you to do is essentially to present a full screen view that loads a particular URL. You can also register for callbacks for when a user dismisses the view or clicks the action button. There are no APIs that allow you to inject JS or read website data out of the view. The actual browsing logic powering t…

> This is an incorrect understanding of how web views are implemented.

No, it’s not. Nothing requires you to use SFSafariViewController.

As you yourself noted, WKWebView exists and grants the application effectively complete control over it.

UIWebView also still exists, and despite being deprecated, remains usable.

Finally, even if everything but SFSafariViewController were removed from the OS, nothing stops the application developer from embedding their own replacement webview implementation.

> However, it would be possible for the platform vendor to restrict use of the web view such that only certain more powerful APIs can be used by browser-style apps, while other less sensitive APIs can be used by all apps.

Such a restriction would be equivalent to the existing SFSafariViewController, but regardless, I must reiterate: absolutely nothing stops the application developer from embedding their own replacement implementation.

> This is because pretty much all of the APIs involve an IPC from the embedding process (e.g. an app under third party control) to another process that actually powers the view under the control of the browser engine (usually the content/renderer process).

Again, nothing stops the application developer from embedding a replacement for your hypothetical sandboxed webview API.

Re: Let websites framebust out of native apps

#26

Post by simonw »

toxicFork wrote: post #5

Can you somehow detect that you're in a webview and instruct users to press the "open in browser" button? Perhaps via the user agent, or some other way?

Yes you can - and Google have been doing exactly that for nearly a year now https://developers.googleblog.com/2021/06/upcoming-security-...

Re: Let websites framebust out of native apps

#27

Post by banana_giraffe »

DaiPlusPlus wrote: post #24
mnutt wrote: post #23

Earlier quoted context omitted.

A few years ago I worked on a web-based augmented reality app intended to be shared by users through services that often displayed links in webviews. Newer SFSafariViewController worked fine but WKWebView failed silently in a way that was impossible to detect. There was no way to determine if you were in a WKWebView except: adding a hidden DOM node somewhere in the format “(123) 456-7890”, real safari would automatic…

> There was no way to determine if you were in a WKWebView except: adding a hidden DOM node somewhere in the format “(123) 456-7890”, real safari would automatically turn it into a detectable phone number link What about non-US users? And doesn't Android's browser do the same thing? Also, what happens if the page has ` ` or `window.open`? Does it always open in the same frame/window/target?

Last time I dug around into this, there was a delegate that's called that allows the app to open a new window/tab as makes sense for the app and display the link. I've seen applications that respond to this delegate by just forcing the existing WebView to open the link. If you don't implement the delegate, as I recall, nothing happens with these sort of links, they just appear dead to the user.

Re: Let websites framebust out of native apps

#28

Post by Spivak »

FridgeSeal wrote: post #18

When I used to work in mobile advertising, advertisers and tech vendors were always so desperate for this, because it would let them track users across apps and not just websites, so I’m not super sold on enabling it by default. > Seem familiar? This is framing, merely in app form. But this time, the framed website has no way to framebust. Click the safari button. It opens it in your normal browser. Better behaved ap…

> Click the safari button. It opens it in your normal browser.

This is a solution to a different problem. The problem is the website can't prevent itself from being loaded in these frames like it can for .

I think there's a good chance Google will actually end up implementing this because they've already had a push to not allow Google login screen in webviews.

Re: Let websites framebust out of native apps

#29

Post by simonw »

teakettle42 wrote: post #21
munk-a wrote: post #16

Earlier quoted context omitted.

At the same time Apple and Google have lists of hard requirements for applications that can be extended to include these - especially if part of this change over is presenting unified shared objects for apps to use to launch browsers.

That’s true, but I still don’t believe there exists a technical solution to this problem; I think this should be solved via: (1) App Store policy, including requiring apps to disclose that they can/do capture embedded web browsing activity as part of their privacy disclosures. (2) Privacy regulation. This is a very intentional dark-pattern used to violate users’ expectation of privacy, and should be addressed. (3) Us…

How about all three of yours, plus:

(4) An HTTP header that websites can use to explicitly opt out of being rendered in embedded in-app browser, reinforced by App Store policy that requires apps to respect and not to work around that header

Re: Let websites framebust out of native apps

#30

Post by Spivak »

teakettle42 wrote: post #25
simscitizen wrote: post #22

Earlier quoted context omitted.

This is an incorrect understanding of how web views are implemented. For SFSafariViewController, all the API allows you to do is essentially to present a full screen view that loads a particular URL. You can also register for callbacks for when a user dismisses the view or clicks the action button. There are no APIs that allow you to inject JS or read website data out of the view. The actual browsing logic powering t…

> This is an incorrect understanding of how web views are implemented. No, it’s not. Nothing requires you to use SFSafariViewController. As you yourself noted, WKWebView exists and grants the application effectively complete control over it. UIWebView also still exists, and despite being deprecated, remains usable. Finally, even if everything but SFSafariViewController were removed from the OS, nothing stops the appl…

> developer from embedding their own replacement webview implementation

Well in the case of Apple they would be kicked off the store so fast it'll make the devs head spin. Human problem, human solution I guess.

Post reply on HN