@thomas.duboucher: Thanks for the report!!

Could you please help us with the sample file where you're seeing this issue to check from our end.

Thanks!!

thomas.duboucher@  sandeepkumars@ If I remember correctly, chrome never supported ndef records with "text/html" mime types.

https://cs.chromium.org/chromium/src/chrome/android/java/AndroidManifest.xml?q=androidman&sq=package:chromium&l=250

Looks like a feature request, not a regression or a bug.

If it was never supported in Chromium in the first place, then it is
indeed a feature request.

Sorry for the unnecessary noise.

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Marking as Feature request as per comment #3 and adding appropriate component for further input's.

Thanks!!

I don't think HTML is an appropriate component for considering this priority.
Forwarding to Blink>NFC, which may have better idea of this.

Can you please share the use case you wanted this for, so we can fit it into our prioritization system? 

The idea/use case behind this was for a Type 4 NFC Tag to serve a
webpage showing data from the tag itself.

My current workaround is to return instead an URL where the content is
encoded in the fragment identifier of the URL, to a webpage whose
javascript would decode it. The drawback is that it requires network
access, to setup a web server and may have privacy implications.

Another workaround would be to store an URL to e.g. an instant app in
the first record and the data in the next records.

Note that it is not possible to simply return an URL, because the data
to be shown is stored on the tag itself, and it is not feasible to
expect a passive NFC Tag to be synchronized with a server.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

This is not really a WebNFC thing but an Android intent handling thing. Reassigning to the general Clank component.

content: URIs are the normal way of passing around local web content, but that wouldn't be possible off of a NFC tag.

+rsesek to comment on whether accepting data: URIs would be dangerous for Chrome.  I'm not aware of any new attack vectors that would open.

With that said even if it is safe, I don't know if we want to support this and whether it would end up giving us more headaches as changing our intent system often triggers other problems to arise.

Chrome doesn't allow pages to navigate to top-level data: URIs (see  issue 594215 ). This isn't quite the same scenario, but I think the motivations behind that change (namely user confusion regarding the data: scheme and its use as a common spoofing vector) apply here.

Thanks for the security input.  Going to close this out then as I don't think this usecase is pressing enough to justify a change in that position.

Agreed with comments #14 and #15. We don't allow data URLs to be loaded from the web, so not supporting them from NFC tags sounds consistent.