Steam "disk write error" after reinstalling windows

This turned out to be a permission problem for me. Although there is no mention of permissions on the steam support page for the error at all.

After reinstalling windows, you'll have a user with a different ID. This means your user won't have access to any of your old files. For example I right clicked steamapps, went to properties, security and saw an unknown user with an red question mark icon. So I followed the following answer and things went back to working: Reset File and Folder Permission of External Hard Drive Data to default in windows 7

In summary, run (with cmd prompt with run as administrator): TAKEOWN /F X:\* /R /D Y, followed by ICACLS X:\* /T /Q /C /RESET. (replacing X: with your drive)

Be warned. I could literally reinstall windows faster than these commands take to run. It takes hours!

I'm not sure if completely disabling user access control UAC would fix this and hence be much faster. Running steam as administrator might work too but bugger doing that every time I boot.

Installing steam on Fedora

Fixing duplicate dnf packages

I just installed a shiny new Fedora 22 (KDE spin). I was running a dnf update when everything froze and I was forced to reboot (the cause of the freeze was the nouveau open source nvidia driver, and I hadn't got around to blacklisting and installing nvidia's driver yet). I was worried that things might be broken and went hunting for a yum-complete-transaction like thing but couldn't find one and since dnf update said "Nothing to do" I left it at that.

When I finally got around to installing the nvidia driver I noticed I had two kernels and couldn't boot from the more recent one (normally it's default). I ran a dnf reinstall for each of the newer dnf list kernel\* packages and everything was ok.

I noticed the real problem when trying to install steam and eventually found out about dnf repoquery --duplicated which listed ~500 items (same pacakage, but slightly newer versions from the update). A potential problem was half the old packages were in use and half the newer ones were. I was thinking I could either remove the new ones and run dnf update again or remove the old ones and reinstall the new ones. Anyway, I decided I couldn't be bothered accounting for both cases and deleted the older ones (because I found package-cleanup --cleandupes still works and does it for me (it calls yum, but now that's just a script which calls dnf). Be careful it doesn't try to remove more than the duplicates (by checking against the list from above)!

dnf repoquery --duplicated | sed "1 d" > dupes
cat dupes | sed 's/^\(.*\)-[0-9]\+:.*/\1/' | sort | uniq | grep -v kernel > reinstall
package-cleanup --cleandupes #uses dnf via /bin/yum (now a passthrough + warning script)

Before saying yes to removing everything, check the file count in reinstall with the number about to be removed. Also note the grep -v kernel or dnf complains about reinstalling the running kernel next.
sudo dnf reinstall $(cat reinstall)

Finally the dupes are gone, except for the kernel (dnf repoquery --duplicated) and I can get back to installing steam.

Australian Data Retention, VPN Security and IP Leaks

Australian ISPs have recently been forced to start collecting metadata from everyone. A giant waste of money and breach of privacy.

So what are some workaround options?

• Tor

Your internet traffic is encrypted and randomly routed to a large number of "exit nodes".

• Free
• Painfully slow
• Browsing only
• VPN

You encrypt and route all your traffic to a specific server in another country.

• Cheap (don't pick a "free" one, just don't)
• Marginally slower, depending on the one you get
• Can still torrent, youtube etc.
• Bonus: avoid geoblocking (i.e. US netflix)

Both approaches shift your trust from your local ISP to where you route your traffic - the Tor exit nodes or VPN service provider - so no magic bullet. Just to confirm, these are all completely legal. Which begs the question, if it's so easy to avoid then why bother. Australian's are paying more for their already shitty internet for nothing.

On a side note, it'd be quite interesting if someone wrote a script to continuously perform google searches and visit random websites. One, if done well enough this may obscure any real internet usage or two, make recording the already high volume of metadata completely impractical.

VPN Security

After finding a decent looking VPN provider (~$50 per year), I started a free trial. Setting up the connection was straightforward as their site had well written tutorials and many options to connect. However it was quite lapsed security wise.

Despite many claims about amazing encryption, none of their services seemed to support server authentication out of the box. For example, using their OpenVPN config:

WARNING: No server certificate verification method has been enabled.

This means that I have no guarantee that the VPN IP I connect to is actually the real server and a man-in-the-middle attack has not occurred which would completely void any security gained by encryption. Perhaps not as important to some, but it feels a bit cheap. One might argue that as long as my ISP isn't the one performing the MITM and storing my metadata then goal achieved.

I submitted a ticket, but the employee didn't seem to understand the need for server authentication at all:

Why do you need this? I recommend you to try the SoftEther VPN Client as it is more stable and faster then other VPN protocols.

Their SoftEther instructions did not include any discussion of server certificates.

I believe the missing OpenVPN directive was remote-cert-tls server (?) which seemed to work, but the point here is that I had to go out of my way to check the service was secure, and it turns out it wasn't out of the box.

IP Leaks

Although it doesn't really affect data retention, a VPN should give some additional privacy on the internet. If your real IP is leaked, visible to the websites you visit, then this feature is useless. Two common ways IPs are leaked with a VPN are:

• WebRTC's use of STUN to find your public IPs and then pass that stright to the javascript in your browser which is then free to send it home. But this is just one aspect of a larger problem — that any apps can still see both your real and VPN public IPs. Some people suggest trying to disable WebRTC/STUN instead, but that just turns off a feature you might want and doesn't address the real issue.
• DNS leaks occur when your computer contacts a DNS server directly instead of going through the VPN connection. It's common because your router typically says itself is the DNS server and forwards that on to your ISP. Since the VPN needs a connection to your router, a routing rule will happily forward DNS requests through your real network adapter. Although if you've manually configured your DNS to be one of google's then you should be fine.

The general problem here is the same. You want ALL traffic from your regular internet usage to go through the VPN. However the VPN functions over a real network connection which also exists on your computer. So there needs to be a special routing rule to only allow traffic from the client VPN application to the real network adapter, then everything else goes to the virtual adapter.

A typical VPN setup includes "default" 0.0.0.0 routing rules to both network devices, which is the cause of the WebRTC STUN issue. There should only be one default route to the virtual adapter and the previous one to the real adapter should be removed.

WebRTC will also report all your network adapter's IPs, which I don't think is avoidable, but if you're behind a router these are local IPs and cannot be traced back to you.

Now, to make sure to not use the router as the DNS server. On windows at least, the DNS servers are set by network adapter priority. Adjusting this to put the virtual adapter at the top correctly uses the DNS servers given by VPN server (its DHCP).

There are many, but this site has a more complete check for IP leaking: https://ipleak.net/