I saw this issue on the Misskey issue board today and I have some concerns over tracking, fingerprinting and de-anonymization.
The proposal said ‘And handling applications themselves MUST apply all the normal and appropriate access controls when retrieving and displaying resources linked this way.’, which I interpret as if any remote fetch is needed, the public key of the user’s actor would be used.
I think there is a good reason we don’t have just a web+search://my+search+term functionality in web browsers.
Technically we can argue that people need search engines every day, and everybody use different search engines so we should have a protocol handler that just dispatches to the user’s preferred search engine.
It isn’t done in reality for a reason IMO, (1) it is not just open redirects there also is fingerprinting and other information leakage concern (2) users still want flexibility, some people use multiple search engines / instances at once, some people want to vet the user or instance first before viewing a resource that could be illegal, etc.
For example I can just add a link to web+ap://my.tracking.example , and monitor which instance looked up my post, and what kind of HTTP signature are attached to track who viewed this (the keyId will encode the User ID), and correlate this with what IP was visiting the page hosting the link (which I control too). I did not see the proposal (either on the FEP or fedilinks.org) discuss considerations in this realm.
At the very least originally the tracker need to predict my instance first and give me a link like https://my.instance.example/@tracked@tracking.example, so they know (1) the IP that loaded the page that hosted the link (2) the public key that signed the later fetch request, now they can systematically track every clicker of that link with a valid Fediverse session somewhere on the device, by just just using web+ap://tracking.example/@tracked or semantic equivalents.
This defeats the purpose of things like media proxy in Misskey. At the very least this /protocol-handler implementation should never sign any remote fetch requests.