Why doesn't anyone ask what the user wants? Are we only about what the app owner or the website owner want?
Let websites framebust out of native apps
61–70 of 158 posts
Re: Let websites framebust out of native apps
#62It 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.
Perhaps it can be an option to check: "Always open websites in your default browser".
Re: Let websites framebust out of native apps
#63Why doesn't anyone ask what the user wants? Are we only about what the app owner or the website owner want?
Re: Let websites framebust out of native apps
#64Why doesn't anyone ask what the user wants? Are we only about what the app owner or the website owner want?
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.
Re: Let websites framebust out of native apps
#65Stop installing apps and demand PWAs.
Re: Let websites framebust out of native apps
#66TotalNews was great for a young news junky who hadn't yet discovered RSS.
Re: Let websites framebust out of native apps
#67There 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.
Re: Let websites framebust out of native apps
#68It 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.
Why shouldn't clicking a link open your browser application? It's done that the entire history of the web and computing.
Embedding a browser in apps to try to keep users "engaged with your brand" after they have already clicked a link to leave for the web is a new thing and is erroneous. Why would you be irritated that clicking a web link opens the link in the browser? That's what's supposed to happen.
Re: Let websites framebust out of native apps
#69Earlier quoted context omitted.
IIRC the [responsible org] says we don't have to add the `X-` to custom headers anymore. Edit: IETF and IANA are the orgs RFC 4229 https://www.rfc-editor.org/rfc/rfc4229.html
This is not a custom header (i.e. one with no UA semantics), it is a standardized header called X-Frame-Options which requires the “X-“ for browsers to recognize it. The prefix is an artifact of the era the header was introduced in. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-...
It's also been deprecated in favor of the content-security-policy header.
Re: Let websites framebust out of native apps
#70> 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).