I've realized that this will be a good opportunity to test the privacy issues of WebRTC and to find out who is this despicable person.

As you probably already know - WebRTC has this flaw/feature which allows a website to reveal your local IP address. Check it out.

So I made up this quick website with some new-year resolutions images I found on the first page result in Google. Used one of my best domain name with valid HTTPS. Waited till that horrible person will send a "funny" message which is intended directly at me and replied: "LoL that was soooo funny, checkout this website with the funniest new year resolutions". Now, if you'll go to this website (now with different domain) it'll send me an email titled "The fish is in the net" with your local IP address.

That doesn't mean much for you, but for that person it means I'll know who he is.

Everything was setup perfectly, I set down and waited for that email. Yet... nothing happened there was no click. That was a bummer but I didn't give up. As in all successful physhing attacks - it's important who the message is coming from. So I made up a new message with a new link and asked someone with more prestige in the company, AKA a manager, to send it. And it worked!!!

I now had the precious local IP.

Getting the hostname from this IP is easy using nmap --system-dns <ip> or nslookup <ip> on Windows. Since it's a big company the hostname is some kind of generated serial which doesn't give much information. Luckily searching the Active Directory is too damn easy.

Busted!!!

So we found him... that despicible person... finally... actually he's a nice dude ;)

The website is still here https://localip.herokuapp.com/ Code is here https://github.com/guy-a/localip

I made a simple node.js script that scraps the page using x-ray and download the videos using ffmpeg.

X-ray is a powerful and easy to use web-scrapper for node.js. FFMPEG is the swiss army knife for everything video.

Here x-ray is used to get all the videos for a certain subject (every page holds videos of 1 subject)

xray(link, '.itemContainer.itemContainerLast h3 > a',
        [{
            file: '',
            src: '@href'
        }]
    )

Than I use the Node's child-process to spawn the ffmpeg with the right params. Mainly the video source url and the name to save it with: var cmd = 'ffmpeg -i {url} -acodec copy -vcodec copy "{file}"';

I'm sure anyone will enjoy these security videos ;) But, this script can also serve as an example for leeching other types of streaming videos.

Script is in here: https://github.com/guy-a/cyberweek2016

Syncing with the server these days is much easier with libraries like socket.io and alike. But, even though there is no need to mess with insane black magic like Comet or Flash-Remoting... - Sometimes all you need is just a simple polling.

In this example we'll see how to implement recursive polling to poll the server for updates. The example is in AngularJS 1.5.x ES5 but the approach is valid for any framework and/or plain javascript.

The key to recursive-polling, and what make it different from just polling, is that we wait for the response before we initiate the next interval. This means that even if we poll the server very fast and the server is slow to response we avoid issues like race-condition and overloading the server.

[Live demo](http://plnkr.co/edit/Io7xt2?p=preview" target="_blank)

var app = angular.module('plunker', ['ngAnimate']);

app.controller('MainCtrl', function($scope, $http, $timeout) {

  var loadTime = 1000, //Load the data every second
    errorCount = 0, //Counter for the server errors
    loadPromise; //Pointer to the promise created by the Angular $timout service

  var getData = function() {
    $http.get('http://httpbin.org/delay/1?now=' + Date.now())

    .then(function(res) {
      $scope.data = res.data.args;

      errorCount = 0;
      nextLoad();
    })

    .catch(function(res) {
      $scope.data = 'Server error';
      nextLoad(++errorCount * 2 * loadTime);
    });
  };

  var cancelNextLoad = function() {
    $timeout.cancel(loadPromise);
  };

  var nextLoad = function(mill) {
    mill = mill || loadTime;
    
    //Always make sure the last timeout is cleared before starting a new one
    cancelNextLoad();
    loadPromise = $timeout(getData, mill);
  };


  //Start polling the data from the server
  getData();


  //Always clear the timeout when the view is destroyed, otherwise it will keep polling and leak memory
  $scope.$on('$destroy', function() {
    cancelNextLoad();
  });

  $scope.data = 'Loading...';
});

In the example we load some dummy data from [http://httpbin.org](http://httpbin.org" target="blank). We try to load it every 1000 milliseconds (1 second) but the server takes more than a second to respond. Using recursive polling saves us from some issues in this case.

When the server has an error (line 19) we generally wouldn't want to just stop the polling all together. It might be a just a temporary hiccup. We increase the timeout to the next load based on the count of response errors. nextLoad(++errorCount * 2 * loadTime); So if the server issues are more serious we won't be hammering it. Eventually when it's fixed we'll go back to normal polling. errorCount = 0;

You can put this mechanism into a centralized service but always control it from the controllers. Start polling when the view is initialized and stop when the view is destroyed.

$scope.$on('$destroy', function() {
    cancelNextLoad();
  });

This way every view will be polling the server when it needs to and only then.

Browsers doesn’t handle webcam permissions well enough. Users should be extremely wary about what’s going on in their browser. From a list of 30 bugs submitted to google regarding that issue, most have been fixed, but some are still alive.
The most obvious bug which is still live and kicking in all of the browsers is PopJacking which is  – clickjacking using popups. This flaw can be abused to trick users into allowing malicious access to their webcam, for example.

Video of the 5 POCs is here

Full text

More than a year ago (6.6.2014) I submitted a list of ~30 security bugs regarding the way Chrome handle WebCam access . These bugs were also regarding the way Chrome handled almost all other kind of special permissions. From webcam/mic access to location.

Some of these were related to bugs and bad implementation of popups and abusing it in relation to webcam access.

Yesterday Google made my bug report public so I figured it’s about time I’d share my findings (all of these links and info were private until now):

This is the original post I privately sent to Google, it has the info

A video with 5 different POCs

The POC and source code

The bug thread on google

While Google fixed most of these bugs some of these are still unfixed. But, even these who were fixed are not fixed good enough and are still vulnerable to PopJacking. Meaning, an attacker can still trick a user to allow webcam access – pretty easily.
PopJacking is merely clickjacking using a popup – probably the most overlooked flaw in browsers since clickjacking.

Another side note here is about Google behaviour regarding this bug:
At first they seemed thrilled about it, but than it took them almost a year to fix most of it. Only to eventually declare it as “Wontfix”.
One of the bug I submitted was opened as a different private bug  but, anyone can easily figure which one it is from the conversation in the currently opened bug thread.

From the way Google dealt with this bug and some other security bugs myself and others have submitted, it’s clear that Google will greatly prefer to dismiss security bugs as “Wontfix” or “not a bug”. Anything other the RCE or XSS will have difficulty to fit in.
I’m pretty sure that something like Clickjacking would have been immediately dismissed, only to realise afterwards the mistake that has been done.
More on that with some examples in a latter post.

So are we safe now?

– No.
It’s still too damn easy to trick a user to allow something like webcam access, and that’s valid to other browsers not just Chrome. Be extremely wary of where you click and what’s going on in your browser at all times. The indication that a website is accessing your camera is not clear enough – you gotta be wary. (FireFox indication is much better, btw)

Popups are evil

Beside the specific security bugs in popups and the way it can be exploited for PopJacking.
I would argue that there is not even one legitimate use of browser popups in term of user-experience.

Browser vendors should just kill popups all together, forever.

The concept of session memory is not valid anymore in today’s browsers. Even sessionStorage is not cleared after closing the tab. It’s easily revived when clicking on “Reopen closed tab”. That might seem as a bug – not if you look at the spec which is rather permissive, maybe too much.

So what’s the problem really?

Imagine you login to your bank website from a trusted 3rd party computer.
When you’re done, you simply click the X button to close the site assuming that you’re session will be done. This used to be true for many years, since it was common for critical websites like banks to store the authentication token in a session-cookie.
And session cookies, as the name implies are gone when the session is gone. The problem is that with tab browsing, and browsers running in the background that session might end long time after you clicked on the X.
This means that most of the time, anyone accessing that computer after you, will be able to continue where you left – logged in as you.

sessionStorage to the rescue? – not really

So if session-cookies are not good enough, what about that shiny sessionStorage?
It’s isolated per tab and cleared when that tab is closed.
It must be good – you click the X and it’s gone.
Well almost…
In Chrome and Firefox the session storage is easily revived with right click and “Reopen closed tab” and “Undo close tab” respectively.

This strange and unexpected behavior of the sessionStorage is still complying with the spec which is somewhat over permissive:
“The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent may support resuming sessions after a restart.”

We can argue whether this is a bug or not, but it’s definitely a bad feature and should be mitigated. We should have real session storage which we can trust to be cleared when we click on the “X”. Without unreliable tricks like onbeforeunload and alike.

Here’s a demo, close the tab and reopen it with “Reopen closed tab”  – the sessionStorage will be revived.

While Chrome and FireFox are acting badly and revive the sessionStorage, Safari and IE11 don’t revive it and are the safer browsers in that regard.

Bottom line

As a user, always always logout manually, never rely on just closing the tab or the browser.

As a developer, the only way to create real sessions that are gone when the user closes the tab is to keep anything critical in the memory and only in the memory. I’ve written more about it with examples in here.

A refresher about relevant browser storage mechanism

1. localStorage ~5MB, saved for infinity or until the user manually deletes it.
2. sessionStorage ~5MB, saved for the life of the current tab
3. cookie ~4KB, can be saved up to infinity
4. session cookie ~4KB, deleted when the user closes the browser (not always deleted)

Safe session-token caching

When dealing with critical platforms it is expected that the session is ended when the user closes the tab.
In order to support that, one should never use cookies to store any sensitive data like authentication tokens. Even session-cookies will not suffice since it’ll continue to live after closing the tab and even after completely closing the browser.
(We should anyway consider to not use cookies since these have other problems that are need to be dealt with, i.e. CSRF.)

This leaves us with saving the token in the memory or in the sessionStorage. The benefit of the sessionStorage is that it’ll persist across different pages and browser refreshes. Hence the user may navigate to different pages and/or refresh the page and still remain logged-in.

Good. We save the token in the sessionStorage, send it as an header with every request to the server in order to authenticate the user. When the user closes the tab – it’s gone.

But what about multiple tabs?

It is pretty common even in single page application that the user will want to use multiple tabs. The afordmentioned security enahncment of saving the token in the sessionStorage will create some bad UX in the form of requesting the user to re-login with every tab he opens. Right, sessionStorage is not shared across tabs.

Share sessionStorage between tabs using localStorage events

The way I solved it is by using localStorage events.
When a user opens a new tab, we first ask any other tab that is opened if he already have the sessionStorage for us. If any other tab is opened it’ll send us the sessionStorage through localStorage event, we’ll duplicate that into the sessionStorage.
The sessionStorage data will not stay in the localStorage, not even for 1 millisecond as it being deleted in the same call. The data is shared through the event payload and not the localStorage itself.

Demo is here

Click to “Set the sessionStorage” than open multiple tabs to see the sessionStorage is shared.

Almost perfect

We now have what is probably the most secure way to cache session tokens in the browser and without compromising the multiple tabs user-experience. In this way when the user closes the tab he knows for sure that the session is gone. Or is it?!

Both Chrome and Firefox will revive the sessionStorage when the user selects “Reopen closed tab” and “Undo close tab” respectively.
Damn it!

Safari does it right and don’t restore the sessionStorage (tested only with these 3 browsers)

For the user the only way to be completely sure that the sessionStorage is really gone is to reopen the same website directly and without the “reopen closed tab” feature.
That until Chrome and Firefox will resolve this bug. (my hunch tells me that they will call it a “feature“)

Even with this bug, using the sessionStorage is still safer than session-cookie or any other alternative. If we’ll want to make it perfect we’ll need to implement the same mechanism using memory instead of sessionStorage. (onbeforeunload and alike can work too, but won’t be as reliable and will clear also on refresh. window.name is almost good , but it’s too old and has no cross-domain protection)

Sharing memoryStorage between tabs for secure multi-tab authentication

So… this will be the only real safe way to keep an authentication token in a browser session and will allow the user to open multiple tabs without having to re-login

Close the tab and the session is gone – for real this time.

The downsides is that when having only one tab, a browser refresh will force the user to re-login. Security comes with a price, obviously this is not recommended for any type of system.

Demo is here

Set the memoryStorage and open multiple tabs to see it shared between them. Close all related tabs and the token is gone forever (memoryStorage is just a javascript object)

**
P.S.** Needless to say that session management and expiration should be handled on the server side as well.

This script will leech all the files from a folder in an FTP. It’s especially appropriate for dealing with enormous amount of files – hundreds of thousands or even millions.

My FTP issues

I have set up an IP security camera to save an image to my shared hosted FTP whenever it recognised any movement. The camera was cheap, old and not that accurate, so it saved lost of photos – more than half a million.

I needed to delete most of these photos but not all of it. Some of the photos captured interesting moments and I wanted to save these. I couldn’t just delete the folder, I had to download and check every photo. Checking the photos wasn’t as difficult as it might sound. Most of it were either almost identical or completely empty (zero bytes). Downloading it was the problem.

The 10000 limit
If you’re using a shared hosting it’s likely that your FTP server is limited. By default most shared FTP servers are probably running PureFTP and have a default limit of 10,000 files. This means you can only list 10,000 files and you will not even know how much files are in there.
You can probably ask your hosting provider to increase the “ftp recursion limit”, but I’m not sure they will be willing to up high enough.
Anyway, it’ll be cumbersome to deal with so many files and most FTP clients will freeze even trying to list less the 10k. I’ve tried a few on different OSs, eventually FileZilla for Windows seemed to be the best. But still, dealing with so many files was an extremely tedious process. And it’s even worse since I can’t even tell how many files are in that folder and how many times I will have to repeat this tedious process:

1. Connect to the server and list the folder – 10 minutes for listing 10,000 files
2. Even TranZilla failed to list the files from time to time – try again
3. Move all the listed files to my local folder – ~1-2 hours for very small files
4. If it fails for some reason – Repeat all steps
5. If it succeeded – Repeat  all steps

Overall if I wanted to do it manually I would have to repeat that annoying process for hundreds of times (including failures).

Python to the rescue

Obviously python is an amazing scripting language (and beyond). Writing a python script to leech an FTP is very easy and straight forward to create. I was able to PoC with just a few lines of code after looking at the ftplib docs.

Eventually I added a few extra features like logging and retries. But not too much, it was supposed to be quick and save me time – and it definitely did 🙂

In order to make even more robust one would consider adding stuff like full tree traversal (leech the whole FTP and not just one folder),  multithreading to download from multiple connection simultaneously, and more. All were beyond the scope of this script and would be relatively easy to add in Python.

The Supervisor

While the leacher.py script is supposed to run continuously until it leeches the whole folder, it might still break in some cases. And on the Mac the machine goes to sleep and stops the script.

That’s why I added this supervisor.py script which runs the leacher.py again if it breaks and also prevents the system from sleeping on the Mac.

How to

Download both leacher.py and supervisor.py from here. Edit the params on the bottom of  leacher.py with your FTP info.

Run like this: python supervisor.py leacher.py

Watch it leech. Check leacher.log for more verbose info.

**Summary
**

Overall the leacher.py script processed about half a million files and saved me a lot of time and annoyance.

Python is awesome!

Although it’s not supposed to be supported – it’s possible to know whether the Chrome console is opened or not.
Check it out.

Reddit discussion.

…
Ever wondered if it’s possible to tell whether the browser’s Development-Tools are opened or not. Apparently it’s not possible in Chrome. And that’s a good thing, it’s no website business to know when I inspect their code.

The thing is… it is possible to tell.

When you run console commands it runs slower when the console is opened. That’s it. You simply run console.log and console.clear a few times and if it’s slower – than the console is open.

With this hack you can find out pretty reliably when the console is open and when it is closed.

Frankly, I don’t see how this can be mitigated without harming the performance of the browser. When the console is opened it has to be slower. Hence this hack will most likely continue to work. And I assume it’ll work similarly on other browsers and with other consoles.

Although others will claim otherwise, the only way I see this hack being used legitimately is by geeks to impress their peers.
Other than that the only valid reasons that I can think of are malicious, but I’m not gonna tell you how 😉

**
Making it perfectly accurate**

In the demo I’ve used a benchmark ratio of 1.6 to determine if the console is open or not. In a perfect implementation the ratio will be dynamic and will change between environments.

Currently if a user will open the page with the console already opened it’ll be detected only after the user will close it at least once.

It’ll be possible to create another independent benchmark to tell whether the console was opened when the page first loaded.

Demo is here

More info: Webcam spying with Chrome

———————————————————————————————————–

Clickjacking and Spoofing the Google Chrome Permission Bar is Too Damn Easy

The permission bar in Chrome suffers from a list of bugs that can be combined in multiple ways in order to trick the user into granting access to privacy related features without being aware of it.

In some situations the user might realize that something bad just happened, but until he’ll take action to reverse it – his privacy will already be compromised. I.e. his camera will photograph him, his location will be revealed, etc’.

**
The Demos:**

The demos are targeting for full access to the user’s camera and microphone, which are probably the most privacy related features.

1. Wearing With Bars.
   This demo abuses the fact that it’s possible to create a completely identical fake permission bar. And that the real bar can be altered to show merely “http://” instead of the full text.
   The user will be tired will multiple fake bars until the real bar will appear.

2. Clickjacking using popups
   Using 2 popups, and the way popups can be controlled, to clickjack the user to “Allow” the access to his camera. Even if the user will notice something phishy happened, and will take immediate action. It’s likely that his privacy was already compromised.
   Clickjacking using popup (Popjacking) is extremely overlooked by all browsers.

3. Ubuntu.
   Chrome renders the permission bars differently on every OS. This is an example of how to mess with it in Ubuntu. This demo is not fully functional, just shows an example of what can be done.
   This flaw was mitigated in Chrome 35 thanx to the move to the Aura UI. But still, the permission bars renders and behave slightly different in Ubuntu.

4. None Closable Popup.
   While this is more of a popup bug, it shows how this can be leverage to trick the user into allowing access to his camera.
   The permission bar should not be functional under extreme condition. In this case the popup is almost frozen but the “Allow” button is still functional.

5. Over And Switch.
   The most basic clickjacking attack on the permission bar.
   The time it takes for the real bar to appear is probably the best time for clickjacking. (~130 milliseconds)

These are just a few examples, these flaws can be combined in multiple other ways.

**
The List of Flaws:**

The list is not the most organised list; I basically threw-in most of the stuff I’ve stumbled into. The video is more explanatory.
Some of the items in the list are objectively bugs, and some may be considered as “by-design”. The by-design features or bugs should be mostly mitigated, though some of it is not harmful on its own.

1. It’s easy to create a fake identical permission bar.
2. Permission bars act and render differently between OSs each with it’s own flaws.
3. Different types of permission-bars act and render differently.
4. It’s possible to tell when the permission bar is opened and when it’s closed – using the content height (resize event is fired).
5. Permission bars are not accessible. When enlarging fonts/zooming – permission-bars stay the same.
6. Use window focus and blur events to tell when the window is clickable.
7. The permission bar doesn’t have “the arrow” when opened in a popup (Mac only)
8. The permission bar can be made to reopen constantly requesting it multiple times. Requesting the same permission multiple times will show the bar multiple times when clicking on “x” (infinitely)
9. It’s easy to control the existent of the permission bar. Showing is obvious, hiding it using refresh and/or sub-domains.
10. When using a very long subdomain the message will be turned into merely “http://“ (MAC only). Other OSs bar are truncated differently.
11. Use staggering permission (multiple tries) – ask for camera if decline ask for microphone if declined ask for speech etc’.
12. Infinite tries using infinite subdomains (if the user “Deny” simply redirect to another subdomain and try again)
13. Resize the popup to show only the “Allow” button (Windows only)
14. Resizing the popup smaller and than bigger – the Permission Bar UI will not revert itself. It’s possible to leave only the Camera Icons and the “Allow” button (Ubuntu)
15. Inconsistency between OSs (MAC, Windows 7, Ubuntu)
16. Information popover (when clicking on the camera icon in the address bar) can be messed-up. Especially on windows when the popup is small. On the mac it can be slightly messed using a long subdomain / domain.
17. The “Allow” button can be clicked in a window, which is out of focus. Optimally the buttons in the permission bar will be functional only a second or so after the window received focus. This will mitigate clickjacking using popups.
18. After the user approve, the camera icon in the address bar is not clear enough, will be missed by most users. It should be clear “Website attacker.com is accessing your webcam and microphone!”
19. On the MAC refresh remove the bar on win7 the bar stays after refresh. It can be removed using a redirect to a different subdomain.
20. The red circle in the tab that indicates that the camera is being access is not existant in popups and hidden on a normal window when multiple tabs are opened.
21. On HTTPS permission is sticky even if the SSL certificate is not valid.
22. POPUPS flaws ->
23. These are flaws on its own but are very helpful for jacking the permission bar.
24. Tell the mouse location also from the parent window.
25. Enforcing the size and position of the popup.
26. Popups can be made un-closable using a while loop, resizing or moving (works only after the Dev tools were opened at least once) (might be possible without opening the dev tools)(easy to trick the user to open the dev-tools by asking him to type the shortcut)
27. Clicking multiple times will open multiple popups- there is absolutely no delay. For example, tricking the user to click 10 times in a second during a game is pretty easy – it will result in 10 popups opening together (windows)
28. Popups opening can be delayed for second, it may look like the popup was not generated from the click. This goes well with the previous flaw – the user will click multiple times before noticing anything wrong and multiple popups are scatter all over the screen. (windows)
29. Using double-click its possible to calculate the different between 2 clicks and make the 2 popups open together. (windows)
30. You can still do popunders in Chrome, jquery-popunder is a good example. (the user will be able to notice it openeing though)
31. You can make a popup open on another screen, messing with moveTo. A small popup that is located on the far bottom of the other screen can go unnoticed.
32. A popup can be made to jump between screen, stucking (no close). This is very annoying and confusing to the user. The popup will become semi transparent and very difficult to interact with.

**
Mitigation**

The fastest mitigation might be to simply add 1 second where the buttons are disabled. It should happen every time the permission bar is opened or when the window is gaining focus. That will mitigate all the clickjacking attacks, but it won’t help other kinds of attacks (tricking the user to click allow using fake bars, for example)

The current permission bar is subtle and elegant, it looks great. But, it doesn’t serve it’s purpose. The Permission-bar should be bigger, clearer and completely separated from the content area.

An extreme mitigation will also eliminate popups completely. Popups are bad for the user experience even when used legitimately.
Obviously, popups can be abused for clickjacking of any web content and not only the permission-bars – this is extremely overlooked by all browsers.

The best solution for this problem is probably OS level permissions that will stay the same across browsers and OSs.

Try the live demo… (Designed for Mac  though it will work similarly on any other OS)

Watch the video…

**
The Sisyphus of computer science**

Speech recognition is like the Sisyphus of computer science. We came a long way but still haven’t reached the top of that hill. With all that crunching power and sophisticated algorithms, computers still can’t recognise some basic words and sentences, the kinds that the average human digest without breaking a sweat. This is still one of the areas that humans easily win over computers. Savor these wins, as it will not last much longer;)

One must appreciate Google for pushing this area forward and introducing speech recognition into the Chrome browser. The current level of speech support in Chrome allows us to create application and websites that are completely controlled form speech. It open vast possibilities – form general improved accessibility to email dictation and even games.

The current speech API is pretty decent. It works by sending the audio to Google’s servers and returns the recognised text. The fact that it sends the audio to Google has some benefits, but from applicative point of view it will always suffer from latency and will not work offline. I believe that the current speech support was introduced with Chrome 25. From Chrome 33 one can also use Speech Synthesis API. – Amazing!

But…
Before this fine API we currently have, Google experimented with an earlier version of the API. It works quite the same, the main difference is that the older API doesn’t work continuously and needs to start after every sentence. Still, it’s powerful enough and it has some flaws that enable it to be abused. I believe this API was introduced with Chrome 11 and I have a good reason to believe it was flawed since than.

**
More Technical Details**

Basically, this attack is abusing Chrome’s old speech API, the -x-webkit-speech feature.
What enable this attack are these 3 issues:

1. The speech element visibility can be altered to any size and opacity, and still stay fully functional.
2. The speech element can be made to take over all clicks on the page while staying completely invisible. (No need to mess with z-indexes)
3. The indication box (shows you that you’re being recorded) can be obfuscated and/or be rendered outside of the screen.

The  POC is designed to work on Chrome for Mac, but, the same attack can be conducted to work on any Chrome on any OS.

This POC is using the full-screen mode to make it easier to hide the “indication box” outside of the screen.
It is not mandatory to use the HTML5 full-screen; it’s just easier for this demo.

As you can see in the demo and video there is absolutely no indication that anything is going-on. There are no other windows or tabs, and no some kind of hidden popup or pop-under.
The user will never know this website is eavesdropping.

In Chrome all one need in order to access the user’s speech is to use this line of HTML5 code:
<input -x-webkit-speech />

That’s all; there will be no fancy confirmation screens. When the user clicks on that little grey microphone he will be recorded. The user will see the “indication box” telling him to “Speak now” but that can be pushed out of the screen and / or obfuscated.

That is enough in order to listen to the user speech without any consent and without giving him any indication. The other bugs just make it easier but are not mandatory.

(For the tree in the demo I have used a slightly altered version of the beautiful canvas tree from Kenneth Jorgensen)

— The bug was reported to Google.

I stumbled upon some CSRF flaws in a very popular e-commerce website. CSRF flaws are generally overlooked and the only way for you as the user to minimize the risk is to logout from a website after you finished using it. This will limit the window of being vulnerable to attacks to the time you spend on a website. I have disclosed my finding to the e-commerce website and will post it here after they’ll finish fixing it.

This is how these CSRF flaws generally works

When you login to a website you get back a cookie that indicates who you are and the fact that you are authenticated.
Now, for better user experience and so you won’t need to re-login, most websites tell your browser to keeps the cookie for very very long time (up to 10 years is considered safe).
The problem is that if a website suffers from any CSRF flaws, and many still do, from now-on every-time you visit any unrelated internet content it may be attacking you. Think of all these slightly phishy content you stumbled upon over the past years, some of it could have been attacking you.

A famous case of CSRF attack against a bank was using a legitimate AD and abused a flaw in the bank website to transfer user’s money. Gmail suffered from a CSRF flaw in its early days, leaking all of its user’s contacts.

CSRF flaws are used to steal sensitive data from users and to perform actions on the user’s behalf. The flaw I found enables both – an attacker can steal user’s personal data and also mess with his assets.

How I stumbled upon it

****I was surfing on an open public WiFi – generally a bad thing to do but I needed to. This public WiFi had a phishy name “eyes2” and there are few other “eyes” circling around – “eyes1”, “eyes2”, “eyes3”, etc’. Call me paranoid but it seems to me that these access points were put there in order to eavesdrop. Might be just for fun might be more. Anyhow, I generally don’t care as long as I keep all of my traffic in SSL. I don’t care them getting my metadata. So I went to this huge e-commerce website just to check something and was amazed it’s not all SSLed. Wow… I wondered… what kind of data have I just leaked to the MITM from the “eyes2” access point?! Apparently, if someone is eavesdropping on my connection he now knew exactly who I am and more.

The fact that any website that deals with even slightly sensitive data, and doesn’t use SSL for all of its traffic is a flaw on its own. But SSL is not related to these specific flaws, in fact using SSL doesn’t help to prevent CSRF flaws. It’s only because I wanted to know exactly what kind of data this website leaked by using plain http and not https (SSL), I found out it’s also vulnerable to CSRF attacks.

Where are all the details?

****I reported my finding to the e-commerce website. It took me way longer to find the appropriate way to contact them than to find the flaws and PoC it. I did eventually managed to report it and they were very responsive about it and seemed like they already started to fix it. I will post all the details after they’ll finish fixing it.

As a website owner it’s important to remember to implement CSRF prevention from the get go. Most web frameworks have their own solutions already. It’s very easy to overlook it. It’s very easy to use something like JSONP and to forget how vulnerable it can be, for example.

How to protect yourself

CSRF is generally based on cookies, what you can do to protect yourself is to logout or delete your cookies after you finished using a certain website. That won’t be bulletproof since you’ll still be vulnerable to attacks while you’re logged-in. The only way to be completely safe is to use only 1 window with only 1 tab while you are logged-in.

Obviously all of this is a complete hassle, and website owners should be the ones responsible for their CSRF flaws. The user can’t be expected to do it.

If your using firefox you may use something like noscript, which also involve some level of annoyance.

After seeing in the previous post how Data-URIs can be used as a mechanism to easily carry malicious code, I’ll elaborate more about the issues it presents.

Some of it merely exists from the way Data-URIs are designed and implemented, and some of it might be considered as security bugs in the browsers.

Using Data-URI to manipulate the address bar

The simplest thing an attacker can do is to add spaces after the “data:” in the URI and by that it can make it look like it some kind of a Chrome internal page.

It will also change the link status in the bottom of the browser. The link will show “data:” hiding all the base64 code that is there. It’s a way to manipulate the status bar without the need of JavaScript. Hence the link will be manipulated even in an environment that doesn’t allow JavaScript.

Combine that attack with the previous example of the phishing SVG and you can get catastrophic results. Lots of users might believe this is an internal Chrome page.

[Live example (Open in Chrome)](data: image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUWVBFIHN2ZyBQVUJMSUMgIi0vL1czQy8vRFREIFNWRyAxLjEvL0VOIiAiaHR0cDovL3d3dy53My5vcmcvR3JhcGhpY3MvU1ZHLzEuMS9EVEQvc3ZnMTEuZHRkIj4KPHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciCiAgICB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIKICAgIHhtbG5zOmV2PSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL3htbC1ldmVudHMiCiAgICB2ZXJzaW9uPSIxLjEiCiAgICBiYXNlUHJvZmlsZT0iZnVsbCIKICAgIHdpZHRoPSIxMDAlIgogICAgaGVpZ2h0PSIxMDAlIj4KCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+CjwhW0NEQVRBWwouaW5wdXQgewogICAgZmlsbDogI2ZmZjsKICAgIHBvaW50ZXItZXZlbnRzOiBhbGw7CiAgICBzdHJva2U6ICNkOWQ5ZDk7CiAgICBzdHJva2Utd2lkdGg6IDE7CiAgICBjdXJzb3I6IHRleHQ7Cn0KLmlucHV0OmhvdmVyIHsKICAgIHN0cm9rZTogI2EwYTBhMDsKICAgIGZpbHRlcjogdXJsKCNpbm5lcnNoYWRvdyk7Cn0KCi5sYWJlbCB7CiAgICBmb250LXdlaWdodDogYm9sZDsKICAgIGZvbnQtc2l6ZTogMTNweDsKfQoKLmdyYXktYm94IHsKICAgIGZpbGw6ICNmMWYxZjE7CiAgICBzdHJva2U6ICNlNWU1ZTU7CiAgICBzdHJva2Utd2lkdGg6IDE7Cn0KCnRleHQgewogICAgZm9udC1mYW1pbHk6IGFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWY7Cn0KCi5nb29nbGUgewogICAgZmlsbDogI2FjYWNhYzsKICAgIGZvbnQtc2l6ZTogMTZweDsKICAgIGZvbnQtZmFtaWx5OiBnZW9yZ2lhOwp9CgouaDEgewogICAgZm9udC1zaXplOiAzNnB4Owp9CgouaDQgewogICAgZm9udC1zaXplOiAxM3B4Owp9CgphIHsKICAgIGZpbGw6ICMxNWM7CiAgICBmb250LXNpemU6IDEzcHg7Cn0KCmE6aG92ZXIgewogICB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsKfQoKLmJ1dHRvbiB7CiAgICBzdHJva2U6ICMzMDc5ZWQ7CiAgICBzdHJva2Utd2lkdGg6IDE7CiAgICBmaWxsOiAjNGQ5MGZlOwp9CgouYnV0dG9uOmhvdmVyIHsKICAgIHN0cm9rZTogIzJmNWJiNzsKICAgIGZpbGw6ICMzNTdhZTg7Cn0KCi5idXR0b24tdGV4dCB7CiAgICBmaWxsOiAjZmZmOwogICAgZm9udC1zaXplOiAxM3B4OwogICAgZm9udC13ZWlnaHQ6IGJvbGQ7CiAgICBrZXJuaW5nOiAwLjU7CiAgICB0ZXh0LXNoYWRvdzogMCAxcHggcmdiYSgwLCAwLCAwLCAwLjQpOwogICAgcG9pbnRlci1ldmVudHM6IG5vbmU7Cn0KCi5tc2cgewogICAgZmlsbDogcmVkOwogICAgZmlsbC1vcGFjaXR5OiAwLjg7CiAgICBvcGFjaXR5OiAwOwogICAgdHJhbnNpdGlvbjogYWxsIDFzOwogICAgZmlsdGVyOiB1cmwoI2Ryb3BzaGFkb3cpOwogICAgcG9pbnRlci1ldmVudHM6IG5vbmU7Cn0KCi5tc2ctdGV4dCB7CiAgICBmaWxsOiAjZmZmOwogICAgZm9udC1zaXplOiAyMHB4OwogICAgdGV4dC1zaGFkb3c6IDJweCAycHggMXB4ICM2NjY7Cn0KXV0+Cjwvc3R5bGU+CjxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij4KICAgIGZ1bmN0aW9uIGF0dGFjayhlKSB7CiAgICAgICAgdmFyIGVsID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ21zZycpOwoKICAgICAgICBpZiAoIStlbC5zdHlsZS5vcGFjaXR5KSB7CiAgICAgICAgICAgIGVsLnN0eWxlLm9wYWNpdHkgPSAxOwogICAgICAgICAgICBlbC5zdHlsZVsncG9pbnRlci1ldmVudHMnXSA9ICdhbGwnOwogICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgIGVsLnN0eWxlLm9wYWNpdHkgPSAwOwogICAgICAgICAgICBlbC5zdHlsZVsncG9pbnRlci1ldmVudHMnXSA9ICdub25lJzsKICAgICAgICB9CiAgICB9Cjwvc2NyaXB0PgoKICAgIDxzdmcgdmlld0JveD0iMCAwIDMwMCA5MDAiIHdpZHRoPSIxMDAlIiBoZWlnaHQ9IjkwMHB4IiBwcmVzZXJ2ZUFzcGVjdFJhdGlvPSJ4TWlkWU1pZCBtZWV0Ij4KICAgIDxkZWZzIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+CiAgICAgICAgPGZpbHRlciBpZD0iZHJvcHNoYWRvdyIgaGVpZ2h0PSIxMzAlIj4KICAgICAgICAgIDxmZUdhdXNzaWFuQmx1ciBpbj0iU291cmNlQWxwaGEiIHN0ZERldmlhdGlvbj0iMyIvPgogICAgICAgICAgPGZlT2Zmc2V0IGR4PSIyIiBkeT0iMiIgcmVzdWx0PSJvZmZzZXRibHVyIi8+CiAgICAgICAgICA8ZmVNZXJnZT4KICAgICAgICAgICAgPGZlTWVyZ2VOb2RlLz4KICAgICAgICAgICAgPGZlTWVyZ2VOb2RlIGluPSJTb3VyY2VHcmFwaGljIi8+CiAgICAgICAgICA8L2ZlTWVyZ2U+CiAgICAgICAgPC9maWx0ZXI+CiAgICAgICAgPGZpbHRlciBpZD0iaW5uZXJzaGFkb3ciIHgwPSItNTAlIiB5MD0iLTUwJSIgd2lkdGg9IjIwMCUiIGhlaWdodD0iMjAwJSI+CiAgICAgICAgCQkJPGZlR2F1c3NpYW5CbHVyIGluPSJTb3VyY2VBbHBoYSIgc3RkRGV2aWF0aW9uPSIyIiByZXN1bHQ9ImJsdXIiLz4KICAgICAgICAJCQk8ZmVPZmZzZXQgZHk9IjEiIGR4PSIxIi8+CiAgICAgICAgCQkJPGZlQ29tcG9zaXRlIGluMj0iU291cmNlQWxwaGEiIG9wZXJhdG9yPSJhcml0aG1ldGljIgogICAgICAgIAkJCQkJazI9Ii0xIiBrMz0iMSIgcmVzdWx0PSJzaGFkb3dEaWZmIi8+CiAgICAgICAgCQkJPGZlRmxvb2QgZmxvb2QtY29sb3I9ImJsYWNrIiBmbG9vZC1vcGFjaXR5PSIwLjQiLz4KICAgICAgICAJCQk8ZmVDb21wb3NpdGUgaW4yPSJzaGFkb3dEaWZmIiBvcGVyYXRvcj0iaW4iLz4KICAgICAgICAJCQk8ZmVDb21wb3NpdGUgaW4yPSJTb3VyY2VHcmFwaGljIiBvcGVyYXRvcj0ib3ZlciIvPgogICAgICAgIAkJPC9maWx0ZXI+CiAgICAgIDwvZGVmcz4KICAgICAgPGc+CiAgICAgICA8dGV4dCBjbGFzcz0iaDEiIHg9IjEiIHk9IjY3Ij5TaWduIGluIHRvIENocm9tZTwvdGV4dD4KICAgICAgIDx0ZXh0IGNsYXNzPSJoNCIgeD0iLTEwNSIgeT0iMTE1Ij5TaWduIGluIHRvIGdldCB5b3VyIGJvb2ttYXJrcywgaGlzdG9yeSwgYW5kIHNldHRpbmdzIG9uIGFsbCB5b3VyIGRldmljZXMuPC90ZXh0PgogICAgICAgPGEgeGxpbms6aHJlZj0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9jaHJvbWUvaW50bC9lbi9tb3JlL3NpZ24taW4uaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPgogICAgICAgICAgICA8dGV4dCBjbGFzcz0iaDQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZpbGw9IiMxNWMiIHg9IjM1MCIgeT0iMTE1Ij5MZWFybiBtb3JlLjwvdGV4dD4KICAgICAgIDwvYT4KICAgICAgIDxyZWN0IGNsYXNzPSJncmF5LWJveCIgd2lkdGg9IjM2MCIgaGVpZ2h0PSIzNTQiIHg9Ii0zNCIgeT0iMTU2Ii8+CiAgICAgICAgIDxnPgogICAgICAgICAgPHRleHQgY2xhc3M9Imdvb2dsZSIgeD0iMjU1IiB5PSIxOTAiPkdvb2dsZTwvdGV4dD4KICAgICAgICAgIDx0ZXh0IHg9Ii0xMCIgeT0iMTkwIiBzdHlsZT0iZm9udC1zaXplOjE3cHg7Ij5TaWduIEluPC90ZXh0PgogICAgICAgICAgPHRleHQgY2xhc3M9ImxhYmVsIiB4PSItMTAiIHk9IjIyNiI+RW1haWw8L3RleHQ+CiAgICAgICAgICA8cmVjdCBjbGFzcz0iaW5wdXQiIHg9Ii0xMCIgeT0iMjM0IiB3aWR0aD0iMzA4IiBoZWlnaHQ9IjM3IiBvbmNsaWNrPSJhdHRhY2soKTsiLz4KICAgICAgICAgIDxsaW5lIHgxPSItMTAiIHkxPSIyMzQiIHgyPSIyOTgiIHkyPSIyMzQiIHN0cm9rZT0iI2MwYzBjMCIgc3Ryb2tlLXdpZHRoPSIxIiBzdHJva2Utb3BhY2l0eT0iMC40Ii8+CiAgICAgICAgICA8dGV4dCBjbGFzcz0ibGFiZWwiIHg9Ii0xMCIgeT0iMzAyIj5QYXNzd29yZDwvdGV4dD4KICAgICAgICAgIDxyZWN0IGNsYXNzPSJpbnB1dCIgeD0iLTEwIiB5PSIzMTAiIHdpZHRoPSIzMDgiIGhlaWdodD0iMzciIG9uY2xpY2s9ImF0dGFjaygpOyIvPgogICAgICAgICAgPGxpbmUgeDE9Ii0xMCIgeTE9IjMxMCIgeDI9IjI5OCIgeTI9IjMxMCIgc3Ryb2tlPSIjYzBjMGMwIiBzdHJva2Utd2lkdGg9IjEiIHN0cm9rZS1vcGFjaXR5PSIwLjQiLz4KICAgICAgICAgIDxyZWN0IGNsYXNzPSJidXR0b24iIHg9Ii0xMCIgeT0iMzY2IiB3aWR0aD0iNzUiIGhlaWdodD0iMzciIHJ4PSIyIiBvbmNsaWNrPSJhdHRhY2soKTsiLz4KICAgICAgICAgIDx0ZXh0IGNsYXNzPSJidXR0b24tdGV4dCIgeD0iNCIgeT0iMzkwIj5TaWduIGluPC90ZXh0PgogICAgICAgICAgPGEgeGxpbms6aHJlZj0iaHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tL1JlY292ZXJBY2NvdW50IiB0YXJnZXQ9Il9ibGFuayI+CiAgICAgICAgICAgIDx0ZXh0IGNsYXNzPSJoNCIgdGV4dC1hbmNob3I9ImxlZnQiIGZpbGw9IiMxNWMiIHg9Ii0xMCIgeT0iNDQwIj5DYW4ndCBhY2Nlc3MgeW91ciBhY2NvdW50PzwvdGV4dD4KICAgICAgICAgIDwvYT4KICAgICAgICAgIDxhIHhsaW5rOmhyZWY9Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9TaWduVXAiIHRhcmdldD0iX2JsYW5rIj4KICAgICAgICAgICAgPHRleHQgY2xhc3M9Img0IiB0ZXh0LWFuY2hvcj0ibGVmdCIgZmlsbD0iIzE1YyIgeD0iLTEwIiB5PSI0NzIiPkNyZWF0ZSBhIEdvb2dsZSBhY2NvdW50PC90ZXh0PgogICAgICAgICAgPC9hPgogICAgICAgICAgPGc+CiAgICAgICAgICAgIDxzdmcgaWQ9Im1zZyIgY2xhc3M9Im1zZyIgeD0iMjAiIHk9IjIwMCIgb25jbGljaz0iYXR0YWNrKCk7Ij4KICAgICAgICAgICAgICAgIDxyZWN0IHdpZHRoPSIyNTAiIGhlaWdodD0iMjAwIiByeD0iMTAiLz4KICAgICAgICAgICAgICAgIDx0ZXh0IGNsYXNzPSJtc2ctdGV4dCIgeD0iMTAiIHk9IjMwIj4KICAgICAgICAgICAgICAgICAgICA8dHNwYW4geD0iMTAiPlRoaXMgaXMgYSBkZW1vbnN0cmF0aW9uIG9mPC90c3Bhbj4KICAgICAgICAgICAgICAgICAgICA8dHNwYW4geD0iMTAiIGR5PSIxLjJlbSI+aG93IFNWRyBjYW4gYmUgYWJ1c2VkPC90c3Bhbj4KICAgICAgICAgICAgICAgICAgICA8dHNwYW4geD0iMTAiIGR5PSIxLjJlbSI+Zm9yIFBoaXNoaW5nIGF0dGFja3MuPC90c3Bhbj4KICAgICAgICAgICAgICAgICAgICA8dHNwYW4geD0iMTAiIGR5PSIyLjVlbSI+Rm9yIG1vcmUgaW5mbyB2aXNpdDo8L3RzcGFuPgogICAgICAgICAgICAgICAgPC90ZXh0PgogICAgICAgICAgICAgICAgPGEgeGxpbms6aHJlZj0iaHR0cDovL2d1eWEubmV0IiB0YXJnZXQ9Il9ibGFuayI+CiAgICAgICAgICAgICAgICAgICA8dGV4dCB0ZXh0LWFuY2hvcj0ibGVmdCIgeD0iMTAiIHk9IjE2MCIgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtd2VpZ2h0OmJvbGQ7Ij5odHRwOi8vZ3V5YS5uZXQ8L3RleHQ+CiAgICAgICAgICAgICAgICA8L2E+CiAgICAgICAgICAgIDwvc3ZnPgogICAgICAgICAgPC9nPgoKICAgICAgICAgPC9nPgogICAgICA8L2c+CiAgICA8L3N2Zz4KPC9zdmc+)

While in the above example the user will see only “data:..” in the address bar. If he’ll feel uncomfortable the user can still examine the address bar and might find the hidden base64 code.

The next example will show how to prevent the user from examining the address bar at all, and it’ll always show “data:” The 3 dots indicating there might be more to it – will be removed as well.

By making the original content larger than ~28KB the address-bar will always show “data:” and only data.

[Live example of only data in the address-bar (Open in Chrome)](data: image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUWVBFIHN2ZyBQVUJMSUMgIi0vL1czQy8vRFREIFNWRyAxLjEvL0VOIiAiaHR0cDovL3d3dy53My5vcmcvR3JhcGhpY3MvU1ZHLzEuMS9EVEQvc3ZnMTEuZHRkIj4KPHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciCiAgICB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIKICAgIHhtbG5zOmV2PSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL3htbC1ldmVudHMiCiAgICB2ZXJzaW9uPSIxLjEiCiAgICBiYXNlUHJvZmlsZT0iZnVsbCIKICAgIHdpZHRoPSIxMDAlIgogICAgaGVpZ2h0PSIxMDAlIj4KCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+CjwhW0NEQVRBWwouaW5wdXQgewogICAgZmlsbDogI2ZmZjsKICAgIHBvaW50ZXItZXZlbnRzOiBhbGw7CiAgICBzdHJva2U6ICNkOWQ5ZDk7CiAgICBzdHJva2Utd2lkdGg6IDE7CiAgICBjdXJzb3I6IHRleHQ7Cn0KLmlucHV0OmhvdmVyIHsKICAgIHN0cm9rZTogI2EwYTBhMDsKICAgIGZpbHRlcjogdXJsKCNpbm5lcnNoYWRvdyk7Cn0KCi5sYWJlbCB7CiAgICBmb250LXdlaWdodDogYm9sZDsKICAgIGZvbnQtc2l6ZTogMTNweDsKfQoKLmdyYXktYm94IHsKICAgIGZpbGw6ICNmMWYxZjE7CiAgICBzdHJva2U6ICNlNWU1ZTU7CiAgICBzdHJva2Utd2lkdGg6IDE7Cn0KCnRleHQgewogICAgZm9udC1mYW1pbHk6IGFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWY7Cn0KCi5nb29nbGUgewogICAgZmlsbDogI2FjYWNhYzsKICAgIGZvbnQtc2l6ZTogMTZweDsKICAgIGZvbnQtZmFtaWx5OiBnZW9yZ2lhOwp9CgouaDEgewogICAgZm9udC1zaXplOiAzNnB4Owp9CgouaDQgewogICAgZm9udC1zaXplOiAxM3B4Owp9CgphIHsKICAgIGZpbGw6ICMxNWM7CiAgICBmb250LXNpemU6IDEzcHg7Cn0KCmE6aG92ZXIgewogICB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsKfQoKLmJ1dHRvbiB7CiAgICBzdHJva2U6ICMzMDc5ZWQ7CiAgICBzdHJva2Utd2lkdGg6IDE7CiAgICBmaWxsOiAjNGQ5MGZlOwp9CgouYnV0dG9uOmhvdmVyIHsKICAgIHN0cm9rZTogIzJmNWJiNzsKICAgIGZpbGw6ICMzNTdhZTg7Cn0KCi5idXR0b24tdGV4dCB7CiAgICBmaWxsOiAjZmZmOwogICAgZm9udC1zaXplOiAxM3B4OwogICAgZm9udC13ZWlnaHQ6IGJvbGQ7CiAgICBrZXJuaW5nOiAwLjU7CiAgICB0ZXh0LXNoYWRvdzogMCAxcHggcmdiYSgwLCAwLCAwLCAwLjQpOwogICAgcG9pbnRlci1ldmVudHM6IG5vbmU7Cn0KCi5tc2cgewogICAgZmlsbDogcmVkOwogICAgZmlsbC1vcGFjaXR5OiAwLjg7CiAgICBvcGFjaXR5OiAwOwogICAgdHJhbnNpdGlvbjogYWxsIDFzOwogICAgZmlsdGVyOiB1cmwoI2Ryb3BzaGFkb3cpOwogICAgcG9pbnRlci1ldmVudHM6IG5vbmU7Cn0KCi5tc2ctdGV4dCB7CiAgICBmaWxsOiAjZmZmOwogICAgZm9udC1zaXplOiAyMHB4OwogICAgdGV4dC1zaGFkb3c6IDJweCAycHggMXB4ICM2NjY7Cn0KXV0+Cjwvc3R5bGU+CjxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij4KICAgIGZ1bmN0aW9uIGF0dGFjayhlKSB7CiAgICAgICAgdmFyIGVsID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ21zZycpOwoKICAgICAgICBpZiAoIStlbC5zdHlsZS5vcGFjaXR5KSB7CiAgICAgICAgICAgIGVsLnN0eWxlLm9wYWNpdHkgPSAxOwogICAgICAgICAgICBlbC5zdHlsZVsncG9pbnRlci1ldmVudHMnXSA9ICdhbGwnOwogICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgIGVsLnN0eWxlLm9wYWNpdHkgPSAwOwogICAgICAgICAgICBlbC5zdHlsZVsncG9pbnRlci1ldmVudHMnXSA9ICdub25lJzsKICAgICAgICB9CiAgICB9Cjwvc2NyaXB0PgoKICAgIDxzdmcgdmlld0JveD0iMCAwIDMwMCA5MDAiIHdpZHRoPSIxMDAlIiBoZWlnaHQ9IjkwMHB4IiBwcmVzZXJ2ZUFzcGVjdFJhdGlvPSJ4TWlkWU1pZCBtZWV0Ij4KICAgIDxkZWZzIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+CiAgICAgICAgPGZpbHRlciBpZD0iZHJvcHNoYWRvdyIgaGVpZ2h0PSIxMzAlIj4KICAgICAgICAgIDxmZUdhdXNzaWFuQmx1ciBpbj0iU291cmNlQWxwaGEiIHN0ZERldmlhdGlvbj0iMyIvPgogICAgICAgICAgPGZlT2Zmc2V0IGR4PSIyIiBkeT0iMiIgcmVzdWx0PSJvZmZzZXRibHVyIi8+CiAgICAgICAgICA8ZmVNZXJnZT4KICAgICAgICAgICAgPGZlTWVyZ2VOb2RlLz4KICAgICAgICAgICAgPGZlTWVyZ2VOb2RlIGluPSJTb3VyY2VHcmFwaGljIi8+CiAgICAgICAgICA8L2ZlTWVyZ2U+CiAgICAgICAgPC9maWx0ZXI+CiAgICAgICAgPGZpbHRlciBpZD0iaW5uZXJzaGFkb3ciIHgwPSItNTAlIiB5MD0iLTUwJSIgd2lkdGg9IjIwMCUiIGhlaWdodD0iMjAwJSI+CiAgICAgICAgCQkJPGZlR2F1c3NpYW5CbHVyIGluPSJTb3VyY2VBbHBoYSIgc3RkRGV2aWF0aW9uPSIyIiByZXN1bHQ9ImJsdXIiLz4KICAgICAgICAJCQk8ZmVPZmZzZXQgZHk9IjEiIGR4PSIxIi8+CiAgICAgICAgCQkJPGZlQ29tcG9zaXRlIGluMj0iU291cmNlQWxwaGEiIG9wZXJhdG9yPSJhcml0aG1ldGljIgogICAgICAgIAkJCQkJazI9Ii0xIiBrMz0iMSIgcmVzdWx0PSJzaGFkb3dEaWZmIi8+CiAgICAgICAgCQkJPGZlRmxvb2QgZmxvb2QtY29sb3I9ImJsYWNrIiBmbG9vZC1vcGFjaXR5PSIwLjQiLz4KICAgICAgICAJCQk8ZmVDb21wb3NpdGUgaW4yPSJzaGFkb3dEaWZmIiBvcGVyYXRvcj0iaW4iLz4KICAgICAgICAJCQk8ZmVDb21wb3NpdGUgaW4yPSJTb3VyY2VHcmFwaGljIiBvcGVyYXRvcj0ib3ZlciIvPgogICAgICAgIAkJPC9maWx0ZXI+CiAgICAgIDwvZGVmcz4KICAgICAgPGc+CiAgICAgICA8dGV4dCBjbGFzcz0iaDEiIHg9IjEiIHk9IjY3Ij5TaWduIGluIHRvIENocm9tZTwvdGV4dD4KICAgICAgIDx0ZXh0IGNsYXNzPSJoNCIgeD0iLTEwNSIgeT0iMTE1Ij5TaWduIGluIHRvIGdldCB5b3VyIGJvb2ttYXJrcywgaGlzdG9yeSwgYW5kIHNldHRpbmdzIG9uIGFsbCB5b3VyIGRldmljZXMuPC90ZXh0PgogICAgICAgPGEgeGxpbms6aHJlZj0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9jaHJvbWUvaW50bC9lbi9tb3JlL3NpZ24taW4uaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPgogICAgICAgICAgICA8dGV4dCBjbGFzcz0iaDQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZpbGw9IiMxNWMiIHg9IjM1MCIgeT0iMTE1Ij5MZWFybiBtb3JlLjwvdGV4dD4KICAgICAgIDwvYT4KICAgICAgIDxyZWN0IGNsYXNzPSJncmF5LWJveCIgd2lkdGg9IjM2MCIgaGVpZ2h0PSIzNTQiIHg9Ii0zNCIgeT0iMTU2Ii8+CiAgICAgICAgIDxnPgogICAgICAgICAgPHRleHQgY2xhc3M9Imdvb2dsZSIgeD0iMjU1IiB5PSIxOTAiPkdvb2dsZTwvdGV4dD4KICAgICAgICAgIDx0ZXh0IHg9Ii0xMCIgeT0iMTkwIiBzdHlsZT0iZm9udC1zaXplOjE3cHg7Ij5TaWduIEluPC90ZXh0PgogICAgICAgICAgPHRleHQgY2xhc3M9ImxhYmVsIiB4PSItMTAiIHk9IjIyNiI+RW1haWw8L3RleHQ+CiAgICAgICAgICA8cmVjdCBjbGFzcz0iaW5wdXQiIHg9Ii0xMCIgeT0iMjM0IiB3aWR0aD0iMzA4IiBoZWlnaHQ9IjM3IiBvbmNsaWNrPSJhdHRhY2soKTsiLz4KICAgICAgICAgIDxsaW5lIHgxPSItMTAiIHkxPSIyMzQiIHgyPSIyOTgiIHkyPSIyMzQiIHN0cm9rZT0iI2MwYzBjMCIgc3Ryb2tlLXdpZHRoPSIxIiBzdHJva2Utb3BhY2l0eT0iMC40Ii8+CiAgICAgICAgICA8dGV4dCBjbGFzcz0ibGFiZWwiIHg9Ii0xMCIgeT0iMzAyIj5QYXNzd29yZDwvdGV4dD4KICAgICAgICAgIDxyZWN0IGNsYXNzPSJpbnB1dCIgeD0iLTEwIiB5PSIzMTAiIHdpZHRoPSIzMDgiIGhlaWdodD0iMzciIG9uY2xpY2s9ImF0dGFjaygpOyIvPgogICAgICAgICAgPGxpbmUgeDE9Ii0xMCIgeTE9IjMxMCIgeDI9IjI5OCIgeTI9IjMxMCIgc3Ryb2tlPSIjYzBjMGMwIiBzdHJva2Utd2lkdGg9IjEiIHN0cm9rZS1vcGFjaXR5PSIwLjQiLz4KICAgICAgICAgIDxyZWN0IGNsYXNzPSJidXR0b24iIHg9Ii0xMCIgeT0iMzY2IiB3aWR0aD0iNzUiIGhlaWdodD0iMzciIHJ4PSIyIiBvbmNsaWNrPSJhdHRhY2soKTsiLz4KICAgICAgICAgIDx0ZXh0IGNsYXNzPSJidXR0b24tdGV4dCIgeD0iNCIgeT0iMzkwIj5TaWduIGluPC90ZXh0PgogICAgICAgICAgPGEgeGxpbms6aHJlZj0iaHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tL1JlY292ZXJBY2NvdW50IiB0YXJnZXQ9Il9ibGFuayI+CiAgICAgICAgICAgIDx0ZXh0IGNsYXNzPSJoNCIgdGV4dC1hbmNob3I9ImxlZnQiIGZpbGw9IiMxNWMiIHg9Ii0xMCIgeT0iNDQwIj5DYW4ndCBhY2Nlc3MgeW91ciBhY2NvdW50PzwvdGV4dD4KICAgICAgICAgIDwvYT4KICAgICAgICAgIDxhIHhsaW5rOmhyZWY9Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9TaWduVXAiIHRhcmdldD0iX2JsYW5rIj4KICAgICAgICAgICAgPHRleHQgY2xhc3M9Img0IiB0ZXh0LWFuY2hvcj0ibGVmdCIgZmlsbD0iIzE1YyIgeD0iLTEwIiB5PSI0NzIiPkNyZWF0ZSBhIEdvb2dsZSBhY2NvdW50PC90ZXh0PgogICAgICAgICAgPC9hPgogICAgICAgICAgPGc+CiAgICAgICAgICAgIDxzdmcgaWQ9Im1zZyIgY2xhc3M9Im1zZyIgeD0iMjAiIHk9IjIwMCIgb25jbGljaz0iYXR0YWNrKCk7Ij4KICAgICAgICAgICAgICAgIDxyZWN0IHdpZHRoPSIyNTAiIGhlaWdodD0iMjAwIiByeD0iMTAiLz4KICAgICAgICAgICAgICAgIDx0ZXh0IGNsYXNzPSJtc2ctdGV4dCIgeD0iMTAiIHk9IjMwIj4KICAgICAgICAgICAgICAgICAgICA8dHNwYW4geD0iMTAiPlRoaXMgaXMgYSBkZW1vbnN0cmF0aW9uIG9mPC90c3Bhbj4KICAgICAgICAgICAgICAgICAgICA8dHNwYW4geD0iMTAiIGR5PSIxLjJlbSI+aG93IFNWRyBjYW4gYmUgYWJ1c2VkPC90c3Bhbj4KICAgICAgICAgICAgICAgICAgICA8dHNwYW4geD0iMTAiIGR5PSIxLjJlbSI+Zm9yIFBoaXNoaW5nIGF0dGFja3MuPC90c3Bhbj4KICAgICAgICAgICAgICAgICAgICA8dHNwYW4geD0iMTAiIGR5PSIyLjVlbSI+Rm9yIG1vcmUgaW5mbyB2aXNpdDo8L3RzcGFuPgogICAgICAgICAgICAgICAgPC90ZXh0PgogICAgICAgICAgICAgICAgPGEgeGxpbms6aHJlZj0iaHR0cDovL2d1eWEubmV0IiB0YXJnZXQ9Il9ibGFuayI+CiAgICAgICAgICAgICAgICAgICA8dGV4dCB0ZXh0LWFuY2hvcj0ibGVmdCIgeD0iMTAiIHk9IjE2MCIgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtd2VpZ2h0OmJvbGQ7Ij5odHRwOi8vZ3V5YS5uZXQ8L3RleHQ+CiAgICAgICAgICAgICAgICA8L2E+CiAgICAgICAgICAgIDwvc3ZnPgogICAgICAgICAgPC9nPgoKICAgICAgICAgPC9nPgogICAgICA8L2c+CiAgICAgIDxnIHN0eWxlPSJkaXNwbGF5OiBub25lIj4KICAgICAgICAgIDx0ZXh0PgogICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXkKICAgICAgICAgICAgICAgICAgZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teQogICAgICAgICAgICAgICAgICBkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICAgICAgICAgIGR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15ZHVtbXlkdW1teWR1bW15CiAgICAgICAgICA8L3RleHQ+CiAgICAgIDwvZz4KICAgIDwvc3ZnPgo8L3N2Zz4=)

While Chrome is the most vulnerable to the Space attack, other browsers will fall for it too.

FireFox trim the spaces when you click on the link, but an attacker will still be able to manipulate the status-bar (at the bottom of the browser). As we’ll see in the next vector.

**Safari **doesn’t trim the spaces but instead convert it to %20 or any other Unicode escaped representation of a space. It’ll work with any combination of unicode spaces.

**Mobile Chrome for iOS. ** It was a bit surprising to see that the Chrome version for iOS will fall for the “Over 28KB base64” attack.

It interesting to see that even Chrome for iOS which is very different environment, share the shell code with all of the other Chrome browsers.

**
Tricking the user to download malicious content using the DATA URI**

We already seen how one can abuse the browser’s address-bar and the status-bar by simply adding spaces after the “data:” in the link.

But what if we add any other character, other than space.  In that case, the users will be prompted to download a file (by default the user won’t be prompted and the file will just download)

How convenient for an evil one. Combining that with the previous stuff…

The user will see data:http://google.com/graphics/doodle.svg in the status-bar, clicking the link will automatically download the attacker’s malicious SVG file that is hiding in the base64 code inside the link.

Click to download doodle.svg (not really a doodle)

As noted before, FireFox trim the spaces after the “data:”, but one can use %20 instead. Also, FireFox does a good job and put an ellipsis in the middle of the link in the status-bar. So the user will see the suspicious gibberish base64 at the end, But that can easily overcome with simply adding spaces at the end of the link as well.

Click to download doodle.svg (FireFox version)

The interesting thing is that this kind of attack doesn’t limit us to SVG, any kind of file can be downloaded this way, any kind of binary file as well.

How about an EXE (that EXE does nothing but to echo some text to the terminal)
(Will add it latter)

Remember COM executables? Only few bytes, 32bit windows will still run it, still many of these are out there.

COM executable

ZIP is a great bad vector IMHO

ZIP with badies inside (not real badies just text files)

While on windows an attacker will also need to trick the user to change the extension of the file or to make him “Open With…” the file with a certain app. On the MAC these extension doesn’t matter much.

The file will be opened or executed according to its real type.

The new Mac OSes have this great feature called Gatekeeper that makes running applications way more secure in general.

The default settings is “from app-store AND identified developers”. How difficult is it for a motivated attacker to become an “Identified Developer”?

If the user have disabled Gatekeeper the app will just run when clicked.

It will probably work on old macs, but anyway I think that the most dangerous attack will be using just a zip file with all kind of badies inside.

The user flow might be:

1. Click on a link -> File is immediately downloaded (there is no wait as the file is already embedded no the page)
2. Click on the downloaded file -> file is automatically extracted (if the zip is small enough the user won’t notice much going on as the extraction will be fast)
3. Malicious apps will be spread all over the user’s Downloads folder.
4. “Hopefully” one day the user will notice these apps and its inviting names and will run one of these – thinking he downloaded it himself.

These are most of the browsers I’ve tested on, other browser may behave differently, generally it works the same on ubuntu as well.

IE (Internet Explorer) – does not suffer form most Data-URIs flaws, it does it by not supporting most of its features.  I don’t think that getting away with it by not supporting it is generally a good thing.

**Final notes about these vectors: **(repeating some from the previous post)

1. Remember that no JavaScript is needed for any of this, all that is needed is a link. It’ll work just the same with JavaScript disabled.
2. No server is involved either.
3. All an attacker need is a bunch of strings and the user’s browser will do all the rest.
4. AV won’t scan these links.
5. Not easily blockable – no domain to block.
6. More easily shared and distributed.
7. The attack is also cached in the browser history and doesn’t need Internet connection to be present at the moment of the attack.
8. Will propagate across devices. For example, if you’re signed-in into Chrome the attack will propagate to all of your devices. (You’ll still have to run it on each device though, just type data in the address bar).
9. Can be easily embedded in the naively looking *.URL file. Who doesn’t click on these? It always felt safe.

— Reported the bug to Google.

SVG files are like little bundles of joy. Encapsulating graphics, animations and logic. One can write a full app or game all encapsulate in one SVG file. That SVG file can be compressed into a binary file with the extension of SVGZ and browsers will still accept it.

Its way less powerful than Flash but the concept is similar – vector graphics and logic in one binary file. And like Flash SWF files – these files tend to get viral and to be re-distributed. And by that I mean, once you release your attack in the wild it can get hosted from many other servers. A good example would be, tiger.svg.

Remember the lovely Flash dog?  It can work just the same and even worse.

SVG also run from local files. By default, on Windows, SVG files are opened in IE, which will run the script with local privileges when it’s double clicked. 

Anyhow, SVGs have some flaws built in into them; many are known some are new. I will argue that even without the new flaws an SVG file is somewhat dangerous by-design. I wanted to see how easy it would be to abuse SVG for phishing. I picked an easy target – Chrome’s “Sign In” page. It was pretty easy to create an almost fully functional version of the Chrome Sign In page.

Check it out only 5kb of SVG “Image”

Compressed as an SVGZ, only 2kb (Chrome will run it just fine) 

Note: Google already changed the appearance of this page, but it almost identical to the previous version.

This page is generally here  (google already changed the way it looks)

Letting SVG files execute JavaScript is actually the root of the problem. I’m not sure it serves any real purpose in today’s web.

A simple attack might goes like this:

• The attacker will send the victim an email with a malicious SVG file “Checkout this cool image / animation”.
• The victim will downloads the SVG and click / double click on it.
• SVG is opened in the browser.
• Attack taking place.

The JavaScript that will run will have local privileges and can easily attack the user (limited to the browser sandbox of course). It can for example – execute multiple cross-domain CSRF attacks (cookies are sent normally with every requests) and/or load multiple other attack vectors. Can be abused for spam, and that is not even illegal as long as long as the attacker doesn’t do anything too malicious.

You may be thinking “so what?!” you can script the user from an html page just as well.

There are few differences, as most users will look at SVG file as just another image.

1. When you double click on an image to view it can’t execute anything –SVG can.
2. SVG files get redistributed – there are numerous clip art sites that will host the evil SVG for the attacker.
3. The malicious code embedded in SVG files will sustain after editing the file in graphic editors like Adobe Illustrator and Inkscape.

I would say that the main problem here is not what SVG files are capable of doing, and it’s more about the way they can get malicious code slip through the user’s normal defenses.

Wait there is more…

**
Even more fun with SVG and HTML5 Data-URI**

Another great feature of HTML5 is Data-URI. Now, SVG is working great with Data-URI. Malicious SVG works amazingly great with data-URIs.

SVG encoded, as Base64 will run directly from a link.
Some might call this a feature but it can be exploited for phishing attacks.

POC of an SVG phishing attack embeded in an HTML5 Data-URI

Some of the attacker benefits are:

1. This is just a link, no need to host anything.
2. AV won’t scan these links.
3. Not easily blockable – no domain to block.
4. More easily shared and distributed.
5. The attack is also cached in the browser history and doesn’t need Internet connection to be present at the moment of the attack.
6. Will propagate across devices. For example, if you’re signed-in into Chrome the attack will propagate to all of your devices. (You’ll still have to run it on each device though, just type data in the address bar).
7. Can be easily embedded in the naively looking *.URL file. Who doesn’t click on these? It always felt safe.

Everything said here is valid to all Data-URIs supported formats; notable is also text/html:
Here is an example

Actually Data-URIs have their own set of problems, which are not necessarily related to SVG. It works perfectly with SVG but the issues are more general. I’ll elaborate more in another post.

More about the demo (Chrome Sign In)

I don’t want give too many ideas for the bad guys, but the possibilities here are endless, I can already think of far more nasty vectors than this demo.

This specific demo has an image of the Google logo. I managed to create the Google logo as an SVG in about 7kb, but the Google logo in the demo is anyhow small and not too noticeable, it felt like a waste of KBs.

I found that the font used be Google for their logo is catull, which is an old style serif typeface, and is similar to … you guessed it… Georgia, that was good enough. Georgia is preinstalled on all OSs.

I know that might look horrible to fonts and esthetics lovers, but the average victim will easily fall for it.

One of the most important features of this attack is the SVG text-input. The user will need to enter his credentials somewhere.

Text-inputs are not natively available in SVG, though there were some attempts to create them.

I didn’t create fully functional text-inputs, didn’t think it’s appropriate for me to do it at this point – for various reasons. For one, I didn’t want to make it too easy to replicate this attack in the real. I’m sure that nearly perfect SVG text-inputs can relatively easily be created – one just need enough motivation.

What about mobile?

Smartphones are just fine with SVG, more on that later as well.

Some tip to keep you safe

1. Be alert when clicking on links that direct to SVG files or Data-URIs.
2. Don’t double-click on SVG files to preview it in your browser.
3. Don’t preview unknown or unchecked SVG files in your browser.
4. Don’t export SVG from Adobe Illustrator and Inkscape without knowing where it came from and making sure it has no malicious script.

These issues refer to HTML5 content running inside the native Android browser as well as  inside the native WebView (i.e. PhoneGap and alike)

———————————–

The promise of HTML5 is great, to be able to use the same code base on all clients and even on the server is really compelling.  While iOS has provided what it promise long time ago already – you can relatively easily create compelling HTML5 apps that will run on the iOS. Android HTML5 capabilities are still lagging far behind.

On paper Android 4.0.x (20.6%) was enhanced with many awaited features of HTML5. Similar to iOS 5. For example, Android 4.0.x was added with the important overflow:scroll, but, the Android 4.0 version is flawed. It has many other great features which are, sadly, mostly buggy. In fact this version is a buggy regression to the Android browser and WebView HTML5 capabilities.

It gets much better in Android 4.1, but this version still only holds only (36.5%) of Androids (48.6% including 4.2 & 4.3). Still today the most common version is 2.3.x which holds (44%) and that version can not be avoided. Generally, if you’ll try to push the HTML5 envelop of the Android it’ll probably push you back.

Even with the new and optimistic way of Google to measure Android versions distribution it’s still clear that 2.2.x and 2.3.x and 4.0.x are still massively out there and needs to be supported.

Having said all that, it doesn’t mean you can’t create decent apps with HTML5 that will run properly on the Android. But you’ll have to consider its lacking abilities from the get go. Design the UI as simple as possible, without too many fancy CSS, images, and animations.

I will put here a list of some of the issues I had to go through while adopting HTML5 on the Android, I will keep this list updated.

Canvas:
Pain: Android** 4.1 – 4.3** render duplicated HTML5 Canvas
Remedy: None of the parents HTML elements to the canvas should have overflow: hidden or overflow:scroll

Pain: In all Androids and especially 4.x canvas drawing performance are extremely reduced by using canvas effects like shadowColor.
**Remedy: **Try pre-rendering or adding the effects only when needed and/or once in every drawing cycles. For example, in a live drawing app – adding the effects only when the user stops to draw.

Network:
Pain: Android 2.x.x Making PUT (protocol) requests with no body will have no Content-Length header, it’s rejected by some servers/proxies i.e. NGNIX
Remedy: Configure NGNIX to accept it or send a {dummy: ‘data’} in the payload. i.e. $.ajax(‘PUT’, url, {dummy: ‘1’});

Pain: Android 2.x.x PUT (protocol) is cached on some versions of Android
Remedy:Cache-bust it, cache-bust all requests to the server even if it’s PUT.

Content:
Pain: Box-scroll was introduced in Android 4.0.x  but it has numerous issue on that version.
Remedy: Don’t use box-scroll for anything under than 4.1, or use iScroll or similar. The best, most performant, solution is to use postion:fixed for headers and footer and to simulate box-scroll.

Pain: CSS pseudo :active selector is not working on 2.x, working badly on 4.0.x.
Remedy: It is only perfect from Android 4.1 and above, try to use your own implementation using touch events.

Pain: Making fixed content (position: fixed) issues on 2.x.x
Remedy: Works fine only  when the ViewPort is not resizable, use this in the html head:
<meta name=”viewport” content=”width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no” />

Pain: Scrollbars shows over fixed content.
Reedy: When using a native shell, scrollbars can be removed using
webView.setVerticalScrollBarEnabled(false);
webView.setHorizontalScrollBarEnabled(false;

Pain: Jumpy text inputs
Remedy (native shell):
Remedy 2 : don’t use *{ -webkit-backface-visibility: hidden} or try to override it with *{ -webkit-backface-visibility:visible !important; }

Pain: Styling text-inputs that has focus
Remedy:http://stackoverflow.com/a/9464837/275333, http://java-cerise.blogspot.co.nz/2011/10/dodgy-double-input-fields-on-android.html

Pain: Android 4.0.x, any tap implementation will not be responsive enough, it will miss a lot of taps. (works fine with all other versions)
Remedy: Essiest will be to revert to clicks on this buggy 4.0.x version

Pain: In Android 4.0.x long press is selecting text, on all other OSs it’s resolved with the css *{ -webkit-touch-callout: none; }
Remedy (native shell): Use this Java snippet http://stackoverflow.com/a/11872686/275333

Pain: Duplicated Input fields on Android 4.0.x. it happens because android uses another native input for fast typing response, it doesn’t work well with scrollable content. (very ugly hack google, if I may)
There are tones of hacks for that out there, most of it doesn’t work or at least doesn’t work good across devices.
Remedy (native shell): If you run in WebView – Don’t put text inputs inside a scrollable iframe or content with overflow:scroll. Putting this in the activity will auto scroll to the text-input (similar to iOS) android:windowSoftInputMode=”adjustPan” – only works on Android 4.0.x, not working on Android 4.1 and above (yeah really).
adjustResize is working on all Androids I’ve tested, but that is less pretty and leads to jumpy inputs on older androids 2.x. adjustResize needs to be on the tags in order for it to work. I do not recommend that as well.
So to summarize the fiasco, adjustPan which give the best UX (similar to the iPhone) is only working on Android 4.0.x.
adjustResize which is still nice in terms of UX can be made to work with all versions of Android, but can cause issues (jumpy text-inputs) for old 2.x
Remedy 2: Put this style on the text input **-webkit-user-modify: read-write-plaintext-only; ** Not great since it’ll make typing slower, it’ll be up to impossible to enter text on some devices. Swype keyboard won’t work either.
Remedy 3: Shift the input element off the screen, and use the change event to render the text into another element. (this is too cumbersome, try to avoid it)

Misc:
Pain:HTML5 PushState is supported since Android 2.2, but somehow it was forgotten on Android 4.0 – 4.0.2 and some 4.0.3 devices. Told you these 4.0.x are cr*p…
Remedy: Make sure your HTML5 app works well for devices without pushState support. Try a 4.0 emulator.

Pain: Incorrect dimensions, sometimes innerWidth & innerHeight might still read 0 even after the DOM is ready.
Remedy:  Wait a few (~100 millisecond) after the DOM is ready to ask it what’s the window size is.
Remedy 2:Use screen.width & screen.height (you’ll have to calculate the toolbar height)
Remedy 3: get the width/height from the server (using something like wufl)
Remedy 4 (native shell):  Get the size from the native shell.

Pain: WebSockets are not supported at all.
Remedy (native shell): Use this WebSockets PhoneGap plugin. Don’t get bothered by sockets unless you really need to.

Pain: Web Workers doesn’t work at all
Remedy: Who cares..?!
**Remedy 2 (native shell): **Multi threaded, yeah baby.

Pain: Android 2.x misses a lot of scrolls attempt because it’s stuck in touchmove event (error is: “Miss a drag as we are waiting for WebCore’s response for touch down.”)
Remedy 🙁 No real remedy, I’m pretty sure there is no sulotion for that and using something like iScroll won’t solve it either.

Pain: DOM manipulation is extremely slow.
Remedy: documentFragments might help but don’t count on it.
You’re left with tricks, for example, It far smother to change visibility than to add/remove DOM elements.
It’s better to pre-render and just show() or hide() as needed, especially when animations are involved.

Some related links:
PhoneGap vs. Native: Some Thoughts on Going Native Discussion in Hacker News These are one year old but still very relevant (sadly)
Regarding point 1: Don’t remove images from the DOM, instead replace the src to a very small image (leason learned by the linkedin mobile team), 2: You can handle that, 3: There are good ways to do caching, 4: These days there’s reasonable debuging tools.

HTML5 for extending the device battery life (PDF)

Some other pains & remedies

** Epilogue: ** Everytime I come across a cool HTML5 example and wonder how well it tuns on mobile, I try it on iOS  and mostly like what I see. Only to be disappointed with the way Android native browser run it. And I’m not talking solely about the old 2.x.x androids that mostly run these in an unacceptable way. Even the newer androids with new version of the OS doesn’t play smoothly as the mobile safari or even UIWebView. The only solution to HTML5 on Android at the moment, is to keep it simple, very simple.

When targeting an HTML5 app to run on mobile browsers, one can not assume that  her users will use anything other than the native browser (as opposed to the more capable Chrome for Android, for example). But,  if your running your HTML5 inside a native shell (i.e. PhoneGap) There are few projects that attempt to solve the native WebView problem, by letting us bundle a better webview.
https://github.com/thedracle/cordova-android-chromeview
https://github.com/davisford/android-chromium-view
https://wiki.mozilla.org/Mobile/Projects/GeckoWebView More on these will follow…

1. Don’t jailbreak, a not jailbroken iPhone is a pretty secure device.
2. Use PIN code Settings -> General -> Passcode** **(and not something like 1234)
3. Make sure data is really encrypted – default since iPhone 4 (which have hardware encryption). If you have an older version go to Settings -> General -> Passcode and look for “Data Protection is Enabled” on the bottom.
4. Don’t install any profiles you’re not absolutely sure about. I saw that some ads company started to use these profiles in order to overcome the App Store restrictions. If you see something like this don’t approve it unless your absolutely sure. Here’s some more info about the danger of malicious profiles.
5. Consider using alphanumeric passcode by setting “Simple Passcode” to “Off”
6. Don’t use Consider not using “Find My iPhone”. This is a trade off, “Find My iPhone” is really great tool for finding your lost phone. But, there is a 1 failure point which is your apple ID. Accessing it will gives attackers your exact position and an easy way to wipe all of your phone data.

Android

1. Don’t root your phone
2. Use a screen lock
3. Encrypt data – works better from Android 4.0 and above, might affect performance (it does not encrypt external SD card)
4. Use a security app like Lookout or AVast – it’s free!
5. Don’t install an app unlesss you have decent amount of confidance in it, also check the permisisons it requires. Remeber to uninstall it if it’s useless.

We all know that Android is open and its apps needs no approval, which make it more vurenable by nature. This openness has another aspect of vurnability, external SD cards will have variant quality and because of that the Android OS doesn’t encrypt it. It can’t promise a good enough performance on cheap external memory. Which make sense in a way, your somewhat compromising security by being open.

Windows 8 Phone
Never had a windows 8 phone only 7.5, but it’s obvious that Microsoft is batting big on their most loyal enterprise consumers, that need enterprise security. From reading online it seems that it has a built in encryption but not for the SD card (same as Android).

Common sense still applies.

1. Use screen lock 
2. Encryption is built in for you, just don’t save anything important on the external SD card.

Linkedin had the better hybrid mobile app (HTML5 + native) and published a series of videos and articles about how they successfully did it with a team of “just” 5 developers.
Admittedly Linkedin app was really nice, but, after learning more about the internals of their app I’ve realized it wasn’t perfect.
For example the way they manage the application cache is not as good as the HTML5 app-cache that just works well out of the box. Using the term “it wasn’t documented” is not a good enough excuse, it was working well long before the debute of their app.
Also, their infinit scroll is just a not so infinit swipe, etc’

Anyhow, it appears that linkedin, similar to her bigger sister Facebook, ditched its mobile HTML5 in favor of native.
Linkedin senior director for mobile engineering Kiran Prasad claims are that there is not a good debuger and no performance measuring tool.
Firstly the debuggers are getting there every day (there are many more).
Secondly, profiling in the desktop and mobile Chrome will give you a general idea where memory is going. Profiling hybrid apps in iOS6 is also available.
I don’t think that these are really the reasons, they simply needed a stronger platform and HTML5 became too difficult to scale to their needs. That’s reasonable, mobile HTML5 is definitely not for everything.

Yet, the promise is still here – use the same code base and the same web development skillset to deploy for: native apps for mobile, browser apps for mobile, cross platform for the desktop (also outside of the browser), and so much more.

So why mobile HTML5 is not there yet? I’ll outline some of the main reasons here:

1. It’s not realy the same web development skillset
Well it is in a way, for the simple stuff it is still mostly HTML, Javasctipt and CSS. But, even for the simple stuff, things that works just fine on the desktop browser can greatly affet smoothness, battery consumption, memory usage, and eventually crashes, when used in mobile.
Every bit of code needs to be perfected in order to maintain the user experiance. Not even talking about specific glitches in specific versions and OSes.

2. Android – when it comes to HTML5 Android sux big time.
iOS had good HTML5 support from the get go. It reached full maturity from iOS 5 which is currently all that is needed to cover the great majority of devices out there.
Android on the other hand only reached HTML5 maturity with version 4.1 which is less than 25% and going up slowly. The notorious Android fragmentation is affecting HTML5 as well.

3. HTML5 apps doesn’t easily scale in terms of features
You needs to be vigilant about every piece of code that is added.
For example, adding just a small feature like an image or a text to every item in a list can greatly hurt performance.

4. HTML5 apps doesn’t easily scale in terms of crew
You needs to be vigilant about every piece of code that is added.
In order to deliver the promise of same code base in all mobile devices and in the desktop you firstly need that all of your crew will be highly proficient. Mobile HTML5 apps can easily be ruined.
Secondly if you want that code to be used in the desktop as well, you need a greater level of harmony between members.

5. Product ppl want stuff they see on other apps.
Some of these stuff are very easy to create nativly but are extremly painfull when created in HTML5.
Product ppl needs to better understand the technology that is used.

6. Native is not that hard to do
At the end of the day wrting native apps for iOS and Android is not that difficult, it’ll be easier than HTML5 in many cases.
It’s way more diffuclt to ruin the smothness in native UI though I see many apps that manage to achive that.
An avarage native developer can easily achive good user experiance.
When writing native you can get a way with poorly written apps. Even if you will make the UI render itself 10 times more than it really needs to, you can still achive good user experiance that will satidfy most users.

7. Peer presure, don’t be a chicken
Some idiot with a rooted and very old phone, will install Android 4.0 mod (worse Android OS for HTML5). And than will start to whine that things don’t work smothly.
– That’s not even a real phone, idiot.
Announcements from facebook and linkedin ditching HTML5 in favor of native lowers the moral of HTML5 supporters and help “classic” developers that are intimidated by stuff like javascript to raise their heads.
What?! Can’t you write it in native what are you chicken – nobody ever calls me chicken (btw, this is how we’ll be in 2 years)
You will (almost) always have doubts about switching to native.

∞. It’s not over, it’s barely just begun
Don’t be let down by facebook and linkedin moving to native, it’s always depends on the type of app, resources and the kind of people involved.
Mobile HTML5 apps are deliverable and in good quality for some time already.
You will gain the benefits mentioned above of same codebase and skillset along with way better deployment model.
Done right, you can deploy new app versions like deploying a website. Without the need for approval, and without sacrificing much user experience.

The bottom line is that mobile HTML5 is here for somewhat long time already, but it’s not for everything and definitely not for everyone – yet.

Anyhow, in that same techcrunch article you can also find that “The FTC also took the opportunity to introduce a new set of guidelines for mobile developers“. Although they explain early in that article that it’s not meant to be a guideline, I still feel they misses a lot.

When it comes to HTML5 apps even the simplest app can greatly compromise the user privacy and security. If we’ll take the FTC example of a simple and harmless alarm clock app, If that app is built using HTML5 its size and complexity doesn’t matter. All that is needed is one javascript injection that will pass thorough.

How will that code be injected you may ask – all that is needed is for the app to load some content from a remote server the simplest example will be the “Terms And Condition” page which is mostly loaded into a WebView. It can be a more “complex” settings, like choosing the favorite color or loading the saved alarms. Any kind of sharing will probably be way more open to be exploited, i.e. “share your favorite alarms”. Push messages might also bring malicious code. ETC’

The bottom line is that any injection of javascript will give an attacker a lot of control over the device, more often than not it’ll be persistant. HTML5 apps usually use the localStorage that is rarely flushed, and leverage native DBs and the file system. The “page” or webview is rarly refreshed, so even if the injection is not persistant it’ll be alive for a long time.
Things like stealing the user’s contact list and tracking the user location are pretty common. Enabled by default in iPhone PhoneGap for example.

It’s only limited by the native API that is opened to Javascript, generally it’s very open, even more than the PhoneGap default API. I know of at least 1 popular HTML5 app that opens almost all of the Android native API.

You see, Javascript is one tough beast – it can run almost anywhere.
Javascript was designed basically as a none important sidekick to the browser’s HTML, “it should not cause any problems by being poorly written and should fail silently and not interfere with the main thing that is HTML.” Seriously that how it was, we’re lucky it’s not case insensitive. I’m sure that back than some people though it’ll make it simpler and better.
So, Javascript will run in any dom element no matter how naive you may think it is, it will run in unexpected parts of the element without needing the <script> tag, i.e. onerror=”attack()”. It used to even run from CSS and from images, but we’re over that now asfaik in mobile browsers.

As opposed to that, it’ll take a very special case for injection to be able to execute arbitrary native code. You can make a native android app that will run anything – even get root, but I doubt that any legitimate app regularly download strings and run it as commands. (basically on rooted Android you can do exec(“su”) and everything else)

With Javascript the app does not need to be designed in any special way, an unsanitizes string will likely to execute.

These kind of injection are not the sole problem of PhoneGap based applications.
Any app that uses HTML5, even if it’s mostly native, any API that is opened to javascript can be leveraged by an attacker.

Phonegap (Cordova) has a mechanism to white list remote hosts which is really only effective on the iOS. It adds a little bit of security, but many apps anyway uses a wildecard “*” to allow all hosts. The wildcard is used by default in the phonegap cloud (saas solution to build phonegap apps)

As you can see the option for an attacker are enourmoe, all it needs is one vector of injection and there is an open path (no phan) to take over all of the devices of all of the users.

HTML5 apps that runs inside the mobile browser are also a nice target for injection attacks, althouygh it’s lacking most of the native api, there is still access to location in all mobile browsers. It’s less powerful for the attacker since it’ll prompt the user way more vigusly.
The Dolphin Mobile Browser implement the full phonegap native api, for example (which is generally a good thing), but it makes in-the-browser websites and apps more exposed to attacks.

So what to do than?!
– Sanitize sanitize sanitize all user input, server and client!

This flaw is very much similar to the well known and very old picture-in-picture
More info.. IMHO the old version is still way more dangers for phishing.

So How Flash is more secure?

What enables this HTML5 fullscreen flaw to exist in his prime is the fact you have full keyboard access. This way an attacker can more easily steal the user’s credentials.
After all fullscreen was existant in Flash for many years now, yet it was never compromised this way. The main reason is that Flash is more secure is that it does not allow full keyboard interaction in fullscreen.

Good thinking Adobe, taking care our security… oh wait… Flash was added with this feature with version 11.3… after all Flash can’t be left behind…
Working demo…

Damn… but still Flash gives you a decent popup confirmation which HTML5 doesn’t

Yeah, I know Chrome give you a popup too, but **you don’t have to click on it to get FULL keyboard access.
**I constructed this “amazing” demo here (chrome only), as you can see you get the message but the keyboard is fully functional and accessible through javascript.

****

So still Flash is more secure than HTML5 – in that respect.

It takes us back to what me and other were preaching about, that with great power comes great responsibility.
HTML5 have its own flaws and the more powerful it’ll become it will get even more.

Stay tuned…

Last Android I used a lot is the Samsung Galaxy Nexus, it has an impressive 720 x 1280 pixels, 4.65 inches screen, and overall a very nice spec. But overall it’s a bad phone. I was totaly not impressed by it. It only become good with the Android 4.1 Jelly Bean update (only 1.2% of Androids). Google even use this phone in the Gelly Bean screenshots.

Developing mainly for mobile, I have an iPhone 4S laying around, I knew the iPhone is better but didn’t want to switch yet because I was used to the Android ecosystem, the great Gmail app and the way it sync everything nicely – this is  an area where the iOS is still lacking.

I always postpond it saying – I will switch with the iPhone 5.

But, one day it happened, I stuck my sim into the 4S and never looked back.The small screen got some time to get used to, but after a short while, you realize its qaulity is far superior than anything else.

When I first saw the leaked iPhone case I was a bit shocked – it can’t be only that, it’s exactly the same just a bit longer. If this is for real than Apple might be in trouble. Then I relized, it doesn’t matter if that only what we get, it’s still gonna be the best phone. The iPhone 4S is already the best phone, so any improvement of that is still the best phone.

Yeah, there is the note with the huge screen, and the S3 is impressive, but still these are niche phones.

Apple will not be able to go on forever with improving what they already have, they will have to reinvent the wheel – again. Hopefully that will arrive as well.

I’m still excited about every new Android version and device, but for now I’m on an iPhone.