i think we’re on the same page - it has to become it’s own real internet protocol 
… but I think for accelerating things it might be an idea to use the TLD-solution short term … doesn’t change the long-term-plan of course =)
1 Like
Can you explain why would someone (a SAFE site owner, app developer, etc.) create links to .safe TLD which may get hijacked (and even take visitors to download malware) just couple of months from now?
1 Like
I disagree - in part. It is most certainly a valid concern, albiet it has a minimal surface area for attack. Caution must be used when creating any standard that is to be followed on the Network.
That being said, I agree that it should not have a show-stopping effect, and that ways to address this concern be investigated.
3 Likes
Ok as long as “safe:” is the long term plan I’m happy
I was just worried that wasn’t gonna happen anymore
1 Like
As you mentioned .safe will be a valid TLD maybe/probably so we wouldn’t use that.
If we’d take .safenet or .snt or .safenetwork I wouldn’t see a problem. Applying for a TLD takes time … you can’t hijack it that easily - and even if it becomes a registered TLD it only would effect people without the addon and not the ones with it.
The Tor network was running on an unregistered TLD without problems for years … what would stop someone from using a safe network link …? you’ll have to update your website anyway from time to time … and you’d notice if .snt could become a problem …
ok - thought while having a shower / proposal:
I don’t know how almighty chrome addons are …
Would it be possible to scan EVERY site a user enters for links like safe:www.riddim and replace them with http://www.riddim.SafeNetworkLinkThisTopLevelDomainWillNeverBeUsed …?
then again every .SafeNetworkLinkThisTopLevelDomainWillNeverBeUsed-Link could be fetched by the addon and the Safe-Site presented …?
This way no hijacking would be realistic, we could stay with our safe:-protocol and those chrome-users could use their beloved browser as they are used to …?
That is a completely ridiculous comment.
If someone can register .safe, why couldn’t they register .diwdpd?
And in the second sentence you claim it wouldn’t be a big deal because it would “only” affect people without the add-on. That means it would affect everyone who could possibly make use it, which I already pointed out 3 or 4 times on this page.
of course they could - but they had to officially apply, find enough supporters and so on …
… but I don’t want to argue here - i like my second idea better anyway 
…
Sadly the picture I had in mind isn’t as intuitive I thought it’d be …
Because if Chrome can’t handle safe: people couldn’t type in addresses … so you couldn’t use those links in ads …
@janitor What do you have to say for the “chrome-addon replaces safe:-links with *.s-links and all the safe-network only uses safe:”-proposal …?
@happybeing too much confusion …? or would you say worth thinking about it …? Chrome users would be in their own *.s-ecosystem and firefox-users in their safe:-environment … the point where confusion could happen is if you want to forward a link to someone using a different browser…
EDIT: @whiteoutmashups do you happen to have a good idea how such a difference between the chrome addon and the firefox addon could be illustrated fool-proof …?
What supporters?
Amazon owns .safe. Some other guys own .rocks.
That has nothing to do with supporters.
1 Like
That’s a killer for me. The same issue is stopping us using “safe:”, so I don’t see any benefit in your proposal I’m afraid.
@smacz we agree “it’s a valid concern” and we should try to address it, and it should not be show stopping… I don’t see the area of disagreement! 
1 Like
hmmm - okay - I’d see the benefit that every chrome user could use the safe network and share his links with other chrome users + if some day chrome accepts implementing the safe:-protocol not every Safe-Link would have to be changed again back from www.happybeing.safenet to safe:www.happybeing
these are 2 big points in my opinion
Neither point applies to the scheme being proposed in this topic as far as I can tell.
The scheme being discussed works across all browsers - as described in the OP.
Later we could extend that to also allow “safe:” URLs, but which would (in the example I gave) only work in the SAFE Network’s own SAFEbrowser - something I have suggested might be used exclusively with SAFEnetwork.
But that’s not part of this proposal - I just mooted it to show that the proposal leaves open the path to supporting “safe:” URLs in future. This would not require conversion from one format to another - the existing addons would continue to work (just not understand “safe:” URLs) and the SAFE browser would be able to support both formats simultaneously - but could make it simple to share one form or the other, defaulting to the universal form for greater compatibility.
Conversion would only be needed if we wanted to drop the support for an existing URL format, which would be of debatable value, at least until the point it was so out of date it was no longer an issue!
Let’s just do it anyway , because we want : safe://
Eventually , even Chrome will somehow include it
1 Like
I think a better way to implement your idea is to simply have the browser symbols without the links showing, the text next to the symbols is a descriptive tag (EDIT: use this when javascript is off)
Even better would be to use a little javascript and only provide the correct link for the browser being used.
And somewhere on the web page is a link to the browser plugin & launcher installers
2 Likes
both points apply to the scheme i proposed - but as you said it’d be a killer to have different appearance between 2 browsers … I myself wouldn’t think so - but I probably won’t be the one programming the addon … so I don’t get to decide ^^
just in case you missed it and I’d go with *.s now instead of *.SafeNetworkLinkThisTopLevelDomainWillNeverBeUsed …
The following point has not been considered so far in this topic:
This means we need to reconsider the security implications of using a URL that the browser - without a plugin - can in fact interpret, because it means that rather than sending a SAFE URL to a search engine, a browser would visit the website we administer instead.
Anyway, as I’ve suggested in the following post, I suggest that we revisit this discussion when we’ve got a better idea of the different options.
1 Like
Well, let’s revisit it.
Now that there’s an http proxy server to be added to Launcher, we know that it will be communicating over http:// instead of an alternative scheme.
This is what’s been accepted - using a TLD of .safenet
The browsers can be configured to use the local proxy only for requests with the .safenet TLD. The configuration can be simplified by providing a PAC file.
– Launcher as a REST Server
1 Like
I’ve been shying away from large threads for the past months, likely because of not having the time of sorts to read. I still don’t at all! But I just started reading some of the heavier/heated sections of the past 20 days of posts, and I find it fascinating how people are looking for the best solution—as an emergent discussion just after/as the core devs work on the incredibly time consuming foundation of the network code. Really makes me want to read everything from top to bottom, and hopefully other people. Lots of people, ideas, interactions, etc… wouldn’t want to miss out. Peace
2 Likes