Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

EIP 1102: Loosens the constraints a bit. #2178

Merged
merged 1 commit into from
Jul 6, 2019
Merged

EIP 1102: Loosens the constraints a bit. #2178

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 11 additions & 14 deletions EIPS/eip-1102.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,13 +12,13 @@ requires: 1474

## Simple summary

This proposal describes a way for DOM environments to expose user accounts in a way that requires user approval.
This proposal describes a communication protocol between dapps and Ethereum-enabled DOM environments that allows the Ethereum-enabled DOM environment to choose what information to supply the dapp with and when.

## Abstract

The previous generation of Ethereum-enabled DOM environments follows a pattern of injecting a provider populated with accounts without user consent. This puts users of such environments at risk because malicious websites can use these accounts to view detailed account information and to arbitrarily initiate unwanted transactions on a user's behalf.

This proposal outlines a protocol in which Ethereum-enabled DOM environments expose no accounts until the user approves account access.
This proposal outlines a protocol in which Ethereum-enabled DOM environments can choose to expose no accounts until the user approves account access.

## Specification

Expand All @@ -30,7 +30,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S

#### `eth_requestAccounts`

Providers exposed by Ethereum-enabled DOM environments define a new RPC method: `eth_requestAccounts`. Calling this method triggers a user interface that allows the user to approve or reject account access for a given dapp. This method returns a `Promise` that is resolved with an `Array` of accounts if the user approves access or rejected with an `Error` if the user rejects access.
Providers exposed by Ethereum-enabled DOM environments define a new RPC method: `eth_requestAccounts`. Calling this method may trigger a user interface that allows the user to approve or reject account access for a given dapp. This method returns a `Promise` that is resolved with an `Array` of accounts or is rejected with an `Error` if accounts are not available.

```js
ethereum.send('eth_requestAccounts'): Promise<string>
Expand Down Expand Up @@ -76,15 +76,15 @@ IF provider is undefined

##### `[1] REQUEST`

Dapps **MUST** request account access by calling the `eth_requestAccounts` RPC method on the provider exposed at `window.ethereum`. Calling this method **MUST** trigger a user interface that allows the user to approve or reject account access for a given dapp. This method **MUST** return a `Promise` that is resolved with an array of user accounts if the user approves account access or rejected if the user rejects account access.
Dapps **MUST** request accounts by calling the `eth_requestAccounts` RPC method on the provider exposed at `window.ethereum`. Calling this method **MAY** trigger a user interface that allows the user to approve or reject account access for a given dapp. This method **MUST** return a `Promise` that is resolved with an array of one or more user accounts or rejected if no accounts are available (e.g., the user rejected account access).

##### `[2] RESOLVE`

If a user approves account access, DOM environments **MUST** populate the provider exposed at `window.ethereum` with an `Array` of user accounts. The `Promise` returned when calling the `eth_requestAccounts` RPC method **MUST** be resolved with an `Array` of user accounts.
The `Promise` returned when calling the `eth_requestAccounts` RPC method **MUST** be resolved with an `Array` of user accounts.

##### `[3] REJECT`

If a user rejects account access, the `Promise` returned when calling the `eth_requestAccounts` RPC method **MUST** be rejected with an informative `Error`.
The `Promise` returned when calling the `eth_requestAccounts` RPC method **MUST** be rejected with an informative `Error` if no accounts are available for any reason.

### Example initialization

Expand All @@ -101,20 +101,17 @@ try {

### Constraints

* Browsers **MUST** expose a provider at `window.ethereum`.
* Browsers **MUST NOT** populate the provider with user accounts by default.
* Browsers **MUST** expose a provider at `window.ethereum` .
* Browsers **MUST** define an `eth_requestAccounts` RPC method.
* Browsers **MUST** show an account access approval UI when `eth_requestAccounts` is called.
* Browsers **MUST** populate the provider with accounts if account access is approved.
* Browsers **MUST** resolve the `Promise` returned by `eth_requestAccounts` if account access is approved.
* Browsers **MUST NOT** populate the provider with accounts if account access is rejected.
* Browsers **MUST** reject the `Promise` returned by `eth_requestAccounts` with an `Error` if account access is rejected.
* Browsers **MAY** wait for a user interaction before resolving/rejecting the `eth_requestAccounts` promise.
* Browsers **MUST** include at least one account if the `eth_requestAccounts` promise is resolved.
* Browsers **MUST** reject the promise with an informative error if no accounts are available.

## Rationale

The pattern of automatic account exposure followed by the previous generation of Ethereum-enabled DOM environments fails to protect user privacy and fails to maintain safe user experience: untrusted websites can both view detailed account information and arbitrarily initiate transactions on a user's behalf. Even though most users may reject unsolicited transactions on untrusted websites, a protocol for account access should make such unsolicited requests impossible.

This proposal establishes a new pattern wherein dapps must request access to user accounts. This protocol directly strengthens user privacy by hiding user accounts and preventing unsolicited transaction requests on untrusted sites.
This proposal establishes a new pattern wherein dapps must request access to user accounts. This protocol directly strengthens user privacy by allowing the browser to hide user accounts and preventing unsolicited transaction requests on untrusted sites.

### Immediate value-add

Expand Down