POC: Navigator: disallow requests to some domains (currently mochiads.com) #3511
Conversation
|
I definitely think it should be an array of banned domains, looks weird for the domain to be hard coded like it is right now |
|
I feel a little iffy about this feature, because it represents fundamentally changing existing SWF content to work around problems caused by a particular advertising vendor. At least for self-hosted Ruffle, it seems like something that should be developer-configurable and disabled by default. For the extension build, this is at least a more defensible option, as the extension is specifically for enabling old and broken websites. Generally speaking, the way browsers handle this problem is to check a remote service like Google Safe Browsing (or the Tencent equivalent, because China) to see if a domain is known malicious. That's actually a trickier job than you'd think - especially when you want to preserve user privacy. Furthermore, we'd have to figure out how to actually manage such a service - who hosts the list and decides what domains should be added to it. I'm not sure if I like the idea of Ruffle phoning home, either. I'm not sure if I have any good answers to any of those questions. To answer your other questions:
|
| pub fn is_fetch_domain_banned(url: &str) -> bool { | ||
| if let Ok(parsed_url) = Url::parse(url) { | ||
| if let Some(domain) = parsed_url.domain() { | ||
| if domain.ends_with("mochiads.com") { |
There was a problem hiding this comment.
This would also block the domain examplemochiads.com; should probably be domain == "mochiads.com" || domain.ends_with(".mochiads.com") or similar
There was a problem hiding this comment.
Some other things to keep in mind (although these are most likely nitpicking, overly defensive, and not relevant for this scenario):
mochiads.com.(note the trailing period) is the same asmochiads.com, except it's "absolute" instead of "relative" (thus, arguably more correct anyway, except almost nobody uses this form anywhere)
EDIT: They are only actually the same under the assumption thatcom, being a fairly common TLD, doesn't/can't appear as a subdomain, but if there is no such rule, these two domains are actually different, but most likely resolve to the same address.- International domain names may be Punycode encoded, or represented directly in Unicode - not sure where the en-/decoding would occur, if any.
There was a problem hiding this comment.
I guess this is just the job for something like tldextract crate.
There was a problem hiding this comment.
Punycoding an ASCII domain merely prepends xn-- and appends - to the domain. The idea is that the prefix says "this is a Punycode domain", then you put all of the directly representable characters in the string, then the -, and finally an encoded list of Unicode code points and where to insert them into the ASCII part of the domain.
Strictly speaking, mochiads.com and xn--mochiads-.com are separate domains. I don't know if/how Adobe handled Punycoding internally or if movie authors were expected to do it themselves. I'm going to assume it works like HTML5 fetch, and thus is_fetch_domain_banned should be seeing Unicode strings that get passed to HTML5 fetch and then the browser actually encodes any IDNs for us. Please correct me if I'm wrong.
|
I think phoning home is only really something you'd do when the list of blocked domains gets to many thousand entries, and you can't comfortably store it on the users device; I think that's highly unlikely, and we can tackle that problem when that happens, if at all.
Agree with developer-configurable (could we just make it a crate feature? If someone really wants to input a custom domain, they could just modify the source), but I definitely think it should be enabled by default, also in the self-hosted version! A few (valid IMHO) points from a Discord member:
|
|
We should also decide when we want to use this list; should we liberally add dead domains, or only when not adding them has a direct effect on the user's experience? An example is But this domain is owned by an unknown actor (definitely not the one that the SWF author intended), and may at any point change the returned SWF and decide to serve ads, change the game behaviour, or just break games. |
|
I agree with @kmeisthax |
|
My initial reaction is also a little against include hardcoded domains by default -- it seems to me that this adds another layer that potentially rots over time as domains may change hands, etc. But we should definitely provide this as an option, both in self-hosted and in the extension. This could also tie-in with a more general URL-redirection feature, where you can redirect network requests from one URL to another (#1486). This could allow Haven't tested this yet; if mochiads.org is blocked, does this allow the Mochi preloader to exit quicker, or does it still show the loading bar for a few seconds? |
|
I don't know if this thread is still active but: ruffle for website owners would have a similar function in config somewhere |
|
Perfect is the enemy of done. In that spirit - shipping this using an array initially (possibly only with mochiads in it to start), and then later on adding this to the addon settings may be a way forward ? |
danielhjacobs
added
security
|
Requests can also be disallowed at the origin level with CSP, example: |
Requested on discord, no GH issue :(
mochiads.com was used by some flash games for distributing ads (and other uses?) - currently the domain was taken over by what looks like malware distributor.
PR design questions: