Historically the web platform has had a notion of “powerful” APIs like those defined in W3C's Geolocation specification and W3C's Mediastreams specification, which are subject to additional security restrictions such as those defined by W3C's secure contexts specification. Since the Ethereum Provider APIs allow dApp websites to request access to sensitive user data and to request use of user funds, new Ethereum Provider APIs generally should align to the security considerations defined by W3C's Secure Context specification in order to better protect the users data and users funds managed via the web.
Unfortunately, because of a difference in interpretations by EIP editors of RFC 2119 terminology around linking in EIP-1, the authors cannot directly link to other W3C specifications which this EIP builds upon. The author's attempted to provide as much context as possible within the text while complying with the editor bot in order to get this merged. If this policy is updated or further clarified before this EIP reaches final call in the future this EIP will be updated with links.
Wallets are oftentimes maintaining security and safety of users' funds that can be equivalent to large portions of money. For this reason, it's a good idea to restrict access to the Ethereum Provider APIs to align it with other powerful APIs on the web platform. This will assist in reducing the surface area that attacks can be conducted to access users funds or data. Additionally, by adding in restrictions we're reducing the surface area that malicious web pages could fingerprint the user via the Ethereum Provider APIs providing some additional privacy benefits. An example of a specific attack that's avoided by this is one where a malicious advertisement is loaded on a legitimate dApp that attempts to interact with a users wallet to maliciously request the user to access funds. With this EIP implemented the advertisement frame would be considered a third-party iframe and therefore would not have the Ethereum Provider API injected into it's sub frame because it's not a secure context.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
The provider objects, e.g. window.ethereum, are expected to only inject the Ethereum Provider APIs in secure context when conforming with this specification. The following restrictions are REQUIRED for conformant wallets:
window.ethereum. This can be checked using window.isSecureContext, including inside iframes.
localhost.chrome://flags/#unsafely-treat-insecure-origin-as-secure flag.window.ethereum MUST be undefined in an iframe where window.isSecureContext returns false in that iframe.allow attribute and Permissions API) for pages to request access, subject to user approval.sandbox attribute is set on the iframe, the provider object MUST be blocked. If the sandbox attribute is set to sandbox="allow-same-origin" it MUST be injected for a first party frame.
"allow-same-origin" does nothing if the iframe is third-party. Third-party iframes SHOULD be blocked by default, but implementations MAY allow access through user-approved mechanisms such as the Permissions API.By limiting the capabilities of where the Ethereum Provider APIs are being injected we can reduce the surface area of where attacks can be executed. Given the sensitivity of data that's passed to the Ethereum Provider APIs some basic levels of authentication and confidentiality should be met in order to ensure that request data is not being intercepted or tampered with. While there have been attempts to limit request access via the wallet interface itself, there have not been limitations that have been set to where these Ethereum Provider APIs are expected to be or not be injected. Since the secure contexts web platform API is a well developed boundary that's been recommended by W3C and the fact that the Ethereum Provider APIs are extending the traditional web platform APIs, no other alternative solutions have been considered in order to extend current established prior art.
Wallet extensions SHOULD consider adding a "developer mode" toggle via a UX so that dApp developers have the capability to disable the insecure context (http) check for the http://localhost:<any-port> origin only in the event that localhost does not return true for secure context. See section 5.2 of W3C's Secure Context specification for more details. This will allow dApp developers to be able to continue to host dApps on the localhost origin if a User Agent has chosen to not already consider localhost a secure context. All major User Agent implementations tested do consider localhost a secure context already. This toggle MUST be set to disabled by default.
http://a.com -> blocked (insecure/top level)https://a.com -> allowedhttps://a.com with <iframe src="http://a.com/"> -> blocked (insecure first party iframe)http://a.com with <iframe src="https://a.com/"> -> blocked (insecure top level window)https://a.com with <iframe src="https://a.com"> -> allowedhttps://a.com with <iframe src="https://b.com"> -> blocked (third-party iframe without sufficient privileges)https://b.com with <iframe src="http://a.com/"> with <iframe src="https://b.com"> -> blocked (insecure iframe)https://b.com with <iframe src="https://a.com"> with <iframe src="https://b.com"> -> blocked (third-party iframe without sufficient privileges)https://a.com with <iframe src="https://sub.a.com"> -> blocked (third-party iframe without sufficient privileges)https://a.com with <iframe src="https://a.com" sandbox> -> blocked (sandbox attribute without "allow-same-origin")https://a.com with <iframe src="https://a.com" sandbox="allow-same-origin allow-scripts"> -> allowed (Note this case is discouraged by User Agent implementer's such as Mozilla's MDN documents because it’d allow the iframe to remove its own sandbox attribute. See the sandbox attribute section of the iframes document in MDN for more details.)data://foo with <iframe src="data://bar"> -> blocked (insecure top level scheme)file://foo with <iframe src="file://bar"> -> blocked (third-party iframe)https://a.com with <iframe src="https://b.com" sandbox="allow-same-origin allow-scripts"> -> blocked (third-party iframe without sufficient privileges)Oftentimes developers require the ability to develop dApps locally in order to test their website and develop while hosting their dApp on http://localhost. In this case localhost would be blocked and compatibility issues would arise when developing a dApp locally. In order to increase compatibility for dApp developers a toggle to disable the check for the localhost can be considered. If this were to be extended beyond the localhost origin it could be used as a means to convince users to enable developer mode in order to subvert the guards put in place by this EIP. Therefore, implementations should be cautious when extending this developer toggle beyond the scope of the localhost origin.
Due to the nature of how the provider object is injected by default into most webpages, there's a risk that a malicious web page could utilize the provider object to fingerprint the user more precisely as a Web3 user. Implementers of this EIP are expected to consider the risks of injecting the Ethereum provider APIs into pages by default in order to consider what privacy characteristics they wish to enable for their users.
Copyright and related rights waived via CC0.