barbaz wrote:
... and describe a real-world situation where it would exist and be problematic for NoScript users in the same way as co.uk or cloudfront.net.
What prevents "mycloudservice.iamcool" from existing?
Why is the assumption that mozillas public suffix list is comprehensive and up to date warranted?
This isn't esoteric.
Unconventional TLDs are allowed on the internet.
Unconventional TLDs can be used to host whatever service you might host.
Thus the default assumption for unconventional TLDs should not be more lax than for known TLDs and public suffixes.
Pansa, this is not like other forums. Around here, when you are asked to back up what you write, attempting to circumvent the question is not a good idea.
It was not as much a circumvention, as it is clearly pointing out that you demand a different layer of "proof" here, than is warranted both for general security concerns, as well as was used to establish concerns for the cases A) and B) above.
It is questioning the premise the question is based on.
And you keep dodging my question all the same. What is the difference in argument between "we don't know what is hosted on cloudfront, thus we don't want make trusting cloudfront as a whole too easy" and "we don't know what is hosted under unconventional TLDs, thus don't want to make the assumption that NONE of them are cloud services".
Or inversely:
Why is assuming that unkown TLDs don't have cloudservices hosted more prudent than
assuming cloudservices might host unwanted scripts.
Why is "well I can't think of an unkown tld that fits this case" different from "well I don't know a specific cloudflare subdomain that hosts questionable scripts"?
It is the exact same level of "preventative security concern in face of unkown content". And that is what defaults need to consider (and in both cases currently do)
