-
Notifications
You must be signed in to change notification settings - Fork 9
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
custom-schemes.md: additional concerns #41
Conversation
hober
commented
Nov 1, 2023
- Add two additional points.
- Use headings instead of numbers so that nesting is more straightforward.
- Separate the conclusion from the list of items.
…sting is more straightforward. Separate the conclusion from the list of items.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Reformatting looks good, just suggest using bullets consistently.
### Friction and app switching | ||
|
||
Opening a custom URL scheme will switch apps, which is a high friction user flow. A browser API could present relevant UI (even from third party wallet apps) in a sheet over the webpage, which is a less disruptive flow. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
custom-schemes.md
Outdated
|
||
- If a user uses a website via http (not https) and it invokes a custom scheme, it's possible that an attacker with access to the network could eavesdrop on or even modify the request (such as by replacing the verifier's public key with their own). | ||
- A browser API could take the position that it will function only within the context of a secure context (https). | ||
If so, that's a problem because it won't go back to the same tab. Apps don't have the ability to return information to the same page that invoked them after a custom scheme invocation; they can just open a new page in a new tab. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think existing wallets work by establishing their own (UI-less) HTTPS connection to the verifier server. Then the website can be waiting on a fetch to the server which resolves when the UI should be updated to indicate the credential has been received. I'm not an expert though, perhaps @Sakurann or @msporny want to weigh in here?
Regardless, existing apps definitely work in this regard. Perhaps this should be framed as a developer ergonomics issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, for some definition of "definitely work". :) It is possible to end in a "successful state", but that ignores the UX challenges of what happens when things go wrong. In the best case (on a same-device flow), presuming that the protocol has some sort of "navigate to this URL when you're done" feature, you're left with a "dead tab" in the browser -- something that the individual will never go back to and have to clean up later.
One of the design goals of CHAPI was to not "break the flow" in the existing web page (and not to leave "dead tab"s around). This is also aligned w/ the design goals for Payment Request (and Payment Handler). That is, you want the browser API to always tell you when the interaction is done (success or failure) and return you to the exact place you were on the website that invoked the interaction in the first place. I expect FedCM has the same (ideal world) requirements.
There are at least three problems w/ invoking a native app or a web-app (using what's available today) in a separate window:
- In a same-device flow, when the flow completes successfully, navigating back to the same tab/window that the individual was in (in the browser) is not possible. In the best case, you have to open a new tab/window, leaving "dead tab"s around.
- In a same device-flow, the UX is not ideal -- popping windows up (because you need to be in first party mode in many cases, and sometimes you need to log in -- which pops up more windows if you are using an external IdP) can cause the user to feel as if something bad is happening - "User: WTF is going on here? This doesn't feel right *closes window, breaking the interaction*").
- In a multi-device or same-device flow, the user is never navigated back to the originating page when there is an error or the interaction is canceled. They're left in the "invoked app" and have to manually switch back to their browser session, which gets no indication that things went wrong and therefore "hangs" for an unacceptably long time -- 5 minutes, 10 minutes... how long should a site give an individual to complete an out-of-band flow?
It's not just a developer ergonomics issue, it's a UX issue, both for same-device and multi-device flows.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a same-device flow, when the flow completes successfully, navigating back to the same tab/window that the individual was in (in the browser) is not possible. In the best case, you have to open a new tab/window, leaving "dead tab"s around.
Definitely agree not having a way to navigate back to the browser app is a problem that we should add to this list.
I had assumed the "best case" wasn't that the wallet would open a new browser window (which browser?), but that it would send a message to a server which the existing web page was waiting on and the user would manually switch back to their last application and see it complete. But there are problems with that as well (eg. under memory pressure the browser may have been killed). So OK Tess's description makes more sense to me now. I'll merge it as-is.
The jarring UX of a full screen app switch is also a problem I can add to the list. I think I've already captured your "3".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the user would manually switch back to their last application and see it complete
This is a tall UX ask of the user. Some of the testing we performed showed some individuals not understanding what the next step in the process was... so, after sending the presentation, they just sat there looking at the wallet, not knowing what to do (because some of them thought they were still in the browser and others didn't know about the usage pattern where you complete something in an app and then switch back to a browser -- it's a rare usage pattern on mobile phones to bounce from browser->app->browser for the same logical flow).
Some were expecting wallet to tell them the next step, and in some cases, the wallet just said "transaction complete!" and then nothing. This could be mitigated by the wallet showing a UI telling them to switch back to their browser (but that feels like a UX failure). To get a consistent experience across all wallets for that UX flow, you'd have to get all wallets to implement that (hacky) UX hint. We've also found that in some cases, once the individual is in the wallet, the wallet software wants them to do other things and keep them there ("Get another coupon!" ... "Add a credit card!" ... "Wait, update your password!" ... "Turn on MFA!")
So yes:
- Full-screen is jarring, a modal that allows the UX flow to be performed and then return the individual back to the page (with a concrete transaction result for the website to process) is better.
- Giving the wallet some hint about where to navigate the user back to (if we don't do the modal thing above) might also be helpful.
We might consider something like the "peek" feature in Arc as the ideal UX pattern to follow here:
https://www.reddit.com/r/ArcBrowser/comments/113ui8u/peek_by_arc_the_best_tab_never_made/
- If a user uses a website via http (not https) and it invokes a custom scheme, it's possible that an attacker with access to the network could eavesdrop on or even modify the request (such as by replacing the verifier's public key with their own). | ||
- A browser API could (and almost certainly should) take the position that it will function only within the context of a secure context (https). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's more of a problem of the website and ecosystems can take precautions against this (rules, checks for HTTPS redirections, HSTS, etc.).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leaving security up to "ecosystems" tends to result in more security holes than we'd like to see. The mere fact that you can invoke an OID4VP flow via an HTTP website is a security issue, and no amount of lecturing web developers will prevent that from happening. A browser API would help guide developers towards only operating in HTTPS mode, universally, which is a good thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm OK with relying on the ecosystem but only if we're confident the incentives are aligned with the agency. I think it's issuers who have the most incentive for security and so they're going to want to certify wallets. Most wallets will probably want to ensure they're invoked securely (even if only to earn the trust of the credential issuers). But verifiers may not have as much incentive, they're more incentivized to make adoption as easy as possible. So if wallets can't impose security requirements on verifiers then I think we have a break in the accountability chain and should expect security for users to suffer. Having the platform in the middle seems to fix this because the platform is incentivized to earn the trust of wallets/issuers (otherwise they'll go around the platform API), and so will impose security constraints on verifiers which increase trust of the wallets and issuers.
|
||
Opening a custom URL scheme will switch apps, which is a high friction user flow. A browser API could present relevant UI (even from third party wallet apps) in a sheet over the webpage, which is a less disruptive flow. | ||
|
||
## What are the privacy implications of a wallet accepting custom schemes? | ||
|
||
- [Android aims](https://developer.android.com/training/package-visibility) to keep the list of installed applications private from other applications, but this capability is reduced for applications which handle arbitrary intents like custom URL schemes. By registering to support custom URL schemes, a wallet application may effectively be leaking PII (such as the user's likely citizenship status or state of residency) to other applications on the device. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The leak happens only when the website learns whether the app was opened or not (or am I missing anything?). Therefore, having e.g., a user interaction before the wallet calls back to the website (via a backchannel) would help to reduce the impact of this privacy leak. (It cannot be exploited in large scale any longer.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@danielfett see this thread for background on this statement: #37 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's not the problem. It's that registering an intent filter on Android makes your Android package name discoverable by other Android apps (silently and at any time) which say they need to query the system for apps satisfying that intent filter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on the additions and headings.
Co-authored-by: Rick Byers <rbyers@chromium.org>
Co-authored-by: Rick Byers <rbyers@chromium.org>
Co-authored-by: Rick Byers <rbyers@chromium.org>