Fallback URI handlers on a webpage

[SoniEx2]

Let's say you have a mastodon and a website, and you wanna put mastodon links that open in the user's mastodon on your website. So you go on your website and sprinkle web+mastodon: around only to find out that browsers are user-hostile and drop the user into a very confusing error page.

It'd be nice to have a way to set all links on a website to fallback to a specific URI handler, so that it, for example, goes to your mastodon instance, or to a mastodon tutorial.

These "fallback handlers" would have to be URI-specific tho, because you may also want some ganarchy links on the same webpage, which uses web+ganarchy URIs instead. So you'd want, web+mastodon to be handled by a mastodon instance and web+ganarchy to be handled by a ganarchy instance.

Nothing gets registered tho, so if the user goes to another webpage, they get to either use their own handlers or if none are available, that webpage's specified fallback (if any).

[domenic]

I had trouble understanding this scenario, but I think I see now. The idea is that today you can:

• Control the resolution of web+mastodon: links to redirect to a different URL pattern on all pages the user interacts with, using registerProtocolHandler. The user can then override this resolution using their browser settings.
• Control the resolution of web+mastodon: links to redirect to a different URL pattern only on pages you control, by modifying the href="" attribute to contain the rewritten URL pattern. The user cannot override this resolution.

But this is asking for a third path:

• Control the resolution of web+mastodon: links to redirect to a different URL pattern only on pages you control, by ???? (new feature here). The user can then override this resolution using their browser settings.

Is that correct?

[SoniEx2]

yes, I believe so. it's a fallback for when no protocol handlers have been registered.

so like, the way link resolution works is like this (roughly):

1. does it have a protocol/base?
2. if not, let base be the current address's base
   1. does the document have a base tag?
   2. use the base tag for base
3. if the browser handles the resulting protocol, navigate to the resulting address and return
4. if the user has a protocol handler for the resulting protocol, prompt the user to select one

I propose adding a 5th step: if the document has a ????, use that.

[domenic]

Well, remember https://whatwg.org/faq#adding-new-features; let's not jump straight to specific solutions. I tried to reframe your OP in terms of use cases, instead of solutions. (Step 2.) Assuming I did so accurately, let's brainstorm other ways of accomplishing those use cases:

• We could add a way to use registerProtocolHandler() with a scope, so that it only applies to your page or site.
• We could add back isProtocolHandlerRegistered(), which would allow you to test if a protocol handler is present, and only rewrite the href=""s if there is no such registered.

Both of these seem to accomplish the use case ("third path") I listed above.

By the way, per the adding new features process, the main work still to do here is step 3.

[SoniEx2]

yes, we could add tracking. however I'm also a firm believer that registerProtocolHandler should only be allowed in onclick event handlers, so I'm strongly against those solutions. (and at least one of them still follows the "algorithm" of going for a document-specific handler after exhausting the other options, so I'm not too far off.)

I specifically want something implicit, with no user interaction and no malware (XSS) or tracking potential. (not using JS is also a nice bonus (I explicitly disable JS on github because their layout/design(?) is absolutely unusable) but eh w/e.)

consider these:

1. isProtocolHandlerRegistered can be spammed by websites to know what you visit without doing anything at all relevant to those protocols.
2. registerProtocolHandler with a scope for the current page or current website, but in an XSS, causing all sorts of problems that can't be easily fixed, potentially surviving reloads.

[wiktor-k]

Hi @domenic, I had the same problem with other URI handlers. For example I want to link to a place using geo URI. But what if there is no system handler installed for that URI? So it's safer to link directly to Google Maps thus leaving user without choice.

Another example: there is openpgp4fpr URI scheme that points to OpenPGP key. On Android OpenKeychain handles these links but if the user doesn't have it installed they won't be able to do anything with the link. Thus I need to use https link.

No fallbacks for URI handlers means the handlers are basically useless as it's not possible to reliably build graceful degradation using JavaScript or otherwise (source).

Or course this needs to be built with privacy in mind so that random sites wouldn't be able to infer what is installed (leading to fingerprinting?).

[rugk]

Or course this needs to be built with privacy in mind so that random sites wouldn't be able to infer what is installed (leading to fingerprinting?).

Thinking about that a little more, that's actually a hard task… :thinking:

[SoniEx2]

that's the beauty of the meta tag approach. javascript (onclick handler) runs before navigation and you get no information about the resolved target.

[rugk]

well… when you have access to the resulting server/URL that is used as a fallback, you get to know that…

[SoniEx2]

okay, but:

1. you control the <a>'s in your page, you can just use an affiliate/tracking link. (TODO work out interactions with JS?)
2. you won't get all the hits. the user may have their own handlers. it's inferior to a tracking link in literally every way.

I mean, take your extension for example. isn't part of the point of it to divert the user away from the "input your mastodon handle here" webpage? your extension and this mechanism I'm suggesting both help websites lose tracking points on it. (altho, more importantly, it streamlines the UX, and blurs the barriers between fediverse instances.)

[rugk]

No, trackings links are not what I am talking about. The attacker's (trackers) idea is:

• I do want to measure whether the user is a Mastodon user/has a Mastodon application installed.

Thus they get 1 bit of tracking data out of this feature. That said, that may not be important considering what other things we have in the web platform that can be used for tracking, but hmm…

[SoniEx2]

it's an (huge) improvement over getting their whole handle ;)

[rugk]

Indeed, that's true… (and also the case for my add-on – also the disadvantage: websites may detect you have this my add-on setup. But this is off-topic, so I've opened https://github.com/rugk/mastodon-simplified-federation/issues/35 for that)

[SoniEx2]

so uh, does this have to be implemented in the browser for it to be accepted by the whatwg? or would a webextension be enough?

[domenic]

WHATWG specs are meant to be followed by browsers, indeed; we don't document what other software does, as that software is not constrained by specifications.

[SoniEx2]

that's unfortunate, because webextensions could be such a powerful mechanism for shaping the way browsers should work. indeed, some browsers even implement various parts of whatwg using webextension-like mechanisms, just shipped with the browser.