Open Bug 1201972 Opened 9 years ago Updated 2 years ago

Page Info / Permissions tab doesn't cover iframes from different domains.

Categories

(Firefox :: Page Info Window, defect, P2)

defect

Tracking

()

Tracking Status
firefox43 --- affected

People

(Reporter: jib, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [ux-needed])

If there was a way to do this that would be great. Even if I right-click on the frame and choose "View Page Info", I still only get controls for the main site.

(From Bug 933917 comment 4)
> (In reply to Ian Nartowicz from comment #2)
> > Note that a single-domain version of about:permissions appears in a tab of
> > the page info dialog.
> 
> Hidden gem, thanks! Unfortunately, it doesn't cover iframes, which means
> using it to e.g. control camera access for https://jsfiddle.net/srn9db4h/
> doesn't work.

Note that jsfiddle.net's iframe is from fiddle.jshell.net.
See Also: → 933917
(In reply to Jan-Ivar Bruaroey [:jib] from comment #0)
> If there was a way to do this that would be great. Even if I right-click on
> the frame and choose "View Page Info", I still only get controls for the
> main site.

Right click the frame -> This Frame -> View Frame Info?

That seems to work in the jsfiddle case... Is this enough to consider this fixed? I don't think it'd be easy to make the permissions pane on the page info dialog deal with multiple subframes and maintain some kind of overview of which permissions apply to which page/uri/frame. That might just be wontfix, but I'll leave that for Florian to decide...
Component: General → Page Info Window
Flags: needinfo?(jib)
I agree. Let's try to keep feature creep out of Page Info.
So all a page has to do to thwart user-control of their access is to put that access in a sub-frame? Most users don't understand frames, so that hardly seems "users first".
Flags: needinfo?(jib)
(In reply to Jan-Ivar Bruaroey [:jib] from comment #3)
> So all a page has to do to thwart user-control of their access is to put
> that access in a sub-frame? Most users don't understand frames, so that
> hardly seems "users first".

I'm not really sure what you mean here. It's possible for the user to remove permissions using the method I mentioned in comment #1, right?

What I'm saying I don't necessarily think is a good idea is complicating the permissions UI shown in this dialog to include subframes, because it's quite conceivable you want different permissions for the different frames (esp. for ads and such), and so the number of options in the UI will multiply heavily, and be hard to navigate if it governs more than 1 frame.

That doesn't strike me as anti-"users first" - just as trying to ensure that the UI users are faced with is understandable exactly for the users who "don't understand frames".
(In reply to :Gijs Kruitbosch from comment #4)
> (In reply to Jan-Ivar Bruaroey [:jib] from comment #3)
> > So all a page has to do to thwart user-control of their access is to put
> > that access in a sub-frame? Most users don't understand frames, so that
> > hardly seems "users first".
> 
> I'm not really sure what you mean here. It's possible for the user to remove
> permissions using the method I mentioned in comment #1, right?

Right, I mean most users don't understand what a frame is, haven't the faintest clue, and are therefore not just unable to identify a frame, right click on it, select "This Frame" and "Show Only This Frame", but they don't even know that this is an avenue to explore, a detour around the immediate problem, which is that the page info drop-down says camera access is blocked, and yet the site has their camera turned on and is looking at them. See also bug 1224453 comment 1.

> What I'm saying I don't necessarily think is a good idea is complicating the
> permissions UI shown in this dialog to include subframes, because it's quite
> conceivable you want different permissions for the different frames (esp.
> for ads and such), and so the number of options in the UI will multiply
> heavily, and be hard to navigate if it governs more than 1 frame.

I don't mean to dictate a specific solution to the problem (which is that I think users expect this to be a one-stop-shop for the *entire* page), but do I note that the existing design already seems adept at reducing quite a bit of available options down to a readable and relevant display.

> That doesn't strike me as anti-"users first" - just as trying to ensure that
> the UI users are faced with is understandable exactly for the users who
> "don't understand frames".

A frame is just another part of a page in most users minds, it is not a different page. Bug 1225156 also appears to have since been filed on this.
See Also: → 1225156
I don't think complicating the UI in the Permissions tab to expose frame-related permissions would help anybody.

I've experimented with making Page Info useful for pages with frames. See this add-on: https://addons.mozilla.org/en-US/firefox/addon/view-frames/ (it exposed a tree of frames on the General tab, and double clicking on a row there reloaded the Page Info dialog to be specifically about the selected subframe).

I don't think this would help much for the specific case of device permissions, because a website abusing subframes to bypass permissions could totally insert an iframe into the document just before requesting device access, and remove it immediately after it, so it would never be visible in Page Info.


I think the problem of "As a user, I set the permission to 'Never' on a page and it keeps prompting me [because there's a frame on a different domain used to do the request]" is valid though. The way I would propose to solve it to make the WebRTC UI code checking for persistent permissions check recursively if there are "never" permissions stored for the domain of the parent frame, until we reach the top level document. Thoughts?
(In reply to Florian Quèze [:florian] [:flo] from comment #6)
> I don't think this would help much for the specific case of device
> permissions, because a website abusing subframes to bypass permissions could
> totally insert an iframe into the document just before requesting device
> access, and remove it immediately after it, so it would never be visible in
> Page Info.

But if it removes the frame then access goes with it, and it doesn't have to do that today.

> I think the problem of "As a user, I set the permission to 'Never' on a page
> and it keeps prompting me [because there's a frame on a different domain
> used to do the request]" is valid though.

Doesn't that generalize to all frame permissions? Not understanding frames seems to be the culprit.

> The way I would propose to solve
> it to make the WebRTC UI code checking for persistent permissions check
> recursively if there are "never" permissions stored for the domain of the
> parent frame, until we reach the top level document. Thoughts?

Changing how web permissions work should be informed by its own merits, not done to solve a particular UX IMHO.

That said, the MediaCapture spec recently added a requirement to double-key permissions in frames, so we might want to anticipate that change: https://github.com/w3c/mediacapture-main/pull/309

But it still doesn't tie permission to the top domain, which this would be doing. There was a reference to a "floated proposal" that did something like this, but it has not gone anywhere yet AFAIK: https://lists.w3.org/Archives/Public/public-media-capture/2016Feb/0013.html
(In reply to Jan-Ivar Bruaroey [:jib] from comment #7)

> > I think the problem of "As a user, I set the permission to 'Never' on a page
> > and it keeps prompting me [because there's a frame on a different domain
> > used to do the request]" is valid though.
> 
> Doesn't that generalize to all frame permissions? Not understanding frames
> seems to be the culprit.

Possibly. I don't know how to move forward for "all permissions", whereas for the device permissions one specifically it's easy for us to make a decision.

> > The way I would propose to solve
> > it to make the WebRTC UI code checking for persistent permissions check
> > recursively if there are "never" permissions stored for the domain of the
> > parent frame, until we reach the top level document. Thoughts?
> 
> Changing how web permissions work should be informed by its own merits, not
> done to solve a particular UX IMHO.
> 
> That said, the MediaCapture spec recently added a requirement to double-key
> permissions in frames, so we might want to anticipate that change:
> https://github.com/w3c/mediacapture-main/pull/309
> 
> But it still doesn't tie permission to the top domain, which this would be
> doing. There was a reference to a "floated proposal" that did something like
> this, but it has not gone anywhere yet AFAIK:
> https://lists.w3.org/Archives/Public/public-media-capture/2016Feb/0013.html

I'm not entirely sure of what you are proposing we implement. Would you like us to check that there's no "deny" saved permissions for the domain of the top level document before prompting or granting access automatically due to saved "allow" permissions for a frame's domain? Or something else?
Priority: -- → P2
Whiteboard: [ux-needed]
Blocks: 1335155
We might want to wontfix this once bug 1224453 is resolved.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.