You are an expert at summarizing long articles. Proceed to summarize the following text: 
it was game theory research , seeking screening strategies to prevent the counterfeiting of websites i.e. phishing attacks . various ways for websites to counterfeit installed software behaviour were studied . in full screen mode , it was found that , browsers can counterfeit almost anything , including blue screens of death and formatting the hard drive . this is discussed in section ii .    from an academic point of view , full screen counterfeiting eliminates several categories of installed software behaviour , as possible anti - counterfeiting solutions . one category of installed software behaviour was resistant to counterfeiting . in section iii i present an explanation of this category from the discipline of cryptography and another explanation from the discipline of game theory . every solution , in that category , was found to be a user - browser shared secret . basically mallory can not counterfeit what mallory does not know . the user - browser shared secret is not known by either bob or mallory . this means a user - browser shared secret can be used to extend tls to seek further authentication of bob by the computer user . on successful verification of a tls certificate s digital signature , the browser presents a dialogue , fig . 1 . mallory can not counterfeit this dialogue without hacking in , to steal the shared secret . the computer user now authenticates ( 1 ) her browser dialogue and ( 2 ) bob , by accepting the shared secret and bob s identity credentials which came from the tls certificate . acceptance of these two proofs of identity is communicated by the user entering her login credentials .        in section iv the possibility of bob authenticating alice was studied . my research found that the absence of trent in this process means that alice must authenticate bob first , during account setup . this makes alice authenticating bob more important than the other way around . at this point i returned to researching alice s authentication of bob .    our total dependence on alice authenticating bob requires us to make this act as straight forward as possible . the final solution proposed is a mixed strategy of ( 1 ) a user - browser shared secret to facilitate extending tls , for alice to authenticate bob , ( 2 ) standardisation of the login process via a browser created login window , ( 3 ) using central banks as trent for financial institutions and ( 4 ) utilisation of common knowledge and education to guide alice through the process i.e. to prevent phishing attacks alice must fulfil her role and authenticate bob . the idea is that a phishing attack is a game of incomplete information . that the user does not even know that a phishing attack is taking place . it is the successful counterfeiting of the website that does this . if we can devise a signalling strategy which can not be counterfeited then the computer user will know when a phishing attack is taking place . they will back away from the phishing website causing the phishing attack to fail . the idea was to add information , specifically an anti - counterfeiting signalling strategy which would be triggered after the browser has verified the digital signature on bob s tls certificate . i listed behaviour that installed software is capable of but websites are not capable of . the idea was your browser is installed software so it has this advantage over websites trying to counterfeit its behaviour . the following categories were proposed for research :    1 . drawing outside the browser canvas area . 2 .   creation of modal windows . file manipulation e.g. file creation , copying , renaming etc . this includes the possibility of formatting the hard disk , though we ca nt use that as evidence either . access to local data and operating system identifiers e.g. your username , your account login picture or whether or not you have accessed this website before . microsoft , user account control behaviour . 6 . existing best practice i.e. inspection of the tls certificate being used by your browser .    in my original research i dismissed or counterfeited every category except number 4 . every solution in category 4 is actually a secret shared between the computer user and their web browser . category 4 is discussed below in section iii . originally i dismissed category 3 believing it to be unworkable . however references [ 3 ] and sitekey [ 5 ] both use cookies to trigger their solutions . cookies actually fit category 3 . this is discussed further in section iv . a key component of this research was the study of screening strategies . while it was not my intention mallory , the counterfeiters , never wanted screening strategies to work . effectively i was researching an arms race where mallory would keep changing her behaviour to prevent my screening strategies from working . section vi outlines one interpretation of that arms race . the actual path that i followed was to study the categories listed above . there is no point in me documenting that research here because it is quite similar to discussions of screening strategies found in [ 1 ] and [ 2 ] . one phishing attack website that i stumbled upon requested a username and password . even though the genuine website was open access . this type of phishing is more social engineering than counterfeiting . during my research the most versatile type of phishing i stumbled upon was full screen counterfeiting . about ten years ago browsers stopped the javascript function window.open() from creating completely undecorated popup windows . the function still works , however an address bar is added to the window , as shown in fig . 2 . without this it would be easy to counterfeit browser controls and inspection of the tls certificate.        within the past few years a fullscreen api has been added to html 5 / javascript . it s still in development so browser specific function names exist like mozrequestfullscreen ( ) and webkitrequestfullscreen ( ) . once a user performs an action which results in this function call , the browser switches into full screen mode . the transition to full screen happens whether or not the user has been warned in advance . yes the browser will show a warning , after the transition . however each browser has its own warning windows and websites can query your browser and deliver the appropriate counterfeit . 3 shows a firefox warning . the thing about social engineering is that almost anything goes . consider a criminal harassing a user with warnings , like that shown in fig . 4 . once the user is accustomed to hitting allow , the criminals can request full screen mode and hope the user falls for it . after that they can counterfeit the entire computer desktop , blue screens of death etc .                        for example , fig . 5 shows six bitmap images . they are deliberately drawn to look fake . when assembled correctly they mimic a desktop . 6 shows a computer desktop just before a full screen counterfeiting attack . once the user clicks on a button which executes javascript . the requestfullscreen ( ) function is called , along with code which alters the webpage to show the fake browser , and desktop , controls . this turns fig . 6 into fig . note the substitution of the bitmaps from fig . 5 for the genuine browser and desktop . if the user does not notice that the warning message is different they may click on allow. there are a number of differences between the harassment window and the genuine warning window . along with the message being different the harassment window can not grey the entire desktop , nor can it be drawn at the top centre of the screen . if the bitmaps used in fig . 5 were realistic then fig . 6 and fig . 8 would be almost identical . furthermore fig . 7 would only appear odd / unusual because the greyed area extended beyond the perceived canvas area and because the warning window appeared outside of the perceived canvas area . these are very weak indicators of counterfeiting .    from a researchers point of view many types of installed software behaviour can be counterfeited . including browser addons , inspection of tls certificates , and microsoft user account control behaviour . as such categories 5 and 6 must be eliminated as suitable anti - counterfeiting solutions . furthermore we now need to be concerned with counterfeiting of blue screens of death , hackers / criminals blackmailing people with the threat of formatting their hard drives etc . the purpose here is to demonstrate these mechanisms . no user testing has been performed . the academic exercise of demonstrating that this is possible is sufficient to eliminate categories 5 and 6 . there is anecdotal evidence in [ 7 ] that these tactics will work .    in the short term best practice can be changed to ( 1 ) hit escape to exit full screen , ( 2 ) click on the padlock symbol and ( 3 ) read the tls certificate details window , to ensure you are connected to the correct website . also we can roll back the full screen api , just like the undecorated window functionality . i believe the system has been mistakenly identified as a two actor system . when , in fact , a third actor is present . the failure of tls to force proper authentication of bob allows mallory to masquerade as bob , to counterfeit his identity i.e. phishing attack . you might argue that the two actor model is incorrect , that users check for the presence of the padlock symbol . if they did then phishing attacks would not exist , or the conflict would escalate as outlined in section vi .            fig . 9 shows a schematic of the existing two actor model and my three actor model . to distinguish between the actors in the two models i have given them different names , as shown . in the existing system alice - browser verifies the digital signature on bob s tls certificate . on success alice - browser and bob proceed to implement tls . in my model hal - browser verifies the digital signature on bob s tls certificate . on success hal - browser turns to alice - human and invites her to further authenticate bob . he does this by displaying a window like that shown in fig . the problem is : this act is vulnerable to counterfeiting . in this context counterfeiting is referred to as a phishing attack .    shown in fig . 10 is a picture of a turtle which is a shared secret between alice - human and hal - browser . neither bob nor mallory know this secret . as such mallory can not counterfeit fig . 10 without hacking into hal - browser to steal the secret . hacking into thousands of computers to steal these secrets is an entirely different endeavour to tricking people into going to a fake website .    once you correctly model the system as a three actor system . cryptographers know how to appropriately authenticate the three participants . as such fig . 10 is a relatively obvious step for cryptographers . dhamija et al also use a user - display shared secret . they use it to protect a dedicated login window from counterfeiting . they do not appear to go beyond that and use it to present bob s identity credentials [ 4 ] . with my solution , by entering her login credentials alice - human is accepting bob s identity credentials and her browser s shared secret . she is authenticating both bob and her web browser . hal - browser then proceeds to implement tls . hence fig . 10 extends tls to ensure proper authentication of bob by alice - human . alice - human now knows she is looking at a dialogue created by her web browser i.e. it is not a counterfeit , a phishing attack . she can now examine the identity credentials presented and complete bob s authentication . i was approaching this as a game theorist seeking screening strategies to prevent counterfeiting . here follows an outline of the game theory interpretation . anti - counterfeiting technologies and the screening strategy that accompany them go together like a lock and key pair . the research involved the study of each category , from section ii , to find screening strategies which would prevent phishing attacks . the definition of a screening strategy , from [ 2 ] is given since its language is used to frame the discussion that follows . from [ 2 ] : _ a screening strategy is a strategy used by a less informed player to elicit information from a more informed player . _    human interactive proofs ( captcha ) , turning tests and anti - counterfeiting technologies are all specific types of screening strategy . here too authentication , through the confirmation of a shared secret , constitutes a screening strategy . the less informed player is eliciting the identity of the more informed player . they are not eliciting the secret because they already know it . they want to know do you know what the secret is? this is why it s just a point of view that this is cryptography . as a game theorist i see a screening strategy . it elicits their identity , as the individual who knows the secret or someone else . furthermore , the fact that this works while other approaches fail indicates phishing attacks involve the counterfeiting of an identity , not a website . this is significant because it allows us to prevent any type of counterfeiting . it recasts counterfeiting as theft of intellectual property , patents , copyright , trademarks , designs etc . accompanied by identity theft . the purpose of the identity theft is to undermine law enforcement attempts which would otherwise prevent the intellectual property theft . this means authentication based solutions can be developed for any type of counterfeiting including manufactured goods like pharmaceutical drugs and currencies . references [ 3 ] and sitekey [ 5 ] both utilise cookies to trigger mutual authentication . in both cases , the cookie is used to authenticate hal - browser to bob . bob then presents his shared secret , seeking authentication from alice - human . this behaviour resides outside of the shared secret category of solutions , just discussed . it s subtle , but this is a new category of behaviour which is resistant to counterfeiting . as a machine hal - browser can discern the difference between identical websites . he can then treat these websites differently , even if we humans ca nt see the difference . all solutions in this new category involve the web browser differentiating between websites and then responding in an installed software manner , which is not vulnerable to counterfeiting . here follow our two examples :    1 . browsers correctly returning cookies to the websites that created them . 2 .   browsers correctly volunteering saved passwords for the websites they belong to .    for the solution presented in fig . 10 our browser responds with installed software behaviour which is not vulnerable to counterfeiting . however that response is not specific to each website . both cookies and saved passwords require the browser to distinguish between websites and provide a response which is specific to that website .    to develop a mechanism for bob to authenticate alice , consider the following thought experiments .      on account setup a bank can create a login page which will trigger the browser save password facility . now the bank specifies both the username and password . the password should be very high entropy , impossible to remember by alice - human . the idea is that the browser will remember it . since the browser can distinguish between websites it will never enter the data into a phishing website . create a cookie with a high entropy code stored inside it . this is equivalent to the password idea , just described i.e. the browser only hands over cookies to the websites that created them . the cookie could be created with multi factor authentication e.g. a code could be sent to alice - human s mobile phone . both solutions are equivalent and they are both vulnerable to the same kinds of attack . i refer to this as cookie as certificate since these solutions use cookies as a poor man s certificate . to identify hal - browser to bob . both [ 3 ] and sitekey utilise cookies as certificates . the thing is , they do nt have a secret private key and they do nt have a digital signature . basically they are a number , a password . all they have going for them is that the browser will only hand them over to the website that created them . mallory simply attacks the cookie creation process . while various solutions can be presented they tend to look like an arms race e.g. mallory could try a brute force attack generating lots of cookies . bob will respond in the usual ways .    on closer inspection , the asymmetric nature of tls makes it easier for alice - human to authenticate bob , than the other way around . alice - human can trust trent and proceed accordingly . in bob s interactions with alice - human no third party ( trent ) is vouching for anyone . for bob to use a cookie , he must create that cookie as part of an account registration process . whatever process is used , it will always be vulnerable to attack by mallory unless alice - human correctly authenticates bob during that account registration . basically , without trent , bob can never authenticate alice - human without her authenticating him first . the cookie creation process will always involve alice - human authenticating bob or it will be vulnerable to mitm . hence bob can not authenticate alice - human without her authenticating him first . this makes bob authenticating alice - human less important than the other way around . this is because tls is asymmetric . alice - human can enjoy the use of tls certificates . the user - browser secret combined with the tls certificate is fig . 10 . that s all alice - human needs . if alice - human will always authenticate bob first then its academic how bob authenticates her . codes , pictures , mobile phone , email , it s all the same . he might as well just ask for a username and password . it s up to her not to type her credentials into a phishing website . the responsibility always falls on her to properly authenticate bob first . after that it s academic if he accepts a username and password or some convoluted dance . effectively this breaks the use of cookies as an anti - counterfeiting mechanism . yes they are an effective solution . however they are dependent upon tls and fig . we re actually going in the wrong direction . instead of worrying about bob authenticating alice - human . we should focus more on actually getting alice - human to authenticate bob . the original idea was quite similar to [ 3 ] and sitekey , however it was abansoned , as outlined above . basically an out of band , multi - factor authentication technique could be used to create a cookie e.g. send a text message to alice - human s phone . 12 would need to be used to create the cookie , just to ensure tls is actually being used . even then it would still fail i.e. this system is vulnerable to all the attacks that work against sitekey and users would only see fig , 12 once every three , or four , years . the reason why its a nice solution , why it s inclused here . is that mallory would not be able to get the login screen up without the cookie . so even if mallory has successfully harvested correct usernames and passwords , she would still need to create the cookie to get the login screen up . its possible this solution will still be implemented , however , computer users still need to authenticate bob . there is no getting away from this . this is the cookie as username idea . 11 shows fig . 10 with this additional solution implemented .    . hence fig . 12 . note the shared secret is now a photo of a ruler which lookes like a giraffe . ] before i dismissed cookies i tried to overcome their shortcomings . fig . 12 is a mock - up of a browser created dialogue for the creation of a cookie . sitekey , [ 3 ] and the cookie as username idea all require fig . 12 to ensure a mitm attack is not used .        since alice - human will only see this dialogue once every three or four years , this solution will fail . to overcome this problem we need alice - human to be educated in the art . since it s not practical to force people to take lessons we need another way . the counterfeiting of currencies is hindered through common knowledge i.e. people use genuine bank notes every day . when they encounter a new note their everyday knowledge will aid them in evaluating that note s authenticity . in the same way fig . 10 will become common knowledge . effectively krugman s theory of passive learning [ 8 ] . clearly passive learning and low involvement consumer behaviour are beyond the scope of this paper . the ideas outlined here need to be combined with user studies like [ 7][9 ] and academic work in the field of education and passive learning .    to educate alice - human , in the art , we can make fig . 10 the second page , in a login wizard . the first page can be used to present messages which will slowly educate the user e.g. fig . 13 and fig . 14 . effectively this passive learning approach will make the required knowledge , common knowledge . the idea is to meet users half way i.e. we should adjust our authentication solution to make it more accessible . and we should aid users in its use . where flaws appear the solution can be assessed to ascertain why the system failed . if the authentication mechanism is flawed we can alter tls , if users are being tricked by some aspect of the system , we can adjust both the educational messages and the login process till they can discern genuine from counterfeit . dhamija et al found that some users did not know this type of fraud was possible . some users accepted websites which contained professional looking images and distrusted websites which were plain i.e. few links and few images . some distrusted webpages which did not originate from the bank s main homepage [ 7 ] . misconceptions like this can be addressed with informational messages on wizard page one . informing and educating does not mean annoying , so a i know this check box could be added to remove educational messages that the user already knows . eventually just the login page will appear or questions during setup could also remove it . the existing system is unhelpful for many reasons . users must remember to click on the padlock to examine the tls certificate . even then , they do nt really know if www.bobsonlinebanking.com should be used rather than www.bobsonlinebanking.ie . trent should be an actual trusted third party . the public probably do nt even know the name of any certificate authorities . identities presented in tls certificates are de facto worldwide trademarks . they are these businesses shopfront . yet we put all of these brand names behind a picture of a padlock .      on inspecting fig . 10 alice - human needs to remember three things , her user - browser shared secret , trent and bob . her secret will be easy because it s the same for every website . once the phishers start attacking browser weaknesses associated with tls , alice - human will need to remember trent . so why not make it easy for her ? if central banks sell tls certificates to banks that operate within their regulation domain then those certificates can state that central bank s name as trent . hence european central bank , federal reserve , bank of england , bank of japan etc . will all appear as trent in their respective countries . now alice - human has less to remember . regular ecommerce sites can continue as usual with tls certificates bought on the open market . also the central banks can outsource the certificate creation process . so the certificate authorities will not be out of pocket , they just wo nt have their name in lights on fig . effectively this is an extension of the existing extended validation certificates idea . the central banks would end up authenticating the identity of these banks . this is precisely trent s role . tell users to search for the padlock .      with either commercially purchased tls certificates , or certificates they created themselves , the criminals can now display a padlock symbol . users are now told to click on the padlock and examine the tls certificate details to verify bob s identity . life is a lot more difficult for the phishers because they now need to trick users into full screen mode . however , once there , they can counterfeit anything . this gives them more options for theft / crime . authentication windows like fig . 10 are introduced and users are directed to only enter their login credentials into these login windows . hal - browser only displays the authentication window fig . 10 on successful verification of a tls certificate s digital signature . hence mallory can not persuade hal - browser to display the window without her own tls certificate . the criminals are likely to attack tls and browser weaknesses associated with tls certificates . anti - virus , private keys , shared secrets all have a role to play . alice - human s job is to complete bob s authentication . a mixed strategy of educating alice , making details of the process common knowledge and altering the authentication process can be used to bring alice - human into the process . at the end of the day , only alice - human can authenticate bob . phishing attacks are not the counterfeiting of a website but the counterfeiting of an identity . the research found the system to be responsive to strategies which protect the website creator s identity , whereas website content could not be protected . in fact , the research found that web browsers can counterfeit almost anything . the asymmetric nature of tls makes alice - human authenticating bob more important than vice versa . without trent , bob authenticating alice - human will always require her to authenticate him first , during account setup . otherwise a mitm attack will occur . this requirement undermines solutions like sitekey . the conclusion is that a mixed strategy is called for . a user - browser shared secret allows tls to be extended so alice - human can complete bob s authentication . the shared secret protects this act from counterfeiting , from phishing , since mallory can not counterfeit what mallory does not know . the login process should be standardised into a predictable login window . this makes details of the interaction common knowledge , guiding alice - human through the process . furthermore educational messages displayed in a login wizard will educate the public by making this knowledge common knowledge . this includes the possibility of central banks taking over the role of trent for financial institutions.the mixed strategy means meeting users half way. alice - human must fulfil her role and authenticate bob . we must make this task as easy as possible . protecting the authentication process from counterfeiting , through the use of a user - browser shared secret , using central banks for trent , standardising the login window , informing and educating users all bring us closer to alice fulfilling her role . s. schechter , r. dhamija , a. ozment and i. fischer , the emperor s new security indicators , 2007 ieee symposium on security and privacy ( sp 07 ) , 2007 . r. dhamija , j. tygar and m. hearst , why phishing works , proceedings of the sigchi conference on human factors in computing systems - chi 06 , 2006 . p. kumaraguru , s. sheng , a. acquisti , l. f. cranor , and j. hong . `` lessons from a real world evaluation of anti - phishing training '' e - crime researchers summit , anti - phishing working group , october 2008 .
phishing attacks occur because of a failure of computer users to authenticate bob . 
 the computer user s role , her job , is to authenticate bob . 
 nobody else can carry out this task . 
 i researched the ability of browsers to counterfeit the behaviour of installed software . 
 the objective was to find a signalling strategy which would protect against counterfeiting i.e. phishing attacks . 
 the research indicates that a user - browser shared secret can not be counterfeited because mallory can not counterfeit what mallory does not know . 
 after your browser has verified a tls certificate s digital signature the browser should create a two page login wizard . 
 the first page should display a random educational message , to inform and educate users about the process . 
 the second page will show the user ( 1 ) the user - browser shared secret , ( 2 ) the verified identity credentials from the tls certificate and ( 3 ) the input fields for the user to enter her login credentials . 
 the shared secret prevents counterfeiting , prevents phishing . 
 computer users can now authenticate bob by examining the tls certificate s identity credentials . 
 the educational messages will communicate to the user , the issues and pitfalls involved . on accepting bob , as bob , the user can enter her login credentials and login .    phishing attacks , game theory , applied cryptography , authentication , security protocols , human factors .