Background

Web development is all about communication. In this case, communication between two (2) parties, over the HTTP protocol:

• The Server - This party is responsible for serving pages.
• The Client - This party requests pages from the Server, and displays them to the user. In most cases, the client is a web browser.
  • The User - The user uses the Client in order to surf the web, fill in forms, watch videos online, etc.

Each side's programming, refers to code which runs at the specific machine, the server's or the client's.

Basic Example

1. The User opens his web browser (the Client).
2. The User browses to http://google.com.
3. The Client (on the behalf of the User), sends a request to http://google.com (the Server), for their home page.
4. The Server then acknowledges the request, and replies the client with some meta-data (called headers), followed by the page's source.
5. The Client then receives the page's source, and renders it into a human viewable website.
6. The User types Stack Overflow into the search bar, and presses Enter
7. The Client submits that data to the Server.
8. The Server processes that data, and replies with a page matching the search results.
9. The Client, once again, renders that page for the User to view.

Programming

Server-side Programming

Server-side programming, is the general name for the kinds of programs which are run on the Server.

Uses

• Process user input.
• Compiles pages.
• Structure web applications.
• Interact with permanent storage (SQL, files).

Example Languages

• PHP
• Python
• ASP.Net in C#, C++, or Visual Basic.
• Nearly any language (C++, C#, Java). These were not designed specifically for the task, but are now often used for application-level web services.

Client-side programming

Much like the server-side, Client-side programming is the name for all of the programs which are run on the Client.

Uses

• Make interactive webpages.
• Make stuff happen dynamically on the web page.
• Interact with temporary storage, and local storage (Cookies, localStorage).
• Send requests to the server, and retrieve data from it.
• Provide a remote service for client-side applications, such as software registration, content delivery, or remote multi-player gaming.

Example languages

• JavaScript (primarily)
• HTML*
• CSS*
• Any language running on a client device that interacts with a remote service is a client-side language.

_{*HTML and CSS aren't really "programming languages" per-se. They are markup syntax by which the Client renders the page for the User.}

I have worked in the past on medical applications running on portable devices that need to communicate with a central server, but need to also work when no network connection is present.

The first thing to do is to do a proper security analysis. What are the risks to data, and how are you managing to protect the data against those risks. e.g.

1. Sensitive data transfer of TCP network to the server.
2. Storage of sensitive data on the device
3. Identification of user on the device
4. Identification of device to the server
5. access to sensitive data on the device by an identified user.

What is appropriate will vary with the nature of the sensitive data, and the product involved, but to give you a guide, here were the answers for that medical product...

1. Data over the network was encrypted by AES-256, and where ever possible we used a private APN network which connected to the server data centre via a private leased line.

2. On the device we stored sensitive medical information encrypted by AES-256 but without any patient identifiers. Encryption key was device specific so data files could not be accessed by copying data to a different device.

3. Access to the software one the device was controlled by a 3 digit pin number. This was probably the weakest aspect, as patients then typically chose simple pins (e.g. 123 or 147)

4. Each device identified itself with a client certificate to the server, and then had to supply additional hardware provided identifiers to the server to validate the device matched the servers expectations. Only the server knew the identity of the patient that used that device, and server identification was all about confirming whether the device was authorised to connect to the server, and which device it was.

5. In our case, having access to past historic measurements was important to the patients, so patients could view their historic measurements if the device had successfully authenticated with the server in the past 24 hours, and its last successful socket connection had resulted in the device being authenticated.