Default whitelist: add {source:*, target:*.typography.com}

[ronjouch]

Test case: https://kottke.org/ , which uses woff fonts from typography.com, which only serves the font if referer is on.

[ntninja]

I'm not sure what to do here: typography.com is probably used by a lot of sites, but it's also strictly non-essential in next to all cases. As such adding a *>*.typography.com rule seems to be similar to adding a *>*.ad-site.bla rule because a third-party ad doesn't load without it: It may improve the page's display in terms of staying true to the original appearance, but it also subverts the whole point of having this extension in the first place. Now, I know that giving access to an ad-site this way is strictly worse than that font site, but I'm really not sure were to draw the line here. A possible solution I see here would be to add a second off-by-default whitelist to the extension just for cases like this (i.e.: let the user decide), does that sound reasonable to you?

Also there should also be some guidelines regarding which stuff belongs into each list. (Your input would be greatly appreachiated here.):

Guidelines for inclusion into the main default whitelist

Rules may be placed into the main default whitelist if their absence causes any important part of a site's experience to disappear, appear broken or become dysfunctional and

1. the different domains used by such rule are directly owned by the same entity (like Google stuff imported on YouTube) – this explicitely does not include corporate groups that happen to include, for instance, both an ad service and a useful site – or
2. a specific (i.e.: without including a global-wildcard * rule for either domain) rule can be crafted between the affected domain and the domain of the 3rd-party service or
3. in case of demonstrated major breakage on several sites, where breakage on many other unknown sites is to be expected, only, a non-specific rule towards the domain of the used 3rd-party service.

Also, in general, the domain of the referenced service should not belong to any privacy violating service. Where „privacy violating service“ is defined as any service offered by an entity that is either reputable of not respecting user's privacy or may reasonability be expected to engage in such behaviour in the future due to „user is the product“-style business practices (including most social media sites and ad networks). Exceptions to this rule may be allowed on a case by case basis if deemed unavoidable due to major breakage to the site being present otherwise and if the rules falls into either category 1 or 2 of the above list; rules added according to category 3 of the above list may never include a privacy violating service.

Specific rules must always be prefered over non-specifc ones. The need for adding a rule must be demonstrated up-front and should be verified (if feasable) by the person considering its inclusion. All rules should be added with a short description of the issue they are trying to solve, as well as the time of last verification.

When considering a new rule the person considering its inclusion should also keep in mind that rules added to this list will be applied by default in most installations of Smart Referer.

Guidelines for inclusion into the (proposed) extended whitelist

Rules may be placed into the extended whitelist if

• they are not suitable for the main default whitelist for any reason and
• their absence causes any visible breakage on the given site and
• their inclusion does not add a domain of a privacy violating service (see the definition above) into any part of the rule (neither source not destination).

As with rules in the main default whitelist, specific rules must always be prefered over non-specifc ones. The need for adding a rule must be demonstrated up-front and should be verified (if feasable) by the person considering its inclusion. All rules should be added with a short description of the issue they are trying to solve, as well as the time of last verification.

Examples of use-cases for this list include: External font services, minor images on a site, privacy-preserving advertising, …

Also adding previous contributors of the last 2 years to the whitelist here, your input would be appreachiated as well! @smed79 @ReporterX @mcbarky @chmike @vertigo220 @bitpixl @crssi @denhal

[vertigo220]

I have some conflicting thoughts here, though I will say my first idea, which I had right before reading @alexander255's same idea, was to have a separate list. So there could be a primary, on-by-default list of stuff required for function, and a second, off-by-default list of stuff that's not inherently bad but is also by no means necessary for a site to work or look good. If possible, this second list should even allow each individual entry to be toggled, with a descriptive explanation of each to help the user decide whether they want to enable it or not. Of course, it gets tricky, because these could just as easily be manually added by individual users on a case-by-case basis, and you might create a second list only to have a couple things in it. But I hate to just shut down an idea, and who knows, maybe it'll eventually turn into a decently sized list which will help provide good information and help users to keep certain "functionality" without a lot of effort (i.e. discovering a site doesn't look the way it should and having to first identify the problem as Smart Referer, then having to figure out the proper rule to fix it). I'm certainly a fan of having a "catalog" of fixes for various things.

All of that said, I personally use uBlock Origin to block all remote fonts by default, and only enable then when necessary, due to the fact they can be used to exploit a browser/system. I've seen the argument made that doing so constrains the artistic intent of the page developer or some such, and that without allowing them the Internet wouldn't be where it is today, and that may be true. Personally, though, I prefer keeping my system secure, protecting my data, money, privacy, etc, and so I'd rather read a page in a standard font than a slightly different font, considering they're both perfectly readable and there's little real difference. So I would recommend to @ronjouch and others to consider this before enabling fonts just for the sake of making these look a little prettier.

That said, I also not only see no problem in allowing them with Smart Referer, I think it's advisable, because the fonts can always be blocked by uBO if desired, and I don't like when more than one thing is blocking something, because it makes it exponentially harder to unblock it if desired. So if I wanted to see the original font on that page, I would have to add a rule in SR AND unblock fonts in uBO. I think most security-conscious people, the type that are going to care about it, will be running uBO (or should be), and so that can be relied on to block, or unblock, it. The only issue with that is the fact that SR is blocking it for different reasons: to prevent the referer from letting typography.com know where you are. So if it's whitelisted in SR, then the user unblocks it in uBO, they would think they're just slightly reducing their exploit protection when in fact they're also reducing their privacy. But that's where putting it in a separate, optional list, with a good description, comes in. I also wonder, does typography.com have to receive accurate information? That is, could it (and potentially others) be set to always receive a particular site, e.g. google, as the referer?

[ReporterX]

It is welcome to let users decide. Create two whitelists. Explain briefly the purposes. Let users decide. I don't really care about the fonts. I won't let it on.

[ntninja]

This issue has been moved to GitLab: https://gitlab.com/smart-referer/smart-referer/issues/103