Since this has been public for 5 years, marking this low severity.

I understand the main problem with Firefox for Android's restriction is that '#' can legitimately appear in extension codes following the phone number proper.  A safe example desired to work is <a href="tel:+12505555555;1234#">Example</a>.

The implementation work to add a restriction in Chrome should be easy, the main blocker is to get a consensus about what exact one we should go with.

The "Magic" dialer codes all seem to start with * or #, which might be one simple way they could be distinguished from dialing use cases that are more likely to be legitimately used?

To provide some context on why this is useful, we have a web page of different phone numbers that you can call to join a meeting by phone. This includes an international phone number + 13 digit PIN which is very tedious to input (and prone to error). To help alleviate this pain point, we would like users to be able to simply tap on the phone number for their country that would open the dialer app and pass through the <phone number>,<pin># so that the user doesn't need to manually type anything in. For us, it is important that at least this functionality is maintained even if other abuse prevention mechanisms are put into place. Thanks!

Even though this requires explicit user interaction, the end result is so bad that I think we should think of this as medium-severity.

+some Android folks since aelias@ has left Chromium. WDYT about restricting the digits that can appear in tel:// links on Android? Should we move towards parity with iOS here, or Firefox, or other browser on Android?

Do we know if anyone besides Firefox does anything for this? What do they do?

IMO, I am less concerned with having this be standard across browsers and more concerned with exposing our users to potential exploits. On the other hand, I don't want to break useful legit phone numbers by blocking all */# numbers.

My gut feeling based on looking at the linked lists is to go with checking that a number has any two of (* or #) anywhere in the number and if so, block it. Feels weird and hacky, but honestly so is the rest of our intent handling code anyway.

Another option is to log how often dispatched tel: links contains * or #, if the counts are super low today, we could just block all outright, knowing we affect very few people. But getting that data would take awhile.

Thouhts?

This issue went to the working group: https://github.com/whatwg/html/issues/2875

It seems the iOS and Firefox are blocking URIs with # and *, which has a functional impact, but given that it sounds like Chrome's the straggler here, the compatibility implications are probably not so bad.

Firefox does this:

    static boolean isUriSafeForScheme(Uri aUri) {
        //  Bug 794034  - We don't want to pass MWI or USSD codes to the
        // dialer, and ensure the Uri class doesn't parse a URI
        // containing a fragment ('#')
        final String scheme = aUri.getScheme();
        if ("tel".equals(scheme) || "sms".equals(scheme)) {
            final String number = aUri.getSchemeSpecificPart();
            if (number.contains("#") || number.contains("*") || aUri.getFragment() != null) {
                return false;
            }
        }
        return true;
    }

If we want to understand the impact, we could add a UKM UseCounter for tel links with '#' or '*' and then look at the URLs we get back.  I suspect we would break some legitimate usage that somebody somewhere will care a lot about, and not sure we'd actually protect any malicious usage (since we haven't gotten any reports AFAIK). Given how little Firefox is used on mobile, I don't think we can count on their behavior being meaningful from a web compat perspective.

Matching iOS would be a more compelling argument, but it sounds like on iOS there's maybe just one additional tap required to dial (not blocked completely)?

I'm somewhat indifferent just to weigh my opinion.  I agree with Maria on the hacky option likely being the best/least invasive (i.e. the one we could probably add very quickly with no risk).

My larger concern is handling the rejected case.  Are we going to need to show a message?  A toast?  Do we need to show a snackbar or infobar or something allowing them to proceed anyway?  Is silently ignoring it ok (I wouldn't think so).

Dialers should be able to distinguish external browser intents by looking for Intent.CATEGORY_BROWSABLE.  In cases where a dialer allows incoming intents to trigger potentially dangerous setup/debug code paths, I'm not going to give a ton of sympathy.

I'd be fine to add some bit of sanity checking to try and help other devs, but I personally wouldn't feel the need to add a ton of logging and drag this process out.

Testing this on Android 8.1.0, it appears that when following a "tel:" link anything after and including the first '#' is stripped when it arrives at the dialer, and the dialer does not automatically perform the call (this puts it in line with the iOS dialing behavior of showing a confirmation popup).

This would still allow codes that include only '*' and numbers, but I don't know of any potentially harmful ones that never include a '#' (which means a user would have to additionally add the '#' and anything after it for it to work).

If we wanted to explicitly stop these from opening the dialer at all on the Chrome side of things, we could maybe add a check to ExternalProtocolHandler::LaunchUrl() to block URLs that have the 'tel:' scheme and start with some form of "*" or "#" or "//*" or "//#".

We might want to also put that behind a feature flag in case we needed to disable the blocking if there's some unexpected breakage, but the fact that any input after the first '#' is stripped anyway seems like it is already breaking existing desired flows (such as the one mentioned in #4).

cthomp - can we find an owner for this until it is driven to completion?

cthomp: Uh oh! This issue still open and hasn't been updated in the last 40 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

cthomp: Uh oh! This issue still open and hasn't been updated in the last 54 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Given that links with # don't work on iOS, Firefox and Android 8.1+, it sounds reasonable to me to drop it from Chrome. Can we do that? (I'm happy to approve an ExternalProtocolHandler CL that does that)

Since we know of some legitimate use cases with # in the number somewhere, I think dropping that will be subject to the blink breaking change process (https://www.chromium.org/blink/removing-features).

But AFAIK we know of no legitimate use case for numbers that start with #, so just breaking those can probably be considered "trivial" IMHO and something we just land and listen for any feedback on.