diff --git a/1-js/08-prototypes/04-prototype-methods/article.md b/1-js/08-prototypes/04-prototype-methods/article.md
index b1e65a66..82a751f9 100644
--- a/1-js/08-prototypes/04-prototype-methods/article.md
+++ b/1-js/08-prototypes/04-prototype-methods/article.md
@@ -111,7 +111,7 @@ Here the consequences are not terrible. But in other cases the prototype may ind
 
 What's worst -- usually developers do not think about such possibility at all. That makes such bugs hard to notice and even turn them into vulnerabilities, especially when JavaScript is used on server-side.
 
-Such thing happens only with `__proto__`. All other properties are "assignable" normally.
+Unexpected things also may happen when accessing `toString` property -- that's a function by default, and other built-in properties.
 
 How to evade the problem?
 
diff --git a/1-js/plan3.txt b/1-js/plan3.txt
index 4d553174..cb954bd3 100644
--- a/1-js/plan3.txt
+++ b/1-js/plan3.txt
@@ -1,5 +1,9 @@
 todo:
 
-intl?
-proxy?
-eval?
+localstorage
+fetch
+indexdb
+
+addEventLitener options once passive
+
+security? xsrf xss csp etc?
diff --git a/2-ui/5-data-storage/01-cookie/article.md b/2-ui/5-data-storage/01-cookie/article.md
index 56d80eae..ae14d0c2 100644
--- a/2-ui/5-data-storage/01-cookie/article.md
+++ b/2-ui/5-data-storage/01-cookie/article.md
@@ -1,18 +1,19 @@
 # Cookies, document.cookie
 
-Cookies allow to store small pieces of data directly in the browser. They are not part of Javascript, but rather part of HTTP, defined by [RFC 6265](https://tools.ietf.org/html/rfc6265) specification.
+Cookies are small strings of data that are stored directly in the browser. They are not a part of Javascript, but rather a part of HTTP protocol, defined by [RFC 6265](https://tools.ietf.org/html/rfc6265) specification.
 
-Most of the time, cookies are set by a webserver, but Javascript can access them too.
+Most of the time, cookies are set by a web server.
 
 One of the most widespread use of cookies is authentication:
 
-1. Upon sign in, the server sets `Set-Cookie` HTTP-header with a cookie with "session id".
-2. The browser stores it.
-3. The browser sends it over the net in `Cookie` HTTP-header for every request to the domain that set it. So the server knows who made the request.
+1. Upon sign in, the server uses `Set-Cookie` HTTP-header in a response to set a cookie with "session identifier".
+2. The browser stores the cookie.
+3. Next time when the request is set to the same domain, the browser sends the over the net using `Cookie` HTTP-header.
+4. So the server knows who made the request.
 
 The browser provides a special accessor `document.cookie` for cookies.
 
-There are many tricky things about cookies and their options, how to set them right. In this chapter we'll cover them in detail.
+There are many tricky things about cookies and their options. In this chapter we'll cover them in detail.
 
 ## Reading from document.cookie
 
@@ -26,48 +27,55 @@ Assuming you're on a website, it's possible to see the cookies, like this:
 
 ```js run
 // At javascript.info, we use Google Analytics for statistics,
-// so there should be some cookies from there.
+// so there should be some cookies
 alert( document.cookie ); // cookie1=value1; cookie2=value2;...
 ```
 
 
-The string consist of `name=value` pairs, delimited by `; `. So, to find a particular cookie, we can split `document.cookie` by `; `, and then find the right key. We can use either a regular expression or array functions to do that. At the end of the chapter you'll find a few functions to manipulate cookies.
+The string consist of `name=value` pairs, delimited by `; `. Each one is a separate cookie.
+
+To find a particular cookie, we can split `document.cookie` by `; `, and then find the right name. We can use either a regular expression or array functions to do that.
+
+To make things simple, at the end of the chapter you'll find a few functions to manipulate cookies.
 
 ## Writing to document.cookie
 
-The `document.cookie` is writable. But it's not a data property, but rather an accessor.
+We can write to `document.cookie`. But it's not a data property, it's an accessor.
 
 **A write operation to `document.cookie` passes through the browser that updates cookies mentioned in it, but doesn't touch other cookies.**
 
 For instance, this call sets a cookie with the name `user` and value `John`:
 
 ```js run
-document.cookie = "user=John";
-alert(document.cookie);
+document.cookie = "user=John"; // update only cookie named 'user'
+alert(document.cookie); // show all cookies
 ```
 
-If you run it, then probably you'll see multiple cookies. Only the cookie named `user` was altered.
+If you run it, then probably you'll see multiple cookies. That's because `document.cookie=` operation does not overwrite all cookies, but only `user`.
 
-Technically, name and value can have any characters, but then they should be escaped using a built-in `encodeURIComponent` function:
+Technically, name and value can have any characters, but to keep the formatting valid they should be escaped using a built-in `encodeURIComponent` function:
 
 ```js run
+// special values, need encoding
 let name = "<>";
 let value = "="
+
 // encodes the cookie as %3C%3E=%3D
 document.cookie = encodeURIComponent(name) + '=' + encodeURIComponent(value);
+
 alert(document.cookie); // ...; %3C%3E=%3D
 ```
 
 
 ```warn header="Limitations"
 There are few limitations:
-- The `name=value` pair together (after `encodeURIComponent`) should not exceed 4kb. So we can't store anything huge in a cookie.
-- The total number of cookies per domain is limited to 30-50, depending on a browser.
+- The `name=value` pair, after `encodeURIComponent`, should not exceed 4kb. So we can't store anything huge in a cookie.
+- The total number of cookies per domain is limited to 20+, depending on a browser.
 ```
 
 Cookies have several options, many of them are important and should be set.
 
-The options are listed after `key=value`, delimited by `;`, for instance:
+The options are listed after `key=value`, delimited by `;`, like this:
 
 ```js run
 document.cookie = "user=John; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT"
@@ -77,23 +85,21 @@ document.cookie = "user=John; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT"
 
 - **`path=/mypath`**
 
-The url path prefix, where the cookie is accessible. By default, it's the current path.
+The url path prefix, where the cookie is accessible. Must be absolute. By default, it's the current path.
 
-If a cookie is set with `path=/mypath`, it's visible at `/mypath` and `/mypath/page`, but not at `/page` or `/mypathpage`.
+If a cookie is set with `path=/mypath`, it's visible at `/mypath` and `/mypath/*`, but not at `/page` or `/mypathpage`.
 
 Usually, we set `path=/` to make the cookie accessible from all website pages.
 
-Please note: the path must be absolute (start with `/`).
-
 ## domain
 
 - **`domain=site.com`**
 
 Domain where the cookie is accessible.
 
-By default, cookie is accessible only at the domain that set it. So, if we set a cookie at `site.com`, we won't get it `other.com`. That's natural, as `other.com` is another site.
+By default, a cookie is accessible only at the domain that set it. So, if the cookie was set by `site.com`, we won't get it `other.com`.
 
-What's more tricky, we won't get it at a subdomain `forum.site.com`:
+...But what's more tricky, we also won't get the cookie at a subdomain `forum.site.com`:
 
 ```js
 // at site.com
@@ -107,7 +113,7 @@ alert(document.cookie); // no user
 
 It's a safety restriction, to allow us to store sensitive data in cookies.
 
-For subdomains like `forum.site.com` that's possible. If we'd like a subdomain to access the cookie, we should set the `domain` to it. Or, much more common that we'd like any subdomain `*.site.com` to access the cookie, then we should set `domain=site.com`:
+...But if we'd like to grant access to subdomains like `forum.site.com`, that's possible. We  should explicitly set `domain` option to the root domain: `domain=site.com`:
 
 ```js
 // at site.com, make the cookie accessible on any subdomain:
@@ -117,7 +123,7 @@ document.cookie = "user=John; domain=site.com"
 alert(document.cookie); // with user
 ```
 
-For historical reasons, `domain=.site.com` (a dot at the start) also works this way.
+For historical reasons, `domain=.site.com` (a dot at the start) also works this way, it might better to add the dot to support very old browsers.
 
 ## expires, max-age
 
@@ -138,7 +144,7 @@ date = date.toUTCString();
 document.cookie = "user=John; expires=" + date;
 ```
 
-If the date is in the past, the cookie will be deleted from the browser.
+If we set `expires` to the past, the cookie will be deleted.
 
 -  **`max-age=3600`**
 
@@ -164,7 +170,7 @@ The cookie should be transferred only over HTTPS.
 
 That is, cookies only check the domain, they do not distinguish between the protocols.
 
-With this option, if a cookie is set while `https://site.com`, then it doesn't appear when the same site is accessed by HTTP, as `http://site.com`. So if a cookie has sensitive content that should never be sent over unencrypted HTTP, then the flag can prevent this.
+With this option, if a cookie is set by `https://site.com`, then it doesn't appear when the same site is accessed by HTTP, as `http://site.com`. So if a cookie has sensitive content that should never be sent over unencrypted HTTP, then the flag can prevent this.
 
 ```js
 // set the cookie secure (only accessible if over HTTPS)
@@ -181,19 +187,19 @@ To understand when it's useful, let's introduce the following attack scenario.
 
 Imagine, you are logged into the site `bank.com`. That is: you have an authentication cookie from that site. Your browser sends it to `bank.com` on every request, so that it recognizes you and performs all sensitive financial operations.
 
-Now, while browsing the web in another window, you occasionally come to another site `evil.com`, that has a `<form action="https://bank.com/pay">` with hacker's account and JavaScript code that sends it automatically.
+Now, while browsing the web in another window, you occasionally come to another site `evil.com`, that has a `<form action="https://bank.com/pay">` with hacker's account and JavaScript code that submits it automatically.
 
-The form is submitted to the bank site, and your cookie is also sent, just because it's sent every time you visit `bank.com`. So the bank recognizes you and actually performs the payment.
+The form is submitted from `evil.com` directly to the bank site, and your cookie is also sent, just because it's sent every time you visit `bank.com`. So the bank recognizes you and actually performs the payment.
 
 ![](cookie-xsrf.png)
 
 That's called a cross-site request forgery (or XSRF) attack.
 
-Real banks are protected from it of course. All forms generated by `bank.com` have a special field, so called "xsrf protection token", that the evil page can't generate.
+Real banks are protected from it of course. All forms generated by `bank.com` have a special field, so called "xsrf protection token", that an evil page can't neither generate, nor somehow extract from a remote page (it can submit a form there, but can't get the data back).
 
 ### Enter cookie samesite option
 
-Now, cookie samesite option provides another way to protect from such attacks, that (in theory) should not require "xsrf protection tokens".
+Now, cookie `samesite` option provides another way to protect from such attacks, that (in theory) should not require "xsrf protection tokens".
 
 It has two possible values:
 
@@ -201,9 +207,9 @@ It has two possible values:
 
 A cookie with `samesite=strict` is never sent if the user comes from outside the site.
 
-In other words, whether a user follows a link from the mail or submits a form from `evil.com`, for any operation that comes from another domain, the cookie is not sent. Then the XSRF attack will fail, as `bank.com` will not recognize the user without the cookie, and will not proceed with the payment.
+In other words, whether a user follows a link from the mail or submits a form from `evil.com`, or does any operation with the site that originates from another domain, the cookie is not sent. Then the XSRF attack will fail, as `bank.com` will not recognize the user without the cookie, and will not proceed with the payment.
 
-The protection is quite reliable. Only operations originating from `bank.com` will send cookies.
+The protection is quite reliable. Only operations that come from `bank.com` will send the samesite cookie.
 
 Although, there's a small inconvenience.
 
@@ -226,7 +232,7 @@ A `samesite=lax` cookie is sent if both of these conditions are true:
 
 2. The operation performs top-level navigation (changes URL in the browser address bar).
 
-    That's usually true, but if the navigation is performed in an `<iframe>`, then it's not top-level. Also, AJAX requests do not get in.
+    That's usually true, but if the navigation is performed in an `<iframe>`, then it's not top-level. Also, AJAX requests do not perform any navigation, hence they don't fit.
 
 So, what `samesite=lax` does is basically allows a most common "open URL" operation to bring cookies. Something more complicated, like AJAX request from another site or a form submittion loses cookies.
 
@@ -250,69 +256,10 @@ This option forbids any JavaScript access to the cookie. We can't see such cooki
 That's used as a precaution measure, to protect from certain attacks when a hacker injects his own Javascript code into a page and waits for a user to visit that page. That shouldn't be possible at all, a hacker should not be able to inject their code into our site, but there may be bugs that let hackers do it.
 
 
-Normally, if such thing happens, then s hacker's code would execute and gain access to `document.cookie` with user cookies, containing authentication information.
+Normally, if such thing happens, and a user visits a web-page with hacker's code, then that code executes and gains access to `document.cookie` with user cookies containing authentication information. That's bad.
 
 But if a cookie is `httpOnly`, then `document.cookie` doesn't see it, so it is protected.
 
-## Appendix: Third-party cookies
-
-A cookie is called "third-party" if it's placed by domain other than the user is visiting.
-
-For instance:
-1. A page at `site.com` loads an banner from another site: `<img src="https://ads.com/banner.png">`.
-2. Along with the banner, the remote server at `ads.com` may set `Set-Cookie` header with cookie like `id=1234`. Such cookie originates from `ads.com` domain, and will only be visible at `ads.com`:
-
-    ![](cookie-third-party.png)
-
-3. Next time when `ads.com` is accessed, the remote server gets the `id` cookie and recognizes the user:
-
-    ![](cookie-third-party-2.png)
-
-4. What's even more important, when the users moves from `site.com` to another site `other.com` that also has a banners, then `ads.com` gets the cookie, as it belongs to `ads.com`, thus recognizing the visitor and tracking him as he moves between sites:
-
-    ![](cookie-third-party-3.png)
-
-
-Third-party cookies are traditionally used for tracking and ads services, due to their nature. They are bound to the originating domain, so `ads.com` can track the same user between different sites, if they all access it.
-
-Naturally, some people don't like being tracked, so browsers allow to disable such cookies.
-
-Also, some modern browsers employ special policies for such cookies:
-- Safari does not allow third-party cookies at all.
-- Firefox comes with a "black list" of third-party domains where it blocks third-party cookies.
-
-
-```smart
-If we load a script from a third-party domain, like `<script src="https://google-analytics.com/analytics.js">`, and that script uses `document.cookie` to set a cookie, then such cookie is not third-party.
-
-If a script sets a cookie, then no matter where the script came from -- ito belongs to the domain of the current webpage.
-```
-
-## Appendix: GDPR
-
-This topic is not related to JavaScript at all, just something to keep in mind when setting cookies.
-
-There's a legislation in Europe called GDPR, that enforces a set of rules for websites to respect users' privacy. And one of such rules is to require an explicit permission for tracking cookies from a user.
-
-Please note, that's only about tracking/identifying cookies.
-
-So, if we set a cookie that just saves some information, but neither tracks nor identifies the user, then we are free to do it.
-
-But if we are going to set a cookie with an authentication session or a tracking id, then a user must allow that.
-
-Websites generally have two variants of following GDPR. You must have seen them both already in the web:
-
-1. If a website wants to set tracking cookies only for authenticated users.
-
-    To do so, the registration form should have a checkbox like "accept the privacy policy", the user must check it, and then the website is free to set auth cookies.
-
-2. If a website wants to set tracking cookies for everyone.
-
-    To do so legally, a website shows a modal "splash screen" for newcomers, and require them to agree for cookies. Then the website can set them. That can be disturbing for a new visitor though.
-
-
-GDPR is not only about cookies, but about other privacy-related issues too, but that's too much beyond our scope.
-
 ## Appendix: Cookie functions
 
 Here's a small set of functions to work with cookies, more conveinent than a manual modification of `document.cookie`.
@@ -393,7 +340,83 @@ function deleteCookie(name) {
 Please note: when we update or delete a cookie, we should use exactly the same path and domain options as when we set it.
 ```
 
+Together: [cookie.js](cookie.js).
+
+
+## Appendix: Third-party cookies
+
+A cookie is called "third-party" if it's placed by domain other than the user is visiting.
+
+For instance:
+1. A page at `site.com` loads an banner from another site: `<img src="https://ads.com/banner.png">`.
+2. Along with the banner, the remote server at `ads.com` may set `Set-Cookie` header with cookie like `id=1234`. Such cookie originates from `ads.com` domain, and will only be visible at `ads.com`:
+
+    ![](cookie-third-party.png)
+
+3. Next time when `ads.com` is accessed, the remote server gets the `id` cookie and recognizes the user:
+
+    ![](cookie-third-party-2.png)
+
+4. What's even more important, when the users moves from `site.com` to another site `other.com` that also has a banners, then `ads.com` gets the cookie, as it belongs to `ads.com`, thus recognizing the visitor and tracking him as he moves between sites:
+
+    ![](cookie-third-party-3.png)
+
+
+Third-party cookies are traditionally used for tracking and ads services, due to their nature. They are bound to the originating domain, so `ads.com` can track the same user between different sites, if they all access it.
+
+Naturally, some people don't like being tracked, so browsers allow to disable such cookies.
+
+Also, some modern browsers employ special policies for such cookies:
+- Safari does not allow third-party cookies at all.
+- Firefox comes with a "black list" of third-party domains where it blocks third-party cookies.
+
+
+```smart
+If we load a script from a third-party domain, like `<script src="https://google-analytics.com/analytics.js">`, and that script uses `document.cookie` to set a cookie, then such cookie is not third-party.
+
+If a script sets a cookie, then no matter where the script came from -- ito belongs to the domain of the current webpage.
+```
+
+## Appendix: GDPR
+
+This topic is not related to JavaScript at all, just something to keep in mind when setting cookies.
+
+There's a legislation in Europe called GDPR, that enforces a set of rules for websites to respect users' privacy. And one of such rules is to require an explicit permission for tracking cookies from a user.
+
+Please note, that's only about tracking/identifying cookies.
+
+So, if we set a cookie that just saves some information, but neither tracks nor identifies the user, then we are free to do it.
+
+But if we are going to set a cookie with an authentication session or a tracking id, then a user must allow that.
+
+Websites generally have two variants of following GDPR. You must have seen them both already in the web:
+
+1. If a website wants to set tracking cookies only for authenticated users.
+
+    To do so, the registration form should have a checkbox like "accept the privacy policy", the user must check it, and then the website is free to set auth cookies.
+
+2. If a website wants to set tracking cookies for everyone.
+
+    To do so legally, a website shows a modal "splash screen" for newcomers, and require them to agree for cookies. Then the website can set them and let people see the content. That can be disturbing for new visitors though. No one likes to see "must-click" modal splash screens instead of the content. But GDPR requires an explicit agreement.
+
+
+GDPR is not only about cookies, it's about other privacy-related issues too, but that's too much beyond our scope.
+
 
 ## Summary
 
-[TODO]
+`document.cookie` provides access to cookies
+- write operations modify only cookies mentioned in it.
+- name/value must be encoded.
+- one cookie up to 4kb, 20+ cookies per site (depends on a browser).
+
+Cookie options:
+- `path=/`, by default current path, makes the cookie visible only under that path.
+- `domain=site.com`, by default a cookie is visible on current domain only, if set explicitly to the domain, makes the cookie visible on subdomains.
+- `expires/max-age` set cookie expiration time, without them the cookie dies when the browser is closed.
+- `secure` makes the cookie HTTPS-only.
+- `samesite` forbids browser to send the cookie with requests coming from outside the site, helps to prevent XSRF attacks.
+
+Additionally:
+- Third-party cookies may be forbidden by the browser, e.g. Safari does that by default.
+- When setting a tracking cookie for EU citizens, GDPR requires to ask for permission.
diff --git a/2-ui/5-data-storage/01-cookie/cookie.js b/2-ui/5-data-storage/01-cookie/cookie.js
index ddb5fbfe..7d8eebf3 100644
--- a/2-ui/5-data-storage/01-cookie/cookie.js
+++ b/2-ui/5-data-storage/01-cookie/cookie.js
@@ -1,45 +1,38 @@
-// возвращает cookie с именем name, если есть, если нет, то undefined
 function getCookie(name) {
-  var matches = document.cookie.match(new RegExp(
+  let matches = document.cookie.match(new RegExp(
     "(?:^|; )" + name.replace(/([\.$?*|{}\(\)\[\]\\\/\+^])/g, '\\$1') + "=([^;]*)"
   ));
   return matches ? decodeURIComponent(matches[1]) : undefined;
 }
 
-// устанавливает cookie с именем name и значением value
-// options - объект с свойствами cookie (expires, path, domain, secure)
-function setCookie(name, value, options) {
-  options = options || {};
+function setCookie(name, value, options = {}) {
 
-  var expires = options.expires;
+  options = {
+    path: '/',
+    // add other defaults here if necessary
+    ...options
+  };
 
-  if (typeof expires == "number" && expires) {
-    var d = new Date();
-    d.setTime(d.getTime() + expires * 1000);
-    expires = options.expires = d;
-  }
-  if (expires && expires.toUTCString) {
-    options.expires = expires.toUTCString();
+  if (options.expires.toUTCString) {
+    options.expires = options.expires.toUTCString();
   }
 
-  value = encodeURIComponent(value);
+  let updatedCookie = encodeURIComponent(name) + "=" + encodeURIComponent(value);
 
-  var updatedCookie = name + "=" + value;
-
-  for (var propName in options) {
-    updatedCookie += "; " + propName;
-    var propValue = options[propName];
-    if (propValue !== true) {
-      updatedCookie += "=" + propValue;
+  for (let optionKey in options) {
+    updatedCookie += "; " + optionKey;
+    let optionValue = options[optionKey];
+    if (optionValue !== true) {
+      updatedCookie += "=" + optionValue;
     }
   }
 
   document.cookie = updatedCookie;
 }
 
-// удаляет cookie с именем name
+
 function deleteCookie(name) {
   setCookie(name, "", {
-    expires: -1
+    'max-age': -1
   })
-}
\ No newline at end of file
+}
diff --git a/2-ui/5-data-storage/02-localstorage/1-form-autosave/solution.md b/2-ui/5-data-storage/02-localstorage/1-form-autosave/solution.md
new file mode 100644
index 00000000..8b137891
--- /dev/null
+++ b/2-ui/5-data-storage/02-localstorage/1-form-autosave/solution.md
@@ -0,0 +1 @@
+
diff --git a/2-ui/5-data-storage/02-localstorage/1-form-autosave/solution.view/index.html b/2-ui/5-data-storage/02-localstorage/1-form-autosave/solution.view/index.html
new file mode 100644
index 00000000..7be19892
--- /dev/null
+++ b/2-ui/5-data-storage/02-localstorage/1-form-autosave/solution.view/index.html
@@ -0,0 +1,10 @@
+<!doctype html>
+<textarea style="width:200px; height: 60px;" id="area" placeholder="Write here"></textarea>
+<br>
+<button onclick="localStorage.removeItem('area');area.value=''">Clear</button>
+<script>
+    area.value = localStorage.getItem('area');
+    area.oninput = () => {
+      localStorage.setItem('area', area.value)
+    };
+</script>
diff --git a/2-ui/5-data-storage/02-localstorage/1-form-autosave/source.view/index.html b/2-ui/5-data-storage/02-localstorage/1-form-autosave/source.view/index.html
new file mode 100644
index 00000000..95a74175
--- /dev/null
+++ b/2-ui/5-data-storage/02-localstorage/1-form-autosave/source.view/index.html
@@ -0,0 +1,2 @@
+<!doctype html>
+<textarea style="width:200px; height: 60px;" id="area"></textarea>
diff --git a/2-ui/5-data-storage/02-localstorage/1-form-autosave/task.md b/2-ui/5-data-storage/02-localstorage/1-form-autosave/task.md
new file mode 100644
index 00000000..b2e0a422
--- /dev/null
+++ b/2-ui/5-data-storage/02-localstorage/1-form-autosave/task.md
@@ -0,0 +1,10 @@
+
+# Autosave a form field
+
+Create a `textarea` field that "autosaves" its value on every change.
+
+So, if the user occasionally closes the page, and opens it again, he'll find his unfinished input at place.
+
+Like this:
+
+[iframe src="solution" height=120]
diff --git a/2-ui/5-data-storage/02-localstorage/article.md b/2-ui/5-data-storage/02-localstorage/article.md
index 2f52453d..41a895b0 100644
--- a/2-ui/5-data-storage/02-localstorage/article.md
+++ b/2-ui/5-data-storage/02-localstorage/article.md
@@ -1,381 +1,247 @@
-# Cookies, document.cookie
+# LocalStorage, sessionStorage
 
-Cookies allow to store small pieces of data directly in the browser. They are not part of Javascript, but rather part of HTTP, defined by [RFC 6265](https://tools.ietf.org/html/rfc6265) specification.
+Web storage objects `localStorage` and `sessionStorage` allow to save key/value pairs in the browser.
 
-We can use Javascript or server-side headers to get/set cookies.
+What's interesting about them is that the data survives a page refresh (for `sessionStorage`) and even a full browser restart (for `localStorage`). We'll see that very soon.
 
-Then the browser sends them in `Cookie` header of every request to the domain that set the cookie, but not to other domains.
+We already have cookies. Why additional objects?
 
-So, cookies are mainly used for authorization and user-tracking. We set a cookie, and then get it at new visits of the same user, so we know who he is.
+- Unlike cookies, web storage objects are not sent to server with each request. Because of that, we can store much more. Most browsers allow at least 2 megabytes of data (or more) and have settings to configure that.
+- The server can't manipulate storage objects via HTTP headers, everything's done in JavaScript.
+- The storage is bound to the origin (domain/protocol/port triplet). That is, different protocols or subdomains infer different storage objects, they can't access data from each other.
 
-The browser provides a special accessor `document.cookie` for that. Managing it manually is quite a tedious task, so we'll compose a few several functions for that.
+Both storage objects provide same methods and properties:
 
-## Reading from document.cookie
+- `setItem(key, value)` -- store key/value pair.
+- `getItem(key)` -- get the value by key.
+- `removeItem(key)` -- remove the key with its value.
+- `clear()` -- delete everything.
+- `key(index)` -- get the key on a given position.
+- `length` -- the number of stored items.
 
-```online
-Do you have any cookies on that site? Let's see:
-```
+Let's see how it works.
 
-```offline
-Assuming you're on a website, it's possible to see the cookies, like this:
-```
+## localStorage demo
+
+The main features of `localStorage` are:
+
+- Shared between all tabs and windows from the same origin.
+- The data does not expire. It remains after the browser restart and even OS reboot.
+
+For instance, if you run this code...
 
 ```js run
-alert( document.cookie ); // cookie1=value1; cookie2=value2;...
+localStorage.setItem('test', 1);
 ```
 
-The string consist of `name=value` pairs, delimited by `; `. So, to find a particular cookie, we can split `document.cookie` by `; `, and then find the right key. We can use either a regular expression or arrays for that.
-
-## getCookie(name)
-
-The shortest way to access cookie is to use a [regular expression](info:regular-expressions).
-
-The function `getCookie(name)` returns the cookie with the given `name`:
-
-```js
-// returns the cookie with the given name,
-// or undefined if not found
-function getCookie(name) {
-  let matches = document.cookie.match(new RegExp(
-    "(?:^|; )" + name.replace(/([\.$?*|{}\(\)\[\]\\\/\+^])/g, '\\$1') + "=([^;]*)"
-  ));
-  return matches ? decodeURIComponent(matches[1]) : undefined;
-}
-```
-
-Here the regexp is generated dynamically, to match `; name=<value>`.
-
-Please note that a cookie value can be an arbitrary string. If it contains characters that break the formatting, for instance spaces or `;`, such characters are encoded.
-
-To decode them, we need to use a built-in `decodeURIComponent` function, the function does it also.
-
-## Writing to document.cookie
-
-The `document.cookie` is writable. But it's not a data property, but rather an accessor.
-
-**A write operation to `document.cookie` passes through the browser that updates cookies mentioned in it, but doesn't touch other cookies.**
-
-For instance, this call sets a cookie with the name `user` and value `John`:
+...And close/open the browser or just open the same page in a different window, then you can get it like this:
 
 ```js run
-document.cookie = "user=John";
-alert(document.cookie);
+alert( localStorage.getItem('test') ); // 1
 ```
 
-If you run it, then probably you'll see multiple cookies. Only the cookie named `user` was altered.
+We only have to be on the same domain/port/protocol, the url path can be different.
 
-Cookies have several options, many of them are important and should be set.
+The `localStorage` is shared, so if we set the data in one window, the change becomes visible in the other one.
 
-The options are listed after `key=value`, delimited by `;`, for instance:
+## Object-like access
+
+We can also use a plain object way of getting/setting keys, like this:
 
 ```js run
-document.cookie = "user=John; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT"
+// set key
+localStorage.test = 2;
+
+// get key
+alert( localStorage.test ); // 2
+
+// remove key
+delete localStorage.test;
 ```
 
-## path
-
-- **`path=/mypath`**
-
-The url path prefix, where the cookie is accessible. By default, it's the current path.
-
-Usually, we should set `path=/` to make the cookie accessible from all website pages.
-
-Please note: the path must be absolute.
-
-## domain
-
-- **`domain=site.com`**
-
-Domain where the cookie is accessible.
-
-By default, cookie is accessible only at the domain that set it. So, if we set a cookie at `site.com`, we won't get it at `forum.site.com`.
-
-```js
-// at site.com
-document.cookie = "user=John"
-
-// at forum.site.com
-alert(document.cookie); // no user
-```
-
-If we'd like subdomains to access the cookie, we should set `domain=site.com` explicitly. For historical reasons, `domain=.site.com` (a dot at the start) also works this way:
-
-```js
-// at site.com
-document.cookie = "user=John; domain=site.com"
-
-// at forum.site.com
-alert(document.cookie); // with user
-```
-
-## expires, max-age
-
-By default, a cookie disappears when the browser is closed. They are called "session cookies"
-
-To change it, we must set either `expires` or `max-age` option.
-
-- **`expires=Tue, 19 Jan 2038 03:14:07 GMT`**
-
-Cookie expiration date (when it dies automatically).
-
-The date must be exactly in this format, in GMT timezone. We can use `date.toUTCString` to get it. For instance, we can set the cookie to expire in 1 day:
-
-```js
-// +1 day from now
-let date = new Date(Date.now() + 86400e3);
-date = date.toUTCString();
-document.cookie = "user=John; expires=" + date;
-```
-
-If the date is in the past, the cookie will be deleted from the browser.
-
--  **`max-age=3600`**
-
-An alternative to `expires`, specifies the cookie expiration in seconds.
-
-Can be either a number of seconds from the current moment, or `0` for immediate expiration (to remove the cookie):
-
-```js
-// cookie will die +1 hour from now
-document.cookie = "user=John; max-age=3600";
-
-// delete cookie (let it expiree right now)
-document.cookie = "user=John; max-age=0";
-```  
-
-## secure
-
-- **`secure`**
-
-The cookie should be transferred only over HTTPS.
-
-That's important, by default if we set a cookie at `http://site.com`, then it also appears at `https://site.com` and vise versa.
-
-With this option, if a cookie is set at `https://site.com`, the browser does not set it to `http://site.com`. So if a cookie has sensitive content, like authorization, then it's more secure.
-
-```js
-// set the cookie secure (only sent with HTTPS requests)
-document.cookie = "user=John; secure";
-```  
-
-## samesite
-
-That's another security option, to protect from so-called XSRF (cross-site request forgery) attacks.
-
-To understand when it's useful, let's introduce the following attack scenario.
-
-### XSRF attack
-
-Imagine, you are logged into the site `bank.com`. That is: you have an authentication cookie from that site. Your browser sends it to `bank.com` on every request, so that it recognizes you and performs all sensitive financial operations.
-
-Now, while browsing the web in another window, you occasionally come to another site `evil.com`, that has a `<form action="https://bank.com/pay">` with parameters containing hacker's account and JavaScript code that sends it automatically.
-
-The form is submitted to the bank site, and your cookie is also sent, just because it's sent every time you visit `bank.com`. So that the bank actually performs the payment.
-
-![](cookie-xsrf.png)
-
-That's called a cross-site request forgery (or XSRF) attack.
-
-Real banks are protected from it of course. All forms generated by `bank.com` have a special field, so called "xsrf protection token", that the evil page can't generate.
-
-### Enter cookie samesite option
-
-Now, cookie samesite option provides another way to protect from such attacks, that does not require "xsrf protection tokens".
-
-It has two possible values:
-
-- **`samesite=strict`, same as `samesite` without value**
-
-A cookie with `samesite=strict` is never sent if the user comes from outside the site.
-
-In other words, whether a user follows a link from the mail or submits a form from `evil.com`, the cookie is not sent. Then `bank.com` will not recognize the user, and will not proceed with the payment.
-
-The protection is indeed reliable. Only operations originating from `bank.com` will send cookies. Although, it may be a little too strict.
-
-When a user follows a legitimate link to `bank.com`, like from their own notes, they'll be surprised that `bank.com` does not recognize them. Indeed, `samesite=strict` cookies are nots sent in that case.
-
-So there's another, more relaxed value.
-
-- **`samesite=lax`**
-
-Lax mode, just like `strict`, forbids the browser to send cookies when coming from outside the site, but adds an exception.
-
-A `samesite=lax` cookie is sent if both of these conditions are true:
-1. The HTTP method is "safe" (e.g. GET, but not POST).
-
-    The full list safe of HTTP methods is in the [RFC7231 specification](https://tools.ietf.org/html/rfc7231). Basically, these are the methods that should be used for reading, but not writing the data. They must not perform any data-changing operations. Following a link is always GET, the safe method.
-
-2. The operation performs top-level navigation (changes URL in the browser address bar).
-
-    That's usually true, but if the navigation is performed in an `<iframe>`, then it's not top-level. Also, AJAX requests do not get in.
-
-So, what `samesite=lax` does is basically allows a most common "open URL" operation to bring cookies. Something more complicated, like AJAX request from another site or a form submittion, passes through, but loses cookies by the way.
-
-If that's fine for you, then adding `samesite=lax` will probably not break the user experience and add protection.
-
-Overall, `samesite` is great, but it has an important drawback:
-- `samesite` is not supported, ignored by old browsers (like year 2017).
-
-So if we solely rely on `samesite` to provide protection, then old browsers will be totally vulnerable.
-
-But we surely can use `samesite` together with other protection measures, like xsrf tokens, to add an additional layer of protection.
-
-## setCookie(name, value, options)
-
-If we gather all options together, here's a small function that sets the cookie `name` to the given `value` with reasonable default options:
-Если собрать все настройки воедино, вот такая функция ставит куки:
-
-```js
-function setCookie(name, value, options = {}) {
-
-  options = {
-    path: '/',
-    // add other defaults here if necessary
-    ...options
-  };
-
-  if (options.expires.toUTCString) {
-    options.expires = options.expires.toUTCString();
-  }
-
-  options.value = encodeURIComponent(options.value);
-
-  let updatedCookie = encodeURIComponent(name) + "=" + encodeURIComponent(value);
-
-  for (let optionKey in options) {
-    updatedCookie += "; " + optionKey;
-    let optionValue = options[optionKey];
-    if (optionValue !== true) {
-      updatedCookie += "=" + optionValue;
-    }
-  }
-
-  document.cookie = updatedCookie;
-}
-```
-
-Аргументы:
-
-name
-: название cookie
-
-value
-: значение cookie (строка)
-
-options
-: Объект с дополнительными свойствами для установки cookie:
-
-expires
-: Время истечения cookie. Интерпретируется по-разному, в зависимости от типа:
-
-    - Число -- количество секунд до истечения. Например, `expires: 3600` -- кука на час.
-    - Объект типа [Date](https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Date) -- дата истечения.
-    - Если expires в прошлом, то cookie будет удалено.
-    - Если expires отсутствует или `0`, то cookie будет установлено как сессионное и исчезнет при закрытии браузера.
-
-path
-: Путь для cookie.
-
-domain
-: Домен для cookie.
-
-secure
-: Если `true`, то пересылать cookie только по защищенному соединению.
-
-
-## Функция deleteCookie(name)
-
-Здесь всё просто -- удаляем вызовом `setCookie` с датой в прошлом.
-
-```js
-function deleteCookie(name) {
-  setCookie(name, "", {
-    expires: -1
-  })
-}
-```
-
-## Сторонние cookie
-
-При работе с cookie есть важная тонкость, которая касается внешних ресурсов.
-
-Теоретически, любой ресурс, который загружает браузер, может поставить cookie.
-
-Например:
-
-- Если на странице есть `<img src="http://mail.ru/counter.gif">`, то вместе с картинкой в ответ сервер может прислать заголовки, устанавливающие cookie.
-- Если на странице есть `<iframe src="http://facebook.com/button.php">`, то во-первых сервер может вместе с `button.php` прислать cookie, а во-вторых JS-код внутри ифрейма может записать в `document.cookie`
-
-При этом cookie будут принадлежать тому домену, который их поставил. То есть, на `mail.ru` для первого случая, и на `facebook.com` во втором.
-
-**Такие cookie, которые не принадлежат основной странице, называются "сторонними" (3rd party) cookies. Не все браузеры их разрешают.**
-
-Как правило, в настройках браузера можно поставить "Блокировать данные и файлы cookie сторонних сайтов" (Chrome).
-
-**В Safari такая настройка включена по умолчанию и выглядит так:**
-
-![](safari-nocookie.png)
-
-### Тс-с-с. Большой брат смотрит за тобой.
-
-Цель этого запрета -- защитить посетителей от слежки со стороны рекламодателей, которые вместе с картинкой-баннером присылают и куки, таким образом помечая посетителей.
-
-Например, на многих сайтах стоят баннеры и другая реклама Google Ads. При помощи таких cookie компания Google будет знать, какие именно сайты вы посещаете, сколько времени вы на них проводите и многое другое.
-
-Как? Да очень просто -- на каждом сайте загружается, к примеру, картинка с рекламой. При этом баннер берётся с домена, принадлежащего Google. Вместе с баннером Google ставит cookie со специальным уникальным идентификатором.
-
-Далее, при следующем запросе на баннер, браузер пошлёт стандартные заголовки, которые включают в себя:
-
-- Cookie с домена баннера, то есть уникальный идентификатор, который был поставлен ранее.
-- Стандартный заголовок Referrer (его не будет при HTTPS!), который говорит, с какого сайта сделан запрос. Да, впрочем, Google и так знает, с какого сайта запрос, ведь идентификатор сайта есть в URL.
-
-Так что Google может хранить в своей базе, какие именно сайты из тех, на которых есть баннер Google, вы посещали, когда вы на них были, и т.п. Этот идентификатор легко привязывается к остальной информации от других сервисов, и таким образом картина слежки получается довольно-таки глобальной.
-
-Здесь я не утверждаю, что в конкретной компании Google всё именно так... Но во-первых, сделать так легко, во-вторых идентификаторы действительно ставятся, а в-третьих, такие знания о человеке позволяют решать, какую именно рекламу и когда ему показать. А это основная доля доходов Google, благодаря которой корпорация существует.
-
-Возможно, компания Apple, которая выпустила Safari, поставила такой флаг по умолчанию именно для уменьшения влияния Google?
-
-### А если очень надо?
-
-Итак, Safari запрещает сторонние cookie по умолчанию. Другие браузеры предоставляют такую возможность, если посетитель захочет.
-
-**А что, если ну очень надо поставить стороннюю cookie, и чтобы это было надёжно?**
-
-Такая задача действительно возникает, например, в системе кросс-доменной авторизации, когда есть несколько доменов 2-го уровня, и хочется, чтобы посетитель, который входит в один сайт, автоматически распознавался во всей сетке. При этом cookie для авторизации ставятся на главный домен -- "мастер", а остальные сайты запрашивают их при помощи специального скрипта (и, как правило, копируют к себе для оптимизации, но здесь это не суть).
-
-Ещё пример -- когда есть внешний виджет, например, `iframe` с информационным сервисом, который можно подключать на разные сайты. И этот `iframe` должен знать что-то о посетителе, опять же, авторизация или какие-то настройки, которые хорошо бы хранить в cookie.
-
-Есть несколько способов поставить 3rd-party cookie для Safari.
-
-Использовать ифрейм.
-: Ифрейм является полноценным окном браузера. В нём должна быть доступна вся функциональность, в том числе cookie. Как браузер решает, что ифрейм "сторонний" и нужно запретить для него и его скриптов установку cookie? Критерий таков: "в ифрейме нет навигации". Если навигация есть, то ифрейм признаётся полноценным окном.
-
-    Например, в сторонний `iframe` можно сделать POST. И тогда, в ответ на POST, сервер может поставить cookie. Или прислать документ, который это делает. Ифрейм, в который прошёл POST, считается родным и надёжным.
-
-Popup-окно
-: Другой вариант -- использовать popup, то есть при помощи `window.open` открывать именно окно со стороннего домена, и уже там ставить cookie. Это тоже работает.
-
-Редирект
-: Ещё одно альтернативное решение, которое подходит не везде - это сделать интеграцию со сторонним доменом, такую что на него можно сделать редирект, он ставит cookie и делает редирект обратно.
-
-## Дополнительно
-
-- На Cookie наложены ограничения:
-    - Имя и значение (после `encodeURIComponent`) вместе не должны превышать 4кб.
-    - Общее количество cookie на домен ограничено 30-50, в зависимости от браузера.
-    - Разные домены 2-го уровня полностью изолированы. Но в пределах доменов 3-го уровня куки можно ставить свободно с указанием `domain`.
-    - Сервер может поставить cookie с дополнительным флагом `HttpOnly`. Cookie с таким параметром передаётся только в заголовках, оно никак не доступно из JavaScript.
-
-- Иногда посетители отключают cookie. Отловить это можно проверкой свойства [navigator.cookieEnabled](https://developer.mozilla.org/en-US/docs/DOM/window.navigator.cookieEnabled)
+That's allowed for historical reasons, and mostly works, but generally not recommended for two reasons:
 
+1. If the key is user-generated, it can be anything, like `length` or `toString`, or another built-in method of `localStorage`. In that case `getItem/setItem` work fine, while object-like access fails:
     ```js run
-    if (!navigator.cookieEnabled) {
-      alert( 'Включите cookie для комфортной работы с этим сайтом' );
-    }
+    let key = 'length';
+    localStorage[key] = 5; // Error, can't assign length
     ```
 
-    ...Конечно, предполагается, что включён JavaScript. Впрочем, посетитель без JS и cookie с большой вероятностью не человек, а бот.
+2. There's a `storage` event, it triggers when we modify the data. That event does not happen for object-like access. We'll see that later in this chapter.
 
-## Итого
+## Looping over keys
 
-Файл с функциями для работы с cookie: [cookie.js](cookie.js).
+Methods provide get/set/remove functionality. But how to get all the keys?
+
+Unfortunately, storage objects are not iterable.
+
+One way is to use "array-like" iteration:
+
+```js run
+for(let i=0; i<localStorage.length; i++) {
+  let key = localStorage.key(i);
+  alert(`${key}: ${localStorage.getItem(key)}`);
+}
+```
+
+Another way is to use object-specific `for key in localStorage` loop.
+
+That iterates over keys, but also outputs few built-in fields that we don't need:
+
+```js run
+// bad try
+for(let key in localStorage) {
+  alert(key); // shows getItem, setItem and other built-in stuff
+}
+```
+
+...So we need either to filter fields from the prototype with `hasOwnProperty` check:
+
+```js run
+for(let key in localStorage) {
+  if (!localStorage.hasOwnProperty(key)) {
+    continue; // skip keys like "setItem", "getItem" etc
+  }
+  alert(`${key}: ${localStorage.getItem(key)}`);
+}
+```
+
+...Or just get the "own" keys with `Object.keys` and then loop over them if needed:
+
+```js run
+let keys = Object.keys(localStorage);
+for(let key of keys) {
+  alert(`${key}: ${localStorage.getItem(key)}`);
+}
+```
+
+The latter works, because `Object.keys` only returns the keys that belong to the object, ignoring the prototype.
+
+
+## Strings only
+
+Please note that both key and value must be strings.
+
+If we any other type, like a number, or an object, it gets converted to string automatically:
+
+```js run
+sessionStorage.user = {name: "John"};
+alert(sessionStorage.user); // [object Object]
+```
+
+We can use `JSON` to store objects though:
+
+```js run
+sessionStorage.user = JSON.stringify({name: "John"});
+
+// sometime later
+let user = JSON.parse( sessionStorage.user );
+alert( user.name ); // John
+```
+
+Also it is possible to stringify the whole storage object, e.g. for debugging purposes:
+
+```js run
+// added formatting options to JSON.stringify to make the object look nicer
+alert( JSON.stringify(localStorage, null, 2) );
+```
+
+
+## sessionStorage
+
+The `sessionStorage` object is used much less often than `localStorage`.
+
+Properties and methods are the same, but it's much more limited:
+
+- The `sessionStorage` exists only within the current browser tab.
+  - Another tab with the same page will have a different storage.
+  - But it is shared between iframes in the tab (assuming they come from the same origin).
+- The data survives page refresh, but not closing/opening the tab.
+
+Let's see that in action.
+
+Run this code...
+
+```js run
+sessionStorage.setItem('test', 1);
+```
+
+...Then refresh the page. Now you can still get the data:
+
+```js run
+alert( sessionStorage.getItem('test') ); // after refresh: 1
+```
+
+...But if you open the same page in another tab, and try again there, the code above returns `null`, meaning "nothing found".
+
+That's exactly because `sessionStorage` is bound not only to the origin, but also to the browser tab. For that reason, `sessionStorage` is used sparingly.
+
+## Storage event
+
+When the data gets updated in `localStorage` or `sessionStorage`, [storage](https://www.w3.org/TR/webstorage/#the-storage-event) event triggers, with properties:
+
+- `key` – the key that was changed (null if `.clear()` is called).
+- `oldValue` – the old value (`null` if the key is newly added).
+- `newValue` – the new value (`null` if the key is removed).
+- `url` – the url of the document where the update happened.
+- `storageArea` – either `localStorage` or `sessionStorage` object where the update happened.
+
+The important thing is: the event triggers on all `window` objects where the storage is accessible, except the one that caused it.
+
+Let's elaborate.
+
+Imagine, you have two windows with the same site in each. So `localStorage` is shared between them.
+
+```online
+You might want to open this page in two browser windows to test the code below.
+```
+
+Now if both windows are listening for `window.onstorage`, then each one will react on updates that happened in the other one.
+
+```js run
+// triggers on updates made to the same storage from other documents
+window.onstorage = event => {
+  if (event.key != 'now') return;
+  alert(event.key + ':' + event.newValue + " at " + event.url);
+};
+
+localStorage.setItem('now', Date.now());
+```
+
+Please note that the event also contains: `event.url` -- the url of the document where the data was updated.
+
+Also, `event.storageArea` contains the storage object -- the event is the same for both `sessionStorage` and `localStorage`, so `storageArea` references the one that was modified. We may event want to set something back in it, to "respond" to a change.
+
+**That allows different windows from the same origin to exchange messages.**
+
+Modern browsers also support [Broadcast channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API), the special API for same-origin inter-window communication, it's more full featured, but less supported. There are libraries that polyfill that API, based on `localStorage`, that make it available everywhere.
+
+## Summary
+
+Web storage objects `localStorage` and `sessionStorage` allow to store key/value in the browser.
+- Both `key` and `value` must be strings.
+- The limit is 2mb+, depends on the browser.
+- They do not expire.
+- The data is bound to the origin (domain/port/protocol).
+
+| `localStorage` | `sessionStorage` |
+|----------------|------------------|
+| Shared between all tabs and windows with the same origin | Visible within a browser tab, including iframes from the same origin |
+| Survives browser restart | Dies on tab close |
+
+API:
+
+- `setItem(key, value)` -- store key/value pair.
+- `getItem(key)` -- get the value by key.
+- `removeItem(key)` -- remove the key with its value.
+- `clear()` -- delete everything.
+- `key(index)` -- get the key on a given position.
+- `length` -- the number of stored items.
+- Use `Object.keys` to get all keys.
+- Can use the keys as object properties, in that case `storage` event doesn't trigger.
+
+Storage event:
+
+- Triggers on `setItem`, `removeItem`, `clear` calls.
+- Contains all the data about the operation, the document `url` and the storage object.
+- Triggers on all `window` objects that have access to the storage except the one that generated it (within a tab for `sessionStorage`, globally for `localStorage`).
diff --git a/2-ui/5-data-storage/02-localstorage/cookie-xsrf.png b/2-ui/5-data-storage/02-localstorage/cookie-xsrf.png
deleted file mode 100644
index 75c5d01e..00000000
Binary files a/2-ui/5-data-storage/02-localstorage/cookie-xsrf.png and /dev/null differ
diff --git a/2-ui/5-data-storage/02-localstorage/cookie-xsrf@2x.png b/2-ui/5-data-storage/02-localstorage/cookie-xsrf@2x.png
deleted file mode 100644
index e6c8ef76..00000000
Binary files a/2-ui/5-data-storage/02-localstorage/cookie-xsrf@2x.png and /dev/null differ
diff --git a/2-ui/5-data-storage/02-localstorage/cookie.js b/2-ui/5-data-storage/02-localstorage/cookie.js
deleted file mode 100644
index ddb5fbfe..00000000
--- a/2-ui/5-data-storage/02-localstorage/cookie.js
+++ /dev/null
@@ -1,45 +0,0 @@
-// возвращает cookie с именем name, если есть, если нет, то undefined
-function getCookie(name) {
-  var matches = document.cookie.match(new RegExp(
-    "(?:^|; )" + name.replace(/([\.$?*|{}\(\)\[\]\\\/\+^])/g, '\\$1') + "=([^;]*)"
-  ));
-  return matches ? decodeURIComponent(matches[1]) : undefined;
-}
-
-// устанавливает cookie с именем name и значением value
-// options - объект с свойствами cookie (expires, path, domain, secure)
-function setCookie(name, value, options) {
-  options = options || {};
-
-  var expires = options.expires;
-
-  if (typeof expires == "number" && expires) {
-    var d = new Date();
-    d.setTime(d.getTime() + expires * 1000);
-    expires = options.expires = d;
-  }
-  if (expires && expires.toUTCString) {
-    options.expires = expires.toUTCString();
-  }
-
-  value = encodeURIComponent(value);
-
-  var updatedCookie = name + "=" + value;
-
-  for (var propName in options) {
-    updatedCookie += "; " + propName;
-    var propValue = options[propName];
-    if (propValue !== true) {
-      updatedCookie += "=" + propValue;
-    }
-  }
-
-  document.cookie = updatedCookie;
-}
-
-// удаляет cookie с именем name
-function deleteCookie(name) {
-  setCookie(name, "", {
-    expires: -1
-  })
-}
\ No newline at end of file
diff --git a/2-ui/5-data-storage/02-localstorage/safari-nocookie.png b/2-ui/5-data-storage/02-localstorage/safari-nocookie.png
deleted file mode 100644
index 1a4fb868..00000000
Binary files a/2-ui/5-data-storage/02-localstorage/safari-nocookie.png and /dev/null differ
diff --git a/2-ui/5-data-storage/02-localstorage/safari-nocookie@2x.png b/2-ui/5-data-storage/02-localstorage/safari-nocookie@2x.png
deleted file mode 100644
index 6c3f9d82..00000000
Binary files a/2-ui/5-data-storage/02-localstorage/safari-nocookie@2x.png and /dev/null differ
diff --git a/2-ui/5-data-storage/02-localstorage/sessionstorage.view/iframe.html b/2-ui/5-data-storage/02-localstorage/sessionstorage.view/iframe.html
new file mode 100644
index 00000000..2555160b
--- /dev/null
+++ b/2-ui/5-data-storage/02-localstorage/sessionstorage.view/iframe.html
@@ -0,0 +1,9 @@
+<!doctype html>
+<script>
+  window.addEventListener('storage', event => {
+    alert("iframe.html: onstorage");
+  });
+</script>
+<button onclick="sessionStorage.setItem('now', new Date())">sessionStorage.setItem</button>
+</body>
+</html>
diff --git a/2-ui/5-data-storage/02-localstorage/sessionstorage.view/index.html b/2-ui/5-data-storage/02-localstorage/sessionstorage.view/index.html
new file mode 100644
index 00000000..110143e5
--- /dev/null
+++ b/2-ui/5-data-storage/02-localstorage/sessionstorage.view/index.html
@@ -0,0 +1,10 @@
+<!doctype html>
+<script>
+  window.addEventListener('storage', event => {
+    alert("index.html: onstorage");
+  });
+</script>
+<button onclick="sessionStorage.setItem('now', new Date())">sessionStorage.setItem</button>
+<iframe src="iframe.html" style="height:100px"></iframe>
+</body>
+</html>