71–80 of 158 posts
Stop installing apps and demand PWAs.
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.
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.
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).
> 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?…
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…
> 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. Apple absolutely can. They already out severe restrictions on what apps are allowed to use for rendering web views. They also approve every app. They can enforce whatever rule they want.
The solution is not to add what amounts to an advisory flag to your page headers, and in the process, mislead users into believing in-app webviews are safe.
Earlier quoted context omitted.
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) Us…
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
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.
Perhaps it can be an option to check: "Always open websites in your default browser".
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.
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-po…
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.
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…
Stop installing apps and demand PWAs.