Let websites framebust out of native apps • Hacker News Board

Re: Let websites framebust out of native apps

#151

Post by [deleted] » Thu, Aug 11, 2022, 4:25 PM UTC

liminvorous wrote: post #115

kitsunesoba wrote: post #14

Earlier quoted context omitted.

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.

On the other hand I am almost always annoyed at apps opening websites in SFSafariViewController, and would prefer to be able to completely disable it and have it always open in the real browser.

[deleted]

Re: Let websites framebust out of native apps

#152

Post by slightlyoff » Thu, Aug 11, 2022, 4:47 PM UTC

postalrat wrote: post #147

sneak wrote: post #124

Earlier quoted context omitted.

The notifications all go through Apple still, which allows them to monitor and censor them. This is not much of an improvement. :(

Whatever the web push standard lacks for encryption or hiding data can be done by your app.

The Web Push Standard supports e2e encryption for messages sent from your app to the device:

https://web.dev/push-notifications-web-push-protocol/#the-pa...

Re: Let websites framebust out of native apps

#153

Post by codethief » Thu, Aug 11, 2022, 6:44 PM UTC

dwaite wrote: post #96

The example (Twitter) does not use a web view - it uses SFSafariViewController. This is the system browser as a modal over an app, a compromise for apps being able to retain navigational control (by having the user return to twitter when they hit 'Done') while not having the privacy, security and usability drawbacks of a webview.

While I agree that SFSafariViewController (or CustomTab on Android) is a security improvement it doesn't completely solve the security issue: The app could still decide to draw something that looks like an SFSafariViewController/CustomTab but is, in reality, a WebView with a key logger injected via JavaScript.

Re: Let websites framebust out of native apps

#154

Post by the_gipsy » Thu, Aug 11, 2022, 6:53 PM UTC

ocdtrekkie wrote: post #144

the_gipsy wrote: post #141

Earlier quoted context omitted.

No, it's a large assumption that users want to open a link in an in-app browser. Why would they? On the other hand, there are clear motives for the app to keep users in the app as much as possible. Because the in-app browser in general is a degraded experience, for example being logged out of habitual websites, the user won't navigate the web as usual, and will soon return to the app. It's nothing but a dark pattern.

Your opinion is in the minority, even among the very technical folks I've seen discussing this issue. It's entirely false to reclassify a feature many users want as a dark pattern. Let me give you an example personally: I want my RSS feed reader to use an in-app browser. Because unless I am going to get significantly more in depth, I just want to see the page content, and then swipe or back out to where I was in my f…

And I say you're the minority here, with that RSS example.

Re: Let websites framebust out of native apps

#155

Post by codethief » Thu, Aug 11, 2022, 6:54 PM UTC

As others have already mentioned, one needs to distinguish between WebViews and "in-app native browsers" / browser overlays (SFSafariViewController on iOS, CustomTab on Android). While WebViews are bad for all the reasons mentioned in the article, overlays do serve a purpose:

- The app gets notified when the website gets closed.

- The app is hidden underneath the overlay while the website is open. That is, the overlay is tied to the app and the user can't get lost or switch back to the app before they haven't closed the website.

All these are important, e.g., for OAuth, 2FA and payment-related applications.

Overlays are also way less bad than WebViews in terms of:

- UX: The overlay uses the cookies and settings of the native browser, looks familiar, and uses an up-to-date browser engine.

- Security for the host app: The website runs in a separate process

- Security for the user: They can see the URL and be (relatively) certain that the host app doesn't have access to the website and their interaction with it (i.e. no key logging).

So while I'd support busting out of WebViews (especially when they're opening paypal.com), I'm not so sure about overlays.

Re: Let websites framebust out of native apps

#156

Post by remram » Thu, Aug 11, 2022, 8:55 PM UTC

vgel wrote: post #74

infotogivenm wrote: post #59

> clickjacking. That’s when, for example, a website frames your site, then hijacks user input such that users are fooled into thinking they’re interacting with your site while they’re actually providing data to the (evil) containing site. Imagine typing your bank credentials into (what you think is) your bank website, whereas it’s in fact an evil site logging everything you’ve typed Nitpick but isn’t this backwards?…

It can happen either way I think. The reverse is framing Amazon but overlaying an evil credit card input invisibly on top of Amazon's.

That is just straight-up phishing, showing a fake Amazon form on your website that is served from a different domain. I'm not sure what you would overlay there.

Obviously you can't overlay anything for people who visit amazon.com, because they are not talking to your server at all.

Re: Let websites framebust out of native apps

#157

Post by krausefx » Sun, Aug 14, 2022, 3:29 PM UTC

btown wrote: post #142

samwillis wrote: post #102

In app browsers are a real problem for online stores and e-commerce, the issue being they (mostly) don’t maintain session cookies when a user clicks the “open in Safari/browser” button. This is disastrous for shopping carts. Say your are an advertiser with an ad click or have a visitor come organically from social. They like your products and place them in their cart and go to checkout, at checkout they want to use A…

How did you detect that an IAB was being used? Do they typically have unique user-agents or something?

Author of the krausefx.com post here: I don't believe there is a universal way of detecting this, however in the case of Instagram, the user agent string actually includes the "Instagram" string. For practical cases it's probably enough to collect user agents of the most used apps and check for those.

However, I believe all of this won't matter for too long after the press the last few days.

Re: Let websites framebust out of native apps

#158

Post by dwaite » Fri, Aug 19, 2022, 3:34 AM UTC

codethief wrote: post #153

dwaite wrote: post #96

The example (Twitter) does not use a web view - it uses SFSafariViewController. This is the system browser as a modal over an app, a compromise for apps being able to retain navigational control (by having the user return to twitter when they hit 'Done') while not having the privacy, security and usability drawbacks of a webview.

While I agree that SFSafariViewController (or CustomTab on Android) is a security improvement it doesn't completely solve the security issue: The app could still decide to draw something that looks like an SFSafariViewController/CustomTab but is, in reality, a WebView with a key logger injected via JavaScript.

Right, this sort of malicious app issue imitating system UI to capture passwords is only really solvable this point by non technical means - App Store rejections, criminal penalties, etc.

Capturing a password is not going to be solved by a frame-busting header because the malicious app can just present its own content instead of rendering the requested enterprise/bank/etc login page.

Well, and new authentication tech like Passkeys/WebAuthn - the platform won't let a web view authenticate for domains other than ones associated with the native app.