morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #3759] [Feature] Passively inspect an explicitly authorized browser iframe through CDP #1463

New issue

Open

opened 2026-10-16 21:05:40 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-16 21:05:40 +00:00

Owner

Originally created by @jrbest2014-maker on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3759

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

Process capture or runtime observation

Current limitation

REA can passively inspect a user-owned Chrome page through CDP, but it currently excludes iframe targets because target discovery and authorization accept only page targets. In a site where the game is rendered inside a separate HTTPS iframe, the page can be identified while the game UI and its scripts remain unavailable to REA.

I observed this on a browser page I operate: the main page was on https://d2jvokyu2sg5e1.cloudfront.net and a separate iframe target appeared on https://d24lpvhb78ilhm.cloudfront.net. A different iframe appeared to be a CAPTCHA and must remain out of scope. These observations identify a possible use case; they do not establish ownership of the site, authorization to inspect its service, or how its server works.

Use cases

An analyst inspecting a page they are authorized to examine needs to passively capture the UI and scripts of one embedded application frame, while excluding unrelated frames such as CAPTCHA providers.

Desired outcome and success criteria

Please discuss whether REA should support passive CDP inspection of one explicitly selected iframe target, in addition to page targets.

If approved, the workflow should:

require an exact caller-approved HTTPS origin for the iframe;
verify and report the iframe's relationship to the selected page without exposing URL paths, query strings, fragments, or credentials unnecessarily;
capture only the selected frame and approved origin, with existing Evidence provenance, completeness, and limitations;
keep unrelated origins, CAPTCHA frames, and unapproved frames excluded;
remain passive: no clicks, navigation, script evaluation, form submission, game actions, or automation.

If the origin, frame relationship, or authorization cannot be verified, the operation should fail closed and report the unknowns. This request is for maintainer scope discussion, not a request to bypass site controls or determine server-side randomness.

The change must not regress access to REA's public repository, documentation, or existing browser-observation workflows. For external targets, REA must use only the caller-selected browser session and explicitly approved origins; if access or authorization is unavailable, it must report the limitation rather than bypass controls.

Expected interaction with targets

Read existing files or captured data, Launch or attach to a process

Target and scope details (optional)

Target type: user-owned Chrome-family browser page inspected through a loopback CDP endpoint. The example page embeds a game-like application in an HTTPS iframe; another iframe appeared to belong to a CAPTCHA provider and is explicitly excluded.

Requested effects: attach-only, passive reads of frame metadata and—only after exact-origin approval—frame UI/script evidence. No target execution, clicks, navigation, authentication handling, CAPTCHA inspection, betting, or game-round automation.

The example host is included only to explain the observed limitation. I cannot establish site ownership or authorization from the browser session alone; please advise what scope and verification would be acceptable before any integration or real-target testing.

Verification available so far

Idea only; I need help defining checks

Verification details (optional)

No implementation or real-target verification is requested at this stage. Possible checks for an approved design include tests with synthetic same-origin, foreign-origin, about:blank, and CAPTCHA-like frames, verifying exact-origin filtering, parent-frame identity, redaction, coverage, and fail-closed behavior. Any live-provider test should use a self-owned or appropriately authorized sample and be separately scoped.

Alternatives considered

No response

Possible direction

No response

References

REA browser observation documentation: https://github.com/morluto/rea/blob/main/docs/browser-observation.md
Contribution scope: https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope

Originally created by @jrbest2014-maker on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3759 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Process capture or runtime observation ### Current limitation REA can passively inspect a user-owned Chrome page through CDP, but it currently excludes iframe targets because target discovery and authorization accept only page targets. In a site where the game is rendered inside a separate HTTPS iframe, the page can be identified while the game UI and its scripts remain unavailable to REA. I observed this on a browser page I operate: the main page was on https://d2jvokyu2sg5e1.cloudfront.net and a separate iframe target appeared on https://d24lpvhb78ilhm.cloudfront.net. A different iframe appeared to be a CAPTCHA and must remain out of scope. These observations identify a possible use case; they do not establish ownership of the site, authorization to inspect its service, or how its server works. ### Use cases An analyst inspecting a page they are authorized to examine needs to passively capture the UI and scripts of one embedded application frame, while excluding unrelated frames such as CAPTCHA providers. ### Desired outcome and success criteria Please discuss whether REA should support passive CDP inspection of one explicitly selected iframe target, in addition to page targets. If approved, the workflow should: - require an exact caller-approved HTTPS origin for the iframe; - verify and report the iframe's relationship to the selected page without exposing URL paths, query strings, fragments, or credentials unnecessarily; - capture only the selected frame and approved origin, with existing Evidence provenance, completeness, and limitations; - keep unrelated origins, CAPTCHA frames, and unapproved frames excluded; - remain passive: no clicks, navigation, script evaluation, form submission, game actions, or automation. If the origin, frame relationship, or authorization cannot be verified, the operation should fail closed and report the unknowns. This request is for maintainer scope discussion, not a request to bypass site controls or determine server-side randomness. The change must not regress access to REA's public repository, documentation, or existing browser-observation workflows. For external targets, REA must use only the caller-selected browser session and explicitly approved origins; if access or authorization is unavailable, it must report the limitation rather than bypass controls. ### Expected interaction with targets Read existing files or captured data, Launch or attach to a process ### Target and scope details (optional) Target type: user-owned Chrome-family browser page inspected through a loopback CDP endpoint. The example page embeds a game-like application in an HTTPS iframe; another iframe appeared to belong to a CAPTCHA provider and is explicitly excluded. Requested effects: attach-only, passive reads of frame metadata and—only after exact-origin approval—frame UI/script evidence. No target execution, clicks, navigation, authentication handling, CAPTCHA inspection, betting, or game-round automation. The example host is included only to explain the observed limitation. I cannot establish site ownership or authorization from the browser session alone; please advise what scope and verification would be acceptable before any integration or real-target testing. ### Verification available so far Idea only; I need help defining checks ### Verification details (optional) No implementation or real-target verification is requested at this stage. Possible checks for an approved design include tests with synthetic same-origin, foreign-origin, about:blank, and CAPTCHA-like frames, verifying exact-origin filtering, parent-frame identity, redaction, coverage, and fail-closed behavior. Any live-provider test should use a self-owned or appropriately authorized sample and be separately scoped. ### Alternatives considered _No response_ ### Possible direction _No response_ ### References REA browser observation documentation: https://github.com/morluto/rea/blob/main/docs/browser-observation.md Contribution scope: https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope

bsakaguchi added the

triage

enhancement

labels

2026-10-16 21:05:40 +00:00

bsakaguchi commented

2026-10-16 21:05:42 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 15, 2026):

Supporting an explicitly selected iframe target alongside page targets fills a real gap for analysts who can see the outer page but not the embedded app. The key strengths of this proposal are the exact-origin approval gate, fail-closed reporting when origin/frame relationship cannot be verified, and the strict passive scope (no clicks, no evaluation, no automation). One design point worth clarifying early: how the caller selects the iframe in a multi-frame page — an exact origin string is a good filter, but if two frames share the same origin you may need a frame-id/ordinal to disambiguate. Keeping CAPTCHA and other unrelated frames excluded by default and requiring explicit opt-in for each origin matches the existing browser-observation security model.

@XinwangTao commented on GitHub (Oct 15, 2026): Supporting an explicitly selected iframe target alongside page targets fills a real gap for analysts who can see the outer page but not the embedded app. The key strengths of this proposal are the exact-origin approval gate, fail-closed reporting when origin/frame relationship cannot be verified, and the strict passive scope (no clicks, no evaluation, no automation). One design point worth clarifying early: how the caller selects the iframe in a multi-frame page — an exact origin string is a good filter, but if two frames share the same origin you may need a frame-id/ordinal to disambiguate. Keeping CAPTCHA and other unrelated frames excluded by default and requiring explicit opt-in for each origin matches the existing browser-observation security model.

bsakaguchi referenced this issue

2026-10-17 21:11:36 +00:00

[PR #1463] [MERGED] fix(skills): expose authored skill to repository discovery #2903

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-10-31 00:30:53 +00:00