At the very basis of networking lies the idea of sending, exchanging and sharing data of different type. To name just a few applications, consider the following:

• online banking: gives access to personal bank accounts, allows placing money transfer orders, credit card management and more;
• web-based customer relation: (company's website) provides information about a company, presents its profile, advertizes its products, contact information etc.; one example could be booking a room in a hotel, an other - online registration for an event, or buying train tickets;
• online file storage: (like Dropbox, GoogleDrive) allows users to send their files to servers in the internet and access them from anywhere by providing login/password information; often also allows sharing the files among more users;
• data centres: sites that let users store their data and perform complex computation on them (see for example Worldwide LHC Computing Grid -- WLCG) often span over more than one physical location, comprize of a large number of computers connected in a compuational grid.

Examples can be multiplied, and you as an experienced user of the Internet can easily name at least a few. Do it now.

A very general view of "interaction with the Internet" is depicted in this figure:

Fig.4.2.1/1

Again, since the picture (Fig. 4.2.1/1) is very a simplistic one, there is a lot of space for interpretation. In an online banking scenario, "client 1" could be someone who entered a fake password into bank's website ("some data..."), while "client 2" entered a correct password (solid arrow) and received information about his/her latest spendings (dotted arrow). In the online file storage scenario, "client 2" published some jpegs ("some other data...") and "client 3" accessed them.

Naturally, the picture lacks quite a few details to give a full picture:

• arrows represent just unitary actions (like access, enter password), but in fact there is a lot of data being transferred multiple times per action; in fact, even if there is only one arrow (like the one from "client 1"), there is in fact quite a lot of information going both ways before the user at "client 1" can interact with "some data";
• there is a time consequence of actions (and thus - arrows) - one cannot download an image which hasn't been shared yet by anyone;
• what we named "internet'' is not, in fact, a blob where "some data" and "some other data" reside, it is a network of interconnected devices who exchange information themselves to provide content to clients;
• there are other "clients" who participate in actions depicted by arrows in that they are physically present in the ... "internet", as much as "client 1, 2 and 3" are.

With all that in mind, we should rewrite the picture as follows:

Fig. 4.2.1/2

We have added some more details.

• The numbered empty headed arrows representing link negotiation between clients and servers storing data. This always happens in the realm of TCP/IP network stack, which we will describe later. See what happens with "client 3". Arrows 1-3 represent the negotiation, which is finalized by data (eg., the website HTTP content) sent from "server B" (arrow 4.).
• "client 2" acts similarly, but there is a distinct "data transfer" arrow 2. This is to show that "server A" sends its credentials (a piece of information testifying that it is the server that "client 2" thinks it is). Apparently, the credentials are valid and hence further link establishment continues (arrows 3,4), followed by user data transfer to the server (an online-banking access password maybe).
• "client 1" performs similar link establishment, but its communication is eavesdropped by "client X", meaning that the latter can see what is being sent between client and the server.
• Servers "A" and "B" exchange some information, which is represented by double-headed arrow between them. It can be that "A" acts on behalf of "client 2" and executes some code or extracts information from "B". Near the end of our course we will introduce schemes, where servers interoperate with one another in order to provide service (a file, website, calculations, ...) to an external user.
• The data transfer arrow marked with '!!!' shows another scenario. We omitted here the TCP/IP link negotiation for brevity, but it must be there anyway. What is important is the following two opposite cases:
  1. "client 2" must be sure that it talks to "server A" (because it sends its online-banking password there). But what if "server B" tricked it into believing that it is "server A" and forced "client 1" to give it the password?
  2. What if information that is stored on "server B" can normally be provided only via "server A" (remember the double-headed arrow) is taken directly from "server B"? Say, this is mortgage information collected by a bank and kept in accordance with personal data protection act -- only the owner can access it by logging into a service (served by "server A").

As you see, the more details come into view, the more obvious it becomes that it is not so easy to "get things from Internet". So far, the following problems were identified:

• how to make sure that the parties on both ends of the communication link are really what they claim to be, or what the other side thinks they are?
• how to secure communication of sensitive data from being overheard by other, not involved parties?
• how to organize that one server can act on behalf of some user on other server?

As a derivative of the first bullet above, let's state one more problem:

• how do we assure that data sent by the servers is really what it should be?

Naturally, if we are concerned that servers (physical entities, after all) can mimick their identities, we should even more be concerned about authenticity of data, which has much more untangible nature.