feat(platform): auto-grant remote permissions to trusted product labels - #446
Open
filvecchiato wants to merge 2 commits into
Open
feat(platform): auto-grant remote permissions to trusted product labels#446filvecchiato wants to merge 2 commits into
filvecchiato wants to merge 2 commits into
Conversation
Product-id TLDs split from the narrower dotNS navigation list so .test is a product scope without bypassing the outbound domain grant.
valentinfernandez1
approved these changes
Aug 20, 2026
| > This RFC below specifies batched remote-permission requests (`remote_permission` taking a `Vec<RemotePermission>`). That part has been rolled back: `remote_permission` again accepts a single `RemotePermission`. After the initial implementation it became clear that the batched API is hard to justify to the end user — a single prompt covering several distinct grants produces bad UX (the user cannot reason about or selectively approve what they are consenting to). The rest of this RFC (device permissions, lifecycle, persistence, implicit triggering) still stands; only the batching of remote permissions is reverted. | ||
|
|
||
| > **NOTE (2026-08-18): first-party products hold remote permissions without a prompt.** | ||
| > The lifecycle below specifies that every permission is prompted on first request. That holds for device permissions, identity disclosure and cross-product account access, but not for remote permissions requested by a product on the trusted list in `truapi_platform::REMOTE_PERMISSION_TRUSTED_LABELS`. Those products hold every `RemotePermission` variant — domain access, WebRTC, chain submit, preimage submit, statement submit — without a prompt, because they ship alongside the host and their remote access belongs to the host's own trust boundary. The grant is not persisted, so a `Denied` written through the permission administration surface still outranks it and revokes the access; clearing that denial restores the auto-grant. An empty `Remote` domain bundle remains denied, since it grants nothing. The list holds bare product labels with no TLD, so one entry covers the product on every network. This is an interim mechanism: the allowlist is intended to move into the product manifest, per RFC 0024. |
Collaborator
There was a problem hiding this comment.
CI is likely failing because there is a change on the RFC but no spec change. We can either live with this or move this note somewhere else
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #434.
REMOTE_PERMISSION_TRUSTED_LABELS(peopl,dim2,stash) holds everyRemotePermissionwithout a prompt; nothing is persisted, and a storedDeniedstill revokes it.PRODUCT_ID_TLDSaddstestfor product ids only. The dotNS navigation list staysdot/paseo, so a.testhost remains external and keeps consuming a domain grant.