Repository navigation
Should getPorts() and requestPort() be allowed with an opaque origin? #223
Description
The web-platform-test serial/getPorts/reject_opaque_origin.html (and similar for requestPort()) seem to indicate that this call should not be allowed with an opaque origin. However, I don't see a reference to this in the spec under the "Permissions policy" or "Security considerations" sections. Does something need to be added to the spec, or is this implied in a way that I'm not seeing?
Thanks!
Activity
reillyeon commentedon Feb 27, 2026
For Chromium specifically we blocked these methods when the top-level origin is opaque because our UI can't render the string "<origin> wants to connect to a serial port" because our implementation renders an opaque origin as the empty string. Note that this only applies to opaque top-level origins because that is the origin displayed to the user. Normal sandboxed iframes are fine.
From a web security model perspective I don't think there's anything wrong with an opaque origin requesting a permission as long as that can be communicated to the user in a meaningful way. Of course that permission will always be ephemeral because opaque origins always compare as unequal.
It's possible that it would be valid to use the precursor origin when displaying an opaque origin in this context and Chromium could remove this restriction, but I'd have to check with our security experts to make sure that makes sense.
gregstoll commentedon Mar 2, 2026
Oh, thanks! That makes a lot of sense.
reillyeon commentedon Mar 2, 2026
It looks like Chrome also blocks requests for other permissions from opaque origins, but there is no mention of this in the Permissions specification. I think we probably want to move the
reject_opaque_origin.htmltest out of Web Platform Tests.Remove serial reject_opaque_origin tests (and fix a typo)
Remove serial reject_opaque_origin tests (and fix a typo) (#58409)