I don't know if I'd trust IRC.com.
[1] https://bpaste.net/show/932b93fc2dce
<rdv[swag]> ENOUGH
<rdv[swag]> THIS IS MY NETWORK AND I WILL RUN IT THE WAY I WANT TO RUN IT
<rdv[swag]> YOU CAN ALL QUIT FOR ALL I CARE
Oh and PIAs support site and customer DB were compromised using a deserialization vulnerability in kayako. They never bothered to publicly acknowledge this, clearly a very "privacy oriented" business.
Kayako seems to have taken down their page detailing this particular vulnerability. Their helpdesk product used to store users sessions as serialized objects in user-controlled cookies, allowing attackers to execute arbitrary code by just sticking an appropriate php object into their cookies.
Any automated auditing tool would've immediately discovered this bug, so clearly PIA just didn't bother.
The cookie looked like this, it's impossible to miss the serialized php object:
Set-Cookie: SWIFT_client=a%3A1%3A%7Bs%3A15%3A%22templategroupid%22%3Bs%3A1%3A%221%22%3B%7D; expires=Wed, 28-Dec-2016 23:24:13 GMT; path=/; httponly
The IRC server software used by Snoonet, InspIRCd, does not contain any functionality for message interception (it doesn't even tell server operators the contents of a message that has matched a spam filter) and at least on the infrastructure I have access to Snoonet does not have any message interception capability either.
Can you please detail when this was? I would assume based on your example in December 2016, however PIA Support wasn't using Kayako in December 2016. For clarity, I run PIA Support and one of the first things I did when I joined the company was replace Kayako.
Looking at some file timestamps on my laptop, I guess this was around feb or april 2015?
I’ve been running the open source kiwiirc.com project for around 7 years and have always been very careful of who has access to what and so far has been clear of any issues. Hopefully I can now bring the same scrutiny and planning to IRC.com too!
On the other hand, I want to give the benefit of the doubt that they are somehow improving the IRC protocol in some meaningful way.
irc.com is a domain purchased by Andrew Lee of Private Internet Access last year. Formerly, irc.com had a letter written from him about his goals hosted on it:
At the bottom of the page opening there is a link to "London Trust Media Holdings":
Some of the brands listed:
* Private Internet Access
* Linux Journal
* freenode
* snoonet
and others
In terms of strict protocol improvements, the IRCv3 WG is the real place where that's going on, the most authoritative thing in terms of introducing new stuff across the IRC infrastructure these days: https://ircv3.net/
But, for new developers looking to get into IRC today, the resources aren't as available as they could be. Sure, there's a bunch of code to look at, libraries you can use to get started that seem to work fine. But when you wanna start digging into the wire protocol, how particular commands or functions work, how to actually approach writing a client/server from scratch, all you have are either the RFCs, some newer resources like the ircdocs/IRCv3, or stuff spread across 20+ year-old textfiles and pages all across the net. My intention for the documentation side of the Foundation is to build up information on how to use/parse commands and numerics, how widely they're used (in terms of software support), and how to really dig into and approach development with the protocol – since that feels like the more valuable information to be out there right now for new devs. It'll be linked to and public sometime soon, it's just that building up a swathe of documentation large enough to show we're serious about it takes some time (if you want those docs to be decent-quality, at least).
For what it's worth, I'm both the primary writer/maintainer of the Foundation's developer docs work, and the maintainer of the more community effort https://ircdocs.horse/ , so hopefully I'm on the right track with supporting devs in the protocol documentation sense.
If there's any questions or suggestions for directions to take on this (stuff that you, as a dev, would find useful for writing IRC software), please let me know! Even if it's not there for initial launch there's a fair backlog of stuff I'm looking to make up with this project.
Please don't do that. I like the fact the IRC is controllable in plain text via commands. Also, what is wrong with knowing about servers and ports? Why is it that IRC should be changed to appeal to the masses?
Everything IRC.com is working on usability-wise is happening on top of the existing protocol. If you're an advanced user you'll be able to connect to the server with your IRC client of choice just like you always have to any other IRC server.
Nobody is going to stop you from just using the “old” protocols. Maybe it’s even backwards compatible in the way that right now you can also add port 80 to a URL but you don’t have to.
Now everyone including grandmothers knows what a pen drive is.
And people are using a chat application 99% of the time. Anything they need to know to chat with their friends, they will learn, fast.
IRC did not die because it used ports and servers. That actually had nothing to do with its decline.
IRC was replaced by something without the feudal structure of founders, SOps, and Ops, and the medieval control they had over normal users, muting and kicking people off channels all the time.
It was a social issue, not a technical one.
And at the rate things are going, that percentage is only going to be going up. We're tunneling more and more over HTTP(S) -- lately, DNS over HTTPS has been unleashed upon humanity --, so ports as a concept are kind of an endangered species at this point.
I have to look through the source code of other IRC server implementations regularly when checking for cross-server compatibility and looking through ngircd's source code is always a pleasure. Its extremely well written and easy to follow unlike the irc2-based IRC server implementations (UnrealIRCd, etc) which usually are a pain to find out what they're even doing.
IP spoofing is possible on ratbox and charybdis; host cloaking is possible on charybdis but I would not depend on it. Personally I believe IP addresses are public information, but for those who don't agree with me, it's super easy to spoof hosts. Not to mention, both ratbox and charybdis support alternate I:lines (connection classes) for bouncers and the like.
if there are IRC servers that can't be trusted, they can't join the network, and hence will form a network of their own. there are dozens of networks out there (hundreds if you include smaller ones), and each one is an island. if i am on a different IRC network than you, then we can not talk to each other.
the only worthwhile improvement of IRC would be to turn it into a federated protocol to rival XMPP or other alternatives. i am not sure that is even possible though, but i wish it is, and i wish that this is where irc.com will be going.
i do look forward to see IRC brought into the modern age.
One way around it would be to stick to embedding of content only from a small number of known sites, but even then things like YouTube can still show geography of viewers iirc. Plus if those sites get tired of your bandwidth they can just block you, no negotiation of money if you don't have big bucks.
But regardless of how it's done, when you host your own actual server, you're now liable. You're identifiable, and In the U.S. identity is all that's required for any civil case, which could be thrown at you by anyone for any reason. When you host yourself you're taking on legal liability for your users, too, such as underage users that get access to pornography through it.
And before anyone proposes Matrix to fill in that blank, I do not believe that it is at all suitable for the goals it is trying to accomplish.