InactiveUser

I can think of 3 options: 1. (on stock Android) Disabling "Location" in Android's settings will keep any app from accessing your GPS and WiFi location. That sucks, of course, if you depend on specific apps, maybe car navigation that may need legitimate location access. At least disable "Google location reporting" and "location history". Details: http://www.howtogeek.com/195647/googles-location-history-is-still-recording-your-every-move/ 2. (on custom ROMs) Use a custom ROM that offers "AppOps" (native Android functionality for app permission management which Google chose to remove) or "Privacy Guard" (CyanogenMod's version of AppOps) Info on CM10/11's Privacy Guard: http://www.androidcentral.com/cyanogenmod-updating-privacy-guard-20-new-features-coming-cm102 Info on CM12's Privacy Guard: www.androidexplained.com/cm12-enable-privacy-guard/ 3. (on stock Android) Apparently, there are several apps that allow you to enable AppOps on stock Android. I haven't tried them, but they're worth a look if you don't want to use custom ROMs: http://www.pocketables.com/2014/12/droidmate-brings-app-ops-back-lollipop.html As victorab correctly explained, keep in mind that you cannot stop your carrier from pinpointing your location at any point of time. Your phone and the network's cell towers constantly communicate, negotiating which tower to use based on how strong the signal is (== how close you are to them). It's nowhere near as precise as GPS but I've read anywhere from 50m, 400m, or several km (depending on cell tower density, higher in cities, lower in rural areas). https://en.wikipedia.org/wiki/Mobile_phone_tracking To add to another good point by victorab: Many governments use IMSI catchers at political events or demonstrations. IMSI catchers are basically fake cell towers that your device will connect to, not only allowing them to locate you but also intercept your calls and data. It's probably smart not to bring your device to any political events to avoid both tracking and confiscation. Sure, unlawful in most countries, but no government particularly cares about legality. Or, try and detect IMSI catchers using an app like this one: Android IMSI-Catcher Detector

Use the "Config Generator", check all the servers you want to use (you can check a whole region / country). You have to enable "Advanced Mode" and "Resolved hosts in .ovpn file". This will give you an .ovpn file containing the entry IPs in the form of remote 1.2.3.4 remote 1.2.3.5 remote 1.2.3.6 ... You can then manually create UFW commands for these IPs, or write a Bash one-liner to automate the process, similar to what I did here for Fedora's firewall: https://airvpn.org/topic/13064-block-all-non-vpn-traffic-in-fedora-21-firewalld/?p=22926 That post also contains screenshots for the "Config Generator". You should also keep an eye on Air's News and Announcements section. Whenever Air withdraws a server, you should remove its entry IP from your firewall configuration.

Less tabloidy source: http://www.theguardian.com/technology/2015/apr/18/jack-monroe-quits-twitter-over-homophobic-abuse I agree that this one tweet, while hateful, should not warrant an arrest. However, you'd be wrong in claiming that this arrest was related to "exercise of free speech": So he didn't just send off one single tweet, he kept harassing her and that's clearly not covered under the exercise of free speech. He was not arrested for merely voicing his opinion.

Your guess is correct because the actual networking is not done by individual applications but the operating system, which uses a routing table to figure out how to contact any given IP address. The default route usually points at your home router, but OpenVPN will set a new default route, pointing at the VPN interface. If you've verified that your browser traffic exits through the VPN, the same will be true for any other application. The only exceptions to this wouldn't be application-specific, but address-specific - for example, connectons to your local address space won't be routed through the VPN.

You mentioned your threat level but you haven't explicitly stated your threat model - the goal of anonymous research includes several adversaries, i.e. family/co-workers, network admins, ISP/VPN provider, government, spooks, Google, trackers, website admins. Specifying who you're trying to protect against helps to give more precise answers. I assume by "login" you mean VPN session - there is no link between sessions but you don't magically get a new "identity/persona" either: - if you visit the same site twice and you don't clear out cookies, the site can obviously link both visits to the same persona. - if you do clear cookies but use the same browser with its probably unique fingerprint, the site can confidently assume that it's the same persona. - if you change your fingerprint but use the same IP, the site might make a reasonable assumption that both visits are linked to one persona. Same goes for the reverse (change IP but not fingerprint) - if you both change your fingerprint and use a different VPN server, it's unlikely that the site would be able to link the two visits, but, in certain edge cases, not entirely impossible. With all that said, I would highly recommend using Tor Browser (on top of your VPN connection) for your research: - Tor provides a bigger, more diverse pool of IPs - Tor Browser's fingerprint is used by millions of people, blending you in with the crowd - the Tor network's onion routing provides some additional protection against certain adversaries, making it harder to link source and destination Of course, using Tor comes with a couple of drawbacks: - a few sites block Tor altogether - significant hits on your bandwidth and latency (but very much usable) - captcha hell, most notably on sites that are powered by the shameful "Cloudflare" CDN If this didn't answer your question, please be more precise about who you don't want to make any links. I wasn't exactly sure how to reply because your stated goal of anonymous research involves much more than preventing a website from linking two sessions (which served as your main example).

I don't think you can make the key any smaller, but you could try the Tomato firmware. According to these instructions, it detects the 5GHz band after resetting NVRAM and rebooting twice. Numerous posts in this thread also suggest changing the country code in order to get 80MHz channels @ 5GHz.

I'm not sure what exactly you want to test for but you can use a site like http://ipleak.net/ to verify that your traffic is routed through the VPN. It'll also inform you about WebRTC or DNS leaks. You could also verify that the correct default route (via the tun interface, gateway address 10.x.x.x) has been set, I believe the correct OS X Terminal command would be: route -n get default I'd recommend enabling Eddie's network lock feature. It will configure your Mac's PF firewall to only allow tunneled traffic while Eddie is running. The last, underlined part is important to keep in mind: As soon as you close Eddie, your Mail client, browser, OS updater, P2P app and so on will happily transfer data outside the tunnel. Same goes for reboots: If some application auto-starts on boot it will communicate outside the tunnel - as long as you haven't launched Eddie yet. There are a few techniques with varying degrees of efficiency (and difficulty) to avoid this: don't have your internet applications auto-start on bootdisable your network interfaces before reboots, re-enable them only after starting Eddie and verifying that network lock is active, then start your internet appsuse your own (permanent) PF firewall rules (advanced topic! this post might get you started)run OpenVPN & firewall on a router / network appliance (OpenWRT, DD-WRT, PFSense, etc. - advanced topic!)

I'm not part of the team but since you haven't received any replies yet I'll chime in: It doesn't matter which application you use. AES-256-CBC refers to the cipher mode of the OpenVPN tunnel between you and AirVPN's VPN server. 4096 bit is the length of your RSA private key (user.key) that is used to authenticate yourself to the VPN server. Both of these parameters only concern the VPN tunnel itself. Any other encryption layer that gets established within that tunnel - for example, SSL/TLS encryption between your browser and some website is a totally separate matter. Browsers and web servers both have a set of supported/preferred cipher suites and negotiate the one they want to use. If I go to about:config in my Firefox and type in "security.ssl3", I get a list of disabled and enabled ciphers, I'm sure Safari provides a similar facility. By the way, you can also click on the "lock" icon in your browser bar to find out more about your current SSL/TLS connection to whatever website you're on. Because the web server at https://airvpn.org does support AES_256_GCM, I could theoretically force Firefox to use that cipher by disabling all the other 128-bit ciphers (but I would run into problems with other websites that might only support AES-128). In reality and in this instance, AES-256 would not make any difference because the key exchange would still rely on a 2048-bit RSA key which is currently considered standard / recommended TL;DR / conclusion: - AirVPN provides you with an AES-256 encrypted VPN tunnel between you and AirVPN but that doesn't impact how (or even if) your browser encrypts communication with any websites - AirVPN's website will usually negotiate AES-128 SSL/TLS encryption but it wouldn't make sense to use AES-256 unless their CA supported 4096-bit keys. Also, AES-128 / RSA 2048 is still considered secure for decades to come.

@flat4: No. With the current implementation, the 21 million cap won't be reached before the year 2140 : Projected Bitcoins Long Term Provided Bitcoin even survives that long, there would even be a way to keep mining going after that date: "The year 2140 is only based on the software's current precision, which divides bitcoins up to 1/100,000,000th. This would imply that around year 2140, the block reward would become zero. However, long before 2140, the precision will be increased (to support smaller fractions of bitcoins, or floating point or whatever) so mining can continue forever. Mining is never "done" and the actual 21 million will never be reached (although it comes arbitrarily close)." (Quote taken from this post on bitcointalk.org) Don't bother mining bitcoins yourself unless you have specialized ASIC hardware. We're long past the point of lucrative/economical CPU/GPU mining.

1. Using (Air)VPN on a Pi is really no different from doing so on any other Linux machine. I'll assume you use Raspbian. Install the "openvpn" package, its daemon looks for .conf files in /etc/openvpn/ . Put your generated AirVPN config file into that directory and change the suffix from .ovpn to .conf. You can control the daemon using the service command: service status/stop/start/restart openvpn 2. It would be a good idea to configure the iptables firewall in order to avoid any leaks. You will find examples in the How-to forum section. If you don't feel comfortable with iptables, you can try ufw which is an iptables front-end that provides easier syntax. 3. Quick way to check your current IP on the Pi: wget -qO - ifconfig.me/ip 4. One thing to look out for: The Pi does not keep time well (at all) on reboots or power outages. If time is off by too much, you won't be able to establish VPN or SSL connections so make sure your Pi can always communicate to an NTP timeserver. If your router comes with a timeserver (many routers do), you can add its IP address to the ntp config file. https://raspberrypi.stackexchange.com/questions/24079/how-to-use-ntp-on-raspberry-pi-by-local-ntp-server

1. There is no need to open any ports on your router, in fact, exposing the same ports you forward through AirVPN might open you up to correlation attacks (read Air's P2P FAQ) 2. aMule lets you choose the "Standard TCP Port" but the UDP port is always set to TCP port + 3 (if your TCP port is set to 30500, UDP port will be 30503). Use the "Suggest a range of sequential free ports" tool on airvpn.org/ports to find 4 free, sequential ports. 3. According to the P2P FAQ you should also avoid remapping Air ports to different local ports (example: don't forward Air port 30500 to local port 34012, just go with the default, straight forwarding). 4. After configuring both ports I instantly received a "High ID" on every eMule server I tried. I also tried both US and Swedish AirVPN servers, no issues.

I get the same error for the portable version on CentOS 6.6. The good news: the rpm version works and pulls in all dependencies (EPEL repos have to be enabled!). After installing the rpm, I tried the portable version again to see a different error message: symbol lookup error: ./libgdiplus.so.0: undefined symbol: g_mutex_lock Bummer, but at least the rpm version works. I don't know whether you already tried the rpm (or whether that's an option for you) but if it works on CentOS 6.6 it should also work on RHEL.

Yes, I have been able to use Syncthing on two firewalled devices behind AirVPN. For this test, I also disabled "Local Discovery" to rule out false positives. 1. Do not change the "Global Discovery Servers" and do not open/forward their ports! Keep it to the default: udp4://announce.syncthing.net:22026, udp6://announce-v6.syncthing.net:22026 2. On both/all of your devices, check Syncthing's web interface and look for the "Global Discovery" field. It has to say 1/2 or 2/2, meaning that it's been able to connect to at least one of the discovery servers. If it says 0/2, check your internet connectivity, VPN connectivity and the default discovery servers (step 1). 3. For each device you want to sync, create forwarded ports in Air's client area. As an example, let's pretend you have 2 devices and get ports 12345 and 12346. Set the "Sync Protocol Listen Address" on device A to 0.0.0.0:12345 and on device B to 0.0.0.0:12346 and don't forget to restart each Syncthing instance after changing ports! 4. (only for firewalled devices) If your devices' firewalls block all incoming traffic by default, allow traffic to port 12345 or 12346. Example for ufw: ufw allow in on tun0 to 0.0.0.0/0 port 12345 Example for iptables: iptables -A INPUT -i tun0 -p tcp --dport 12345 -j ACCEPT 5. In Air's client area, do the TCP port check for each device. If Syncthing is running on the given device/port and your firewall allows incoming traffic (see step 4), you will get a green light. If you don't, check all the previous steps. 6. If you do get a green light for both devices, you can go ahead and pair your devices. On device A, click "Add Device" and type in device B's Device ID. You will now see a message on device A: Device B ([AirVPN IP]:some_port) wants to connect. Add new device? Choose "Add" and you're good to go

Sure, VPNs get blacklisted too but it's not quite the same. In my browsing experience, I see way more captchas (or get denied access altogether) when using Tor. I don't see any merits of hybrid VPN/Tor servers outweighing the drawbacks. Also, AirVPN already runs two middle relays and funds a TorServers.net exit: https://airvpn.org/mission/

popular download manager "JDownloader": it's GPL-licensed but "contrary to the license, some source files are not publicly available""JDownloader's installer installed adware without the user's consent"https://en.wikipedia.org/wiki/JDownloader http://www.herdprotect.com/signer-appwork-gmbh-0100000000012e71e7355c.aspx This application serves as a perfect reminder that a FOSS license is not a guarantee of quality. When installing software, always take into consideration who the developers are and how/if they are trying to monetize their software.

Chromium: it's impossible to keep Google out of it. If you doubt me, read this old thread on superuser.com or try it yourself: change search engine to DDGset a blank homepagedisable "phishing/malware protection" (aka Safe Browsing)disable "reports to Google"disable "webservice to resolve navigation errors"disable "prediction service" With these settings, would you expect Chromium to immediately contact Google? I didn't. Yet, when launching Chromium, I instantly see connection attempts to 5 Google servers: SYN-SENT 173.194.46.64:443 SYN-SENT 173.194.46.67:443 SYN-SENT 216.58.216.74:443 SYN-SENT 173.194.46.72:443 SYN-SENT 173.194.46.66:443 Why? What for? I'll stick with Firefox, thanks!

What's really interesting is that they would tell paying customers how to connect to their service.. probably to weed out account sharers.. waiiiiit a second, sharing accounts is exactly what those multi-hosters do themselves.. now how ironic is that? Scumbags!

I find it difficult to recommend any platform for a self-built box because of your requirement of 2 PCI slots / 3x 1Gbit NICs - that rules out small, energy-efficient systems like AMD's AM1 (Jaguar/Kabini) or Intel Bay Trail / ARK Atom. I do have an alternative idea: €299 firewall box - explicitly built for OPNSense / pfSense, claiming "~80Mbps (AES256)", 3x 1Gbit ports. That's probably a bit more than you intended to spend but you have to factor in power consumption. That firewall will only consume 10W. On a self-built box you're looking at anywhere from 25-55W (or more) just for the CPU alone.

Try cycling through Air servers till you find one that works with these sites. They use aggressive IP blacklists that block Tor and unfortunately some Air servers. However, I was able to access both hammondmfg and A1Parts while being connected to a NL Air server.

Certainly possible but not trivial, it's quite a bit of work. You would need to add the option "route-nopull" to the openvpn config file (preventing openvpn to set a default route)a separate user account (let's call it: vpnuser) to run Firefox etc. (through sudo or su)iptables rules to mark vpnuser's packetsa bash script to create a route for vpnuser, executed whenever the tun0 interface goes updisable reverse path filteringAn example of something like this can be found in this blog post but it's not tailored to CentOS. Another (not very elegant, but much simpler) solution would be: run OpenVPN on another box (could even be a lightweight virtual machine! Also, don't forget to firewall it against non-VPN traffic)ssh into that box: "ssh -D 12345 user@the_other_box" (opening the local port 12345 as a SOCKS proxy)configure Firefox to use the SOCKS5 proxy at 127.0.0.1:12345 (sending Firefox' traffic to the other box which is running OpenVPN)

You might not want to use your primary / personal email address - just in case Air's database were ever to be compromised. But don't use a throw-away/invalid address either, you need it to reset your password. I avoid credit card payments as much as possible, mainly to avoid profiling by banks, credit bureaus and payment gateways: why allow 3rd parties to keep permanent records of your payments? That said, crypto-currencies come with their own flaws and leave their own trails (primer: https://en.bitcoin.it/wiki/Anonymity) but the process is more transparent - thus allowing you to take control of it. The bottom line is: Reducing exposure of personal information is always a good idea, although it's difficult to measure tangible "benefit". Spend a sensible amount of time on minimizing data exposure, but always keep in mind that whatever you do, there's one important piece of data you can't hide: Your IP address that's connecting to AirVPN servers.

go558a83nk: YoutubeCenter https://github.com/kkapsner/CanvasBlocker/issues/7 Random Agent Spoofer (only if RAS is also set to block canvas) https://github.com/kkapsner/CanvasBlocker/issues/16 There shouldn't be too many other issues but I found it odd that it would affect other extensions at all. For example, using NoScript obviously doesn't stop other extensions using JavaScript internally.

The EasyPrivacy list might block some canvas tracking scripts but it's a static list (blocking scripts by file name / origin, not by behavior). It can't stop websites from using canvas fingerprinting techniques embedded in otherwise innocuous script files. To prove my point: My adblocker does use the EasyPrivacy list but it doesn't stop https://www.browserleaks.com/canvas

I tried Privacy Badger on both Chrome and Firefox, it didn't prevent canvas fingerprinting (I used https://www.browserleaks.com/canvas to check). It's still in alpha, maybe they add such functionality later on. Their FAQ: "The alpha release of Privacy Badger only protects you against tracking by third party sites. In the future we plan to add some privacy protections for "first party" sites that you actually visit"

I don't have any opinion on CanvasBlocker but there are a couple of problems with it: it interferes with other extensions instead of only affecting websitesthe author makes it unnecessarily difficult to work with the code (but it's technically open source and also free-software licensed!)I don't use any extension to prevent canvas fingerprinting. Instead, I block scripts with NoScript (canvas fingerprinting requires JavaScript)use Tor Browser, which asks you whether to allow canvas image extraction (without the need to block scripts)