Glad to see you guys love our project the same I do
I have to admit I didn’t read 100% of this threat … but I think @janitor is right with his opinion that:
does have pretty much the same effect the modified link has … @happybeing Why do you think the link-solution is so much better than just a safe-link with hint …? Because we now need Firefox to use the safe network …? (Most people I know use Firefox … so I wouldn’t see this as a problem with people around me … but yes it is a barrier and if we talk about browser support that really could be an factor …)
Unfortunately, if we’re going for mass adoption, that is statically not the case across the world:
Usage share of all desktop browsers for December 2014:
Browser | Low Est. | High Est.
Chrome: | 22.7% | 49.7%
Internet Explorer | 17.5% | 59.1%
Firefox: | 11.9% | 18.0%
My proposal is based on “safe:” not being possible - if it were possible that would be worth considering. Given that we can’t use “safe:” this proposal need to be considered relative to the other viable alternatives so far, and any new ones we can come up with.
In the place where the initial safe:// link would be posted there could be two hints (“if you don’t have this Firefox extension, click here to access the SAFE Network in no time; users of other browsers click here to learn more about SAFE”).
Most people don’t want to go to another site to read how get started. I’m sure there’s some “law” of most users giving up if the goal is not a click away. I would even skip all the info and just provide a link to download Firefox; if they don’t want to do that OR (those who already have it) download the plugin, the conversion rate of those who do make it to the “Why SAFE” page won’t be high.
There is no reason to not have the Why SAFE page. App creators don’t have to send people to it, so the both approaches can coexist. That’s why I am not against the idea, I just feel a simpler solution will convert users better.
This is to be worked out of course, by my first thoughts on a walk just now are:
we start with one approach, whether .safe or safenetwork.net/ or whatever (if the latter I’d recommend we look for something shorter than safenetwork.net, although I do also like the descriptiveness of this long form)
later, much later, if we feel able though mass adoption to push for our preferred standard on existing browsers, we have the option to create a SAFEnetwork browser that handles the above form, but also understands the “safe:” URL form. If this was a SAFEnetwork only browser, users would know it is for SAFEnetwork and not the old web. If it handles both, it could become popular as an easier way (than browsers that don’t support “safe:” URLs) to access the two networks interchangeably.
That’s just some initial thoughts - I think there’s a lot to consider there as to if and when we might do that, issues that don’t necessarily get resolved until the “much, much later” time. But shows that an initial scheme could be a stepping stone, rather than locking us in to a less perfect style of URL as some have feared.
TL;DR we can conceivably switch to “safe:” if we can first manage to achieve a very large user base (significant percentage of the web).
This is another reason to prioritise mass adoption: because if we become a standard, we help define a future, and future design patterns (not just technical standards), that embodies the values of decentralisation and secure access for everyone.
ok - i’m with @janitor here - a landing page “why safe” doesn’t help in my opinion … if you try to convince people then they get a feeling it would be a big decision and want to think about it later “when they have the time” …
just a link with hint “this is a safeNetwork link! You need the Browser Addon otherwise you can’t see the content!”
[this way they ‘need’ the addon and don’t even start to think if they really want it ^^]
and for the sake of a higher adoption rate I would agree that the pseudo-TLD *.safenet wouldn’t be the worst choice @happybeing …
…I know this creates a risk for people in difficult countries… they’d have to be careful to only use their safe-browser/browser with addon … @Tonda this is a problem … I agree … it is not possible to use *.safenet 127.0.0.1 just in your host file to prevent this MitM-attack … is it …? (EDIT: googled it … doesn’t work)
EDIT2: and maybe the TLD-thing and browser support for chrome isn’t just only important for users … but even more to convince shops/content-creators to use our amazing network
1.) I like the idea of this domain redirect in terms of getting people onboard, however I think the security concerns with regard to people following links that some agency could (via the monitoring of ISP’s) then use against people is very bad. E.g. I share a link to something being sold on safe-exchange and someone follows it without a plugin - they get redirected and their ISP picks up the full requested address; the government then knows that the person might be looking to purchase this ‘something’ and if it happens to be illegal (as they can cross-reference the requested link with what is on the SAFE network), then this person get put on a list and potentially persecuted.
2.) I imagine that the ‘plugin’ for the browser is a PLUGIN … NOT an ADD-ON. So, it should be cross-browser compatible as it’s compiled code akin to adobe’s flash plugin. With a proper plugin it should be easily doable to use SAFE:// and in-so-doing we can avoid any leakage of information from the user to the outside world … and that is part and parcel to what SAFENET is about IMO.
3.) Worst case is we need to make our own browser. If we were to make an ADD-ON anyway, then taking the open-source code of say firefox and reworking it to be SAFEFOX seems a no-brainer, would be a safer alternative (in terms of leakage), AND would likely generate publicity for SAFE on it’s own. Consider that the Tor people already have their own browser hacked for the Tor network to prevent leakage – so honestly I think this is where we need to go for SAFEnetizens as well.
4.) Perhaps we could petition FIREFOX and other browser devs to build in a catch all for SAFE:// addresses to just redirect them to a search for the safenetwork (and not the link they put in). I big ask, but such would accomplish the same thing as Happybeing’s proposal.
Can someone briefly tell why we cannot use or make it happen with safe:// or maid:// ?
IF we have to go for a TLD would that not make us all more dependent on third parties ?
As far as I got it ooo:// indicates just a type of protocol used , which we are or will be … ;
existing as a new and decentralised private flavour of http:// and https:// mixed with safe://
What is exactly the Problem with having a simple approach that people can naturally relate to ?
This sounds a big issue, but I’m not convinced because the context is almost always going to someone shares a link which someone else could just as well receive for an equally dangerous resource on the current web.
So the recipient either knows it’s a dangerous link and:
takes precaution (e.g Tor/VPN) because they know it might incriminate them, or
knows they are taking a risk that their ISP or some other agent might get to hear about it
The only risk is for people who think it’s safe because they’ve been told enough about SAFEnetwork to think it’s safe, but don’t yet know enough to realise they have to not use a normal browser.
This is a very low probability to my mind - if people are going to access dodgy resources, the kind that might get them persecuted, they are almost certainly savvy enough to do their research first.
And people who don’t know how to access dodgy URLs still generally know they are easily spied on by all and sundry, so again, they are both a) unlikely to knowingly click on something dodgy, and b) unlikely to be persecuted if they do - because they are not the kind of people who they are looking for!
Large numbers of people must surely visit dodgy URLs on the open internet every day. So this is not a new problem, or I think likely to be a significant cause of persecution, currently. So I don’t think it will be in this case either. I think the way to deal with the increasingly pervasive snooping (eg logging of website visits by ISPs), is to accelerate the number of people protected by SAFEnetwork add much as we can.
So when I consider the likelihood of people being hurt by this, compared to the likelihood of many more people being unprotected and likely to be hurt because SAFEnetwork grows more slowly, and maybe never reaches a 100 million users, I don’t see this as sufficient reason to be cautious.
A TLD is not a solution, as already explained above.
It’s no different from posting links here. It’s actually worse, because this domain can’t be taken away (as long as renewals are paid) for no reason, while any made up TLD can be taken away by someone who actually applies for it.
Lol! Yeah its a bummer…but can you imagine being like “Hey Google, we want Chrome to be able to use a custom protocol plugin that will black out all your advert/user data for any user (potentially millions of millions!!!) who install it, you guys cool with that?”
I don’t think getting them to give up revenue of that possible scale would be an easy sell!
hmhmm - so you’d prefer to not have chrome support - firefox only - than using a TLD …?
do you think it would slow down adoption…? could it be beneficial to use the “safe-protocol” [not yet implemented in chrome] as kind of marketing strategy …? would people then see better the difference between safenet & clearnet …?