Open Bug 1322304 Opened 8 years ago Updated 2 years ago

Allow vanity URLs for WebExtension pages

Categories

(WebExtensions :: Frontend, defect, P5)

Product:
WebExtensions
Component:
Frontend
Type:
defect

Tracking

(Not tracked)

People

(Reporter: soeren.hentzschel, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: ux-userfeedback, Whiteboard: [design-decision-approved][triaged])

Attachments

(2 files)

WebExtension-beautifulURL-proposal.gif
(deleted), image/gif
Details
WebExtension-beautifulURL-danger.png
(deleted), image/png
Details
I am the author of New Tab Override and I am trying to find equivalents for the current SDK based implementations in the WebExtension world. In the current version of my add-on I implemented two about:pages, one for the settings UI and one for a news feed. That's great, because I can say, for example, "please open about:newtaboverride" if I want to point a user to the settings UI. In my WebExtension I have a URL like "moz-extension://ecd773ac-2a57-ce4a-bf3e-eb3c90ac16c8/html/options.html" and that's a bad URL, from an UX perspective. I would like to see a way to implement a page with a nice URL. It doesn't need to be an about:page, something different would work for me, but I really dislike ""moz-extension://ecd773ac-2a57-ce4a-bf3e-eb3c90ac16c8/html/options.html"".
Flags: needinfo?(amckay)
It was suggested in a mail thread that you could do this using the omnibox API and register a keyword for your add-on: https://mail.mozilla.org/pipermail/dev-addons/2016-December/002404.html
Flags: needinfo?(amckay)
Thank you for the suggestion. It solves the part >>I can say, for example, "please open about:newtaboverride" if I want to point a user to the settings UI<<, because I can implement something like "newtab settings" as command. That's nice. But it's still an ugly URI and bad from an UI point of view. Are there any plans to improve this? Of course, you could say that the URI doesn't matter and it has no value to improve this. But as add-on developer I would really like to see a way to have a nice UI for my add-on. And that includes the visible string in the location bar.
Flags: needinfo?(amckay)
Whiteboard: [design-decision-needed]
No plans right now, the omnibox API seems pretty good. From what I've seen the implementation of moz-extension seems like quite a bit of work. Perhaps there's a better way to do it?
Flags: needinfo?(amckay)
Beijing office would like to see such an option too. We've been using `about:cehome` (means China Edition Homepage) as our extension provided homepage for China repack for like five years. This was introduced as part of some agreement with Baidu.
Blocks: 1311472
I wonder if a pages:* protocol could be interesting for webextensions as a simplification of the full sized url. Benefit would be avoiding pollution of about:* pages, yet giving simple urls for users to type.
Flags: needinfo?(amckay)
:hectorz, for about:cehome, see my comment in bug 1329853.
Using a custom protocol handler might be a good way to do this and not have to add anything special. Be curious to see how exploration around that goes.
Flags: needinfo?(amckay)
This has been added to the agenda for the May 2 WebExtensions Triage meeting. Soren, we'll discuss this bug immediately after 1332308. :) Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting Agenda: https://docs.google.com/document/d/1vf8AaW8tKKbMn4KhsqEYhrYqVTUGaERHQmzanEp2Cls/edit#
Unfortunately I won't be able to attent, so let me summerize why I advocate for this enhancement. If an add-on implements a user interface in a new tab, the URL of this user interface is always visible. That's the reason why I consider the url as part of the user interface of the add-on. As add-on author I don't want that the user interface of my add-on has a url like "moz-extension://ecd773ac-2a57-ce4a-bf3e-eb3c90ac16c8/html/options.html" because it's ugly and so a part of my user interface is ugly. I want a url which is nice to read. It could be about:<pagename>, moz-extension:<pagename>, addon:<pagename> or something else. I don't have a strong opinion *how* the url should look like. But I would be prefer that I, as add-on author, can register one or more page names. Let's say I have an add-on with a page for all the functionality and a options page, so there are two pages. It would be *okay* if I have a url like "moz-extension:myaddon/html/start.html" and "moz-extension:myaddon/html/options.html" (it's better than the current situation), but it's still not perfect. It would be better if I can register a page "moz-extension:myfunctionality" and a page "moz-extension:myaddonsettings". For a new tab add-on it could be "moz-extension:newtabpage" and "moz-extension:newtabsettings". If more than one add-on wants to register the same page name, either the first or the last add-on should "win". I don't know how it works for add-ons which override the new tab page, but it's a similar situation because there can only be one new tab page. Just do it the same way, so that it's consistent (either always the first add-on wins or always the last add-on).
Putting in another layer of registering URLs seems like an awful lot of code to write and maintain for little value and we'd have to add in more APIs (what would getExtensionURL resolve to for example). Doing that didn't seem to make sense to anyone in the meeting. Based on that we'd move this to denied. However, we are implementing bug 1266012, I think we can build on that and maybe make the URL a little nicer by maybe doing some UX work. So for that I'm going to bounce over to UX to get their opinion. If there's something simple from their point of view, that might make sense.
Flags: needinfo?(mjaritz)
I would love to use the extension name (with dashes instead of spaces), but I expect that name to not be unique, so that wouldn't work. So no simple solution here. I agree that we should not solve that on the individual level but have a general solution. Either generic - which I will add to the add-on UX backlog, or we could register unique strings for IDs like how hostnames relate to IPs.
Component: WebExtensions: Untriaged → WebExtensions: Frontend
Flags: needinfo?(mjaritz)
Keywords: uiwanted, ux-userfeedback
Going to mark this approved as it seems like there's broad approval for a UX solution. The general problem is that no-one is quite sure what that is. So if someone is planning on working on this, your next steps are to propose a solution or work with UX on that. I don't think there's any need to hold it up decision-needed anymore.
Whiteboard: [design-decision-needed] → [design-decision-approved]
Priority: -- → P5
Whiteboard: [design-decision-approved] → [design-decision-approved][triaged]
Bug 1266012 has been implemented, so let me make a proposal. At the moment we have URLs like "moz-extension://c9aff1e0-a30f-3644-b1d7-12855fcaf1b9/html/ui.html". With bug 1266012 it looks like: "[[Extension (Bookmarks Organizer)]] moz-extension://c9aff1e0-a30f-3644-b1d7-12855fcaf1b9/html/ui.html" My proposal is to hide the entire "moz-extension://c9aff1e0-a30f-3644-b1d7-12855fcaf1b9" part. So it will be look like: "[[Extension (Bookmarks Organizer)]] html/ui.html" But if you click into the location bar the full URI is visible, including the "moz-extension://c9aff1e0-a30f-3644-b1d7-12855fcaf1b9". It's still not great but at least it looks okay if the location bar has not the focus. I think this would be the easiest solution since it does not require to find a better solution for the generated ID part, it simply hides what is not necessary and still allows to copy the full URI. Since the ID is a generated ID and cryptic and there is the name of the add-on on the left side there is no value in always show the full URI. I would love to see a better solution but I think this is at least a solution without a lot of downsides and better as the status quo. Markus, what do you think?
Flags: needinfo?(mjaritz)
Attached image WebExtension-beautifulURL-proposal.gif (deleted) —
(In reply to Sören Hentzschel from comment #13) > > My proposal is to hide the entire > "moz-extension://c9aff1e0-a30f-3644-b1d7-12855fcaf1b9" part. > So it will be look like: > > "[[Extension (Bookmarks Organizer)]] html/ui.html" > > But if you click into the location bar the full URI is visible, including > the "moz-extension://c9aff1e0-a30f-3644-b1d7-12855fcaf1b9". It's still not > great but at least it looks okay if the location bar has not the focus. I > think this would be the easiest solution since it does not require to find a > better solution for the generated ID part, it simply hides what is not > necessary and still allows to copy the full URI. Since the ID is a generated > ID and cryptic and there is the name of the add-on on the left side there is > no value in always show the full URI. > > I would love to see a better solution but I think this is at least a > solution without a lot of downsides and better as the status quo. Great that you considered the connection to Bug 1266012. I really like your idea as it allows people to still know that this is coming from an extension, but hides the cryptic part. I still think we should show the scheme as this is something we do for any other URL that is not from the browser itself. (file:// ftp:// http:// https://) But we can hide/collapse the ID as as you suggested, as it does not add value in the unselected state. (See option #1) I still visualized your proposal, (Option #2) but I feel this is not consistent with other URLs, and is too big of a difference between selected, and unselected.
Flags: needinfo?(mjaritz)
I don't like option #1 because it still shows the moz-extension:// and a part of the generated ID, so it's not much better than the current state. I don't think that showing this is really necessary since bug 1266012 because it's already clear that this page is coming from an add-on. Also, Firefox does *not* show the protocol for http://, so there is already no consistency. For these reasons I vote for option #2. What is the next step to move this request forward?
Needinfo'ing Andy here for help determining next steps as Markus is out until August 20.
Flags: needinfo?(amckay)
I think its a matter of starting to implement it as per one of the proposals. I like #2 too, but would look to Markus for final thumbs up on that. Sören, is this something you want to work on?
Flags: needinfo?(amckay)
As a developer of web extensions, I also think the current implementation of moz-extension url is very bad and can worry users. Option #2 seems perfect to me. It wasn’t said in this topic, but in case of newtab page, the url should be empty or selected by default (#1372996). My preference is to be empty, but if the selected option is chosen, showing the full url (including moz-extension and id, as current implementation) will be counterproductive. moz-extension id isn't relevent for end user and we will know from wich extension the page come from, thanks to identity part.
(In reply to Andy McKay [:andym] from comment #17) > Sören, is this something you want to work on? I never wrote a patch for Firefox and I don't know what to change. So I would need a mentor with time and patience. ;)
Attached image WebExtension-beautifulURL-danger.png (deleted) —
I am still in favor of option 1 as with option 2 I see the danger of extensions being able to fake other urls with their path/filenames... (like www.mybank.com or https://www.mybank.com) which, even if not perfect, would come very close to what people would be familiar with from https://www.mybank.com to normally look like.
Summary: Allow about:pages or another form of "beautiful" URLs in WebExtensions → Allow vanity URLs for WebExtension pages
(In reply to Markus Jaritz [:designakt] (UX) from comment #20) > Created attachment 8899862 [details] > WebExtension-beautifulURL-danger.png > > I am still in favor of option 1 as with option 2 I see the danger of > extensions being able to fake other urls with their path/filenames... (like > www.mybank.com or https://www.mybank.com) which, even if not perfect, would > come very close to what people would be familiar with from > https://www.mybank.com to normally look like. I think we should be able to avoid that by showing the full URL whenever the shortened version would look like an ordinary URL. The main issue I see is that it would be hard to determine when a path component might look like an ordinary domain ("google.com/?q..."), which is what we'd normally show for non-HTTPS URLs. But maybe we could also always include the leading `/` in extension URLs, and maybe do something to the styling of the identity box to make it clearer that it's part of the URL?
One downside of just hiding the moz-extension ID is that the pages still contain the machine-specific component, which, IIUC, means that it's impossible to share a URL (send tab to device, for example, or open a desktop bookmark in Firefox for Android).
I'd like to get Security's perspective on this URL discussion. Daniel: - Do we need the machine specific part for a security reason? (Comment 22) - Do you see the faking of URLs as a thread if we would shorten the URL? (Comment 20)
Flags: needinfo?(dveditz)
Thinking about this some more and talking to Andy and Blake, it seams there might be ways to make this URL shorter but still keep it clearly away from being able to fake other urls. (That is if when displaying, we replace the ID with the extension name (+number) and shorten moz-extensions to ext) And with that make it into something the user can relate to, instead of a random string of numbers that might just be confusing people. instead of "[[Extension (Bookmarks Organizer)]] moz-extension://c9aff1e0-a30f-3644-b1d7-12855fcaf1b9/html/ui.html" we could maybe display "[[Extension (Bookmarks Organizer)]] ext://bookmarks-organizer/ui.html" and if the user has another extension with a similar name "[[Extension (Bookmarks-Organizer)]] ext://bookmarks-organizer-1/ui.html"
(In reply to Markus Jaritz [:designakt] (UX) from comment #23) > I'd like to get Security's perspective on this URL discussion. > Daniel: > - Do we need the machine specific part for a security reason? (Comment 22) > - Do you see the faking of URLs as a threat if we would shorten the URL? In short yes and yes. But there's room to play with alternatives. The install-specific part of the URL prevents fingerprinting users by whether certain URLs are available or not (of course some extensions can still be detected by the changes they make to the page context). It also protects users from attackers who knows of a vulnerable web-accessible resource in a particular extension: it will be nearly impossible for the attacker to cause that resource to load since the ID won't be known. Of course this directly conflicts with the desire of extension authors or troubleshooters to be able to say "open URL foo:barbaz and do this or that". As to display, Option 2 is a horrible spoofing risk -- although if an extension is going to be malicious (and some definitely are!) they can already do things like use a content script to keylog a user logging in so no need to phish for it. The whole point of a URL in an addressbar is to let people copy and link to things. If we make it pretty to the point it doesn't actually work maybe we should just blank the URL and show the site identity box [Extension (foobar)]. Also, think about what we would need to do on Fennec where we don't have the space for the "this is an extension" hint box.
Flags: needinfo?(dveditz)
> The install-specific part of the URL prevents fingerprinting users by whether certain URLs are available or not (of course some extensions can still be detected by the changes they make to the page context). It also protects users from attackers who knows of a vulnerable web-accessible resource in a particular extension: it will be nearly impossible for the attacker to cause that resource to load since the ID won't be known. Do you mean that the only reason for it is that web-accessible and web-inaccessible resources are located in the same namespace? Would it be possible, for example, to have `ext://extension-name-or-id/path/to/file.html` as an alias for the corresponding `moz-extension://UUID/path/to/file.html` URLs where the `ext://` scheme is not accessible to web content at all? > The whole point of a URL in an addressbar is to let people copy and link to things. Yeah, and that's exactly the point that does not work with `moz-extension://` URLs any more than "bookmark it locally". At the moment the only way I see to make the extension URLs shareable / syncable is to register a domain specifically for intercepting requests to it and presenting the extension UI there, which does not feel like a clean solution.
Flags: needinfo?(dveditz)
> The whole point of a URL in an addressbar is to let people copy and link to things. The idea mentioned in bug 1365355 was to make the URL editable once the user interacts with the URL bar but show by default the much shorter version. As for concerns of extensions having spoofed names of others I think that sounds more like an AMO/install time issue. If there were collisions perhaps the extension could be renamed or the user is warned at install time. As Dan mentions the risks of extensions as a whole are much worse than one extension pretending to be another for these URL indicators. For example I could make an extension called LaastPass with the same icon which would steal user credentials in the browser action.
(In reply to Denis Lisov from comment #27) > Do you mean that the only reason for it is that web-accessible and > web-inaccessible resources are located in the same namespace? I don't know if that's the _only_ reason, but it's an important reason from the security team's POV. > Would it be possible, for example, to have `ext://extension-name-or-id/path/to/file.html` > as an alias for the corresponding `moz-extension://UUID/path/to/file.html` URLs where the > `ext://` scheme is not accessible to web content at all? Sure, it's probably possible; not sure that really solves your problem. The only unique thing would be the extension's ID, and many of the most popular (old) addons have completely meaningless IDs in the same format moz-extension:// is using today. They'd still be ugly. For visual UX purposes something like Markus's option 1 (comment 14) would look as good or better than your ext:// suggestion. Once we get the site identity box that names the extension we could even hide the ID entirely and expand when the field gets focus. moz-extension://.../path/to/resource What do you get out of a URL that can't be linked on the web? Wouldn't it be better to simply have a UI hook in your add-on to get to whatever important page you need opened? Or as suggested earlier, use the omnibox keyword API? From a security POV I wouldn't have a problem with letting an extension declare a mapping from a URL namespace to specific pages in their apps as long as those aren't web-accessible links. For example: ext-about:myextname/prefs. But given the similarity in functionality to the omnibox API I'm not sure the web extension team would find it worth the effort. (of course we'll have to decide what happens when multiple extension pick the same "myextname"--the usual namespacing problems that the omnibox API also shares.)
Flags: needinfo?(dveditz)
> Once we get the site identity box that names the extension we could even hide the ID entirely and expand when the field gets focus. moz-extension://.../path/to/resource There is already a site identity box with the name of the add-on for WebExtensions…
There is an article that may be relevant to this topic: https://www.ghacks.net/2017/08/30/firefox-webextensions-may-identify-you-on-the-internet/
(In reply to Sören Hentzschel from comment #32) > There is already a site identity box with the name of the add-on for WebExtensions… And now for about:newtab overrides we completely hide the URL (bug 1372996). Is that better? Not quite what was asked here because the Address bar stays blank -- you can't select it to edit the URL. (In reply to erosman from comment #33) > There is an article that may be relevant to this topic: > https://www.ghacks.net/2017/08/30/firefox-webextensions-may-identify-you-on-the-internet/ It's not. Hiding the UUID or allowing a vanity alias wouldn't stop that attack, and stopping that attack by randomizing the UUID every session as Safari does would not fix this bug ("urls are ugly").
> And now for about:newtab overrides we completely hide the URL (bug 1372996). I wish this would be true, but it's not. Bug 1372996 changed *nothing* for add-ons like my add-on New Tab Override. It only works for overrides via manifest so it's useless for all add-ons which let the user decide which page should be shown instead of about:newtab. Furthermore, the override of the new tab page is not the topic of this ticket *at all* so I don't understand what do you want to say with your comment. Could you please explain? Even if bug 1372996 would help for the new tab page (and it does not help) how does it help for a page like moz-extension://ecd773ac-2a57-ce4a-bf3e-eb3c90ac16c8/html/options.html?
Flags: needinfo?(dveditz)
I meant was that a better experience? Obviously other panels are not the newtab page, but is it good enough for those pages if they are also presented with a blank Address Bar (apart from the site identity box which says what extension it is)? We clearly have the technology to do that so it might be simple and more likely to happen. If your addon is about replacing the newtab it should be fine for you, but maybe not for your options page. True "vanity" URLs will take work and raise security complications we'll have to worry about (e.g. namespace clashes if two addons claim the same vanity URL, or privacy issues if the vanity names are leaked to content). Blank is safe. Does the internal extension path convey any useful information to users? Hiding the <UUID> part and showing "moz-extension://.../<path>" would be OK too. In either case we could revert to the real URL if the user focuses the address bar. Showing just a relative path raises spoofing risks. Yeah, the "Extension (Foo)" text will be in the site box, but I bet lots of users will miss that and the "path" could look enough like a domain or URL to spoof people. If we were going to review every web extension I wouldn't worry about it since such paths in the package would be suspicious. But we are NOT going to be reviewing these ahead of time and we KNOW some people will try whatever they can get away with.
Flags: needinfo?(dveditz)
Thank you for your explanation, it's now much clearer for me! For the new tab page an empty address bar makes a lot of sense for me, for other sites I am less sure. When I think about it I would say: yes, an empty adress bar is the better user experience for other sites, too, compared with the current moz-URI. The UUID is random, so something like "you can find the options via "moz-extension://extensionname/options.html" is not possible. So there is no real value in the URL and it should be okay to hide it. Well, maybe there is one use case for knowing the exakt URL of a page: someone could like to use an add-on page as home page. But I don't know how common this use case is. If an empty address bar makes such a difference for security and implementation then yes, this should be the way forward. This could also automatically solve the problem that bug 1372996 did not helped for New Tab Override (there is still no blank address bar on the new tab page). At least I hope so.
From what I understand 2 options emerged to make the URL look nicer without putting people at risk. But none of them are true vanity-urls, but just making the current urls a little 'more beautiful'. - hiding the URL completely but leaving the site identity box - shortening the URL, and expanding it on focus I do not think hiding the url is a good idea. People have learned the pattern of having a url in the url-bar when they open any thing in a tab. (Unless they haven't opened anything in the tab yet, which is why it is good to continue the pattern of no url on newTab replacements.) Not having anything in the url-bar in any other case will cause confusion, especially as also all our internal pages show a url. So, we are left with the option to simplify/shorten the URL, and expand it on focus. For that, option 1 in attachment 8879571 [details] is an easy way to do that. And if we want to further simplify, we could file a bug to change "moz-extension://" to "ext://" or something similarly short. But that is a separate bug to me.
(In reply to Sören Hentzschel from comment #37) > If an empty address bar makes such a difference for security and > implementation then yes, this should be the way forward. This could also > automatically solve the problem that bug 1372996 did not helped for New Tab > Override (there is still no blank address bar on the new tab page). At least > I hope so. If you are redirecting people to a (potentially changing) url, they should be able to see that URL. So no, I do not think New Tab Override should have the option to not show a url. If you pic one url to show to people on newTab, they will see that and an empty URL bar, because we will ask them to confirm this is the page they intent to see. (https://bugzilla.mozilla.org/show_bug.cgi?id=1397809) Allowing continuous changes to that url, would require to ask the user to confirm on every new url, which would potentially result in many messages, and I therefor wouldn't want to do.
It was always possible to clear the address bar for the new tab page and it's the - by far - most requested feature for New Tab Override. And it is already implemented for new tab overrides via manifest (bug 1372996) so why allow for override via manifest but not via browser.tabs.update()?
(In reply to Sören Hentzschel from comment #40) > why allow for override via manifest but not via browser.tabs.update()? See my answer above: https://bugzilla.mozilla.org/show_bug.cgi?id=1322304#c39 and Marks commente here: https://bugzilla.mozilla.org/show_bug.cgi?id=1372996#c34
If I set a new tab URL via manifest the URL can't change? I don't see the difference. The only difference from the user's POV is whether the add-on has a hard-coded URL or the URL is entered by the user. And if the URL is entered by the user the user should know what he/she did, no? It's really very, very sad that almost all new tab add-ons are more or less *useless* at the moment because the user has to clear the addressbar on every new tab if the new tab page was overriden. It's not possible to open a new tab and start typing in the addressbar… New Tab Override has more than 100,000 users and it's not the only add-on overriding the new tab page… But maybe this discussion should be moved to bug 1372996 or another ticket…
Product: Toolkit → WebExtensions
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: