Add EIP-5593: Restrict Web3 Provider Object API Injection

[kdenhartog]

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

• The PR edits only existing draft PRs.
• The build passes.
• Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
• If matching on email address, the email address is the one publicly listed on your GitHub profile.

cc @lightclient @axic @SamWilsn @MicahZoltu this is my first time submitting an EIP so if there's anything additional that needs to be done here please let me know.

[eth-bot]

A critical exception has occurred:
Message: pr 5593 is already merged; quitting
(cc @alita-moore, @mryalamanchi)

[Pandapip1]

No external links

[kdenhartog]

What's the best way to externally reference other normative specs and useful documentation then to enhance context for readers and implementers? Within W3C specs there's something similar to citation bibliography that they use. This would be possible to achieve in a similar method using markdowns reference style links.

This has the benefit of better readability while also being able to externally link for additional context. I assume there's a reason this rule was put in place though and this benefit was outweighed by the downsides of using them.

Out of curiosity what's the motivation for this rule? I assume either security related or to prevent maintaining broken links, but am not certain.

I'd be happy to help define some additional editorial rules in the process document to allow for external links if the editor team is open to revisiting this rule.

[xinbenlv]

@kdenhartog I think it's complete reasonable to include reference to w3c. The editors are still debating rules about external links.

FYI: @lightclient @gcolvin for comments

[xinbenlv]

External links are allowed by EIP-1 when necessarily.
Please see #5597

[SamWilsn]

The current policy is to disallow external links in their entirety. If a linked resource allows redistribution, you may embed it in assets/eip-5593 and link to it from there.

In this case, I don't think the links are necessary to understand the proposal, so I'd just remove them.

[Pandapip1]

No external links

[xinbenlv]

@EIPW please suppress warning

@Pandapip1 , I support adding this link. I think this is informative and non-promotional.
FYI: @gcolvin @SamWilsn @Pandapip1

[Pandapip1]

Those are not the criteria for determining whether a link is allowed or not.

[xinbenlv]

@EIPW please suppress warning

I support adding this link. I think this is informative and non-promotional.
FYI: @gcolvin @SamWilsn @Pandapip1

[Pandapip1]

Those, again, are not the criterion for determining what is or is not an okay link. The only criterion is "is it going to last longer than the EIPs repository." I would say that links to w3.org are likely okay, but this is not the place to debate that. If you feel like links to w3 are justified, the correct place to do so is in a PR making that change to EIP-1.

[kdenhartog]

I'm happy to hold this PR until we get that resolved and will contribute to the discussion as well based on my experience as an editor in W3C.

[rekmarks]

I just want to chime in to thank @kdenhartog for their excellent work here and that we will follow up on the PR to the MetaMask extension to get it merged.

[kdenhartog]

Thanks @rekmarks credit definitely goes to @diracdeltas and @bbondy for the idea and implementation. I got the easy job of turning the docs into an EIP. 😄

[Pandapip1]

@kdenhartog mind adding these files to the directory I just created? kdenhartog#1

[kdenhartog]

@kdenhartog mind adding these files to the directory I just created? kdenhartog#1

Thank you for the PR to consolidate this into PDFs. I'll leave them in for now, but leave the links unchanged at the moment. If we decide that linking isn't going to be allowed in the #5597 discussion then we can update everything accordingly. That work for you?

My preference would be to link to these documents at this point because the TR directory at W3C has a very rigorous process for updating it and along with that they've built in good processes for how specs are edited with errata and new versions. The chromium links need to be updated to a better link as well. If we go towards the PDF route we end up having to maintain these PDFs rather than being able to lean on W3C's processes (or other SDOs like WHATWG) which handle these aspects well. Especially since some of these things like the permissions API are actively being worked on at the moment and require that I normatively reference them for an additional normative MAY I'm working on adding right now.

As an example, here's a spec for XML which was published in 2008, so going on 14 years now as a stable URL. It includes notes about links being updated and errata which are not available with the PDF approach. In my opinion using links for the W3C spec is actually an advantage here. If we were going to link to Chromium docs, I'd be more open to it, but even in that case we can lean on commits

[Pandapip1]

If we decide that linking isn't going to be allowed in the #5597 discussion then we can update everything accordingly. That work for you?

It would be my preference for you to just link to the PDFs anyway - it's also likely to get your EIP merged faster.

[kdenhartog]

@SamWilsn I've reviewed kdenhartog#2 and updated to try and and make it work as much as possible. FWIW, I just realized there's no way to link to a reference implementation right now either so I'm probably going to have to drop this section to merge it too.

[kdenhartog]

Once again the EIPW bot does not reflect language in the EIP-1 document. It's not a requirement for the sections to exactly match the template according to EIP-1. See here for details: https://eips.ethereum.org/EIPS/eip-1#eip-formats-and-templates. No where does it state that the EIP MUST match the template. Additionally, it's throwing errors on the recommended template for licensing.

If the bot is going to be the ultimate arbiter of truth then there's no point in having EIP-1 in my opinion and there should be more than @SamWilsn implementing and reviewing changes to the bot if so. Right now governance of this repo is being unilaterally managed by the EIP Walidator bot, not EIP-1.

[SamWilsn]

I'm sorry you've been having an unpleasant time with the bot and the process in general. I'm happy to try and help get your PR merged as much as I am able.

Once again the EIPW bot does not reflect language in the EIP-1 document. It's not a requirement for the sections to exactly match the template according to EIP-1. See here for details: https://eips.ethereum.org/EIPS/eip-1#eip-formats-and-templates. No where does it state that the EIP MUST match the template.

eipw enforces the generally agreed upon consensus of editors, and EIP-1 lays out the hard rules of the process. Where EIP-1 does allow leeway eipw probably doesn't. That's somewhat intentional. For the majority of cases, we expect that the rules in eipw will be followed. In the remaining exceptional cases, EIP editors can override eipw.

You'll note that EIP-1 says "Each EIP should have the following parts:", and lists the sections you should include. eipw enforces those rules but if an editor decides to allow it, you could theoretically have other sections. In practice, it's very hard to convince editors to override those rules.

Additionally, it's throwing errors on the recommended template for licensing.

Yes, that's a bug: ethereum/eipw#51

Sorry about that! It looks like there's an http://localhost without backticks on line 78.

If the bot is going to be the ultimate arbiter of truth then there's no point in having EIP-1 in my opinion and there should be more than @SamWilsn implementing and reviewing changes to the bot if so. Right now governance of this repo is being unilaterally managed by the EIP Walidator bot, not EIP-1.

eipw is just a tool to catch the most common problems we see. The ultimate arbiter of truth is and will always be the rough consensus of EIP editors.

[kdenhartog]

I appreciate the thoughtful and level-headed response as you always bring to the table @SamWilsn. I presume in this case the 4 ones about the license can be overridden. Is the one about the privacy considerations one that you're willing to do as well since it's a two hash header rather than 3? If not, I'll change it to a subsection of security for now as you've already made a huge effort on getting the links in place which was far more important to me. We can save the privacy considerations as a top level header for another day and merge this one.

[SamWilsn]

I presume in this case the 4 ones about the license can be overridden.

I think there are still external links? Three in the reference implementation, and the one on 78 I mentioned earlier.

Is the one about the privacy considerations one that you're willing to do as well since it's a two hash header rather than 3? If not, I'll change it to a subsection of security for now [...]

You should move it to be a subsection of security considerations.

[kdenhartog]

I presume in this case the 4 ones about the license can be overridden.

I think there are still external links? Three in the reference implementation, and the one on 78 I mentioned earlier.

Is the one about the privacy considerations one that you're willing to do as well since it's a two hash header rather than 3? If not, I'll change it to a subsection of security for now [...]

You should move it to be a subsection of security considerations.

Ok, I'll try to go a few more rounds with this thing and see if I can figure it out. I see a few more links in this EIP (implementation ones for example), so I presume it's just flagging the wrong line then and I miss understood ethereum/eipw#51.

[xinbenlv]

@Pandapip1 In the industry a lot of people confused security with privacy, I would suggest as a RFC/XIP type of body, we keep the distinction more obivous?

Shall we add a "Other considerations" to catch all? FYI @kdenhartog

[kdenhartog]

That's a good approach that allows the bot to remain more strict to the template while also having a good abstraction point that makes this useful beyond just privacy considerations.

[Pandapip1]

LGTM!