11 ms·

Let websites framebust out of native apps

430 points by samwillis 4y ago

simonw 4y ago
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-changes-to-googles-oauth-2.0-authorization-endpoint.html https://developers.googleblog.com/2021/06/upcoming-security-...
- rawling 4y ago
  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.
  - munk-a 4y ago
    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.
    - eek2121 4y ago
      Apple actually has really tight quality control over the applications found on the app store. If your app is found to have a vulnerability, it goes away immediately. That is why you don't have apps with malware or apps rooting the device or apps replacing the launcher via an exploit.
      - cat_plus_plus 4y ago
        Or apps that compete with Apple
  - mr_toad 4y ago
    Or just straight-up fake the sign in page. There’s no way to tell.
- djbusby 4y ago
  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 https://www.rfc-editor.org/rfc/rfc4229.html
  - semiquaver 4y ago
    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-Frame-Options https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-...
    - thayne 4y ago
      It's also been deprecated in favor of the content-security-policy header.
  - quelltext 4y ago
    Was curious what they say about it but the link didn't seem to have anything on custom headers.
draw_down 4y ago
westoncb 4y ago
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
- tingletech 4y ago
  This was before iframes iirc; just frames. Edit: at least the frame busting js was pre- iframes
toxicFork 4y ago
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?
- munk-a 4y ago
  That would erode usability and increase friction though - it'd be really nice if, like the article suggested, it just happened automatically.
  - toxicFork 4y ago
    Sure, but until Apple and Google starts caring, what can we do?
    - munk-a 4y ago
      Complain. Call our congressfolk. Pretty much all we can ever do when faced with a monopoly (or duopoly in this case).
- kyle-rb 4y ago
  You can detect if Facebook injects a tracking script into your app :)
- mnutt 4y ago
  A few years ago I worked on a web-based augmented reality app intended to be shared by users through services that often displayed links in webviews. Newer SFSafariViewController worked fine but WKWebView failed silently in a way that was impossible to detect. There was no way to determine if you were in a WKWebView except: adding a hidden DOM node somewhere in the format “(123) 456-7890”, real safari would automatically turn it into a detectable phone number link, whereas WKWebView would not. With that ugly hack, we’d have to display a message asking the user to open in safari and hope the app had deigned to put a safari button somewhere.
  - DaiPlusPlus 4y ago
rawling 4y ago
> 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 https://news.ycombinator.com/item?id=32415470
simscitizen 4y ago
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.
- kitsunesoba 4y ago
  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.
  - seandoe 4y ago
    I disagree. If it's a link to the web, I want my main, default browser everytime. No exceptions. The context switching is never an issue for me. App browsers screw up magic links too. I wish they'd go away.
    - hmcamp 4y ago
      I agree. I’d prefer the exploit choice to have the link open in my default browser.
  - danboarder 4y ago
    Perhaps it can be an option to check: "Always open websites in your default browser".
    - monkpit 4y ago
      Funny thing - the Gmail app has this prompt on the iPhone buy it never remembers my preference. It asks me every time even when I tell it not to.
teakettle42 4y ago
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
      - 4y ago
dannyphantom 4y ago
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.
- Mogzol 4y ago
  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.
- pantojax45 4y ago
  Ironically people handle this with: link to instagram (because you can break out of browser): link to insta => link tree in insta => get to link you like => user can click safari button…
  - hackmiester 4y ago
    Yeah, and that frustrates the hell out of me, too, because I don't have Instagram and it varies (based on Zuck's mood, I guess) whether they will even allow me to view someone's profile without an account.
FridgeSeal 4y ago
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.
- Spivak 4y ago
  > Click the safari button. It opens it in your normal browser. This is a solution to a different problem. The problem is the website can't prevent itself from being loaded in these frames like it can for <iframe>. I think there's a good chance Google will actually end up implementing this because they've already had a push to not allow Google login screen in webviews.
- charcircuit 4y ago
  If people want a feature so bad doesn't it make sense to add it?
  - aendruk 4y ago
    Depends who wants it.
jefftk 4y ago
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.
- sriku 4y ago
  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.
  - jefftk 4y ago
    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?
cortesoft 4y ago
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)
- not2b 4y ago
  Some sites attempt to prevent you from using the browser on a phone (notably reddit, though as you say old Reddit is a workaround).
  - djitz 4y ago
    It pains me greatly that somehow Reddit engulfed just about every forum on earth, because I despise the way they force you onto the app. Their manipulation of search engines’ “last updated” parameters are also egregious.
    - polotics 4y ago
      Reddit I started to look at on my phone, but then it tried to bully me into installing an app. I like bullies much less than I like forums, so I do not look at Reddit on my phone anymore. Matter fixed!
- CoastalCoder 4y ago
  I don't know how big that minority is, but I'm part of it. I have an Android phone, and any time a company tries pushing me to use their native app, I start counting my silverware.
- kody 4y ago
  I'm right there with you. I wonder why I even have a smartphone since I'm so app-averse, other than requiring the computing power to run any modern bloated website. I've had arguments with PMs instisting that, for example, a shopper in a supermarket is not going to download an app but they will visit a website that can offer equivalent functionality.
sally1620 4y ago
Apple could solve this problem in Webkit. But Android is more complicated. On Android, third-party browser engines are allowed. Google cannot prevent an app from shipping its own browser engine for in-app browsing experience.
- not2b 4y ago
  The app would have to get much larger if they have to bundle most of a browser with it to avoid using the browser components on the phone. But sure, they could do that. But to be in the app store an app has to comply with the rules. Google could decide to require compliance with that header. It's no loss to them, because the consequence would be that almost all Android users would use Chrome, and the tracking in the browser would still be controlled by Google.
- sneak 4y ago
  Apple is incentivized not to solve this because presently app creators can hijack these links to open in their own native code app, provided: 1. they have paid to join the apple developer program 2. they have validated ownership of their URL's domain with apple 3. they have submitted to all of the censorship requirements of the apple App Store (failure to do this one is what destroyed Tumblr and the Hong Kong anti-police protester app, you may recall) 4. they pay apple a cut of their sales 5. they buy mac workstations for all of their iOS mobile developers, to run xcode Apple actually has a vested interest in apps supplanting the web, and has little incentive to improve web security features because Apple would prefer that new businesses simply use native iOS apps for everything (which sells more iPhones and locks both development investment as well as user eyeballs to their hardware).
  - etchalon 4y ago
    Apple's interest is in selling people iPhones. One of the iPhone's marquee features is privacy. Apple has shown that it is willing to piss off native app developers in favor of user privacy.
  - rawling 4y ago
    The other-people's-apps-opening-your-site-in-their-custom-webview-and-adulterating-it problem doesn't go away if you onboard with Apple, build an app & register your domain for Universal Links. The custom webview is quite capable of blocking ULs.
dang 4y ago
Related ongoing thread: Instagram can track anything you do on any website in their in-app browser - https://news.ycombinator.com/item?id=32415470 https://news.ycombinator.com/item?id=32415470 - Aug 2022 (371 comments)
cat_plus_plus 4y ago
Really, the proposal is to prevent people from implementing alternative web browsers? How about this: - Want to control the experience? Implement your own app - Want to be easily accessible to users without them having to install your app? Then accept them using any browser, including one embedded into Twitter - Want to only support specific web browser? You can try to detect them using various tricks or convince them to support DRM. But, accept that many users will be driven away.
- account42 4y ago
  Exactly, if there are apps that are collecting data they they should not or being otherwise malicious then we should go after those apps - preferably via the law but the app store gatekeepers can also act. This is not something we need to throw out the entire concept of alternate user agents over.
6510 4y ago
Didn't the new EU regulation intend to forbid forcing users to use a specific browser? Embedding your preferred browser into some other app doesn't seem like an acceptable work around?
neilv 4y ago
The article starts with historical anecdote from 1996, and talks about later frame-busting JS. At the time, you could also bust out of frames before JS was widely supported, simply by setting your HTML `A` element `target` attributes to `_top`. If you were already generating your HTML back then, including having a function to generate a link, this was possibly a one-line change. If you did this HTML-only frame-busting, you'd still appear within whatever questionable frames setup some other side had going, but as soon as someone tried to follow a link-- bam, now the site you host has either taken over the window, or are in an all-new window. Frames initially seemed like a godsend, for arguably useful purposes, like keeping a floating table-of-contents sidebar on a large document (before CSS). My once employer, Electronic Book Technologies (EBT), makers DynaText that TBL considered, jumped on frames for this purpose, and were able to convert DynaWeb to leverage frames "overnight" from the same SGML source. But frames did have some downsides even within a site, even if you didn't mess up the HTML (e.g., bookmarking of individual pages wasn't as usable/possible, and you could also somehow land on a page intended to be in a frameset but outside the frameset navigation UI context). Besides the TotalNews example the article mentions, there were a lot of sites putting other sites inside frames, maybe as often due to misunderstanding or not realizing, rather than aggressively trying to freeload. (At the same time as TotalNews, I'd built a fuzzy Web scraper in Java, and a prototype "personalized newspaper" that used it to get news articles and weather from other sides. I didn't know what to do about ads, which were brand new and image banners, so I just captured them while I was scraping, and re-presented them in the UI, at the bottom of the page whenever presenting data from the pages they were on. Such were the clumsy days of young Web innocence. :)
- throwaway14356 4y ago
  i've made a frameset site recently. With modern stuff you can have a single document display different content (or a frameset) depending on the name of the frame and push state a more representative url. This also solves the history navigation. loading videos and pdf files into frames is also nice.
destroy-2A 4y ago
Yes 10000x I hear insta engineers happily proclaim Instagram is one of the most popular web browsers :/
cvccvroomvroom 4y ago
Don't use web inside of an app, desktop or mobile for anything other than pure content. Use native for UI. Electron is doing it wrong and {NS,UI}WebView are abused too often to provide an entire app using a website.
infotogivenm 4y ago
> 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? e.g. a clickjacking attack tricks you into thinking you are interacting with a harmless site, when in actuality you are clicking “buy now” on amazon in an invisible logged-in iframe.
- mtlynch 4y ago
  You're right. They have it backwards. It's the legitimate site that needs to protect itself from being invisibly framed within a malicious site.
- vgel 4y ago
  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.
  - remram 4y ago
    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.
codereviewed 4y ago
Why doesn't anyone ask what the user wants? Are we only about what the app owner or the website owner want?
- svnpenn 4y ago
  https://wikipedia.org/wiki/Poe%27s_law https://wikipedia.org/wiki/Poe%27s_law
- exodust 4y ago
  Correct. In addition to the proposed solution, there should be a global setting on the phone that lets users decide that all web links in apps should open in browser; ask every time; or open in app every time. In addition, a per app setting that overrides the global setting should be available too.
postalrat 4y ago
Stop installing apps and demand PWAs.
- sneak 4y ago
  On iOS this means you can't get notifications. Notifications are really important. Apple won't do web notifications because it means then people wouldn't have to pay their 10x-over-the-industry-standard premium (30% instead of 3%) for bundled credit card processing if they buy stuff on the web and not via the App Store.
  - mitjam 4y ago
    This seems to have changed. Web push is coming to mobile Safari next year. https://webkit.org/blog/12945/meet-web-push/ https://webkit.org/blog/12945/meet-web-push/ (Edit: better link - „Keep an eye out for Web Push on iOS and iPadOS in 2023.“)
    - sneak 4y ago
      The notifications all go through Apple still, which allows them to monitor and censor them. This is not much of an improvement. :(
      - postalrat 4y ago
        Whatever the web push standard lacks for encryption or hiding data can be done by your app.
        slightlyoff 4y ago
        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-payload-encryption https://web.dev/push-notifications-web-push-protocol/#the-pa...
- deleted 4y ago
  [deleted]
kmstout 4y ago
TotalNews was great for a young news junky who hadn't yet discovered RSS.
thayne 4y ago
There are a couple of problems with this proposal. First of all, it would prevent you from using webviews to implement any kind of browser. Which in the case of iOS means it would impossible to make an alternative browser to safari, because you aren't allowed to use an alternative browser engine. Secondly, a lot of native apps rely on using websites controlled by the same entity that have x-frame-options set, and those would break if that suddenly caused it not to open.
sneak 4y ago
> This means: If you’re logged into a website in your phone’s browser, but you click a link to that site from a native app’s webview, your logged-in state will not be honored. You’ll need to log in all over again. > At best, this is irritating. At worst, it gives people the false impression that the website is broken or logged them out. No, at worst, it uses the original/authentic website as phishing bait, and convinces the user to type a login and password for site A (the framed site) into application B (which shouldn't have access to it).
gauddasa 4y ago
I prefer not to use app if the same service is available through website. And those services that are not available through websites, they rarely involve any hyperlink to a third party. This may change in future if many essential services ditch their websites and switch exclusively to app. That's one of my nightmares.
tristanb 4y ago
It’s always a terrible experience too. I’m never logged in, my password management app doesn’t work, and if I do want to login it’s a new browser so it trips all the security.
deleted 4y ago
[deleted]
a-dub 4y ago
protip for gmail on android users: gmail -> settings -> general settings -> open web links in gmail -> uncheck
Raziarazzi 4y ago
Some apps lack this setting, whereas many do. Funny thing is that the Gmail programme on the iPhone offers this prompt, but it never saves my preference. I'd be amazed if a native app couldn't strip the header if it had as much control over the webpage as it appears to have. Alternately, you might use a proxy that removes it and ignore the resulting HTTPS problems.
chrismorgan 4y ago
I think the proposal of piggybacking on X-Frame-Options as expressed is just a smidgeon too coarse, and it needs a little more nuance. My suggestion would be that web views that aren’t deliberately being an actual browser be classified as possessing some origin, preferably checked where possible by the OS to match an origin or custom scheme that’s associated with the app (thus generally tying into Android’s app links and iOS’s universal links). Of course, this is still technically fallible since browsers need to be able to disable it, so it’d become another thing for the app store reviewers to check. Then, you apply your Content-Security-Policy’s frame-ancestors directive (the successor to X-Frame-Options, allowing more nuance than simple DENY/SAMEORIGIN: e.g. `Content-Security-Policy: frame-ancestors 'self' instagram:` would be same-origin or the Instagram app), and treat deny as “open in an external browser”, as proposed.
polotics 4y ago
This! I most notably always fight google news: preventing it from dropping out of real-chrome into worst-chrome by opening in new tab has become finger memory...
obviouslynotme 4y ago
You will never prevent people from downloading your html and rendering it, correctly or incorrectly. Attackers will just pull in an open source browser engine that supports mobile. Our smartphones were not made with security in mind. They are literal spyware. I suspect the more likely use of OS-based frame busting is to circumvent ad blocking browsers. This is even the use case he mentions as an example.
- potamic 4y ago
  The next step could be the OS taking control of HTTP and allowing only the native browser to receive a HTML content type.
dwaite 4y ago
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.
- codethief 4y ago
  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.
  - dwaite 4y ago
    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.
Abimelex 4y ago
I also have always the problem, that "in app browsers" don't recognize the native Apps I have installed and so links to youtube or Instagram e.g. do not open the native app but the browser version instead. Copy pasting links is my everyday browsing experience on twitter and linkedIn e.g.
samwillis 4y ago
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 Apple Pay or their saved card details. These aren’t available in most IABs, so they click the “open in browser” button, but now they have lost their cookie and have an empty cart! This causes a massive drop out rate at checkout. I run a store that sells personalised items, it takes time for a customer to prepare their item before going to checkout. We experienced something like a 30% drop out rate from Facebook ads due to this. The “work around” was to detect users in an IAB and display a message on first navigation attempt to prompt them to click the “open in browser” button early. The fact that Facebook let this happen shows that have very little interest I’m making the advertising experience better for advertisers. They just want to keep users in Facebook.
- throwaway14356 4y ago
  it sounds like a scam. If it hurts sales you've paid for it would be hard to argue differently. Showing the advertised page in an iframe is a very old scam. You can buy those "clicks" for around 5 dollar per 5000
- btown 4y ago
  How did you detect that an IAB was being used? Do they typically have unique user-agents or something?
  - krausefx 4y ago
    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.
SergeAx 4y ago
I see almost no reason to use mobile apps for Facebook, Instagram or Twitter today. Just use mobile web browser instead. The only thing is a dark mode for Facebook, but I believe it is achievable via DarkReader plugin for Firefox. Also, ad blockers are more or less working in browser, although Facebook is actively counteracts.
- ramblerman 4y ago
  A lot of them detect it and try to force you. It's malicious as hell, but somehow allowed. For example reddit won't open a link it deems +18 through the web browser, and redirects you to use the app.
  - SergeAx 4y ago
    I saw that on Reddit couple of times. I just close the tab in that case: there's nothing 18+ on Reddit that worth installing their app.
    - Dracophoenix 4y ago
      A solution to this is use HyperApp or Userscript to automatically redirect to old.reddit.com. It works like a charm.
      - SergeAx 4y ago
        Not for mobile Firefox, unfortunately.
        Dracophoenix 4y ago
        Well, that's on Apple.
  - SergeAx 4y ago
    I wonder, by the way, why Reddit's "install app or continue with browser" popup isn't blocked by uBlock Origin. It is clearly an ad, and very malicious indeed.
KronisLV 4y ago
> Popular apps such as Instagram and Facebook don’t just use vanilla webviews. They use customized ones, with their own quirks. This might be understandable, but also feels a bit odd. Why couldn't they just use what the system already providers, without bloating everything with their own implementation? Then again, one could probably ask the same about desktop software that is commonly based on Electron, but in theory might as well be run through Firefox with some additional capabilities that locally running Electron apps would otherwise get. Then again, we kind of had PWAs on the desktop, which have been retired now as well: https://9to5google.com/2021/01/27/firefox-discontinues-work-pwa-desktop/ https://9to5google.com/2021/01/27/firefox-discontinues-work-...
mschuster91 4y ago
> There was indeed a time when this argument made sense: the years before 2015, which is when iOS 9 introduced a global Back button conveniently solving the problem. And of course Android has its global Back button. These days this argument holds no water. Oh of course it does hold water. On Samsung's pretty recent Active Tab 3, opening a link in an app (e.g. RIF) in Chrome takes ages (I recently timed it, 80 seconds) because Chrome for whatever goddamn reason thinks it has to reload all the icons for the 100+ tabs I have open every time Android's completely bonkers memory manager decides it wants to suspend Chrome in background.
tnjm 4y ago
Related to the quirks of in-app browsers mentioned in the article, the Facebook, Instagram and Snapchat apps manage to break file uploading every few months, and take several weeks to fix it each time. I'm not sure why this in particular is such an achilles heel, but it's a surprisingly big problem for e.g. online stores advertizing on Instagram and offering personalized products.
ccouzens 4y ago
There have been a couple of these posts recently and they all contain the same flaw. They talk about their experience on an iPhone and assume it's true on all ecosystems. It's not true for mine (Firefox and Android). When following a link from Gmail it opens embedded within the Gmail app and the site has access to the same cookies as if I'd opened it in the browser. And it's trivial and seamless to then open into full Firefox (position in page and form values are kept). I think Chrome Android is more or less the same too.
- rawling 4y ago
  Gmail may do that, but Android still offers developers "a webview that is basically a detached Chrome tab" and "a webview that you control and add your own chrome around". Instagram offers me a UI that looks quite different to Gmail, so I suspect it's still using the latter.
bastawhiz 4y ago
iOS aside, I'm not sure there's anything to be done here. Apps could simply embed their own browser engine that lets them use webviews in whatever unfettered way they want. And on iOS, it's not unlikely that Apple will be required to open their walled garden to other browser engines in the future.
- jaywalk 4y ago
  > Apps could simply embed their own browser engine that lets them use webviews in whatever unfettered way they want. The biggest pro for consumers in having an app store is that the store can set regulations on apps. If Google says apps can't do this, then it's effectively dead. Of course, that would rely on Google effectively policing it.
codethief 4y ago
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.

430 points by samwillis 4y ago

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-changes-to-googles-oauth-2.0-authorization-endpoint.html https://developers.googleblog.com/2021/06/upcoming-security-...

rawling 4y ago
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.
- munk-a 4y ago
  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.
  - eek2121 4y ago
    Apple actually has really tight quality control over the applications found on the app store. If your app is found to have a vulnerability, it goes away immediately. That is why you don't have apps with malware or apps rooting the device or apps replacing the launcher via an exploit.
    - cat_plus_plus 4y ago
      Or apps that compete with Apple
- mr_toad 4y ago
  Or just straight-up fake the sign in page. There’s no way to tell.
djbusby 4y ago
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 https://www.rfc-editor.org/rfc/rfc4229.html
- semiquaver 4y ago
  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-Frame-Options https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-...
  - thayne 4y ago
    It's also been deprecated in favor of the content-security-policy header.
- quelltext 4y ago
  Was curious what they say about it but the link didn't seem to have anything on custom headers.

draw_down 4y ago

westoncb 4y ago

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

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

toxicFork 4y ago

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?

munk-a 4y ago
That would erode usability and increase friction though - it'd be really nice if, like the article suggested, it just happened automatically.
- toxicFork 4y ago
  Sure, but until Apple and Google starts caring, what can we do?
  - munk-a 4y ago
    Complain. Call our congressfolk. Pretty much all we can ever do when faced with a monopoly (or duopoly in this case).
kyle-rb 4y ago
You can detect if Facebook injects a tracking script into your app :)
mnutt 4y ago
A few years ago I worked on a web-based augmented reality app intended to be shared by users through services that often displayed links in webviews. Newer SFSafariViewController worked fine but WKWebView failed silently in a way that was impossible to detect. There was no way to determine if you were in a WKWebView except: adding a hidden DOM node somewhere in the format “(123) 456-7890”, real safari would automatically turn it into a detectable phone number link, whereas WKWebView would not. With that ugly hack, we’d have to display a message asking the user to open in safari and hope the app had deigned to put a safari button somewhere.
- DaiPlusPlus 4y ago

rawling 4y ago

> 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 https://news.ycombinator.com/item?id=32415470

simscitizen 4y ago

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.

kitsunesoba 4y ago
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.
- seandoe 4y ago
  I disagree. If it's a link to the web, I want my main, default browser everytime. No exceptions. The context switching is never an issue for me. App browsers screw up magic links too. I wish they'd go away.
  - hmcamp 4y ago
    I agree. I’d prefer the exploit choice to have the link open in my default browser.
- danboarder 4y ago
  Perhaps it can be an option to check: "Always open websites in your default browser".
  - monkpit 4y ago
    Funny thing - the Gmail app has this prompt on the iPhone buy it never remembers my preference. It asks me every time even when I tell it not to.

teakettle42 4y ago

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

dannyphantom 4y ago

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.

Mogzol 4y ago
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.
pantojax45 4y ago
Ironically people handle this with: link to instagram (because you can break out of browser): link to insta => link tree in insta => get to link you like => user can click safari button…
- hackmiester 4y ago
  Yeah, and that frustrates the hell out of me, too, because I don't have Instagram and it varies (based on Zuck's mood, I guess) whether they will even allow me to view someone's profile without an account.

FridgeSeal 4y ago

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.

Spivak 4y ago
> Click the safari button. It opens it in your normal browser. This is a solution to a different problem. The problem is the website can't prevent itself from being loaded in these frames like it can for <iframe>. I think there's a good chance Google will actually end up implementing this because they've already had a push to not allow Google login screen in webviews.
charcircuit 4y ago
If people want a feature so bad doesn't it make sense to add it?
- aendruk 4y ago
  Depends who wants it.

jefftk 4y ago

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.

sriku 4y ago
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.
- jefftk 4y ago
  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?

cortesoft 4y ago

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)

not2b 4y ago
Some sites attempt to prevent you from using the browser on a phone (notably reddit, though as you say old Reddit is a workaround).
- djitz 4y ago
  It pains me greatly that somehow Reddit engulfed just about every forum on earth, because I despise the way they force you onto the app. Their manipulation of search engines’ “last updated” parameters are also egregious.
  - polotics 4y ago
    Reddit I started to look at on my phone, but then it tried to bully me into installing an app. I like bullies much less than I like forums, so I do not look at Reddit on my phone anymore. Matter fixed!
CoastalCoder 4y ago
I don't know how big that minority is, but I'm part of it. I have an Android phone, and any time a company tries pushing me to use their native app, I start counting my silverware.
kody 4y ago
I'm right there with you. I wonder why I even have a smartphone since I'm so app-averse, other than requiring the computing power to run any modern bloated website. I've had arguments with PMs instisting that, for example, a shopper in a supermarket is not going to download an app but they will visit a website that can offer equivalent functionality.

sally1620 4y ago

Apple could solve this problem in Webkit. But Android is more complicated. On Android, third-party browser engines are allowed. Google cannot prevent an app from shipping its own browser engine for in-app browsing experience.

not2b 4y ago
The app would have to get much larger if they have to bundle most of a browser with it to avoid using the browser components on the phone. But sure, they could do that. But to be in the app store an app has to comply with the rules. Google could decide to require compliance with that header. It's no loss to them, because the consequence would be that almost all Android users would use Chrome, and the tracking in the browser would still be controlled by Google.
sneak 4y ago
Apple is incentivized not to solve this because presently app creators can hijack these links to open in their own native code app, provided: 1. they have paid to join the apple developer program 2. they have validated ownership of their URL's domain with apple 3. they have submitted to all of the censorship requirements of the apple App Store (failure to do this one is what destroyed Tumblr and the Hong Kong anti-police protester app, you may recall) 4. they pay apple a cut of their sales 5. they buy mac workstations for all of their iOS mobile developers, to run xcode Apple actually has a vested interest in apps supplanting the web, and has little incentive to improve web security features because Apple would prefer that new businesses simply use native iOS apps for everything (which sells more iPhones and locks both development investment as well as user eyeballs to their hardware).
- etchalon 4y ago
  Apple's interest is in selling people iPhones. One of the iPhone's marquee features is privacy. Apple has shown that it is willing to piss off native app developers in favor of user privacy.
- rawling 4y ago
  The other-people's-apps-opening-your-site-in-their-custom-webview-and-adulterating-it problem doesn't go away if you onboard with Apple, build an app & register your domain for Universal Links. The custom webview is quite capable of blocking ULs.

dang 4y ago

Related ongoing thread: Instagram can track anything you do on any website in their in-app browser - https://news.ycombinator.com/item?id=32415470 https://news.ycombinator.com/item?id=32415470 - Aug 2022 (371 comments)

cat_plus_plus 4y ago

Really, the proposal is to prevent people from implementing alternative web browsers? How about this: - Want to control the experience? Implement your own app - Want to be easily accessible to users without them having to install your app? Then accept them using any browser, including one embedded into Twitter - Want to only support specific web browser? You can try to detect them using various tricks or convince them to support DRM. But, accept that many users will be driven away.

account42 4y ago
Exactly, if there are apps that are collecting data they they should not or being otherwise malicious then we should go after those apps - preferably via the law but the app store gatekeepers can also act. This is not something we need to throw out the entire concept of alternate user agents over.

6510 4y ago

Didn't the new EU regulation intend to forbid forcing users to use a specific browser? Embedding your preferred browser into some other app doesn't seem like an acceptable work around?

neilv 4y ago

The article starts with historical anecdote from 1996, and talks about later frame-busting JS. At the time, you could also bust out of frames before JS was widely supported, simply by setting your HTML `A` element `target` attributes to `_top`. If you were already generating your HTML back then, including having a function to generate a link, this was possibly a one-line change. If you did this HTML-only frame-busting, you'd still appear within whatever questionable frames setup some other side had going, but as soon as someone tried to follow a link-- bam, now the site you host has either taken over the window, or are in an all-new window. Frames initially seemed like a godsend, for arguably useful purposes, like keeping a floating table-of-contents sidebar on a large document (before CSS). My once employer, Electronic Book Technologies (EBT), makers DynaText that TBL considered, jumped on frames for this purpose, and were able to convert DynaWeb to leverage frames "overnight" from the same SGML source. But frames did have some downsides even within a site, even if you didn't mess up the HTML (e.g., bookmarking of individual pages wasn't as usable/possible, and you could also somehow land on a page intended to be in a frameset but outside the frameset navigation UI context). Besides the TotalNews example the article mentions, there were a lot of sites putting other sites inside frames, maybe as often due to misunderstanding or not realizing, rather than aggressively trying to freeload. (At the same time as TotalNews, I'd built a fuzzy Web scraper in Java, and a prototype "personalized newspaper" that used it to get news articles and weather from other sides. I didn't know what to do about ads, which were brand new and image banners, so I just captured them while I was scraping, and re-presented them in the UI, at the bottom of the page whenever presenting data from the pages they were on. Such were the clumsy days of young Web innocence. :)

throwaway14356 4y ago
i've made a frameset site recently. With modern stuff you can have a single document display different content (or a frameset) depending on the name of the frame and push state a more representative url. This also solves the history navigation. loading videos and pdf files into frames is also nice.

destroy-2A 4y ago

Yes 10000x I hear insta engineers happily proclaim Instagram is one of the most popular web browsers :/

cvccvroomvroom 4y ago

Don't use web inside of an app, desktop or mobile for anything other than pure content. Use native for UI. Electron is doing it wrong and {NS,UI}WebView are abused too often to provide an entire app using a website.

infotogivenm 4y ago

> 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? e.g. a clickjacking attack tricks you into thinking you are interacting with a harmless site, when in actuality you are clicking “buy now” on amazon in an invisible logged-in iframe.

mtlynch 4y ago
You're right. They have it backwards. It's the legitimate site that needs to protect itself from being invisibly framed within a malicious site.
vgel 4y ago
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.
- remram 4y ago
  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.

codereviewed 4y ago

Why doesn't anyone ask what the user wants? Are we only about what the app owner or the website owner want?

svnpenn 4y ago
https://wikipedia.org/wiki/Poe%27s_law https://wikipedia.org/wiki/Poe%27s_law
exodust 4y ago
Correct. In addition to the proposed solution, there should be a global setting on the phone that lets users decide that all web links in apps should open in browser; ask every time; or open in app every time. In addition, a per app setting that overrides the global setting should be available too.

postalrat 4y ago

Stop installing apps and demand PWAs.

sneak 4y ago
On iOS this means you can't get notifications. Notifications are really important. Apple won't do web notifications because it means then people wouldn't have to pay their 10x-over-the-industry-standard premium (30% instead of 3%) for bundled credit card processing if they buy stuff on the web and not via the App Store.
- mitjam 4y ago
  This seems to have changed. Web push is coming to mobile Safari next year. https://webkit.org/blog/12945/meet-web-push/ https://webkit.org/blog/12945/meet-web-push/ (Edit: better link - „Keep an eye out for Web Push on iOS and iPadOS in 2023.“)
  - sneak 4y ago
    The notifications all go through Apple still, which allows them to monitor and censor them. This is not much of an improvement. :(
    - postalrat 4y ago
      Whatever the web push standard lacks for encryption or hiding data can be done by your app.
      - slightlyoff 4y ago
        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-payload-encryption https://web.dev/push-notifications-web-push-protocol/#the-pa...
deleted 4y ago
[deleted]

kmstout 4y ago

TotalNews was great for a young news junky who hadn't yet discovered RSS.

thayne 4y ago

There are a couple of problems with this proposal. First of all, it would prevent you from using webviews to implement any kind of browser. Which in the case of iOS means it would impossible to make an alternative browser to safari, because you aren't allowed to use an alternative browser engine. Secondly, a lot of native apps rely on using websites controlled by the same entity that have x-frame-options set, and those would break if that suddenly caused it not to open.

sneak 4y ago

> This means: If you’re logged into a website in your phone’s browser, but you click a link to that site from a native app’s webview, your logged-in state will not be honored. You’ll need to log in all over again. > At best, this is irritating. At worst, it gives people the false impression that the website is broken or logged them out. No, at worst, it uses the original/authentic website as phishing bait, and convinces the user to type a login and password for site A (the framed site) into application B (which shouldn't have access to it).

gauddasa 4y ago

I prefer not to use app if the same service is available through website. And those services that are not available through websites, they rarely involve any hyperlink to a third party. This may change in future if many essential services ditch their websites and switch exclusively to app. That's one of my nightmares.

tristanb 4y ago

It’s always a terrible experience too. I’m never logged in, my password management app doesn’t work, and if I do want to login it’s a new browser so it trips all the security.

deleted 4y ago

[deleted]

a-dub 4y ago

protip for gmail on android users: gmail -> settings -> general settings -> open web links in gmail -> uncheck

Raziarazzi 4y ago

Some apps lack this setting, whereas many do. Funny thing is that the Gmail programme on the iPhone offers this prompt, but it never saves my preference. I'd be amazed if a native app couldn't strip the header if it had as much control over the webpage as it appears to have. Alternately, you might use a proxy that removes it and ignore the resulting HTTPS problems.

chrismorgan 4y ago

I think the proposal of piggybacking on X-Frame-Options as expressed is just a smidgeon too coarse, and it needs a little more nuance. My suggestion would be that web views that aren’t deliberately being an actual browser be classified as possessing some origin, preferably checked where possible by the OS to match an origin or custom scheme that’s associated with the app (thus generally tying into Android’s app links and iOS’s universal links). Of course, this is still technically fallible since browsers need to be able to disable it, so it’d become another thing for the app store reviewers to check. Then, you apply your Content-Security-Policy’s frame-ancestors directive (the successor to X-Frame-Options, allowing more nuance than simple DENY/SAMEORIGIN: e.g. `Content-Security-Policy: frame-ancestors 'self' instagram:` would be same-origin or the Instagram app), and treat deny as “open in an external browser”, as proposed.

polotics 4y ago

This! I most notably always fight google news: preventing it from dropping out of real-chrome into worst-chrome by opening in new tab has become finger memory...

obviouslynotme 4y ago

You will never prevent people from downloading your html and rendering it, correctly or incorrectly. Attackers will just pull in an open source browser engine that supports mobile. Our smartphones were not made with security in mind. They are literal spyware. I suspect the more likely use of OS-based frame busting is to circumvent ad blocking browsers. This is even the use case he mentions as an example.

potamic 4y ago
The next step could be the OS taking control of HTTP and allowing only the native browser to receive a HTML content type.

dwaite 4y ago

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.

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

Abimelex 4y ago

I also have always the problem, that "in app browsers" don't recognize the native Apps I have installed and so links to youtube or Instagram e.g. do not open the native app but the browser version instead. Copy pasting links is my everyday browsing experience on twitter and linkedIn e.g.

samwillis 4y ago

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 Apple Pay or their saved card details. These aren’t available in most IABs, so they click the “open in browser” button, but now they have lost their cookie and have an empty cart! This causes a massive drop out rate at checkout. I run a store that sells personalised items, it takes time for a customer to prepare their item before going to checkout. We experienced something like a 30% drop out rate from Facebook ads due to this. The “work around” was to detect users in an IAB and display a message on first navigation attempt to prompt them to click the “open in browser” button early. The fact that Facebook let this happen shows that have very little interest I’m making the advertising experience better for advertisers. They just want to keep users in Facebook.

throwaway14356 4y ago
it sounds like a scam. If it hurts sales you've paid for it would be hard to argue differently. Showing the advertised page in an iframe is a very old scam. You can buy those "clicks" for around 5 dollar per 5000
btown 4y ago
How did you detect that an IAB was being used? Do they typically have unique user-agents or something?
- krausefx 4y ago
  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.

SergeAx 4y ago

I see almost no reason to use mobile apps for Facebook, Instagram or Twitter today. Just use mobile web browser instead. The only thing is a dark mode for Facebook, but I believe it is achievable via DarkReader plugin for Firefox. Also, ad blockers are more or less working in browser, although Facebook is actively counteracts.

ramblerman 4y ago
A lot of them detect it and try to force you. It's malicious as hell, but somehow allowed. For example reddit won't open a link it deems +18 through the web browser, and redirects you to use the app.
- SergeAx 4y ago
  I saw that on Reddit couple of times. I just close the tab in that case: there's nothing 18+ on Reddit that worth installing their app.
  - Dracophoenix 4y ago
    A solution to this is use HyperApp or Userscript to automatically redirect to old.reddit.com. It works like a charm.
    - SergeAx 4y ago
      Not for mobile Firefox, unfortunately.
      - Dracophoenix 4y ago
        Well, that's on Apple.
- SergeAx 4y ago
  I wonder, by the way, why Reddit's "install app or continue with browser" popup isn't blocked by uBlock Origin. It is clearly an ad, and very malicious indeed.

KronisLV 4y ago

> Popular apps such as Instagram and Facebook don’t just use vanilla webviews. They use customized ones, with their own quirks. This might be understandable, but also feels a bit odd. Why couldn't they just use what the system already providers, without bloating everything with their own implementation? Then again, one could probably ask the same about desktop software that is commonly based on Electron, but in theory might as well be run through Firefox with some additional capabilities that locally running Electron apps would otherwise get. Then again, we kind of had PWAs on the desktop, which have been retired now as well: https://9to5google.com/2021/01/27/firefox-discontinues-work-pwa-desktop/ https://9to5google.com/2021/01/27/firefox-discontinues-work-...

mschuster91 4y ago

> There was indeed a time when this argument made sense: the years before 2015, which is when iOS 9 introduced a global Back button conveniently solving the problem. And of course Android has its global Back button. These days this argument holds no water. Oh of course it does hold water. On Samsung's pretty recent Active Tab 3, opening a link in an app (e.g. RIF) in Chrome takes ages (I recently timed it, 80 seconds) because Chrome for whatever goddamn reason thinks it has to reload all the icons for the 100+ tabs I have open every time Android's completely bonkers memory manager decides it wants to suspend Chrome in background.

tnjm 4y ago

Related to the quirks of in-app browsers mentioned in the article, the Facebook, Instagram and Snapchat apps manage to break file uploading every few months, and take several weeks to fix it each time. I'm not sure why this in particular is such an achilles heel, but it's a surprisingly big problem for e.g. online stores advertizing on Instagram and offering personalized products.

ccouzens 4y ago

There have been a couple of these posts recently and they all contain the same flaw. They talk about their experience on an iPhone and assume it's true on all ecosystems. It's not true for mine (Firefox and Android). When following a link from Gmail it opens embedded within the Gmail app and the site has access to the same cookies as if I'd opened it in the browser. And it's trivial and seamless to then open into full Firefox (position in page and form values are kept). I think Chrome Android is more or less the same too.

rawling 4y ago
Gmail may do that, but Android still offers developers "a webview that is basically a detached Chrome tab" and "a webview that you control and add your own chrome around". Instagram offers me a UI that looks quite different to Gmail, so I suspect it's still using the latter.

bastawhiz 4y ago

iOS aside, I'm not sure there's anything to be done here. Apps could simply embed their own browser engine that lets them use webviews in whatever unfettered way they want. And on iOS, it's not unlikely that Apple will be required to open their walled garden to other browser engines in the future.

jaywalk 4y ago
> Apps could simply embed their own browser engine that lets them use webviews in whatever unfettered way they want. The biggest pro for consumers in having an app store is that the store can set regulations on apps. If Google says apps can't do this, then it's effectively dead. Of course, that would rely on Google effectively policing it.

codethief 4y ago

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.