Live data from Hacker News

Let websites framebust out of native apps

holovaty.com

1–10 of 158 posts

Re: Let websites framebust out of native apps

#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 embedding, but having different syntax (X-Frame-App-Options: DENY for example) would solve this need very effectively.

It's interesting to note that Google have already taken steps in this direction: Google sign-in now detects if it is running in an in-app embedded browser and shows you an error telling you to use the native browser instead: https://developers.googleblog.com/2021/06/upcoming-security-...

Re: Let websites framebust out of native apps

#4
A summary if you're short on time:

Mobile app webviews (like those used by e.g. instagram, twitter) are in many ways a modern re-incarnation of the old exploitative frame embedding problem; but in this case, apps use webviews to track user behavior + keep them in their app.

To deal with the frame issue X-Frame-Options: DENY was developed so websites could opt out, but there is currently no recourse for users or website owners in the webview case.

The problem could be solved on the mobile OS level by having it interpret the presence of X-Frame-Options: DENY as disallowing webviews for particular sites, and instead open the OS default browser.

Conclusion:

> Our best bet is regulatory intervention, along the lines of what Open Web Advocacy is doing. In collecting my thoughts here, I hope to start this conversation. The modern version of TotalNews must be reined in.

Edit: forgot there was a frame separate from iframe

Re: Let websites framebust out of native apps

#6
post #4

A summary if you're short on time: Mobile app webviews (like those used by e.g. instagram, twitter) are in many ways a modern re-incarnation of the old exploitative frame embedding problem; but in this case, apps use webviews to track user behavior + keep them in their app. To deal with the frame issue X-Frame-Options: DENY was developed so websites could opt out, but there is currently no recourse for users or websi…

This was before iframes iirc; just frames. Edit: at least the frame busting js was pre- iframes

Re: Let websites framebust out of native apps

#7
> Proponents of native apps would also likely say: “If you had your own native app, this problem would be solved, because you can register a link handler that will automatically open all soundslice.com URLs in your native app.”

I believe the embedded-style webviews bypass this link-handling anyway.

E - discussion of an article linked to from this one: https://news.ycombinator.com/item?id=32415470

Re: Let websites framebust out of native apps

#8

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?

That would erode usability and increase friction though - it'd be really nice if, like the article suggested, it just happened automatically.

Re: Let websites framebust out of native apps

#9
It looks like Twitter is using SFSafariViewController for their in-app browser. This is the system-recommended way of creating an in-app browser. It prevents the embedding app (Twitter in this case) from reading website data and injecting JavaScript into the view. You can also break out of the session into Safari pretty trivially by hitting the Safari button in the lower right corner.

Apps that implement a custom web browser using WKWebView (e.g. IG) are much worse and can do those nefarious things.

Re: Let websites framebust out of native apps

#10
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…

If a native app has as much control over the webpage as it seems to, I'd be surprised if it's not able to strip the header. Or point through a proxy that strips it, and ignore the ensuing HTTPS errors, or some other workaround.
Post reply on HN