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
>  
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fraffaeleflorio%2Fqubes-url-redirector%2Fcommit%2F868718dcb0d482e5d20ba3d2752e93da765de45e&sa=D&sntz=1&usg=AFQjCNEQoD-PvL1auQoZSYOuwQXeJt3yWw>


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.

On Sunday, 15 October 2017 03:48:48 UTC-4, Raffaele Florio wrote:
>
> -----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-----
>
>
>

-- 
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/74eaa9ca-e491-460a-ba88-e9e704bb16de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to