Re: [w3c/manifest] Add id member to manifest (#988)

> > Are there side channels such as "thing X will only happen if there's a matching manifest ID" where X can be a network load, a flag being set, an API returning a different value etc?
> 
> The [scope_extensions](https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-explainer.md) proposal intends to use app IDs to enable web apps extending their scope to other origins. Combined with a feature like link capturing a web app would know its ID is one listed in the cross origin web-app-origin-association.json file via capturing a user navigation to that other origin as a JS event.

Interesting! But as far as I can tell, super infeasible

So the case setup would be:
* Web dev sets id to, say `user_1123314` on app.com
* Web dev sets scope extensions to other origins, say app2.com
  * The hooking of these origins can't happen yet - app2.com has to not serve the association file yet, or other means of delay
* User clears browsing data (uninstalling would completely remove this record, so that case is fine)

The 'attack' - In order for the website to discover the id, they have to:
 1. guess the id in the associations file on app2.com. If the id was 'user_1123314`, then, well, let's say they guess N number of user Ids
 2. get the user to navigate to app2.com after this guess was correct. The fact that app.com gets the launch from app2.com would tell it that it guessed correctly.
 3. However, this would tell them that ONE of the guesses in the N guesses was right. They would have to modify their associations on app2.com to continue narrowing down to the correct id.

So this means that the attack would require:
1. Site to have app2.com have, say, half of their user id space as id associations in the file (thousands? Millions?)
1. the site to ask the you "hey can you click on these thousands/millions of links until I tell you to stop"
1. When a link "works", the site then has to then modify the origin association file to have half again (binary search), and go back to step 1.

This seems like an infeasible attack vector to me, would take absolutely forever & require a ton of user interaction.

If we decide this is somehow feasible (interested, then there are some mitigations):
* Restrict the amount of origin associations you can make in the origin association file.
* Restrict the refresh rate of this file. refresh it once a day? This means it would take 16 days minimum of the above process, including user doing all the guessing, to narrow down to a single id in 100,000. With association restriction, this removes the binary search, and makes it.... 10,000 days (28 years) if we limit to 10 associations? Again assuming the user would play ball and click on 100,000 links? 

Anyways - let me know if my thinking is off here.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/988#issuecomment-902120411