1.

INTRODUCTION

1.1 INTRODUCTION

OSN’S have become integral part of our daily life and has profoundly changed the way
we interact with each other, fulfilling our social needs–the needs for social interactions,
information sharing, appreciation and respect. It is also this very nature of social media that
makes people put more content, including photos, over OSNs without too much thought on the
content. However, once something, such as a photo, is posted online, it becomes a permanent
record, which may be used for purposes we never expect. For example, a posted photo in a party
may reveal a connection of a celebrity to a mafia world. Because OSN users may be careless in
posting content while the effect is so far-reaching, privacy protection over OSNs becomes an
important issue. When more functions such as photo sharing and tagging are added, the situation
becomes more complicated. For instance, nowadays we can share any photo as we like on OSNs,
regardless of whether this photo contains other people (is a co-photo) or not. Currently there is
no restriction with sharing of co-photos, on the contrary, social network service providers like
Facebook are encouraging users to post co-photos and tag their friends in order to get more
people involved.
However, what if the co-owners of a photo are not willing to share this photo? Is it a
privacy violation to share this co-photo without permission of the co-owners? Should the co-
owners have some control over the co-photos? To answer these questions, we need to elaborate
on the privacy issues over OSNs. Traditionally, privacy is regarded as a state of social
withdrawal. According to Altman’s privacy regulation theory privacy is a dialectic and dynamic
boundary regulation process where privacy is not static but “a selective control of access to the
self or to ones group”. In this theory, “dialectic” refers to the openness and closeness of self to
others and “dynamic” means the desired privacy level changes with time according to
environment. During the process of privacy regulation, we strive to match the achieved privacy
level to the desired one. At the optimum privacy level, we can experience the desired confidence
when we want to hide or enjoy the desired attention when we want to show. However, if the
actual level of privacy is greater than the desired one, we will feel lonely or isolated; on the other
hand, if the actual level of privacy is smaller than the desired one, we will feel over-exposed and

1
vulnerable. Unfortunately, on most current OSNs, users have no control over the information
appearing outside their profile page. In Thomas, Grier and Nicol examine how the lack of joint
privacy control can inadvertently reveal sensitive information about a user. To mitigate this
threat, they suggest Facebook’s privacy model to be adapted to achieve multi-party privacy.
Specifically, there should be a mutually acceptable privacy policy determining which
information should be posted and shared. To achieve this, OSN users are asked to specify a
privacy policy and a exposure policy. Privacy policy is used to define group of users that are able
to access a photo when being the owner, while exposure policy is used to define group of users
that are able to access when being a co-owner. These two policies will together mutually specify
how a co-photo could be accessed. However, before examining these policies, finding identities
in cophotos is the first and probably the most import step. In the rest of this paper we will focus
on a RF engine to find identities on a co-photo. FR problems over OSNs are easier than a regular
FR problem because the contextual information of OSN could be utilized for FR For example,
people showing up together on a co-photo are very likely to be friends on OSNs, and thus, the
FR engine could be trained to recognize social friends (people in social circle) specifically.
Training techniques could be adapted from the off-the-shelf FR training algorithms, but
how to get enough training samples is tricky. FR engine with higher recognition ratio demands
more training samples (photos of each specific person), but online photo resources are often
insufficient. Users care about privacy are unlikely to put photos online. Perhaps it is exactly
those people who really want to have a photo privacy protection scheme. To break this dilemma,
we propose a privacy-preserving distributed collaborative training system as our FR engine. In
our system, we ask each of our users to establish a private photo set of their own. We use these
private photos to build personal FR engines based on the specific social context and promise that
during FR training, only the discriminating rules are revealed but nothing else. With the training
data (private photo sets) distributed among users, this problem could be formulated as a typical
secure multi-party computation problem. Intuitively, we may apply cryptographic technique to
protect the private photos, but the computational and communication cost may pose a serious
problem for a large OSN. In this paper, we propose a novel consensus based approach to achieve
efficiency and privacy at the same time. The idea is to let each user only deal with his/her private
photo set as the local train data and use it to learn out the local training result. After this, local
training results are exchanged among users to form a global knowledge. In the next round, each

2
user learns over his/hers local data again by taking the global knowledge as a reference. Finally
the information will be spread over users and consensus could be reached.

We show later that by performing local learning in parallel, efficiency and privacy could
be achieved at the same time. Comparing with previous works, our contributions are as follows.
1) In our paper, the potential owners of shared items (photos) can be automatically identified
with/without user-generated tags. 2) We propose to use private photos in a privacy-preserving
manner and social contexts to derive a personal FR engine for any particular user. 3) Orthogonal
to the traditional cryptographic solution, we propose a consensus-based method to achieve
privacy and efficiency. The rest of this paper is organized as follows. In Section 2, we review the
related works. Section 3 presents the formulation of our problem and the assumptions in our
study. In Section 4, we give a detailed description of the proposed mechanism, followed by
Section 5, conducting performance analysis of the proposed mechanism. In Section 6, we
describe our implementation on Android platform with the Facebook SDK and the extensive
experiments to validate the accuracy and efficiency of our system. Finally, Section 7 concludes
the paper.
1.2 EXISTING SYSTEM
A survey was conducted in to study the effectiveness of the existing countermeasure of un
tagging and shows that this countermeasure is far from satisfactory users are worrying about
offending their friends when un tagging. As a result, they provide a tool to enable users to restrict
others from seeing their photos when posted as a complementary strategy to protect privacy.
However, this method will introduce a large number of manual tasks for end users. In,
Squicciarini et al. propose a game-theoretic scheme in which the privacy policies are
collaboratively enforced over the shared data. This happens when the appearance of user i has
changed, or the photos in the training set are modified adding new images or deleting existing
images. The friendship graph may change over time.

1.3 PROPOSED SYSTEM

During the process of privacy regulation, we strive to match the achieved privacy level to
the desired one. Unfortunately, on most current OSNs, users have no control over the
information appearing outside their profile page. In , Thomas, Grier and Nicol examine how the

3
lack of joint privacy control can inadvertently reveal sensitive information about a user. To
mitigate this threat, they suggest Facebook’s privacy model to be adapted to achieve multi-party
privacy. In these works, flexible access control schemes based on social contexts are
investigated. However, in current OSNs, when posting a photo, a user is not required to ask for
permissions of other users appearing in the photo.
In , Besmer and Lipford study the privacy concerns on photo sharing and tagging
features on Facebook. A survey was conducted in to study the effectiveness of the existing
countermeasure of untagging and shows that this countermeasure is far from satisfactory: users
are worrying about offending their friends when un tagging. As a result, they provide a tool to
enable users to restrict others from seeing their photos when posted as a complementary strategy
to protect privacy. However, this method will introduce a large number of manual tasks for end
users. In Squicciarini et al. propose a game-theoretic scheme in which the privacy policies are
collaboratively enforced over the shared data.
Basically, in our proposed one-against-one strategy a user needs to establish classifiers
between self, friend and friend, friend also known as the two loops in Algorithm. 2. During the
first loop, there is no privacy concerns of Alice’s friend list because friendship graph is
undirected. However, in the second loop, Alice need to coordinate all her friends to build
classifiers between them. According to our protocol, her friends only communicate with her and
they have no idea of what they are computing for
Advantages
 Secret Sharing Photo Unknown Person cannot Access The Photos And Any Data Its
Access Permission only .
1.4 OBJECTIVE OF THE PROJECT
Photo sharing is an attractive feature which popularizes Online Social Networks (OSNs).
Unfortunately, it may leak users’ privacy if they are allowed to post, comment, and tag a photo
freely. we attempt to address this issue and study the scenario when a user shares a photo
containing individuals other than himself/herself (termed co-photo for short). To prevent possible
privacy leakage of a photo, we design a mechanism to enable each individual in a photo be aware
of the posting activity and participate in the decision making on the photo posting.

4
 2. SYSTEM STUDY

2.1 FEASIBILITY STUDY

The feasibility of the project is analyzed in this phase and business proposal is put
forth with a very general plan for the project and some cost estimates. During system analysis
the feasibility study of the proposed system is to be carried out. This is to ensure that the
proposed system is not a burden to the company. For feasibility analysis, some
understanding of the major requirements for the system is essential.

Three key considerations involved in the feasibility analysis are

 ECONOMICAL FEASIBILITY
 TECHNICAL FEASIBILITY
 SOCIAL FEASIBILITY

2.1.1. ECONOMICAL FEASIBILITY

This study is carried out to check the economic impact that the system will have
on the organization. The amount of fund that the company can pour into the research and
development of the system is limited. The expenditures must be justified. Thus the developed
system as well within the budget and this was achieved because most of the technologies used
are freely available. Only the customized products had to be purchased.

2.1.2 TECHNICAL FEASIBILITY

This study is carried out to check the technical feasibility, that is, the technical
requirements of the system. Any system developed must not have a high demand on the available
technical resources. This will lead to high demands on the available technical resources. This
will lead to high demands being placed on the client. The developed system must have a modest
requirement, as only minimal or null changes are required for implementing this system.

2.1.3 SOCIAL FEASIBILITY

The aspect of study is to check the level of acceptance of the system by the user. This
includes the process of training the user to use the system efficiently. The user must not feel

5
threatened by the system, instead must accept it as a necessity. The level of acceptance by the
users solely depends on the methods that are employed to educate the user about the system and
to make him familiar with it. His level of confidence must be raised so that he is also able to
make some constructive criticism, which is welcomed, as he is the final user of the system.

6
 3. SOFTWARE AND HARDWARE REQUIREMENTS

3.1 Hardware Requirements

• System : Pentium IV 3.5 GHz.
• Hard Disk : 40 GB.
• Floppy Drive : 1.44 Mb.
• Monitor : 14’ Colour Monitor.
• Mouse : Optical Mouse.
• Ram : 1 GB.

3.2 Software Requirements

• Operating system : Windows XP or Windows 7, Windows 8.

• Coding Language : Java – AWT, Swings, Networking, Android
• Data Base : My Sql
• Documentation : MS Office
• IDE : Eclipse Galileo
• Development Kit : JDK 1.6

7
 4. DESIGN

4.1 ARCHITECTURE

Fig 4.1 System architecture

Our system is evaluated with two criteria: network-wide performance and facial recognition
performance. The former is used to capture the real-world performance of our design on large-
scale OSNs in terms of computation cost, while the latter is an important factor for the user
experience. In this section, we will describe our Android implementation first and then the
experiments to evaluate these two criteria.
4.1.1 Implementation
Our prototype application is implemented on Google Nexus 7 tablets with Android 4.2 Jelly
Bean (API level 17) and Facebook SDK. We use OpenCV Library 2.4.6 to carry out the face

8
detection and Eigenface method to Compute classifiers Feature extraction Check with privacy
policies who post Post photo Pick friends Classifiers Private training set Pick close friends Start
Specify policy Training set Post photo Fig. 4: System structure of our application carry out the
FR. Fig.4 shows the graphical user interface (GUI). A log in/out button could be used for log
in/out with Facebook. After logging in, a greeting message and the profile picture will be shown.
Our prototype works in three modes: a setup mode, a sleeping mode and a working mode.
Running in the setup mode, the program is working towards the establishment of the
decision tree. For this purpose, the private training set Xi and neighborhood Bi need to be
specified. Xi could be specified by the user with the button “Private training set”. When it is
pressed, photos in the smart phone galleries could be selected and added to Xi. To setup the
neighborhood Bi, at this stage, a user needs to manually specify the set of “close friends” among
their Facebook friends with the button “Pick friends” as their neighborhood. According to the
Facebook statistics, on average a user has 130 friends, we assume only a small portion of them
are “close friends”. In our application, each user picks up to 30 “close friends”. Notice that all
the selected friends are required to install our application to carry out the collaborative training.
With Xi and Bi specified, the setup mode could be activated by pressing the button “Start”. Key
operations and the data flow in this mode are enclosed by a yellow dashed box on the system
architecture Fig.4. During the training process, a socket is established exchange local training
results. After the classifiers are obtained, decision tree is constructed and the program
switches from the setup mode to the sleeping mode. Facebook allows us to create a list of friends
such as “close friends” or “Acquaintances”. We can share a photo only to friends on list.
According to the proposed scheme, this friend list should be intersection of owner’s privacy
policy and co-owners’ exposure policies. However, in Facebook API, friend lists are read-only
items, they cannot be created or updated through the current API. That means we cannot
customize a friend list to share a co-photo. Currently, when the button “Post Photo” is pressed,
co-owners of x are identified, then notifications along with x are send to the co-owners to request
permissions. If they all agree to post x, x will be shared on the owner’s page like a normal photo.
In this sense, users could specify their privacy policy but their exposure policies are either
everybody on earth or nobody depending on their attitude toward x. The data flow for a photo
posting activity is illustrated by the solid red arrows. After the requests are sent out, the program
will go back to the sleeping mode. If Xi or Bi is modified, the program will be invoked to the

9
setup mode. In this case, the operations in the yellow dashed box will be performed again and
decision tree will be updated.

Data flow diagram

Fig.4.2 Data Flow Diagram

10
 User Case Diagram

List All Images with Comments

View Image Ranks

Search Posts

View User Profile

Add Posts

Search Posts Based on Keyword

Search Posts Based on Content

Search Friend

Search History
User
View All Requests

Find Strangers

Fig.4.3 Use Case Diagram

11
 Flow Chart : User

Start

User Register

Yes No
Login

View users Profile Username &

Password Wrong

Add posts

Search Posts Based on Keyword

Logout

Search Posts Based on Content

Search Friends

My Search History

View All Requests

Find Strangers

Fig 4.4 Flow chart for User

12
 Flow Chart : Admin

Start

Admin Login

Yes No
Login

Username &
List All Users Password Wrong

List All Images with Comments

Log Out
View Search History

View Image Ranks

Search Posts

Fig 4.5 Flow chart for Admin

13
Class Diagram
Admin
List All Users (), List All Images
with Comments (), View Image
Ranks (), Search Posts (), View
Searched History (), Logout ()
User Name, Address, DOB,
Mobile, Status, Title, Location,
Description, Rank, Privacy, Added
by, Keyword, Date and Time, Post
Name.
Web Server
View user details (), Add posts (),
Methods
Search Posts Based on Keywords
(), Search Posts Based on Content
Methods (), Search Friends, View All Friend
Requests (), My Search History (),
User Name, Address, DOB, Mobile,
Status, Title, Location, Description,
Members
Rank, Privacy, Added by, Keyword,
Members Date and Time, Post Name.

Login
Login, Register Register

User Name, Password Methods Methods Register

Members Name, Password, Mobile,

End User Members E-mail, Address, DOB,
Gender, Pin code, Image.
View user details (), Add posts (),
Search Posts Based on Keywords (),
Search Posts Based on Content (),
Search Friends, View All Friend
Requests (), My Search History (), Methods
Logout ()

User name, Mobile, E-mail, DOB, Title,

Location, Description, Rank, Privacy,
Search by Keyword, Search Content,
Members
Friend Name, Date and Time.

Fig 4.6. Class Diagram

14
Modules and Their Functionalities

 Photo privacy
 Social network,
 Friend list

 Collaborative Learning

Photo privacy

Users care about privacy are unlikely to put photos online. Perhaps it is exactly those people who
really want to have a photo privacy protection scheme. To break this dilemma, we propose a
privacy-preserving distributed collaborative training system as our FR engine. In our system, we
ask each of our users to establish a private photo set of their own. We use these private photos to
build personal FR engines based on the specific social context and promise that during FR
training, only the discriminating rules are revealed but nothing else With the training data
(private photo sets) distributed among users, this problem could be formulated as a typical secure
multi-party computation problem. Intuitively, we may apply cryptographic technique to protect
the private photos, but the computational and communication cost may pose a serious problem
for a large OSN.

Social network

study the statistics of photo sharing on social networks and propose a three realms model: “a
social realm, in which identities are entities, and friendship a relation; second, a visual sensory
realm, of which faces are entities, and co-occurrence in images a relation; and third, a physical
realm, in which bodies belong, with physical proximity being a relation.” They show that any
two realms are highly correlated. Given information in one realm, we can give a good estimation
of the relationship of the other realm. Stone et al., for the first time, propose to use the
contextual information in the social realm and co photo relationship to do automatic FR. They
define a pair wise conditional random field (CRF) model to find the optimal joint labeling by
maximizing the conditional density. Specifically, they use the existing labeled photos as the
training samples and combine the photo co occurrence statistics and baseline FR score to

15
improve the accuracy of face annotation. discuss the difference between the traditional FR
system and the FR system that is designed specifically for OSNs. They point out that a
customized FR system for each user is expected to be much more accurate in his/her own photo
collections. social networks such as Face book. Unfortunately, careless photo posting may reveal
privacy of individuals in a posted photo. To curb the privacy leakage, we proposed to enable
individuals potentially in a photo to give the permissions before posting a co-photo. We designed
a privacy-preserving FR system to identify individuals in a co-photo.

Friend list

Basically, in our proposed one-against-one strategy a user needs to establish classifiers between
self, friend and friend, friend also known as the two loops in Algorithm. 2. During the first loop,
there is no privacy concerns of Alice’s friend list because friendship graph is undirected.
However, in the second loop, Alice need to coordinate all her friends to build classifiers between
them. According to our protocol, her friends only communicate with her and they have no idea of
what they are computing for. Friend list could also be revealed during the classifier reuse stage.
For example, suppose Alice want to find ubt between Bob and Tom, which has already been
computed by Bob. Alice will first query user k to see if ukj has already been computed. If this
query is made in plaintext, Bob immediately knows Alice and Bob are friends. To address this
problem, Alice will first make a list for desired classifiers use private set operations in [10] to
query against her neighbors’ classifiers lists one by one. Classifiers in the intersection part will
be reused. Notice that even with this protection, mutual friends between Alice and Bob are still
revealed to Bob, this is the trade-off we made for classifiers reuse. Actually, OSNs like Face
book shows mutual friends anyway and there is no such privacy setting as “hide mutual friends”

Collaborative Learning

To break this dilemma, we propose a privacy-preserving distributed collaborative training system

as our FR engine. In our system, we ask each of our users to establish a private photo set of their
own. We use these private photos to build personal FR engines based on the specific social
context and promise that during FR training, only the discriminating rules are revealed but
nothing else. propose to use multiple personal FR engines to work collaboratively to improve the
recognition ratio. Specifically, they use the social context to select the suitable FR engines that

16
contain the identity of the queried face image with high probability This data isolation property
is the essence of our secure collaborative learning model and the detailed security analysis. With
KKT conditions and Wolfe dual, detailed iterative updates are listed in Eq

17
 5. IMPLEMENTATION
6.1.Technologies

The Java Programming Language

The Java programming language is a high-level language that can be characterized by all
of the following buzzwords: Simple,Architecture neutral,Object oriented,Portable,Distributed
,Interpreted,Multithreaded,Robust,Dynamic and Secure. With most programming
languages, you either compile or interpret a program so that you can run it on your computer.
The Java programming language is unusual in that a program is both compiled and interpreted.
With the compiler, first you translate a program into an intermediate language called Java byte
codes —the platform-independent codes interpreted by the interpreter on the Java platform. The
interpreter parses and runs each Java byte code instruction on the computer. Compilation
happens just once; interpretation occurs each time the program is executed. The following figure
illustrates how this works.

You can think of Java byte codes as the machine code instructions for the Java Virtual
Machine (Java VM). Every Java interpreter, whether it’s a development tool or a Web browser
that can run applets, is an implementation of the Java VM. Java byte codes help make “write
once, run anywhere” possible. You can compile your program into byte codes on any platform
that has a Java compiler. The byte codes can then be run on any implementation of the Java VM.
That means that as long as a computer has a Java VM, the same program written in the Java
programming language can run on Windows 2000, a Solaris workstation, or on an iMac.

The Java Platform

A platform is the hardware or software environment in which a program runs. We’ve

already mentioned some of the most popular platforms like Windows 2000, Linux, Solaris, and
MacOS. Most platforms can be described as a combination of the operating system and
hardware. The Java platform differs from most other platforms in that it’s a software-only
platform that runs on top of other hardware-based platforms.

The Java platform has two components:

 The Java Virtual Machine (Java VM)

18
  The Java Application Programming Interface (Java API)

You’ve already been introduced to the Java VM. It’s the base for the Java platform and is
ported onto various hardware-based platforms.

The Java API is a large collection of ready-made software components that provide many
useful capabilities, such as graphical user interface (GUI) widgets. The Java API is grouped into
libraries of related classes and interfaces; these libraries are known as packages. The next
section, What Can Java Technology Do? Highlights what functionality some of the packages in
the Java API provide.

The following figure depicts a program that’s running on the Java platform. As the figure
shows, the Java API and the virtual machine insulate the program from the hardware.

Native code is code that after you compile it, the compiled code runs on a specific
hardware platform. As a platform-independent environment, the Java platform can be a bit
slower than native code. However, smart compilers, well-tuned interpreters, and just-in-time byte
code compilers can bring performance close to that of native code without threatening
portability.

What Can Java Technology Do?

The most common types of programs written in the Java programming language are
applets and applications. If you’ve surfed the Web, you’re probably already familiar with
applets. An applet is a program that adheres to certain conventions that allow it to run within a
Java-enabled browser.

However, the Java programming language is not just for writing cute, entertaining applets
for the Web. The general-purpose, high-level Java programming language is also a powerful
software platform. Using the generous API, you can write many types of programs.

An application is a standalone program that runs directly on the Java platform. A special
kind of application known as a server serves and supports clients on a network. Examples of
servers are Web servers, proxy servers, mail servers, and print servers. Another specialized
program is a servlet. A servlet can almost be thought of as an applet that runs on the server side.
Java Servlets are a popular choice for building interactive web applications, replacing the use of
CGI scripts. Servlets are similar to applets in that they are runtime extensions of applications.

19
Instead of working in browsers, though, servlets run within Java Web servers, configuring or
tailoring the server.

How does the API support all these kinds of programs? It does so with packages of
software components that provides a wide range of functionality. Every full implementation of
the Java platform gives you the following features:

 The essentials: Objects, strings, threads, numbers, input and output, data structures,
system properties, date and time, and so on.

 Applets: The set of conventions used by applets.

 Networking: URLs, TCP (Transmission Control Protocol), UDP (User Data gram
Protocol) sockets, and IP (Internet Protocol) addresses.

 Internationalization: Help for writing programs that can be localized for users
worldwide. Programs can automatically adapt to specific locales and be displayed in the
appropriate language.

 Security: Both low level and high level, including electronic signatures, public and
private key management, access control, and certificates.

 Software components: Known as JavaBeansTM, can plug into existing component

architectures.

 Object serialization: Allows lightweight persistence and communication via Remote

Method Invocation (RMI).

 Java Database Connectivity (JDBCTM): Provides uniform access to a wide range of

relational databases.

How Will Java Technology Change My Life?

We can’t promise you fame, fortune, or even a job if you learn the Java programming
language. Still, it is likely to make your programs better and requires less effort than other
languages. We believe that Java technology will help you do the following:

 Get started quickly: Although the Java programming language is a powerful object-
oriented language, it’s easy to learn, especially for programmers already familiar with C
or C++.

20
  Write less code: Comparisons of program metrics (class counts, method counts, and so
on) suggest that a program written in the Java programming language can be four times
smaller than the same program in C++.

 Write better code: The Java programming language encourages good coding practices,
and its garbage collection helps you avoid memory leaks. Its object orientation, its
JavaBeans component architecture, and its wide-ranging, easily extendible API let you
reuse other people’s tested code and introduce fewer bugs.

 Develop programs more quickly: Your development time may be as much as twice as
fast versus writing the same program in C++. Why? You write fewer lines of code and it
is a simpler programming language than C++.

 Avoid platform dependencies with 100% Pure Java: You can keep your program
portable by avoiding the use of libraries written in other languages. The 100% Pure
JavaTM Product Certification Program has a repository of historical process manuals,
white papers, brochures, and similar materials online.

 Write once, run anywhere: Because 100% Pure Java programs are compiled into
machine-independent byte codes, they run consistently on any Java platform.

 Distribute software more easily: You can upgrade applets easily from a central server.
Applets take advantage of the feature of allowing new classes to be loaded “on the fly,”
without recompiling the entire program.

ODBC

Microsoft Open Database Connectivity (ODBC) is a standard programming interface for

application developers and database systems providers. Before ODBC became a de facto
standard for Windows programs to interface with database systems, programmers had to use
proprietary languages for each database they wanted to connect to. Now, ODBC has made the
choice of the database system almost irrelevant from a coding perspective, which is as it should
be. Application developers have much more important things to worry about than the syntax that
is needed to port their program from one database to another when business needs suddenly
change.

21
 Through the ODBC Administrator in Control Panel, you can specify the particular
database that is associated with a data source that an ODBC application program is written to
use. Think of an ODBC data source as a door with a name on it. Each door will lead you to a
particular database. For example, the data source named Sales Figures might be a SQL Server
database, whereas the Accounts Payable data source could refer to an Access database. The
physical database referred to by a data source can reside anywhere on the LAN.

The ODBC system files are not installed on your system by Windows 95. Rather, they
are installed when you setup a separate database application, such as SQL Server Client or
Visual Basic 4.0. When the ODBC icon is installed in Control Panel, it uses a file called
ODBCINST.DLL. It is also possible to administer your ODBC data sources through a stand-
alone program called ODBCADM.EXE.
From a programming perspective, the beauty of ODBC is that the application can be written to
use the same set of function calls to interface with any data source, regardless of the database
vendor. The source code of the application doesn’t change whether it talks to Oracle or SQL
Server. We only mention these two as an example. There are ODBC drivers available for several
dozen popular database systems. Even Excel spreadsheets and plain text files can be turned into
data sources. The operating system uses the Registry information written by ODBC
Administrator to determine which low-level ODBC drivers are needed to talk to the data source
(such as the interface to Oracle or SQL Server). The loading of the ODBC drivers is transparent
to the ODBC application program. In a client/server environment, the ODBC API even handles
many of the network issues for the application programmer.

The advantages of this scheme are so numerous that you are probably thinking there must
be some catch. The only disadvantage of ODBC is that it isn’t as efficient as talking directly to
the native database interface. ODBC has had many detractors make the charge that it is too slow.
Microsoft has always claimed that the critical factor in performance is the quality of the driver
software that is used. In our humble opinion, this is true. The availability of good ODBC drivers
has improved a great deal recently. And anyway, the criticism about performance is somewhat
analogous to those who said that compilers would never match the speed of pure assembly
language. Maybe not, but the compiler (or ODBC) gives you the opportunity to write cleaner
programs, which means you finish sooner. Meanwhile, computers get faster every year.

22
JDBC

In an effort to set an independent database standard API for Java; Sun Microsystems
developed Java Database Connectivity, or JDBC. JDBC offers a generic SQL database access
mechanism that provides a consistent interface to a variety of RDBMSs. This consistent interface
is achieved through the use of “plug-in” database connectivity modules, or drivers. If a database
vendor wishes to have JDBC support, he or she must provide the driver for each platform that the
database and Java run on.

To gain a wider acceptance of JDBC, Sun based JDBC’s framework on ODBC. As you
discovered earlier in this chapter, ODBC has widespread support on a variety of platforms.
Basing JDBC on ODBC will allow vendors to bring JDBC drivers to market much faster than
developing a completely new connectivity solution.

JDBC was announced in March of 1996. It was released for a 90 day public review that
ended June 8, 1996. Because of user input, the final JDBC v1.0 specification was released soon
after.

The remainder of this section will cover enough information about JDBC for you to know what it
is about and how to use it effectively. This is by no means a complete overview of JDBC. That
would fill an entire book.

JDBC Goals

Few software packages are designed without goals in mind. JDBC is one that, because of
its many goals, drove the development of the API. These goals, in conjunction with early
reviewer feedback, have finalized the JDBC class library into a solid framework for building
database applications in Java.

The goals that were set for JDBC are important. They will give you some insight as to why
certain classes and functionalities behave the way they do. The eight design goals for JDBC are
as follows:

1. SQL Level API

23
 The designers felt that their main goal was to define a SQL interface for Java.
Although not the lowest database interface level possible, it is at a low enough level for
higher-level tools and APIs to be created. Conversely, it is at a high enough level for
application programmers to use it confidently. Attaining this goal allows for future tool
vendors to “generate” JDBC code and to hide many of JDBC’s complexities from the end
user.

2. SQL Conformance

SQL syntax varies as you move from database vendor to database vendor. In an effort
to support a wide variety of vendors, JDBC will allow any query statement to be passed
through it to the underlying database driver. This allows the connectivity module to
handle non-standard functionality in a manner that is suitable for its users.

3. JDBC must be implemental on top of common database interfaces

The JDBC SQL API must “sit” on top of other common SQL level APIs. This goal
allows JDBC to use existing ODBC level drivers by the use of a software interface. This
interface would translate JDBC calls to ODBC and vice versa.

4. Provide a Java interface that is consistent with the rest of the Java system

Because of Java’s acceptance in the user community thus far, the designers feel that
they should not stray from the current design of the core Java system.

5. Keep it simple

This goal probably appears in all software design goal listings. JDBC is no exception.
Sun felt that the design of JDBC should be very simple, allowing for only one method of
completing a task per mechanism. Allowing duplicate functionality only serves to
confuse the users of the API.

6. Use strong, static typing wherever possible

Strong typing allows for more error checking to be done at compile time; also, less
error appear at runtime.

7. Keep the common cases simple

24
 Because more often than not, the usual SQL calls used by the programmer are simple
SELECT’s, INSERT’s, DELETE’s and UPDATE’s, these queries should be simple to
perform with JDBC. However, more complex SQL statements should also be possible.

MySQL

Fig. 5.1 MySQL Architecture

The second layer is where things get interesting. Much of MySQL’s brains are here, including
the code for query parsing, analysis, optimization, caching, and all the built-in functions (e.g.,
dates, times, math, and encryption). Any functionality provided across storage engines lives at
this level: stored procedures, triggers, and views, for example.

The third layer contains the storage engines. They are responsible for storing and retrieving all
data stored “in” MySQL. Like the various filesystems available for GNU/Linux, each storage
engine has its own benefits and drawbacks. The server communicates with them through
the storage engine API. This interface hides differences between storage engines and makes
them largely transparent at the query layer. The API contains a couple of dozen low-level
functions that perform operations such as “begin a transaction” or “fetch the row that has this
25
primary key.” The storage engines don’t parse SQL[4] or communicate with each other; they
simply respond to requests from the server.

Connection Management and Security

Each client connection gets its own thread within the server process. The connection’s queries
execute within that single thread, which in turn resides on one core or CPU. The server caches
threads, so they don’t need to be created and destroyed for each new connection.[5]

When clients (applications) connect to the MySQL server, the server needs to authenticate them.
Authentication is based on username, originating host, and password. X.509 certificates can also
be used across an SSL (Secure Sockets Layer) connection. Once a client has connected, the
server verifies whether the client has privileges for each query it issues (e.g., whether the client is
allowed to issue a SELECT statement that accesses the Country table in the worlddatabase).

Optimization and Execution

control arises. For our purposes in this chapter, MySQL has to do this at two levels: the server
level and the storage engine level. Concurrency control is a big topic to which a large body of
theoretical literature is devoted, so we will just give you a simplified overview of how MySQL
deals with concurrent readers and writers, so you have the context you need for the rest of this
chapter.

We’ll use an email box on a Unix system as an example. The classic mbox file format is very
simple. All the messages in an mbox mailbox are concatenated together, one after another. This
makes it very easy to read and parse mail messages. It also makes mail delivery easy: just append
a new message to the end of the file.

But what happens when two processes try to deliver messages at the same time to the same
mailbox? Clearly that could corrupt the mailbox, leaving two interleaved messages at the end of
the mailbox file. Well-behaved mail delivery systems use locking to prevent corruption. If a
client attempts a second delivery while the mailbox is locked, it must wait to acquire the lock
itself before delivering its message.

26
This scheme works reasonably well in practice, but it gives no support for concurrency. Because
only a single process can change the mailbox at any given time, this approach becomes
problematic with a high-volume mailbox.

Read/Write Locks

Reading from the mailbox isn’t as troublesome. There’s nothing wrong with multiple clients
reading the same mailbox simultaneously; because they aren’t making changes, nothing is likely
to go wrong. But what happens if someone tries to delete message number 25 while programs are
reading the mailbox? It depends, but a reader could come away with a corrupted or inconsistent
view of the mailbox. So, to be safe, even reading from a mailbox requires special care.

If you think of the mailbox as a database table and each mail message as a row, it’s easy to see
that the problem is the same in this context. In many ways, a mailbox is really just a simple
database table. Modifying rows in a database table is very similar to removing or changing the
content of messages in a mailbox file.

The solution to this classic problem of concurrency control is rather simple. Systems that deal
with concurrent read/write access typically implement a locking system that consists of two lock
types. These locks are usually known as shared locks and exclusive locks, or read locks and write
locks.

Without worrying about the actual locking technology, we can describe the concept as follows.
Read locks on a resource are shared, or mutually non blocking: many clients can read from a
resource at the same time and not interfere with each other. Write locks, on the other hand, are
exclusive—i.e., they block both read locks and other write locks—because the only safe policy is
to have a single client writing to the resource at a given time and to prevent all reads when a
client is writing.

In the database world, locking happens all the time: MySQL has to prevent one client from
reading a piece of data while another is changing it. It performs this lock management internally
in a way that is transparent much of the time.

27
Lock Granularity

One way to improve the concurrency of a shared resource is to be more selective about what you
lock. Rather than locking the entire resource, lock only the part that contains the data you need to
change. Better yet, lock only the exact piece of data you plan to change. Minimizing the amount
of data that you lock at any one time lets changes to a given resource occur simultaneously, as
long as they don’t conflict with each other.

The problem is locks consume resources. Every lock operation—getting a lock, checking to see
whether a lock is free, releasing a lock, and so on—has overhead. If the system spends too much
time managing locks instead of storing and retrieving data, performance can suffer.

A locking strategy is a compromise between lock overhead and data safety, and that compromise
affects performance. Most commercial database servers don’t give you much choice: you get
what is known as row-level locking in your tables, with a variety of often complex ways to give
good performance with many locks.

MySQL, on the other hand, does offer choices. Its storage engines can implement their own
locking policies and lock granularities. Lock management is a very important decision in storage
engine design; fixing the granularity at a certain level can give better performance for certain
uses, yet make that engine less suited for other purposes. Because MySQL offers multiple
storage engines, it doesn’t require a single general-purpose solution. Let’s have a look at the two
most important lock strategies.

in the storage engines, and as you’ll see later in this chapter and throughout the book, the storage
engines all implement locking in their own ways.

Networking

TCP is a connection-oriented protocol; UDP (User Datagram Protocol) is a connectionless

protocol.

IP datagram’s

The IP layer provides a connectionless and unreliable delivery system. It considers each
datagram independently of the others. Any association between datagram must be supplied by

28
the higher layers. The IP layer supplies a checksum that includes its own header. The header
includes the source and destination addresses. The IP layer handles routing through an Internet. It
is also responsible for breaking up large datagram into smaller ones for transmission and
reassembling them at the other end.

UDP

UDP is also connectionless and unreliable. What it adds to IP is a checksum for the contents
of the datagram and port numbers. These are used to give a client/server model - see later.

TCP

TCP supplies logic to give a reliable connection-oriented protocol above IP. It provides a
virtual circuit that two processes can use to communicate.

JFree Chart
JFreeChart is a free 100% Java chart library that makes it easy for developers to display
professional quality charts in their applications. JFreeChart's extensive feature set includes:

A consistent and well-documented API, supporting a wide range of chart types;

A flexible design that is easy to extend, and targets both server-side and client-side
applications;

Support for many output types, including Swing components, image files (including PNG
and JPEG), and vector graphics file formats (including PDF, EPS and SVG);

JFreeChart is "open source" or, more specifically, free software. It is distributed under the
terms of the GNU Lesser General Public Licence (LGPL), which permits use in proprietary
applications.

1. Map Visualizations

Charts showing values that relate to geographical areas. Some examples include: (a)
population density in each state of the United States, (b) income per capita for each country in
Europe, (c) life expectancy in each country of the world. The tasks in this project include:

Sourcing freely redistributable vector outlines for the countries of the world,
states/provinces in particular countries (USA in particular, but also other areas);

29
 Creating an appropriate dataset interface (plus default implementation), a rendered, and
integrating this with the existing XYPlot class in JFreeChart;

Testing, documenting, testing some more, documenting some more.

2. Time Series Chart Interactivity

Implement a new (to JFreeChart) feature for interactive time series charts --- to display a
separate control that shows a small version of ALL the time series data, with a sliding "view"
rectangle that allows you to select the subset of the time series data to display in the main chart.

3. Dashboards

There is currently a lot of interest in dashboard displays. Create a flexible dashboard mechanism
that supports a subset of JFreeChart chart types (dials, pies, thermometers, bars, and lines/time
series) that can be delivered easily via both Java Web Start and an applet.

4. Property Editors

The property editor mechanism in JFreeChart only handles a small subset of the
properties that can be set for charts. Extend (or reimplement) this mechanism to provide greater
end-user control over the appearance of the charts.

J2ME (Java 2 Micro edition)

Sun Microsystems defines J2ME as "a highly optimized Java run-time environment targeting a
wide range of consumer products, including pagers, cellular phones, screen-phones, digital set-
top boxes and car navigation systems." Announced in June 1999 at the JavaOne Developer
Conference, J2ME brings the cross-platform functionality of the Java language to smaller
devices, allowing mobile wireless devices to share applications. With J2ME, Sun has adapted the
Java platform for consumer products that incorporate or are based on small computing devices.

30
1. General J2ME architecture

Fig 5.2 J2ME Architecture

J2ME uses configurations and profiles to customize the Java Runtime Environment (JRE). As a
complete JRE, J2ME is comprised of a configuration, which determines the JVM used, and a
profile, which defines the application by adding domain-specific classes. The configuration
defines the basic run-time environment as a set of core classes and a specific JVM that run on
specific types of devices. We'll discuss configurations in detail in the The profile defines the
application; specifically, it adds domain-specific classes to the J2ME configuration to define
certain uses for devices. We'll cover profiles in depth in the The following graphic depicts the
relationship between the different virtual machines, configurations, and profiles. It also draws a
parallel with the J2SE API and its Java virtual machine. While the J2SE virtual machine is
generally referred to as a JVM, the J2ME virtual machines, KVM and CVM, are subsets of JVM.

31
Both KVM and CVM can be thought of as a kind of Java virtual machine -- it's just that they are
shrunken versions of the J2SE JVM and are specific to J2ME.

2.Developing J2ME applications

Introduction In this section, we will go over some considerations you need to keep in mind when
developing applications for smaller devices. We'll take a look at the way the compiler is invoked
when using J2SE to compile J2ME applications. Finally, we'll explore packaging and
deployment and the role preverification plays in this process.

3.Design considerations for small devices

Developing applications for small devices requires you to keep certain strategies in mind during
the design phase. It is best to strategically design an application for a small device before you
begin coding. Correcting the code because you failed to consider all of the "gotchas" before
developing the application can be a painful process. Here are some design strategies to consider:

* Keep it simple. Remove unnecessary features, possibly making those features a separate,
secondary application.

* Smaller is better. This consideration should be a "no brainer" for all developers. Smaller
applications use less memory on the device and require shorter installation times. Consider
packaging your Java applications as compressed Java Archive (jar) files.

* Minimize run-time memory use. To minimize the amount of memory used at run time, use
scalar types in place of object types. Also, do not depend on the garbage collector. You should
manage the memory efficiently yourself by setting object references to null when you are
finished with them. Another way to reduce run-time memory is to use lazy instantiation, only
allocating objects on an as-needed basis. Other ways of reducing overall and peak memory use
on small devices are to release resources quickly, reuse objects, and avoid exceptions.

4.Configurations overview

The configuration defines the basic run-time environment as a set of core classes and a specific
JVM that run on specific types of devices. Currently, two configurations exist for J2ME, though
others may be defined in the future:

32
* Connected Limited Device Configuration (CLDC) is used specifically with the KVM for
16-bit or 32-bit devices with limited amounts of memory. This is the configuration (and the
virtual machine) used for developing small J2ME applications. Its size limitations make CLDC
more interesting and challenging (from a development point of view) than CDC. CLDC is also
the configuration that we will use for developing our drawing tool application. An example of a
small wireless device running small applications is a Palm hand-held computer.

* Connected Device Configuration (CDC) is used with the C virtual machine (CVM) and is
used for 32-bit architectures requiring more than 2 MB of memory. An example of such a device
is a Net TV box.

5.J2ME profiles

What is a J2ME profile?

As we mentioned earlier in this tutorial, a profile defines the type of device supported. The
Mobile Information Device Profile (MIDP), for example, defines classes for cellular phones. It
adds domain-specific classes to the J2ME configuration to define uses for similar devices. Two
profiles have been defined for J2ME and are built upon CLDC: KJava and MIDP. Both KJava
and MIDP are associated with CLDC and smaller devices. Profiles are built on top of
configurations. Because profiles are specific to the size of the device (amount of memory) on
which an application runs, certain profiles are associated with certain configurations.

A skeleton profile upon which you can create your own profile, the Foundation Profile, is
available for CDC.

Profile 1: KJava

KJava is Sun's proprietary profile and contains the KJava API. The KJava profile is built on top
of the CLDC configuration. The KJava virtual machine, KVM, accepts the same byte codes and
class file format as the classic J2SE virtual machine. KJava contains a Sun-specific API that runs
on the Palm OS. The KJava API has a great deal in common with the J2SE Abstract Windowing
Toolkit (AWT). However, because it is not a standard J2ME package, its main package is
com.sun.kjava. We'll learn more about the KJava API later in this tutorial when we develop
some sample applications.

33
Profile 2: MIDP

MIDP is geared toward mobile devices such as cellular phones and pagers. The MIDP, like
KJava, is built upon CLDC and provides a standard run-time environment that allows new
applications and services to be deployed dynamically on end user devices. MIDP is a common,
industry-standard profile for mobile devices that is not dependent on a specific vendor. It is a
complete and supported foundation for mobile application

development. MIDP contains the following packages, the first three of which are core CLDC
packages, plus three MIDP-specific packages.

* java.lang

* java.io

* java.util

* javax.microedition.io

* javax.microedition.lcdui

* javax.microedition.midlet

* javax.microedition.rms

5.2 Sample Code

34
35
36
 7. SYSTEM TESTING

7.1 TESTING METHODOLOGIES

The following are the Testing Methodologies:

o Unit Testing.
o Integration Testing.
o User Acceptance Testing.
o Output Testing.
o Validation Testing.

7.1.1 Unit Testing

Unit testing focuses verification effort on the smallest unit of Software design that is the
module. Unit testing exercises specific paths in a module’s control structure to ensure complete
coverage and maximum error detection. This test focuses on each module individually, ensuring
that it functions properly as a unit. Hence, the naming is Unit Testing.

During this testing, each module is tested individually and the module interfaces are
verified for the consistency with design specification. All important processing path are tested
for the expected results. All error handling paths are also tested.

Integration Testing

Integration testing addresses the issues associated with the dual problems of verification
and program construction. After the software has been integrated a set of high order tests are
conducted. The main objective in this testing process is to take unit tested modules and builds a
program structure that has been dictated by design.

The following are the types of Integration Testing:

 Top Down Integration

This method is an incremental approach to the construction of program structure.

Modules are integrated by moving downward through the control hierarchy, beginning with the

37
main program module. The module subordinates to the main program module are incorporated
into the structure in either a depth first or breadth first manner.
In this method, the software is tested from main module and individual stubs are replaced
when the test proceeds downwards.

 Bottom-up Integration

This method begins the construction and testing with the modules at the lowest level in
the program structure. Since the modules are integrated from the bottom up, processing required
for modules subordinate to a given level is always available and the need for stubs is eliminated.
The bottom up integration strategy may be implemented with the following steps:
 The low-level modules are combined into clusters into clusters that perform a specific
Software sub-function.
 The cluster is tested.
 Drivers are removed and clusters are combined moving upward in the program structure
The bottom up approaches tests each module individually and then each module is module is
integrated with a main module and tested for functionality.

7.1.3 User Acceptance Testing

User Acceptance of a system is the key factor for the success of any system. The system
under consideration is tested for user acceptance by constantly keeping in touch with the
prospective system users at the time of developing and making changes wherever required. The
system developed provides a friendly user interface that can easily be understood even by a
person who is new to the system.

7.1.4 Output Testing

After performing the validation testing, the next step is output testing of the proposed
system, since no system could be useful if it does not produce the required output in the specified
format. Asking the users about the format required by them tests the outputs generated or
displayed by the system under consideration. Hence the output format is considered in 2 ways –
one is on screen and another in printed format.

7.1.5 Validation Checking

38
 Validation checks are performed on the following fields.

Text Field:

The text field can contain only the number of characters lesser than or equal to its size.
The text fields are alphanumeric in some tables and alphabetic in other tables. Incorrect entry
always flashes and error message.

Numeric Field:

The numeric field can contain only numbers from 0 to 9. An entry of any character
flashes an error messages. The individual modules are checked for accuracy and what it has to
perform. Each module is subjected to test run along with sample data. The individually tested
modules are integrated into a single system. Testing involves executing the real data
information is used in the program the existence of any program defect is inferred from the
output. The testing should be planned so that all the requirements are individually tested.

A successful test is one that gives out the defects for the inappropriate data and produces
and output revealing the errors in the system.

Preparation of Test Data

Taking various kinds of test data does the above testing. Preparation of test data plays a
vital role in the system testing. After preparing the test data the system under study is tested
using that test data. While testing the system by using test data errors are again uncovered and
corrected by using above testing steps and corrections are also noted for future use.

Using Live Test Data:

Live test data are those that are actually extracted from organization files. After a system
is partially constructed, programmers or analysts often ask users to key in a set of data from their
normal activities. Then, the systems person uses this data as a way to partially test the system. In
other instances, programmers or analysts extract a set of live data from the files and have them
entered themselves.

39
 It is difficult to obtain live data in sufficient amounts to conduct extensive testing. And,
although it is realistic data that will show how the system will perform for the typical processing
requirement, assuming that the live data entered are in fact typical, such data generally will not
test all combinations or formats that can enter the system. This bias toward typical values then
does not provide a true systems test and in fact ignores the cases most likely to cause system
failure.

Using Artificial Test Data:

Artificial test data are created solely for test purposes, since they can be generated to test
all combinations of formats and values. In other words, the artificial data, which can quickly be
prepared by a data generating utility program in the information systems department, make
possible the testing of all login and control paths through the program.

The most effective test programs use artificial test data generated by persons other than
those who wrote the programs. Often, an independent team of testers formulates a testing plan,
using the systems specifications.

The package “Virtual Private Network” has satisfied all the requirements specified as per
software requirement specification and was accepted.

7.2 USER TRAINING

Whenever a new system is developed, user training is required to educate them about the
working of the system so that it can be put to efficient use by those for whom the system has
been primarily designed. For this purpose the normal working of the project was demonstrated to
the prospective users. Its working is easily understandable and since the expected users are
people who have good knowledge of computers, the use of this system is very easy.

7.3 MAINTAINENCE

This covers a wide range of activities including correcting code and design errors. To
reduce the need for maintenance in the long run, we have more accurately defined the user’s
requirements during the process of system development. Depending on the requirements, this
system has been developed to satisfy the needs to the largest possible extent. With development

40
in technology, it may be possible to add many more features based on the requirements in future.
The coding and designing is simple and easy to understand which will make maintenance easier.

7.4 TESTING STRATEGY

A strategy for system testing integrates system test cases and design techniques into a
well planned series of steps that results in the successful construction of software. The testing
strategy must co-operate test planning, test case design, test execution, and the resultant data
collection and evaluation .A strategy for software testing must accommodate low-level tests
that are necessary to verify that a small source code segment has been correctly implemented
as well as high level tests that validate major system functions against user requirements.

Software testing is a critical element of software quality assurance and represents the
ultimate review of specification design and coding. Testing represents an interesting anomaly for
the software. Thus, a series of testing are performed for the proposed system before the
system is ready for user acceptance testing.

7.4.1 System Testing

Software once validated must be combined with other system elements (e.g. Hardware,
people, database). System testing verifies that all the elements are proper and that overall system
function performance is

achieved. It also tests to find discrepancies between the system and its original objective, current
specifications and system documentation.

7.4.2 Unit Testing

In unit testing different are modules are tested against the specifications produced during
the design for the modules. Unit testing is essential for verification of the code produced during
the coding phase, and hence the goals to test the internal logic of the modules. Using the
detailed design description as a guide, important Conrail paths are tested to uncover errors
within the boundary of the modules. This testing is carried out during the programming stage
itself. In this type of testing step, each module was found to be working satisfactorily as regards
to the expected output from the module.

41
 In Due Course, latest technology advancements will be taken into consideration. As
part of technical build-up many components of the networking system will be generic in nature
so that future projects can either use or interact with this. The future holds a lot to offer to the
development and refinement of this project.

42
 8. RESULTS
Screen Shots

Fig 8.1 Admin Login

43
Fig 8.2 User Registration

44
Fig 8.3 User login

45
Fig 8.4 User Posting

46
Fig 8.5 List of Posts

47
Fig 8.6 Search post by Keyword

48
Fig 8.7 Search post by Content

49
Fig 8.8 View Stranger or Mutual Friend or Friend Details

50
Fig 8.9 Different Image Permission Details

51
 9. CONCLUSION

Photo sharing is one of the most popular features in online social networks such as Facebook.
Unfortunately, careless photo posting may reveal privacy of individuals in a posted photo. To
curb the privacy leakage, we proposed to enable individuals potentially in a photo to give the
permissions before posting a co-photo. We designed a privacy-preserving FR system to identify
individuals in a co-photo. The proposed system is featured with low computation cost and
confidentiality of the training set. Theoretical analysis and experiments were conducted to show
effectiveness and efficiency of the proposed scheme. We expect that our proposed scheme be
very useful in protecting users’ privacy in photo/image sharing over online social networks.
However, there always exist trade-off between privacy and utility. For example, in our current
Android application, the co-photo could only be post with permission of all the co-owners.
Latency introduced in this process will greatly impact user experience of OSNs. More over, local
FR training will drain battery quickly. Our future work could be how to move the proposed
training schemes to personal clouds like Dropbox and/or icloud.

52
REFERENCES

[1] I. Altman. Privacy regulation: Culturally universal or culturally specific? Journal of Social
Issues, 33(3):66–84, 1977.
[2] A. Besmer and H. Richter Lipford. Moving beyond untagging: photo privacy in a tagged
world. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems,
CHI ’10, pages 1563–1572, New York, NY, USA, 2010. ACM.
[3] S. Boyd, N. Parikh, E. Chu, B. Peleato, and J. Eckstein. Distributed optimization and
statistical learning via the alternating direction method of multipliers. Found. Trends Mach.
Learn., 3(1):1–122, Jan. 2011.
[4] B. Carminati, E. Ferrari, and A. Perego. Rule-based access control for social networks. In R.
Meersman, Z. Tari, and P. Herrero, editors, On the Move to Meaningful Internet Systems 2006:
OTM 2006 Workshops, volume 4278 of Lecture Notes in Computer Science, pages 1734–1744.
Springer Berlin Heidelberg, 2006.
[5] J. Y. Choi, W. De Neve, K. Plataniotis, and Y.-M. Ro. Collaborative face recognition for
improved face annotation in personal photo collections shared on online social networks.
Multimedia, IEEE Transactions on, 13(1):14–28, 2011.
[6] K. Choi, H. Byun, and K.-A. Toh. A collaborative face recognition framework on a social
network platform. In Automatic Face Gesture Recognition, 2008. FG ’08. 8th IEEE International
Conference on, pages 1–6, 2008.
[7] K.-B. Duan and S. S. Keerthi. Which is the best multiclass svm method? an empirical study.
In Proceedings of the 6th international conference on Multiple Classifier Systems, MCS’05,
pages 278–285, Berlin, Heidelberg, 2005. Springer-Verlag.
[8] P. A. Forero, A. Cano, and G. B. Giannakis. Consensus-based distributed support vector
machines. J. Mach. Learn. Res., 99:1663– 1707, August 2010.
[9] B. Goethals, S. Laur, H. Lipmaa, and T. Mielik?inen. On private scalar product computation
for privacy-preserving data mining. In In Proceedings of the 7th Annual International
Conference in Information Security and Cryptology, pages 104–120. Springer-Verlag, 2004.
[10] L. Kissner and D. Song. Privacy-preserving set operations. In IN ADVANCES IN
CRYPTOLOGY - CRYPTO 2005, LNCS, pages 241–257. Springer, 2005.

53
[11] L. Kissner and D. X. Song. Privacy-preserving set operations. In V. Shoup, editor,
CRYPTO, volume 3621 of Lecture Notes in Computer Science, pages 241–257. Springer, 2005.
[12] N. Mavridis, W. Kazmi, and P. Toulis. Friends with faces: How social networks can
enhance face recognition and vice versa. In Computational Social Network Analysis, Computer
Communications and Networks, pages 453–482. Springer London, 2010.
[13] R. J. Michael Hart and A. Stent. More content - less control: Access control in the web 2.0.
In Proceedings of the Workshop on Web 2.0 Security and Privacy at the IEEE Symposium on
Security and Privacy, 2007.
[14] M. E. Newman. The structure and function of complex networks. SIAM review, 45(2):167–
256, 2003.
[15] L. Palen. Unpacking privacy for a networked world. pages 129– 136. Press, 2003.

54