Popular shared stories on NewsBlur.
1359 stories

The glass is already broken

5 Comments and 12 Shares

"You see this goblet?" asks Achaan Chaa, the Thai meditation master. "For me this glass is already broken. I enjoy it; I drink out of it. It holds my water admirably, sometimes even reflecting the sun in beautiful patterns. If I should tap it, it has a lovely ring to it. But when I put this glass on the shelf and the wind knocks it over or my elbow brushes it off the table and it falls to the ground and shatters, I say, 'Of course.' When I understand that the glass is already broken, every moment with it is precious."

From Thoughts Without a Thinker: Psychotherapy from a Buddhist Perspective by Mark Epstein.

Tags: Achaan Chaa   books   Buddhism   Mark Epstein   religion   Thoughts Without a Thinker
Read the whole story
2 days ago
I think I have a better understanding of nothingness after reading this.
Waterloo, Canada
Share this story
3 public comments
6 hours ago
"I am already dead. That makes every living moment precious."
1 day ago
The book's worth reading.
3 days ago
Holy Something. It is weird to me that I understand this so well.
2 days ago
I have to agree with you .. It's weird I totally get it!

Recently Spotted 103-Year-Old Orca Is Bad News For SeaWorld -- Here's Why

2 Comments and 12 Shares

UPDATE: Since this post, Granny has been making serious waves, by guiding her familyswimming hundreds and hundreds of miles off the Pacific coast and by generally proving SeaWorld wrong in every way. Also see this post for an explanation of how scientists know her age. 

SeaWorld could be in trouble because of “Granny,” the world’s oldest known living orca. The 103-year-old whale (also known as J2) was recently spotted off Canada’s western coast with her pod -- her children, grandchildren and great-grandchildren. But while the Granny sighting is thrilling for us, it’s problematic for SeaWorld.    

First of all, SeaWorld has claimed that “no one knows for sure how long killer whales live,” when simple figures or even living and thriving examples -- like Granny -- can give us a pretty good idea. The Whale and Dolphin Conservation project estimates that whales born in captivity only live to 4.5 years old, on average; many of SeaWorld’s orcas die before they reach their 20s. Perhaps because of their reduced lifespans, the whales are forced to breed continuously and at perilously young ages, which could also diminish their overall health. 

Another key aspect of an orca’s life -- which is missing in captivity -- is the ability to swim up to 100 miles per day. When Granny was spotted earlier this week, she had just finished an 800-mile trek from northern California along with her pod. According to animal welfare advocates, long-distance swimming is integral to orcas’ psychological health and well-being; SeaWorld, however, has gone on record claiming that orcas do not need to swim hundreds of miles regularly, ostensibly to defend the parks’ cruel practice of keeping massive, powerful orcas confined to cramped tanks.

Since Granny was first spotted (as early as the 1930s), she’s believed to have mothered two calves, who in turn have had calves of their own. (One of her grandchildren, Canuck, reportedly died at the age of 4 after being captured and held at SeaWorld). As her pod has grown, Granny has kept up with them -- without being separated through human intervention -- and traveled astonishing distances with her pod annually. Orcas at SeaWorld are routinely separated from their pods, which has been known to cause huge mental and emotional strain and can prevent calves from developing normally.

Granny doesn’t simply represent an impressive feat of nature; she embodies what’s wrong with SeaWorld by being a living example of what’s right in the wild. While it’s true that most wild orcas don’t live as long as Granny has, their lifespans are still dramatically longer than those of SeaWorld’s whales (the NOAA estimates that wild female orcas, like Granny, live an average of 50 to 60 years). Their lives are also filled with much more swimming, exploration, variety and bonding with family -- in other words, their lives are likely filled with much more joy.  

Read the whole story
Share this story
2 public comments
9 hours ago
_Blackfish_ was a pretty decent documentary on this topic, the ethically very troubling practice of keeping orcas in captivity. These are very intelligent, even creative, and very social creatures. Keeping them as we do is as wrong as it would be to keep human kids in isolated cellars.
1 day ago
Boston Metro Area

blazepress: Hole punch flip book.

2 Comments and 8 Shares


Hole punch flip book.

Read the whole story
2 days ago
Well, that's sort of genius.
Share this story
1 public comment
2 days ago
Greater Bostonia

Your Password is Too Damn Short

10 Comments and 23 Shares

I'm a little tired of writing about passwords. But like taxes, email, and pinkeye, they're not going away any time soon. Here's what I know to be true, and backed up by plenty of empirical data:

  • No matter what you tell them, users will always choose simple passwords.

  • No matter what you tell them, users will re-use the same password over and over on multiple devices, apps, and websites. If you are lucky they might use a couple passwords instead of the same one.

What can we do about this as developers?

  • Stop requiring passwords altogether, and let people log in with Google, Facebook, Twitter, Yahoo, or any other valid form of Internet driver's license that you're comfortable supporting. The best password is one you don't have to store.

  • Urge browsers to support automatic, built-in password generation and management. Ideally supported by the OS as well, but this requires cloud storage and everyone on the same page, and that seems most likely to me per-browser. Chrome, at least, is moving in this direction.

  • Nag users at the time of signup when they enter passwords that are …

    • Too short: UY7dFd

    • Lack sufficient entropy: aaaaaaaaa

    • Match common dictionary words: anteaters1

This is commonly done with an ambient password strength meter, which provides real time feedback as you type.

If you can't avoid storing the password – the first two items I listed above are both about avoiding the need for the user to select a 'new' password altogether – then showing an estimation of password strength as the user types is about as good as it gets.

The easiest way to build a safe password is to make it long. All other things being equal, the law of exponential growth means a longer password is a better password. That's why I was always a fan of passphrases, though they are exceptionally painful to enter via touchscreen in our brave new world of mobile – and that is an increasingly critical flaw. But how short is too short?

When we built Discourse, I had to select an absolute minimum password length that we would accept. I chose a default of 8, based on what I knew from my speed hashing research. An eight character password isn't great, but as long as you use a reasonable variety of characters, it should be sufficiently resistant to attack.

By attack, I don't mean an attacker automating a web page or app to repeatedly enter passwords. There is some of this, for extremely common passwords, but that's unlikely to be a practical attack on many sites or apps, as they tend to have rate limits on how often and how rapidly you can try different passwords.

What I mean by attack is a high speed offline attack on the hash of your password, where an attacker gains access to a database of leaked user data. This kind of leak happens all the time. And it will continue to happen forever.

If you're really unlucky, the developers behind that app, service, or website stored the password in plain text. This thankfully doesn't happen too often any more, thanks to education efforts. Progress! But even if the developers did properly store a hash of your password instead of the actual password, you better pray they used a really slow, complex, memory hungry hash algorithm, like bcrypt. And that they selected a high number of iterations. Oops, sorry, that was written in the dark ages of 2010 and is now out of date. I meant to say scrypt. Yeah, scrypt, that's the ticket.

Then we're safe? Right? Let's see.

You might read this and think that a massive cracking array is something that's hard to achieve. I regret to inform you that building an array of, say, 24 consumer grade GPUs that are optimized for speed hashing, is well within the reach of the average law enforcement agency and pretty much any small business that can afford a $40k equipment charge. No need to buy when you can rent – plenty of GPU equipped cloud servers these days. Beyond that, imagine what a motivated nation-state could bring to bear. The mind boggles.

Even if you don't believe me, but you should, the offline fast attack scenario, much easier to achieve, was hardly any better at 37 minutes.

Perhaps you're a skeptic. That's great, me too. What happens when we try a longer random.org password on the massive cracking array?

9 characters2 minutes
10 characters2 hours
11 characters6 days
12 characters1 year
13 characters64 years

The random.org generator is "only" uppercase, lowercase, and number. What if we add special characters, to keep Q*Bert happy?

8 characters1 minute
9 characters2 hours
10 characters1 week
11 characters2 years
12 characters2 centuries

That's a bit better, but you can't really feel safe until the 12 character mark even with a full complement of uppercase, lowercase, numbers, and special characters.

It's unlikely that massive cracking scenarios will get any slower. While there is definitely a password length where all cracking attempts fall off an exponential cliff that is effectively unsurmountable, these numbers will only get worse over time, not better.

So after all that, here's what I came to tell you, the poor, beleagured user:

Unless your password is at least 12 characters, you are vulnerable.

That should be the minimum password size you use on any service. Generate your password with some kind of offline generator, with diceware, or a passphrase approach – whatever it takes, but make sure your passwords are all at least 12 characters.

Now, to be fair, as I alluded to earlier all of this does depend heavily on the hashing algorithm that was selected. But you have to assume that every password you use will be hashed with the lamest, fastest hash out there. One that is easy for GPUs to calculate. There's a lot of old software and systems out there, and will be for a long, long time.

And for developers:

  1. Pick your new password hash algorithms carefully, and move all your old password hashing systems to much harder to calculate hashes. You need hashes that are specifically designed to be hard to calculate on GPUs, like scrypt.

  2. Even if you pick the "right" hash, you may be vulnerable if your work factor isn't high enough. Matsano recommends the following:

    • scrypt: N=2^14, r=8, p=1

    • bcrypt: cost=11

    • PBKDF2 with SHA256: iterations=86,000

    But those are just guidelines; you have to scale the hashing work to what's available and reasonable on your servers or devices. For example, we had a minor denial of service bug in Discourse where we allowed people to enter up to 20,000 character passwords in the login form, and calculating the hash on that took, uh … several seconds.

Now if you'll excuse me, I need to go change my PayPal password.

[advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you.
Read the whole story
3 days ago
Disagree on using federated logins like Google/Facebook. If someone learns that password the service provides a handy list of all the other linked accounts which they have also just compromised as a bonus.
Bend, Oregon
3 days ago
I think the idea is that doesn't matter since so many people use the same passwords all over the place anyway and it is better for everyone with a website to NOT invent their own way of storing that one password.
3 days ago
While yes I understand that you are basically creating a single "weak link" it is likely a better option than using the same weak password stored under who knowns what standards. At least google etc has a vested interest in keep your info safe. That said I would love to move away from passwords in general...
1 day ago
I think Mozilla Persona solves this pretty well: the central password is used to create bespoke private keys in the user's browser for the length of a session so then logins to federated sites simply become mostly between your browser and the site. (There's a bit of an issue that the easiest way to validate the tokens is to use a central validation service, but that's a thing that could be fixed with increased adoption of Persona.) I wish articles like this would talk up Persona more, because I think the biggest barrier to Persona is that not enough websites support it, but they should.
1 day ago
If the choice is between federated logins and using the same password, federated is better. Obviously the best choice is a good, unique password for every site.
Share this story
8 public comments
1 day ago
All good (especially passphrases), but the issue with federated logins stays the same: it's unacceptable to put that much trust in a single party and you cannot really do away with password if you want a fallback.
2 days ago
For users tl;dr; "You can't really feel safe until the 12 character mark even with a full complement of uppercase, lowercase, numbers, and special characters."
3 days ago
Instead of showing some ambiguous strings like "great" or "so so". Wouldn't it be helpful to show an estimate how long it woult take to crack a just entered passwort?
3 days ago
3 days ago
There is no cloud, just other people's computers.
3 days ago
We should see some gems and packages to support this
New York City
3 days ago
god do I EVER just love how Bank of America rejects every single one of those passwords
Providence RI USA
3 days ago
What fxer said -- the article in the same breath faults users for using the same password on multiple sites, and then suggests using Google/Facebook login instead...

Yes, this makes sense from the specific POV of the article (odds that the hashed version of your password will be compromised), but there are a lot of other ways a password can leak (key loggers, anyone?), so the less eggs you put in one basket...
3 days ago
Also, I don't want Facebook knowing anything more about me than they already do know. Same for Google or any of the others.
1 day ago
Mozilla Persona solves the privacy concerns of things like Facebook/Google login (and bootstraps on top of Google login as a bonus)... it just needs more traction.

Saturday Morning Breakfast Cereal - The Wolfman

3 Comments and 9 Shares

Hovertext: Disclaimer: Drug not indicated for lycanthropism.

New comic!
Today's News:
Read the whole story
Share this story
2 public comments
4 days ago
Finally the Werewolf problem is solved!
5 days ago

Prosecutors drop robbery case to preserve stingray secrecy in St. Louis

2 Comments and 10 Shares

Prosecutors in St. Louis, Missouri have seemingly allowed four robbery suspects to go free instead of explaining law enforcement’s use of a stingray in court proceedings.

The St. Louis case provides yet another real-world example where prosecutors have preferred to drop charges instead of fully disclosing how the devices, also known as cell-site simulators, work in the real world. Last year, prosecutors in Baltimore did the same thing during a robbery trial.

According to the St. Louis Post-Dispatch, the dismissal this month came just one day before a St. Louis police officer was set to be deposed in the robbery case where three men and a woman were accused of stealing from seven people in September 2013.

Neither the office of Circuit Attorney Jennifer Joyce nor the office of Megan Beesley, a public defender involved in the case, immediately responded to Ars’ request for comment over the weekend. The St. Louis Police Department also did not respond to Ars’ request for comment.

While the St. Louis newspaper did not name the suspects, it reported that an unnamed Circuit Attorney spokesman denied any connection between the dismissal and the forthcoming deposition.

According to court records, detective John Anderson told defense attorneys that the cops had used a "proven law enforcement technique" in order to locate one of the stolen phones and eventually the suspects. Anderson refused to elaborate, citing a non-disclosure agreement that he and his agency were bound by.

This revelation strongly suggests that the St. Louis Police Department has an agreement along the lines of one recently


in a court case in Erie County, New York. In that case, a

rare unredacted form

demonstrated the full extent of the FBI's attempt to quash public disclosure of stringray information. The most egregious example from the document showed that the FBI would prefer to drop a criminal case in order to protect secrecy surrounding the stingray.

Brandon Pavelich, one of the victims who was pistol-whipped and needed 18 stitches, told the Post-Dispatch that "he was ‘shocked’ when prosecutors told him the charges were dropped and explained only that ‘legal issues’ had developed."

The paper continued:

In 2011, St. Louis police approached prosecutors and the court to work out procedures for using a loaner StingRay, said Circuit Court Judge Jack Garvey, who was part of the discussions. He praised police and prosecutors for their efforts to find the appropriate way to authorize StingRay use.

Police mainly used the device to locate crime victims’ cellphones, with the owners’ permission, Garvey explained. He said he was familiar with the technology, and signed administrative search warrants to authorize its use.

In 2012, St. Louis police sought bids for their own StingRay II in an SUV. It is not clear whether the purchase went through.

The court orders used now in St. Louis require a lesser standard of evidence and do not specifically mention cell site simulators, instead favoring this dense language: "Twenty-four hour a day assistance to include switch based solutions including precision location pursuant to probable cause based information queries and all reasonable assistance to permit the aforementioned Agencies to triangulate target location, including but not limited to terminating interfering service on the target telephone."

Read the whole story
Share this story
2 public comments
7 days ago
what is the point of having it then?
Idle, Bradford, United Kingdom
7 days ago
I'm assuming it's a mix of being able to use parallel reconstruction to pretend they didn't use it and the tendency of courts in the past to allow the government to plead national security to conceal their actions. I'm hoping that we're seeing a trend of judges realizing just how much their trust has been abused in that regard.
7 days ago
Hypothesis: the devices use zero-day exploits in the baseband protocol which the FBI doesn't want the telcos to fix. And perhaps the same exploits could be used to interfere with billing.
Mountain View, CA
Next Page of Stories