完整UI控制的即时应用。前面稍微介绍了一下即时应用，与微信的小程序类似，但也只是表面看起来类似，其实技术原理是有很大区别的。因为小程序毕竟只是微信这个应用中一个小小的功能，而谷歌的即时应用是针对于整个Android系统的。
完成这一整套即时应用机制大概有几个步骤：首先开发人员构建了一个即时应用，也就是他们应用的一个小功能版本，然后将其上传到Google Play商店。并且开发人员需要将这个即时应用与URL模式关联，也就是指向一个开发者控制的域名。这样做就是为了当用户浏览这种模式的URL时，Android框架开始下载和运行与这个URL模式关联的即时应用。然后为了安全起见，开发人员需要先向Google证明她控制的目标域名。这步是依赖于DAL协议[17]实现的。
即时应用在可用性上确实是有很多好处，但是也为攻击者的钓鱼行为提供很多便利。作者观察到，即时应用可以让攻击者的网络钓鱼转移到移动网络钓鱼。其实现在网络钓鱼是比较难真正被钓到的，因为（1）用户会看域名、HTTPS链接是否完成、SSL证书是否有效等等。但是在移动设备上，就缺少这些让你信任的指标。而且（2）那些像素完美攻击的关键就是要能够控制屏幕上所有的像素，而在网站上这一点是无法实现的。不过攻击者可以在即时应用上实现，就是要在浏览器的JavaScript沙箱外部的设备上执行代码，并获得UI的完全控制能力（无需请求任何权限）。
一旦攻击者获得完整的UI控制，就会有很多可能性了。就是不管是网页端还是移动端，你区分不开恶意的即时应用和真实合法的应用了，因为UI被完全控制了嘛，可以操作任何像素，所以表面就可以被做成任何样子。
所以接下来说的就是结合前面密码管理器的缺点和即时应用这个功能，在钓鱼攻击方面的实际情况。由前面我们知道密码管理器是可以被欺骗的，从而泄露用户的凭据，但是前提是受害者的手机上要有安装恶意应用。然后现在有了即时应用以后，就不用在受害者的手机上安装恶意应用，就可以欺骗密码管理器了。因为即时应用虽然不是完全安装的应用程序，但是确实会出现在Android框架和依赖它的组件上。并且目前密码管理器不能对完整的应用程序和即时应用程序之间做出区别。所以当即时应用受到攻击者控制的时候，密码管理器就可能被欺骗甚至泄露凭据。
首先说的是端到端的概念验证这种攻击。如图3所示，以用Facebook钓鱼为例。当你在访问某个网站时发现有一段来自于Facebook的文字你很喜欢，你想点赞，于是你点击like那个按钮，如图a所示，这个按钮是链接到与其即时应用关联的攻击者控制的URL的。当你点击完以后，就会触发即时应用，此时页面会弹出询问你是否确认启动即时应用的窗口，如图b所示。在这个弹窗中会显示对应应用程序的名称（就是Open With后面打码的文字）以及图标（就是名称左边这块儿，作者这里用的是白方块），但是这些名称图标啥的其实完全是受攻击者控制的。当你点击这个绿色的“打开应用”按钮时，就会开始自动下载即时应用，同时在图c中显示等待的视图，约一秒钟。此时，恶意的即时应用就已经在你的设备上运行了，如图d所示。由于作者的应用程序是使用com.facebook.*这种模式创建包名的，所以LastPass这个密码管理器会被欺骗，就会自动向你推荐你真实的Facebook凭证。当你点击弹出的这个自动填充的窗口以后，你的凭证就会完整地泄露给攻击者。这就是即时应用钓鱼攻击概念验证的一个大致过程。
然后作者讨论了一下他们这个概念验证应用的实用性。首先通过图3我们可以知道，只需要点几下就可以让攻击者获得凭据，其实我们平时不管是移动端还是浏览器端都会有很多类似流程的操作。其次作者还发现图b和图c的“打开应用”和“加载”只会在第一次显示。也就是说，攻击者可以通过让用户事先批准和下载即时应用程序，让图a和图d无缝连接，并且这一过程也让用户看起来与网络钓鱼无关，是无害的，从而使这种攻击变得更加实用。最后作者认为这种攻击策略显著降低了对网络和移动设备上所有已知网络钓鱼攻击的限制。因为这是据他们所知，第一个不需要在手机上有已安装的恶意应用的攻击，甚至也不要求用户自己插入他们的凭据。所以作者认为这种攻击比目前已知的所有移动网络钓鱼攻击都更实用。
之后是隐藏密码字段这种攻击。作者在这里评估了一下当前的移动密码管理器是否容易自动填充隐藏字段，就是用户不可见的字段。就比如攻击者可以创建一个带有用户名字段和隐藏密码字段的表单，就是我们平时登录的时候要输用户名和密码嘛，这两项我们都可以看到对吧，然后它的意思就是，这里用户名这一项我们还是能看到，但是密码这项我们看不到，被隐藏了，但是其实这两项都是要被填充的。所以当受害者使用他的密码管理器自动填充这个表单的时候，在用户不知道的情况下，他的密码就会被泄露给攻击者，因为他不知道填了密码这一项嘛。然后作者考虑了四种不同的技术来使 用于隐藏密码的EditText看起来不可见，分别是透明度、小尺寸、相同颜色的背景和前景，以及不可见标志。
首先是透明度。要在Android中创建透明的EditText，可以相应地通过setAlpha（）API设置其alpha值。作者发现，如果alpha值设置为零，则a11y和自动填充服务都无法自动填充EditText，因为它不可见了。但是如果将alpha值设置为0.01，这足以使字段不可见，并且使自动填充机制起作用。
然后另一个让人眼看不到的方法就是小尺寸。作者发现无论是a11y和自动填充哪个服务，并且即使字段大小为1dp×1dp，密码管理器都会自动填充密码字段。
之后是相同颜色的背景和前景。就是如果文本颜色与背景颜色相同，则字段及其内容将不可见。这种技术直接适用于a11y，但不足以欺骗自动填充服务。因为在自动填充的时候，自动填充服务会使用黄色覆盖自动填充字段，从而使隐藏字段对用户可见。就是我们有的时候填完用户名，密码自动出来的时候，密码下面的背景色就是黄的，这就会将本来设置好的颜色覆盖掉，密码就会显示出来。但是攻击者可以并且可能会创建应用内 叠加层来覆盖此黄色叠加层，这个操作不需要额外的权限，并且可以使该字段对用户不可见。
最后是不可见标志。就是将字段的可见性设置为View.INVISIBLE，从而隐藏该字段。 不过这种方式对a11y没用，就是它不会自动填充这些“不可见”的字段。但对自动填充服务是有用的。
之后作者对这部分工作做了一个总结式讨论。就是虽然上面提到的某些隐藏技术不适用于a11y或自动填充服务，但没有任何的东西可以防止攻击者使用这些技术。而且这些密码窃取的攻击是可能发生的，因为当前支持自动填充的机制的设计存在问题，就是所有这些机制都使用包名作为主要的抽象，从而使得当前的密码管理器实现了一个易受攻击的映射算法。所以接下来作者提出了一个设计安全的API。
getVerifiedDomainNames（）API。它是通过使用域名作为密码管理器需要与之交互的唯一抽象来实现安全设计机制的。它将直接向密码管理器提供给定应用程序合法关联的域名列表，并且在其内部实现所有必需的安全检查。这个API的主要区别在于密码管理器将直接查询域名，而不是包名。
接下来作者描述了一下自动填充表单的请求步骤，如图4所示，是这个API的时序图。首先在进入这个API前，客户端将密码发送给密码管理器以请求凭证。然后，密码管理器就调用getVerifiedDomainNames（）这个API，将接收到的Intent作为参数进行传递。（1）之后它从Intent中检索发件人的包名称，（2）用于提取客户端的应用程序签名密钥。（3）然后从客户端的清单文件中提取应用声称的可以访问的域名列表。（4）接下来API在内部为每个域名下载相关的DAL文件，（5.1）并验证请求的应用程序（包名称+应用程序签名密钥的哈希值）是否列在其中。 （5.2）最后API在其返回值中包括满足此类安全检查的所有域名列表。根据这些域名，密码管理器可以安全地在其内部数据库中查询关联凭据并将其发送回请求客户端。
之后作者对侧通道漏洞提出了自己的看法。当前OpenYOLO客户端通过发送广播Intent从凭证提供方请求凭证，从而使所有其他应用知道这个请求。这时恶意应用就可以使用这个侧通道来推断用户即将登录的特定帐户，这个信息可让攻击者知道什么时候生成其欺骗性网络钓鱼UI。所以作者认为客户和凭据提供方之间的通信必须保密，不仅仅是内容，甚至就不让其他人知道他们正在通信这个事。因此，每个客户端都应该可以访问可配置的可信密码管理器应用列表，例如LastPass，从而可以使用明确的Intent而不是广播Intent。这个列表可以存储为包名对和签名密钥的哈希。这类似于浏览器对可信证书的处理方式。
因为当前标准是DAL，然后作者又分析了一下DAL的采用率。他们的数据集就是他们检查过的密码管理器中提取的所有映射中的所有域名，由8,821个域名构成。并且由于它们是从密码管理器中提取的，所以这些域名至少包含一个带有登录表单的页面。最终他们得到的结果是只有8％（710 / 8,821）的域名有相关的DAL文件；只有2％（178 / 8,821）根据Google文档[21]指定了Android应用（就是将网页和应用关联）。这就是说，因为没有统一使用DAL，所以即使密码管理器开发者已经意识到app到网站之间的映射是存在安全隐患的，并且安全实施密码管理器问题的解决方案，也会由于只有一小部分的域名中有dal文件，密码管理器不能完全采用这种验证DAL文件的形式验证app和网站之间的关联，从而遇到兼容性问题。而Google Smart Lock是通过不依赖于全自动技术，也就是需要开发人员手动填写Google表单，以及仅在存在安全映射时支持应用到Web同步来解决这些问题的。所以作者认为其他密码管理器应该遵循类似的方法，并在无法建立安全的应用到web关联时警告用户潜在的问题。