Allow tel: URIs

[jwdomb]

Shouldn't tel: links be allowed? Relevant standard: http://tools.ietf.org/html/rfc3966

I'm submitting this request because I would like to use tel: links within Github wikis.

[verdy-p]

mailto: links generally do not generate additional costs when it is used in web applications. However tel: links may perform call immediately (if the user has not configured its browser to restrict them or at least ask for confimation before calling) which may turn to be extremely expensive (imagine you insert some INMARSAT international call, or some numbers to national value-added services: you're taxed immediately a few euros or dollars, some times as much as a dozen one and then pay for the first seconds even if you don't hear anything, and then pay for each minute; on mobile phones you pay also an additional connection tax, and if you are currently abroad, you will also pay additional roaming taxes from your mobile phone operator).

"tel:" URI also rarely work natively in browsers (there's no installed plugin to support the call) but would likely work immediately on mobile phones in their browser (if it is accidentally misconfigured and left without sking prior authorization or not transfered to another safe application handing the "tel:" protocol. On PC, calls may be taken for example by a Skype plugin (or other similar local Windows app). That application may be initiating the call immediately, or you could be tricked by some interface to confirm it unvoluntarily and Skype will charge you for the call.

Following the link accidentally while reading a spam email could happen.

With email links, you cannot send it directly without filling the subject line and some content, or to add or change the recipients (the mail agent will also require you press the "Send" button and should let you add other content (such as a personal signature) or modify the proposed text, or add some digital signature or encyrption, or insert some attachements. I've never seen any email app sending an email directly without exposing the complete input form (that "mailto:" URIs are almost never prefilling completely).

If mailto links are restricted to contain only a single recipient email address (most common cases) and the format of the email address is checked, an empty email input form will be opened but you'll still need to compose the message. It is easy to cancel this input form.

On the opposite a phone number is directly usable "as is" without additional information to initiate a call directly by following displayed in an HTML contact list.

I think that applications will be safer if they don't use phone URIs, but just display a number that can selected-copy-pasted into the phone app with explicit user interactions.

[jwdomb]

Thanks for the input, @verdy-p. Perhaps I used an overzealous comparison with mailto: URIs. I've revised my pull request accordingly.

Each of the concerns you mentioned is covered in the RFC. It seems like your main objections could be summarized in three statements:

1. Some user agents may dial the phone number immediately, presenting various concerns
2. Some user agents may not do anything with the link
3. Phone numbers are usable "as is"

Covering each in turn:

1. I agree this presents a theoretical hazard, though it seems quite minuscule as a practical concern:

   a. The RFC expects user agents to prompt users before dialing a phone number (similar to how they do with mailto: links), and, indeed, the vast majority of those in popular use—especially if you consider market share—apparently do.

   b. One could accidentally click on all sorts of HTML anchors that do something unintended and bad. One doesn't even need to click a link: consider cross-site request forgeries. Thus, this doesn't present a reasonable objection to supporting the protocol.

2. This is not a reason to reject supporting the scheme. Some user agents may not support mailto: or https: schemes for that matter. As in the previous item, the vast majority of user agents in popular use do support the protocol, many of them doing something relevant outside of the context of mobile phones.
3. This is also not a reason to reject supporting the scheme. Any HTML anchor with an href could be usable "as is" provided the anchor's href is shown.

[verdy-p]

Not all users agents will do this, notably on smartphones, where you can directly click on a contact from the contact list to perform an immediate call. Contact lists are generally managed in a separate application than the telephony application which is launched automatically (though there should be a specific permission given by the telephony app to accept immediate calls from the contact list application. There are lot of contact list applications.

As well my comment was in a specific context where the pattern is to be recognized in a "safe" tiidy form of HTML, intended to be rendered actually not in a full browser, but in limited apps that will not perform these checks. The purpose of this module is effectively to remove potentially hazardous behaviours (and that's why it also eliminates elements such as "script" or many active HTML attributes.

"Mailto:" links cannot be used to send a mail directly (it will not be enough to just feed the recipient address. And the purpose of this module is to make sure that the reduced subset of HTML will be safe in all contexts, including in chats or wikis, and only allow safe contents that will also not impact the rest of the webpage where the HTML subset will be inserted.

Just consider MediaWii for example: it allows mailto links but no tel in external links. But some wikis are even more restrictive and will only allow contact their users by a contact form hosted on the same site, and redirecting it to the effective (hidden) email address (so mailto links are also rejected).

Yes there are also privacy concerns with mailto (just like tel) but these privacy issues exist independantly of the capability of creating a direct link. And there are now many URI schemes created daily for various apps (Windows 10 itself comes now with many application specific schemes, with almost always one (or more) for each target application. The same is true for schemes targetting Android or iOS apps from a webpage: the opssibility of launching local apps.from a local web browser is in fact not really performed by the browser, but by the target application (or browser plugin)

2016-09-10 4:00 GMT+02:00 Joseph Dombroski notifications@github.com:

Thanks for the input, @verdy-p https://github.com/verdy-p. Perhaps I used an overzealous comparison with mailto: URIs. I've revised my pull request accordingly.

Each of the concerns you mentioned is covered in the RFC. It seems like your main objections could be summarized in three statements:

1. Some user agents may dial the phone number immediately, presenting various concerns
2. Some user agents may not do anything with the link
3. Phone numbers are usable "as is"

Covering each in turn:

1.

I agree this presents a theoretical hazard, though it seems quite minuscule as a practical concern:

a. The RFC expects user agents to prompt users before dialing a phone number (similar to how they do with mailto: links), and, indeed, the vast majority of those in popular use—especially if you consider market share—apparently do https://css-tricks.com/the-current-state-of-telephone-links/.

b. One could accidentally click on all sorts of HTML anchors that do something unintended and bad. One doesn't even need to click a link: consider cross-site request forgeries https://en.wikipedia.org/wiki/Cross-site_request_forgery. Thus, this doesn't present a reasonable objection to supporting the protocol. 2.

This is not a reason to reject supporting the protocol. Some user agents may not support mailto: or https: protocols for that matter. As in the previous item, the vast majority of user agents in popular use do support the protocol, many of them doing something relevant outside of the context of mobile phones. 3.

This is also not a reason to reject supporting the protocol. Any HTML anchor with an href could be usable "as is" provided the anchor's href is shown.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jch/html-pipeline/pull/254#issuecomment-246081372, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUqG_eZiq0Ir9U0p9Zw1OFyGFumV8pcks5qog8mgaJpZM4IWvVS .