bootstrap JavaScript: should token cards be in iframe or div

When a token is used on a website (imagine Qoin being used on a shop, Myer.com.au), the cards should be launched in a protected/separate webview, for privacy/security (you don't want the shop - in this case, myer.com.au - to learn the user's available credit). e.g. in AlphaWallet it will be opened over the web page, not inside the web page.

But in bootstrap, we have to give up a bit of security/privacy as it is supposed to run with any existing dapp browser that has an Ethereum "provider". We also give away a bit of "Trust", meaning that the website always has the control if the browser doesn't have an in-built TokenScript engine.

  • The website is able to modify the CSS inside the card, whether or not implemented in <iframe> or <div>
  • The website is able to modify the JavaScript inside the card, whether or not implemented in <iframe> or <div>
  • The website is able to read your available credit if you use a credit token.

With these "perimeters" already completely under the website's control in the bootstram case (i.e. browser lacks TokenScript engine), is there any difference in using <iframe> or <div>? Here is what I think.

variable namespace.

In the current API, web3.tokens have access to all available instances of the token (typically, only one token inside the variable, even if there are two tokens used on one website since the two tokens are probably not the instance of the same token). Currently, web3.tokens is under window, which is shared between the JS inside the div and outside. If we implemented cards using div, we need to change the API in one of the two ways.

  1. We can add a pointer to help the token card to know which object holds token data. e.g. web3.tokens.current.
  2. We can detach tokens from window.web3 (where to?).

id conflict

Since we don't know what id will be used in the website, there is a chance that both implemented id like main (main is the id typically chosen for token cards by current TS developer). Even worse, if there are 2 tokens, both will have id like main, therefore all code that uses getElementById breaks.

We still can work around it by either of the two:

  1. dynamically assign a container ID for each token card's outer div, like <div id="token3870a5802">, then, pass that to the JavaScript inside a token card, so when it accesses elements inside it can use stuff like token3870a5802.getElementsByName().
  2. we can do the same except using <form> instead of <div> as the outer container, therefore the developers can use form3870a5802.amount to access <input name="amount"/>.

In both cases, card developers are discouraged to have any id inside a token card. They are guaranteed to conflict if there are two instances of the same token (say, you have 2 instances of EntryToken and one opens the door to the office the other opens the door to your home and you have a website that shows both for you to choose). But this feel like a terrible idea to me, because a card developer will habitually use id and be very angry when we tell them not to, just like the last time when we asked them to wrap JavaScript in CDATA and they were like WTF we have been using JavaScript without CDATA wrapping for decades, they may as well say "we have been using getElementById for decades why break the working things".

CSS / JS pollution

Let's say, that the website is using a black background with white text, and such a rule is applied to body. We have the situation that a card mistakenly paints the background white and forgot to set the font colour black (as he might assume it black).

The solution is for the card developer to always diligently write overriding rules, like:

body {
font: …;
color: black;
background-color: black;
background-image: none; /* in case the website specified otherwise */
font-size: normal;
font-weight: medium;
text-decoration: nonoe;
…
}

The list goes on and on. We rely on the diligence like this. You need to do this not only for the body, as it's not clear if the website has an overriding rule such as sub-emeent rule:

body p { color: white; background-image: url(pattern.png);}

To counter that you need to repeat the diligence with body p. Ultimately, carefully tweaked inline styles should work and defeat any website themes, but only very careful token issues would spend the time to make sure it's the case.

Regarding JS, the risk is that the Card developer decided to declare a global variable (or have it under window, and there are 2 cards on the website and the second card's developer also wanted to have a global of the same name, or that the website has it).