EIP: Opt-in web3 access

[bitpshr]

MetaMask and most other tools that provide access to web3-enabled environments do so automatically and without user consent. This exposes users of such environments to fingerprinting attacks since untrusted websites can check for a web3 object and reliably identify web3-enabled clients.

This proposal outlines a new dapp initialization strategy in which websites request access to the web3 API instead of relying on its preexistence in a given environment

• Ethereum Magician's discussion

[MicahZoltu]

This needs a condition for "user neither approves nor rejects" as well as a condition for "user does not have a web3 enabled browser (e.g., no MetaMask install).

[bitpshr]

In practice, if a user neither approves nor rejects web3 access, the open web3 approval UI could close after a timeout is reached. I'm not sure something like this should be codified into the proposal since different web3 environments could use different UX flows. For example, what if one dapp browser wants to indefinitely leave the web3 approval UX open instead of closing it after a timeout? I worry about adding such implementation-specific UX details to a proposal intended to be platform-agnostic.

As for the "non-web3" environment case, I modified the logic a bit to handle this case and to better handle the rejection case to fully prevent fingerprinting. Good catch!

[MicahZoltu]

Is there a way to do this that works across all major browsers? Ideally something that has been standardized.

[bitpshr]

While this is just a suggestion as this proposal aims to stay platform-agnostic, window.postMessage works across all major browsers and browser runtimes that most dapp browsers are built on. It's part of the HTML living standard, so unless a particular environment chooses to intentionally omit a part of the HTML specification, this should be safe to use.

[MicahZoltu]

The specifics of this need to be specified here. A standard that says, "Something like window.postMessage" doesn't fulfil its purpose of being a standard that people can follow.

[bitpshr]

See my comment below re: remaining platform agnostic.

[MicahZoltu]

I believe this needs to be standardized, not implementation specific. As a dapp author, having every web3 enabled browser notify me differently results in me living like a circa 2003 web developer.

[bitpshr]

I agree that the community should converge on specific implementations of this proposal for each platform, but I don't necessarily think this proposal should provide those implementations. For example, a web3 environment built on a mobile platform without a DOM wouldn't use postMessage but should still follow the strategy outlined in this proposal. For this reason, aspects of this proposal like the platform-specific specific messaging protocol were intentionally omitted.

It's always possible that platform-specific EIPs could be used to standardize implementations for every different possible environment if this level of proposal granularity is necessary, but that potentially seems unmaintainable.

[MicahZoltu]

I recommend using much stronger language throughout this standard. Whenever possible a standard SHOULD use **MUST** and **MUST NOT**. Anything that is **SHOULD** or **MAY** is effectively not part of the standard and cannot be relied on.

[MicahZoltu]

I don't think there is value in asserting what dapps MUST do in this standard. In fact, I think prescribing behavior of dapps isn't appropriate for this EIP outside of providing examples or workflows. IMO, this standard should describe the API for web3 enabled browsers and dapp developers can then code against that however they want.

[bitpshr]

Thanks for the quick review @MicahZoltu! Feedback addressed either by proposal modification or comment.

[MicahZoltu]

Based on some of your comments, I think I don't understand the purpose of this EIP. When I see an EIP like this, I think of the value a standard would bring if everyone followed the same pattern. As a dapp developer, having every dapp provide a different mechanism for communicating with signing tools means I need to write code for every signer separately. This is akin to writing code for every different browser back in the 90s and 00s.

If this EIP is not attempting to set a standard for how dapps can interface with signing tools, then I fail to see the value it adds as an EIP. If this is just a "hey guys, here is a good idea if you are going to build a dapp or signer" then I feel like an EIP isn't the right place for it and instead it could just live as a blog post or tutorial.

Note: I do think there is a ton of value in signing tools applying the ideas you have laid out here. I also think there is a ton of value in signing tools all utilizing the same interface, rather than each one having a different interface they use. I really think there is value in having this EIP very clearly/specifically the exact signing API that all compliant signers MUST follow, rather than leaving things "up to the implementation".

As to the whole, "different strategies for different platforms", I think there is value in creating an EIP like this for each platform. So Android signing API, IOS signing API, Windows 10 Metro signing API, Browser signing API, etc. Personally, I would start with browser and try to get buy-in from MetaMask, Mist and Parity. From there you can extend to target hardware wallets, mobile devices, etc.

[bitpshr]

Thanks for detailing your thoughts @MicahZoltu, really appreciate the feedback. For some context, I'm an engineer at MetaMask and we've discussed our intention to establish an opt-in web3 strategy with a few other environment providers.

I agree that the value of a proposal should be derived directly from the standards it sets forth, as you said, so that "everyone [can follow] the same pattern." That's exactly what this proposal does: it establishes a specific pattern that every web3-enabled environment must follow to safely expose the web3 API. This proposal objectively details a standard pattern of interaction for signing tools and intentionally and explicitly does so agnostically of platform-specific APIs.

Your concern about different environments of the same type (e.g. Mist vs. MetaMask) providing different APIs to request web3 is valid and would result in a poor development experience. That being said, why has web3 been injected by default until now by all major environment providers? What EIP were all of these individual implementations like Mist and MetaMask referencing up to this point to remained aligned? The point I'm getting at is that the actual per-platform messaging protocol used to request web3 will most likely be decided on by per-platform communities and through conversations between major web3 environment providers just like the current auto-exposure behavior was settled on in the past.

I feel strongly that adding new, near-identical signing strategy EIPs for every new platform that arises is an unmaintainable and unnecessary approach, especially when the main (and perhaps only) difference between each platform proposal would be the messaging protocol. But as a middle ground, and if others also feel maintaining per-platform web3 access EIPs is valuable, then this proposal could serve as the abstract proposal each of those concrete platform-specific proposals must reference and conform to.

Note: This is a unique proposal. Rather than suggesting a change to web3 itself, in which case platform would be irrelevant, this proposal suggests a change to how web3 is accessed, which inevitably involves some level of platform interaction. I see tremendous value in defining the abstract requirements for parameterized web3 access regardless of platform so that all platforms provide a familiar experience despite having access to different messaging protocols. If each individual platform wishes to codify its proprietary implementation for how the actual request for web3 is initiated, additional EIPs can be submitted that reference and build on this EIP.

[MicahZoltu]

Preface: I am a big fan you taking on this project and the pattern you propose. My only argument here is simply that as written, an EIP isn't the right place for the work you have done.

My vote (which carries no weight, I'm not even an editor here) is to close this PR if it is not intended to end up as a standard that someone can implement. It sounds like this EIP (as written and targeted) is akin to someone creating an RFC stating that "Communication between client and server should be encrypted" (great idea!) without providing any specifics (not actionable). While this is a great idea, it isn't useful as an RFC because it doesn't result in something concrete and actionable for end-users, developers or implementors. HTTPS on the other hand provides a very clear specification on how HTTP is encrypted between client and server so browsers can all implement the client side separately and web servers can all implement the server side separately and everyone can communicate with each other.

I really want you to propose an EIP that specs out a protocol for communicating between dapp and signer. I can totally appreciate designing something first in collaboration with Mist/Parity on a tight feedback loop and then formalizing it (EIP) after it is in the wild. I do think this should be formalized at some point, but I don't want to slow down velocity while you iterate on what that looks like exactly.

I would not at all be against having a single EIP (like this one) that simply included specifics for each platform. For example, this EIP could specify today what the standard API is for browser signers, and then it could later be extended to include mobile signers. I'm not trying to say that this MUST be broken up into multiple EIPs, only that the EIP should be actionable/implementable and provide cross-implementation compatibility benefits, not just an idea.

Note: This is far from the first EIP where someone has "a good idea" that ends up as a draft EIP without any actionable content. I believe I am in the minority for feeling that such things should just be blog posts or tutorials rather than EIPs. I personally prefer EIPs be actionable standards that benefit from standardization (cross-implementation compatibility), not best practices or standards that don't need to be standards.

[bitpshr]

Thanks again for more thoughtful feedback @MicahZoltu, I think this type of conversation helps a lot during the EIP process. While I appreciate your viewpoint and insight, I disagree that this proposal simply suggests a "good idea" without actionable content. That's sort of akin to saying a protocol-changing EIP must also provide language or platform-specific APIs to be used for every implementation...

Quite simply, this standard as written is a standard that someone can implement; we're already doing just that at MetaMask, and other DOM-based environment providers are investigating this approach as well. As I said before, I feel strongly that adding new, near-identical signing strategy EIPs for every new platform that arises is an unmaintainable and unnecessary approach, especially when the only difference between each platform proposal would be the messaging protocol.

But again, as a middle ground, if others also see value in maintaining per-platform web3 access EIPs solely to specify the platform-specific messaging protocol that each would use, then this proposal should serve as the abstract proposal each of those concrete platform-specific proposals must reference and conform to. How else would each per-platform "actionable" EIP align with one another if they have no higher-level, platform-agnostic protocol to defining their expected behavior?

On a high level, I don't think we're in disagreement: platform-specific EIPs that codify the actual per-platform messaging protocol used to request web3 may have value to maintain uniformity across environments. But if the community desires to codify these as EIPs for every possible platform (when the original auto-injection-web3 behavior was not an EIP, but was still unanimously adopted), that can still be done, and should be done so in a way that satisfies the protocol set forth in this EIP (e.g. "this is an iOS signing EIP that satisfies EIP XXXX").

This EIP is directly actionable in that it defines a concrete strategy to request parameterized web3 API access. This EIP can be thought of as a "protocol" level proposal, and any other platform-specific EIPs that reference this proposal can be the "actionable" proposals you're referring to. There still has to be a parent proposal that defines the general, platform-agnostic protocol, otherwise an iOS-specific EIP could define en entirely new flow than a DOM-specific EIP, for example.

[MicahZoltu]

That's sort of akin to saying a protocol-changing EIP must also provide language or platform-specific APIs to be used for every implementation

Protocol EIPs are required to provide all details that enable the clients to interop with each other. This means that all wire communication needs to be standardized in the protocol. In this case, the EIP does not provide enough details such that someone could code against the EIP and walk out with a dapp/signer that can interop with anything else.

This touches on the second point I mentioned previously (and elsewhere) which is that I am of the belief that EIPs should be used only for things that benefit from interoperability when standardized. In the case of best practices, there is no interoperability benefit to people standardizing. Each implementation can choose to implement all, part of, or none of the recommendations in this EIP and regardless of their choice there will be no guarantee that they will be able to interop with anything else.

web3

It is certainly possible to have a standard without an official process, just as the web3.currentProvider situation managed to do and how browsers managed to be semi-standardized before they switched to an actual standards process. I have been on both sides of the fence as to whether to standardize early or standardize late, so I won't comment much on that topic. I think if you can successfully coordinate with other signers during your development process then there isn't a strong need to standardize early.

otherwise an iOS-specific EIP could define en entirely new flow than a DOM-specific EIP, for example.

I see no problem with this. If the Android Activity flow has no need to interop with the HTML DOM flow, then they are free to have different flows. In fact, I would argue that standardization of the flow is bad because it limits innovation. Perhaps by the time someone actually authors an Android Activity flow people have come up with ideas for better flows. Sticking to the standard laid out here would give them no additional benefits (no interop benefits) and it would constrain their creativity. One could easily argue that "no one is forcing you to follow the standard" which I agree with, but then that results in the question, "What is the point of the standard if no one is forced to follow it and there are no tangible benefits from following it?"

I think ultimately that is why I consider this to be a "good idea" and not a standard: it doesn't contain enough information to enable interop between implementations.

[bitpshr]

Again, I firmly believe that a high-level, platform-agnostic proposal such as this one that explicitly defines both the message format and message payload that any platform-specific implementation must follow is absolutely essential; this ensures that web3 environments request and expose the API (and future account information) uniformly and consistently. Who are we to say there won't be 20 new platforms over the next year that have no DOM whatsoever? You really see no problem if every new platform ever created requests web3 using completely different protocols / flows / message payloads? A common proposal must layout a standardized protocol to request web3, with standardized message formats, that can be applied to all platforms.

How each of those platforms implement this EIP in a platform-specific manner either belongs as a separate EIP that conforms to this EIP, or just belongs as standard that the community arrives at organically.

Lastly, we are already attempting to coordinate with other DOM-based web3 environment providers. This proposal is the direct result of many conversations that identified the need for an abstract standard protocol for requesting web3 across all possible platforms, even those that don't yet exist.

Thanks again for your feedback so far.

[wighawag]

I am not sure I follow your argument @MicahZoltu as this EIP is actually actionable. If I were to start building a web3 signer for dom based dapps, I would have enough info to ensure the dapps can ask whether the user accept using the signer with it.

As a dapp developer, I would be more than happy to have only one api to follow for web based dapps. As @bitpshr mentioned it could also form the abstract flow to follow for non dom signer.

I agree though that the use of MUST and MUST NOT would be more appropriate. Actually was it your only critique ?

[bitpshr]

To summarize what I've gathered so far @MicahZoltu, it sounds like we're in agreement over most of the proposal except for one key aspect: the designation of the proposal itself as an actual "EIP" (as opposed to something informal, like a blog post.) Playing the EIP-per-platform scenario out to its logical conclusion, we'd end up with an indefinitely-growing number of platform-specific EIPs, each of which could implement an entirely different protocol for user-approved web3 access; this is an objectively unacceptable outcome. To prevent potential protocol differences between different platforms, a high-level proposal such as this one must exist so that any platform-specific EIPs can conform to the same end-user flow.

If I understand your point correctly, you feel that no platform-agnostic opt-in web3 proposal should exist; instead, a unique proposal should be created for every possible platform, and you "see no problem" if these platform-specific proposals don't follow a standardized pattern (which is the very pattern this EIP sets forth.)

I really do appreciate your feedback, being challenged on a downstream-developer-facing proposal like this is important. I can get on board with platform-specific EIPs if the community deems them necessary, but in order to have those platform-specific EIPs, a platform-agnostic EIP defining the protocol of user approval is an absolute necessity.

[MicahZoltu]

If I were to start building a web3 signer for dom based dapps, I would have enough info to ensure the dapps can ask whether the user accept using the signer with it.

If 3 people write browser signers (like MetaMask or Parity extensions) and 3 people write dapps, and all 6 of them follow this EIP as written, obeying all of the MUSTs and ignoring the SHOULDs and examples, then it is entirely possible that none of the dapps will work with any of the signers. This is why I argue this EIP (as currently written) doesn't add value as a statdard. It is justm a best practice recommendation as is, not something someone can implement and expect to be able to interop with anything else afterwards.

[MicahZoltu]

we'd end up with an indefinitely-growing number of platform-specific EIPs, each of which could implement an entirely different protocol for user-approved web3 access; this is an objectively unacceptable outcome.

It is unclear to me why you think this is a bad outcome. As a web dapp author, I can read the EIP that tells me how to author my dapp against the web signer standard so that it works properly with any standards compliant web signer (like MetaMask).

With this EIP, I cannot write my web app in a way that guarantees it will interop with any standards compliant signer. A signer could be compliant to this standard but not have the same API as another compliant signer, thus a dapp will not work with both unless it implements both APIs. The whole point of standards is to solve this specific problem.

[bitpshr]

@MicahZoltu again, this is the abstract standard that any platform-specific standard must conform to and implement. Without a high-level standard sitting above any platform-specific standard, there's zero guarantee those platform-specific standards would ever follow a uniform pattern.

This proposal concretely defines that pattern.

Your single example above (which is contrived, we at MetaMask try to communicate with Mist, Parity, and other DOM environment providers as often as possible), could be solved very simply: through a DOM-specific EIP that implements a DOM-specific version of the protocol defined in this EIP. I'm still struggling to understand how you think the following is in any way acceptable:

We'd end up with an indefinitely-growing number of platform-specific EIPs, each of which could implement an entirely different protocol for user-approved web3 access; this is an objectively unacceptable outcome.

Platform-specific signers should follow an identical flow in terms of requesting user approval and the payloads they send / expect. This proposal directly makes platform-specific signers follow a uniform pattern.

Again, and most importantly: I can get on board with platform-specific EIPs if the community deems them necessary, but in order to have those platform-specific EIPs, a platform-agnostic EIP defining the general protocol of user approval is an absolute necessity.

[MicahZoltu]

there's zero guarantee those platform-specific standards would ever follow a uniform pattern.

And that is okay. 😄 Since the platforms don't interop (at least not in any way defined by this EIP) they don't have to follow the same pattern.

I can write an app that follows an object oriented pattern in code while someone else follows a functional pattern. Both patterns might be good ideas, or maybe one is better, but there is no need (or benefit) for everyone following one or the other. Both patterns should be documented somewhere, just not in RFCs.

Perhaps it would help if you explain why it is important that all signers follow this pattern? What if my users prefer to have their address automatically given to every site they visit because they want auto-login via crypotgraphic signing. If I'm building a signer, it seems like following this pattern creates a burden on my users. What do I or my users benefit?

[kumavis]

Perhaps it would help if you explain why it is important that all signers follow this pattern?

This is a standard proposal for Ethereum Dapp Browsers. It specifies an interaction between the dapp and the dapp browser for requesting access to the ethereumProvider (e.g. web3 / web3.currentProvider ). It's important that all dapp browsers align this interaction for dapps to work consistently across dapp browsers.

What if my users prefer to have their address automatically given to every site they visit because they want auto-login via crypotgraphic signing. If I'm building a signer, it seems like following this pattern creates a burden on my users.

The dapp browser MAY automatically respond to the request and connect the ethereumProvider without user interaction. This would be analogous to what we do now (inject web3/provider by default).

What do I or my users benefit?

The main driver of this proposal is that, if adopted, the webapp is unable to fingerprint the browser as web3 browser. This enhances privacy for the user.

@MicahZoltu

[fulldecent]

There are two types of fingerprinting that we are discussing:

1. Is Web3 available?
2. Which network is enabled?
3. What is the user account?

Number 3 may be a concern and 1 is not, not sure about 2.

In this case, then perhaps web3js is the place to discuss all these things.

[bitpshr]

Thanks for the feedback @fulldecent, very much appreciated.

I may be misunderstanding your response, but I believe that "Is web3 available?" is actually the primary and most dire security concern being addressed by this proposal in terms of fingerprint prevention. Navigating to an unknown app shouldn't allow that app to identify web3-enabled clients and gather metrics on potential Ethereum users without their consent.

I feel that "Which network is enabled?" and "What is the current user account?" become non-issues since this information would only ever be exposed through web3, which would only ever be exposed to dapps after explicit user approval as outlined in this proposal.

I'd be happy to start a discussion in ethereum/web3.js, but this proposal defines the protocol to gain parameterized access to web3, not a protocol for using it. If any part of this proposal is implemented on the web3 level, fingerprinting will still be possible since a web3 global will still be injected.

[kumavis]

@fulldecent If I were an advertiser/tracker I would definitely keep track of which users had web3 injected and target them with ads like ICOs

[fulldecent]

As a user, I don't care if advertisers know I have Metamask installed. But I do care if they know my account number.

Either way, I do not think this is grounds for standardization.

[MrTibbles]

Having metamask installed can be classed as personal data, as it gives advertiser's the ability to make an informed decision that you are interested in the crypto space, or on from that ICOs as @kumavis says, which is generally undesirable. An advertiser having awareness of your pub key is of course the next undesirable step.
One aspect of standardisation is to enforce best practices and consistent UX, which is the intention of this proposal; IMO.

[MrTibbles]

This is very similar to a native mobile application requesting access to your contacts or camera; IMO.

[bitpshr]

@fulldecent: While I can appreciate that you personally don't mind if you're fingerprinted, tracked, and targeted as an Ethereum user, I'm struggling to find any tangible or objective justification in your response as to why your personal security preferences on this topic should block standardization. Do you feel that untrusted apps should be able to identify web3-enabled clients, and that targeting these specific clients with advertisements is both 1) acceptable, and 2) in-line with a decentralized future of selective information disclosure?

Even if the (major) value-add of fingerprint prevention is disregarded, this proposal also defines a (potentially more important) protocol for parameterized web3 access, such as requesting a specific network with a specific account type.

To make sure I understand correctly, you see no issue with the current auto-injected web3 behavior even though it allows Ethereum users to be reliably identified without their consent by any website they may visit?

[bitpshr]

@fulldecent: We're not.

Please update the contributing guidelines so potential contributors know that an EIP can only be considered for draft status if it has "existing implementations that people are already using" (which invalidates several merged draft EIPs), even if every existing implementation is already informally-standardized on a protocol that exposes an immediate security vulnerability.

[danfinlay]

I am turned off by arguments that tell other people to do something (e.g. standardize something) before they themselves have made a commitment to do that thing

This is not a recommendation EIP, we composed it to engage community in discussion before we deploy this change to production.

Historically, implementing a new web3 browser feature that gets popular quickly becomes a de-facto standard that other browsers begrudgingly implement, often with improvement suggestions in hindsight.

Rather than implement this feature before asking the larger public for comment, we've opened it up.

So far there have been plenty of productive comments that have improved the proposal, and so I consider this EIP a success of community engagement, regardless of the usual meta-debate dumped on web3 browser devs of whether or not this EIP is categorically an EIP or whatever.

The editors have been clear, a variety of "layers" of EIP are valid EIPs, including contract interfaces and browser APIs changes. They're just coordination tools, nothing binding.

[danfinlay]

perhaps web3js is the place to discuss all these things.

This is a common misperception. Web3.js does not actually define the web3-browser API.

Even web3 itself depends on the API exposed as "the Ethereum Provider" (web3.currentProvider), which is basically a direct mapping of the JSON RPC API, and so actually even web3 is dependent on multiple clients for its API surface.

Further, even the Mist browser plans to stop injecting the web3.js convenience library by default (eventually currentProvider will probably be the only property on web3), further clarifying web3.js is a library, not a standards organization.

[wighawag]

I don't know why the web3/Json rpc EIPs are neglected so much. It is probably the API that will be the most difficult to change as we go along. As the message signing api and the whole history of the web show.

It is important to have discussion on this kind of EIPs before it is too late and thus before any particular browser implement it and promote it as the standard. Thanks @bitpshr for allowing the discussion to happen.

@fulldecent , I think it is very important to have this standard discussion before each browser start implementing similar api without compatible implementation. I would thus be in strong disagreement if to have a live implementation was a requirement for an EIP to be valid

At some point it was suggested to separate EIP between smart contract standard and other. I would like to consider a separation for web3/json RPC standard to give then more visibility.
But this is offtopic.

As a dapp developer that care both for my user's privacy and my time (to not have to work on incompatible api) I am strongly in favor for this EIP.

[MicahZoltu]

To be clear, I'm 100% in favor of having this discussion. My only argument is that it shouldn't be an EIP. 😄 In fact, I added a comment recently in the Discourse discussion on how I think we can even further improve end-user privacy.

[danfinlay]

The EIP post was mostly meant to be a cross-post for people not following ethereum-magicians, which I understand to be the new preferred place (by EIP editors) to have these discussions in general.

Plus it's threaded... so much easier to follow.

[MicahZoltu]

I'm not really a fan of creating EIPs as a form of "advertising" a topic of discussion. I feel like we already have a big enough problem of EIP spam as it is. At the least, if there is not an intent to have this merged as a draft then an Issue would probably be better.

[bitpshr]

I still feel strongly that this EIP should be merged as a draft for the reasons I've outlined throughout this thread and on Ethereum Magicians. There have been zero community objections to the actual content of the proposal; only subjective dissent was only expressed about its validity as a "true" EIP.

It would be great to have a draft of this strategy that all dapp browser implementers can uniformly refer to and iterate on while ultimately standardizing the protocol for web3 exposure, especially given its positive community response. I feel this is the entire point of the EIP process and its "draft" status designation.

I'd be interested to hear what @Arachnid or @Souptacular thought about the validity of this proposal as a draft EIP for community iteration.

[MicahZoltu]

The purpose of EIPs (IMO) is to create standards, like RFCs, that define implementation details necessary for two people to implement the standard in isolation and have the two implementations be interoperable with each other. This means that the two implementations could perhaps share a data store, communicate with each other over some channel, operate with a shared data format as input, etc.

A design pattern or a UX pattern is not a standard in the sense of RFCs, no matter how great of an idea the pattern is. Design patterns include things that are generally good ideas like immutability (software design pattern), idempotency (DB design pattern), call-to-action (UX design pattern), or not sending raw passwords over the wire (security design pattern). These are all good ideas (some of them great) and we should strongly encourage people to follow them. However, they do not serve the purpose of allowing two people to implement the pattern in isolation and expect interoperability between implementations like an RFC does.

This proposal falls into the latter category, which is why I don't believe it makes sense as an EIP.

[Arachnid]

If specified concretely - with an API that can be implemented across multiple user agents - this is definitely a valid subject for standardisation. As stated, it's too vague to be standardised, since multiple implementers will produce incompatible results.

I'm happy to merge this as a draft in its current state, however - it definitely meets the requirements for draft, assuming the intention is to flesh out the specification concretely.

[MicahZoltu]

My understanding from the above conversation is that the intention is to not flesh it out concretely and leave it vague indefinitely. Please correct me if I'm misunderstanding @bitpshr!

[bitpshr]

Thanks very much for your input @Arachnid, I think this is fair.

@MicahZoltu, while the original intention of this proposal was to form an abstract protocol that other platform-specific proposals would concretely implement, I think you're right; that's probably too contrived given that every existing dapp browser at the time of writing exposes a DOM. I agree with you now that this proposal should be made DOM-specific and should detail concrete APIs so that it can implemented uniformly and in isolation across various products.

I updated the proposal accordingly; please let me know if there are any other objections to merging as an initial draft, and thanks again for the help throughout this process @MicahZoltu and @Arachnid.

[sergeys-opera]

Why not using an existing Permissions API? https://developer.mozilla.org/en-US/docs/Web/API/Permissions_API/Using_the_Permissions_API

Then developers can benefit by almost free (as in "cheap") browser support and users can get native feeling as native dialogs are shown in such case (and the permissions can be revoked in the UI).

As a reference you can check Opera for Android with crypto-wallet support: https://www.opera.com/sv/crypto

[bitpshr]

Hi @sergeys-opera, thanks for your comment. I responded over on Ethereum Magicians.