Andreas – Joakal

October 5, 2009

Curbing stagnation and refining representation – Politics project

Filed under: Projects,Web Development — Tags: , , , , , — Andreas Markauskas @ 9:12 pm
  • Developed: 2009-2010
  • Location: Home
  • Type: Personal Project

Index

Tackling the apathy of voters and politicians.


Summary

Forcing politicians both elected and opposition to listen to the voices rather than be content in voters' apathy.


Description

I have created this political project to encourage competition among stagnant places. The website aims to present short, easy and simple information with definitions of terms like marginal seat, and opinion articles such as ways to create a marginal seat such as this weak example: "Your Warringah how-to-get-rid-of-Tony Abbott guide". With these information, I can present to people who complain about how their hopeless they feel about politics and how everything is too confusing (Very few people know the definition of a marginal seat).

In order to develop my website, I will be using technologies such as Joomla and Wikimedia with PHP backend.


Status

Finished production.


Changes

The direction has changed a bit, there's now two sections; politics and issues. This is because I feel that politics is such a bloody bore to people just want to know what party is for what. There's going to be some more continual updates over time which can be found at Shock Seat's own news section (It's in the forums).

Update: The project has been closed

September 14, 2009

Browser Based Reputation Transfer – JRep project

Filed under: Projects,Web Development — Tags: , , , , , — Andreas Markauskas @ 11:25 pm
  • Developed: 2009
  • Location: Home
  • Type: Personal Project

Update (5th Oct 2009): The project is closed after reviewing OpenID extensively. Since OpenID has been around longer, free, open source and even taken up by large Internet corporations, I found it too much like re-inventing the wheel. I am going to spend time on other projects including my Yaneh project before taking on OpenID again. I suppose it's a lesson in humility when I assumed OpenID wasn't good enough and quickly brushed it aside.

Index

Creating trust in a web of chaos


Summary

An explanation of the basic way to transfer reputation points from one website to another website.


Description

In creating my Yaneh project, I came across an old problem that many new (and old) user submission sites face: the users would be all new and there would be a few (optimistically) that spoil the experience for the rest due to the fact that each submission is giving the same weighting to begin with. In coming up with this, the best way for this to succeed if there was an open standard that can be reliably used from new and old sites alike.

A real life example; a person can get a home loan based on their credit score that was based on the information provided.

However as far as I know, no trust system exists or even one to allow transfer of reputation from one site to another. Despite this, I wished to start at least some groundwork of a free open standards based way to transfer reputation, JRep (Joakal Reputation). This project would serve to build an openness of trust between the server and client where anonymity is rampant in the internet world.

Advantages:

  • A prominent online user can have the site vouch for that person at very minimal expense of the site.
  • User can benefit from extra abilities from being more known.
  • Site can benefit from less risky users who are not anonymous.
  • Long-time internet users can carry their reputation across.

Disadvantages:

  • Electronic trail: You can't avoid being linked together. However this disadvantage is negligible if you avoid stating personally identifying information on both sites.
  • Less privacy overall as it's anti-anonymous.

Beneficial to:

  • Auction sites. More trusted buyer/sellers. Example; new buyers can quickly become trusted.
  • Comment sites (Blogs, forums, etc). More trusted commentators. Example; some forums like people with some credentials.
  • Business: More trusted workers. Example; I provide consultancy services in computers but my association on a prominent computer blog could be beneficial to companies I work with.
  • Banks: More trusted traders. Example; an international business would be more willing to trade with others (Also known as Line of Credit).
  • Submission sites (Recipes, Videos, Links, Jokes, etc). More trusted uploaders. Example; content does not need to be checked as much for trusted users eg old users.


The Basic Theory

The simple process requires minimal interaction from the user at the new site.

  • A click on Localhost/jrep section reveals a list of available old sites that the new site trusts.
  • The user selects an old site from the list which prompts for the username at that old site.
  • Upon user submission, a process is created to send it to the old site which in turn waits for the user to log in.
  • At the old site, the user logs in with the old user name. On the JRep page is the option to confirm/deny the request.
  • Upon confirmation, the old site sends the relevant reputation information to the new site of the specified user. Otherwise a denial is sent.

Simple JRep Process

Fig 1.0. Simple JRep Process.

  1. User happily provides the details to the new website.
  2. New website sends the request to the old website.
  3. User confirms/denies the request at the old website.
  4. Old website sends the reputation data to new website.


The Technical Theory

This code incorporates a way that has less forgery requests, open standard of exchanges, simple for the user and web master and a one way reputation transfer.

JRep Process for trust from new site to old site

Technical JRep To Old Site Process

Fig 1.1. Technical JRep to Old site process.

  1. User submits old site and old user name to new site.
    • New Site server sanitises it (doesn't trust trusted user, ironically).
    • Server stores it and sends the request to Old Site.
  2. Old Site server sanitises it, checks if the Old User Name exists and sends a request back to the new site to see if it exists.
    • New Site server gets a response, sanitises it.
    • Server checks if the site sent a request of the New User Name and sends it back to Old Site if so.
  3. Old Site server sanitises response and updates the record so now it's available to be confirmed/denied by the user at this site.

JRep Process for trust from old site to new site

Technical JRep To New Site Process

Fig 1.2. Technical JRep to New site process.

  1. User confirms or denies the request.
  2. Server sanitises and sends the reputation feedback on confirmation, otherwise a deny without the information is sent.

Example, I send a malicious request at new site to piggy-bank on an old user, Andreas' reputation at Joakal.com. These usual terms: New Site = Yaneh.com, Old Site = Joakal.com, Old User Name = Andreas and New User Name = Joakal

  1. Joakal selected Andreas at Joakal.com as himself.
  2. Yaneh.com receives and sends information to Joakal.com.
  3. Joakal.com tests that Yaneh.com exists by sending a request back.
  4. Yaneh.com confirms this to Joakal.com.
  5. Joakal.com displays it to Andreas.
  6. Andreas sees that I sent a request and selects deny.
  7. Joakal.com understands the request and submits a deny response to Yaneh.com.
  8. Yaneh.com understands the response and places a blackmark on me, Joakal, I can't request from Joakal.com any more.


Standards

What would this project be without standards? Chaos. With no actual background or previous experience in standards, I have created this standard as a rudimentary beginning to build upon (or until someone finds something better).

To send a request to old site

Type Description Limits (chars)
POST Use POST form
server The type of message. (Request) 7
reply_to The location to reply to 50
new_user_name The user name at this site sending it 50
old_user_name The user name at the old site 50
private_key Private key developed by the site so the sites can communicate 50

To send a test to new site

Type Description Limits (chars)
POST Use POST form
server The type of message. (Test) 7
reply_to The location to reply to 50
new_user_name The user name of previous site that sent a request 50
old_user_name The user name at this site 50
private_key Private key developed by the site so the sites can communicate 50

To send a request to yes to the old site

Type Description Limits (chars)
POST Use POST form
server The type of message. (Yes) 7
reply_to The location to reply to 50
new_user_name The user name at this site sending it 50
old_user_name The user name at the old site 50
private_key Private key developed by the site so the sites can communicate 50

To send a denial to new site

Type Description Limits (chars)
POST Use POST form
server The type of message. (Deny) 7
reply_to The location to reply to 50
new_user_name The user name of previous site that sent a request 50
old_user_name The user name at this site 50
private_key Private key developed by the site so the sites can communicate 50

To send a confirmation to new site

Type Description Limits (chars)
POST Use POST form
server The type of message. (Confirm) 7
reply_to The location to reply to 50
new_user_name The user name of previous site that sent a request 50
old_user_name The user name at this site 50
private_key Private key developed by the site so the sites can communicate 50
Reputation data

Reputation data can be one or many things as long it indicates a fact, quantity or quality of the user. Here are some of them.

JRep

  • Name: jrep
  • Type: integer
  • Limit: 0-100

My creation with the aim to be the most simplest and to be the most commonly used where trust systems generate a numerical quality integer based on calculations to allow relative ease of understanding by new sites.

Guidelines of use:

  • 0 for bad/banned/etc.
  • 1 typically indicates a normal starting user.
  • 1-99 indicates normal users.
  • 99 typically indicates a normal user with maximum trust possible.
  • 100 is reserved for site admins wishing to prove authority.

However, the reason it's a guideline is because there may not be a 1-99 rule at some sites or some problematic JRep calculation produces a number bigger than 100 which becomes truncated down to 100 through the database, giving the appearance that the mechanics of trust makes the user look like admin from that old site.

Creation/Join date

  • Name: creation_date
  • Type: date
  • Limit: http://asg.web.cmu.edu/rfc/rfc822.html#sec-5

This is based of when the user registered on the site. The upside is how old the user is. The downside is that it does not indicate activity on the site.


Trust Suggestions

Some suggestions when using a trust-based system:

  • Never be consistent.
  • Have slightly high and lower than actual trust display sometimes.
  • Don't make any trust pivileges available immediately.
  • Reject certain trust on suspicion.
  • Allow the ability to automatically disable the assigned trust from rogue sites/users.
  • One or more denials = bad trust given
  • Four or more inactive requests = bad trust


Problems and expected questions

This is meant to be an exhaustive list to answer all questions. But ask away.

  • Reputation information is transferred in plain text.
  • No encryption code or standard.
  • Spam of requests to old sites.
  • Only one account of old site per request at new site.
  • Multiple websites spring up to vouch for one person.
  • Moderately old users on new site get disadvantaged by recent yet very old users as vouched by other sites.
  • Lack of anonymity or privacy.
  • This web admin only trusts people from "website"!
  • Middle-in-man attacks.
  • One site gets hijacked and favours people so highly

Reputation information is transferred in plain text.

My system promotes the aim of one new site that can handle all old sites provided all these old sites have the JRep feature. However, this will mean even a website can be started up so that website can see, for example what their reputation is at Joakal.com. Rather than an old site that gives permission to select few new sites and other restrictive methods, this openness should instead be embraced.

Methods suggested:

  • As an Old Site, don't ever send more or the full reputation to the site.
  • As a New Site, don't place full trust in one site.

Otherwise, if you're going with a closed off system, I suggest using an agreed closed encyrption method between both sites.

No encryption code or standard

The encryption code is planned to come next although I haven't started coding it yet. As a result, I do not know of the best standard for encryption between sites. I would appreciate the code if you could help create it! You'll be given at most credit though from this open project.

Spam of requests to old sites

Even with a closed off system, there could still be spam sent even to as far as requesting the user to confirm/deny.

Best solution: Use public display names. Implement a system where user names are never public and encourage your users to never ever display their user names. As a bonus, this would prevent 'hacks' through common passwords eg user name: Joakal, password: 123456. Having a display name public instead of user name means random malacious attacks to private user names are no longer possible.

Only one account of old site per request at new site

This forces users to select accounts they have the highest reputation in. However, I believe the system can be expanded to include multiple accounts at old site for one user at new site.

Multiple websites spring up to vouch for one person

This is eliminated if new sites select only the old sites they trust.

Moderately old users get disadvantaged by recent yet very old users as vouched by other sites.

It's up to the web admin whether to give more or less advantage based on history given by other sites. Maybe the web admin just doesn't trust the moderately old user yet.

Lack of anonymity or privacy

Up to the web admin what is transmitted and what is used based on your input. I have provided a working start that's aimed at openness of information you wish to share from one site to another. Sooner or later, you might come to realise that companies are already dilvulging your information without your consent or legally via weak EULAs or terms (which I think is illegal due to certain monopolistic practices). I can't do anything about that but I wish to beat this development to the punch by establishing an open system instead of the company's closed system example.

This web admin only trusts people from "website"!

This project has the risk of alienating new users. For example, a Drama site may only accept users who have been vouched by certain restrictive web sites. My only advice is to take your 'viewership' elsewhere and they may realise they need your valuable viewership. Or you could create your own drama site!

Middle-in-man attacks

I was told that that implementing SSL technology both ways is secure.

One site gets hijacked and favours people so highly

And the favoured people go to the receiving site to take advantage of extra trust. Like the saying, 'don't put all your eggs in one basket'. Never give too much trust to one user from old sites, especially one site. For rogue old sites, it is suggested to disable the received feedback for all users from that site as it's likely completely compromised.


Addenum

Other reading material:


Final words

I wish to thank jdw, dch24, whiskeylover, glarbex, seb42, Foonly, gobbledegook, .Cobby. For answering my questions in the forum.

I will post the JRep project code next, to show the process.

If you have a better idea for transferring reputation or a way to analyse how to gauge trust from a sudden influx of new users to a site, lets hear it.

Update (5th Oct 2009): The project is closed after reviewing OpenID extensively. Since OpenID has been around longer, free, open source and even taken up by large Internet corporations, I found it too much like re-inventing the wheel. I am going to spend time on other projects including my Yaneh project before taking on OpenID again. I suppose it's a lesson in humility when I assumed OpenID wasn't good enough and quickly brushed it aside.

August 2, 2009

Restaurant Guide

Filed under: Projects — Tags: , , — Andreas Markauskas @ 4:04 pm
  • Developed: 2006
  • Location: Computer Graphics College
  • Type: Assignment

A final project for Computer Graphics College Certificate. I was requested to design and develop from scratch with a partner, a presentation that would show tourists about particular areas of Sydney from an information kiosk. For this, we've decided on a Sydney Restaurant Guide using Director MX. We have designed it to have; Restaurants, Reviews, Locations, Help guides and Restaurant yearly events.

With no Director MX, I am unable to produce an example of my work in either Flash or picture form. You can make a request with my Contact Me form.

July 23, 2009

Yaneh Project

Filed under: Projects — Tags: , , , — Andreas Markauskas @ 11:33 pm
  • Developed: 2005-Present
  • Location: Home
  • Type: Personal Project
  • Status: Currently coding

Starting

A project that has been largely a solo hobby project for me since Computer Graphics College. I have aspired to use a system that would tell me what exactly I could cook from my kitchen without going to the store.

Life Delays and Restart

After many months of in between breaks due to school, work and holidays. It was only sometime in 2008 that I've decided to make this project a reality. Following then, the project was surrounded in secrecy since I largely hoped to create a huge impact until late near release where my cookoholic sister showed me sites similar to my basic goals!

Reaction and Plan

However, the sites don't have certain ideals that I feel is necessary and not entirely beneficial. I plan to take advantage of this and become different. Unfortunately, due to the rapid nature and potential features this project may incorporate, I can not entirely or accurately list what Yaneh would have.

Web site: Yaneh.com