qubes-url-redirector

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Hi all,

I'm writing an extension to resolve this issue: https://github.com/QubesOS/qubes-issues/issues/845. I uploaded on GitHub an alpha version.

Currently I implemented redirection with a context menu. You can choose to open the link in: dvm, default VM (settable in options page of extension), some vm or here.

The missing feature is redirection of normal HTTP traffic, so when user click on the link normally. This behavior, obviously, is determined by options page, it supports open in: dvm, in a default vm and here. Soon I'll upload a complete version.

Here the repo: https://github.com/raffaeleflorio/qubes-url-redirector.

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZqmUHAAoJEI08Rvun9XHuj2MP/REuq2OA02sDpbktPSJ2QpdY

RZpC3alDL/4GZ012zj+oow9TKzGWiyTw/eXIQNHg2ungg36We7c1Qaf9wQNKuOvK

E1n33NjpnOTV14jEC30Ni3IpEpESU4b4Y3TnWmvYenQUOC0hzKPGpDdqCNBTzfMx

EAM4z8P83b7WshfEVzn0H2Y2Gak4DQ3B4MYpIxNMRxSk35EVjg0nu5aoFhOJpkT/

cgsrwLcNoxgu1FRJ5xexteTi2U2Etd3bu764FwhU5nh+fUjwjBJ0Idq/bBMofPZ8

Y6mjIMOAcGPq2iktK2T4qW9y1vEIC0ZTG9EThf4CXMlpKPXYM0vp3gilk0Y+AplV

RrTRSTTb5GklguoiJNxItKi76YHmycXtBTPLRPo4P6AKvXOGluy06aH+YS7WqgZ2

YnLI9RtT++07mL845tCEs74t1jpaRj1Cf8hCAddKP69nDwJItaIfoj1016fL1hqE

qJnmfQskXM+eLE1WJAkJq+5RwOyIZjxwyqkqVwf1QhP3O5tavpXZSpD9UUNLnM9x

oSPHZvCJ6QuYI3h6CnmozACVNQ21nFlUjymOhLZDqfMWTq8WiyvjBiRNLDuyFo6F

wIGFmhCFdLcZZzLLxNjLpF6GPxrh7H18ZQHCftwRQVA5dFPy1pfgLT9VEQc6NWoN

H3G9f1/MbYIsNtxVh8y+

=2oLL

-----END PGP SIGNATURE-----

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

I explain better what I'm doing. I just re-read and I think that this explanation is not complete.

Currently I'm writing extension for Firefox/Chrome to resolve the issues pointed in gsoc ideas list about browsers and email client, not only #845 issue.

Firefox/Chrome extension objectives are:

1) Settings page where user can personalize extension: what has to do browser when user clicks on a link and what is the default VM.

2) Personalized context menu entries for link. So when user right click, there are new entries: Open in dvm, Open in default VM, Open in some vm, Open here.

3) HTTP Redirection according to settings page.

4) Best integration with browser.

I reached the goals with WebExtension standard, supported by major browsers.

I think that desktop file technique pointed in "https://github.com/QubesOS/qubes-issues/issues/441" is not suitable for browser as is, because of the above points. However also if this approach were improved (e.g. with a software that ask what to do with that url, and this is an annoying approach too [alt.0]) there isn't a simple way to has different browser settings and default settings. Obviously with WebExtension this problem doesn't occur.

For Thunderbird I've not start yet. However I don't know if HTTP Redirection (as WebExtension supports it) is available. And I think that it's not necessary because if you open the link in browser from email client, the browser take default action for HTTP request as set in extension settings page. So in addiction to context menu this approach I think that it's a good tradeoff.

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZq92vAAoJEI08Rvun9XHu8QEQANExX47nAyQgRycoh1VKCjoK

GsKRWmc6OseTR6VznJ7/AT0pt1xxi0RFBGayFikbRiqJPoo5h/V3j8gd8zy9bEKv

2pJFuSksntMmoScSkm74fc3ZoxZdbvcDjMrRlaJDT2sjIc5KmoTWoiqcVme3gttn

o2CEDH/Iw2CRcVLuPlDxUf7VaJJzEgBfen7RmKwixoH4Y7sf4UUYbsfnD357xZwr

94eOf3aDTXhK3olYIFVK1jFiGvFFuF+n5kX1tlesoUzUtuU+naE79IDDGotf5sQ0

hWORR23ew/j4KP8PfGeF7GerxFkbFbL+2aMc7mrk75qMoq6NfcwV6eykUy5CxXTw

k4N0vgnBrCuBOqhUKlnCJDpMOts31btcyWYB2J/G85PTRsHtOC+ErdRpVvjUDNHC

4EAxO7iwvmSuihPV2F2o97wowhc0LJ9JBs6wsPqJ40Kp+lLCnfhFJXCZ1VzZl1Vq

A8BFkFLsvVoG4dvx35g4HfWpVeiasXDuzBUo/jkbjeCta4JzaGExz4njmAGoskQ8

+Mprq+1Ih6vw27OXqZZAKMvLyWyWZnX4qSzzWpP4ftHxJfux2K52SYpY/Jj9FSvR

Pg5/DJ2cgB4McnJba/rOWWYIG4NdUalVuIGZ5nz4l91yqZNbrN0h1Qm8ip2hA0Fv

qmw6NrfHHMSf+4F2sgUE

=KzlZ

-----END PGP SIGNATURE-----

--

You received this message because you are subscribed to the Google Groups "qubes-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/8DABf5_dsDSkJ5slKlFWjlT9reQh3FSa9Ca9nllwLg-mvHn4aJPbPiuH_WheeU8C2K6R_xKzYKAuzrzBeV7yK_dulwX7RNwjznb5AiI2aOc%3D%40protonmail.com.

For more options, visit https://groups.google.com/d/optout.

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Hi all,

I've just uploaded a working version on GitHub. I tried it on Firefox, soon I'll try on Chrome. Actually it can work on every browser that supports the WebExtension standard.

Here what I've done:

1) You can customize default url redirection behavior through browser.

2) url redirection happens BEFORE any tcp connection is made. So no data is sent to the browser.

3) Only interactive url are redirected (URL opened with left click). On this way external resources inside main page aren't redirected or blocked.

3) You can open an URL with personalized context menu entries. So a determined link can be opened: in a dvm, in the default vm, in a specific vm or in the actual vm.

4) You can add whitelisted url. Obviously these URLs aren't redirected.

The missing feature is regex support for whitelisted URL. When I'll implement it, folders or domain can be whitelisted entirely. However there isn't a lot work to do, I use Javascript regex. In this way there is a lot of flexibility.

After this feature implementation, what are the steps to done to be included in Qubes OS officially?

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZrYD7AAoJEI08Rvun9XHukQcP/iXsCcF6PSdHRAZ//zG0i3HF

fn8WPlXDqzaL4bTvkrQCFXV81sWL6Qgh8SA09E5R+e+QSC+fqFL/ju4yJE32bNaa

+mVSo0uG9MEzetjkya8UPMIhR4GyUdhaFH+Tt6rT4h0BjQUA31zh019bqcSPOp0n

dPk6uyQNtqD8+KMIY8zSRDFpO5zvyxmYc1J0gqZdYMW5vCyD7//GNuqExS88TZ51

Q+iYCuK9SbMzlAA0Tb36tYLNkdigG5ygPRPorC+SUW/dhLZTTdkcx5tcoJsVQSA0

6+FbY74TFsX5nHtLhOJ+TTnh+8LnoZrNdytqp+FyhIYg7iUMDXKSdC9Lq4OhBIzS

BV4nvJCSlChiHMQH1jeoIEvuQcIQaFGMGS8PtSmCecjn4kxblnGhUlWrnF0mMiXK

w8xxMGrb3TcHLyaBOjU2u0Ouq2cXKCgESDiVLlE+1srOjhtO4RqxeLK5PZHkQeMb

AxdLcFAnJy0VAibInsY+G2vl296UX8Um1kEJOJnYWy1uLzrVoufjK+K4gEOlmGG8

cpNT+DbuEAurBcgmzMkRndEEi4UrQ51o0+FCQQzWaZ52AvLT5ebA3RJgVtsaLu9k

qzaPRblxHBGbzzwsfOBHZvk/FK5em6pYqDOIJlAJCThsOuMAs0X06ny4ar0ne9dL

V0jtXz9Q7McTS5cDI3v5

=+XvS

-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Mon, Sep 4, 2017 at 12:36 PM, 'Raffaele Florio' via qubes-devel
<qubes...@googlegroups.com> wrote:
> Hi all,
> I've just uploaded a working version on GitHub. I tried it on Firefox, soon
> I'll try on Chrome. Actually it can work on every browser that supports the
> WebExtension standard.
>
>
> Here what I've done:
> 1) You can customize default url redirection behavior through browser.
> 2) url redirection happens BEFORE any tcp connection is made. So no data is
> sent to the browser.
> 3) Only interactive url are redirected (URL opened with left click). On this
> way external resources inside main page aren't redirected or blocked.
> 3) You can open an URL with personalized context menu entries. So a
> determined link can be opened: in a dvm, in the default vm, in a specific vm
> or in the actual vm.

In a specific VM is... non-trivial. See comments below.

> 4) You can add whitelisted url. Obviously these URLs aren't redirected.
>
>
> The missing feature is regex support for whitelisted URL. When I'll
> implement it, folders or domain can be whitelisted entirely. However there
> isn't a lot work to do, I use Javascript regex. In this way there is a lot
> of flexibility.
>
>
> After this feature implementation, what are the steps to done to be included
> in Qubes OS officially?
>
>
> Best,
> Raffaele.

Nice work :)

A cursory review of the code looks ok to me (but I'm not a web security guy).

One question about encoding here [1].

As for pattern matching URIs and routing them to specific named VMs,
please see issue #910 [2]. tl;dr - the direction things are going is
for source VM to not be able to specify a destination VM by name
within the untrusted UI of the source VM, but rather for this
selection to be done in a trusted UI in dom0. This means the source VM
won't be able to specify (and shouldn't even know) destination VM
names.

One way this might still work is to instead map URIs to qubes RPC
arguments (e.g. qubes.OpenURL+is_github, qubes.OpenURL+for_work, or
something). and let dom0 policy map arguments to destination VMs. This
has some UX implications which require some thought.

As for package inclusion, in theory the process is [3]. qubes-contrib
has yet to be put into use, but it seems like the right place to me.

Thanks for contributing!

Cheers,
Jean-Philippe

[1]: https://github.com/raffaeleflorio/qubes-url-redirector/commit/36c80a74af0da2165972e477d9338e980bb66d15#commitcomment-24080745
[2]: https://github.com/QubesOS/qubes-issues/issues/910
[3]: https://www.qubes-os.org/doc/package-contributions/

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

> One question about encoding here [1].

Encoding issue resolved. Then I also modified background's interface.

> In a specific VM is... non-trivial. See comments below.

Actually I implemented specific VM redirection because qvm-open-in-vm supports it. So at current status of Qubes OS it doesn't add any security risk. But I agree with #910 approach. I've also reflected on current rpc implementation problems when I faced this problem, and for these reason I total agree with this direction..

> This has some UX implications which require some thought.

Yeah..

> Nice work :)

Thanks! :D

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZroWPAAoJEI08Rvun9XHuiNgP/j0v1xkSJ1IGgJtCFYBbmiyI

9kWOQm7YS/AUXuwdkZEcoKtsiGi7519UzewxV+Au7zf4/aOcU+BAQomTWfNG2S0C

KHbtZ1rVkVGfnVGYOUBvcawovZmiaMwvXscVrnDP2ar8Q82faMr6CyBNmZ+QGcXc

UP2rXIZkHxapmBxhm6AAlSz2F6TOmtBJC+oULYAimrVRfuZrIvNFKPlmtFO79W/V

OUnqaA+vP0Q4MDCdf6Uqa3IqEyQtGbBnqN+4m+nDttvtpba77Yw4shaq0hf4uDfe

xvt0oeanCnLOFmBZSLbiOYNvC7nlaxzGfk5P9CaU70eYdF7fsjwFWMElq8lPEEce

vxfMpQbmFv33sSJceqEXM6JADaHEmEsaH4JzFF1zGkhyHfua1v1CFNnssY4cKlXw

6j0UpaDfmyhTcwesgol/GvIMasmOgZ/3lYiipNdOdnLkpXOlZmZ/D+bOz1s7eMB2

QtmZTuaP+hun7NUi2fFcWtx/OSsZy9MRdJeEqgEpx5Z+xANfUUom/2VyzOfs512L

AKPnH3p+csIjxsdxNCV3KXQs6dzkmVkh1z5nwwlywI/oBfeSPPcTBHoJFiI4A3M/

7u4G1ZFJc3rfiaR8Xn3QsBXq+6Trrs0XjJhXyYuG/ufDzCSlEmrvDog/Ija4MqJR

u4fRH9h2ynWnxKURRcqG

=k1Bo

-----END PGP SIGNATURE-----

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

I've just uploaded a new working version (1.1) on GitHub. I implemented javascript regexp support. In this way there is a lot of flexibility to define whitelisted URL. IMHO, this feature is vital.

So I implemented the last planned feature! :D

Soon I'll try it on Chrome. However every browser that supports WebExtension standard should supports it. On Firefox it works!

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZrtpqAAoJEI08Rvun9XHu/5kP/2c0sAgOLFPdTpQwe4/Es6cn

c5KAY1cvVrD7xNG19vRcZ/STPRgwq5PJhYdhGcGTJ5wao3ZBcHc9EABHQU87wmMD

zGugMCKYBekL562m/FRlNKBy8X5OOc8rQtLK3lt7degrEPWeFv1zgGVv5ky7MnbO

BaBknpJnWPbf4GDnjJKzgntwusSzZ2CrxM1vhu1ksn1fD9lRNnoAeJGKr2bDv0Xi

wkQ80yfkY9Xh6OiLW98OhkQS2Rr/WU8NHSe6mt6eXH3PaTexHMp4LGnrIVADh5EI

+tWActFGqoHp8Y+XtFpP3WFVxOuhMiNkBe3HJb7be/gn81ijIfdcsBI5BOc/Y464

dAXtSXi/LJW8eJ2W5jMKPkmC2jfzIvkqq9XqB8eXNFQBLIjF8BMcRi385+auVI+S

VgbEfunF1mckDhZVMDbjE91OF4Jwk+l60aopl8l3eadm9evFILJ7Pk3hCSBFuflV

QbrEU+abKQWj7gKY+gaypegQ1TqEfKOLyK0d1MDdptctr+GtCq0b96iLzXHGYJPo

oRj6K6U0FBwceCY4MmBIeWb5gBqzfYrudOKEoWxa3UAlr+sX8EdT1+aywsCAHGnH

BMCTpTx/g3xDs35REqtrbqPEATz9F6Ds/vFb5V2Qlt2Xy1FsTiWibux+ZAgRSZ1U

frGss0qILUqjZnpXbSuJ

=qDA9

-----END PGP SIGNATURE-----

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

I've just finished tests on Chrome. Extension works with some fixes (to Chrome settings too, it has a bad default behavior about suggestions).

Soon I'll create a new branch where I add Chrome's functions. There will be also a new branch for Firefox. In fact there are few different files.

Soon I'll review fixes and I'll upload changes..

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZsXKjAAoJEI08Rvun9XHudUAP/3GDmdIz4qSxawllfOOBsVhO

RIhjPRu8miUqHVkcBQcNcym4d9jSrcDxvNo6kHUTFFzmTlAJFS5LdkasUkvMVytC

/hNc7yzG+2b7lKo465CAnXz3u166qNiaIqdU9pFr2RfAEY2hPHS8QaLi5jxQJUkf

sRruIC10awaPb31JSTFGqSF2K2z1XLAF85eDCi+48OkNxk6koqnA0bAg/Pi2gL3S

TW3tmMHfKk+8Tb7vbFB6f0uzDvtb321TV6ZYxYjnAU7JXHZn8wYvI7RuI9dEiiAN

P9XzhIM9GJQbfBRea0YsK2ROJ4tcW61OHoCHYge+vyNXaZN+wTXU/ItpHRZIi2eK

A4D06yrpzS7EwsWIr3sNbdIrPDjJhB8o24OV7E1apy2dwY1TNZPjpojhy1Zqn0qO

0fEejfQqplZvLO0xISnVeHq45/wUK1DmfzHcIfgkbSzMFPzWaJq8QsZkTGTcsJej

F/66KUHqmvTv1hglyzD2H6aIWzSh17xWDI75Xv+eHAKydrurc6Q5AhPPEXN/vXsm

5hTcySbgVbNyD5HX++wm7H/2m0R5nArB9a8eakiQvv0RwOFQrkkPRX/gBUhHzmDW

YWG51xgI9se4mmwya9PNWfST26SeZZVbFylZ50wwuEU7rixCnTLpM5qhaFDG0xoO

k9Ge4uSm+UcaEFOyFq++

=Lo7f

-----END PGP SIGNATURE-----

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Hi all,

I updated to v1.2. I improved Promise's code and setting's interface. I picked colors from: https://www.qubes-os.org/doc/style-guide/ and I improved interface following: https://www.qubes-os.org/doc/usability-ux/. I uploaded images on GitHub.

Soon I'll add a new radio to interface because the regexp to whitelist securely a domain isn't very user-friendly. So with the radio an user can choose between domain or regexp.

Example:   ^(?:https?://)?(?:www\.)?domain\.xyz/?

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZsrIAAAoJEI08Rvun9XHubSgQAJ2QX9rLr9DCM9HWSh5xt1Xd

NjGH/P15C7gvfQeJKxuTr1JArktwc3qhgb+JsB/Eyc9LKZwvoFzgzchQj0KY0H3i

TYOZz250n6SrBdLPYrjALufTCplPnTg0VJdyygsnUQ7C3SfmlJOJJG/jrlTCDV8N

qC/WhTIoOBglHOfjlTNnIWJqLTcZ7Gv/TcO6/fM0j+jFY5EpDTJclKbWgSiE+VlB

LnpU8s3LjuJevpTYoFjHTbZ1cp5ZUXTgcjj0ckoofo3afCsSJEMh5u07K2jNZqBA

loM0VUBPOoODWz6U8+eKQn8jSY8nm9wFH4qsz7H88SZk6/iqnafyIqFQQwGc8eNF

YQPVZtPTulRdWi4/cHJqVeUC7c3KM0e17Ix/LqSF6+79SO2SRb3A+OvAdIUMA8gi

lWFNDal72C5Ew8qVXHrLpH+n7EvK4neW9O/xKeAqA+IyclDL2s7XjeKwip62Y4AD

gE1XV6UEhc4wga33tEgCbiCklvUVhpV4GflU6LhUUiyZMGBkgqKrN34WmpRgo1pi

qM7+si1WBXqlQ1+GFxVd6UWpWZCwzAO7zlKzL9Z0H8RJrMMl9kUGLtzfkAc6Svlh

4gYK5ACammIg7Loqoe86eLEr6Ukftqm/rFpsR2ag7JA0vXc25IDWejPUMnG1I1og

rj6CVcOuYax4aiEBDgA4

=0f51

-----END PGP SIGNATURE-----

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Hi all,

Good news. I've just finished to write a polyfill for Chrome. So I finished tests on Chrome. It works! I wrote a polyfill because with Mozilla's polyfill doesn't work properly.

Tomorrow I'll upload everything on GitHub.

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZuBWsAAoJEI08Rvun9XHuTgsP/RFRJrXoNyOmr18+vVAtZIk4

1Qupma3o0Uc0x9+wMIZ5F9lyDvkicFJiB8bOf3UZOOaZKhlXSXqTDumU9kBnoeHO

E4KD4iGY95H6i5/HGtPV38gcE6CQzA5So7HmfQB/RA9DKgszD5GOPr4p1tYPGN5J

9xiYq1htQ+mpHZbgIkdjfSuy4rkkUrm15BXfV/x4o6QbKke2RV2DQhP2VA/YRxqG

+cVDvF1TsKwzSeqO1mnQVhHOw3/qYZ50Nerg95FpZoILqLfmoJRLLU73Pv/J/VFI

qjokZjkCjt+hOok3yNFtlwASg22DwCbbas4cfQplxOsCs+ewC5sjd6AO9EoDX1lS

Xy71iZSGb0aQrhwy91Uxi8MtvxM1epNDVE0YXlEjTeClWS1wIkb98embfKrNw/of

/VjlO83hYucYZAfhsW1QrhJrLFkUDWWTiefYeluowCqUIEpcQF5eythcb1HxMPMB

VcWD8YfvUfls+g05evq0hwklWJvr14cWxQBBvZqe5O//eVth+Jjwaovzgdw3jqUP

82IeoIlmfjQ64QSgywqvZE99paLruBvQuedGO17AiEglsa50j+ep9T3H9ULyivoZ

3sRW6+BJl/4sF5qlq49OYtIrec5cmViFItVjQVHG+8tsxR9sByk9BVw6rbjebljr

y1riPLqolXGZI3HHdNta

=5XtI

-----END PGP SIGNATURE-----

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Hi all,

Finally the compatible version with Chrome/Chromium is on GitHub. I reorganized directories and files. Differences between the two versions are only two files: manifest.json and json file about nativeMessaging.

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZuqxXAAoJEI08Rvun9XHuw0gP/02DMN8Acga4gTBrFS5bGrdq

W+q74AYq5y94Lcrfbwv1I/JwRoBAMP/hv9AbnLXiIPrBGik4O+4jtoEmKWV5rF9f

+C5IZ9IXyFXgA3pAM2BDk2KkuIvMIMaQUY25bzsKMZKvx6u2UDL6Rmq/tfL6zqJU

NpnnVcOX2KzdxIIz12wquVaNDlh+9Fq+5G1UXRshxn2XNaTBzFuEOcAvGz4fO43g

r3NP/pb4ZJHQpNMtYTUN9IkVDnz5mh9ZMrlZ5Bfyo4sjtej0LcXkv5/gJSILDXDQ

evvY+lHWYJAHPXdF/6isPqMsiEmQ4Dw/9di2bielPU3vQmIKv6V+HfEL2l+x/Qe6

IcEJ57ibQjX0DEBRE4J/FALG5syGIdu5pFwBKTBD3zzB+shLwDJ5SKCg9V+o1o+t

EIAyRCNxP8IE1M2wQrS2ADvfxf0QyjoexvHCtNwIoNVQX4Bs8PxInfAQaFZjadKe

P6HV4k9skomGm+ISmnVW1q3DEdllf72UyJhLw7RGPbSle3UPzEs0wChIpItDrfCV

KgQKExXnRi1qGD7pm320OtAAS3PN2gOkxrUVVehq61sIgZDhIiI8uyyelbPzwgrk

HapjrPzFgNWtD81BmKLuzbFeehixl1E0LqvexYXU6UaqJaCaRakNmaq068V3SKDA

INT5amKsRCuBuWtMiVfn

=fYVn

-----END PGP SIGNATURE-----

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Hi all,

I've just build xpi file (Firefox package extension).

However in order to be installed user has to disable pacakge verification globally through about:config or I have to send xpi to Mozilla and they signs the package. Obviously I prefer the latter.

However I think that package's sending to Mozilla, distribution and updates of the extension in Firefox is a Qubes's task. I think that someone has to review my code, then the code is put in Qubes-contrib and from that moment everything is filtered through this repo. Is this correct?

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZwj3+AAoJEI08Rvun9XHuQpAQAKq3GOL64k9mHUwFp2SQDlvO

e3bu4HlYldpHl05s+bYIA9vyVkpUiOQn6ebrMqtCmblGMx0TVPnamdNTzC8lr7ad

3gehv3BP3J/fIvyG8Ch2zuxFK2BFE/k7BbK0Kw5NCRbM3di5kaoRKyfMl4+D0y2P

jhACA19P9ZUJPcMWBHhuG4EYRa6O/2+cKe6yzaIVLePOq+H8QYcrF4UG2D9el+1L

IoxQYHiO3ylE15teL3JuWilgFQMsfxenlwNOzY/VJMPXthKPDwPndurfbJtj6sEc

mZvmfAgyRh5FRqxV2KWtkYg449HDoH+fbZZS6rIYNp//XWGy6SB1oK2A0JepNuC4

31tGIkHAjeNsqaRnuaFR7xI4AShsIFmwMfgzAKSHDh60yy4xG7L5GnKpIq4adlBI

DUp8qcOys+xqCDfjZajTKTOjC56m2NwxeUUNZ791MK4NAtZS2YZ0McKcvneFk0Gn

TGDBGmMX0FySlWZyaqhtVUUDTf6FnO+mfzHeT0Z3e7dlzjbm1ZksuybQPE+icuwv

SxGLniaH0ZkBMA2rGWgd3TwbWaJOe2hDszv8IcbCiC4ndVm56jvNpLkx0Hep0mMf

B0pc1u7AZkCtWrGTFZgmx0C6VMzf8uTYc4p2jcNtpWCo6EPmr6R5NbsbI3VR9ACR

wY+v996pwbB6IiJzvFic

=+DJ/

-----END PGP SIGNATURE-----

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Hi all,

I've a question about Thunderbird's extension.

Are main objectives these ones?

1) Whitelist senders based on email address and signing key.

2) Open/Save behavior about attachment.

3) Context menus to decide where to open links.

I don't understand properly first one and related points, from https://github.com/QubesOS/qubes-issues/issues/845:

- - Open message in DispVM/Predefined AppVM.

- - Do the above if the Sender not in a whitelist.

This means that if an user clicks or scrolls on a message from a non whitelisted source it automatically open in a VM? What actually has to do Thunderbird's extension with mail's content excluding attachments?

Others objectives are clear.

For the third I've some solutions for the conflict with browser's extension. In fact the latter blocks and redirects everytime an URL is opened in the browser. Currently I'm preferring a message passing system, because user has to do nothing when he installs these extensions. In this way Thunderbird's extension passes a message to the browser's extension with URL to be opened and the browser's counterpart opens it. However I'll update on this.

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZxkSrAAoJEI08Rvun9XHu5HwP/jGM1tTks3Or2jXoStPG30z7

JxGBs07cEOHwxjTIrA6MO5sN/VHxcnqtpxsMPTWSftD0hXRLHl3OhX+XEER4Ow6s

X3qsZvNXRp+Op0PKFZA5VzSTjARHckaQ7FL/sbZqzJHNAnYMzK+rmblRZ3BBDzfZ

DDOqqtnYacejF5vp/r0EwhdrcuoIdM1hK7UcsTiEEQAKVYo4SX6IcdNy9XOovcJz

Yg27U0FK3r+A0vCineXv/bRdcW1uKbGqRg4kIj41J1MrfvEop5mnMi6cmchpOxrl

AEJUqac1L28Vx+umefQh/YDEYeaWHLV5pBpmFH8xcB0j2mfUe11VPP8r6mn4hvpk

PQEXjl71F2OVDNrzw9QklnDYTqMZ5DuEaBWQjW1pBY6hN2UI6sYZIsyRMwd8Cq73

MnrLl3t5bCnmGRINGqTQbiVNPv3r16hg35Y99ftJiiIDGrEMj4udkWXFiqBEJned

mt7FPRRc9bmwyEE5lHIAyLhT9SiLGSC/ybuQpQmPIl5dc4FqRP/wbGrw9+Cv7k2J

OJ1t4N/CBmojY5u3AiukbsHqfgxMYwcLQJy88NN/gbI0RMNzSEeAaEqYAYqGmLXp

fi43hJSn1TST2d3PU27e4BdFcQlb4m1QhyKI7LlrNRtvj5jMtg74rdWh/6BQw4qq

pkk1bW3eyBMS06UATXLh

=Vl83

-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Sep 23, 2017 at 07:25:50AM -0400, 'Raffaele Florio' via qubes-devel wrote:
> Hi all,
> I've a question about Thunderbird's extension.
> Are main objectives these ones?
> 1) Whitelist senders based on email address and signing key.
> 2) Open/Save behavior about attachment.
> 3) Context menus to decide where to open links.
>
> I don't understand properly first one and related points, from https://github.com/QubesOS/qubes-issues/issues/845:
> - Open message in DispVM/Predefined AppVM.
> - Do the above if the Sender not in a whitelist.
> This means that if an user clicks or scrolls on a message from a non whitelisted source it automatically open in a VM? What actually has to do Thunderbird's extension with mail's content excluding attachments?

I'm not sure what the original intention was either. But the first step
could be about attachments. The current extension allow you to open all
attachments in DispVM by default. It would be nice to configure this
behaviour based on sender (identified by a signing key).

As for the message - maybe it is about built in preview? So, it get
blocked for not whitelisted senders? Opening the whole message in DispVM
could be useful feature too, especially for html emails. But IMHO it
would degrade user experience so much that nobody will use it...

> Others objectives are clear.
>
> For the third I've some solutions for the conflict with browser's extension. In fact the latter blocks and redirects everytime an URL is opened in the browser. Currently I'm preferring a message passing system, because user has to do nothing when he installs these extensions. In this way Thunderbird's extension passes a message to the browser's extension with URL to be opened and the browser's counterpart opens it. However I'll update on this.
>
> Best,
> Raffaele.
>

- --

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZxlFKAAoJENuP0xzK19csf/AH/As5bp08kEmPKNhu2r3B7jbl
+OP2MIPNf9JagzJWdb5Ib+abu1lkB23VWNgR0W05rvrcTunMz4k64hXU6eO6KZce
mFnQitRtxqg6ZeIhCIbtun17HAQD/4EboX2ilpQNfJRsbk6qcxye4NsNJIuJy2FM
p9Joz1iWw+wcctcS4AONlkuT4n6DgQExd32n1jYemUutFkcgDGnBCpO8ubmu8yhu
nCFAaA89MaxX5r1Zj7YKpNJpiQ5n09AhaG133u6DFl9K1t3ed6eDrWThSQdtawly
TK+DjLhbQUH/Lm92Y3eNJkevN28YPxwkPV3o7LAEEGKQ3TqQ8f1jbKR+gBnoLmc=
=fst+
-----END PGP SIGNATURE-----

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

> I'm not sure what the original intention was either. But the first step

> could be about attachments. The current extension allow you to open all

> attachments in DispVM by default. It would be nice to configure this

> behaviour based on sender (identified by a signing key).

Yeah.

> As for the message - maybe it is about built in preview? So, it get

> blocked for not whitelisted senders? Opening the whole message in DispVM

> could be useful feature too, especially for html emails. But IMHO it

> would degrade user experience so much that nobody will use it...

Exactly... Furthermore I think that with plain-text representation and extension's attachment protection this feature is useless. Maybe there could be a button that permits to open only HTML emails in a different VM, according sender's signing key. I.e. if a sender is bad, user could open HTML email in another VM, else user can see there.

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZxlsxAAoJEI08Rvun9XHum7oP/A1OItc8hxC/AbqI+HHOYwIy

PxU56QkL25HZF/rWrPqCPnJgXzkG+PVIJ0eWzvAXbz6rtEl5Zk6fZ3A5JBFWT/Gl

ENeXweA7Cn48yPdsCB6rW2owrUzAxx4GtMqJl5DuJPQL4sgaHXSWTaUhDhC/oqk5

1jvi6Mw4P+glPXnw4xIT+77kxkxvV0BixUSojUfkgL1EwuFdGRWydP5rqZXiR18x

ZvvnTa5M+CCRIP5aIKaOAMLB26pQY3tBdycn7p1EUCqUAsBTWz6FO73oNgAP6hlY

mt3IePpKz+eJ30estaMywc2Vw+QTb/5X7WGb9oasOvPL8Ojnl4Bz2EWxd7mXb8fM

IDneVaoJ9Ua/rfzbbM3kTDIyfIzZuN5Rhjl7CC1fyallI/7pO5ufj87tZGrrXFth

8ydK2sJA2ZVdex/XltEdpZv1ADnOgK2ohmeETbBPg82cst2Ghq1EvVNUd93sxaNC

0qNxb2mE9cRvXmIGzIE+c2O8RBDdKvfAMm/oUF/BQtS3YrAJTcSxkcvZ51j6lUj5

Gh5lSh1QDr1ntV3h4w89OYmV8gHrek/JmjNV0s4Xu8KP9p+AhT28loiicxW8Sbg9

xGmwaFN7LJI0uFwe0xGgyywQFHJQJnaDC2ll0zvWwzNYvzebdC8z76n/IyYckUKH

enEo+S5H19Sp+WewzJZV

=hR7j

-----END PGP SIGNATURE-----

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Hi all,

I've a question about HTTP redirection behavior. During this period of testing I'm noting that redirection, sometimes useless (i.e. domain.xyz -> www.domain.xyz),  is very common. Currently, before redirection, extension treats the request according its settings. However I don't find this behavior correct. If user opens (or whitelists) an URL in the current VM, he/she considers URL's resources as good ones. So if user follows redirection requested by the server, there aren't any other risks. Because the risks actually comes only from the whitelisted resources.

So I think that redirection should be allowable, what do you think about this policy?

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZzS3dAAoJEI08Rvun9XHuvUoP/0zmgrNWHsHc8n7I1JGfDeKP

4sHTuHkArAjPqBMubkNpmFkidDpY53McNFrvBrHWRMCZSvbbP/Ztfoe1eizpnHqw

DfBAvu1oEMFYGJrBh1+QM/EXqEBkV32EwphSMdJkIK0oq3BV17BpOYL3TtWGuy1B

RVt37rwWs0OE8fvWfCA+2q6RkbeGt4jMnCMxs/PW85XvH8idIyXSqnr4dapoGcMT

CyKhYrOfDW1Zg42CilQitD4RCYOOxgDJ3ut+uy434eKYTcfW80YuG842hzzgIOdk

23v+A0c6OjGCbOieAnimMuoTX3k1uHJkf2UOXSEmiRa936VybrXWzT3z2jPJebRJ

+4/J2lOn9II6j5nlD/col8Eg4EsSY0Q3GhlRNfB2DDjiZAzQcIxeZ9XfjiLqBuIT

M3hKy9JGxzpPvW2d7duPmezYQBkwRtJOBwKDY/2Q5Otn+qdulPuIB1ygrZVOTnkA

C/eDaItDkB5pm0q9NREEFPvHCVn3o48qAImSDwod7D9BsOwMwIvz0FE3/icAhs3a

ePs1+RF3PVimrKmLMGK5eED9A6GAzWCWwqthy0boRiZEJpurI+8wDmZO4NuQUhJi

+kgQZbwUvTg52GJPrg54ufEDAHRXue1UmUGCU6QznvSU0icEtXZXkm2wZEkdxRAv

ddK3UCHqnAWNjaZSfKoH

=yjcf

-----END PGP SIGNATURE-----

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Hi all,

Today I uploaded the version with redirection's modification. Furthermore I fixed some issues and I added some features. Maybe a feature to implement is domain name verification according RFC spec. However I don't consider it a vital feature...

Soon I'll open an issue on qubes-issues to request the integration.

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZ2S0JAAoJEI08Rvun9XHuoDwQAI1ZTcVpceJjraqx2TEqC6k6

JD2bLP12P1Fi+klI0vSDJmp0bt0Ap1AjlD6u7lEsn6CXulrsA4WMidKXlwQWquiA

6WIweX91W1qBxsNFaB2mONxlaOgwfRV3L8Fu5qjuytwqahxEOYMxsQqBVQwV7obk

uH5Ic3cs1SA712lKCJV+QtjyhzjyEMYFAZZHPWrWp82RkxwQPmcWJT8vWH6Qkwd5

yUbLyK33rP1gLcTJSebqVjmLIZDpRF150mMfOkyc3L3N35Cfs6O3X3ujP5UUI1z1

GXKKlcmjjJFVkPYrMMa1zjnTHkVUYH0vbt2LsiKCtBwvCJ+9mmriTxMsmRT0sdb2

CPx4TMe4Hf3VGM7byZemDEH5adDwgaE6AiqxBNz1FpKJofHAxub+klJzU7qZLo4w

tbIas1J695Z6GGGau4ldciTSwMubZoatyIECplWEz4sJVmaH8DWuXscz70HJXpt0

Z6sqEBx7aBITFCSpvPOY0hA1nlJrBn99fMNJms6ZZ3Kpbg1aKsJNLQqMyRSw5dTs

N+cLqKSw9dR24zUaRN9vCsiKj8+sLWNgpPUyRdTCH+gpxt/9JUJM+v9M7IOUtgR6

jGdjxMtOBDhjxqKLBvdIpiK38lEYYEHnBjA/SKjUHJJ9NrlPxwnNAKKgmNeR7Pik

oQlfqKNQKXe4Q/iYNZcc

=eQPM

-----END PGP SIGNATURE-----

[joev...@gmail.com]

How do I build/install for chrome?

Right now I am using the method that uses tampermonkey to change all href substrings of 'http' to another protocol of my choosing, and creating an xdg-open association to qvm-open-in-vm.  It works, except for leaving behind empty/untitled tabs in the browser.

I've coded the replace function to ignore all links to same domain.

Can you elaborate on your question, I don't understand.

On Saturday, 2 September 2017 04:00:32 UTC-4, Raffaele Florio wrote:

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Hi all,

I've a question about HTTP redirection behavior. During this period of testing I'm noting that redirection, sometimes useless (i.e. domain.xyz -> www.domain.xyz),  is very common. Currently, before redirection, extension treats the request according its settings. However I don't find this behavior correct. If user opens (or whitelists) an URL in the current VM, he/she considers URL's resources as good ones. So if user follows redirection requested by the server, there aren't any other risks. Because the risks actually comes only from the whitelisted resources.

So I think that redirection should be allowable, what do you think about this policy?

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Hi,

I've just uploaded the repo with installation istructions. Yeah I read that method. However I don't consider it suitable for browsers, as you can read from aforesaid motivations.

Before update [0], if an user opens a whitelisted URL and the server responds with a HTTP redirection request, the extension treats the redirection according its rules. So it could be redirects to other VM. However I don't consider this behavior good, because actually it doesn't improve anything. After update [0] the extensions permits that type redirection.

[0] = https://github.com/raffaeleflorio/qubes-url-redirector/commit/868718dcb0d482e5d20ba3d2752e93da765de45e

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZ4e02AAoJEI08Rvun9XHutMkP/3lyK7VqzPgVLYvn9CjKGikw

LMlmtNcsxKdw6c8CkeFcbSU/X6IWUcrkIB8OBOozCbHNbTpJtdtmxDn9KBoadyak

oYXoq9XzqWyVV6jCaGWB6kEA5f2DM7FYbiajNCJnTTcpd63t/rw+FuZ7GK36QCqS

2SO4hFv3w6U7Ifcdd8dn23ou8CjRQzheML8i0ITzMCcFtXQwvbtL1sOPRLHoAevp

nticJJ9U0XNvF9QbI8EX3V5dxmyjB0NQFwdpuU6l8ohmzVbOqIc/E96lZQZKStAa

11z/gnJnf5AkSZgtvymvtSvCM7EpFOMvCd7XZT+CqTjPe62mtv7kEeA0IjCBcL5A

l9rfPxWBvaEi6LPZPOJ8unvsP8cjYS2xCaZ9k5oujJ7fStVx68cPDt3Y2Rr94peV

CwMWqmgNX5WKLhT2i5UEoZzfp5FRNjBB77iMnbYXY6+GV29RVVRuppYaLomuzXsL

JCWGAC2KHB8mvT0a928U+sNkRMCE5TMxyXIK6LPRPK9aOOM439YZWqIzTe4FdUYT

7/4zlc8q8rMbQxQDyEhAi0RabRG89lOvQRE38S0+gbmLxNDzyxSfu8MWlLKzIQwE

018Iqs3ah6/pH4o6u3DUBnObYRL8pLwAKLTLRzJtygTFGHKLG0xyNsVGnOPqBi/6

MxmaMQn3kc0yDRWNmp4R

=Lsmq

-----END PGP SIGNATURE-----

[joev...@gmail.com]

Thanks for the instructions.

At first it would not load as an unpacked extension because manifest.json and other references to polyfill.js.  Your git does not include polyfill.js.

So I got one from https://raw.githubusercontent.com/GoogleChrome/inert-polyfill/master/inert-polyfill.js

Now, several errors in the extension and the options won't save.

main.js:86 Uncaught ReferenceError: browser is not defined
    at main.js:86
(anonymous) @ main.js:86
menus.js:22 Uncaught ReferenceError: browser is not defined
    at createMenus (menus.js:22)
    at menus.js:95
createMenus @ menus.js:22
(anonymous) @ menus.js:95
webRequest.js:35 Uncaught ReferenceError: browser is not defined
    at webRequest.js:35

[joev...@gmail.com]

My Version of Chrome... running on Fedora25. 

Version 63.0.3236.7 (Official Build) dev (64-bit)

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

The polyfill is at [0].

However I added it as a git submodule to qubes-url-redirector. If you used git to clone my repo you can get proper file following instructions at [1]. Essentially git clones the submodule in the main repo. In this way there aren't missing files.

[0] = https://github.com/raffaeleflorio/webextension-browser-proxy

[1] = https://git-scm.com/book/en/v2/Git-Tools-Submodules#_cloning_submodules

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZ4xEnAAoJEI08Rvun9XHuuvQQAMeiCjaqIgux55PBGmzqAFa1

SonVnHCb8eLUoXiF0VrlIZbiTJU7SzCK4r2iLUBjIhiIhAk5smxLllPXg7ZUmYLY

2LRqRI23X/XibeJhTuYliODKfa8GtRDFt0sWM1oO2DzwmSf6BN7nCxHmnx4gdNOy

3OXEPjERhY6d46o5b23j0NNm86TRbI2cYqfwzJGZdVb0yacXiBlycRJ8t3b7ZiIn

GereKfKQDxuM3QBbWa26gDKWqrHN4MiDLI4hi5HNrGpTCG0xpbU5uurSQz+HCSaV

T45h9KJcHJ25ng8H6q5B9PKrTh5RAvZgIatmQH69nH7s8bpCNNjfAwY442/NNuc3

EihIL/V+YFMf98GainSHmEhwFgikOhIO9WAkeeWwtlpm4RrmRNaVaPD8xAelzBdF

Hvl6QzxxGX6vAENXYG6GXWKKAlH2Y00EnihCBZI0HZm7cifY95IOXuUTXynEnfs3

rSnE5I1fJDzxdPgJ3DjZf1gYQVQ3hxTCddXcR8OJFulAMSRjJHoXifRJgycSWqnT

13QFFptZlA2hSK2HBJrQkqtj5/97EkWbpKq/CIoTgAZse+7hDeVqZ51uDIplWOky

OcDPpsAFLQq+q8cjgcbY23Zw6OZ7hLmagEPfHs81pIHuiXylET65i9e2lEWKxQq1

A6hkfFhf8HpTdrmlqFHH

=2pxe

-----END PGP SIGNATURE-----

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

However I added to the Makefile the procedure to clone the submodule.

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZ4xLBAAoJEI08Rvun9XHu1MQQAJ2Ai8zSGPE+LqL5Ph/ltULt

efyaAeXmW4PQXI5Yzysg18M8HC6M+heqWsx3+jyu7VbcWGHL8O0DJpC+RVvI/0U6

PkJl0hwxgKuu5a9RLOp5b01Cal4NPHoBuYh8GddCDTdl3RZfE9QWuNqhJuLcTjYd

GiRRn6zmYRtW01fmgcARqfRx9XivZgaBYhRYetYEH+/hfGGSByY2FFBrzu6EaxFq

BMRBTMeIOub4h+MuS9buRG9uGl8SCIV4ZhPex6Ri5IY2SebUCQVA6WbjuAUAS064

dwz7rglfu44MvKSHla3BfLBidBT1w+9ju9iIKVK/3S7O+hBkKGN698kHdq5sckP/

1ZTYMQL3Bs81Qaw3STyaXAAcM7f/r3HXRgdAa7vLo1TDqsKJTGaRx1oCd/4pYcrn

u8GJSmWYn6jDkXm/Q2w9CyM9sMwFsXZevIwm5bnlC7vdr+1MyFKtnM8tV4bYEScl

MUO8dwq5plDPIjlogq11q5b6qu7uFsTuKC1rThlomosOYf098A4vAk3P0PUrhU7G

a19rBn97lXTv4Iz3rR7wpvGPSymrg+p57e9GqW2oFeHrrU+rFiIpsIi3LmMVRAkv

RkQteNFNIhWISkjSAXbQHRj/b9MmfiNq0ZasCdg/fvt3fEisrFLH8LQNAejQAYzv

p0Y//+DM9HJ580I2rE0f

=IA7i

-----END PGP SIGNATURE-----

[joev...@gmail.com]

Great that works now.

I've a question about HTTP redirection behavior. During this period of testing I'm noting that redirection, sometimes useless (i.e. domain.xyz -> www.domain.xyz),  is very common. Currently, before redirection, extension treats the request according its settings. However I don't find this behavior correct. If user opens (or whitelists) an URL in the current VM, he/she considers URL's resources as good ones. So if user follows redirection requested by the server, there aren't any other risks. Because the risks actually comes only from the whitelisted resources.

Before update [0], if an user opens a whitelisted URL and the server responds with a HTTP redirection request, the extension treats the redirection according its rules. So it could be redirects to other VM. However I don't consider this behavior good, because actually it doesn't improve anything. After update [0] the extensions permits that type redirection.

[0] = https://github.com/raffaeleflorio/qubes-url-redirector/commit/868718dcb0d482e5d20ba3d2752e93da765de45e

I do like the current behavior for 302 redirected links. 

Testing with https://httpbin.org/redirect-to?url=http%3A%2F%2Fexample.com%2F
Whitelisting either httpbin.org or example.com does not prevent your extension from redirecting to another VM.  Only whitelisting both works to prevent it.  This is good.

By the way, I do use other js userscripts to remove some of the ad tracking redirections from google and facebook.  It removes all 'onmousedown'  and 'onclick' from <a> tags... and also parses href attributes for things like aclk?sa= and s_dest_url= for google and l.php?u= for facebook.   That way links go straight to the destination domain.  With your extension, either way, it will open in another VM, but with my script I can avoid the privacy leak of these ad trackers.

[joev...@gmail.com]

Also, can anything be done to prevent the original tab from closing when redirecting to another vm?  If the link was set to open in same tab, such as google search results, and is then redirected to another vm, I don't want to close that original tab, with all the search results, but rather have it do nothing.

I can work around this by changing links with link.setAttribute("target", "_blank"); so they attempt to open in another tab, and that new tab disappears when its redirected to another vm.
But it will need some logic because it should only apply to links leaving parent domain because otherwise it would be whitelisted.

Thanks.

On Saturday, 14 October 2017 06:56:11 UTC-4, Raffaele Florio wrote:

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Yeah, with the next commit I'll resolve tab issue.

I know ad-tracker issue, in fact I implemented an object to escape Google Search rwt manipulation. However I think that it's a privacy issue not related to this extension. Maybe I'll write an extension or I'll write an object that implements this protection used by qubes-url-redirector.. Obviously I prefer the former.

Currently I wrote an anti_rwt extension, but, as is, it works only for Firefox. It works by defining an 'immutable' rwt function.

One cross-browser, clean, solution is to redirect, before any connection is made, to the original URL when an extension detects a request to a manipulated URL.

Another clean one is to inject in every evil page a script that use the Firefox approach. However it seems not reliable.

I don't like brute-force approach such as for each link disable that manipulation. Currently do you use an extension or do you inject javascript?

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZ5F7LAAoJEI08Rvun9XHupVIP/12HRbT75p10HYeddUogh9ss

IkoZmX6f2LFeIaEWLwGFe5OobJZ1pUHuNHGtuOO8pG21TMm2D0bGlLhBQK25o6d0

3xeqhl+duOs6+CA8B78bX4GsS45YMsiyKKzLg4+sxbRlCZINsLBlo6PtsoqHiLYo

plRNGirkjTEzM9vD3a72UHvVJGMgvDwZj9TrD7Sxu1NbWPtsr67i8qYvznIrl/hj

c71oc2wcEO1Vbxx4xRc3tK8yjBFz3X/8tPIX7BDGQsEoyUKyVhBglC0BINRxvtz3

uxJh0caM1RiXeRnSOs5HGobLC1WNmmV6YTMBwhAMWCVJMKhEe7gsfV1VIP0Jvqst

RrNu5qN9PHxSDO6N2j2iSNoLgLjNV8oYmys4BrK4IoYrP68TLDS5vCSv0P/V7MSR

cHhE6bup+014x9jou3XmgDrSu4/mNSsJwB1vEeB+qEcRvzgD63kINXVfBSLlHUwQ

4ZNFUO+jp04x0Ho2JwRw+LOB75Qj+Z6t2yAj1MSHQ07u4Pzer3GtQ1JWaPKfxREI

6mJWETSyQNYk5tZagTVXOFZIS6fS1ecLjXuX7Bi7cxpSi1l2jrUJxRya3IYvkFPf

x1v0jjIXjZWs9mWOYEx0wGyqZT+2Gchb6iqK11bkoAB3voE4pXOTECWAb/KIroMG

SGUOzqSDqNL+4Xo9ZLqA

=zhHP

-----END PGP SIGNATURE-----

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Hi all,

I've just released 2.0 version. There are a lot of changes in the code and related files organization. I implemented tab closing prevention but actually there is a Chrome issue, [0].

[0] = https://github.com/raffaeleflorio/qubes-url-redirector/issues/2

Best,

Raffaele.

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2

iQIcBAEBCAAGBQJZ53XSAAoJEI08Rvun9XHunPwP/0UcwJuR4GDW+4csfQ1EUzAy

ocOknJdESRgcdRU1ipaeX3JRjtfy/GbK4prCXHdjRClUyb7yOtPfJ4qPIEsMKr+a

htQg0IYCBxnkcrLzxHTZFwOO3LI4kn4j1elsWdBFilSMH1PC0pWbQgjA++kQPpow

nhRTLLyMsqbTdBKYbsGrMNhEs1SSrfDO1DCDzM3GYTuUavJ2AGVZkFXTOq3nraGk

tsBPq4bgjpnbw6vBL4+OjdFfJ/pNTEA0RC+PBIyJLVoLsHdDruB5ZIeCeGzNne3s

V+uwOTjwQergPlOYu01/68SbS3/obXS288bUalHncO+Jpr6t+KB0C4Y4ePvWrN6T

VMhjAZXmGZfqpOTcRPO5eynrCQhYFWhCC2jUgF6sbzioJKcJVRE+hVAJH9HjUQYa

Kqn2T2BxnhRc1PSgTzCDksSiCu5WSM9lwGapH8nShBtM04CVvjTFOaj+W5Vikeu8

CPG907k5t9Bk0Ao7dpm5xTCpRRY0WR5XpWSRMaeRH9RpxKbZsCPIdKFTvMorIKIJ

N21mwT39YG6ideZXKytwqArX7MgORLzdlxPNbNtfrTQYlQpoNq2iQfJzQ7HYaos2

KruRYjV8wkOmdTBGY2gtpNJKR1XSCZXADts2gU6gVIwmW6vxVdzbBIi/PTFUjnuK

Ovc0LzTnbyn2PaXsoxlE

=l/Tg

-----END PGP SIGNATURE-----