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.
> 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 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!
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]
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.)
There's no evidence that anything from the DNS cache is sent home at all - perhaps the processing is done locally.
Of course local processing/data can't necessarily be trusted, but this may be just be one of many tests performed to decide the statistically likelihood of cheating.
If anything from the cache *is* sent home, then I will be just as angry as you. At the moment there isn't any evidence for that though.
Yes. However, presumably if Valve are using the DNS cache for cheat detection, then it's just one of many factors that they use to determine the probability of cheats being used.
The decompiled file appears to be "VAC3-MODULE-bypoink.dll", which sounds like it's come from the Windows version of Steam. My Linux version of Steam has no.dll files, only.so files as expected. Perhaps this is limited to Windows.
I agree that it's very invasive if the list is returned to Valve, however I can't find any evidence that it is. The code originally posted only details the *reading* and hashing of the DNS cache, with no sign of *transmitting* it.
As far as I can see, numerous headlines and articles since the code was posted have made the claim that the list is sent to Valve, without any evidence.
Now that I think about it, neither gave a frequency, so both can be correct. Perhaps the title was implying per eight seconds and the summary was implying per second.
Slashdot Mirror
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.)
There's no evidence that anything from the DNS cache is sent home at all - perhaps the processing is done locally.
Of course local processing/data can't necessarily be trusted, but this may be just be one of many tests performed to decide the statistically likelihood of cheating.
If anything from the cache *is* sent home, then I will be just as angry as you. At the moment there isn't any evidence for that though.
Yes. However, presumably if Valve are using the DNS cache for cheat detection, then it's just one of many factors that they use to determine the probability of cheats being used.
The decompiled file appears to be "VAC3-MODULE-bypoink.dll", which sounds like it's come from the Windows version of Steam. My Linux version of Steam has no .dll files, only .so files as expected. Perhaps this is limited to Windows.
Do you have a source for this?
I agree that it's very invasive if the list is returned to Valve, however I can't find any evidence that it is. The code originally posted only details the *reading* and hashing of the DNS cache, with no sign of *transmitting* it.
As far as I can see, numerous headlines and articles since the code was posted have made the claim that the list is sent to Valve, without any evidence.
The claim is that the operating system's DNS cache is scanned, not any particular application's history.
Now that I think about it, neither gave a frequency, so both can be correct. Perhaps the title was implying per eight seconds and the summary was implying per second.
Probably not though.
If we assume that the AC was just poking fun at the title/summary disagreement, then it was a fair comment.
You're quite right. I was only looking in the HTML for this thread, but it's still in the title for the the main homepage.
The text persists in the head within a link title:
But it does indeed seem to be gone from any normally viewable place, sadly.