Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Facebook Alternative Releases Source Code
Facebook Alternative Releases Source Code
#1
http://www.tgdaily.com/software-feature ... ource-code]Diaspora is now available for crowdsourcing.
-- Bob
---------
Then the horns kicked in...
...and my shoes began to squeak.
Reply
 
#2
The bad news: several sources I trust have said this code isn't up to snuff (and where did that phrase come from?).

The good news: it's open source, so it can/will be fixed!
-Terry
-----
"so listen up boy, or pornography starring your mother will be the second worst thing to happen to you today"
TF2: Spy
Reply
 
#3
Quote:isn't up to snuff (and where did that phrase come from?)
In the sense you're using it, it came as a mutation in the early 20th century of an older usage that meant "sharp, informed", which itself dates back to the early 19th century. http://www.phrases.org.uk/meanings/up-to-snuff.html]More detail here.
Quote:The good news: it's open source, so it can/will be fixed!
Which is, of course, the point of releasing it.
-- Bob
---------
Then the horns kicked in...
...and my shoes began to squeak.
Reply
 
#4
Sweno, your sources have been http://www.theregister.co.uk/2010/09/16 ... landmines/]confirmed.
-- Bob
---------
Then the horns kicked in...
...and my shoes began to squeak.
Reply
 
#5
Ok I've had some time to poke at the code myself, and I'm both dissaponted and worried.

They don't just have the normal "don't validate user input/SQL injection" problems that every newbie makes.

They have flaws on their code that demonstrate a fundamental misunderstanding of some basic security ideas.

I'm not going to use or suggest anyone else use diasporia untill the project is taken over by people with some experience in the field.

Could this become something great? Sure, but it is nowhere near close enough. Heck it's not even in the same zip code.

It would require a Mozilla level organization adopting this for me to use a release of anything related to this.
-Terry
-----
"so listen up boy, or pornography starring your mother will be the second worst thing to happen to you today"
TF2: Spy
Reply
 
#6
Ouch. That sucks.
Reply
 
#7
http://www.kalzumeus.com/2010/09/22/sec ... ra-launch/]More criticism, including code snippets.
-- Bob
---------
Then the horns kicked in...
...and my shoes began to squeak.
Reply
 
#8
ya, he pretty much hit the nail on the head.

I want to make it clear, I don't think the developers are incompetent. I just think they tried to tackle a very complicated problem with a set of software tools designed to help with quickly implementing ideas.

These are guys:

1) without much experience in the field (something I don't blame them for).

2) trying to come up with an alternative to a dominant platform (something I don't blame them for).

3) using a automated build environment without knowing what it hides / covers up (something I want to blame them for but can't).

4) who never asked anyone with security experience for help, or never listened to the response (something I do blame them for).

4a) because anyone worth their chops should have said 'you don't know enough, get someone who does/let me help'.

Security (especially when you are dealing with other peoples personal information) is not a simple thing. It's complicated, nuanced, deep, and you are dealing with hostile entities with far too much time on their hands.

In order to get it right you have to understand how your own system works (#3), and what the vulnerabilities are of each layer.

You need to assume that any input you get from a different layer of your system might have been compromised, that any and every user you have is Greater Internet Fuckwad who wants nothing more than to screw with you or other users.

When you assume that everyone is out to abuse your system, you tend to build things that compartmentalize the damage that can be done. You trust, but validate, inputs and returns.

You make assumptions about things, but understand what those assumptions are, and how they can interact with other assumption elsewhere.

I know I don't know enough about it. I'm certain that I am in the 'conscious incompetence' group when it comes to the majority of security systems.

And it pains me to see such a promising project attempt to add on security like spackle over gaps in their foundation.
-Terry
-----
"so listen up boy, or pornography starring your mother will be the second worst thing to happen to you today"
TF2: Spy
Reply
 
#9
My Ruby experience is limited (extremely limited); that said, the biggest problem here doesn't seem to be their understanding of their development platform, but rather, of basic security concerns.
What further concerns me is this: even if they do fix each and every security hole that's been exposed, the basic underlying function of this is that each node in the greater Diaspora network is trusted by the other nodes, correct?  And further, nodes can be created and joined to the cloud by anybody.
In principle, this is no different than P2P networks.  But P2P networks don't generally intentionally store private information!
As I used to say back when part of my job was breaking into so-called secure computers: if I have physical access to the machine it's only a matter of time.  And the same is true for encrypted data.  Once it's on a malicious users' machine, it's only a matter of time.*
(* yes I'm aware strong enough encryption makes the 'time' value rather large, but brute force is the last-resort option.  If you have a node running on your box, what's to stop you from sniffing legitimate traffic and ferreting out the key?)

--sofaspud
--"Listening to your kid is the audio equivalent of a Salvador Dali painting, Spud." --OpMegs
Reply
 
#10
sweno Wrote:And it pains me to see such a promising project attempt to add on security like spackle over gaps in their foundation.

Actually, this is something that's bugging me about a lot of the comments on that post. Because, based on my understanding of the Rails framework, the right place to put the security checks wouldn't be in the code that's getting complained about *anyway*. If they make use of the tools, they will in essence be -doing it right-.

-Morgan.
Reply
 
#11
Morganni Wrote:Actually, this is something that's bugging me about a lot of the comments on that post. Because, based on my understanding of the Rails framework, the right place to put the security checks wouldn't be in the code that's getting complained about *anyway*. If they make use of the tools, they will in essence be -doing it right-.

Ok perhaps I messed up in my use of construction analogy then. Allow me to restate:

There are Large gaps in the use and handling of authenticated user privileges. They are confusing the fact that a user is authenticated (this person who says they are bob realy is bob) with allowed (authenticated bob should not be allowed access to information about alice)

This ignorance of scope is one of the basics they seem to just not get. And one of first things you deal with when it comes to dealing with hostile users.

I don't have a lot of experience with ruby on rails, but I know enough to say that this level of security is something you need to bake into the code. It isn't something that can be added on later (ok it can be, but it costs exponentially more to do so. Your better off rewriting in most cases). If it can't be handled in code (something I highly doubt given the articles linked above) they they should not be using the framework.
-Terry
-----
"so listen up boy, or pornography starring your mother will be the second worst thing to happen to you today"
TF2: Spy
Reply
 
#12
sweno Wrote:This ignorance of scope is one of the basics they seem to just not get. And one of first things you deal with when it comes to dealing with hostile users.
I don't have a lot of experience with ruby on rails, but I know enough to say that this level of security is something you need to bake into the code.

The thing is, it's kind of built into the framework already. Or at least, what strikes me as the correct way to handle most of these issues is to do allowability checking in before_filter actions. If it looks good there, then it gets passed on to the business logic. And it makes sense to implement the business logic first under this structure, because that gives certainty on exactly what needs to be checked for a given action. (And, given a reasonably straightforward design, should allow one to avoid a great deal of Repeating Yourself, which has various benefits.)

Basically, it wouldn't cost exponentially more to add proper security to this code. It really, really wouldn't.

The real problem here seems to be a social one. While it may make sense to code things in this order, it's a real problem for code in this state to end up in the hands of people who will actually try to use it as-is. (Though given certain statements in the release, I might call it on the order of a stupidity tax...)

-Morgan.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)