I really wish the idea that apps need to open websites in-app would go away. Like it looks neat when you're demoing it for your coworkers but it just increases the number of taps since to do anything useful I need to open in in Chrome/Safari anyway.
If the in-app browser was just a window into actual Chrome/Safai (i.e. it's a real tab when you open Chrome/Safari and has your logins bookmarks, etc.) and you could "pull" the window into the foreground as a slick transition to the browser app then it would be fine, but as it's implemented it's mostly just annoying for everything but oauth flows.
Hmm, that’s strange because I mostly find the ability to open websites in-app very useful: The context of how I was directed to the website exists in the app. I feel that if the site I’d moved to Safari, I eventually forget how I got to this site.
I think the problem isn’t in the WebView model - It’s probably that you have to use the browser to do something useful that WebViews can’t.
>[...] This opens the door for other apps to run malicious code, such as registering callbacks that try to intercept usernames and passwords. Additionally, a malicious app could open another web page that mimics the Link flow in a phishing attempt.
I'm not sure what type of threat model they have, but I don't see how this increases security at all. If the app is malicious, there's nothing preventing them from faking the CCT interface, or omitting it all together. It's not like users would be suspicious if they were asked for credentials outside of a chrome custom tab.
Ironically, Plaid is doing the same thing. Their login screen[1] is designed to look like you're logging into your bank, even though your passwords are sent in plain text to plaid.
> While not all users have Chrome installed, the vast majority do. For those who do not, we are using the browser fallback method described above (option 3); other than adding one line of code, we get the fallback for free from CCT. As noted before, the browser fallback is not the ideal user experience due to its latency, but it does maintain the high level of security that Plaid requires.
Maybe I misunderstood the article, but the way I read this sentence is 'this is one of the four options we considered, and it wasn't implemented because of the UX'
And they explicitly disclaimed responsibility for security breaches.
>TO THE EXTENT PERMITTED BY LAW, PLAID, ITS AFFILIATES AND ITS AND THEIR SUPPLIERS WILL NOT BE RESPONSIBLE FOR: (A) ANY LOST PROFITS, LOSS OF USE, LOST OR INACCURATE DATA, FAILURE OF SECURITY MECHANISMS, FINANCIAL LOSSES, OR ANY INDIRECT, SPECIAL, INCIDENTAL, RELIANCE OR CONSEQUENTIAL DAMAGES OF ANY KIND OR (B) ANY DAMAGES OR AMOUNTS EXCEEDING, IN THE AGGREGATE, THE GREATER OF (1) THE AMOUNT YOU PAID US TO USE THE PLATFORM AND (2) ONE HUNDRED U.S. DOLLARS (US $100).
If the in-app browser was just a window into actual Chrome/Safai (i.e. it's a real tab when you open Chrome/Safari and has your logins bookmarks, etc.) and you could "pull" the window into the foreground as a slick transition to the browser app then it would be fine, but as it's implemented it's mostly just annoying for everything but oauth flows.