-
simonw mkramer Twitter Twitter owns a signal they handle and attach to requests via Twitter Blue: very easy. But the technical obstacles for in-app browsers are there for very good reasons to protect both publishers and users from data leakage and potential hijacking if the app is a bad actor...Permalink On twitter.com
❤️ 2 Favorites
Mood 0
-
simonw mkramer Twitter If you wanted to get a site's subs to work in an in-app browser smoothly you'd need the app to have a line into the site's login system, it would need to manage users's logins or at least share the email to the site, and potentially auth with that site and then store that auth...Permalink On twitter.com
❤️ 2 Favorites
Mood +1 🙂
-
simonw mkramer Twitter Maybe if you use a centralized authentication provider like Log In With X or a popular SaaS paywall like Pico, Twitter could make deals, though you'd still have to also log into those providers *in Twitter*, but for folks who want to run their own paywalls this wouldn't work.Permalink On twitter.com
❤️ 2 Favorites
Mood +8 🙂
-
simonw mkramer Twitter Anyway, the shitty middle option that some are pushing people into is to push any opening of a link (in any app) to trigger a the publisher's app (which can maintain auth and the system can set as a handler for that URL) which is the imperfect solution for an imperfect world...Permalink On twitter.com
❤️ 2 Favorites
Mood -6 🙁
-
simonw mkramer Twitter But that's such a hack and comes with a host of bad behaviors, weird requirements, and potential hijacking by bad apps that users might unknowingly download. The right solution is to burn in-app browsers to the ground forever and fire the ashes into the sun.Permalink On twitter.com
❤️ 3 Favorites
Mood -9 🙁
-
simonw mkramer Twitter (In case you are curious, here's some info on how Twitter Blue works - help.twitter.com/en/using-twitter/twitter-blue-ad-free-articles#adfreehow )On twitter.com
❤️ 2 Favorites
Mood +1 🙂