Live data from Hacker News

Let websites framebust out of native apps

holovaty.com

31–40 of 158 posts

Re: Let websites framebust out of native apps

#31

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…

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

Re: Let websites framebust out of native apps

#32
I like the general idea a lot: let sites say whether they're willing to be displayed this way. But two main disagreements:

* We can't reuse X-Frame-Options for this, because sites are already setting that without necessarily wanting to opt out of in-app browsers.

* I do think Apple and Google might be persuaded to require all IABs to respect this "I want my site to open in the user's default browser" directive, as an app store approval requirement. For example, their account security teams would likely be strongly in favor.

I do think Android's Custom Tabs and iOS' SFSafariViewController should still be allowed, however, since the embedding app can't exfiltrate site data, inject JS, etc.

Re: Let websites framebust out of native apps

#33
I feel like I am in the extreme minority in that I pretty much never use an app for anything that already has a website. I just use the website on my phone.

The experience might be slightly worse, but I much prefer just staying in the browser on my phone for everything. Reddit, Twitter, the few times I log into Facebook, are all just using a browser. I just find it simpler, and I like when the interface is the same on my phone and desktop (which is why I use old Reddit)

Re: Let websites framebust out of native apps

#34
post #2

I really like the simplicity of this proposal, and how Adrian compares it to X-Frame-Options: DENY which has been in place for a decade now and has solved the problem of clickjacking and unauthorized framing for regular websites. My hunch is that having X-Frame-Options: DENY start applying to native mobile apps wouldn't be feasible because it would break too much existing stuff that didn't intend to opt-out of native…

IIRC the [responsible org] says we don't have to add the `X-` to custom headers anymore.

Edit: IETF and IANA are the orgs

RFC 4229 https://www.rfc-editor.org/rfc/rfc4229.html

Re: Let websites framebust out of native apps

#35
post #32

I like the general idea a lot: let sites say whether they're willing to be displayed this way. But two main disagreements: * We can't reuse X-Frame-Options for this, because sites are already setting that without necessarily wanting to opt out of in-app browsers. * I do think Apple and Google might be persuaded to require all IABs to respect this "I want my site to open in the user's default browser" directive, as an…

I think non-platform browsers also use the same engine and webview, so if the platform implements "honor X-Frame-Options", won't it essentially lock out third party browsers? Like I won't be able to use Firefox Focus.

Maybe the app review process can catch this behaviour instead? ... That way, it can be permitted for browsers but not for apps with embed a webview? That might work for iOS where reviews are strict, but no idea whether it would on Android.

Re: Let websites framebust out of native apps

#36

As someone pointed out already, Twitter does a good job with this. Reddit does a fine enough job, too. However, tiktok doesn't allow users to break out of their in-app browser. This is especially frustrating when you wish to follow an artist on Spotify WITHOUT signing into Spotify in the tiktok app.

The tiktok thing is so annoying. It's not even possible to get the URL of the page you're viewing so you can open it in another app, and you can't long press any links to copy them either (neither in the in-app browser or in a user's bio). It makes it so frustrating when someone has social media links in their bio, because there's literally no way to open them in a different app short of manually typing out the URL. I understand why they do it (data collection/tracking), but it's a horrible user experience.

Re: Let websites framebust out of native apps

#38
post #35
post #32

I like the general idea a lot: let sites say whether they're willing to be displayed this way. But two main disagreements: * We can't reuse X-Frame-Options for this, because sites are already setting that without necessarily wanting to opt out of in-app browsers. * I do think Apple and Google might be persuaded to require all IABs to respect this "I want my site to open in the user's default browser" directive, as an…

I think non-platform browsers also use the same engine and webview, so if the platform implements "honor X-Frame-Options", won't it essentially lock out third party browsers? Like I won't be able to use Firefox Focus. Maybe the app review process can catch this behaviour instead? ... That way, it can be permitted for browsers but not for apps with embed a webview? That might work for iOS where reviews are strict, but…

Yes, I think actual browsers should be allowed to do nothing when seeing it. Strongly against anything that would make it harder to use Firefox.

My understanding is that both app stores already have a concept of "this is a web browser" vs "this is an app that includes an in-app browser" and so this is pretty practical?

Re: Let websites framebust out of native apps

#40
post #34
post #2

I really like the simplicity of this proposal, and how Adrian compares it to X-Frame-Options: DENY which has been in place for a decade now and has solved the problem of clickjacking and unauthorized framing for regular websites. My hunch is that having X-Frame-Options: DENY start applying to native mobile apps wouldn't be feasible because it would break too much existing stuff that didn't intend to opt-out of native…

IIRC the [responsible org] says we don't have to add the `X-` to custom headers anymore. Edit: IETF and IANA are the orgs RFC 4229 https://www.rfc-editor.org/rfc/rfc4229.html

This is not a custom header (i.e. one with no UA semantics), it is a standardized header called X-Frame-Options which requires the “X-“ for browsers to recognize it. The prefix is an artifact of the era the header was introduced in.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-...

Post reply on HN