LibreOffice Writer seems to start in around 0.35 seconds on this PC*. I'm not certain about that, because it's really hard to measure something that fast.

*i7-4790, 8 GB RAM, SSD, Gentoo Linux

I remember starting OpenOffice 6 or 7 years ago, and it was indeed painfully slow at starting back then.

Usability seems fine to me, but I'm not a power office suite user.

Thanks. I might ask my ISP if they'll consider switching from a /64 to a /56 prefix + a /128 global address. Doesn't seem likely, but worth a go!

> assign either 0 or 1 IPv6 address on the link interface

As in, zero or one *global* addresses? Presumably you need at least one IPv6 address. I think you clarified that in your next sentence, I just wanted to check.

My ISP uses DHCPv6 to provide a /64 prefix and a separate link local address, and indeed outgoing traceroutes from internal hosts behind the router always have one unresolvable hop between the CPE and the ISP. Incoming traceroutes are fine though.

Certainly in British English there is no difference in meaning, although I gather that in US English farther is often encouraged when referring to physical distance.

For this scenario, yes. Without speculating as to how likely it is, it can of course be achieved using a compromised browser (e.g. attacker's CA added as trusted) or a compromised CA (e.g. common CA hacked or compromised in some other way like government agency pressure).

In one of those scenarios, the SMS step doesn't add much, if anything.

It does add a useful step in the case of something like the user's machine being compromised by keylogging, but frankly these days the MITM scenario doesn't seem that unlikely. (Think Snowden revelations level government attacks.)

Scenario at time of account signup:
Browser - MITM - Server

Scenario after signup:
Browser - (Optional MITM) - Server
User's phone - Attacker's phone - Server

1. Browser sends user's phone number to MITM
2. MITM sends attacker's phone number to Server
3. Server sends SMS code to attacker's phone
4. Attacker forwards SMS code to user (preferably masking the source number, perhaps using an internet SMS gateway)

To the user, the above process was transparent so the account is used normally. At any time the attacker can sign in as the user by requesting the SMS code, neglecting to forward it on to the user, and using it for himself.

This of course relies on a MITM at the time of signup, but the first AC in this thread proposed that the SMS was to ensure the initial signup is secure. It can't be secure if the second channel (SMS) relies on a compromised first channel (MITM attacked HTTPS).

The suggestion above was about a MITM attack between the end user and the server, not a compromised server.

The attacker could also relay the SMS to the real user. That way the real user does the first log in (and any others that require the SMS code), but the attacker's phone number is stored in the system for when they choose to log in.

It won't kill your hardware (I've compiled it on significantly less suitable machines), but it will take a fair while (a number of hours) on a machine of that power.

There's a lot of learning to be done with Gentoo, but once you get it, I think you'll appreciate it considerably.

(Nothing is needlessly complicated or arcane, but it can be rather different to somebody used to most popular distros.)

I've been running Gentoo since 2005, and my main desktop (which I'm using right now, incidentally) has had the same Gentoo install since 2006. I only got rid of my original 2005 install because I switched architecture (x86 -> x86_64).

If it's sane enough for me to keep it running and fully up to date for nine years without much effort, it must be pretty sane. I'd trust it!

Even if it is happening at cell tower level, who's to say they don't just duplicate a cell ID?

Citation needed.

It gets even worse than 100 kB.

JT Global charge in 1 MB increments [1]
Airtel Vodafone charge in 1 MB increments (they say 1 Mb, but I am assuming this to be a typo) [2]
Sure charge in 200 kB increments [3]

[1] http://www.jtglobal.com/Jersey...
[2] http://www.airtel-vodafone.je/...
[3] http://shop.sure.com/jersey/su...

Presumably, if the DNS cache /is/ even used to detect cheating, then it's just one part of some weighting system. Even this is just assumption. We don't have enough information yet.

I'm not speculating which possible thing I think is more likely, I've only been trying to point out what we *don't* know, to try to counter the stated-as-fact unknowns that various articles have been giving.

(I'm all for getting an answer from Valve about what's actually happening.)