altendo

I understand completely! I appreciate the effort that you and goldfisk put into it. Hope to see more Defcon talks from you guys :)

> Either most people don't care about privacy or we, the tech community, do a poor job of connecting things like encryption to what people do genuinely care about.

Communication needs to be better for sure. The burden of that is on us - we know what's going on, but misinformation and technical jargon can make that knowledge less useful.

To the broader point, though: I don't think it's necessarily that people don't care about privacy. It may be partly that some people don't know to what extent we share our lives online, but also partly that the convenience of using online services - shopping online, chatting online, etc - outweighs whatever perceived privacy risks exist. (I say perceived because they may not completely understand what gets shared, how, and when.)

The We Vibe was the topic of a Defcon 24 talk, Breaking the Internet of Vibrating Things[1]. Was an excellent talk, but I felt it needed more jokes woven in.

[1] https://www.youtube.com/watch?v=v1d0Xa2njVg

EDIT: grammar fail

Asking for advice is perfectly fine, provided that those giving it have no expectation that it will be followed. I mention this only because sometimes, when advice is given, there's an implicit assumption that it will be followed - "You asked for advice, I told you to do X, but then you didn't do X! Why'd you even bother asking for it then?!" - when the person asking for it can (and will) do whatever they want.

Of course, this doesn't help with hurt feelings when a person doesn't implement advice, but that'd happen regardless of whether you're giving feedback or advice.

> there is simply no way for her to be denied entry to the US

As was proven when Trump instituted his executive order, people with valid visas and even green cards were denied entry into the US[1]. That's since been reversed in the courts... but that doesn't mean that the current, or even a future, administration won't try again in the future. (I doubt Trump will, after getting blocked in the courts... but you never know.)

[1] http://www.pbs.org/newshour/rundown/trump-muslim-ban-green-c...

In 2014 I traveled to Ghana for a friend's wedding there. The day I flew back, I had to go through a second, thorough security checkpoint at the gate before I could hope to board my plane. I didn't have anything to worry about - I'm considered one of the "'real' Americans" that the OP mentions - but I was still struck by what sort of impression this might leave on others coming to the United States with me. Namely, I thought that it sent the message that the US, before even receiving visitors, was saying "I don't trust you".

There is always that balance between security and openness; I don't deny that it's difficult to manage. Let's not pretend, however, that people aren't affected by xenophobic rhetoric. They are. What message does it send to actual Americans citizens like the OP when we lambaste them for their religion? Is that who we are as Americans, those who spread fear to those who don't look or act "real"?

I'm not liking where this country is going.

I'm actually surprised at the dearth of updates. The cleaner interface is nice for sure, and transcription in Spanish is great (yay internationalization!), but the post is underwhelming overall. There's just vague messaging about future updates. Was hoping for more of a splash (and better app store availability, based on some comments here).

For me, it's hard to speak against the outcome; criminals are being caught, after all. I'm wary, however, to give the government total leeway with technology. It's the issue of giving an inch to someone, and they take a mile: It (potentially) opens the door for misuse later on down the road. Whether or not a society is a democracy or a dictatorship is irrelevant, as either one can abuse the technology available to it.

I never have clear answers in cases like this one, because there is that balance between security and privacy. So far this seems to be good thing, but who knows what kind of abuse will happen down the road.

>Despite what you may have heard, the Amish aren’t against technology. Communities adopt new gadgets such as fax machines and business-use cellphones all the time—as long as the local church approves each one ahead of time, determining that it won’t drastically change their way of life.

This alone is the most interesting point of the article. People not belonging to the community, like myself, have a fixed preconceived notion of what it's like to be Amish. I still don't know much about Amish life and culture, but it's fascinating to see where my assumptions are wrong (and what else I may be wrong about!)

As an aside, for those looking to understand YARA rules, [1] provides a brief introduction and [2] introduces how to write them. I needed to look it up myself, but seems relatively straightforward if you have a programming background.

tl;dr: YARA rules are a method of categorizing malware based on their characteristics. So the PDF here released a YARA rule to determine a specific piece of malware used in the hack (it's not clear to me what it identifies, other than a PHP script).

For convenience, here's the YARA rule presented in the PDF formatted to be more readable:

rule PAS_TOOL_PHP_WEB_KIT {

  meta:
    description = "PAS TOOL PHP WEB KIT FOUND"

  strings:
    $php = "<?php"
    $base64decode = /\='base'\.\(\d+\*\d+\)\.'_de'\.'code'/
    $strreplace = "(str_replace("
    $md5 = ".substr(md5(strrev("
    $gzinflate = "gzinflate"
    $cookie = "_COOKIE"
    $isset = "isset"

  condition:
    (filesize > 20KB and filesize < 22KB) and
    #cookie == 2 and
    #isset == 3 and
    all of them

}

[1] https://securityintelligence.com/signature-based-detection-w...

[2] http://yara.readthedocs.io/en/v3.5.0/writingrules.html

EDIT: formatting

[1] answers it clearly:

> With today's release, domain fronting is enabled for Signal users who have a phone number with a country code from Egypt or the UAE. When those users send a Signal message, it will look like a normal HTTPS request to www.google.com. To block Signal messages, these countries would also have to block all of google.com. (emphasis added)

It can be blocked, but doing so will block google.com. Basically Open Whisper Systems is making a block that much more costly to implement, since Google is ubiquitous in so many different areas.

EDIT: forgot how to add the emphasis, is fixed now.

The way I like to think about it is that the database does not know nor does it care (nor should it!) about the meaning behind the queries you're sending it. It cares about fetching and storing data correctly first and foremost - it can't tell your intent from the query you're sending it. It has to be told what to do (transactions, readability levels, etc) to ensure the data reflects what the app developer expects.

RDBMSes are general-purpose tools that need a little bit of extra information to give you better guarantees on how data is manipulated. You can reconfigure the database ensure serializability by default, but if you want it available for specific queries the app developer has to be the one to ensure that constraint.

derp. OP has a small statement on the differences:

> Unlike SERIALIZABLE isolation, it works even in autocommit mode or if the statements are in separate transactions. For this reason it’s often a good choice for web applications that might have very long user “think time” pauses or where clients might just vanish mid-session, as it doesn’t need long-running transactions that can cause performance problems.

They will behave similarly in similar situations. There's four scenarios for 2 transactions:

1) Transaction 1 starts and commits before Transaction 2 starts. 2) Transaction 1 starts; Transaction 2 starts; Transaction 1 commits; Transaction 2 attempts to commit. 3) Transaction 2 starts; Transaction 1 starts; Transaction 2 commits; Transaction 1 attempts to commit. 4) Transaction 2 starts and commits before Transaction 1 starts.

1+4 and 2+3 are the same. In 1+4, the transactions are serialized - they are wholly independent of each other, so the second transaction will always see the updated version, so there's no worries about failing on that.

In 2+3, the version number increments when the first transaction commits. For optimistic concurrency control, the version number will have changed, which is detected prior to updating. (In the OP's example, the query is an UPDATE balance WHERE version = X, and since the version is X+1, zero rows get updated.) For the SERIALIZABILITY concern, it will fail because internally the version has changed for the given row ("version" referring to the metadata Postgres keeps to track which rows are current), kicking it back to the user with an error.

I don't think there's a scenario where reordering lets a SERIALIZE'd transaction succeed but optimistic locking fails. They are effectively - as far as the methodology used - the same thing (with some differences that the OP mentions).

EDIT: minor readability things

One major difference is that optimistic concurrency control is handled by the calling application and not in the database. Your app should handle the error in either case, but in the case of OCC you end up doing the bookkeeping yourself, which may be preferable (lower overhead for Postgres to handle the query for instance).

I'm in agreement with the other replies here - this seems more useful within a datacenter (and any unit smaller than that, such as an AWS Availability Zone) and not so much useful over the general internet. Too much unpredictability in how things get routed, what types of routers are hit, etc.

I am reminded of the old joke about how there are 2 major problems in computer science: caching, naming things, and off-by-one errors.

This is characteristic of all distributed systems, so in that sense it isn't a unique concept to NOPaxos. The emphasis here is minimizing the traffic that a typical Paxos implementation incurs while changing the constraints of the distributed system.

I do recall that. Still scary that we even had that in place.

The recent speculation about a national registry for Muslims - and what that may look like - makes this even more poignant. The times may have changed, but fear and ignorance have not.

I didn't mean to say that we shouldn't have knowledgeable people handling our voting machines (as pretty much any election shows, we certainly do). I just imagined sysadmins across the country saying "screw it, I'm taking care of this" and abandoning their normal jobs to take care of it.

My tongue-in-cheek solution: put the sysadmins in charge of voting machines. They'll make sure there are several backups, automate testing of all the machines, and an unwavering ambition to prevent data corruption and hacker intrusion. The heroes we need.

Full disclaimer, I am a systems engineer :p

Right now I think there is a pretty hard reaction to openness and trust. Hopefully we can work through it and make things a little better :)

clarification: if it gets to the point where I suspect an attempt is likely, or if an attempt is happening, I will start working towards attempting to get location information. The first thing I usually do, however, is help the caller process their feelings to help build trust upfront, even in cases of high suicidality. Speed is of the essence though in certain circumstances.

It depends entirely on where your call to the suicide hotline gets routed. I won't contact police unless there's an immediate threat to the caller or to someone else (in cases of abuse/homicide, the caller might not be the one in danger), anything short of that I won't. This, however, is how my crisis center handles such calls. I can't speak for every organization that takes calls from the suicide hotline.

If I perceive an imminent likelihood of an attempt, I'll generally start trying to get a location from them - it's not subtle, they'll know. Sometimes people will give it, other times they resist for whatever reason. For those that resist I will process that feeling that they have and then try again. They may even ask if I'll contact police, in which case I can't lie to them. Ultimately I may _never_ get a location, or I'll have an extremely ill-defined location - it's always up to the caller if that is information they want to give.

He called the right number. The Veterans' Crisis Line and National Suicide Hotline are the same phone numbers (1-800-273-8255). When you call that number, you need to press 1 at the audio prompt to switch over to the line specific to veterans.

> Help is NOT out there unless you're extremely lucky and rich

There is, for sure. There are crisis centers that don't respond like that. They may not be common - so maybe some luck is involved - but there are people out there trying to help others.

the article fails to clarify this, but the number for the Veterans' Crisis Line and the National Suicide Hotline are the same (1-800-273-8255). When you call that number, you are prompted to press 1 to be redirected to the veterans line. In this case, Mr. Corrigan likely missed the prompt and got sent to the suicide hotline - a not uncommon experience for veterans.

This is hard to read. I volunteer at a crisis center, and just reading the description of how the phone volunteer handled the call made me cringe. In my experience, you don't call the cops just because they call the suicide hotline and have guns - I've experienced instances where callers call and aren't suicidal. I'd need a clear sense of intent before going out of my way to do that. I really hope this was just a one-off thing, and not at all how volunteers (if they are volunteers at all) treat callers on the suicide hotline.