New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Contribution] qubes-url-redirector #3152

Open
raffaeleflorio opened this Issue Oct 7, 2017 · 2 comments

Comments

Projects
None yet
3 participants
@raffaeleflorio

qubes-url-redirector

Repo: https://github.com/raffaeleflorio/qubes-url-redirector
Discussion: https://groups.google.com/forum/#!topic/qubes-devel/fsIAQO1xFkU

Hi all,
I wrote a browser extension written using WebExtension standard API. So it's compatible with any browser that supports this API.
Essentially I implemented requested feature in https://www.qubes-os.org/gsoc/#thunderbird-firefox-and-chrome-extensions . Then I added some other features. Currently Thunderbird's counterpart is missing.

So qubes-url-redirector permits to manage which VM is responsible to open links, obviously redirection happens before any TCP connection is made. Furthermore, through context menu entries, you can open a specific link in a custom way. Currently you can open links in: DVM, a default-VM, a specific VM and in this VM. However I know the direction things about qvm-open-in-vm.

Then the extension has a settings page embedded in browser where you manage default behavior and it supports a whitelist based on Javascript's RegExp, in this way there is a lot of flexibility to define trustworthy URLs or domains. Settings page is also accessible through a button in browser's toolbar, besides the default way (e.g. Firefox's Add-Ons manager).

For UI I followed these guidelines (in the repo there are some screenshots):

@andrewdavidwong andrewdavidwong added this to the Release 4.1 milestone Oct 7, 2017

andrewdavidwong added a commit that referenced this issue Oct 7, 2017

andrewdavidwong added a commit that referenced this issue Oct 19, 2017

andrewdavidwong added a commit that referenced this issue Feb 3, 2018

andrewdavidwong added a commit that referenced this issue Feb 23, 2018

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek May 26, 2018

Member

First, sorry for extremely late reply @raffaeleflorio.
I'm looking how to package this. On Fedora there are few Firefox extensions available directly from Fedora repositories (https everywhere, noscript, ublock origin etc), so can be used as an example.
But I can't see much for Chrome/Chromium besides one setting user-agent. Anyway, it looks like for packaging Chrome extension I need to set its ID, which is based on public key used to sign it. Am I correct that extension signing applies only to chrome web store, but not local installation? If so, I could probably use any ID... But if you ever plan to upload this extension to web store (too?), better use the same ID for seamless updates. Is that key generated by the developer, or inside chrome web store? In other words: is it possible to get the public key / ID before uploading the extension to web store?

Member

marmarek commented May 26, 2018

First, sorry for extremely late reply @raffaeleflorio.
I'm looking how to package this. On Fedora there are few Firefox extensions available directly from Fedora repositories (https everywhere, noscript, ublock origin etc), so can be used as an example.
But I can't see much for Chrome/Chromium besides one setting user-agent. Anyway, it looks like for packaging Chrome extension I need to set its ID, which is based on public key used to sign it. Am I correct that extension signing applies only to chrome web store, but not local installation? If so, I could probably use any ID... But if you ever plan to upload this extension to web store (too?), better use the same ID for seamless updates. Is that key generated by the developer, or inside chrome web store? In other words: is it possible to get the public key / ID before uploading the extension to web store?

@raffaeleflorio

This comment has been minimized.

Show comment
Hide comment
@raffaeleflorio

raffaeleflorio May 30, 2018

First, sorry for extremely late reply @raffaeleflorio.

Don't worry @marmarek, you're very busy and thanks for all of your work!

On Fedora there are few Firefox extensions available directly from Fedora repositories (https everywhere, noscript, ublock origin etc), so can be used as an example.

The difference with Chrome is that the Firefox extension has to be signed by Mozilla in order to be installed by the browser. However the upload to the web store is optional.

But if you ever plan to upload this extension to web store

Unfortunately this isn't possible because the extension, in order to work, needs a simple host application that run "qvm-open-in-vm". Obviously the web store doesn't handle such type of installation.
Furthermore it will be available for every other Linux distro (at least).

In other words: is it possible to get the public key / ID before uploading the extension to web store?

Yeah, indeed the key/ID is generated offline during the packaging process. The upload to the web store is optional, like for Firefox.


The new version (tracked by the v2.1.1 branch) is more stable, with more feature and simpler. It's almost finished. For various reason I couldn't work on it in the past period.

There is only an issue with Firefox, due its APIs: the extension can only handle HTTP(S) URLs. Chrome APIs, instead, permit to handle every scheme (like data, ftp and so on). What do you think it's more appropriate to do? A big warning on the Firefox version?
There are some hacky way to bypass the Firefox limitation. But they aren't, by their nature, reliable or they're too invasive.

First, sorry for extremely late reply @raffaeleflorio.

Don't worry @marmarek, you're very busy and thanks for all of your work!

On Fedora there are few Firefox extensions available directly from Fedora repositories (https everywhere, noscript, ublock origin etc), so can be used as an example.

The difference with Chrome is that the Firefox extension has to be signed by Mozilla in order to be installed by the browser. However the upload to the web store is optional.

But if you ever plan to upload this extension to web store

Unfortunately this isn't possible because the extension, in order to work, needs a simple host application that run "qvm-open-in-vm". Obviously the web store doesn't handle such type of installation.
Furthermore it will be available for every other Linux distro (at least).

In other words: is it possible to get the public key / ID before uploading the extension to web store?

Yeah, indeed the key/ID is generated offline during the packaging process. The upload to the web store is optional, like for Firefox.


The new version (tracked by the v2.1.1 branch) is more stable, with more feature and simpler. It's almost finished. For various reason I couldn't work on it in the past period.

There is only an issue with Firefox, due its APIs: the extension can only handle HTTP(S) URLs. Chrome APIs, instead, permit to handle every scheme (like data, ftp and so on). What do you think it's more appropriate to do? A big warning on the Firefox version?
There are some hacky way to bypass the Firefox limitation. But they aren't, by their nature, reliable or they're too invasive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment