接入网络与链上网络不要混称
讨论公共网络和区块链连接时，“公共网络”可能指公共Wi-Fi，也可能指公开参与的区块链。本文只讨论前一种接入场景：设备通过一个自己不能完全控制的网络，访问钱包配套网页或区块链数据服务。它不等同于判断某条公有链的共识机制。
连接路径与访问对象也要分开。前者关心设备和服务器之间怎样传递数据，后者关心服务器究竟是谁。即使数据在途中被妥善保护，如果访问的本来就是另一个服务，这条安全连接也不会自动把它变成预期对象。
HTTPS保护的是传输中的通信
MDN将TLS的作用分为传输加密、完整性保护和端点认证。HTTPS使用这种机制保护网页通信；服务器的数字证书把网站密钥与域名联系起来，使浏览器能够核对连接到的域名身份。这里的认证范围是技术端点，不是服务的经营信誉。
因此，判断一项业务之前，不能把“连接已加密”当成它的内容、收费或承诺已经获得认可。TLS也不是设备磁盘加密的别名，不能根据网页连接正常，推断本地保存的文件、已经复制的截图或另一应用的数据都受到相同保护。
钱包请求还要对应实际来源
以Sign-In with Ethereum规范为例，登录消息里的scheme和domain需要与实际发起请求的来源相对应。规范同时提出网页通信应使用HTTPS。两项要求放在一起，说明保护传输与核对请求对象是配合关系，不能省掉其中一项。
例如，自己正在浏览甲服务，却出现声称属于乙服务的签署请求，就需要先解释来源差异，而不是只看两个页面是否都能通过HTTPS打开。这个例子仅用于理解检查范围，不描述某个真实站点，也不表示全部钱包都已经实现同样的核验界面。
无法解释的提示应当保留为疑问
遇到证书或请求来源警告时，可以先记下完整域名、访问时间、正在进行的动作及提示文字，再通过已确认的官方入口查证。不要为了让页面继续加载就忽略警告，也不应把“换个网络后能打开”直接写成服务身份已经核实。
一份清楚的记录应分别回答：浏览器连接了哪个域名，钱包请求由哪里发起，自己原本要使用哪个服务。三者未能对应时，保留未确认状态更准确。本文没有检测读者的网络或钱包，也不以一个图标或单次连接成功作安全保证。