Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sites should be able to allow open PWA access. #3

Open
LuHuangMSFT opened this issue May 28, 2020 · 3 comments
Open

Sites should be able to allow open PWA access. #3

LuHuangMSFT opened this issue May 28, 2020 · 3 comments
Assignees

Comments

@LuHuangMSFT
Copy link
Collaborator

[Ported from https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/301]

The current spec'd pwa-site-association file doesn't allow for a site owner to openly allow any PWA to handle it's URIs (or a subset of them). I think to remedy this, wildcard support should be added to the 'manifest' field of this pwa-site-association.

Though I don't think this would be common for most sites, I can imagine some testing and education scenarios, as well as some open-source communities that may want to open this ability to everyone.

@LuHuangMSFT
Copy link
Collaborator Author

@HowardWolosky:

@mhochk, can you provide a strong example here? This sounds pretty dangerous to me. With one mistaken configuration property added to a manifest for a banking site, all of a sudden any PWA would be able to register as its URL handler and potentially spoof the site.

@mhochk
Copy link

mhochk commented Jul 7, 2020

My examples come from thinking about this feature in comparison to the existing capabilities offered to apps. As one example, www.xkcd.com has intentionally made its primary content (the comics + title + hover text) accessible through a simple JSON API so that others can easily write apps to consume this data. As a result, there are multiple XKCD Viewer apps (e.g. Easy xkcd) that not only leverage these APIs, but also register for the xkcd.com URLs so that when clicking an xkcd.com link you are offered the option of opening it in the viewer rather than the browser. I would expect that in a similar fashion the xkcd.com site might want to open up intercepting its URLs to any PWA interested in doing so.

This isn't a make-or-break feature, so if there are strong security concerns it may make sense to exclude it for now and only revisit it in the future if the demand for it arises.

@LuHuangMSFT
Copy link
Collaborator Author

In Android, any app is free to configure intent filters to capture URLs without needing validation from the site (deep linking). The disambiguation dialog will be shown to the user. To bypass the disambiguation dialog requires validation from the hosted assetlinks.json file on the site (app linking).

Xkcd cannot prevent apps from registering intent filters with Android to handle their content URLs, and doesn't need to opt-in to opening up their URLs for capture. One difference from PWAs is that Android apps usually come from a store and have IDs. There is quality control and recourse for delisting these apps.

I have seen discussions for and against allowing third party developers to write apps for first party content without any action from first parties I don't have an opinion on this issue yet.

I'm not sure there is a lot of value in a flag that allows open access if it is going to be off by default. I would rather first determine if there could be a general solution of enabling 3rd party apps to capture first party URLs.

Apart from deep links in Android, I think both Apps For Websites in Windows and Universal Links in iOS require first party validation. Both of those require listing specific app ids.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants