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

11–20 of 158 posts

Re: Let websites framebust out of native apps

#11

Post by teakettle42 »

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.

Re: Let websites framebust out of native apps

#12

Post by toxicFork »

munk-a wrote: post #8
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?

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

Sure, but until Apple and Google starts caring, what can we do?

Re: Let websites framebust out of native apps

#13

Post by munk-a »

rawling wrote: post #10
simonw wrote: 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.

Yea - in-app browsers are just more code... so Google could modify webkit mobile distros to adhere to this behavior but if Facebook was willing to compile their own library (which, honestly, they probably do already anyways) they would need to voluntarily comply with respecting such headers... right now I think this is do-able, app store controllers have a firm enough grasp on the market they could boot any apps that refuse to play nice - but it will require enforcement efforts.

Another option is to force these browser plugins to be shared objects that the app store has more control over but then you'll wander into the territory of how to enforce it on every fork of firefox and the like.

Editing to add: Oh legacy apps are a huge can of worms here - most businesses don't bother updating out of date app versions so folks with older phones will probably be stuck with perpetually insecure apps. But legacy apps and the "tight" control Google & Apple have are sort of perpetual issues to any sort of security.

Re: Let websites framebust out of native apps

#14

Post by kitsunesoba »

simscitizen wrote: post #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…

Came here to say this. Custom webviews like Facebook likes to use are another matter but SFSafariViewController is for all intents and purposes real Safari with per-app cookies, storage, etc to bust tracking.

And I have to say, I would be pretty irritated if every site demanded to open in my main browser. Many if not most links I tap are quick one and dones I’d prefer to not clutter up my tabs.

Re: Let websites framebust out of native apps

#15

Post by munk-a »

toxicFork wrote: post #12
munk-a wrote: post #8

Earlier quoted context omitted.

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

Sure, but until Apple and Google starts caring, what can we do?

Complain.

Call our congressfolk.

Pretty much all we can ever do when faced with a monopoly (or duopoly in this case).

Re: Let websites framebust out of native apps

#16

Post by munk-a »

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.

Re: Let websites framebust out of native apps

#17

Post by dannyphantom »

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.

Re: Let websites framebust out of native apps

#18

Post by FridgeSeal »

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 apps (shout out to Apollo) will let you set a config that sends off links to safari directly. The only apps I know of that don’t have this button are Facebook messenger and TikTok, to nobodies surprise, 2 reasonably badly behaved apps. I think Instagram still does as well, but that’s not a surprise. You can still escape the app context via the sharing menu though, although that is somewhat more involved.

Re: Let websites framebust out of native apps

#19

Post by borschtplease »

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…

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

Post reply on HN