uBlock Origin Rule to block non-safenet-content on safenet

one moment! this is a filter for clearnet-links on safenet-sites - is it …? :open_mouth:

(since i use ublock origin anyway … this took my 5 seconds or so Oo … nice :smiley: )

3 Likes

Yes.

Maybe I should explain the rules:

  • ||$domain=safenet Blocks all urls in any *.safenet-domain
  • @@||safenet^$domain=safenet is an overwrite on that to allow all *.safenet-domains on safenet-domains.

Thus in combination: this blocks all “clearnet” requests from within safenet.

9 Likes

thx for the explanation :slight_smile:

2 Likes

Very useful tip, thanks for sharing!

3 Likes

clever and simple ! Thanks for sharing

you still need to allow request from safe to 127.0.0.1:8101, though

4 Likes

Fabulous. . . . . . !

Perhaps on sites that are designed to use this filter one should put up a sign of some sort or conversely sites that link back to content on the clearnet should put up their own warning. What I’m thinking is some sites may say link to youtube videos. Now a safesites that block all clearnet content won’t see said videos. Will they even see the links to said videos? If not then they won’t even be able to go and download the content directly. Ergo for them the site will be broken. Now this could easily be fixed by simply downloading the videos from youtube and simply reuploading it to SAFE, and I’m sure people will start doing that more and more, but one has to know what content is streamed from the clearnet and what content is beamed directly from SAFE you know? I’m using youtube as a simple example but we all know there can be extensive heavy lifting in code behind the scenes of any website. I believe some web languages can depend on externally hosted libraries and such that could eventually be hosted on SAFE but for now are usually hosted by companies like Google and Microsoft for example, again on the clearnet. God forbid anyone uses google analytics or something.

To expand on my previous thought. One could probably rig up a little extension to read a bit of javascript or json code or something embedded in the site’s code itself or as a file or something if not that basically said “Warning: This site has clearnet content in it.” Then rig up some flags to declare what kind of content it is. Then the user is given a choice as to allow the content. A user may allow a simple youtube video or set of links and disallow a bunch of google analytics and ads. Or whatever other conditions they may set. It would kind of be like how your phone asks for a bunch of permissions when it wants to download an app, although hopefully with more control. (If you guys think of a better or more efficient way of doing this I’m all ears.)

@anon81773980 I was thinking this might be a practical example of where one could employ the whole bitlaw situation as this would essentially be a common COLA scenario. Does the user accept clearnet content or not. Obviously those who are going to the extent of using ublock to filter it out do not. But there may be conditions where one may find it acceptable or nessesary. Ergo a COLA. Ultimately security is like pregnancy but that’s again up to the user to decide.

1 Like

I think those are some good ideas. However, I appreciate what @lightyear has done and it’s usable right now.

1 Like

We can change the API address to http://api.safenet
This will allow us to use this filter without problems.

3 Likes

just thought i’d mention i changed my filter now to

||$domain=safenet
@@||safenet^$domain=safenet
@@||localhost:8100$other
@@||127.0.0.1:8100$other

this is how it works for me
but how does it happen that i use port 8100 and you 8101 @nice …? or was that a typo?

mmm I took 8101 from the original pac file that Maid released.

ok - for me only 8100 works - if i allow any other port nothing works :smiley: … strange …

my bad

8101 is the port firefox uses for connecting the launcher as a proxy on localhost.
8100 is the API requests port, which we are willing to let open in ublock.

In accordance with what has been said on the launcher security topic:

I believe the usage of api.safnet is the better way to go, and disallowing localhost is a way to better enforce that. Agreeably, this breaks many current apps (including my very own Ghost in the Safe), but that means our apps are broken and should be fixed, rather than including that bad rule. I will see how I can make that happen for GitS soon, but I’ll not add that rule in the topic description as I recommend against it.

1 Like

As you said, it would be great to stick to api.safenet for web apps. But for the desktop apps, it would be better to connect to the launcher directly rather than connecting to the launcher via proxy. This would be a needless redirection.

1 Like

@Krishna_Kumar

As you said, it would be great to stick to api.safenet for web apps. But for the desktop apps, it would be better to connect to the launcher directly rather than connecting to the launcher via proxy.

What does “directly” mean? And, can you explain how the two methods differ - I don’t understand. Thanks.

1 Like

Agreed. There is not point disallowing the usage of the Launcher API directly. It has to make an interface available locally either way. But this post only focuses on the browser part of that equation anyways. For that disallowing localhost and only allowing api.safenet as you proposed in the safe launcher post sounds very good.

He is talking about allowing (locally run) Apps to directly connect to the launcher via an HTTP-request on specified port. If the Launcher would not react when asked for localhost but only if the hostname given in HTTP-Headers is api.safenet that creates an unneccessary burden in development (which makes it by no means any more secure). One way to implement this second way is to urge every app to use the launcher as their proxy and only connect to the API indirectly that way (rather than directly on localhost:PORT).

Did that clarify it?

1 Like

@lightyear

Did that clarify it?

A little. I think I am not understanding exactly what “if the hostname given in HTTP-Headers is api.safenet” means. Let me see if I understand…

One method is via the proxy so in a browser app, it would not matter because launcher can/could respond to either localhost or api.safenet. In this case it’s a standard HTTP request, which means port 80, which the Launcher can respond to only if the user has set up the browser proxy to use the launcher port.

But a standalone app has the option of connecting directly to the launcher port on the local machine (localhost). In this case it does not specify api.safenet as the domain, it just sends an HTTP request to the appropriate port in localhost. Alternatively we could force standalone apps to access the launcher though the proxy, in which case they would…

No, I can see this doesn’t quite add up so I’m not quite there yet :-/

Well, you said it all though and it was totally correct. And “this doesn’t quite add up” is exactly what we were discussing: encouraging the use of api.safenet from the web shouldn’t mean that we only allow local apps to access the API through the provided proxy. That just doesn’t make any sense :wink: .

1 Like