I don’t see how. The webview should in this case never use the network. The application should be repsonsible for fetching the images from whatever source it needs and supplying them to the webview. (Including only downloading this once and never again; ignoring tracking pixels etc)
Implementing this as a firewall like you suggest above makes this easy to accidentally misimplement.
In my experience They totally do, except for shitty newsletter services.
How many people spin up a web server to include a link to an image instead of actually sending it?
This practice is a tracking nightmare and we should not accept it as normal ir the default.
But leaving it to the program makes all places to need to reimplement the link downloading, etc.
How about something like
Bmail theMail = oneDownloadedEmail;
myHtmlEmailView = new HtmlView(theMail, RestrictedFlags);
Then the view shows a banner/button/etc informing that there are things to be downloaded, and the user can opt to accept it. That would change an internal property of the component, and then the HtmlView would redraw itself, downloading and processing/positioning the new elements.
With something like that, any improvements could be done inside the HtmlView part, ( like refusing tracking pixels, for example ) and would be disponible to all programs that used the compoment.
For all other cases, do we need html emails at all? Text email is fine.
And, yes, I’m subscribed to various newsletters and that’s where I need html and embedded images most. Alongside with order confirmations from websites and stuff like that.
I don’t see how asking the apps to reimplement network access is of any help to anyone here. That’s part of the job of the web view and I’m sure it can do it with the needed protections. Which are also useful in a web browser anyways, if you find yourself on a slow connection/busy public wifi/rate limited service, being able to surf the web without images is also good to have.
I don’t think disabeling images is relevant outside of this specific context, the thought here is that we want to render html but we do not want any network access as the files should be available already. Images are the only exception in this case, and only relevant to emails. I don’t think any email clients support loading iFrames or anything else.
So that is why I think this should primarily live inside the code of an email client, as this is not generally applicable at all. The case of no network and no js is much more common for example for documentation pages, and not having those available by default should be a security feature. Stuff like the “allow by default” api you suggested above seem like a security issue to me.
I do think html email is nice on it’s own, it gives you control over font size, boldness etc and simple layouting. in the iOS email app it looks like a “smart” text view and behaves like it, sending as html and falling back to html gracefully. We could similarily have a stylededit-equivalent textfield as input and this case would work fine.
For email clients a firewall like api you suggested above would not be able to implement the needed caching and such, so that these images only ever need to be downloaded once (since they were ment to be part of the email, and if we can’t avoid downloading them we should atleast not download them every time the app restarts)
Anyhow, we can probably discuss this further once we actually design this api?
We certainly should implement more of those features generally, especially in webpositive, say permission to download from sites (Only safari does this that i know off, but i really like that feature), javascript etc.