Hacker News new | past | comments | ask | show | jobs | submit login

> When it comes to embedding third party content with iframes, you essentially want two-way security and privacy. The embedder can't change things in the embedded and vice versa.

> With webviews however, that model doesn't make much sense: the embedder is controlling the webview and frequently needs to apply or enrich the embedded view.

This isn't necessarily the case - it's certainly often been the assumption, but I don't think maintaining status quo here is a self-evident good.

Common case: I click a link in an email client / social media feed and it opens in a webview controlled by that app. It's a 3rd-party link either sent to me by an email contact, or posted by some private individual using the social media platform: it's not necessarily owned/controlled by the developer of the app, and as a user, I have no strong desire for the app to have direct access to that content.

The iframe comparison fits quite well in my mind, and most of the concerns / ideals hold true.




OP was referring to the use case where webviews extend your native mobile app functionality.


OP was using that use case as their example, but this is about standardisation so it needs to fit a range of use cases, most importantly the common ones.

How do you restrict one use case and not another? If a restriction is opt-in in a standard it's not useful.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: