yfriedman, do you know who might be a good person to handle this bug?

No ideally without starting to trawl through git logs. Perhaps Michal does as perhaps this changed related to nearby/physical web?

Also +Ted in case he's familiar with changes here.

Totally unrelated to physical web.  We never touched NFC.

+blundell/reillyg for services/devices/nfc

I believe this was originally authored here (by folk from intel):
https://codereview.chromium.org/1486043002

Moved to services here:
https://codereview.chromium.org/2894373002

I'm not immediately familiar with the internals of the NFC processing as the reviews I did were more about the integrations with the Android framework and not into the Chrome layers.  Hopefully one of the two I added will be more knowledgeable about that.

Is this related to the (unshipped) WebNFC API or handling of NFC tags which contain URLs and thus trigger navigation? services/device/nfc is related to the former only.

It won't be anything unshipped.

Ahh...I just assumed it had to be something recent but completely ignored that Chrome accepts incoming NFC intents:

https://cs.chromium.org/chromium/src/chrome/android/java/AndroidManifest.xml?l=249

+mariakhomenko for external intent knowledge.

To my awareness, incoming NFC intents are treated no differently than incoming VIEW intents.  I thought gesture calculation was done here:

https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/IntentHandler.java?l=394

In particular a gesture token would have needed to previously be generated by Chrome and attached to the intent:

https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/externalnav/IntentWithGesturesHandler.java?q=getUserGestureAndClear&dr=CSs&l=105

That being said, my knowledge of this is old as well and there have been a fair number of changes to how we process incoming intents to deal with things like instant apps and custom tabs.  I don't know if there are other places that would change the gesture bit.

Are we sure it's an M-61 regression? In my understanding, we dispatch to external applications on incoming intents including redirects. By design. Without any gesture tokens.

Is the dispatch to native application the issue here?

(+qinmin@, who might have some insight)

I presume the schemes that can be used in NFC tags are limited to http://, https:// and maybe a few more (they wouldn't have had to use this approach if they could just put the intent:// in the NFC tag directly).

AIUI, previously, the contents of an http:// page couldn't navigate to intent:// without a user gesture.

This does seem like a security regression, since now an NFC tag can send data and/or trigger actions with for many(any?) potentially exploitable native apps.

The internal code for handling VIEW vs NDEF_DISCOVERED intents appears to be identical, so as Maria said above, I think this is likely not a regression nor any different than if Chrome received an Intent from any other app.

That being said, NDEF_DISCOVERED is more restrictive on the types of implicit intents it can receive:
https://cs.chromium.org/chromium/src/chrome/android/java/AndroidManifest.xml?l=250

            <intent-filter>
                <action android:name="android.nfc.action.NDEF_DISCOVERED" />
                <category android:name="android.intent.category.DEFAULT" />
                <data android:scheme="http" />
                <data android:scheme="https" />
            </intent-filter>

So it will only accept http, and https.

VIEW intents have a broader accepted filter:
https://cs.chromium.org/chromium/src/chrome/android/java/AndroidManifest.xml?l=196

            <intent-filter>
                <action android:name="android.intent.action.VIEW" />
                <category android:name="android.intent.category.DEFAULT" />
                <category android:name="android.intent.category.BROWSABLE" />
                {% if channel in ['stable', 'default'] %}<data android:scheme="googlechrome" />{% endif %}
                <data android:scheme="http" />
                <data android:scheme="https" />
                <data android:scheme="about" />
                <data android:scheme="content" />
                <data android:scheme="javascript" />
                <data android:mimeType="text/html"/>
                <data android:mimeType="text/plain"/>
                <data android:mimeType="application/xhtml+xml"/>
            </intent-filter>

So, it supports about, content, and javascript where NFC does not.  Chrome does not accept incoming intent:// URLs as those are handled by the Android framework.

If they're relying on a redirect from http, https -> intent://, then this is likely no different then receiving a VIEW intent from any other app on Android.  We do not process incoming intents if the screen is off either, so the phone needs to be on and unlocked for this to work.

If we want to restrict the capability of NFC intents, this is likely a change in behavior and not a regression fix.

tedchoc@ -- since you are driving this issue and know a lot more about it than me (current security sheriff), would you mind if I assign it to you? Please feel free to unassign it, if you like. thanks.

I think we need some security input on whether NFC needs to be treated differently from VIEW intents sent to Chrome by other applications.

Is there a difference from security point of view on when a user clicks on a link in, say, their messenger app and get redirected to an installed application on their device vs them scanning an NFC tag and the same thing happening.

We technically could block NFC intents from dispatching to native apps, just want to make sure there's really a difference in these two cases from security POV.

Assigning to rsesek@ for security input.  To the best of Maria's and my understanding, this is how NFC has always worked on Android.  We treat it no differently from an incoming VIEW intent and is granted the same level of abilities.

If we want to special case NFC, then this is a request for a change in behavior more so than a regression in anything existing.

rsesek: Uh oh! This issue still open and hasn't been updated in the last 17 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

rsesek: Uh oh! This issue still open and hasn't been updated in the last 32 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

Woops, sorry for missing this over the holidays.

I think treating NFC intents the same as VIEW is likely the right thing to do, especially if #13 is accurate and we only process NFC if the device is unlocked. Just checking: do we also limit NFC -> http(s) -> intent:// to CATEGORY_BROWSABLE?

Yes, all intents we dispatch for intent:// URLs have category browsable included in the intent.

Ok, then back to tedchoc@ now that we have an answer. I guess there's nothing to do here, though?

Sounds like this is WAI.