4 ms·

This proposal seems predicated on a fundamental misunderstanding of the security model of non-web applications. A WebView is fully under control of the applica

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 private API or twiddling internal state) to not respect X-Frame-Options. - Embed their own web view implementation that ignores X-Frame-Options. Apple and Google cannot guarantee that their code will ever see the X-Frame-Options header, nor can they guarantee that an embedded webview will even be implemented using their platform code.

munk-a 4y ago
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.
- teakettle42 4y ago
  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.
  - simonw 4y ago
    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
    - teakettle42 4y ago
      The header misleads developers and users into believing it provides security guarantees that it cannot.
borschtplease 4y ago
All of this can be reason to reject an app during submission review. Google and Apple could update their guidelines and start enforcing them. I mean if I would Apple I would go even stricter. In Info.plist you declare list of domains which can be accessed with webview and reason why. Just like you declare reason why you should have access to photos or a camera. Everything other would straight open in browser. Also there is a solution to make component which acts as a webview, but in fact is blackboxed main browser which app has no access to, just like PHPicker photos select in ios 15
simscitizen 4y ago
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/ 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.
- teakettle42 4y ago
  > 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.
cortesoft 4y ago
> Apple and Google cannot guarantee that their code will ever see the X-Frame-Options header, nor can they guarantee that an embedded webview will even be implemented using their platform code. Apple absolutely can. They already out severe restrictions on what apps are allowed to use for rendering web views. They also approve every app. They can enforce whatever rule they want.
- teakettle42 4y ago
  The App Store review process is not sufficient to provide such a strong technical guarantee. The solution is not to add what amounts to an advisory flag to your page headers, and in the process, mislead users into believing in-app webviews are safe.

munk-a 4y ago

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.

teakettle42 4y ago
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.
- simonw 4y ago
  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
  - teakettle42 4y ago
    The header misleads developers and users into believing it provides security guarantees that it cannot.

borschtplease 4y ago

All of this can be reason to reject an app during submission review. Google and Apple could update their guidelines and start enforcing them. I mean if I would Apple I would go even stricter. In Info.plist you declare list of domains which can be accessed with webview and reason why. Just like you declare reason why you should have access to photos or a camera. Everything other would straight open in browser. Also there is a solution to make component which acts as a webview, but in fact is blackboxed main browser which app has no access to, just like PHPicker photos select in ios 15

simscitizen 4y ago

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/ 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.

teakettle42 4y ago
> 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.

cortesoft 4y ago

> Apple and Google cannot guarantee that their code will ever see the X-Frame-Options header, nor can they guarantee that an embedded webview will even be implemented using their platform code. Apple absolutely can. They already out severe restrictions on what apps are allowed to use for rendering web views. They also approve every app. They can enforce whatever rule they want.

teakettle42 4y ago
The App Store review process is not sufficient to provide such a strong technical guarantee. The solution is not to add what amounts to an advisory flag to your page headers, and in the process, mislead users into believing in-app webviews are safe.