In our experience with a deployed P2P system, UDP hole punching is more successful with all the strange NAT boxes deployed. Our success rate is 95.3% now in the wild. As said above, this TCP fallback sounds like an excellent way to get to 97% connection success rate!
You must assume that the NSA already has master keys for all domestic CA root certificates, and given how many were hacked recently, foreign ones too. In which case SSL traffic is effectively the same as plaintext to them.
Is this correct? Wouldn't they still need all of the leaf private keys to decrypt things?
My understanding was that having a CA's private key just enables someone to issue new child keys for that CA. That vulnerability could be addressed with certificate pinning.
Not quite sure what you mean, but for the record, as a general rule CAs do not generate keys. They just sign the public keys coming in as Certificate Signing Requests. Without ever seeing the accompanied private key.
The biggest problem faced by organizations collecting this type of data is sorting the signal from the noise.
Unfortunately, until real encryption is the norm, using this font or other means to hide your communications is like giving the NSA a free "this bit is particularly juicy, have a human read it" flag.
s|movies, games, music|games/software| and it might be more plausible. (.mkv, .mp3 or even the .rmvb that's weirdly popular in China are hardly common attack vectors.)
However, if we're talking about China, and the demographic of employees that get sent for international matters, then we're definitely not talking about people that can't afford their own computers. I would posit this holds for nearly any country (except North Korea?)
Taking your argument as just "a culture of grabbing untrustworthy software from anywhere is the reason", it becomes more persuasive to me.
A couple minutes of basic usage (FF20, Linux) have me in pain:
- CTRL-B (and presumably other shortcuts) doesn't always take effect immediately. Sometimes there is delay, sometimes it seems necessary to let go of CTRL for the event to get flushed, sometimes nothing ever happens at all. Multiple hits without letting go of CTRL also behave erratically.
- Focus stays on formatting buttons and requires manual click to get back to text widget. Several times I wondered where my text was, only to realize focus was on wrong widget.
- By far the worst thing: the way formatting codes are handled leaves me crying for WordPerfect's Reveal Codes. Make some text bold, unbold the text after it, type something right after the bolded text, it isn't bold, hit enter for new line and type something, now it became bold again. Argh!
I like the idea of this, but presently there are some rough edges.
Thanks for reporting this. I didn't test under Linux as I don't have a linux box handy. We bind keyboard events to jquery keydown. Is it better to bind to something else for FF/Linux?
* On Chromium 25 and Chrome 26 the first two issues do not exist.
* More playing with FF20 and it seems this is actually tied to CTRL+B, not any other shortcut. At least initially, clicking the "Bold" button also has no effect. Possible explanation: In FF CTRL+B opens the Bookmarks pane by default, in practice certain focus combinations do open this pane. This explanation would seem to require the Bold widget to be generating a keypress under the hood, though.
* The codes issue is tricky, but one way to see an example on Chrome/chromium browsers is:
1. refresh page
2. select pre-existing "Go ahead..." text
3. type "this is bold and this is not"
4. select "this is bold" and make it bold
5. place cursor at start of " and this is not"
6. type "so is this", text is bold
7. hit enter and type "but this isn't", it isn't bold
The original issue I saw was similar, but related to numbered bullet lists. To reproduce the third issue on FF follow the same steps, except a) one must first mash about on CTRL+B and/or the Bold button until they start working, then follow same steps. Result: you get the inverse, text in 6 is not bold, and text in 7 is.
Sorry, don't have domain knowledge about keybinding.
I was able to reproduce the first two problems in FF on Linux, but not Chrome (everything seems to work perfectly there). It seems to be FF's problem, not Linux's.
Firefox on OSX works fine... so it's a combination. I don't have a linux box handy to test, but it would be nice if you could see if keydown is the problem, and if so we'll change it.
Don't know what jurisdiction you're in, but fraudulent transactions[1] == "theft" in the colloquial/moral sense where I'm from. Malice is not requisite to defraud.
[1] I charge you for services but do not provide them.
Where I'm from, theft requires intent. Fraud requires intent. If money is lost through unintentional error, there may be legal repercussions, but it will almost assuredly be a civil suit. I don't see how it would be untenable to charge anyone at Facebook with an actual crime for this.
It's not entirely simple, because when they realise the mistake, they have to correct it. I don't know how to unpack the question of whether Facebook has realised the mistake, and I don't know what Facebook's internal state is.
That's not their political beliefs, that's their lawyers making a risk vs reward decision. Why is everybody so quick to attribute things to malice when they can be explained by simple pragmatism?
To me the point is that when you start arbitrarily enforcing rules against some people (small guys) and not others (big guys) it smacks of hypocrisy. Maybe you can explain how it was just blind process -- it still stinks.
Treating the big guy one way and the little guy another may be "pragmatic" but that's not upstanding in my book. Sure, it's within their rights to do business with whom they want, but it doesn't mean we can't call a double standard when we see one.
If you read some of the comments, essentially:
a) looking for resistors that could be placed in multiple positions on the board and
b) following the traces from the resistors: going to GPU? probably not what you want. Going to PCIE interface? Probably correct.
But the remote host can limit your ServerAliveInterval, however most hosts don't close your session if there is something running. On our clusters this is the only working solution, and I tried both, trust me.
If that's an issue (I've never met a server like that, not to mention one like that and I couldn't change the setting) then wouldn't you rather use this?
while [ true ]; do sleep 1000; done
Just using:
sleep 1000; exit
means you can't make new connections after 17 minutes.
Yes, in fact I use the first one (while true; sleep; ls) but I thought the second is more succint. Anyone interested can make a loop. Please notice that most of the snippets aren't meant to be copied & pasted, but rather analyzed and understood by the user.
Ah, sometimes that's a hard line to draw since often the people that know enough to understand not to take it literally don't really need the pointer in the first place. :)
