Every time you write code that requires Chrome or CEF or Electron, just remember: you are giving Google control over you and your users.
You are letting them dictate what you can and cannot do. You are letting them view your user's potentially private activities (URLs are always sent to Google without Debian's patch set).
You are becoming a part of their toxic culture, their neocapitalism.
@djoerd @awilfox @sorin This annoys me to no end! They did have something like that for a while some years ago, but then stopped. Electron is increasingly popular, and that's great for Linux because we get apps we never would've gotten otherwise. But why doesn't Mozilla make an alternative? They have to see the potential! Instead they make screenshot tools and the millionth way to send files over the internet...
That sounds like either Samba (proprietary protocol even if the implementation is open source), or NFS which is complex as all hell to set up in a small business.
Unfortunately file sharing has never really gotten attention by people who care about networking, security, and good UX.
Apple's AFP was almost good and had a BSD licensed version but they got rid of it.
@awilfox @troubleMoney @vertigo
I really really hope he meant something like nextcloud. Cause if not, that's the reason people call us nerds and don't want to hear us. Try to explain how to download file from your FTP server to your mom's female friend vs 'I send you this on facebook'. No need to get angry folks, it's how the world is.
@troubleMoney @awilfox @vertigo
My use case is a collaboration project I work with non tech people that we do in a spare time not in office. We use Slack to communicate and share files. It's vastly integrated (google driver, trello etc) and provides nice UX and it's dumb easy to use. Now try to convince those people that don't kniw what TLS or webdav is to configure an IRC client, install ZNC and learn how to use FTP
@troubleMoney @vertigo @mdfrg so yeah even if you have an office with dedicated IT staff, the only way you can hope to have SMB or NFS work properly in ways users can tolerate is with something like LDAP.
and let's not even start with the shift to remote work. then you need VPN to log in with LDAP/Kerb and use SMB/NFS, or worse, run everything public.
we don't have good solutions to these problems yet. and we need them. badly.
However, if you do, there's always Citadel BBS software. It offers a web-based UI as well as classical text-mode interface, live chat, supports file uploads/downloads, et. al. It's actually pretty neat.
But, again, I only need the ability to chat. I tend to send files over e-mail, and important information tends to get archived on wikis.
Your usecase may vary.
Some prefer the web interface, but some actually do prefer the SSH interface.
It's pretty awesome, actually. I do wish it were more popular though. Would love a console Mastodon interface that had more or less the look and feel of Citadel, for example.
proprietary software does not imply slavery.
it may be in bad taste, but like Linus, i prefer to use proprietary software that's well executed (Slack), rather than free software that is poorly executed (IRC).
however, in reality, i would prefer matrix if they would care more about security and less about shiny features.
welp, since you ask.
i have worked on basically every ircd out there: unreal, inspircd, ircu, hybrid, ratbox, charybdis.
i designed the IRC SASL binding, which brought the concept of pre-authentication to IRC, allowing things like I:lines (allow rules) to be selected based on what the services daemon said to do.
i designed and wrote an entire new services implementation called atheme, that was not derived from the ircservices lineage, that was intended to take away privilege from IRC operators and give it to the communities that existed on the IRC network. while IRC operators could override the security, they had to consciously make this decision.
using the atheme platform, we created a bunch of service modules that automated the most common tasks of IRC operators (spambot mitigations), which reduced the need for IRC networks to have so many IRC operators. we also attempted to reform the role of IRC operator into one of being a community leader.
but in the end, traditional IRC users, with traditional IRC egos, always kept winning out.
i suspect the main reason why this is, likely has to do with the fact that your average irc network operator is a prepubescent teenager who feels they are always right.
@kaniini @awilfox @SLRock @vertigo I send my complements for the work you've done. You cannot change people. nor should you ever try. These days devs shall already now they have to work on pair with some UX/PR experts by the drawing board before coding. The community beind IRC was always... specific, so don't get to gloomy with that. I think now it's a good time to reimplement IRC since it's primary used by tech (freenode) and with Matrix around the corner. What do you think about it?
I prefer to see freenode sunset and be replaced by Matrix (possibly with private internet access running a Matrix homeserver under the freenode domain), once a more stable and secure protocol is fleshed out.
The good news is that some of the charybdis people have started reworking the Matrix specs to introduce correct security.
But in a spiritual sense, I see Matrix as the correct successor to IRC.
freenode staff are literally the worst case of traditional IRC users I have ever seen.
People on freenode are legitimately afraid to engage freenode staff for their problems.
As somebody who was previously a freenode staffer, it makes me angry that the network has become this way, because the whole point of my work was to spread the original administrative philosophy behind freenode to other networks.
outside of EFnet/IRCnet, IRC has always been very authoritarian.
this authoritarian environment breeds meanness.
the reason why people are afraid to engage freenode staff in present day, is largely because engaging them can result in a k-line (network ban).
so now, when people on freenode have problems, they just move their community off of IRC (an open protocol), to Slack, Discord or Gitter (proprietary protocols).
the lesson is the same lesson it was 15 years ago: resolve problems through peaceful conflict resolution instead of k-lines.
rob tried to call this approach "catalyzing" because he felt that peaceful conflict resolution would result in more productive output.
the whole point of the atheme platform, as well as "atheme workflow" (the official way we suggested to run an atheme-based network) was to implement this philosophy.
but i guess it's easier to just ban people instead of actually solve things.
to expand on what i mean here: police uniforms show privilege, and this is seen as de-escalatory. but it is de-escalation through fear (fuck with this cop and who knows what will happen).
IRC operators in a traditional IRC environment are the same way. status is flaunted and many IRCds have created tons of ranks for the IRC operators, such as "Network Administrator" all the way down to "Help Operator."
these ranks are strictly cosmetic and mean essentially nothing on a technical level. they exist only so that people will see them in their IRC clients and know that they have that type of status.
it is the IRC equivalent of a paramilitary hierarchy.
it is, in some cases, useful to know if somebody is a cop, but is it useful to know what kind of cop they are?
the paramilitary hierarchy imposed by traditional IRC is what breads the meanness. the wrong people get IRC operator privilege, and then work their way to the top.
a good freenode example would be spb.
now, when it comes to the IRC paramilitary hierarchy, it is actually worse.
so this paramilitary hierarchy extends downward into the communities themselves, and the actions of the paramilitary hierarchy extend downward as well. for example, there are many channels that have `+b $c:#freenode` on their banlists, which means if you are banned on #freenode you are automatically banned from the other channels too.
that bad advice comes about as a result of overzealous channel operators feeling that they should "protect" their channels from people they most likely are never going to have any actual interaction with. because they are "trolls" afterall.
@kaniini @awilfox @SLRock @vertigo It scales for me - just as much as Facebook messenger with 10 friends. I don;t need anything better. We should stop trying to find universal solution for every case scenario - there is none. XMPP is (now) very, ver good for 1&1 and 1&few IM with file and media sharing.
i would say Matrix's protocol is going through a peer-review phase by the charybdis++ team right now.
the people involved with charybdis/charybdis++ have a lot of experience with S2S protocol security as applied to chat protocols.
now, the question of course is, who will peer-review the revised protocol, and to that one, i don't know yet. :)
as for the future of matrix?
i think increasingly lightweight implementations such as charybdis++ will win over dendrite (which is heavyweight) and synapse (which doesn't scale).
i see the role of matrix.org transforming to one of purely protocol stewardship, much like the XMPP foundation is.
Slack has a different security model: the communities just buy an instance from them and do what they want to. You just click some buttons to get one.
And the Slack client can be attached to multiple communities at once, so while it's obviously not federated, the control aspect falls to the community.
That is miles ahead of where IRC is.
With IRC, you get to either use somebody else's infrastructure and subject yourself to having to make sure that somebody else stays happy with you (unless they boot you off their network) or go buy a VPS from some company and spend time manually compiling and configuring ircd.
Then you have to learn how to secure it, etc.
I think you misunderstand what I am saying.
IRC from a security POV is so fucked that it is literally more pleasant to use proprietary Slack or Discord if you want full control over your community (even though these are proprietary, but you are at least paying for the privilege of using them, so hopefully that means they won't screw with your community).
Communities on, say, freenode, for example, have to consider very carefully whether or not they want to involve freenode staff with their problems, because that could create even more problems.
With the proprietary services, there's no staff to involve, because you are in control of who is allowed on the instance.
You can convince the convinced as much as you want but (sad) truth is, as far as IM /chat apps are concerned is more a question of who uses what not what technology is more RAM efficientband superior. Besides, Slack is just different service than Irc, it's designed for different needs and workflow so you're comparing apples to oranges here.
However I don't really agree Slack and IRC are different use cases. Channels, some invite only, allowing users to talk to each other and PM. Slack adds file sharing like DCC but otherwise it's just plain old IRC reimplemented IMO.
@mdfrg @vertigo It doesn't do message sync unless you use ZNC which is more software to set up, and its client side so everyone has to set it up. I don't know of any message search beyond grep on ZNC logs (or find in page if you open in text editor).
It usually uses TLS these days. It can support TLS only, TLS and plaintext, or plaintext only.
@awilfox I was surprised to see the world "neocapitalism" in this context, so I did a quick check on the definition of the term, and it doesn't seem like it's necessarily such a bad thing? I mean, it's certainly better than the rampaging capitalism that we have right now?
@awilfox @amdt Chromium and Electron are two different things, the Debian patch is for chromium, not the underlying web rendering engine shared with Electron.
Electron apps don't send URLs to Google, you are either misguided or spreading FUD.
Actually, one of the most privacy respecting browsers, Brave (https://brave.com), is based on an Electron fork (Muon).
Brave uses Chromium with changes, which does remove Google tracking, in addition to replacing ads on pages with Brave ads. Cite: https://arstechnica.com/information-technology/2016/01/mozilla-co-founder-unveils-brave-a-web-browser-that-blocks-ads-by-default/
Muon is not a fork of Electron. It is a framework similar to Electron, but based on the Brave fork of Chromium instead of CEF.
I'll Wireshark Atom later today.
So is Electron, which adds nodejs integration to Blink to build apps.
About Muon (which I know pretty well), just read the Readme: "Muon is a fork of the Electron framework which is currently used in the Brave web browser."
And yes, maybe you should wireshark products *before* making claims...
@fabricedesre @amdt I have already wiresharked before, but will do it over to 1) have logs easily accessible, 2) see if anything has changed in what it hits / what protocols it uses (QUIC, SPDY, or just HTTP), 3) use the current version.
I don't see GAIA in Electron any more, so that's progress, but there's definitely more than Blink in Electron; Muon's readme clearly says it uses Chromium source with patches. Blink itself can't support Chrome extensions, for example.
"one of the most privacy respecting browsers" brave does browser-in-the-middle to replages ads with it own, without user's consent (opt out-baspfed), it's the opposite of privacy-respecting