Security features discussion on Brainstorm

[[Wiki.trustroots.org]] is an independent wiki with information for people who are actively exchanging hospitality.
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

You can add some text in this page by clicking the little "edit" link on top of this page. If there is no "edit" link, it means you are not logged in. To log in, click on the little "log in" link on the top left corner. You'll be taken away from this page and to a "Username / Password" screen. Use your CS username and password to log in. If it works, you'll be taken back to this page, but with the ability to edit the content.

If the text that you add doesn't look professional, it is not a problem. Someone that knows how to format a page will come after you and make it look beautiful. The most important is the content.

Issues

Pictures ("Main Photo")

Criticisms

Showing your face adds trust, but sometimes, people upload pictures where they are not clearly recognisable, or even that is not them, and that is not clearly indicated.

Improvement suggestion

  • Having a tickbox under the pictures of visited profile captioned "Member_name physically looks exactly like this", to tell the system which photos are usable for face recognition.
  • Making the upload of one ID usable picture mandatory.
  • Facebook-like picture tools.

Friends

Criticisms

  • The system does not give a guideline on how to use the "friend feature" and it is being used by different members for different purposes. Thus damaging its usability for safety.
  • Too linked to "references". Too many people systematically befriend everyone they leave a reference to.

Improvement suggestion

  • Meshing the friend data with the "anonymous trust statement" data in a way to make it more relevant.
  • Clearly defining the usage of the friend feature
  • labeling friend links with "types" instead of "level": "(former) colleague", "family member".
  • suggest allowing BOTH levels AND types. Levels indicate publicly, the closeness level and trust level. Also when all someone has is level 3 CS friends vs quite a few level 5 or 6 friends, this indicates how strongly to take their refs, and how seriously they take giving their vouches. But knowing if they are relations, old high school friends, or online friends gives useful context for interpreting references.

References

Criticisms

  • The referencer that leaves a bad reference is in a position of "aggressor". The system should take that position.
  • Victims shy away from reporting abuses. Retaliation is very common and poorly addressed.
  • The trust information and the affinity information are mixed in the free text box.
  • References "as a host" and references "as a guest" are presented together along with social, non-surfing refs.
  • Cultural resistance to use of negative and neutral references. Many non-western cultures absolutely resist using negative or even neutral refs as they are considered 'defaming' or create a 'loss of face'; in some cultures no matter who is at fault, a woman who posts a negative reference for harassment will be blamed/shamed.
  • In some cases, the worse the experience, the less likely a negative reference will be left. For instance harassment that is unsuccessful may receive a negref, but in an actual rape, the reporter will not want this event publicly known.

Improvement suggestions

  • Separate the trust information to the affinity information. Reference stack together your appreciation of a person and your appreciation of an hospitality experience. If the two were separated, it would be easier to browse through and pinpoint incompatibilities.
  • Separate negative experiences into 'non-fun' and 'dangerous' - or otherwise flag 'dangerous' references. Right now a dirty floor to sleep on will often be listed as the same 'negative' as 'I had to sleep with a knife I was so scared '. This is poor information segregation for others. 'Negative' and 'extremely negative' could, alternatively, be reinstated, each with a description. Such a bad hosting or surfing experience that it drives people out of CS, or makes hosts refrain from ever surfing, should be somehow notable.
  • Register each couchsurf for both host and surfer, so that it is apparent when one or both have left NO reference for the other party. Most important when neither leave a ref as there is no indication then of the surf happening at all.
    • making this missing information more transparent lets people email to find out what happened.Currently the lack of a reference after a surf is NOT known by CSers nor noted by the system as a potential safety indicator.
    • Missing references (especially a large number of them) can both alert CS to a problem and also if listed, allow people to contact both parties to find out what happened.
  • Drop down menu giving various graduation to a couple of key criteria: "cleanliness", "concordance with the profile" "respect for cultural norms" "manners"
  • More explicit titles than "positive" through "negative".
    • a long time ago we were able to leave little 'titles' for our references...
  • "Neutral" should be the default setting for all refs, and writer/member should have to jump through some hoops to justify both a positive and a negative. Making it harder to leave pos/neg will make people consider if pos/neg are really worth their time.
  • the term 'neutral' could be differentiated into 'OK' (meaning fine but no big deal, should be default setting) and 'mixed', meaning BOTH positive and negative.
  • Example of typical use of each title available to the referencer. For example:
    • Typical use of "Positive": "I had a nice time with her, she managed to spend some time with us in the evening, even though she was quite busy with work."
    • Typical use of "Neutral": "He came to our place on very short notice (which was fine with us) and stayed only one night. He was quite tired when he arrived so we didn't exchange much."
    • Typical use of "Negative": "He stayed for three days with us, making quite a lot of mess and never cleaning it. I suppose we should have told him up straight but we're kind of shy in the family. He's not dangerous at all though, I hope I'm not misusing the negative reference."
  • Problem with above: how to differentiate a real negative from a DANGEROUS negative - that is, someone who makes others feel unsafe? Propose a special category for this.
  • Ask relevant yes/no questions: * Would you host this person again? / Would you recommend this person to your friends (for hosting or surfing)? This is the information people really want!
  • these could be statistically aggregated after 5 hosts + surfs, to show "80% of hosts/surfers would host/surf with this person again.
  • Filter on references: Relevant references often get swallowed by the constant stream of party-and-meeting-references. Party-and-meeting-references don't need to be an issue. If we could filter the references list with a little icon (surfboard, couch or plane. So that I can see "XXXX's reference as a guest", "XXXX's references as a host", "XXXX's references as a travel companion", and if a tag ever goes out for party-and-meeting-references, "XXXX as a social buddy".
  • Propagate the trust: If my best friend had a really good experience, it is likely that I will have one too with the same person.
  • Removing the "negative reference", replace it with "not so good", and have a link: "signal an abuse" on the reference page. Clicking there would take you to a page showing in which cases it is appropriate to leave a negative reference (with, there, the possibility of leaving a "negative" or "abuse" reference), and in which case it is appropriate to contact the MDST.

Vouches

Criticisms

  • Vouching parties
  • Vouching is permanent, when the memberbase is quite young and likely to change over years.

Improvement suggestion

  • allow only one vouch per home town to count as a 'vouch'. This insures that
  1. travellers and hosts having real experiences of couchsurfing are doing the vouching, not local friends and relations and socializing buddies have experienced neither surfing nor hosting.
  2. cliques do not play the system
  3. people have an incentive to meet travellers and to go travelling
  • CON: travelers may be selectively hosted if they have a vouch, but this is true already.
  • Having a tool to report people asking for vouches, suspend the vouching power of multiple offenders.
  • Special reporting on "vouching parties" as reported in Sweden and India
  • Having a delay of one month between the 3rd vouch and the possibility to vouch others.
  • Rendering a clearer image of vouching through a couple of well-chosen examples: 'I would recommend my mother, and my sister and all her friends to stay with this person'
  • Making the whole vouching tree going through one member visible.
    • Highlight vouches from relatives of me. A vouch from a friend is more valuable to me than a vouch for userX.
  • Allow unvouching, at least after a year.
  • Restricting the vouches to people that shared hospitality.
  • Allowing to vouch back only after a delay (to avoid the "I vouch for you if you vouch for me)
  • Add a button saying 'report vouching violation' to make that easier - also a 'rollover' text which explains that vouching cannot be requested or coerced, and if it is, it is a violation

Verification

Criticisms

  • Does not verify real address, but any address that can get mail passed on to you.
  • Has the double status of security feature and source of revenue, the latter confusing the former.
  • Most humans on the planet don't have a credit card. Making this feature accessible only to a minority.
  • You can buy a credit card on Ebay
  • where is paypal?

Improvement suggestion

  • Verification at the post office with an ID card in the countries that allow it.
  • Member-to-member ID verification through checking the passport.
  • Member-to-member address verification through hospitality.
  • Removing the quite-high minimal sum for verification. The minimum should be the minimum required for such a transaction.
  • Or, setting the amount of verification equal to the minimum required for such a transaction, making it fully a security feature by removing its "donation" status.

Other

Most feature are effective only on members with some experience. Fresh new ones are completely unevaluated.

New features

Passport information

Have a field for a member to store in his passport information, ready to be sent to other member at a click of the mouse. Have the hosts to state if they require passport data before hosting. Have a field in references for "I verified his passport data".

Group posts of this member

Allow the user that want to have it displayed to have a link to all (or less) of their group posts.

Visibility score

From the assumption that an abuser would have a "sleeper" profile, put a feature that measures the online activity of a user (forum posts, chat...) and display on his profile.

Pattern analysis

Analyse the web pattern of people that dropped out after getting a negative reference (and that might be busy opening a new profile), there probably much to be learned.

IP ban

Though it's not totally accurate, but it can't be more accurate than doing nothing. The best would actually be to blacklist the suspicious IPs, and keep an eye on them, with a bot and volunteer.

Trust score

Private friend management tool

A couple of tools for people to organise their friend list, sort them in chronologically-met order, give them a "friendship score", tag them... all of that privately within the limit of their access (the friend doesn't know about it). There is already a step in that direction with the anonymous info given for every friend connection.

The goal is to feed a trust algorithm that would combine the data from all the existing security features in a 0 to 10 score. The beauty of it is that it would allow to use the confidential trust data and the private friend attributes without disclosing them. And would be a lot more reliable than public comments, where people chicken out of their true feeling for fear of retaliation.

To allow the algorithm to be implemented (ie. to avoid it disclosing private or confidential data):

- trust score should only take this sensible data in account after a certain amount of content has been submitted on a given member.

- When a new entry is made on a given user, it will go through the algorithm and, before it is "added" (or subtracted) to the existing trust score, it is given a coefficient equal to zero. So that it does not affect at all the trust score. This coefficient would then rise slowly in a random way and should equal 1 after a period between one and three months (or two other values). That way, it is very difficult to link the variations of the trust score to the comment of a given member.

Victim relief service

Having a service independant from MDST, with no actual power on profiles, to listen to people that believe they have been victim of abuse and eventually send the case to MDST. The image of almighty CS-police of MDST might prevent victims to contact them.

Other

  • Poll the membership on the question of abuse, in order to have some relevant data regarding to the occurrence of unreported abuse.
  • Request CS to post number of 'negative' experiences on main statistics page.
  • Request CS give full picture of problems/on-positive experiences by reporting numbers of 'problems with member' and 'problems with ambassador' CUQs. TRANSPARENCY about these problems will fulfill CS' legal requirements.
  • More coherency between the different safety features: Highlight references from people from the friend list, more for a higher lever of friendship. Highlight references from vouched people, verified people, ambassadors. Present differently vouches from friends, non-friends... interconnect the features.
  • COuntry/culture/language-specific package mailed out to new members AND old members in trouble hotspots or where miscommunications due to press or anything else, have confused the message of the CS vision. Especially in their own language, a clearer message is given.
  • Have a subset of 'groups' volunteers that respond on a rapid basis to posts that constitute security breaches, like someone posting private information, email addresses, etc. Ideally there would be global volunteers assigned to a region that would be rapidly responsive here - more trusted than a moderator and able to delete such posts that fit TOU criteria - this feature exists in some form but can be slow. delegate!
  • You delete the profile of an abuser, he'll open another one in a minute. The community loses any chance to trace him. If you really want to ban access to him to the site, freeze profile and put it in a "known abusers" folder. Also mark it in red as "deleted for inappropriate behavior BY CS". ALso: make sure to show other fake profiles this abuser has used, highlight their real name (as would be on passport). A link to this 'Known Abusers' page should go into the next Safety Package sent out.
  • Clearly state to the user the limitations of a security feature. Overstating it causes people to relax as though a higher level of trust has been assured, when it has not.
  • Address next level of safety: Ambassadors as a safety feature.
    • ambassador choice/approval requirements,
    • ambassador ethics,
    • ambassador review (which has been declared but never happened.
    • Consider removing all vouches given to an amb during his tenure as an amb, if he/she was removed for misconduct.
    • Mark profile clearly that ambassadorship was REMOVED BY CS, not voluntarily.