PGP Public Key


-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQENBE7vTfMBCADrsRfg06my/tJeGYFoNQwa8CZvy8GRvzQwFozlIntlDQtxIYEH
nW/imqpHyPKzs+28CS3eAEvPZvMj7yrQNubPwwjcS2IQq5NYOJXqXcyQiR6Nu6Le
10rnkvg5YPKaqsQn1KSTuFJA5/wUZtVrYF9O1fluE7xWQVGdfA7j14nAI56BmrqK
nWiBVQWY4nwcwGqv30cse1FOII0CQ6+1dzFbB53fgzUDGmORsFLuHX9kq2bQlday
FL5iP/Ge3OOt/Gz9Uh97mEmveKpnhw4Ic5Y61GY4CFHXAAdHz8AEYEGNwQ6qdi8F
peO/gOQRWzgJnI2EbzDGE8tf/y16S4BrhCSfABEBAAG0FkNsb2RvIDxjbG9kb0Bj
bG9kby5pdD6JATUEEwECAB8CGyMGCwkIBwMCBBUCCAMDFgIBAh4BAheABQJYaXBh
AAoJEC/ixHrG0m4LxAIIAL2XDiNHTfgrgB7t8JsnvCrubXI8AyUseSJ/htvv5qdP
Mmw2FuaXFqzM9TIfzfuG3OLtwmPxkP66CD7/NWZ0FTb8+9jnCEKhD+C5DtJdDYkB
IUIaQc0LiZs+zWX6I9hM1ciuJ1I3QHiFQLFxi6JVrglJyrVX+sxbfm3sjFJ1qYT+
cASwKNAJJ4c5+P2X64+Uj5g6PRTD7eHnwbUc+6TXyyjrxs3ZOcMKMW+NWCd+XOQm
UXZIco0+CL7bpX2jicM8de5FCh0QLLpEBdsdS2zJT+U5CdL4oaF+mACjrpEtE4Z0
R7zbO/8cCWOfxntHRrt8W3G+a5FkI6iwMU/ALnJk3wq5AQ0ETu9N8wEIAL3XzaWK
5oK+bdzAFZcQ10xmonsrbHp/JZOXh8bvEktMxSqI37GcrfqG3BpIDwAJpNzuZsKe
QBulItka1F41P7usYLI3midMKIkeIA0vBg08HoAFC+2YiUxFTFXdPp+sijfNcAAK
OK1l1vU0vvpBwcULLB+e6EFnIoE1AQDKgimIlmEDFFny6AvjYEHy8UayNT9NBnDI
PUBHWFGCkLN4aStUmkZcHTxZP9AJlpFAd02GPzMy8ptVDLtsiylGKmfEeT373ULM
d9JJoo2BlwFCqYrIhGHNL8VyW8CeB+9Szl9fYtr/pT6G5lgaiS7ooCnm7TPY5Yxt
JNO8Pyh44jJB9lUAEQEAAYkBHwQYAQIACQIbDAUCWGlwZgAKCRAv4sR6xtJuC8xq
CADjH8fSnj23O+tBaXKwipygARa878Gqc1gUVvoQA3DUDtqUP04qoAmMaHF71cWk
C8292ylo/zsxrVnb21qpmoZHP8sJkomR+yNYzQysh9idxo3fZ44gKzHv4pZi+a0B
ncXx9cGeZHxyhPWDnN/GEEneOg9fWFxG3d3a3I77C+MpejpqNIofxarcvDOmp+ry
CCd7zKCgfwWtgek7MQ7jKHa6ZuwQ5WXZq8Sv4x982+I1eJnYCSQ9aXJhJRM4ETXn
Lfh5+2HCJQhcwCqK0YnxTYB/tt1Ssb0YaaViiNYgl8u53e9BF8L5hlAnMLyym8as
M9xTV/6EIWpqZL04zHjNfDwt
=n1qy
-----END PGP PUBLIC KEY BLOCK-----

An alternative approach to so-called WebRTC leaks

Posted on Reddit here: http://redd.it/32d94q

Recently there were a lot of discussions about the WebRTC IP Leak. Almost all of them are talking about a “Security flaw” or treat it as a bug.

However, many articles about the WebRTC [leaks] talk about a solution: disable WebRTC in favorite browser.
Two questions:

  • Is it really a “Security flaw” that needs to be fixed in browsers? Look at browsers bug-reports to understand how many different opinions exist on this.
  • Why the browser can go outside the VPN tunnel? How many app/protocols can do the same things of the WebRTC leak? So, is disabling WebRTC a sufficient solution for those who use a VPN to avoid exposing their ISP IP address or traffic?

I will explain details of the issue. But first, if you are connected to a VPN service right now, try this:

ipdetection.zip (source available here )

or, under Unix try this (try also as root):

for s in `ifconfig -a | sed 's/[ \t].*//;/^\(lo\|\)$/d'`; do curl --interface $s http://www.clodo.it/projects/whatismyip/; done

Is your real ISP IP leaked?

Details

When a user connects to OpenVPN, the main interface (ethernet, wifi etc) is still available (also to talk with the VPN server itself).
And another network interface is opened (tun/tap).
This is the scope of OpenVPN: create a tunnel.

As a plus, OpenVPN can be configured to push a directive from the server to their client: “redirect-gateway”.
This tells at client-side that ALL traffic needs to be redirected inside the tunnel by default.

Almost all VPN services use a specific option of that directive: “redirect-gateway def1”.
From OpenVPN manual

def1 — Use this flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.

Now, this means that the original 0.0.0.0/0 route are still active, but there are other routes created by OpenVPN that override the original based on precedence.
But 0.0.0.0/0 is a route assigned to the standard interface, while the new 0.0.0.0/1 and 128.0.0.0/1 are assigned to the TUN interface.

In every OS, when a connection/socket is opened, the program can choose a specific network interface that needs to be used.
This is not common, because most applications don’t need that and let the OS use the default network interface.

The program above do exactly this: bind to specific network interface to query an external what is my ip address service.
When binding to the standard interface, the overriding rules of OpenVPN are simply ignored, at least under Windows.

I think browsers do the same thing in WebRTC discovery.

Can a VPN service based on OpenVPN resolve the issue server-side, transparently to their users?

Yes.
Simply don’t use the def1 option in redirect-gateway directive.
Without def1, OpenVPN client removes totally the 0.0.0.0/0 route, and re-creates it at disconnection.

But I don’t recommend this approach: with def1, if the OpenVPN process is terminated, the overriding routes are automatically deleted or unused, and traffic continues to flow over the standard interface.
Without def1, if OpenVPN process is killed/terminated, the user remains without any route for his/her traffic.

For me, a good VPN service needs to use the def1 option, for the final consideration below.

Final consideration

WebRTC IP Leak is not a fault of browsers.

It is not a fault of OpenVPN (that is designed to be a Tunneling software, not an Always hide my traffic software).

It is a fault of users, because they trust the standard OpenVPN client for things out of its scope, or trust a badly-written VPN service client software.

Users need to use a VPN service that has a software addressing this kind of issue, or need to understand how to configure a firewall or a router.

*Disclaimer: *
I’m the author of the client software of a known VPN service. Anyway I don’t cite it in this reddit.

VrSpaceTunnel

Update: sources released on GitHub.

I’m done some game/experiment during my study on DK2 gameplay, this is one of them (about body movement and reflexes). Maded with Unity 5.0.18 Indie and Oculus 0.4.4 sdk.

Image
Image

YouTube Preview:

A guy that enjoy my game (with the correct gameplay: without controller!)

Windows: http://files.clodo.it/projects/vrspacetunnel/VrSpaceTunnel.windows.zip (45 mb)
OS X (UNTESTED): http://files.clodo.it/projects/vrspacetunnel/VrSpaceTunnel.osx.zip (47 mb)
Linux (UNTESTED): http://files.clodo.it/projects/vrspacetunnel/VrSpaceTunnel.linux.zip (57 mb)

The game need an initial calibration, to detect the maximum and minimum position a player can move it’s head.
Press X to reset the calibration. Press R to reset Oculus Rift orientation.
Press SPACE to start (and restart at game-over).

Can be played seated, but i recommend to play it stand up, with hands on desk.

Works at 75fps with my GTX 570 on an old i7. Press F11 to see the FPS, and 0,1,2,3,4,5 to change graphics quality (0 fast, 5 is best).

At game-over, press SPACE to reset and look left to check if you beat your highscore.

I released all source-code under public domain. Not well commented, it’s just an experiment. It works with Unity Indie.
http://files.clodo.it/projects/vrspacetunnel/VrSpaceTunnel.src.zip (85 mb)

The zip contain parts of some third-party assets, but all of them are totally free in Unity Asset Store.

Music by Imphenzia: http://soundtrack.imphenzia.com/ – i used the watermarked version to allow me to release the entire project out-of-the-box under open-source.

No more improvement are planned, unless people like it 😛

My best score is 4307 meters 😛 Enjoy!

Sphere spirals, 1958, MC Escher

Immagine inviata

Immagine inviata Immagine inviata Immagine inviata Immagine inviata Immagine inviata

Download MP4

Rendering di una isosuperficie ispirata da un’opera di Escher, Sphere Spirals.
Formule per Povray da “Almost Sphere Spirals” by Tor Olav Kristensen (2002)

‘Tor Olav Kristensen’ said

An isosurface shape inspired by M.C. Escher’s “Sphere Spirals” (“Bolspiralen”) woodcut print from 1958. The edges of the four spiraling bands on the sphere can be formed by an inverse stereographic projection of eight infinite logarithmic spirals in a complex plane tangent to a Riemann Sphere onto it’s surface. I found some useful information about this shape here.

Shot 1: Twisting rate a 1.5, 4 bande. 1920 x 1080. Rendering: 2 ore circa.
Shot 2: Twisting rate a 0.1, 1 banda. 1920 x 1080. Rendering: 20 ore circa.
Shot 3: Twisting rate a 0.5, 4 bande. 1920 x 1080. Rendering: 8 ore circa.
Shot 4: Twisting rate a 1.9, 12 bande. 1920 x 1080. Rendering: 1 ora circa.
Shot 5: Twisting rate a 1.0, 4 bande, fog. 1920 x 1080. Rendering: 8 ore circa.
Animazione: Twisting rate variabile da 1 a 3, 4 bande. 640 x 360, 30 fps, 600 fotogrammi (20 sec). Rendering: 2-3 settimane su 3 macchine circa, tempo variabile da 3 ore a mezz’ora per ogni fotogramma.

Tutti con antialiasing di default, senza radiosità.
In dettaglio, i riflessi non incidono particolarmente nei tempi di rendering. E’ l’isosuperficie che “ammazza”, in particolare con bassi valori di twisting rate.

Sorgenti (PovRay 3.6 richiesto, 3.7 consigliato): ini, pov.