Add EIP-5593: Restrict Web3 Provider Object API Injection

EIPS/eip-5593.md

@@ -0,0 +1,92 @@
+---
+eip: 5593
+title: Restrict Ethereum Provider API Injection
+description: Wallet guidance for restricting Ethereum Provider API access to secure contexts for improved privacy and security for wallet users.
+author: Yan Zhu (@diracdeltas), Brian R. Bondy (@bbondy), Andrea  Brancaleoni (@thypon), Kyle Den Hartog (@kdenhartog)
+discussions-to: https://ethereum-magicians.org/t/rfc-limiting-provider-object-injection-to-secure-contexts/10670
+status: Draft
+type: Standards Track
+category: Interface
+created: 2022-09-05
+requires: 1193
+---
+
+## Abstract
+
+Historically the web platform has had a notion of “powerful” APIs like [geolocation][w3c-geolocation] and [camera/microphone][w3c-mediastreams], which are subject to additional security restrictions such as those defined by [secure contexts][w3c-secure-contexts]. 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 of secure context in order to better protect the users data and users funds managed via the web.
+
+## Motivation
+
+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 3P iframe and therefore would not have the Ethereum Provider API injected into it's sub frame because it's not a secure context.
+
+## Specification
+
+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.
+
+### Restrictions for providers
+
+The provider objects, e.g. `window.ethereum`, are expected to only inject the Ethereum Provider APIs in secure context when conforming with this standard. The following restrictions are REQUIRED for conformant wallets:
+
+- Provider objects MAY be accessible in private (incognito) windows.
+- The origin MUST be a [potentially trustworthy origin][w3c-secure-context-trustworthy-origin] to have access to `window.ethereum`. This can be checked using `window.isSecureContext`, including inside iframes.
+    - Secure contexts include sites that are served from HTTPS but also HTTP `localhost`. 
+    - The browser implementation may optionally also support configured [potentially trustworthy origins] that would normally not be considered trustworthy if the user configures their browser to do so. See the [Development Environments section of Secure Contexts][w3c-secure-context-dev-env] for additional details.
+- By default the Ethereum Provider APIs MUST NOT be exposed to 3p iframes.
+- `window.ethereum` MUST be `undefined` in an iframe where `window.isSecureContext` returns `false` in that iframe.
+- If the iframe is a third party to the top-level secure origin, it SHOULD be blocked. It MAY be unblocked if the iframe uses the `allow="ethereum"` attribute. In order to achieve this implementers are REQUIRED to extend the Permissions API.
+- If the iframe is first-party to the top-level origin AND the `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.
+    - Note `"allow-same-origin"` does nothing if the iframe is third-party. The case of the third party iframe is dictated by the usage of the `allow` attribute and the Permissions API as defined in the rule above.
+
+## Rationale
+
+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 has been attempts to [limit request access via the wallet](./eip-2255.md) interface itself there's 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.
+
+
+## Backwards Compatibility
+
+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][w3c-secure-context-localhost]. This will allow dApp developers to be able to continue to host dApps on the localhost origin if a browser environment has chosen to not already consider localhost a secure context. Most major browser providers do consider localhost a secure context already. This toggle MUST be set to disabled by default.
+
+## Test Cases
+
+### Required Test Cases
+
+- Top level `http://a.com` -> blocked (insecure/top level)
+- Top level `https://a.com` -> allowed
+- Top level `https://a.com` with `<iframe src="http://a.com/">` -> blocked (insecure first party iframe)
+- Top level `http://a.com` with `<iframe src="https://a.com/">` -> blocked (insecure top level window)
+- Top level `https://a.com` with `<iframe src="https://a.com">` -> allowed
+- Top level `https://a.com` with `<iframe src="https://b.com">` -> blocked (3p iframe without sufficient privileges)
+- Top level `https://b.com` with `<iframe src="http://a.com/">` with `<iframe src="https://b.com">` -> blocked (insecure iframe)
+- Top level `https://b.com` with `<iframe src="https://a.com">` with `<iframe src="https://b.com">` -> blocked (3p iframe without sufficient privileges)
+- Top level `https://a.com` with `<iframe src="https://sub.a.com">` -> blocked (3p iframe without sufficient privileges)
+- Top level `https://a.com` with `<iframe src="https://a.com" sandbox>` -> blocked (sandbox attribuute without "allow-same-origin")
+- Top level `https://a.com` with `<iframe src="https://a.com" sandbox="allow-same-origin allow-scripts">` -> allowed (but note this case is discouraged in https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox because it’d allow the iframe to remove its own sandbox attribute)
+- Top level `data://foo with <iframe src="data://bar">` -> blocked (insecure top level scheme)
+- Top level `file://foo with <iframe src="file://bar">` -> blocked (3p iframe)
+- Top level `https://a.com` with `<iframe src="https://b.com" sandbox="allow-same-origin allow-scripts">` -> blocked (3p iframe without sufficient privileges)
+
+### Optional Test Cases
+
+- Top level https://a.com with <iframe src="https://b.com" allow="ethereum"> -> allowed (3P iframe because "allow" attribute in use)
+
+## Reference Implementation
+
+Test suite link needs to be created and linked here still.
+
+## Security Considerations
+
+### User Enables Developer Mode 
+
+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.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).
+
+[w3c-mediastreams]: https://www.w3.org/TR/mediacapture-streams/
+[w3c-geolocation]: https://www.w3.org/TR/geolocation/
+[w3c-secure-context]: https://www.w3.org/TR/secure-contexts/
+[w3c-secure-context-localhost]: https://www.w3.org/TR/secure-contexts/#localhost
+[w3c-secure-context-dev-env]: https://www.w3.org/TR/secure-contexts/#development-environments
+[w3c-secure-context-trustworthy-origin]: https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy
+[eip-2255]: ./eip-2255

assets/eip-5593/archive/w3.org/LICENSE.md

@@ -0,0 +1,21 @@
+# W3C SOFTWARE AND DOCUMENT NOTICE AND LICENSE
+
+This work is being provided by the copyright holders under the following license.
+
+## License
+
+By obtaining and/or copying this work, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions.
+
+Permission to copy, modify, and distribute this work, with or without modification, for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the work or portions thereof, including modifications:
+
+- The full text of this NOTICE in a location viewable to users of the redistributed or derivative work.
+- Any pre-existing intellectual property disclaimers, notices, or terms and conditions. If none exist, the W3C Software and Document Short Notice should be included.
+- Notice of any changes or modifications, through a copyright statement on the new code or document such as "This software or document includes material copied from or derived from [title and URI of the W3C document]. Copyright © [YEAR] W3C® (MIT, ERCIM, Keio, Beihang)."
+
+## Disclaimers
+
+THIS WORK IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE OR DOCUMENT WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
+
+COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE SOFTWARE OR DOCUMENT.
+
+The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the work without specific, written prior permission. Title to copyright in this work will at all times remain with copyright holders.