raffaeleflorio / qubes-url-redirector Goto Github PK

The end goal is to have normal users use this to redirect links. They don't need to know that it's called qubes-url-redirector. Instead, have something more user-friendly like 'Open in Qube' or perhaps 'Send to Qube'.

Thanks for your work!

Improve documentation about how this extension works internally.

Add a trust level to whitelist entries in regard to other resources linked to the whitelisted one. Specifically the trust level is related to the other resources's host.
Three levels will be present:

• MIN (default). This means trust no other host. Implemented in ac58814 at L43.
• MID. Trust every resource loaded by every subdomain. Implicitly this is valid only for DNS name. Not yet implemented.
• MAX (covered in #28). Trust every resource loaded by every host. Implemented in ac58814 at L44.

Add update manifest to permit automatic update.

Currently Firefox manifest is here: https://github.com/raffaeleflorio/qubes-url-redirector/blob/master/firefox/updates.json

Because the centralized nature of the manifest, it will be in a dir in raffaeleflorio.github.io repo.

Improve domain name and ipv{v4,v6} regexp verification to include RFC requirements.

When a non whitelisted URL is opened the current tab is closed, everytime. Prevent this behavior, specifically when the originating tab is a "valid" one (e.g. Google Search). Currently it's supported by Firefox using [0].

[0] doesn't work in Chrome/Chromium because the latter, when a request is cancelled, opens a page saying that the request is blocked by an extension. So Chrome/Chromium always update the current page. Then it does requests, with different id, two or more times the blocked resource. For this reason the tab is always closed with [1].

For various reason the most reliabe solution is to force non-whitelisted URL opens in a new tab. In this way the original tab is left untouched and the new tab is being closed. However this doesn't prevent tab closing in case of dynamic redirect (e.g. location.href, in this case a js proxy could be well). This approach could be boosted with a MutationObserver object to detect dynamic changes.

[0] = Firefox fix
[1] = Chrome fallback

As suggested in #18 is useful to have the possibility to define custom shortcuts. For example one for dispVM and one for open-here. Obviously it is intended for redirect to less trusted VMs.

When the extension redirects to a qube or blocks (#27) an URL, an HTML page will be displayed instead of the requested resource. Through this page the user will know what happened.

Add this limit to avoid DOS attacks when the url should be redirected to another qube, very plausible.
This limit could be customized through the settings page.

UPDATE:
Improve the limitator implemented in 50a18dd.

UPDATE 2:
The limitator will be replaced by #27.

Currently anti_rdr.js supports escaping of:

• google.com/url url
• l.facebook.com url

Furthermore implement in a modular, flexible way.

When the icon is setted at line [0], Chrome throws an exception with the following message: "Icon invalid".

0. qubes-url-redirector/common/js/backend/main.js

   Line 50 in a983c7f

   browser.browserAction.setIcon({path: "common/logo.png"});

This includes:

• dir structure
• Refact of JavaScript scripts
• Use messaging to communicate with background scripts (Resolves #3)
• Improve readability and structure of HTML pages

Currently there isn't any description to the extension in the manifest file

Differentiate installation method for AppVM and TemplateVM.

Currently only browser.storage.local is supported and there is only a "global" whitelist (per Firefox instance).

If sync storage area is supported the user can give a name to a whitelist (i.e. like qubes name) and choose to share one whitelist (or more) between VM instances, potentially on different Qubes OS instances.

It could be useful to add more granularity to context menu entries. Especially the possibility to add other VMs. Nonetheless wait for Qubes OS 4.0.
It could interact with #21.

Is the behaviour you describe under "Chrome/Chromium new tab behavior" really true?

Because I don't see any such URL contacted in the network console in Chrome/ium:

tl;dr: this happens because > The event `browser.runtime.onInstalled' will be fired also on a Firefox update.

After a few days (I don't know how many) the qubes-url-redirector Welcome page opens up in a new tab. I've Firefox set to restore session and this Welcome page appears as a new tab after startup.
I have Automatic Updates off for this extension. Last update was 8 oct 2018.
I'm running other extensions: uBlock Origin, uMatrix, NoScript, Https Everywhere.

Firefox Quantum 
63.0 (64-bit) 
Mozilla Firefox for Fedora 
fedora -1.0

on a Fedora 28 Qubes AppVM.

All firefoxes in all other AppVMs showed The Welcome page for qubes-url-redirector right now.
This happened before, but I thought maybe it auto-updated behind my back. However, this time I didn't have internet cable connected (though, arguably it could've updated last time browser was running, but I doubt it).

related #17

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/extension/getBackgroundPage
https://bugzilla.mozilla.org/show_bug.cgi?id=1329304

SOLUTION: Use messages to communicate with backgroundPage.
This will be resolved by #10.

Hello ! i followed the instrcutions to install on chrome and i have these errors :

Failed to load extension from: ~/Downloads/qubes-url-redirector-master/chrome
Could not load background script 'webextension-browser-proxy/polyfill.js'.

And can you add a keyboard shortcut + click to open in disposavle vm ?
Thank you so much for this exstension !

With this feature the user could choose to trust every resource loaded by a whitelisted URL.

Currently the installation is done by a Makefile.

Firefox WebExtension API permits only interception of HTTP(S) URL.
The extension can only redirect, through context menu entries, every URL. This means that the extension cannot intercept a request when an URL is opened through a left click or though a background request.

Make chrome package as Firefox one.
Now there is a zip file, installation is done manually.

Running Qubes R4.2 I have a number of Debian 12 and Fedora 39 minimal templates that control various AppVMs. This extension works great on Firefox and Chrome in qubes based on full Debian and Fedora templates. However, I find it fails on AppVMs where the template is minimal.

By failure, I mean that I am able to right-click on links, select "Open in Qube", and select a disposable or named disposable. Unfortunately, after that, nothing happens. No disposable is opened. There are no errors displayed.

I am assuming that I may be missing some things in my minimal templates. What would be the specific packages I'd need to install in minimal Fedora/Debian templates to get this extension to work?

webextension-browser-proxy repo: https://github.com/raffaeleflorio/webextension-browser-proxy

Currently Qubes icon is used. An icon to represent/identify better the extension is needed. Furthermore the icon will be used to represent different status of the extension. (e.g. red for disabled).

• Enabled icon
• Disabled icon

Apparently it does not work in 4.1 anymore: a disposable Qube starts, but nothing happens.

Hi. I've set Default Action in qubes-url-redirector to be Open in the default qube and Default qube: to untrusted-fdr28, however when I try to open an url, which should open in the default qube, I am being asked by Qubes (or by qvm-open-in-vm) to type the target VM in a dialog, as if it doesn't already know that its name is supposed to be untrusted-fdr28.

Is there some policy setting in Qubes that makes this dialog pop-up ?
I've looked with grep in /etc/qubes-rpc/policy/ but couldn't find anything at first glance.

I've encountered this before in QubesOS/qubes-issues#4207
I'm on Qubes OS 4.0

In Chrome/ium the open-here feature doesn't work for timing issue. Specifically [0] is called before [1].

0. qubes-url-redirector/common/js/backend/req_handler.js

   Line 70 in e6219ae

   if (QUR.tabs.isWhitelisted(details.tabId)) {

1. qubes-url-redirector/common/js/backend/tabs.js

   Line 86 in e6219ae

   _tabs[wTab.id] = qurTab;

Do consider signing and releasing this extension in it's current state.
Project was in status quo for the last 2 months without complaints, which means no urgent work was needed. The only currently known bug (#3) has a very limited scope in Qubes environment because Whonix DVM's provide much bigger privacy guarantees than Private Mode in a regular Firefox.

Also, currently available options of installation suck. One needs either:

• to globally disable sign verification - not secure
• to install it by hand on each launch of FF - not practical

And this addon is already extremely useful in it's current state. So please sign current version 2.1.

The current domain entry type should be replaced by a generic URL entry type, because of more flexibility. In this way the user could whitelist a domain (or an IP) with specific paths, port and so on.

Only links opened voluntarily by the user will be automatically redirected (if needed).
The link opened dynamically (e.g. through JavaScript) will be redirected to an internal page (#25). So the user will be the only one who can choose to redirect or not these URLs.
This will replace the limitator (#16).

Currently settings is accessible only by the browser's settings page. A quicker way is needed.

Add an entry label customizable by the user. In this way the user could add an optional label to each whitelisted entry.

I can't open a new tab in google chrome when the exstension is enabled , but when i disable it i can open a new tab + when i right click open in dispvm nothing happens

In Chrome/Chromium the new tab is actually a remote HTML page. So the browser makes an HTTP(S) request. Currently the URL is: https://google.com/_/chrome/newtab?ie=UTF-8 (it redirects to the Google Search homepage). For this reason an user needs to whitelist either the URL or change the behavior of the new tab.

Currently a redirect to another qube is mandatory. However a block only behavior is useful. Furthermore because it's less invasive use as default policy.

Instead of #33 add a browserAction popup that allows the user to whitelist on the fly disallowed resources.

The popup will contain:

• Resource's link
• The resource type (e.g. image, css and so on)
• Allow button

After the installation a HTML page will be displayed. It will contains the instructions and eventually the setup page. In this way the user could customize and understand what the extension does, before any other interactions with the browser.

Since the update to FF 71.0 the Q is red and the plugin doesn't work anymore.

replace TODO file with GitHub issues.