30 comments

[ 3.1 ms ] story [ 68.2 ms ] thread
From this we can safely assume their privacy approach was "lets pray no one will find our S3 buckets"
It would seem that `mysterious ways` was never the best security approach.

Still to impact 10M users given "It has been downloaded by more than 1 million people on Google Play, and ranks as the #24 lifestyle app in the Apple App store" does seem interesting and would love a breakdown upon that as not sure that 9M Apple app users of this. So, probably some deeper breachers of GDPR and the like going on here.

Hah, do they have an "Add a contact to pray for" feature? A Zuckerbergian personal information hoarder/reseller would salivate at the thought of having such info.
"Zuckerbergian personal information hoarder/reseller"

I'm going to have to remember that one. Ha.

From the article:

"Most damningly, the cloud database included whole phone books from users. Whenever a person joins the Communities social network, the app asks if it can invite friends to join. If a user says yes, the app uploads the user’s entire ‘phonebook’ from their device, containing all contacts and associated information."

"more than 1million" just means "1-10million" or whatever the bucket boundary is in the Play UI. Don't try to read too much specifics into these broad estimates.
A reasonable choice. It is a praying app after all ;)
Every time I see an exposure like this I'm reminded of a couple things...

1. Security everywhere is an after thought. How many people have performed a threat analysis of the app they're working on? How many have management who will slow down velocity on features to put the time in to securing personal information?

When the culture isn't there the training isn't there either.

2. I don't know if it's the case here but, in the move to move more work on to app developers (ops, etc) there is only so much they can learn while still delivering on the things. How much of the reality of overloading app developers adds to this?

Another, somewhat related issue is the fragmenting of teams. Having a few in-house devs, an outsourced team in Argentina, and a few other contractors, all coordinated by non-technical managers. This more or less describes all the projects I've worked on in my career and it creates the ideal conditions for security problems.
There are ways to combat that. For example, some clear processes and documentation. This will help many other issues in organizations as well. Someone can have security as part of their KPI. That will put a focus on it.
I don't think it's possible for a sub-$1B consumer operation to be secure, unless they operate inside a very tight sandbox where all the data and processing live inside a Google/Apple/similar sandbox. If the data is managed by the vendor system (which includes most data-monetization plays), it's leaked. Security is too complicated and expensive to get right.
Security isn't a binary state. It's more layered like an onion. There are a lot of layers that even a small startup can do... that many don't.
sending my thoughts and prayers
Thoughts and prayers with the devs.
> up to 10 million people

> Subscriptions run anywhere from $50 to $120.

Holy shit. And presumably it's all tax free.

I wonder if there is some secret underground religious Venture Capital system that we don't know about.

There's no reason to assume it is tax free. You can find out.
The real value is in lead generation, getting contact info of gullible people with spare money.

Lots of dubious products are marketed to religious people, a segment that are easy to soon part with their money.

I wanted to downvote you for disparaging a massive sector of the population, although it is true that superstition is inevitably easier to peddle to people inclined to some form of mysticism. This said, there are plenty of equally "gullible" non-religious segments though ("bio/organic", homeopathy, fitness, diets, "goop", etc etc...).
Given how common unsecured buckets and similar scenarios are and how widespread this architecture is, was there a time where less separation of cloudy concerns meant fewer opportunities to make mistakes and therefore fewer mistakes? Or is the rate the similar, but we just have many more companies creating this type of products these days?
> “The people whose data Pray.com had stored in these phonebook files were not app users,” according to vpnMentor’s analysis this week. “They were simply people whose contact details had been saved on a Pray.com user’s device. In total, we believe Pray.com stored up to 10 million peoples’ private data without their direct permission – and without its users realizing they were allowing it to happen.”

This is the part about this that annoys me the most. I hate how many companies see no issue with grabbing the data of someone else without consent.

This does highlight how tough it can be for a non-tech entity, especially one run by non-tech volunteers, to play in tech spaces.
For bridges we have decided to only allow licensed engineers anywhere near the process. Maybe it's time to do the same for (parts of) tech.
That's a hard argument to make when even the pros still do this stuff. My point was if the pros have trouble doing it then the volunteers more likely will.

There's also a point that many professional techies would probably not want to work on these kinds of products or websites.

If the Engineers say, they wont build your dream bridge, then you wont get a bridge. Easy as that. Sometimes there is a reason pros wont do it.
Yeah, I really doubt that has much merit in this context. If you're one of these engineers feel free to explain why you wouldn't do it and why these entities don't deserve work but an entity like Facebook does.
Engineers will surely build you a bridge, if you pay them to do so, it just will not be your dream bridge. As they have to adhere to physics.

Maybe our problem is that most rules are not physical and thereby easy to break.

> “Through further investigation, we learned that Pray.com had protected some files, setting them as private on the buckets to limit access,” they explained. “However, at the same time, Pray.com had integrated its S3 buckets with another AWS service, the AWS CloudFront content delivery network (CDN). Cloudfront allows app developers to cache content on proxy servers hosted by AWS around the world – and closer to an app’s users – rather than load those files from the app’s servers. As a result, any files on the S3 buckets could be indirectly viewed and accessed through the CDN, regardless of their individual security settings.”

I have minimal knowledge of this kind of configuration, but it seems like making content available via a CDN from the same vendor should by default carry forward access restrictions on the original backend data.