My understanding is that in-app browsers are only browsers if browsers don't need to include any privacy. e.g. WKNavigationDelegate seems to allow the surrounding app to capture cookies for any site the user logs into.
-
-
Replying to @jyasskin @othermaciej and
Well, they *are* browsers after all. Of course they do.
1 reply 0 retweets 0 likes -
How's that different than if you install Firefox on your Android? (Or Google Chrome on iOS).
1 reply 0 retweets 0 likes -
Replying to @tobie @othermaciej and
You are trusting any browser you install with your full browsing data, which is why Firefox, Safari, Brave, etc. use privacy arguments to try to convert Chrome's users. How many users realize that their browser decision isn't keeping them safe when they click a link in an app?
1 reply 0 retweets 1 like -
Replying to @jyasskin @othermaciej and
It's not like they really have a choice.
1 reply 0 retweets 1 like -
They don't and that's not OK. But more to the point, giving a choice will not fix the problem in practice. This is a serious design flaw that users shouldn't need to know or care about.
1 reply 0 retweets 2 likes -
Replying to @KenjiBaheux @tobie and
It would be great if more in-app browsers (or even all of them) could be the good kind. Tough problem to take away or restrict existing APIs, but worth it to work on it. In any case, the in-app browsers that are implemented the less good way are still browsers.
1 reply 0 retweets 1 like -
Replying to @othermaciej @KenjiBaheux and
I've been defining browsers as "apps that accept all navigation intents"; that's a bit Android specific (as you can actually replace the default browser there), but it captures the essential difference in responsibility to the user, IMO. These WebView things are franken-browsers.
2 replies 0 retweets 2 likes -
Replying to @slightlylate @othermaciej and
Arriving at a sort of agreed-upon definition would be interesting and would help inform conversations. Maybe a
@w3ctag finding? How can we make progress when there's no agreement between browser engineers as towards what we're working?2 replies 0 retweets 2 likes -
Replying to @tobie @slightlylate and
I’m not sure a TAG finding on “what is a browser” would be of practical use, and it could easily fly off into the abstraction stratosphere. (My quaint view is: if it does web browsing, it’s a web browser. But not sure this has anu practical relevance.)
2 replies 0 retweets 2 likes
I'd like to trust our colleagues there to elucidate meaningful lines that highlight important differences (until they don't). The @w3ctag helped accelerate TLS adoption through a set of overlapping Findings that were used to improve outcomes in subsequent standards debates, e.g.
-
-
Replying to @slightlylate @othermaciej and
I realise that Apple specifically was pro-TLS for apps (but not for websites?), but perhaps the
@w3ctag's leadership allowed all parties to reframe the web debate in terms of user value and privacy benefit.1 reply 0 retweets 0 likes -
Replying to @slightlylate @tobie and
Safari has a pretty aggressive warning for non-TLS websites, even more so if you focus a form field. Not sure why you’d think Apple isn’t pro-TLS for websites. I’m not aware of anything from the TAG influencing us on this, at least not directly.
1 reply 0 retweets 0 likes - 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.