Gunshot victims to be suspended between life and death - <AUTHOR> http://www.newscientist.com/article/mg22129623.000-gunshot-victims-to-be-suspended-between-life-and-death.html#.UzNzxfBdXme <comment><USER2> > At this point they will have no blood in their body, no breathing, and no > brain activity. They will be clinically dead.

Is this right? That seems to imply that brain activity can be restarted from a cold, "electrically" inactive mass of grey matter. I thought brain dead was dead and there was no coming back from that.

Is the article accurate? If so, does the ability to restart the mind from an inert brain tell us something important about how thought and consciousness works?

<comment><USER3> Check out the concept of information-theoretic death:

[http://en.wikipedia.org/wiki/Information- theoretic_death](http://en.wikipedia.org/wiki/Information-theoretic_death)

Regarding brain death, I think you may be mixing up cause and effect. When the brain's activity ceases due to catastrophic structural damage, that's pretty much the end. But if the brain is simply "paused" without deterioration, I don't see why consciousness couldn't return once blood flow is restored.

(Personally, I'm interested to see if anyone reports any kind of dream-like experience while undergoing the procedure. I know, I know, it's impossible. Still fun to imagine our scientific understanding of the mind being turned upside down.)

<comment><USER4> But will it be the "same person"? Does cold-starting from the same neural network give you the _same_ consciousness or a copy? Does consciousness require some form of continuity that's lost if you lower neural activity beyond a certain level?

<comment><USER5> Who is downvoting all these comments made in good faith? The same thing is happening in other posts on the front page, and elsewhere on this page.

If you downvoted this, you need to go review the HN guidelines [1] and Paul's recent comments on what makes an ideal HN comment [2].

Downvoting is not something you do for a comment you mildly disagree with -- it should be reserved for posts that explicitly violate community standards. This is not one of them, regardless of whether or not you or I agree with the particular sentiment.

1\. [https://news.ycombinator.com/item?id=7445761](https://news.ycombinator.com/item?id=7445761)

2\. [https://news.ycombinator.com/item?id=7445761](https://news.ycombinator.com/item?id=7445761)

<comment><USER6> I wonder if changing the downvote button to a "flag" link would be more appropriate for how the button is intended to be used.

<comment><USER7> This would make a lot of sense. Flagging clearly says "this comment is not appropriate on this site", while downvoting usually means simply "I don't agree with this comment".

<comment><USER8> Downvoting also means "this comment should be this high", however the problem is that there's o indication when a comment is at score of 1, so people would inadvertently push it into gray area.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> There are other ways to do suspension as well. Certain gases are known to have the very same effect (induce clinical death, slow down your body metabolism) and the body can be restarted when oxygen is pumped in forcefully again.

Alas with the _extremely_ slow state of regulatory changes, many people that could be already saved nowadays using these techniques are just ending up dead.

<comment><USER10> > _Alas with the extremely slow state of regulatory changes, many people that > could be already saved nowadays using these techniques are just ending up > dead._

I think the article touches upon this, but it's a little more nuanced than 'regulatory changes', because with this technique there is no time for informed consent, and doctors understandably want to avoid a situation carrying out this procedure on a patient who then subsequently died but _could have survived_ were another treatment approach taken.

On the one hand many people do end up dying prematurely because they were not able to benefit from the latest medical technology: on the other, but on the other these new technologies may have substantial short and long term side effects that we're not fully aware of yet.

To give you some examples: many medical professionals are now arguing for _stronger_ regulation of antibiotics because a lack of prior regulation has resulted in widespread drug resistance. Ritonavir is a antiretroviral drug used to treat HIV which during clinical trials was very promising, but after being released was found to be polymorphic and convert in-situ to a different structure which was useless (the drug had to be taken off the market and re- formulated). Thalidomide is a classic case of a wonder-drug which subsequently was found to be wholly inappropriate.

I don't think anyone in the medical profession would argue we should deprive people of the most effective treatment - indeed, it is standard practice in a double-blind trial to halt the placebo participants if the drug being tested proves to be overwhelmingly effective, because it would be unethical to continue. However, it takes time, effort, money, and regulation to establish how that treatment works and what side effects it might have.

<comment><USER9> > I think the article touches upon this, but it's a little more nuanced than > 'regulatory changes', because with this technique there is no time for > informed consent, and doctors understandably want to avoid a situation > carrying out this procedure on a patient who then subsequently died but > could have survived were another treatment approach taken.

Sure, i don't argue on that. What I mean is that even if their first trial is widely successful (they save 50% of patients instead of the standard 7%), how long will it take and how many trials will be needed for the FDA to recognize this as a new clinical practice? It will be years - and in this period how many persons who could have been saved by this kind of procedure will die? That's what I was referring to.

<comment><USER11> If we could tell, just from a single trial, whether a particular drug was safe and effective, then it's true that the subsequent FDA trials would be a huge waste of time. Sadly, history has told us time and again that we can't.

</comment></comment></comment></comment><comment><USER12> Why are the researchers focusing only on knife wound and gun shot victims? I understand that those injuries are particularly sudden and severe, but so are many of the injuries associated with automobile accidents, which occur more frequently.

Of course, they need to introduce this technology in a small, focused way, but it would seem more logical to use a patient's physical condition as the deciding factor rather than his or her exposure to two specific crimes.

<comment><USER13> Knife and gunshot wounds really just means penetrating trauma. There's a hole and it's bleeding, but otherwise the body and vital organs are fine. If you can fix the hole and stop the bleeding in time, the person will live. If not they die.

Contrast this with a car accident where massive blunt trauma forces have crushed and wounded lungs, livers, bones, etc. There's no one "hole" to fix, just blood oozing from thousands and thousands of micro tears. Surgery won't fix these people.

Make sense?

<comment><USER14> Most of the damage from a gunshot wound doesn't come from the _hole_ , but rather from the _cavitation_ the flesh is subject to as the bullet passes through it. The shock wave from a physical impact of that magnitude absolutely _rends_ flesh.

<comment><USER15> Most urban/non-military gunshot injuries are from pistols, which have a fairly negligible temporary cavity since they're relatively low velocity (order of 1000fps, vs. 2500-3000fps for a rifle round). Plus, they're often expanding ammunition (hollowpoints, etc.) which do more direct tissue damage.

Military rifles, firing FMJ ammunition, do have a huge temporary/cavitation trauma vs. direct trauma (unless they hit bone).

<comment><USER16> See my comment elsewhere in this thread; Martin Fackler and his followers believe temporary cavitation trauma is " _at best a secondary mechanism, if not irrelevant._ "

Although I have a personal theory about why FMJ battle rifle (e.g. 7.62 NATO/.308) torso wounds tend to be fatal, at least in the field: there larger temporary trauma diameter stands a good chance of shocking the spine and disabling long enough for person to bleed out unless someone else quickly comes to their aid.

</comment></comment></comment></comment></comment><comment><USER17> I emailed my best friend's dad who is a retired ER doc and Harvard grad, this was his response...

"We already do this with CPR survivors. It is not clear that it is helpful. It is logical, but as you know logic is the great deceiver."

</comment><comment><USER18> If the goal is just to get the patient cold why not use ice cold blood? Why use saline?

You could even use a cardiopulmonary bypass to rapidly cool a patients own blood.

<comment><USER9> Saline is easier to find than blood, and you don't need to know the blood type when it comes to an emergency. Saline is standard and available in large quantities everywhere in hospitals, and very cheap. It makes sense.

<comment><USER19> In a pinch, coconut water can be used as well:

[http://www.ncbi.nlm.nih.gov/pubmed/10674546](http://www.ncbi.nlm.nih.gov/pubmed/10674546)

</comment></comment></comment><comment><USER20> Well this is unfortunate... I came to this thread way too late and I doubt people will see my post. I am a physician and I know a lot about hypothermia and its uses in medicine. Oh boy, where to start...

First of all, death is a really nebulous concept when you understand physiology at the cellular level. We still do not know the signs that represent irreversible death at the organismal level. The heart can be restarted, consciousness can be lost and restored (coma, concussion), and even the entire cardiovascular system can be bypassed in emergency situations (Google: ECMO). I mean, we accept that decapitation is a non-survivable condition, but is that person dead at 10 seconds? 1 minute? 10 minutes? What if they could be revived in body, but their cognition/personality information was all lost... are they alive? It's really controversial and hard to define. So instead we make definitions of cardiovascular death and brain death so that we can make laws and regulations regarding the issue. But scientifically? Yeah, good luck with that.

Now accepting that there is no 'on/off' switch of life and death, we must come up with ways to preserve to most 'at risk' parts of the body to preserve life. In this case, the brain. 5-10 minutes tops without oxygen and you are death for all intents and purposes--an exception (which they kept forgetting to mention in the article) is that you aren't dead until you are 'warm and dead.' There are plenty of cases of hypothermic 'dead' that could be rewarmed and they 'come back.' Are they intact? Absolutely not! Most of them suffer short term memory loss and spastic muscle issues (the most susceptible cells to anoxic injury are namely the hippocampus and purkinje cells in the cerebellum --both of which would be expected to cause these symptoms if injured). Using rats and pigs to model recovery in hypothermia (which has been done as far back as the 80s) is misleading because you can do things to them that you can't do to humans. Namely, subject them to high-risk, experimental procedures without their consent. This is an unusual study because they WILL be doing just that--bypassing consent to give these people presumably the only chance they have to survive. In past studies of hypothermia, people could not be consented fast enough or they couldn't be cooled fast enough (an entirely different discussion). The key is the immediate cooling. If you can get their temperature low enough, quickly... you can preserve almost all brain function. Again, we know this from cases of frozen lake drownings, hypothermic cardiopulmonary bypass, etc.

So, yes... this trial is promising... but I am afraid that it will be difficult to do it right. The fact is that getting central arterial access to 'replace their blood and cool them' is not as easy as it's made out to be. Plus, if they have that much blood loss... those injuries need to be repaired and that same fluid being pushed through those injured vessels, is now just pouring out of those same injuries. Yes, it may work in some cases... but overall, traumatic injury is a very heterogeneous group.

In the group that they describe who will receive this experimental treatment, I fear that they will have already had too much ischemic time--too much time without significant blood pressure. High-quality CPR is rare in the field, and even in the hospital can be sometimes missing. Assuming they have been getting 'good' CPR for the 10-15 minutes the ER team spent attempting to resuscitate them, there is still a good chance that their brain was not being perfused.

IMHO, this trial will unfortunately not give positive results. The science works in principle, but not in practice.

That being said, the 'holy grail' would be a drug/chemical that could slow cellular metabolism. Emergency responders could inject this at the point of triage and then hold them in 'stasis.' One day, we will definitely have this... but there are no good compounds in the pipeline to my knowledge.

EDIT: I think I gave the false impression that I don't support the study. Actually, I DO! I was just speaking about the existing human studies that are out there. I think it is both ethical and important that we continue to investigate these interventions.

<comment><USER21> _" I mean, we accept that decapitation is a non-survivable condition"_

I do not accept that ([http://en.wikipedia.org/wiki/Head_transplant#History](http://en.wikipedia.org/wiki/Head_transplant#History))

<comment><USER20> Haha this is incredible! I've never seen these surgeries. Technically you could do this on a person too, I don't see any reason it wouldn't work. Of course, with our current level of scientific understanding, we have no means to 're-connect' the spinal cord--that is currently our rate limiting step in surviving a controlled decapitation, say one performed under hypothermia in an OR suite. We could use a bypass machine on a severed head, but it would still be a quadriplegic and unable to breathe for itself.

Futurama's 'heads in bowls' is not so far-fetched if we never figure out our to reattach a spinal cord.

</comment></comment></comment><comment><USER22> link to the study:

[http://www.ccm.pitt.edu/research/projects/epr-cat- emergency-...](http://www.ccm.pitt.edu/research/projects/epr-cat-emergency- preservation-and-resuscitation-cardiac-arrest-trauma)

"[T]est the feasibility of rapidly inducing profound hypothermia ... with an aortic flush in trauma victims"

</comment><comment><USER23> I remember reading about this research in pigs many years ago and over the years I kept wondering "what's going on with this?"

If they can make this work only in a statistical sense, reviving more people than would have died otherwise, it'll lead to even more research. My firm belief is that this is one of those things that the more we do, the more we'll be able to do. It wouldn't surprise me to see people being "dead" for 4-16 hours then brought back to life -- assuming a decade or two of research.

At that point, all kinds of weird things become possible, like head transplants, or people who have lost their body from the navel down being saved.

Very cool stuff.

</comment><comment><USER24> If this works, could it give some credibility to cryonics?

<comment><USER25> None whatsoever.

edit: The stumbling block for cryonics the massive trauma to cells at a molecular level from freezing. If I have to bet, that never gets solved and cryonics is a pipe dream. So, I didn't mean to be so blithe, but this offers no new information that's relevant to the viability of cryonics.

edit: I'm aware of vitrification. Vitrify and revive a human, then. It's a safe bet that it's not a perfect process at the scale of a whole human body.

<comment><USER26> Well you don't have to revive the whole body, or even the brain. Just preserve the information in it.

<comment><USER27> Exactly. What makes up the identity of a person is not the physical substrate but the pattern of information stored.

But this is a tough bullet to bite, even for computer professionals.

</comment></comment></comment></comment><comment><USER28> Science fiction is becoming medical practice. In Lois Bujold's Miles Vorkosigan books, the main character is killed by a grenade to the chest. The emergency medical procedure was to dump the lower-ranking dead body already in the portable body freezer, exsanguinate the corpse by opening the carotid arteries, and pump the circulatory system full of "cryoprotectant fluid". The body is then frozen. Replacement parts are grown from the corpse's own tissues, which are surgically implanted when the body is thawed in a fully equipped, state-of-the-art medical facility.

In the context of the fiction, the procedure was imperfect, and is not without side effects. The frozen dead people often fail to revive. The main character, for instance, was left with a debilitating seizure disorder for the remainder of his life, something that was eventually treated by a neurological pacemaker implant.

Based on existing studies and technology, the fiction is a very plausible future technology. Between stem cells, volume printers, and extracellular matrix, autologous donor organ replacement seems possible. Hibernating amphibian studies tend to indicate that a blood replacement containing glycerine, perfluorodecalin, raffinose, glycogen, and drugs would help minimize human tissue damage from the freezing and thawing process. It would be an emulsion, and would probably superficially resemble the android blood from the Alien movies.

The only question, really, is whether the person that wakes up after surgery is the same person that "died" beforehand. Is it really saving someone's life, or is it just replacing them with a simulacrum that has their memories? And that question hardly matters at all.

</comment><comment><USER29> There we go, soon will see zombies like in walking dead if something goes wrong.

</comment><comment><USER30> > _" We are suspending life, but we don't like to call it suspended animation > because it sounds like science fiction," says Samuel Tisherman, a surgeon at > the hospital, who is leading the trial. "So we call it emergency > preservation and resuscitation."_

Because that doesn't sound like science fiction at all...

</comment><comment><USER31> even a tl;dr is long, but worth reading:

      The technique involves replacing all of a patient's
      blood with a cold saline solution.

      The technique was first demonstrated in pigs in 2002 by
      Hasan Alam at the University of Michigan Hospital in Ann
      Arbor, and his colleagues.

      Their blood was drained and replaced by either a cold
      potassium or saline solution, rapidly cooling the body
      to around 10 °C. After the injuries were treated, the
      animals were gradually warmed up as the solution was
      replaced with blood.

      Surgeons are now on call at the UPMC Presbyterian
      Hospital in Pittsburgh, Pennsylvania, to perform the
      operation. Because the trial will happen during a
      medical emergency, neither the patient nor their family
      can give consent. A final meeting this week will ensure
      that a team of doctors is fully prepared to try it. Then
      all they have to do is wait for the right patient to
      arrive. When this happens, every member of Tisherman's
      team will be paged.

      The technique will be tested on 10 people, and the
      outcome compared with another 10 who met the criteria
      but who weren't treated this way because the team wasn't
      on hand. The technique will be refined then tested on
      another 10, says Tisherman, until there are enough
      results to analyse.

      "...we don't like to call it suspended animation because
       it sounds like science fiction..."

      says Samuel Tisherman, a surgeon at the hospital, who is
      leading the trial.

      "After we did those experiments, the definition of 'dead'
       changed, Every day at work I declare people dead. They
       have no signs of life, no heartbeat, no brain activity.
       I sign a piece of paper knowing in my heart that they
       are not actually dead. I could, right then and there,
       suspend them. But I have to put them in a body bag.
       It's frustrating to know there's a solution."

      says surgeon Peter Rhee at the University of Arizona in
      Tucson, who helped develop the technique.

The suspense is _KILLING_ me!</pun>

</comment><comment><USER32> I haven't seen that many pop up ads since 2003.

<comment><USER33> I'll never go back to that site. Absolutely atrocious.

<comment><USER34> NoScript is a fantastic browser add-on. I had no pop-ups.

</comment></comment></comment><comment><USER35> If the human body is anything like the first generation of ACPI this is not going to end well for the patients :P

</comment><comment><USER36> Does this mean people live in Autarctica could live longer but think slower?

</comment><comment><USER37> Replacing __all __of someone 's blood with _anything_ is extremely scary- sounding.

Also, now I can't help but imagine replacing all of someone's blood with things like jello and cream cheese.

<comment><USER38> Ethics committees take all the fun out of science.

<comment><USER39> \- Walter Bishop</comment></comment></comment>


Bill Gates on Google - Worst Predictions - <AUTHOR> http://2010.newsweek.com/top-10/worst-predictions/bill-gates.html <comment><USER2> A tiny collection of more quotes : <http://www.slothmud.org/~hayward/mic_humor/mic_quotes.html></comment>


The most strange and extraordinary character in computer. - <AUTHOR>

۞
↑Here is the strange and extraordinary character I found on PC. This character will cause many strange phenomenon on computer, especially on Windows. Really wired.
1. Copy that and pasta into Google search bar, you will see the text alignment of search bar become right to left.
2. Put it into notepad or any input area on browser. Input blank space before this character, and press backspace, or add some common characters before or after it. Many strange things happen, and you cannot remove it sometime.
Enjoy this ghost-like character! <comment><USER2> Using Linux here, seems totally ordinary to me.

EDIT: Though I really don't understand why a lot of these characters even exist. I mean, what is that? The sun?

EDIT2: When I pasted into DuckDuckGo it actually told me:

[https://en.wikipedia.org/wiki/Rub_el_Hizb](https://en.wikipedia.org/wiki/Rub_el_Hizb)

<comment><AUTHOR> Try Windows.

<comment><USER2> I was just pointing out that a lot of this behavior probably is caused by quirks in windows character handling as opposed to any intrinsic strangeness of the character itself.

FWIW, copy pasting it into google _does_ invert the justification of the search bar text.

<comment><USER3> On a mac, so can't verify - but if it's an Arabic character, seems plausible that Windows just shifts to right-to-left mode, which can sometimes cause some quirks when trying to delete the first/last character, etc.</comment></comment></comment></comment>


Albert Camus: A reconstructed conversation - <AUTHOR> http://nautil.us/issue/49/the-absurd/ingenious-albert-camus <comment><USER2> If you'd like to read something from Camus, I highly recommend The Stranger: [https://en.wikipedia.org/wiki/The_Stranger_(novel)](https://en.wikipedia.org/wiki/The_Stranger_\(novel\))

If you have some knowledge of French, you may try the original French edition - the style is simple and should be very accessible.

<comment><USER3> I haven't read much Camus but I absolutely loved his semi-autobiographical story about his childhood growing up in Algeria he wrote just before he died in a car accident: [https://www.amazon.com/First-Man-Vintage-International- ebook...](https://www.amazon.com/First-Man-Vintage-International- ebook/dp/B008QLVNE2/)

The story stuck with me for a long time and I was told it was much more accessible than many of his earlier books that were more philosophical.

It's a great story if you were ever the intelligent rebellious independent type growing up.

</comment></comment><comment><USER4> A lighthearted view of Camus that some people here may enjoy can be found at [http://existentialcomics.com/philosopher/Albert_camus](http://existentialcomics.com/philosopher/Albert_camus)

</comment><comment><USER5> Camus has been a guiding light for me through my youth and I still draw from him today.

The human absurdity is very real in the modern condition. The challenges we face are so much more profound these days.

With Nuclear armament, AI and climate change, We are literally dealing with topics that frame the end of humanity, but we can't face it.

In the rebel, Camus teaches us that rebellion is probably a futile task.

Governments won't save us, so why riot?

Acceptance of absurdity gives us true freedom to create. Acceptance of systems stifles our ability to solve problems. Technology as a movement is heartening, as long as we continue to break it, reinvent it, hack it - in order to rescue ourselves.

Thanks for sharing this, made my day.

<comment><USER6> > Governments won't save us, so why riot?

Because everything you're talking about, and all of the ideas in the posted article, basically deal with the top-most peak of Maslow's hierarchy:

[https://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs](https://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_needs)

There's still 90% of that iceberg beneath this surface, however.

In other words, human systems and institutions may be powerless to help you reach self-actualization, "save us", solve everything, make humanity endure forever, etc. However, you must be living a VERY comfortable life, free from hunger, health, and personal safety concerns, to wonder why humans bother to riot in some cases.

</comment></comment><comment><USER7> I cannot be anything but skeptical here. Who's to say what Camus would have said if actually asked this questions? Can the dead be "reconstruted" from things said in different contexts, at different points in time? Certainly not with an absolute degree with confidence. Thus, as there is some degree of uncertainty regarding the answers, there would be more than one way in which he might have answered any question given what we know about him. And not one of the possible interviews might be satisfactory, because none of them might be close to an actual interview with Camus.

<comment><USER8> > _I cannot be anything but skeptical here. Who 's to say what Camus would > have said if actually asked this questions?_

Nobody, but that's beside the point. It's not supposed to be a seance, but a made up conversation (plus, the answers are adapted from the writer's own work).

A "discussion" with the writer similar to the way an author discusses with their ideas by reading their books and getting to understand their way of thinking.

> _Certainly not with an absolute degree with confidence._

Yeah, but no such degree of confidence is promised -- or even expected from the readers to have. Approach this similar to how one would approach this guy's writing about Hemingway's Javascript preferences:

[http://byfat.xxx/if-hemingway-wrote-javascript](http://byfat.xxx/if- hemingway-wrote-javascript)

Of course Hemingway didn't have any, and never wrote JS. But the idea is to put what we know about the author (and their preferences, beliefs, mannerisms, style, etc) and apply it to how they'd answer a question or how'd they do something like writing JS.

There's no absolute degree of confidence here either -- Hemingway, were he actually alive today at ~120 years old and interested in programming might surprise us all and opt for Angular. But from what we know, and to the best of our ability to interpret them, this would be his style (and "that would be what Camus would have said" in TFA case).

<comment><USER7> So, I was sleepy and going off to bed when I made that comment and now I've realized that how massively I botched it. Major failure of communication on my part, sorry.

But it's good that you mentioned the Hemingway article, because the difference between that article and this interview highlights pretty well what's my issue with trying to "reconstruct" Camus from quotes. A living person is able to perceive as well as react to context. What questions have been asked, who's asking them, what is the level of understanding of the world, where we are ... these all might be grouped into "context", and the point is that they're all relevant in conversation.

Now, when a person takes up the mannerisms of someone else, it doesn't really detract from their ability of adhering to context. But when they're trying to "reconstruct" a person from things they've said at some point for the purposes of an interview, while trying to preserve those quotes to some degree, there can never be such a close fit between question and answer because each was made in different contexts.

Another way to look a it: what the author did is essentially search the Camus corpus for continuous segments of text which most closely fit his questions. But the answer which Camus would have most likely given could depend on discontinuous segments of text. This is actually pretty common in academic literature: whenever people are trying to reconstruct the meaning of certain concept, like Aristotle's "entelechy" or like Kant's "noumenon", sometimes we have to refer to different passages of the relevant corpus in order to get a clearer picture of what it might have meant. And there's an interaction between these passages, because they don't just heap over one another as in a concatenation of disjointed facts, but instead build upon another. The interaction between different passages might actually change the perceived meaning of individual passages. If there were a living person to answer these questions, whether it be Camus or just someone who really knows Camus, he already has these higher degree interactions in his head. He doesn't have the excerpts of text, he has the model which generates them. So if there's any question which might warrant a more subtle or complex answer, he'll able to do it. Maybe even a question which wasn't previously considered by Camus and for which we can find no immediately relevant passages in the corpus.

My issue isn't that this is some bit of necromancy, but rather that it is a _Procrustean_ bit of necromancy. I wasn't skeptical because there's some degree of uncertainty either (though I think that in between chopping text and answering based on some model there would be less uncertainty regarding the latter), I was skeptical because I think this is an awkward and useless approach. It doesn't "reconstruct" anything, it merely deconstructs the Camus corpus.

</comment></comment></comment><comment><USER9> Just a good related book recommendation: At the Existentialist Cafe is a great piece on philosophy and modern history.

[https://www.goodreads.com/book/show/25658482-at-the- existent...](https://www.goodreads.com/book/show/25658482-at-the- existentialist-caf)</comment>


An Open Question to Path: What distinguishes your app from Instagram? - <AUTHOR> http://kommons.com/questions/312

<comment><USER2> What distinguishes Canon from Nikon?

Having used both services for a few months, I would say I only post "artsy" photos to Instagram, ruthlessly filtering on aesthetics while I find myself posting "inside jokes" to close friends on Path.

It's probably less interesting to quibble about how these apps are different than it is to ask why are the apps taking off now in the first place? Is the next generation of photography hardware agnostic, relying instead on the social features? Overall, what do people take more photos of: art or their friends?

If that is the case, betting on the Facebook guys may not be such a bad move...

</comment><comment><USER3> "Why would you need this many employees to build this?"

How many employees at Path?

<comment><USER4> <https://www.path.com/about>

13 listed on their about-page.

</comment></comment><comment><USER5> Now, now, children. There are enough cookies to go around.

</comment><comment><USER6> This question assumes that there is something valuable that Instagram does that Path is "copying" in some way.

Instagram does a good job of quickly taking photos, applying filters, and then uploading them to your choice of social photo sites. That's something any number of us here could code up in an afternoon with all the APIs and toolkits available on the iPhone/these services.

</comment><comment><USER7> As far as intimacy and close privacy are concerned...why not just go email. People will upload these "intimate or personal" pictures ...and then later complain about privacy concerns. Why all this struggle and buzz. If you want privacy, stay offline or go email.no need for a new app for that. Seriously.

</comment><comment><USER8> Dunbar's number is real. However the truth of the number is from research of Apes.

I am excited for Path, but until it works on Palm Pre and Android, it just wont be for me and my friends.

</comment><comment><USER9> Even the kids know that.

"50 is the new .edu" Exclusivity & Privacy. You can be yourself.

Instagram adds cool effects and helps you share.

Did you even read about them?

<comment><USER10> Quoting from Techcrunch (<http://techcrunch.com/2010/11/14/path-photo- sharing/>)

"Path is a private photo sharing network - think Instagram, but without the filters and with a privacy model that takes away any anxiety associated with sharing photos with people you don't know. It's based around email addresses and phone numbers, rather than a public database of users. And compared to other popular social applications, Path is going against the grain: there's no follow system and the friend system is also quite different from what you're used to on Facebook."

<comment><USER11> If you read the NYT article, selling filters and selling you to advertisers are business models being considered right now.

[http://www.nytimes.com/2010/11/15/technology/15photo.html?pa...](http://www.nytimes.com/2010/11/15/technology/15photo.html?partner=rss&emc=rss)</comment></comment></comment>


Show HN: RemindMe, a reminder bot on Messenger - <AUTHOR> http://remindme.tech <comment><AUTHOR> Hi HN, I'm the maker of RemindMe. I made this bot because I used to spend a lot of time adding reminders on calendars.

Check it out if, like me, you don't want to clutter your brain with little tasks to remember.

Looking forward your feedbacks!</comment>


Ask HN: What are people's main sources of articles these days? - <AUTHOR> I use HN as my primary source of news and articles these days as I'm having difficulty finding alternative sources for tech news, along with meaningful commentary. I find that the variety of article sources on here quite abundant, but aside from finding them on HN, how are people stumbling upon them otherwise? <comment><USER2> I used to enjoy futurology until it was taken over by the eco-crowd: [https://www.reddit.com/r/Futurology/](https://www.reddit.com/r/Futurology/) (I have been working in renewable energy since 2004 and have planted over a million trees, but I would like to get tech news without a political agenda)

lobsters: [https://lobste.rs/](https://lobste.rs/) is pretty good for drilling down into a specific technology.</comment>


Netflix Polls BitTorrent Habits of Leaving Customers - <AUTHOR> http://torrentfreak.com/netflix-polls-bittorrent-habits-of-leaving-customers-100903/ <comment><USER2> That question also has "Bootleg DVDs" as a possible option.

It's a multiple choice question with no "other" option. Netflix including any given option doesn't mean they think it's a big threat, just that they'd like to know if it did start siphoning away lots of their customers.</comment>


Adding Third Party Libraries with Carthage - <AUTHOR> http://littlebitesofcocoa.com/post/120450570974/11-adding-external-libraries-with-carthage

<comment><USER2> Why are you putting Emoji at the end of your HN submission titles?

<comment><AUTHOR> because it's fun! (Also because I've been putting emoji at the end of each of the titles of these bites in all the other forms: [http://twitter.com/lilbitesofcocoa](http://twitter.com/lilbitesofcocoa))

<comment><USER3> Please don't do that. HN prizes plain text and good English, and we generally want titles that are neutral and don't use gimmicks. We don't allow things like hashtags in titles either.</comment></comment></comment>


Why dont Facebook engineers quit over Zucks stance on fake news and hate speech? - <AUTHOR> Why don't Facebook engineers quit over Zuckerberg's stance on fake news and hate speech? Is it the money? Do they actually agree with the policies? I really want to understand the thought process of people that actually work there and unfortunately (or fortunately) no one I know works at Facebook. <comment><USER2> Do you know how many people work at Facebook? Do you think they all share the same moral and political views? Your question seems to expect an answer that applies to all FB engineers. You could just as well ask why everyone isn't vegan.

Some people have quit. Some maybe agree. Most probably need the job. You would have to sample a representative number of FB engineers to get any kind of meaningful answer. Anecdotes and speculation aren't worth anything.

<comment><AUTHOR> That is the purpose of this question. Google engineers are frequently in the news for protesting company policies, which results in actual company changes, but there is never anything from Facebook. I am trying to get a broad sample of thoughts on current and former Facebook employees so I can understand if it is due to company culture, the hiring process selects for likeminded people, or if there are disagreements but no one airs their dirty laundry.

<comment><USER2> Easy to find.

[https://www.nytimes.com/2019/10/28/technology/facebook- mark-...](https://www.nytimes.com/2019/10/28/technology/facebook-mark- zuckerberg-political-ads.html)

[https://www.theguardian.com/technology/2019/oct/28/facebook-...](https://www.theguardian.com/technology/2019/oct/28/facebook- employees-strongly-object-to-policy-allowing-false-claims-in-political-ads)

[http://peninsulapress.com/2019/10/24/facebook-employee- fired...](http://peninsulapress.com/2019/10/24/facebook-employee-fired-after- attending-protest-has-no-regrets/)

[https://www.google.com/amp/s/www.cbsnews.com/amp/news/mark-z...](https://www.google.com/amp/s/www.cbsnews.com/amp/news/mark- zuckerberg-explains-why-facebook-left-up-trump-posts/)

<comment><AUTHOR> Thanks for sharing these. It is still surprising to see only ~250 employees out of ~45,000 signing the letter about politicians to posting advertisements on the platform that include false claims. My original questions still stand for the remaining 44,500+ employees

<comment><USER2> You'll have to ask them. Why isn't the entire US adult population marching in Minneapolis today? What would you learn from compiling that data?

</comment></comment></comment></comment></comment><comment><USER3> Any engineers that had morals would've already quit long ago. In the grand scheme of things, what Facebook is currently accused of is tame compared to the stalking and privacy violations they've been doing for over a decade now.

</comment><comment><USER4> Right, vote with our feet. How about we stop using Facebook? Be that person that who tells friends to do the same.

I think people have their own reasons for doing what they do that isn't so clear cut. I wouldn't want to work at FB but wouldn't rule it out exclusively for a stint. I did work in retail Forex which is like selling lottery tickets, or casino entertainment games, or sports betting. People have to do something with their time.

</comment><comment><USER5> Facebook already has hate speech policies, and it's incredibly hard to define fake news.</comment>


API Tooling Companies: We Are Watching You - <AUTHOR> https://medium.com/@APIdays/api-tooling-companies-we-are-watching-you-46f18e87989a <comment><USER2> API spec-ing can be so powerful when using the right tools. From a single source of truth, one can get: docs, generated SDKs (both backend/frontend) and functional tests.

Full disclosure: I'm the co-author of [http://ramses.tech](http://ramses.tech) an API framework written in Python (on top of Pyramid for those interested to know) that generates a full blown API from a RAML file.</comment>


Show HN: Play Rock-Paper-Scissors Against a Neural Network - <AUTHOR> https://github.com/victorqribeiro/jokenpo <comment><AUTHOR> On my path to improve myself and learn more about machine learning and where it could be applied, I came up with this idea: to feed the neural network during execution time.

On the firsts round, it plays randomly. After 3 rounds gathering information about the player it starts making predictions of next move.

<comment><USER2> Very interesting. I once learned some basic statistics about how most people play rock-paper-scissors, and can now pretty reliably win most best of 3 games I play.

I had to unlearn all of that strategy for this, instead trying to guesstimate the statistical model of my playstyle it had developed and subvert it.

The computer and I actually stayed pretty close together in terms of points, eventhough the computer was slightly ahead of me. The number of ties was only a third of the other 2 point values, which tells me it isn't just randomness.

<comment><AUTHOR> If you start with a pattern and then change later on the game, it might take a while for the nn to catch up, but it'll eventually.</comment></comment></comment>


Ask HN: Are you using the Julia programming language for non-scientific tasks? - vanilla-almond I really like the Julia programming language and although it is described as a general purpose language, it was designed with a focus on programming for mathematical and scientific domains (where it shines). Libraries outside these scientific domains are much less prevalent in the language (as is non-scientific programming activity in general).<p>Are you using Julia outside a scientific domain e.g. for a business app or a web app, or utility tasks? If you are, how have you found the experience and would you recommend the language for non-scientific tasks or domains? <comment><AUTHOR> I built some webapps and it works well. But I spend 99% of my life doing scientific computing, so I tend to mostly use Julia only for scientific computing.</comment>


Stop using JWT for sessions (2016) - <AUTHOR> http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/ <comment><USER2> Top reason for me always was :

> You cannot invalidate individual JWT tokens And there are more security > problems. Unlike sessions - which can be invalidated by the server whenever > it feels like it - individual stateless JWT tokens cannot be invalidated. By > design, they will be valid until they expire, no matter what happens. This > means that you cannot, for example, invalidate the session of an attacker > after detecting a compromise. You also cannot invalidate old sessions when a > user changes their password.

> You are essentially powerless, and cannot 'kill' a session without building > complex (and stateful!) infrastructure to explicitly detect and reject them, > defeating the entire point of using stateless JWT tokens to begin with.

<comment><USER3> Not true. Encode a token and validate it against a constant, which you change in case of a compromise.

<comment><USER2> What's the point of having a token if you need to check it with a database on every request?

Instead of `SELECT isValid from tokens where token="<TOKEN>"`, why not `SELECT user from sessions where session="<COOKIE-SESSION>"`?

<comment><USER4> You don't store the token in the database, you put it in a channel that deploys with your app and can up updated as needed. That can be a flat file shipped with production, or if a production push is too costly, set some other way.

Changing the static token causes all JWT token verifications to fail (since the token is stored in the JWT),so requires each user re-auth on the next request. It's a manual fail-safe to invalidate stored sessions.

This, of course can spike load considerably in the period immediately after, so if that's a problem, you can always use multiple tokens based on some criteria, such as one matching the first letter of the username, or the user id mod some value, so split your user into N chunks that each have their own invalidation token, so you only have to invalidate the sessions of 1/N users.

<comment><AUTHOR> >>Changing the static token causes all JWT token verifications to fail (since the token is stored in the JWT),so requires each user re-auth on the next request.

So if a single user's token gets compromised, you force ALL users to log in again?

<comment><USER4> No, you force the JWT to be verified against the DB, which might be as simple as checking if the JWT creation time is older than the password update time in the DB, and if so, force only those users to log in.

All the token does is force some extra level of scrutiny. It doesn't mean the JWT has to be invalidated,but it does give you the ability to selectively invalidate specific ones for the cost of extra DB load _once_ for all affected users.

<comment><AUTHOR> I see. Thank you for clarifying. :)

Anyway, I'm still not convinced because when it comes to security I feel like it's a better idea to walk the well-trodden path, rather than invent new and exciting mechanisms. JWTs are useful for other stuff, but using them for security requires increasing back-end complexity quite a bit.

<comment><USER4> Sure, I'm not making a case JWT should be used, just that in the cases where the benefits it provides can yield real value (e.g. high capacity secured API with good caching infrastructure behind it), there are mitigations that might help offset the downsides.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> The idea of JWT is basically you give your user a "token" that can be used against many "services" while servers don't have to persist the state of that token, just be able to read the encrypted token, and trust the information in the token. The obvious issue is the server cannot easily revoke that token without blacklisting it, therefore persisting that token somewhere on a blacklist on the server. If you are going to make a lookup for a token in a blacklist you might as well look up for a session ID to being with.

<comment><USER6> Traversing a list of 100,000 users/sessions in a db to pull up the session is a different beast compared to traversing an in memory list of 10-100 revoked JTIs in redis. It is a lot less data to store and optimize (the full session vs. a small list of revoked JTIs)

<comment><USER5> > Traversing a list of 100,000 users/sessions in a db to pull up the session > is a different beast compared to traversing an in memory list of 10-100 > revoked JTIs in redis. It is a lot less data to store and optimize (the full > session vs. a small list of revoked JTIs)

I don't see why one can't use redis to persist sessions at first place and why your list of revoked token would be limited to 100.

<comment><USER7> It does depend on how many users you have and your TTL for the JWT, but if you have a 10 minute time to live, you only need to store the revocations for 10 minutes in redis since otherwise the tokens themselves expire. (Just an example, sub 10 minutes with 24 hours or whatever)

</comment></comment></comment></comment><comment><USER8> If an attacker can read the user's localStorage you have much bigger issues to worry about: XSS, physical access, no TLS, etc. With any of those, the token is the least of your concerns; an attacker can make API calls, read the data, etc anyway, no matter if its JWT or sessions.

So, IF (which is a big if) you implement everything correctly then you have to do two "extra" steps with each tech:

\- Blacklists (or Whitelists). You _do_ need these, because you want users to be able to logout. Then it's a lot more like sessions... oops.

\- CSRF protection for sessions. These become trickier to manage in SPA and just become sort of a "token" that you need to refresh on each call... oops.

It seems that the shortcomings of each technology makes it to lean towards the other. The good news is that both of them are theoretically secure, the bad news is that to reach that level you have to do a lot of work (on both!) with a lot of room for error.

That is why I personally prefer JWT with SPA and CSRF with traditional servers, since the amount of new code that I have to write is a lot lower so chances for error are quite lower. For instance, see the (very brief) documentation of the CSRF for my project server.js: [https://serverjs.io/documentation/router/#csrf- token](https://serverjs.io/documentation/router/#csrf-token) . If I had more time I'd write something similar for JWT.

<comment><USER9> "If an attacker can read the user's localStorage"

9/10 the attacker is the user.

<comment><USER8> Since the topic is authentication, that is an independent concern, right?

Edit: unless you mean something about making the user do something. If it's running a script, it's the same in both ways. Now, if it is about the user retrieving and sending the token, the attacker could still ask the user to manually get the session cookie or the localStorage JWT. The cookies might be protected not to be accessible from JS, but they are still in the browser.

</comment></comment></comment><comment><USER10> It's an interesting reading (together with second part), but should be taken with a grain of salt.

Stateless sessions are useful under load and not necessarily under reddit-size load. I like 2-layered setup actually with long-expiration (1 year) "session" cookie kept on `auth.example.com` domain and short-lived (1 hour) JWT-cookie kept on `example.com` domain. JWT can optionally include permission for dangerous operations which is not automatically granted.

You still need redis to take care of forceful expiration, but that would be very simple call to the small list (1 hour of force-expirations if you reissue jwt-tokens on hourly basis), not data-fetching calls. We can keep this in a tiny redis-cluster colocated with frontend machines. JWT would have enough data to personalize cached templates. This will render really fast.

API-backend, database and larger redis-storages can be kept deeper in logical server-room and be accessed only on cold requests

<comment><USER11> I generally agree, but to me "short-lived" would be below a minute. The point of the short-lived token is to make many clustered requests (as when a page loads a lot of assets) cheap because you only need to check a token. Any other human interaction, which takes longer, should go through the server-persisted session logic.

<comment><USER10> hi ;)

I guess that depends on exact use-cases. Below-a-minute is fine for tightly controlled environments, but publicly-used web-apps usually have a sweet spot with TTLs between 10 and 60 minutes. More requests = shorter TTL, less requests = longer ttl (as it would be counter-productive to have more auth- requests than data-requests)

<comment><USER11> Indeed hi! :)

</comment></comment></comment></comment><comment><USER12> This JSON Web Token Security Cheat Sheet[1] or this python script[2] are both quite useful when reviewing anything using of JWTs.

[1] [https://assets.pentesterlab.com/jwt_security_cheatsheet/jwt_...](https://assets.pentesterlab.com/jwt_security_cheatsheet/jwt_security_cheatsheet.pdf)

[2] [https://github.com/ticarpi/jwt_tool](https://github.com/ticarpi/jwt_tool)

<comment><USER13> Those are great! I find the OWASP cheat sheet[1] useful as well but I'm going to keep the pentesterlab cheetsheet bookmarked for easier to digest to similar data. Thanks for sharing!

[1] [https://www.owasp.org/index.php/JSON_Web_Token_(JWT)_Cheat_S...](https://www.owasp.org/index.php/JSON_Web_Token_\(JWT\)_Cheat_Sheet_for_Java)

</comment></comment><comment><USER14> I'm not 100% sold. I think JWT's are fine in some situations as long as you know the limitations.

Regarding session invalidation, I would handle this in two ways.

1\. Support a "Log everyone out" function by storing a simple version number in the JWT. If the version constant in your app is different to the number in the JWT, it is invalid.

2\. Support a "I need to logout user X function" by storing a blacklist of tokens in your RDBMS. If your RDBMS goes down, you have much bigger problems. A blacklist will be very short, and often completely empty, so lookups will be significantly faster than checking a session table. You could also use Redis or an application cache for storing the blacklist, with an RDBMS fallback.

Regarding storage, there's nothing stopping you putting your JWT into a cookie with the HTTPonly flag set. So long as you're not storing too much in token, they will be less than 4k and so will fit.

<comment><AUTHOR> >>2\. Support a "I need to logout user X function" by storing a blacklist of tokens in your RDBMS.

Again though, the whole point of JWT is to completely avoid server-side state management. The moment you store state somewhere (whether a list of valid tokens or a shorter list of invalid tokens) you have re-invented the concept of sessions, so why not use that instead?

<comment><USER14> How about instead of "the whole point of JWT is to completely avoid server- side state management" we think of it as "the whole point of JWT is to reduce the overheads of server-side state management".

In my answer above, I was pretty clear about how the load on the database can be significantly reduced with a blacklist and optionally Redis out front, thus allowing JWT to significantly reduce the burden on the database.

<comment><USER15> Why would the lookups be faster in a small/empty table? If the lookup is by indexed ID it should be trivially fast either way.

Furthermore, you can store the session information in Redis by ID, too, to reduce DB burden.

</comment></comment></comment></comment><comment><USER16> I used to be very opposed to JWTs but I can see some interesting use cases for them now, at least when using the variant based on public key cryptography. For example, if you need/want the ability to verify token validity locally (i.e. without making a call to you auth backend) they are very handy: Generate a token, sign it using the auth backends' private key and clients can verify it using the public key.

That said, I wouldn't use them as a default authentication mechanism as invalidation requires a connection between clients and auth backend again, as many people here pointed already out. It might still be easier to establish such a channel though than continuously verifying traditional tokens via the backend, which you can solve differently though as well: For example, for our APIs at KIProtect we cache validity information for (hashed) access tokens for 60 seconds on the API server, and we refresh the tokens in the background 30 seconds before they expire (if triggered by a request). Like that we can ensure that invalid tokens cannot be used after a short grace period (60 seconds is good enough for us) while not slowing down clients that perform many API requests as the token needs to be fetched only for the first request and will then never leave the cache (as it gets updated) if the client performs at least one request roughly every 60 seconds (or more often).

</comment><comment><USER17> Sorry, I'm going to be a contrarian here. JWTs can be good.

First, cookies-vs-local storage is a non-issue here. If a JWT is small, it can be put in either location.

The only real issue is, should session state be on the client or on the server?

Suppose you have an app with large numbers of users, doing hundreds+ of queries per second across many boxes. If you put session state on the server, then you must either 1) have sticky sessions, which generate problems when a server goes down; 2) have a central session server, which generates scalability and reliability problems; 3) have a Redis-like distributed system, which either a) must do one or more server-to-server round trips on every client call to validate the session, or b) cache session information on a node.

When latency matters, an extra server-to-server round trip is a non-starter. And if you do server-side caching, then cache invalidation and JWT invalidation present similar problems. ("There are only two hard things in Computer Science: cache invalidation and naming things.").

Server-side sessions don't really buy you much. If you're using a system that has them built in, lovely, but if you're not, it's a lot of extra work.

JWT is a good solution to the problem. You can store _small_ amounts of session state on the client and simplify the whole system. You can avoid having to do lookups to determine state variables. (What database was the user connected to? Is he in mode A or mode B? What timezone? What language?) Put a short expiration on the token (a minute? five minutes?) and force the user to re-validate against some data store after that.

The benefit is that you greatly reduce internal server traffic at the cost of not being able to invalidate a session within your short timeout interval. Depending on your app, letting someone remain an admin for an extra minute is not a big deal.

And if it is a big deal, you can still handle it by sending a message to each node telling it to invalidate that particular user. A pain, yes, but the tradeoffs may be worth it.

<comment><USER18> > If you're using a system that has them built in, lovely, but if you're not, > it's a lot of extra work.

They're built in with PHP and most Node.js frameworks I've ever worked with.

I'm not sure about Python, RoR, etc. web frameworks but the engineering overhead for adopting server-side sessions _should_ approximate 0, since they're usually the default.

<comment><USER19> Ruby dev here, Rails is pretty good at sessions. I hear the Python crowd have some great stuff too.

</comment></comment></comment><comment><USER20> Like many other articles on JWTs, this one mischaracterizes the trade-offs that exist.

You can invalidate individual JWTs, you simply store the blacklisted token IDs in a table in your database. Implemented naively, this results in a request flow in which the database is still accessed on every request, defeating one primary purpose for using JWTs. However, there are better ways.

Since the blacklist is just a collection of random token IDs, it isn't sensitive. You can store it anywhere, including in memory in your web servers or in a distributed cache. You can wait during blacklist/token invalidation events until the newly blacklisted token has been propagated.

Using the above, JWTs enable a design space trade-offs that doesn't exist with session tokens. You trade slower blacklist requests (logout, one time confirmations, etc) and minor auth complexity for one fewer db access per request, more flexibility, and more uniformity if you use oath or similar.

All of this is around 90 lines of python in my Django site.

<comment><USER21> > Since the blacklist is just a collection of random token IDs, it isn't > sensitive. You can store it anywhere, including in memory in your web > servers or in a distributed cache. You can wait during blacklist/token > invalidation events until the newly blacklisted token has been propagated.

This is very dangerous advice. If you're advocating for the addition of a fast blacklist storage, you really haven't changed your previous pattern complaint, but the dangeous bit of your advice is implying that it's simple to store "anywhere" such as "in memory in your web servers."

 _That is a bad idea_. If your authentication model is depending on an explicit stop-list to invalidate tokens, then you need to take the integrity of that data set very seriously or be at serious risk of credential replay attacks. A loss of integrity in this data store in unacceptable. Even some eventual consistency can be dangerous (but is generally accepted as a risk if the time envelope is acceptable).

It's much better (from a security standpoint) to have very short lived tokens and constantly revalidate. The revalidation cycles CAN be full database cycles since they occur at a reduced rate, and you can then have more sophisticated policies there without too much trouble.

> All of this is around 90 lines of python in my Django site.

I don't doubt it, but trying to scale your advice to a product or to an environment with actual concurrency opens up a lot of complications you're not considering.

JWTs are, by and large, just an inferior spec with too many brittle edges. You need to be really careful to properly implement JWTs in your environment. You're much better off either sticking to rich session tokens or using something like Macaroons.

P.S., not only is the phrase "black" list steeped in a history you may not realize you're invoking, but it's much less precise than the term "stop list". Please do consider this.

<comment><USER20> > then you need to take the integrity of that data set very seriously or be at > serious risk of credential replay attacks.

This is no more true in my technique than in session tokens. You have to invalidate session tokens carefully, most simply using serializable database transactions. You can do the same with the blacklist.

People also put session tokens in memory, and your concern about caching and consistency applies equally in that context. The blacklist is in some ways easier to manage because it is not sensitive like a session token. It's more difficult in other ways, but IMO harder to get wrong.

<comment><USER21> > This is no more true in my technique than in session tokens.

Which is to say that it's equally true, but you're advocating for a more ephemeral storage.

> People also put session tokens in memory, and your concern about caching and > consistency applies equally in that context. The blacklist is in some ways > easier to manage because it is not sensitive like a session token. It's more > difficult in other ways, but IMO harder to get wrong.

If you're leaking session tokens your entire authN/authZ system collapses I guess that's not wrong, but it's not clear that your invalidation session is as insensitive as you suggest. For example, if your token generator's RNG has flaws, you're essentially enabling that discovery via a public stoplist store.

Ultimately, it's weird to imagine using something like JWT and having a request-to-authZ scheme. You have all the equipment to do short-lived renewable tokens, and then you get invalidation (to the resolution of your timing) for free and better scaling properties and a whole host of other security benefits.

I personally strongly discourage people to use JWTs at all, but if you are at least take advantage of them!

</comment></comment></comment></comment><comment><USER22> Many in the comments are curious about blacklisting JWTs. No, you don't need to put the whole token on a blacklist. Give your tokens reasonably unique JTI claim[1] and put the affected JTIs on the blacklist.

The benefit of JWTs is that token blacklists are usually much shorter than hypothetical token whitelists.

[1] [https://tools.ietf.org/html/rfc7519#section-4.1.7](https://tools.ietf.org/html/rfc7519#section-4.1.7)

<comment><USER23> What if the blacklist becomes unavailable? The author addresses this in part 2.

<comment><USER24> Then your application is unavailable, just like it would be if your session table went away? I don't get this complaint.

The advantage is that you can use a loosely consistent datastore with expiring entries and few records at any given time. There's lots to love about the approach.

<comment><USER23> > _Then your application is unavailable, just like it would be if your session > table went away?_

The author replies: "congratulations, you've just reinvented sessions, with all their problems (like centralized state) and gained nothing in the process", and also with an implementation that is "less battle-tested".

My own opinion: loose consistency can work in some circumstances, but seems a security risk in others.

<comment><USER25> But we've drastically reduced the amount of central state, the complexity of managing it, the time it takes to access it, the danger of losing it, the performance impact of updates to it, while making the happy path to your site faster.

Revolutionary, maybe not, a solid improvement on the traditional design of sessions, I think so.

</comment></comment></comment></comment></comment><comment><USER26> > Unless you work on a Reddit-scale application, there's no reason to be using > JWT tokens as a session mechanism.

And what should I use when I do work on a Reddit-scale application?

<comment><USER27> [https://paseto.io/](https://paseto.io/)

>>Paseto is everything you love about JOSE (JWT, JWE, JWS) without any of the many design deficits that plague the JOSE standards.

</comment></comment><comment><USER28> Previous discussion: [https://news.ycombinator.com/item?id=11895440](https://news.ycombinator.com/item?id=11895440)

</comment><comment><USER29> From my time browsing HN, the consensus seems to be "don't use JWTs". What is the preferred method of client authentication for simple APIs these days?

<comment><USER30> OAuth access tokens? The difference being that JWTs contain information directly, as well as an access token to hit any APIs, while an access token contains no information on its own - thus solving the revocation issue.

Now I don't think anyone really uses JWTs for API authentication, or they should not at least. APIs should still be gated by access tokens.

</comment></comment><comment><USER31> I use JWT for authentication on my current project. And I eventually ended up having to check the user's 'role' in the database for authorization before I let them do anything anyway (and consequently, revoking someone's user role or suspending their account has immediate effect).

I saw many examples on the net of people putting role/authorization and various other types of session information within the JWT and it just looked insane to me.

Ultimately, I think what I ended up with is only a minor win over just generating random tokens and maintaining a "sessions" table. Probably not worth the effort and likely won't use JWT again.

<comment><USER32> > I saw many examples on the net of people putting role/authorization and > various other types of session information within the JWT and it just looked > insane to me.

Why is this crazy? If you encrypt your JWT with a private key that is only known to the server, then any modification to the JWT will lead to an invalid token.

The only thing here is that the list of roles granted is visible to the user if they were to decode the JWT, which is something you might not be entirely comfortable with but I don't think it's totally crazy.

<comment><USER31> I suppose it depends on the application. I wanted to be able to revoke a user's permissions and not have to wait until token expiration for them to be locked out.

</comment></comment></comment><comment><USER33> Burp Plugin for JWT decoding / attacks [https://github.com/mvetsch/JWT4B](https://github.com/mvetsch/JWT4B)

</comment><comment><USER34> Can anybody recommend a tutorial or book on how to do Authentication properly? Say for the usecase SPA + REST API.

If I google quickly I mostly just find tutorials that turn out to be ads for some 3rd party service. Or other beginner tutorials that don't seem very trustworthy.

I feel like I'm missing something, since this should be a very common use case for most (web) apps.

(Bonus if it also covers User Authorization, i.e. different roles that are allowed to do things or not.)

Thanks.

</comment><comment><USER35> We use JWT for validating simple handoffs from server to server, allowing someone to briefly access a resources such as downloading a file from a server designed to do that. We set the expiration to only an hour, and JWT is excellent for this use case as it means we don't need to implement our entire login and database workflow on a machine that just serves files.

</comment><comment><USER36> "You cannot invalidate individual JWT tokens"

This is not exactly true. There are lots of things you can do to expire tokens. For instance, every JWT has a creation date stamp so you could say on the server side all tokens created before Time.Now() no longer accept as valid. Allowing users to expire ALL tokens, etc.

<comment><USER37> > you could say on the server side all tokens created before Time.Now() no > longer accept as valid

But that's not anywhere near "invalidate individual JWT tokens" \- you're invalidating -every- token before `Time.Now()`. Unless you store a different "valid after" time per user and then you're back to storing sessions in the DB, aren't you?

</comment></comment><comment><USER38> Can someone explain how this is similar/different from the default ways Ruby on Rails stores sessions?

I know they're encrypted and signed, and all the session data is stored in the cookie. This seems to work great, what is the downside of just doing this method (for say, bigger sites)?

<comment><USER39> The only downside I've ever encountered to Rails default sessions involves authenticating against other backend endpoints from JS applications served by Rails. Which really has very little to do with Rails itself...

<comment><USER38> So do you know the difference between that way and the JWT way? All these different methods are kind of confusing, and it seems Rails does it a great way, and everyone hates JWT... but arent they basically the same thing?

</comment></comment></comment><comment><USER40> The arguments here says you can't invalidate a JWT. Exactly!! JWT IS A TOKEN. You can use it for refresh (invalidation & renew) and access (authorization) tokens. There's so much disinformation about JWT. The end result is some not invented here "JWT".

<comment><USER41> Yes but you're missing an entire chunk of context. The problem mentioned in this article is saying it's bad that you can't invalidate a JWT WHEN using them for authentication and/or authorization. This makes it impossible to do things like disable/kill a session that has been deemed hostile or dangerous (like a stolen account).

Now to build on this, good defense-in-depth can help here. For example if you use JWT only for authn but kept authz 100% server-side. You could then revoke the users access to everything so that the blast radius is confined. The bad actor could still authenticate into the system but would not have access to much or any resources.

</comment></comment><comment><USER42> A huge part of the issue with JWT is that it's often used wrongly.

I'm currently in a project where JWT is used. We have a list of searchable items and each one of them holds a gallery of photos - up to 5MB per photo.

The issue at hand is that these photos are served from a certain endpoint which we eventually want to secure, but the back-end's idea here is for the front-end to download the photos via XHR putting the token in the _Authorization_ header - they refuse to send the JWT via cookie saying that it's "incompatible with JWT".

</comment><comment><USER43> JWT is an authentication token - it isn't session state. Session state changes during the lifetime of a session. Whereas the authentication token does not - other than for renewals. Overloading the authentication token to also store unrelated domain concepts such as shopping basket items is a gross abuse of its purpose. Given that generating a JWT token is computationally expensive I really doubt that many people are doing this like the premise of the article suggests.

<comment><USER23> I think by payload they mean the JWT can "store" actual permissions. Not state such as a shopping cart, but a payload composed of permissions granted to this client to do this or that in this app.

<comment><USER43> Storing security claims i.e. permissions in the JWT token is a valid use. This isn't session state. Those permissions don't change, they are in fact cryptographically immutable, until the next renewal of the token. Whereas by definition "state" does change.

<comment><USER23> I know it's a valid use (I use JWTs!). But it _is_ state, which is why you have a payload and not merely an id. State doesn't have to change; that's _mutable_ state. (Permissions do change, by the way, only less frequently than a shopping cart!).

</comment></comment></comment></comment><comment><USER44> We have a requirement that users be logged out after 30 minutes of inactivity, so JWTs are perfect for our use case.

<comment><USER30> Except cookies are quite literally perfect for that - set the expiration to 30 minutes from issuance and it will automatically be expired with inactivity. Or bumped on activity.

<comment><USER45> You shouldn't be trusting the client to expire your sessions for you. (That is, relying on a cookie's expiration to actually expire the session.)

(Now, if you mean looking up a session token in a database and checking _that_ for expiry, then yes, that works, but the only real difference between JWT and tokens then is the latter requiring a database query.)

<comment><USER46> The more important difference between JWT and tokens is that the former requires you to trust that your encryption mechanism is foolproof, whereas the latter doesn't.

<comment><USER45> Session tokens (an unguessable identifier that identifies server-side stored session data), while they don't need to be encrypted or signed, the identifier should usually be cryptographically random, however, so you can still get into trouble there.

JWTs don't have to be encrypted. (And IME, typically aren't.) They need to be signed, but the algorithms that do this are common, well-understood algorithms. Some of them are likely being used by TLS to protect your session anyways. If they're _not_ foolproof, you have bigger issues than JWT.

If you are referring to the implementation, then sure, but the same concerns exist about your implementation of TLS, and the same advice applies: use a well-known, hopefully well tested library.

</comment></comment></comment></comment></comment><comment><USER47> Short lived JWT is ok for stitching desperate micro services together as it saves round trips to verify things but I prefer mystery tokens when using more intimate services that have access to similar underlying stores to verify them. Basically use them appropriately and they are fine.

</comment><comment><USER48> How I use JWT:

an encrypted storage of the user's authentication credentials, stuffed into a persistent domain cookie.

Thus, JWT is just a standardized way of encrypting a json payload and storing/retrieving it in a cookie.

works for me (my arch is stateless), and seems orthogonal to the arguments described in the article.

</comment><comment><USER49> Can someone explain the Cookie vs LocalStorage thing? You can access cookies from Javascript, so how is localstorage worse? Assuming an attacker can execute arbitrary js in the browser (the model provided by the article).

edit: Thanks for the answers - httponly, makes sense.

<comment><USER50> The author glosses over this but what they mean is that you can set the HttpOnly flag on cookies to prevent them from being accessed via JavaScript.

<comment><USER51> But is it still sent automatically on ajax requests by browsers?

<comment><USER52> Yes.

</comment></comment></comment></comment><comment><USER27> Relevant: [https://paseto.io](https://paseto.io) Platform-Agnostic Security Tokens

>Paseto is everything you love about JOSE (JWT, JWE, JWS) without any of the many design deficits that plague the JOSE standards.

</comment><comment><USER53> An update that has not been added to the article yet due to a lack of time: even if you _do_ have a valid usecase for stateless tokens, you probably want PASETO[1] instead of JWT, due to the inherent cryptographic design flaws within JWT[2].

I'm probably not going to engage in the discussions on here this time, as it was an incredibly mentally draining experience last time; the vast majority of arguments were either already addressed in the article itself (which the commenters clearly had not read and understood in full), or argued against a misrepresented claim. It got so bad that I had to dedicate a whole second article to it[3].

If you have a genuine question or concern about the article rather than an Angry Internet Comment, feel free to e-mail me; my contact details are at the bottom of the article. No guarantees on response time as I'm juggling a lot of other plates at the moment, but I'll eventually get around to responding :)

EDIT: Another addition... this presentation[4] gives some insight into the history of JWT-for-sessions and why it became so popular. A spoiler: it wasn't for rationally-technical reasons.

[1] [https://paseto.io/](https://paseto.io/)

[2] [https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is- ba...](https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard- that-everyone-should-avoid)

[3] [http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt- fo...](http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions- part-2-why-your-solution-doesnt-work/)

[4] [https://youtu.be/GrLtOjCTB1s?t=1h2m44s](https://youtu.be/GrLtOjCTB1s?t=1h2m44s)

</comment><comment><USER54> Are there any engineering books that have a collection of best practices for internet engineering problems similar to this one? I find that most of this information is learned colloquially, or through what other frameworks do.

</comment><comment><USER55> I used JWT for a SPA site using Vuejs with Django backend. The project became a nightmare and I had to abandon it because of the increasingly complex security issues. The client was not happy

</comment><comment><USER56> what about setting a secure cookie with a jwt, and expiring it when you log- out? what is the utility in server-sessions? (aside from the ability to revoke it at any time from the server.)

<comment><USER5> > and expiring it when you log-out?

and how would you do that if the user doesn't actively log out of a service?

<comment><USER56> set the cookie in the response to their next request to you?

specifics depend upon the language and framework used on the server, etc...

</comment></comment></comment><comment><USER57> None of what the author is writing about concerning the inability to revoke stateless tokens is particularly novel. We have the same problem with SSL/TLS PKI. Once a cert is revoked, there is no reliable way to ensure that its revocation is enforced among all clients. The world has proved to be content with accepting this risk.

Protip: be sure to read what I said before you use the b-word in your responses.

Additionally, the sarcastic flowchart that is included in part 2 of his post makes some pretty open-ended assumptions. "Just take down the blacklist server" is my favorite.

edit: clarification.

</comment><comment><USER58> This seems to be targeted at web apps. I take it I don't need to remove JWT token support from all of my mobile applications?

<comment><USER21> The problems with JWTs go well beyond "how do we do session invalidation." However, since mobile apps tend to be SSL encrypted on devices that don't reveal contents to users, you've often got a lot more leeway than the transparent condition web apps suffer.

I know my app didn't have any real security challenges until we had a website with actionable data.

</comment></comment><comment><USER59> I wrote a scala JWT library on a weekend when I was more of an intermediate developer (6 years ago?) and it started to be used. But I never ran it in production and flaws were found in it. As a consultant 5 years later I found a customer using it and told them to use someone else's :).

I'm not a security expert - one of the strengths is one of the weaknesses - that's it's a simple spec to implement so your average Joe can implement it, but imperfectly.

</comment><comment><USER60> Wow, I wish people would stop complaining about JWTs..

JWTs are a silver bullet, but it's nicer than rolling your own signing scheme.

Don't run with scissors, don't do security if you don't understand your primitives..

<comment><USER18> The alternative to JWTs isn't rolling your own signing scheme. Use PASETO instead. [https://paseto.io](https://paseto.io)

But the issue being discussed in this article is about _how_ JWTs are being used, not JWTs themselves.

> don't do security if you don't understand your primitives..

The security industry needs to do more to provide tools that _do security_ for people who don't understand their primitives.

</comment></comment><comment><USER61> Obviously written by a non-expert. Half of the claims here are false and he only references other blogs. OWASP is nowhere to be found.

<comment><USER62> This comment is completely unhelpful without detailing which half.

<comment><USER8> Obviously written by a non-expert /s

</comment></comment></comment><comment><USER63> Incorrect, these are not comparable things.

JWTs are a standardized way to securely encode data into a self-contained token. Cookies are special headers added to HTTP requests to store state.

You can _absolutely_ use JWTs as the payload of your cookie. _How you pass_ the session data back and forth is separate from _how you encode_ the session data. Most web frameworks have their own token formats, but you can easily change them to be JWTs.

Using the Authorization header just means you're using a different header, and since it's not automatically sent then you don't have the CSRF issues with browsers, but now you have to manage it more manually in your client-side code.

Regardless of how you encode your tokens, if you want to do instant expiration or other live data lookup then of course you'll need to manage that on your server, whether it's a database, in-memory cache, or something else. The split between where state is managed is irrelevant to the physical transfer and encoding.

<comment><USER18> > This is just FUD.

No, it's an engineering argument that makes several testable claims about JWTs, sane session protocols, and how the two are mutually exclusive.

> JWTs are a standardized way to securely encode data into a self-contained > token. Cookies are special headers added to HTTP requests to store state.

The difference is this:

      - Sane sessions
        - Random unique identifiers stored in a cookie
        - Upon receiving the cookie, the web app looks in the
          filesystem/database/etc. for the data associated with
          that session
        - Can be invalidated by deleting the server-side storage
      - JWT-based sessions without server-side persistence
        - All session state is encoded into the cookie
        - All the trust is outsourced to the client to invalidate
          sessions.

The other arguments follow from this difference.

A strongly worded argument against a bad engineering argument is not FUD.

<comment><USER63> As stated, how you encode state is different from how you transfer state. It's not an engineering argument if you don't understand the fundamentals.

JWTs are a encoding format. You can just put a single random unique identifier in there if you want. And you can use cookies to transfer JWTs automatically instead of using the Authorization header. Either can be checked on every request by the server for further validation.

The limitations you wrote are completely arbitrary.

<comment><USER18> It sounds to me like you don't understand what Sven is arguing against in the article.

> JWTs are a encoding format. You can just put a single random unique > identifier in there if you want. And you can use "cookies" to transfer JWTs > automatically instead of using the Authorization header. Either can be > checked on every request by the server.

This is totally irrelevant!

Does your cookie (JWT, PASETO, or whatever) contain more than just a unique identifier?

The argument is: Are you storing things like user_id=13455&is_admin=false in the cookie instead of having that entirely server-side? Don't do that, it's a bad design, store that server-side instead.

That's literally the argument.

<comment><USER63> How you ENCODE data is different from how you TRANSFER data and neither are related to storing state completely on the client vs the server.

You can pass JWTs as cookie data, and you can store nothing but a single session ID in the JWT itself. They are completely orthogonal and have nothing to do with the actual argument. It's misleading when the title and the entire article talks about JWTs vs session/cookies.

<comment><USER18> > That has nothing to do with JWTs.

Progress! You're so close to understanding the article.

It wasn't ever about _JWTs in particular_. It was a response to a widespread engineering antipattern of "storing all session state in a cookie then maybe encrypting or HMACing it so you don't have to store anything server-side". JWT was just how developers tended to implement this antipattern.

Like, literally, that was the _entire_ point of the _entire_ article that Sven wrote.

The examples of apps that do this have become less common since the article was written, so if you're confused by that, you're just missing context, and that's OK.

As for "anti-JWT" arguments, I've made them separately from the argument of Sven's claims. JWT is an error-prone cryptographic design. I wrote a replacement standard called PASETO that doesn't contain these foot-bullets. _I still don 't recommend people use PASETOs for sessions!_

<comment><USER63> Yes I understand that it's about client vs server managed state and the balance between. You can see this noted in my very first comment.

But this article is titled and talks about JWTs at great length with pros and cons, which is completely misleading. The fact that many of the comments here are only talking about JWTs vs cookies and skip over what and where the state is managed only further reflects that confusion.

Perhaps a better article should be written and posted.</comment></comment></comment></comment></comment></comment></comment>


US Customs seized ship owned by JPMorgan – found $1B worth of drugs on it - <AUTHOR> https://markets.businessinsider.com/news/stocks/cocaine-ship-jpmorgan-owns-vessel-seized-by-us-cbp-2019-7-1028340025 <comment><USER2> As the topic of asset seizure crops up on HN occasionally, this is one of those cases where you can expect to see a docket like _United States v. 40,000 lbs of of cocaine and a pile of cash_ while the beneficial ownership of the ship's contents is uncertain.</comment>


Redesigning Hawaii's Emergency Alert System's Interface in the Open - <AUTHOR> https://hackernoon.com/redesigning-hawaiis-emergy-alert-interface-in-the-open-91c6318a7045 <comment><USER2> As a UI developer, I think we tend to over-think too much with the aesthetics and workflow. I think a simple confirmation prompt/or a 5 second timer before initiation would have prevented the issue.</comment>


German paper claims to be blocking iphone based browsers to force app purchase. - <AUTHOR>

http://eu.techcrunch.com/2009/11/06/europes-biggest-newspaper-decides-the-iphone-browser-isnt-welcome/
Im torn. A part of me thinks this is quite a smart idea, yet the rest of me thinks this is quite a stupid idea. I guess it is a fine line.
Curious to see what others think.
1) I build a site.
2) I then build a iphone app to integrate into the site.
Would it not be best, to perhaps have a page explaining limitations of the web app for an iphone user. ( ie mouseover events )
Personally I think they could have done this better, yet I do to a point like where it could lead. <comment><USER2> Price discrimination: if you're out and about and you can't be bothered to bring your laptop, you have to pay through the app for the news. Or buy a paper copy.

Or you can look at one of their rivals' sites for free.

Between this and Murdoch charging for his UK newssites, we are going to find out for sure to what extent people will switch away to free alternatives, rather than just assuming they will.

</comment><comment><USER3> Oh great, now I need an app for every single website I visit. Oh you don't have one for my phone yet? Oh you are never going to support my phone?

Wait, you've stopped using HTML for your own proprietary markup?

Seriously? This is dumb.

<comment><AUTHOR> It will only be dumb if they try and stay with the limitations of html and current browsers.

If they take advantage of features unique to the iphone I think there is a chance it would be more successful.

What if they gave you a better "offline" search engine than they offer the user thru the browser?

Maybe submitting via your paid app you get a communication channel with "new internet tv newsreaders".

Maybe iphone submitted content gets given priority?

Yes, potentially this development can be looked as a shot in the foot, but I think creativity could make such concepts fantastic and profitable.

</comment></comment><comment><USER2> Clickable link: [http://eu.techcrunch.com/2009/11/06/europes-biggest- newspape...](http://eu.techcrunch.com/2009/11/06/europes-biggest-newspaper- decides-the-iphone-browser-isnt-welcome)

</comment><comment><USER4> this is an interesting development, but i don't like the submission format. you should have submitted it as a link, and put your own feelings into a comment.

<comment><AUTHOR> Thanks for that tip, I had wondered how best to do it. This will be the last time.</comment></comment>


PHD VI: How They Stole Our Drone - <AUTHOR> http://blog.ptsecurity.com/2016/06/phd-vi-how-they-stole-our-drone.html <comment><USER2> Interesting contest, but it seems that the organizers and participants might have overlooked that an active group of RC hobbyists completely reverse engineered the Syma X5C protocol and several other protocols for other popular toy drones already.

[https://github.com/goebish/nrf24_multipro/tree/master/nRF24_...](https://github.com/goebish/nrf24_multipro/tree/master/nRF24_multipro)

</comment><comment><USER3> Holy smokes, what a detailed and informative write-up. Genuinely learned some high and low-level concepts, approaches, and reflections on the event. Glad I got to see this and appreciate the posting here.

</comment><comment><USER4> "There were more those who were interested, but most of them decided not to participate when they found out that it was not about hacking Wi-Fi. Many people are afraid to take on something new and strange, and this keeps the Internet of Things secure."

I find this strange / interesting / amusing. I'm guessing the people who declined are the ones who would probably not get fare with hacking wifi either.

<comment><USER5> i don't know, a lot of folks show up to CTFs with skills to break conventional apps. Actual reverse engineering (especially something a little different like radio) takes a bit more creativity and effort.

</comment></comment><comment><USER6> It's impressive how much you can do with Gnu software defined radio by wiring functional blocks together. It used to take a rack of expensive equipment to tear down an arbitrary signal like that.</comment>


Introducing Frock, a flocking chicken simulation written in Lua with Löve - <AUTHOR> http://webjazz.blogspot.com/2009/02/introducing-frock-flocking-chicken.html <comment><AUTHOR> Right now, it's naive about getting the k-nearest neighbors for any one chicken O(n^2). For my 1GHz computer, I can only run it up to around 50 chickens.

Anyone have good leads on algorithms to cull the number of comparison down to find the k-nearest neighbors? I've been looking at variants of the R-tree, but if there are other techniques, it'd help to know. Thanks ya'll.

<comment><USER2> Nah, you don't need any trees. Just use good old bin-lattice [1]. If it's good enough for Craig Reynolds :)

 _Interaction with Groups of Autonomous Characters_

<http://www.red3d.com/cwr/papers/2000/pip.html>

 _Big Fast Crowds on PS3_

<http://www.red3d.com/cwr/papers/2006/PSCrowdSandbox2006.html>

Seriously, I did a lot of such simulations (in graduate school) and usually the simplest thing is the best.

\-----

[1] Let's say your world is 100x100 units. You create 2D array of 10x10 cells (preallocate each cell to be able to hold max number of agents, so that you don't fragment memory and waste time on allocations/garbage collection/etc.).

In each step of the simulation, you go through all agents and place them in the correct cell (that's O(N) and constant is actually really cheap => cell[0.1 x agent.x][0.1 x agent.y]).

Then for the interactions, just check agents in your cell and also 8 neighboring ones (that's practically O(N) because of repulsion forces).

<comment><AUTHOR> Huh, I had thought about that, but because the bins aren't dynamic, like they are with trees, I figured it would give some odd aberrations. I'll try this first since it's the simplest. Thanks. I didn't know that Craig Reynolds tried it out this way also.</comment></comment></comment>


In social networks, group boundaries promote the spread of ideas, study finds - <AUTHOR> http://phys.org/news/2015-06-social-networks-group-boundaries-ideas.html <comment><USER2> The take away:

 _Loosening these tight group boundaries means that people 's next-door neighbors may have different jobs or levels of education, but they may still have similar politics or recreational activities. These similarities allow people in different social groups to encourage the adoption of a new complex idea, take neighborhood recycling as an example, which can then spread to other neighborhoods and social groups.

But when group boundaries are eliminated entirely, people have almost nothing in common with their neighbors and therefore very little influence over one another, making it impossible to spread complex ideas._

<comment><USER3> Hacker News is a case in point. Its success and civility is due in large part to it being an enclave. Long time users and ycombinator itself has worried that it will be if not has already been a victim of its success as more and more of the general population is drawn to it.

</comment></comment><comment><USER4> I would argue it all comes down to how much 'trust' can be generated within a network. A network of people with lots of common similarities and easily shared traits will have a higher level of trust and therefore a greater propensity to share and receive more nuanced ideas/concepts. Large open and highly diverse networks of people will feel less 'trustworthy' or less 'comfortable' for people to contribute to or participate in.

The most effective networks have high levels of 'inner-trust' to generate ideas between participants, and cross-pollinating trust' to share ideas between networks.

<comment><USER5> This is a powerful argument against entryism.

</comment></comment><comment><USER6> I had written about how limits are not necessarily bad: [http://stephan.sugarmotor.org/2010/08/couple-of-thoughts- abo...](http://stephan.sugarmotor.org/2010/08/couple-of-thoughts-about- evolution-and-economics/)

One can make good arguments in favour of trade barriers as well (related also: "globalization", [https://en.wikipedia.org/wiki/Criticisms_of_globalization](https://en.wikipedia.org/wiki/Criticisms_of_globalization))

</comment><comment><USER7> In _model of_ social networks, group boundaries promote the spread of ideas, study finds. Has the model been tested well?

<comment><USER8> To be honest, I don't find anything surprising about this, as what he describes is a traditional "small world" network (high clustering coefficient with short path links). The strong links within clusters efficiently amplify information, and the weak links between members of different clusters serve to transmit across the graph. (The fewer sparse cuts needed to decompose the graph, the less effectively you will be able to transmit data across it.)

For example, Milgram (1969) found in his famous letter-delivery experiment that the strongest predictor of success when sending a letter across ethnic lines was whether the first jump between ethnic groups was a "strong" or "weak" link -- weak links were significantly more likely to end in a successful transmission. This is almost certainly because ethnicity tends to be an accidental (due to uncontrollable historical factors) signal of socioeconomic group; weak ties are more likely to be across socioeconomic boundaries.

There may be more to the article than the press release indicates; Centola is a former MIT professor with a background in computational modeling, so I assume he brings something new to the table here.

</comment></comment><comment><USER9> "It could be that the Internet is in fact set up and operates in such a way as to allow easier coordination on complex ideas," he said.

I'm not sure if he's being sarcastic. I thought that this was the explicit original purpose of the internet.

<comment><USER3> You're missing his point, and what he is providing a counter-argument to. When he says _" the Internet is in fact set up and operates in such a way"_ he is referring to the widespread impact of echo chambers and filter bubbles, the very phenomenon that most people consider to work against knowledge sharing.

 _" Counterintuitively, he finds that breaking down group boundaries to increase the spread of knowledge across populations may ultimately result in less-effective knowledge sharing. Instead, his research shows that best practices and complex ideas are more readily integrated across populations if some degree of group boundaries is preserved. "_

</comment></comment><comment><USER10> Thank you for sharing this study. It is very interesting.

Every kind of social group has its pros and cons.</comment>


Google Play Install Error 400, 403 and 500 - <AUTHOR>

I have just submitted a game named "Gago Bird Soccer 2014" to Google Play. I got a few complains that the installation failed. We got 3 error messages namely error 400, error 403 and error 500. Anyone know whether the problem is with the game or server or the gadget itself? Most of the time the installation is successful though. <comment><USER2> I used to have error 403 on a game I made. I fixed the problem using this tutorial: [http://www.androidpit.com/forum/590684/google-play-store- how...](http://www.androidpit.com/forum/590684/google-play-store-how-to-fix- play-store-error-403)</comment>