Dialog added to ask permissions for webpage #11034
Conversation
|
@vkjr do we give permissions per domain? or for webview and all domains? I would deny any permissions for webview for now |
|
@flexsurfer, as far as I understood WebView requests for permissions every time when page tries to invoke related js code, for example call |
Jenkins BuildsClick to see older builds (24)
|
|
@0kok0, what do you think, should we allow camera/mic access at all? |
|
@vkjr if we add camera/mic permission, we have to take care protecting against permission sniffing/bypass/spoofing/... in webview. As a user, i would probably expect it to work for example when using some webrtc app, but I would be positively surprised by a message like: If we, by default, disallow it globally, i'd call it a security feature (tor browser does that). |
|
Disable by default makes sense. It would add a feature in cc @errorists |
|
@hesterbruikman, maybe switch like |
|
I believe it should always ask you for a permission without a permanent switch. Maybe whitelisting domains, but even then I'd have a time limit like
|
There's a misunderstanding. The settings switch is to enable a popup as sketched by @errorists in the first place.
Definitely. The settings switch is supposed to ask the user for "permission for being asked for permission" so to say. The default would just be to block websites that request camera/mic access to protect user privacy as like in e.g. the Tor Browser. |
| @@ -102,6 +105,26 @@ | |||
| :accessibility-label :modal-chat-button} | |||
| [icons/icon :main-icons/message]]])) | |||
|
|
|||
| (defn show-access-request [resources on-allow on-deny] | |||
| (utils/show-confirmation {:title (i18n/label :t/permission-request) | |||
There was a problem hiding this comment.
Consider that window.title can be reset, spoofed, might not be unique and can be reused by other pages if the permission is persistent, same goes window.location.
|
@0kok0 Can you articulate the privacy risk in case camera use is not blocked by default? i.e. the risk of having |
Securitywise, disabling permission requests completely yields a different level of security compared to asking for permission. There's no permission-request-bypass, if permissions are disabled. In a broader sense, the issue boils down to the idea that asking a permission is not a neutral act, but setting an agenda and attracting/distracting the users attention, not necessarily for a good reason. There's an extreme present with websites/services asking for permission to access my location. I, as a user, would like to not be bothered by any pizza delivery if they can access my GPS while I'm visiting their site. It's not that bad with camera access, but similar. This is especially relevant for a privacy browser, which might not be my default to do online shopping, but the browser I use to interact with Dapps. As a privacy affine user, I'd the browser that handles my tokens not to ask me for potentially invasive permissions. I don't like the idea of the browser just not reacting and leaving a part of the site empty when the permission request is suppressed. I'd add a small popup, informing users "a request to access your camera by this site has been blocked". Also I want to make sure, I'm not arguing for rejecting all camera access requests, I'm asking to give the user the option to make an informed decision about the default behavior and their UX, if their status browser is supposed to act as every other browser or as something that passively keeps requests, popups and the like away from them. |
|
So per additional discussion with @hesterbruikman this PR goes following way:
|
vkjr
changed the title
vkjr
force-pushed
the
fix/webview_behavior
branch
from
fbdaa17
to
196579b
Compare
vkjr
force-pushed
the
fix/webview_behavior
branch
2 times, most recently
from
eeb26a8
to
001c97b
Compare
vkjr
changed the title
98% of end-end tests have passedFailed tests (2)Click to expand
Passed tests (97)Click to expand
|
| @@ -103,6 +103,12 @@ | |||
| :preview-privacy? (boolean private?) | |||
| {}))) | |||
|
|
|||
| (fx/defn switch-webview-permission-requests? | |||
| [{:keys [db] :as cofx} enabled?] | |||
| (multiaccounts.update/multiaccount-update cofx | |||
There was a problem hiding this comment.
can we move cofx to the next line, that would help to keep it in 80 chars range
| :style styles/blocked-access-button | ||
| :on-press (fn [] | ||
| (components.permissions/request-permissions | ||
| {:permissions (map #(get resources-to-permissions-map %) resources) |
There was a problem hiding this comment.
resources-to-permissions-map is never nil so it safe to go with (map resources-to-permissions-map resources)
| :active webview-allow-permission-requests? | ||
| :accessory :switch | ||
| :subtitle (i18n/label :t/webview-camera-permission-requests-subtitle) | ||
| :subtitle-max-lines 2 |
|
@vkjr what about IOS? |
|
@churik, thanks, you are absolutely right! It won't be implemented separately since on ios there is on permission requests from webview. So we definitely need to hide it from settings! |
|
@churik, it is hidden now for ios |
|
Tested on Android 10, Android 8:
|
vkjr
force-pushed
the
fix/webview_behavior
branch
from
dc3bb64
to
a555e44
Compare
Signed-off-by: Volodymyr Kozieiev <vkjr.sp@gmail.com>
vkjr
force-pushed
the
fix/webview_behavior
branch
from
a555e44
to
a955200
Compare
|
Awesome work @vkjr |
fixes #TBD
Summary
Followup on #11028
On privacy and security page new toggle added "Webview camera permissions request".
When it DISABLED and some page wants camera access - user gets notification that access was blocked.
When it ENABLED and some page wants camera access - user asked if he wants to allow access.
Platforms
Areas that maybe impacted
Web browsing
Steps to test
Test 1
webview camera permissions requesttoggle should be disabled)Test 2
Privacy and Securitypage, enablewebview camera permission requesttoggleTest 3
status: wip