- From: Ojan Vafai <ojan@chromium.org>
- Date: Fri, 8 Jul 2011 09:44:03 -0700
On Fri, Jul 8, 2011 at 12:05 AM, Jonas Sicking <jonas at sicking.cc> wrote: > I definitely have privacy concerns regarding a isRegistered function. > Such a function might be ok in some contexts, but I'd like to avoid it > as far as possible. > Just to be clear, you have privacy concerns for an isRegistered function that is same-domain restricted? > For example I don't think we need to think in terms of the, arguably > crappy, UI that browsers currently use. One simple improvement that > browsers could do is to simply have UI that shows "yes", "not now" and > "never". If the user chooses "never" then no UI would be displayed the > next time that the site calls registerProtocolHandler. > > Similarly, having a unregisterProtocolHandler without a isRegistered > function makes a lot of sense to me. I agree it might not let you > create the perfect UI, but you can get pretty far. > > / Jonas > > On Wed, Jul 6, 2011 at 10:30 PM, Ojan Vafai <ojan at chromium.org> wrote: > > All the arguments for registering handlers aside, it ought to be possible > > for a website to provide some UI for deregistering. For example, many > users > > will expect to go into gmail's settings to stop having gmail handle email > > links. Gmail's help section needing to give users instructions on each > > browser's UI for deregistering is not a good user experience. > > > > If they're going to have a UI for deregistering, it makes sense for them > to > > be able to show it only when actually registered. > > > > On Wed, Jul 6, 2011 at 10:06 PM, Peter Kasting <pkasting at google.com> > wrote: > > > >> On Wed, Jul 6, 2011 at 6:38 PM, Rich Tibbett <richt at opera.com> wrote: > >> > >> > For registration, we could allow _auto-registration_ of protocol > handlers > >> > only if a.) this is the first time the protocol is being registered > and > >> b.) > >> > when the registration request is coming directly from the top-most > window > >> > context only (i.e. from a web page that users are actually visiting). > >> > > >> > >> We can't allow auto-registration in any case (nor was Robert suggesting > >> that), or the protocol is registered to whoever happens to ask first, > >> land-grab style. This is doubly bad if (like Chrome) the UA registers > the > >> protocol handler OS-wide. > >> > >> When the user wants to override the default protocol handler then the UA > >> > could allow e.g. ctrl-shift-click to force show the protocol handler > >> dialog > >> > to the user. > >> > >> > >> These sorts of click modifiers are all taken already. (Ctrl-shift-click > >> means "open link in new foreground tab".) > >> > >> Users should be able to easily detach protocol handlers from this list > with > >> > either [delete] or [delete all handlers for this domain] on this > >> interface. > >> > >> > >> Honestly I think we're getting a bit afield here. It's not really the > >> WHATWG's purview to say precisely what kind of interface UAs should > >> provide. > >> Even my comments about possibly wanting to check for a user gesture > were > >> intended as motivation for discussing various APIs, not as proposed > specs. > >> > >> PK > >> > > >
Received on Friday, 8 July 2011 09:44:03 UTC