Communication Methods of the Future

Re: Communication Methods of the Future  

  By: Top(Asgardian) on 27 December 2016, 5:13 p.m.

I do agree with a web browser. It would get our name out, as well as it would be a stepping stone. I will say I would use it. For that... I only use a cell. (─‿─) So it's a bitter sweet. It would have to be formatted for mobile. Before I can use it.

Re: Communication Methods of the Future  

  By: BohZao(Asgardian) on 27 December 2016, 5:23 p.m.

In the browser we could do a LogIn fixed menu for asgardians (Ours ID +Password) , it will help US to mantain our things in security and could possible make curious people search about this menu(believe theres a lot of user that search things because of the curiosity)

Re: Communication Methods of the Future  

  By: Ryan.zohar(Global Admin) on 2 January 2017, 9:34 p.m.

What would it take to develop a browser? Is there a way to possibly create a plugin for existing browsers, such as Chrome or Firefox?

Re: Communication Methods of the Future  

  By: Dirk Baeyens(Chapter Advocate) on 2 January 2017, 9:39 p.m.

I would not create a browser but rather a portal.

There are also online OS's that you can use as a computer.

Grtz, Dirk.

Re: Communication Methods of the Future  

  By: Lloyd Cox(Asgardian, Interest Mod) on 3 January 2017, 6:05 p.m.

Building a browser from scratch would be the best option in my opinion, you can build it exactly how you want it then.

Re: Communication Methods of the Future  

  By: EyeR(Asgardian) on 4 January 2017, 3:56 p.m.

What would it take to build a browser? minimally coders. Preferably collaborational tools. And a lot of thinking about what you're doing, and why.

Building a browser from scratch would be a time-intensive process. Using an existing open source base(Chromium, FF, etc) however would save a lot of time. The browser itself shouldn't require a "plugin" or external modifications in order to provide services, all required being able to be delivered to the client with the page. By using an open source base you can reduce workload to pretty much removing "features" that would render the browsing experience less secure, like various data leaking functions, execution of random third party code as a default, etc.

We are in more desperate need of a "portal" more than a browser. The existing site/forum would have difficulty conforming to "portal" but it's a start, and the technologies leveraged to do so look applicable for easy expansion. The "online OS" I believe would be in reference to "live disc" - unless they did actually mean an online OS, like EyeOS or chromium(the entire OS was supposed to live in the browser, hence the browser being developed first) - I did mention somewhere about potentially embeding an OS into a USB card reader that would extract data from passport for use as auth on Asgardian services, the loose intent being an OS that hasn't already been compromised through either poor usage habits or unsafe software selections that can be run on anything that will boot from USB.

As to "formatted mobile" - that's just .css.

Re: Communication Methods of the Future  

  By: Lloyd Cox(Asgardian, Interest Mod) on 5 January 2017, 8:48 p.m.

If the browser ever did get developed or portal, you definitely get my vote of being one of the team members EyeR.

Can you clarify the last sentence please, do you mean a personalized card/USB that has an OS embedded on to it, so that in order for an Asgardian to access Asgardian services (portal/browser plus any others) they must use their card/USB to sign in or something?

If I have understood correctly I think that is a brilliant idea!

Re: Communication Methods of the Future  

  By: EyeR(Asgardian) on 5 January 2017, 9:23 p.m.

The loose idea was to use passports as authentication to services - A combination of physical posession of the passport, and the passphrase to unlock the private key inside one of the digital "pages" assuring the user is actually the citizen, as much as authorised for access -=- requiring ofc a passport reader. If we build the reader ourselves, we can include something that identifies as read-only generic USB mass storage or as a card reader -=- Similar to how USB 3G/4G modems modeswitch from a "Install CD" to implant ISP malware before the device identifies as a modem. This storage could allow for provisions of tools, and potentially even a full OS that could be optionally booted for a potentially more secure environment.

Re: Communication Methods of the Future  

  By: Doc.Flay(Asgardian) on 9 January 2017, 4:19 a.m.

I agree with the idea of using standard digital certificates for authentication and encryption, because all main OSs support them already. No extra software or plugins are needed for anyone. PGP is desirable but should be considered an extra or alternative. Standard SSL/TLS S/MIME email certificates can also be used to authenticate a user to a website, and used in various communication apps. There are not many free certificate vendors, but I posted a few in a blog about email security https://drflay.wordpress.com/2016/05/26/easy-certificate-encryption-for-email/

I would recommend that Asgardia plan to become a certificate authority, so that ID management can be kept in-house. Perhaps the EFF could be of some service here.

-

Mumble chat and VOIP system uses standard S/MIME certificates to login. I suggest Mumble would be a good start point if you are looking for an Open Source group client with robust authentication. Asgardia can host an official Mumble server without much extra expense, and thus have control of the comms network.

-

The only reason Google have a browser is because they are an advertising company, and it is a tool to rake in more money from a captive audience. They reinvented a wheel and made it more bloated, with less features than other browsers.

As a long-time beta tester for Avira and Vivaldi browsers, it is very noticeable that my system sufferers from a huge amount of wasted space due to duplication of everything. It will take at least 2 years to get a solid and safe new browser into shape, so you need to think about what we do now.

If you want a secure and private browser, do not try to reinvent the wheel when there are other projects already better placed to fill that need, with developers that are already familiar with privacy and security issues. They are the "professionals" and even they get things wrong (no browser is flawless), so any belief that a new Asgardia browser will be trustworthy simply because it is made by Asgardians should be put to one side.

Avira have already set their heart on making Chromium into a private browser, and as the "Avira Scout" project is lead by the main developer of the EFF Privacy Badger project, you can guarantee a more private and safer experience, also backed by the worlds top free Anti Virus provider (based on monthly average test results).

Vivaldi browser is a more community-driven product, aimed at power-users, journalists and researchers. It also has a big focus on privacy but due to the amount of community requests for features has been slow progress, which is how it would be for a new Asgardian browser.

Re: Communication Methods of the Future  

  By: EyeR(Asgardian) on 9 January 2017, 9:13 a.m.

SSL/TLS is commonly used to secure the transport, more than the authentication of the user. For user authentication it's far more common for X.509 - which is somewhat related. You'd definitely not need any form of "vendor" to generate yourself certificates using this method, this only really being required for HTTPS to allow third parties to independantly verify the fingerprint of the certificate you've been served in order to setup a TLS tunnel is from the vendor it's claimed, and used in the expected service.

Certificate is more a software feature, than an OS thing. There's only limited use in becoming a CA, I suspect it would cause more problems than it would solve long term, especially as these things are obvious targets. You don't need to be a full on CA to sign certificates, being able to deploy similar methods to self-signing with signing remote users keys for use with auth.

Mumble isn't entirely a poor suggestion, XMPP is older however - more development/bugfixes, more testing, more hours runtime without incident - and far more flexible, designed as a comms protocol more than an afterthought of multiplayer gaming, as evidenced by it's far wider adoption in many cases by "serious" firms, like google, facebook, whatsapp etc. Should be able to host that on existing resources, overheads are minimal so zero extra expense, and has ability to be operated in a de-centralised manner by way of allowing inter-server transport between users.

The only reason google have a browser is because they understood the significance of the chromium project, and what it would really mean to get the OS off of the device itself. The end goal with that being the device only really has to have enough code/power to fire up a browser and everything else happens remotely, through that browser - it only has to worry about displaying the content. Naturally, this entailed the development of the browser component first. This should lead to smaller, lower power draw devices that can do more with less. This also opens up things like software as a service at the OS level, the subscription model to which representing the most likely future of the commercial software industry. Microsoft have already started this with orrifice and have plans to move the OS to "the cloud" ASAP. As an added bonus, investing in that technology early allowed them to expand the data raped from users of their services to users of their fork of the software which will in turn take every service it connects to. "Advertising" is just one of the more pleasant uses planned for this data.

Browsers, as modern software goes, are quite tiny. Installing several different breeds should struggle to exceed 1GB, which is about 1/10th of a HiDef film packed in h264 inside and .mkv - or about 1/30th an average "AAA" game. Unless you've a seriously old machine(pre 1998) or otherwise rediculously small amount of storage accessible, it should be difficult to notice this consumption.

Midori might be worth a gander if you've not played with it, think that was forked from FF, but I could be easily be wrong.

When it comes to making a browser more secure, for the most part, "features" are what make it insecure. Commonly. Things like BeEF just wouldn't work without them. I wasn't suggesting a browser we'd had built would be secure just 'cause we'd built it, more it can be made secure by removing the additions that are not strictly required, and making sane those which are. Development speed would depend entirely on the contribution pool for the project. One person wouldn't go very fast. 1% of our population however would be able to push out updates rapidly.

With regards to A/V software generally, consider the previous history of the vendor, and their staff. Typically, the person most qualified to venture into such a role is the sort of person that has previously written virus, possibly even responsible for some breeds doing their rounds decades later, and still updating them. To ignore the glaringly obvious conflict of interest that arises here, then consider the lack of open source nature of such things. There's a reason they obfuscate it, and it's not even remotely about keeping nasties from prying into operations or giving competitiors an advantage. Clam open sources their engine, for example, and it is still resilient enough to be professionally chosen to form the backend of many solutions deployed in public facing environments, even sometimes on government systems - commonly sanitising emails but it should be good for most purposes. It's also worthy to point out that most of these things tend to operate on some sort of "fingerprint" basis - meaning it's only as good as the list of prints. Unless it's seen it before, it's useless - additionally, shady government agencies have their malwares prints removed from these lists in order to remain effective. Lists however can be augmented, missing data added - but commercially available flavours are less likely to make this easy and even harder to find the required prints.