Open
Bug 776794
Opened 12 years ago
Updated 2 years ago
Statically enumerate permissions grantable by PContentPermissionRequest
Categories
(Core :: DOM: Core & HTML, task, P5)
Core
DOM: Core & HTML
Tracking
()
NEW
blocking-basecamp | - |
People
(Reporter: cjones, Unassigned)
References
Details
(Whiteboard: [WebAPI:P3])
Right now we send a raw string permission. Instead, we should create a union of dynamically-grantable permissions and send that.
I hope we have code at a lower level that rejects dynamic requests for telephony, e.g., but we shouldn't play with fire here.
Reporter | ||
Updated•12 years ago
|
Updated•12 years ago
|
blocking-basecamp: --- → ?
Whiteboard: [blocked-on-input]
Comment 1•12 years ago
|
||
I forget why we're blocked on input here. Can anyone enlighten me?
Updated•12 years ago
|
Assignee: nobody → jonas
blocking-basecamp: ? → +
Comment 2•12 years ago
|
||
Per cjones, needs Jonas' analysis to determine if there's work here or not.
Whiteboard: [blocked-on-input]
Sending this over to Dougt who is looking at all the prompting stuff.
Assignee: jonas → doug.turner
Comment 4•12 years ago
|
||
Is your vision that the parent process tells the child process "here are the 4 permissions you have for right now"?
Reporter | ||
Comment 5•12 years ago
|
||
From my reading of the code, it looked like PContentPermissionRequest was behaving as expected, for dynamically-grantable permissions. For example, it is behaving as expected for granting non-certified permissions like offline storage.
HOWEVER, we should not even allow the possiblity of content processes accidentally requesting permissions like sms or telephony through PContentPermissionRequest. We should be summarily denying dynamic requests for those permissions at a lower level, but it makes me nervous to even expose that interface.
Statically enumerating the grantable permissions, through an IPDL |union|, would eliminate this problem entirely.
Summary: Lock down PContentPermissionRequest → Statically enumerate permissions grantable by PContentPermissionRequest
Reporter | ||
Comment 6•12 years ago
|
||
(In reply to Doug Turner (:dougt) from comment #4)
> Is your vision that the parent process tells the child process "here are the
> 4 permissions you have for right now"?
We should be doing that somewhere else, yes.
Comment 7•12 years ago
|
||
perfectly clear now. thanks!
Updated•12 years ago
|
Whiteboard: [WebAPI:P3]
Updated•12 years ago
|
blocking-basecamp: ? → -
I don't quite understand why we want to do this. A PContentPermissionRequest *should* only have the ability to bring up a dialog to the user, which isn't really a sensitive thing if we do it for the "wrong" type of permission.
And more importantly, it *should* only have the ability to do that for permissions that are listed as PROMPT in the permissionmanager for that app, or for permissions that any app/webpage has permission to prompt about (like geolocation). Which means that a PContentPermissionRequest *should* only be able to bring up permission dialogs for things that the content process has permission to prompt about.
So it seems ok to me if someone sends a totally invalid string here.
Of course, I'm not sure if this matches what the current implementation does. But if not we should fix that either way.
Comment 10•12 years ago
|
||
unassigning things that I am not working on.
Updated•12 years ago
|
Assignee: doug.turner → nobody
Comment 11•6 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046
Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.
If you have questions, please contact :mdaly.
Priority: -- → P5
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
Comment 12•3 years ago
|
||
Type: defect → task
Keywords: feature
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•