Browser-laptop: protocol handler permission request needs a friendlier message

Created on 18 Aug 2016  Â·  23Comments  Â·  Source: brave/browser-laptop

Did you search for similar issues before submitting this one?
Yes

Describe the issue you encountered:
When visiting inbox.google.com got a prompt "Allow ⁚https://inbox.google.com⁩ to ⁚register a protocol handler⁩?" but no helpful text as to why I should say yes or no

Expected behavior:
Brave should provide helpful text as to what this allows if I say yes (not just for this site, but any)

  • Platform (Win7, 8, 10? macOS? Linux distro?):
    Win 8.1 x64
  • Brave Version:
    v0.11.5 Dev Channel
  • Steps to reproduce:

    1. Visit inbox.google.com

accessibility addressed-with-brave-core design wontfix

Most helpful comment

I just got this popup and ended up here after googling what it is. I still have no idea whether I should say yes or no, so count me in the "Please add a friendlier message" group.

All 23 comments

same for bitcoin:. iirc this will require changes to Electron to emit the type of protocol being handled.

@bridiver Can we get electron to provide a handler lookup table for these and provide users with intelligible alerts?

I would think that it's possible, but @bbondy is more familiar with how the protocol handler works

Having a friendlier message would be super nice :smile:

Also related: https://github.com/brave/browser-laptop/issues/2461

I think electron permissions just has the type of permission and no other data, I'm sure we can change how it works though.

I thought of a way to do this, we could send a different permission request only for the common protocols we encounter, mailto:, webcal: bitcoin:

chrome has a completely different path for protocol registration, but we could add an ExternalProtocolRegistrationHelper as a WebContentsUserData and set the protocol url in HandleExternalProtocolInUI. We could retrieve the ExternalProtocolRegistrationHelper in BravePermissionManager::SetPermissionRequestHandler if PermissionType == PROTOCOL_REGISTRATION and send the url to the node callback.

I just got this popup and ended up here after googling what it is. I still have no idea whether I should say yes or no, so count me in the "Please add a friendlier message" group.

Allow https://www.example.com to register a protocol handler? [Deny] [Allow]

The current string has multiple issues:

  • What is the protocol? Message fails to identify the protocol. Potential security issue.
  • Doesn’t explain what a “protocol handler” is and it’s implications.
  • URLs must always be enclosed in quotes for security purposes (message overwrite/escape)
  • Long URLs will break it (especially on smaller screens)

Suggestion that addresses all but the last issue:

“https://www.example.com” wants to be your default webapp for opening “irc:” links. [Cancel] [Set New Default]

You can get away with replacing the URL with “The current website” when the requesting URL exactly matches the address field of the current tab. Otherwise use the URL or the origin domain (but watch out for overly long URLs). This applies to all similar toolbars and UIs, by the by.

The "user-friendly" police is requesting a fix before 1.0 release... : )

So should I say "yes" or "no"? What are the repercussions for saying no?

@drozzy apologies that none of us have responded to you yet

Your yes/no decision will be recorded in Preferences, under the security tab:
screen shot 2017-03-02 at 3 19 42 pm

I'll assign a loose milestone to this (we'll need to go through 1.0 and post 1.0 items soon)

@bsclifton Perhaps I wasn't clear. I mean what is it actually asking? You showed me that it will set "Always allow" option - but what does that option do?

E.g.: Protocol registration for gmail allows gmail to be used as your primary email client.

Is that the case? If so - what is coinbase registering as a protocol handler for?

@drozzy: Coinbase probably wants to handle bitcoin:.

I like @da2x's suggestion. Showing the actual protocol is essential, IMO.

@Liunkae Oh I see. Thanks.

I clicked "Yes" on one of these messages, but I don't see Saved Site Permissions in the Security tab. I'm guessing this is because I didn't check the "remember for this site" option. So now not only am I not certain which protocol it is, I can't see a way to deregister the protocol handler.

if protocol handling in muon is scoped by origin instead of origin+protocol, it might be tricky to allow/deny by protocol. in which case we could show the protocol but have the permission apply to all protocols on the site.

From my understanding "registering a protocol handler" means that if lets say you get a url with the registered protocol it will have a specific behavior.
So if we want to register "gmail" protocol and have "www.google.com" handle it then if we have a url "gmail://www.shouldhandlebygoogle.com" then since the protocol signifier in the url is "gmail" then the registered handler will be used instead of the regular HTTP/HTTPS handler

if protocol handling in muon is scoped by origin instead of origin+protocol, it might be tricky to allow/deny by protocol. in which case we could show the protocol but have the permission apply to all protocols on the site.

Allowing the origin Audible.com the audiobook: protocol is quite different than allowing it to register audiobook:, sms:, ssh:, and telnet: as well. #secuirtyissue

@drozzy: Perhaps I wasn't clear. I mean what is it actually asking? You showed me that it will set "Always allow" option - but what does that option do?

Same here: I read through the comments, but I still don't clearly understand why or why not I should choose "yes/no."

@bradleyrichter @bsclifton, please consider adding a "Learn More" link for every time you prompt a user to make a choice (unless it is fairly obvious...).

I came here hoping to find insight on the same thing. It might be easier to choose how to answer "Allow https://mail.google.com to handle special protocols (mailto:, bitcoin:, etc.)?" if it mentioned what effect that would have. Will that affect the functional behavior of the page contents (such as making some things clickable or maybe automatically executing some script in response to the presence of those strings in the contents), or just the way the page contents are rendered?

This issue might not be entirely solved with brave-core, but let's see how that looks before creating a new issue. These protocol handlers will now be part of the omnibox I believe and also are accessible in the preferences panel. We should be showing a better message by default (since we default to what Chromium does)

If this support thread says anything about how saying NO to the choice will affect the browser's function or behavior, I must have missed it.  I might re-read the whole thread if I get time later.  But it seems there isn't even info given on what the current setting is (i.e. which user choice actually changes anything).
On Friday, August 31, 2018, 11:04:48 PM PDT, Brian Clifton notifications@github.com wrote:

Closed #3246.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

octohedron picture octohedron  Â·  3Comments

briannyeko picture briannyeko  Â·  3Comments

jkup picture jkup  Â·  3Comments

luixxiul picture luixxiul  Â·  3Comments

lukemulks picture lukemulks  Â·  3Comments