qubes-url-redirector

Affichage de 126 messages sur 26
qubes-url-redirector Raffaele Florio 02/09/17 01:00
-----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.




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-----

Re: [qubes-devel] qubes-url-redirector Raffaele Florio 03/09/17 03:48
-----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.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] qubes-url-redirector Raffaele Florio 04/09/17 09:36
-----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-----

Re: [qubes-devel] qubes-url-redirector Jean-Philippe Ouellet 04/09/17 20:08
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/
Re: [qubes-devel] qubes-url-redirector Raffaele Florio 05/09/17 04:08
-----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-----

Re: [qubes-devel] qubes-url-redirector Raffaele Florio 05/09/17 10:10
-----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-----
Re: [qubes-devel] qubes-url-redirector Raffaele Florio 07/09/17 09:24
-----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-----
Re: [qubes-devel] qubes-url-redirector Raffaele Florio 08/09/17 08:07
-----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-----
Re: [qubes-devel] qubes-url-redirector Raffaele Florio 12/09/17 10:13
-----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-----
Re: [qubes-devel] qubes-url-redirector Raffaele Florio 14/09/17 09:21
-----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-----

Re: [qubes-devel] qubes-url-redirector Raffaele Florio 20/09/17 03:08
-----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-----

Re: [qubes-devel] qubes-url-redirector Raffaele Florio 23/09/17 04:26
-----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-----


Re: [qubes-devel] qubes-url-redirector Marek Marczykowski-Górecki 23/09/17 05:19
-----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-----
Re: [qubes-devel] qubes-url-redirector Raffaele Florio 23/09/17 06:02
-----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-----

Re: [qubes-devel] qubes-url-redirector Raffaele Florio 28/09/17 10:15
-----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-----

Re: [qubes-devel] qubes-url-redirector Raffaele Florio 07/10/17 12:38
-----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-----

Re: qubes-url-redirector joev...@gmail.com 13/10/17 09:54
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?


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-----

Re: [qubes-devel] Re: qubes-url-redirector Raffaele Florio 14/10/17 03:56
-----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.




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-----


Re: [qubes-devel] Re: qubes-url-redirector joev...@gmail.com 14/10/17 17:20
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.

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

Re: [qubes-devel] Re: qubes-url-redirector joev...@gmail.com 14/10/17 23:00
My Version of Chrome... running on Fedora25. 
Version 63.0.3236.7 (Official Build) dev (64-bit)
Re: [qubes-devel] Re: qubes-url-redirector Raffaele Florio 15/10/17 00:41
-----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.




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-----


Re: [qubes-devel] Re: qubes-url-redirector Raffaele Florio 15/10/17 00:48
-----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-----


Re: [qubes-devel] Re: qubes-url-redirector joev...@gmail.com 15/10/17 11:21
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.
Re: [qubes-devel] Re: qubes-url-redirector joev...@gmail.com 15/10/17 11:45
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:
Re: [qubes-devel] Re: qubes-url-redirector Raffaele Florio 16/10/17 00:25
-----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-----

Re: [qubes-devel] Re: qubes-url-redirector Raffaele Florio 18/10/17 08:40
-----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].




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-----

Plus de sujets »