At GitHub, we faced the same issue when ZenHub [1] came out with their chrome extension. While, Slack is well within their rights to _ask_ you not to modify their user experience, it's short sighted of them to do so.
With ZenHub, we worked with them even closer because we saw that our users were happier using GitHub + ZenHub. We made it super clear that UI changes would likely break their app but that would be a risk for them to evaluate. In the end, it worked out well since ZenHub invested alot in their UI and became a long term partner of GitHub's.
From a technical level, I'd also take issue with this. You're customizing the output of their services once it's in the browser at the request of the user. If you're still interacting with Slack through the API and being a good platform partner (i.e. respecting rate limits), then I think you should be allowed to keep on. Disclaimer: I'm running a company on the Slack platform [2]
I’m not being a good platform partner basically because they make it impossible for me to be one.
I’d love to avoid reverse engineering their minified code and use well documented APIs. Unfortunately, that’s not possible nor planned (as they told me on a tweet I linked on the post).
I really feel both sides of this. On the one hand, I like customizing things, and I love to see users getting involved in platforms they love. On the other, I see how responsibly providing APIs is a big long-term burden that can prevent internal innovation.
I was talking a while back with some Mozilla people about the move from their legacy API [1] to WebExtensions [2]. It was a giant pain, but their old API exposed way too much surface area in ways that were too closely tied to the original implementation. The way I heard there were significant ongoing costs in trying to maintain the old API and support popular extensions while trying to improve the underlying tech and the user experience. So I get why Slack is very reluctant to expose API surface area, especially for the UI.
In deprecating functionality necessary for the extensions that made Firefox worthwhile for me, though, the reasons to prefer it over other browsers evaporated.
Have you considered asking them if you could continue running your system if you agreed to add a permanent large banner at the bottom or top stating clearly that your system may break user experience?
I realize they are saying something about privacy, so it may be their position to argue against every system that does what your's does...
GitHub projects is a much worse experience and still missing a lot of what ZenHub offers. It ranges from obvious holes like half decent filtering of the project board to niceties like viewing issues in a pop up modal rather than their own page (causing you to lose your spot in the board).
GH projects also has this arbitrary distinction between notes and issues, and notes are more or less useless yet the default when adding new items to the board.
> Worth mentioning that github ended killing ZenHub, by introducing github projects
Sherlocking is a well-known risk every tenant application must consider if they want to make a business out of it.
I would hope and expect that the ZenHub folks always understood github could just integrate the features directly, and not necessarily by buying zenhub.
I just reached out to joe (of this post) and I now recommend geteventbot to everyone. Small businesses run by responsive leaders like that deserve our $$$s
Really happy to hear that ZenHub has an official relationship with GitHub. We use the combo in my company and think that they work remarkably well together
I think you can safely ignore this cease and desist. Just change the name and add a disclaimer so your users know that by using your extension they are violating their acceptable use policy.
This is no different than any user writing a Tampermonkey script to modify any website they want to modify. Even further, this is no different than a user opening the Dev Tools console and modifying things there.
> I think you can safely ignore this cease and desist
Will you cover his legal costs for choosing this decision? Right matters less than resources if it's expensive to even be right. You can state your case here on HN without repercussion, not so when being sued (it costs to even state your case reasonably due to hazards of self-defense and it costs dearly if you lose).
Oh come on, I chose not to read every word and view every image on a web page -- it's my attention, not theirs. I choose not to download large images or ads -- it's my browser, they are sending me the bits.
And if I choose to run my own code in my browser why not?? Who's computer is it, after all?
> And if I choose to run my own code in my browser why not?? Who's computer is it, after all?
In your moralistic mind or in the courts? Because idealists are not immune to laws they don't like any more than the rest of us. This arm chair idealism is getting ridiculous.
There is no law that bans me from running whatever code I want on my machines (except perhaps some sort of DDOS software). No law compiles me to download some link on the net. No law bans me from drawing a mustache onto a photo in a newspaper I buy.
In the 90s the music industry tried to claim that the buffering data while playing music was making a copy of their data for which they should be paid or which they did not authorize. A few technically ignorant judges initially sided with this argument but it was eventually laughed away.
Your calling this "armchair idealism" makes me think you might be suffering from a legal system Stockholm syndrome.
It's not about what the law allows, it's about the cost to defend yourself. And yes, there are cases such as in web scraping where that has been ruled against the law (running whatever code you want on your machine...not about DOSing or distributing, just running). There have been other cases where simply accessing ToS-disallowed parts of a site has been ruled illegal too, whether we like it or not. That the OP is being asked to risk his livelihood and money defending himself for others ideals in light of these past rulings is armchair idealism. I made it clear in my original statement that it's not exactly about who's right, it's about the cost of being right, especially in non-obvious situations.
It's implied. Unwillingness to abide by a request from a company's legal team, especially after acknowledging receipt, can be used against you in court. Court cases about web scraping and other site ToS violations have referenced received stop requests when considering willful violation.
Are you serious? Did you miss the obvious subtext?
>Please respond to this message to acknowledge that you have received it. If you can resolve the matters specified above in the next seven days, that would be excellent. If you anticipate that it will take longer, please let us know. I’ve cc’d our Legal alias so that in the event that I am unable to respond, one of our product counsels will be able to provide any necessary assistance.
tl;dr: respond and desist or they will escalate to the next step. Legal action is heavily implied, and it's outright foolish for you to read that and somehow think there's no threat to sue, whether implicit or not
I guess the person you're replying to's point was to take it to the next step. Let them initiate legal proceedings (and pay lawyers) to do something.
Maybe it's foolish, maybe it's not, but this email cost Slack the salary of the person for the time it took him/her to write it. At least make them also pay for an hour or two of legal fees to have this taken down.
And in the process be potentially banned from the platform. This could cost OP his job, considering he built this utility to make Slack bearable to use in his place of employment.
A disclaimer would not work. Disclaimers might work where there is a risk that the user will violate the acceptable use policy but this cease and desist letter has effectively said that all users will violate the acceptable use policy therefore the disclaimer would be quickly dismissed by any court of law.
As a slightly bad analogy imagine a disclaimer that customers of a fairground ride might experience back pain. If it was found that all previous customers had suffered back pain then the disclaimer would not be enforceable and the ride owners could be sued for negligence.
False, how a website is rendered on a device I own is not enforceable (legally speaking) by a acceptable use policy or any website policy; otherwise people would just use that to deter ad-blockers browsers extensions instead of all the shady tactics commonly used.
Axel Springer (not to be confused with Springer, the publisher for scientific papers) is still trying to sue btw, they're trying to go for the angle that Adblocking prevents freedom of the press since it takes away their funding.
And tbh, Axel Springer isn't the most surprising entity to sue for this, the entire publication house is a bunch of asshats, who have been cited for being the most deplorable journalists and in one case someone argued that one should be as mean and rude as legally possible to employees of Axel Springer.
They have also succesfully sued the producer of an Anti-Anti-Adblocker since their Anti-Adblocker was considered DRM by the court (IIRC).
I don't think Slack would ever go after end-users who install something like this. But they could go after the creator, who presumably created a Slack account in order to be able to build the extension, and who therefore must have agreed to the T&Cs. This could include a no-reverse-engineering clause that prohibits the sorts of things that this extension does.
I don't personally know of anything that specifically. But I'd imagine that in most cases, things would unfold as they did here — with the creator pulling the extension rather than risk losing the lawsuit.
This just starts a death spiral though. Slacks next step is to start detecting the objecting code and banning users from using the web interface that are found using those tools.
There are a bunch of folks doing this already for ad blockers.
Try using Slack in a browser on Android. It doesn't work. I find that really objectionable. They don't (last time I asked) distribute an APK. Instead they directed me to a pirate APK site, so I don't believe it's for security.
Sites like APKMirror aren't pirate sites, as they only host APKs that are free of charge. Also, if you're using Android without Play Services but still want to download Play Store apps, you can use the "Yalp Store" app from F-Droid.
I'm not making a moral judgement, maybe 'pirate' was the wrong word. It probably was something like APKMirror, and my point was the chain of trust is broken (you have decide to trust that site and its provenance model) vs an HTTPS download from the Slack domain.
I just checked with Firefox Focus on Android, and the 'launch' button is missing. Even if I go to the `/messages` URL I am redirected back to the account splash screen. That's my default browser, especially as I only wanted to log in for a minute to check on something on my personal device.
It does work with Firefox on Android (not Firefox Focus), if you check 'desktop mode'. Weird that you should have to fake the user-agent string to access it.
Is there any company that have had positive results using such tactics?
It seems anyone who tries gets such a backlash and end up losing more than what they gain, plus they expose themselves to have false positives (e.g. one image didn't load due connection issues but slack falsely assumed it was an extension blocking it)
You kinda do. What do you think we did before slack? Change can happen the same way; convince the people with power to make the decision to use something else. There's always some resistance because you have to get many people to change - start with your team, convince others to join another service.
We use slack and I still have to use 4+ other forms of communication at work daily (jira, confluence, outlook, github). Sometimes we use video chat services and conference calls as well. There are days where very little happens via slack, and I'm becoming increasingly convinced that anything beyond pinging for simple things (hey look at this jira ticket, have you done this?) is wasted effort.
That’s not the case at all. Your “ownership” of the device isn’t that important in the grand scheme of things. If you’ve signed an agreement with Slack not to modify their product, then you don’t get to modify their product.
Blocking ads is not quite the same thing as modifying a product - but I don’t see any obvious reason why an EULA which forbids ad-blocking wouldn’t be enforceable. Though it would be deeply unpopular.
You are not modifying slack (their product), when you request a website all they are sending you its a bunch of characters, including characters inside CSS or JS files, rendering those its up to your machine, you are not legally binded to render those in a specific way, otherwise screen readers would all be completely illegal, all threads of not modifying your local render of a website always end poorly by the people doing such threats, examples:
Their product are the bits they ship to you and the code they run on their servers.
You're modifying a part of their product.
Since you can't modify their product, you also obviously shouldn't be able to use any web browser to view slack because those browsers take those bytes they ship you and interpret them in the context of the browser windowing system (its userChrome.css for example)... that's also clearly modifying the experience they delivered to you.
You also shouldn't be able to use a computer monitor that has color settings different from the web designers working at slack. If you accidentally have a monitor with slightly less blue than theirs, well, you just modified the slack UI to be a little less blue. Obviously a ToS violation and you shouldn't use them at all.
God forbid if you zoom in on the page to modify their product's resolution/size.
He he, too funny you mention zooming. I've had a bug report going for a while where their emoji sprite sheet gets all messed up if you run at smaller zoom levels. I think they still haven't fixed it properly. :)
> Blocking ads is not quite the same thing as modifying a product
I was going to comment something similar, but in trying to come up with details and examples to explain my point, I realized I couldn't, I so I decided they aren't really different with respect to modifying a product. What makes them different is how the product was modified, but that presupposes modifying the product and that's not really the way the question has been posed.
Blocking ads is removing the revenue mechanism, and is akin to patching out account verification for a desktop product (assuming the webapp/webpage has some AUP stating that the ads are required to be viewed as part of the service).
Modifying a program takes many forms, from removing authentication mechanisms to fixing bugs or adding enhancements, so while the legal system may or may not acknowledge those differences, it's at best an overly broad description of the case in question.
Sort of. It’s fine to have a disclaimer which says “this will void your warranty”, just look at smartphone jailbreaking. He’s not breaking Slack’s terms of service - his users are.
But then the next logical step is to argue that he’s inducing a breach of contract by his users, which seems to be the case.
A disclaimer which says “this will void your warranty” is perfectly legal. Breaching the limitations of a warranty is not illegal. In fact in some jurisdictions, the limitations of a warranty are themselves not enforceable (in the USA under the Magnuson-Moss Warranty Act)
Inducing a breach of contract is a tort [1]. It does not apply in all cases where someone is induced to break a contract but in this case where the extension author has knowledge of the Slack terms of service and the extension targets Slack only, it almost certainly does apply. This argument was used in the case of Blizzard vs Bossland [2].
In any case, it probably is not worth likely legal costs and effort should the other party take legal action. It is one thing to theorize about legal implications, quite another to risk livelihood etc to put it to test. Defending against action takes time and money which amounts to loss in many cases even when you are successful in court.
There is almost zero chance slack would win this case and I doubt they would even try.
Adblockers inject code into sites. So do password keepers. If sites could sue adblockers because it breaks their terms of service, don't you think they would?
You are not bound by the slack terms of service except in the scope of your slack account or an API connection of some type.
Someone else can use my software all day long to break their terms of service, but that doesn't make me liable. I didn't agree to anything.
People need to realize that terms of service are a civil contract. It's not "illegal" to break them. Especially if you didn't agree to the terms.
Has anyone (with tons of money to spend) ever made a suggestion to you that they might sue you? It is pretty stressful. I do not recommend it to anyone.
This is the difference between fantasizing about the likelihood of outcomes when you have no skin in the game and being on the other side of a well funded adversary that is threatening a lawsuit. Put yourself in the POV of the one with skin in the game and consider that it may take years and insane expense (time/money/energy) to prevail against even a poorly founded lawsuit.
He should talk to a lawyer, especially if he accepted a binding agreement by using Slack that forbids any of the research he did to figure out how to get his integrations to work.
I think what tptacek means is that when we sign up for a service, we agree to terms of use. Even if we don't sign it, it might be legally undecided as to whether that counts as
a binding contract, nor whether "terminate the user's service" is the only recourse the service provider has.
In most of the world it is decided. The decision is click-wrap 'contracts' are unenforceable. Starting with the fact that they don't meet the definition of a contract.
He talked in detail about how his company is long-time user of Slack. He and his colleagues each agreed to the "no reverse engineering" terms when they signed up.
Maybe the agreement isn't binding depending on his local jurisdiction, but it's unclear how he could use Slack without agreeing (or at least clicking "agree") to the terms.
In many jurisdictions you can't be bound by an agreement if not explicitly agreeing. It most likely boils down to where Gervasio lives. In my country for example I'd be certain Slack would have no standing at all with this. Though even in the US Slack would have to pull an Oracle to win this (which, well, is the risk that they might). Good reminder though in which moral category of enterprises Slack has to be sorted in.
It does not matter, he does not want to fight this.
It might be more than just a EULA. Often to sign up for an API key, you have to go through a bit more explicit agreement to a ToS than there is in a standard funnel. There's also a bit more of an expectation that people will actually read them (and are competent to understand them).
"Terms of Use" are part of the agreement between you and a service provider with regards to the service being provided. That's a civil law contract like any other.
No that's not, and I'm not playing on semantic. Laws are above any terms of use, regardless of what they might say. And not using the product makes you not bound to the terms of use, unlike laws which you have to obey at all times.
I'm beginning to think that when you said by "not signing anything" earlier, you actually meant "not agreeing to anything", is that correct?
> And not using the product makes you not bound to the terms of use, unlike laws which you have to obey at all times.
Of course not. But in this specific case, it is safe to assume that he is using the product, or more specifically: he used Slack to develop BetterSlack.
You mean you do not ignore cease and desist orders by principal? Why? There should be at least some criteria by which you judge which ones you can ignore and which you can't? What if they told you to cease and desist programming forever on any project because they state in their terms that once you mess with their UI with JavaScript you are not allowed to program anymore? Ridiculous right? So would you listen? Probably not.
So lets see what they are 'forbidding' you: They don't want you to write code that makes browsers do other things to their site... How is that any of their business?
What if a new browser comes along that renders all of their fonts differently so that they become unreadable, is that any of their business or is it the business of the people who use that browser? I'd say the latter.
I agree that a disclaimer and a change of name should be enough. I'd suggest 'SlackingOff' as a name.
You are free to write any extension that does anything to any website as long as you aren't hurting users' human rights and as long as you aren't hacking them if you ask me. Users can decide whether they want to use your extension perfectly fine on their own.
Also note that you are free to not write any extension as well. It is your life of course :)
I see all of these comments in here telling you that Slack doesn't have a leg to stand on, that you should do your best to stick it to them, that you're in the right, that you should ignore them, etc. Meanwhile, I'm thinking, "If I were in this person's shoes, I'd probably distribute it privately to a few people who might want it, and in spite of all the hard work, let the project die in official capacity."
On principle, I want to side with all these other commenters. Fact of the matter is that time is precious. Glad you're doing what you feel is important to you.
When you delete a public repository, one of the existing public forks is chosen to be the new parent repository. All other repositories are forked off of this new parent and subsequent pull requests go to this new parent."
I got a cease and desist for a extension that improved the look of Craigslist. I just ignored it, I've never had to talk to a lawyer or anything. But that's my situation, I understand that other people may feel differently. EFF offered to review my case, but I didn't wind up following up with that either. Might be an option for you.
Craigslist Inc. v. 3Taps Inc., 942 F.Supp.2d 962 (N.D. Cal. 2013) was a Northern District of California Court case in which the court held that sending a cease-and-desist letter and enacting an IP address block is sufficient notice of online trespassing, which a plaintiff can use to claim a violation of the Computer Fraud and Abuse Act.
For one thing, the extension author is not an active participant and cannot be considered to be trespassing. A user, maybe. But I don't think we'll see Slack banning users anytime soon.
The intent is clear. I don't know the details of those decisions but Blizzard has won cases and stopped people from distributing tools that access their services in ways they don't approve of.
> You are free to write any extension that does anything to any website as long as you aren't hurting users' human rights and as long as you aren't hacking them if you ask me.
But you're not the person being asked - the courts in g3rv4's jurisdiction and in Slack's are the ones who would be asked, if it came to it. Have you read the relevant law (including case law) about copyright and "cybercrime" in these jurisdictions and concluded that, in fact, Slack does not have the power to restrict this? Have you read the Slack user agreement and concluded that the provisions in that user agreement are unenforceable?
> Have you read the relevant law (including case law) about copyright and "cybercrime" in these jurisdictions and concluded that, in fact, Slack does not have the power to restrict this? Have you read the Slack user agreement and concluded that the provisions in that user agreement are unenforceable?
Is this your first week on the Internet? Of course he hasn't read any of those things! We're all arm chair lawyers here with our own personal, grumpy views about what shape society should be.
Ok Stallman, now back to reality where people do own software, they do have legal restrictions on its use, and it's not a human right to circumvent it.
Yeah and I also own the machine that's rendering the HTML and executing the Javascript. Nobody has any legal right to prevent me modifying my browser and changing how it interprets said javascript.
No, there are two points raised by the cease-and-desist: one was not to modify the experience, and the other was to change the name. These are two independent issues.
But it doesn't inject code into their site, right? The HTTP request is made to the server all the same, nothing modified via the browser, it's all code additive/correction in the extension?
Those terms bind Slack users. This problem goes away if the maintainer doesn't use Slack and has never used Slack. It wouldn't be efficient, but it'd be possible.
@g3rv4, I understand it really sucks and feels terrible. But I also understand their reaction.
Don't be surprised about legal writing. He/She as a legal person is responsible for writing in a very clear and explicit way since any misunderstanding might cost the reader or themselves in the future. It just shows their accountability. You don't want a misunderstanding cost you trouble.
I have colleagues working in the legal department. They understand you, but they still have to make sure there is no misunderstanding there.
They are serving enterprise companies, Anything goes wrong can destroy their business. It makes sense for them not to risk anything.
Companies are paying them for the security. Otherwise, there are cheaper alternatives to Slack with somewhat similar features.
Slack could allow custom clients. But I'm pretty sure all major customers will require their employees not to use un-official clients for security reasons.
> Don't be surprised about legal writing. He/She as a legal person is responsible for writing in a very clear and explicit way since any misunderstanding might cost the reader or themselves in the future.
Ok, then he/she can be called out since we are on the front page of HN and there is a lot of noise and harm done.
I honestly can’t see a single reason why slack legal department, probably worth millions per year, in a company worth several billions, can write such things just to kill a free chrome extension built by a single person for non profit reasons.
I never used slack but from now on I will actively advice against using it.
When you arrive at the point that you can’t even modify your browser to see whatever you like I think that we are almost at the brink of total destruction/anarchy/“choose your not so preferred destination”.
Disclosure for slack layers: I never used your product, so I never agreed to your TOS and I would never use it hopefully.
I am not associated in any way with any of your competitors.
I sadly have to admit that sometimes I play with JSFiddle
in my browser just for fun.
If you want to sue me please go on, there is not much difference compared to what you are suing g3rv4 for.
And I don't. I mean, charitably this could be attributed to some non-tech person noticing the extension and sending/asking legal to send a C&D because they didn't like it. That's the only thing I can think of, because the alternative is plain malice. This is a client-side modification, the main part of their letter is just absurd, and the justification is nonsense.
But they are risking something. As a Slack user, I find the temerity of this extremely annoying. I imagine that I'm not the only one.
If those enterprise customers are worried, they're free to lock down browser extensions on their employees' systems if they want. If they're worried about this, they should be just as worried about extensions acting on webmail, internal sites, etc.
> Companies are paying them for the security. Otherwise, there are cheaper alternatives to Slack with somewhat similar features.
> Slack could allow custom clients. But I'm pretty sure all major customers will require their employees not to use un-official clients for security reasons.
Is security really a client side thing? Obviously I understand stuff like key logging and such in a malicious client, but how would somebody using a custom client affect another user's security with an official client? I mean if it would, wouldn't that be a horrible situation anyway from security point of view?
I think where the dev gets into trouble here is that he must have a Slack account in order to have built this. That means that he himself has agreed to the T&Cs at some point. If he could have built this without having an account, then he would have a better chance of being able to avoid liability.
In that case, there would be no "contractual privity" between Slack and the dev, and Slack would have to go after him for inducing breach of contract or some such thing.
You won't be able to tell your lawyer "this is no different than paying you with real money" and hand over a stack of monopoly banknotes. Legal advice by analogy is unlikely to be all that useful.
Analogies are used all the time in legal decisions. You'll find them regularly in supreme court opinions, for example. Anytime something that has never been seen is litigated, it's likely that analogies will be made to figure out the law [1].
I think the real lesson is "don't take legal advice from internet forums of non-lawyers", or at least take it with a grain of salt. Not all analogies are equally good and only a qualified lawyer is gonna know which analogies will fly in court.
In Adams v. New Jersey Steamboat Co., a steamboat passenger sued the owner after the theft of valuables from the rented cabin; neither passenger nor owner had been negligent. The passenger claimed the owner nonetheless was strictly responsible, regardless of any failure or compliance with care, in light of prior case ruling that innkeepers were strictly liable for the theft of boarders' valuables. The owner argued against strict liability and pointed to precedents rejecting liability claims by passengers on open-berth sleeping trains. For purposes of liability for theft from a passenger, should the steamboat owner be viewed as more like the innkeeper or more like the train owner? The court reasoned that "A steamer carrying passengers upon the water, and furnishing them with rooms and entertainment, is, for all practical purposes, a floating inn, and hence the duties which the proprietors owe to the passengers in their charge ought to be the same." The court noted that both innkeepers and steamboat operators are entrusted with high levels of confidence in the face of temptations by many to endanger guests. Given this parallel relationship to guests, innkeepers and steamboat operators should bear the same kinds of duties to guests.
Yes, that's what I meant. Sure, a court can make an analogy but hey, they're a court. Random stranger on the internet is unlikely to provide you with a useful legal analogy. If anything, this seems like an intersection of topic and venue (legal stuff, forums for technically-minded people) that generates giant billowing clouds of useless analogies.
To be fair cease and desist orders can generally be thrown directly in the trash.
I can't even count the number of them I have received. They look scary but basically will not be followed up with. You might as well just respond with "fuck off"
Slack has really jumped the shark. Between this and their cutting off their IRC gateway, I don't really see the point of using it. You can't be openly hostile to people who create "hacks" like this if you're claiming to be a communication medium for "hackers."
Slack is no longer for "hackers". It's mainstream now. My company of 500 with only 30 devs uses it.
These are power moves by Slack. They want to have greater control over the communication medium and presentation
If you thought they were ever going to support extensions of their IRC gateway for long, then you misunderstood their product and who their market was or rather who their market became
Same at my workplace. Slack is mostly used by the managers, all the devs avoid it. Even if you don't mind the proprietory protocol, the performance even on beefy machines is an absolute dumpster fire, that nobody wants to touch the app with a ten foot pole.
When Slack came up, some of our development teams picked up using it, because it was free and didn't have to be installed and because of "it was that hot new thing from Silicon Valley that all devs use now". Most people loved it. I've always been in the "we try to keep our other infrastructure mostly in-house for control/privacy/anti-lock-in reasons, so why add a dependency to an external service and push internal documents onto it while we don't even pay for that thing?" camp and therefore flat-out refused to use Slack until the issue of internal instant messaging got enough attention to be discussed on a company-wide level. It was agreed upon the need for such a service, but it was also recognized that the way in which Slack was used to serve that need was not sustainable and far from rational, so alternatives were discussed and we eventually settled on trying out Mattermost.
Within weeks, all teams using Slack had moved over to Mattermost, and even most of the people who never wanted to use Slack for various reasons, including me, were okay with giving Mattermost a try. Most kept using it, so it has become a widely accepted part of our internal infrastructure now.
Slack definitely started from the software niche, but is far from the only player in the field.
Others mentioned Mattermost, Discord, but really, there are so many viable options out there. See this list of 25+ alternatives for example: https://fleep.io/blog/best-slack-alternatives/
From cloud-based to self-hosted, open-source and commercial... As long as they integrate with the tools devs use, there will be devs who use it.
We've actually just switched to MS Teams. It's OK. Does the job. But, to be honest, I'm no great fan of instant messaging so I'm always going to react a bit like that to it.
Main difference is cost. If you're already paying for Office 365 then paying for Slack Enterprise (or Plus, or whatever it's called these days) across a fast growing organisation of 170 people on top starts to look really hard to justify versus Teams. You can, of course, stick with the free version but this caused two problems for us:
- We ran out of integrations,
- We found losing message history more than a few days old was really starting to hurt us - you couldn't even go back and refer to a conversation you'd had last week.
Teams isn't perfect: it's purple theme is pretty gross (actually it has a couple of other themes, but they're both foul as well), it can be very slow/laggy, and it has a plethora of UX annoyances (like having poorly designed chat window layout and formatting that wastes loads of space) but we saved £20k/annum by switching over to it. And we now have conversation history and unlimited integrations.
Plus, I have to say, I do not approve of this move by Slack. They could have approached it much more positively by partnering with the author (as an example).
Discord doesn't really solve any problems in the text chat space any better than Slack, and introduces additional problems like its lack of ability to leave/join channels.
I use discord personally all the time and really wanted to use it for business but couldn't.
Some reasons:
* You are in all channels, all the time.
* no threaded replies (most important)
* the notifications system is weird
* weak integration system (integrations cannot add widgets to chat)
Some more reasons that I forgot. But these ones most importantly.
While I haven't seen any legal threats, they tend to threaten end users with bans (due to breach of ToS) for using third party clients, client modifications (like BetterDiscord), and "self-bots".
Agreed. This hostility towards users is ridiculous. As a current slack customer (50 or so person org), I will be investigating alternatives starting tomorrow.
Not to mention that while Slack still has a web interface, they can't really expect to control what extensions are installed in the user's browser and how they render/modify the data the website is sending them. That'd be like Reddit or Google sending uBlock Origin a C&D because it can block ads on their sites. Or SalesForce C&D'ing whoever did an extension that implemented XKCD's force/horse replacement (https://xkcd.com/1418/).
Slack can shut off their web interface and rely on their own apps if they want to control that stuff.
"we prefer that you do not include the word “Slack” in your product’s name."
From the people who had no problems naming their product identical to the colloquial name of the oldest maintained GNU/Linux distribution, thereby confusing the hell out of actual technical people for the longest time with press releases.
Also, Bob Dobbs called...
(Edit: you can take away my upticks, but you will never take away my slack. "Hacker" news my ass.)
I suspect the real beef is with the name. In one swoop, it dilutes their trademark and makes the case that Slack is inferior to something else. Big no-no.
I bet the Slack top brass just told legal to throw the book at the guy because of the name, and so they padded the letter with everything they could find, including weak technical arguments that they don't even enforce on others.
(I agree on the confusion with Slackware btw, it took me a while to realize they had no connection whatsover with Volkerding or the distro.)
I'm going to go out on a limb here and guess you're in the extreme minority if you honestly confused Slack the chat client for Slackware the Linux distribution. That's...a leap.
Frankly the origin of Slack's name has nothing to do with Slackware Linux (or Linux in general) so I'm having difficulty following your grievance here.
70's counter-culture and early hacker culture are not that far apart. It's more than likely their origins are related.
Now if "Slack" means the pretty protocol-breaking irc-client to you, that's perfectly fine. But if some party starts threatening someone with 'That's not what "Slack" means! We're the authoritative source on the meaning of "Slack"', a hacker should resists. Slack is for everybody. Many may have forgotten, but it's not VC-money that makes the Internet go round, it's Slack.
To quote the prophet:
"If someone is making money off ``Slack'', it better be me."
"Those who cannot remember the past are doomed to trade their precious Slack for worthless trinkets."
"The Slack that can be described is not true Slack."
> But if some party starts threatening someone with 'That's not what "Slack" means! We're the authoritative source on the meaning of "Slack"', a hacker should resists.
Okay but they didn't do that. Slack is concerned about someone using their name in relation to third party, unaffiliated software which is obviously related to their own software. Slack the messaging company doesn't care about the use of Slack outside of that niche.
If you wrote a browser extension called "BetterSlack" that emulated Slackware in your browser, Slack wouldn't care. If you wrote a browser extension called "DontSlackOff!" that automatically restricted the time you could procrastinate on Hacker News or reddit, Slack wouldn't care.
Slack cares about its brand, not being the canonical authority on an English word use of that word in products. The idea that Slack cares about uses of the word that don't have anything to do with its own software seems like a willful misinterpretation of the point. This is a pretty mundane legality and has nothing to do with hacker culture or "resisting" anything.
I hadn't heard about Slack until I started in my current job (4 years ago) and when they told me that Slack was among their commonly used tools I immediately thought they were talking about Slackware and said I was surprised anyone was still using it. Came off as a total "bleeding edge" snob/hipster until we figured out what was happening.
Not sure I was ever confused by Slack's name, I just never knew what it was for ages until finally I used it, and after seeing the name crop up on HN so often I had to eventually look for myself.
> In order to remedy this, we ask that you please modify your product so that you are not forcing your own code into our services. We have opened a number of channels for the developer community to build tools that improve their experience with Slack. We encourage you to utilize those channels to their fullest extent.
Except that these channels make it impossible to really interact with Slack, and they pulled the rug out from under the APIs that used to kinda make this possible (XMPP/IRC integration). If you're going to force people to use your client, then you should allow for users to customize how that client looks and feels. Even more so if you're doing a terrible job at that yourself.
This. How many "Slack dark mode" haxtensions need to be made?
I don't need more emoticon skin tones bloat. I need to save my eyes with hours in this productivity tool forced by my workplace.
Slack Team, just listen to the market (hint: HN score!) and bring such guys like OP into a gig to improve your stuff.
You solved on of my biggest gripes (muting spam) and a few others I didn't even know I had. Thanks for doing this. I grabbed a fork for myself. Definitely a big middle finger from Slack to the developer community and when I'm the one making the decisions, I'll be recommending people skip Slack. They mostly lost me when they killed the IRC gateway but they added another nail to the coffin with this.
From something I wrote in January 2016 (just one concern of many):
"Reasons Not to Use Slack for Free Software Development"
https://pdfernhout.net/reasons-not-to-use-slack-for-free-sof...
"Slack requires signing up and agreeing with a long Terms of Service (TOS); the TOS can be changed at any time, and historically such TOS have changed for the worse over time for other services once a lot of users adopt the service and become locked in by inertia and interlocking usages with other groups."
I guess I did not explain that clearly enough in the essay. The issue was not using Slack in itself. I've unfortunately had to use a bunch of proprietary tools and hardware over the years, and in fact (unfortunately) I use Slack where I work now. The issue was that Automattic, the company behind the FOSS WordPress software, was moving from open solutions to use proprietary Slack. That included moving away from FOSS ones they made themselves in-house like o2 ( https://github.com/Automattic/o2 ). And that disappointing choice by Automattic to embrace proprietary communications tools seemed in conflict with my hope to have made WordPress into a better FOSS communications platform while working there. I also did not feel it boded well for the company itself -- since Automattic seemed to be narrowing its business ideals from supporting and expanding the single biggest FOSS communications platform on Earth in terms of hosting much of the web to becoming essentially just another WIX competitor.
I dont see any legal reason why you can't publish the extension under a different name. Your extension is under no legal obligation to follow their acceptable use policy, only the users that use your extension.
1. I don't want to get involved in that, even if I'm based in Uruguay and they'd have a hard time suing me.
2. What they could do is put resources to detect the extension and block it. We could start a mouse and cat game that they'd win... I don't have their resources to invest in it. After all, all I wanted was to solve Slack for me, and that would make it harder.
Could they really sue you for creating a chrome extension that modifies their webpage? That would be a very dark day for the internet. I can't imagine there's any legal basis for that, but it would be very interesting to hear a lawyer's opinion.
Well done on what you have achieved, keep fighting the good fight!
(Goes without saying, but IANAL) It's my understanding that in the US you can be sued by anyone for anything. That doesn't mean the case has merit, but it does mean you're obligated to defend yourself or lose by default. This is often the mechanism by which patent/copyright trolls put pressure on their 'mark.'
It sounds like the plugin author isn't located in the US, so this may be moot, but countries colonized or invaded by European countries or the US often have similar legal systems.
I doubt they'd win in a fair fight, but I also doubt the plugin author can afford to put up a fair fight.
IANAL -- but I've been on the receiving end of a MegaCorp's C&D for alleged violations of the Copyright Act, the CFAA, and other things.
The biggest thing is Terms, which will almost always exclude any tampering of any kind, client or server side. These agreements are usually upheld in the US. So that's hurdle #1.
The CFAA isn't really obviated by client-side modifications, because the CFAA allows essentially arbitrary definition of "unauthorized access" and "exceeding authorized access". If they tell you to cease and desist, most judges won't believe that you can reasonably claim that you didn't know your access was unauthorized. The CFAA makes unauthorized computer and network access illegal.
There's a third barrier here, which is copyright law. The "RAM Copy doctrine" is the dominant interpretation, and it states that even the temporary copies that exist within RAM are sufficiently tangible to qualify for copyright protection, meaning you either need a license from the rightsholder or you need to prove fair use just to load the content.
The only way I can see that that wouldn't affect client-side applications would be if they access everything through a proxy without ever actually loading the copyrighted content directly, i.e., by injecting and accessing the DOM through the browser. But you'd still have to convince the judge that the extension itself is not infringing on the work it alters, which seems unlikely -- it would likely be considered a derivative work.
Again, I'm not a lawyer. Maybe all this is wrong. You shouldn't rely on it. But the situation is not as dreamy as people think. BigCos keep this bully pulpit relatively quiet because it makes it easy for them to crush upstart competitors who may offer a "move your profile from $X" feature. With the data locked up, the users never move.
> What they could do is put resources to detect the extension and block it. We could start a mouse and cat game that they'd win... I don't have their resources to invest in it. After all, all I wanted was to solve Slack for me, and that would make it harder.
Honestly, if they do that they're idiots and, longer term, slack is a dying product: they'd be much, and I mean MUCH, better served by investing those resources in improving the product.
You could still continue development on Github, and allow users to install the extension themselves. I believe this is the approach that some paywall bypass extensions take[0]
Whilst it is true that the extension has no legal obligation to follow the acceptable use policy, users do have to follow the policy and the courts would argue this extension coerces users to break the policy. The legal precedent is Blizzard vs Bossland [1] which Bossland lost in the UK courts [1], US courts [2] and German courts [3]
I agree with you there, to win the case there would have to be some economic reason for Slack to not want users to use this extension.
The reason they state is "Injecting javascript into Slack via Chrome extension can have an impact on the privacy and security of our customers and our product. Furthermore, this can create reliability issues when we ship product updates." If they can prove that is true then the case stands up but if BetterSlack doesn't impact security, privacy or reliability then the case would probably be dismissed.
If it alters the DOM, it impacts security, and in a very significant way, since DOM security is in a sense the most important security barrier between untrustworthy content and all the messages a user has access to on a Slack.
Sure, it "impacts" security. But as we are discussing above, it would need to be shown to "negatively" impact security. I don't think you could win on the basis of "it's not recommended to do that, but we can't see any examples of it actually causing security problems."
One of Chrome Web Store’s terms is that a developer is not allowed to publish an extension that “knowingly violates a third party’s terms of service.”[1] So even if the author has the 1st Amendment right to publish the extension on his own website, Google will likely take it down from the Chrome Web Store.
Many userscripts target specific websites and change both their appearance and behavior. Userscripts are often indexed, distributed and ranked like browser extensions are, as well.
Great question. What matters is the outcome, not the mechanism. It is the modification of the functionality of Slack’s product which is at issue. Most extensions don’t do that in any substantial manner.
Furthermore, in a civil suit what needs to be demonstrated are actual damages to their business. (It’s not enough to just show that the ToS were violated). There’s no possibility of that for most browser extensions.
Hey g3rv4 sorry to hear the news. Although I personally don't use slack, when I saw your last post (congrats on the double front page btw) I was super impressed by the stuff you'd added, sorry to see it go.
So this seems rather unfortunate now but the first thought I had on reading your initial post was "wow, I wish he'd come and do some similar stuff for riot[1], but unless slack shut him down there's no chance." However lo and behold here we are, so I thought I might as well reach out. If you haven't heard of it, Riot can be described as "an open source slack" although I think that's unfair on it, it certainly lacks certain features that slack has (although with its current rate of development this gap is shrinking) but also can do things slack just can't.
Full disclaimer I'm not a developer on riot (or matrix[2] the open protocol it implements), just a happy user so I can't speak with true authority but I think they'd be happy for you to make these sorts of changes to riot.
So I invite you to come check it out, I hope you find it compelling. At the very least riot has a means of bridging to slack (along with irc, gitter and more) which you might find helpful in dealing with slack (I know I do).
Hope your future endeavors so smoother, I look forward to seeing whatever you create next.
I am a very happy Riot/Matrix user. Commercial software has a place. I think for things like Photoshop it can make sense. It's a complicated and powerful system. I just can't justify closed source software for a chat application. They are fundamentally simple systems. We CAN build competitive open source alternatives. Eventually companies have to make money, and all the approaches I've seen for that go against the user.
Speaking as someone working on matrix and riot, we would love you to come and do BetterSlack style things to Riot - we are getting tantalisingly close to being “as good as Slack” (except entirely FOSS, decentralised, standards based and with E2E encryption) - and positively encourage folks to customise the apps as long as they don’t introduce bugs or harm the security model. Plus we can just accept changes straight into the app rather than injecting via an extension. Pleeease come help us make it better - #riot-dev:matrix.org would be the place to come :) And yes, we have bridging to slack too.
I'll be honest, I don't have a huge amount of experience using it, never to a company slack sort of thing and there may be some company policy about this sort of thing (security and all that) so I'd encourage checking there but I hope it works out!
I think it's really dangerous to choose to take Slack's message seriously here. I've been working on a WebExtension recently [0] at my university that's entire existence is staked on continuing to improve on platforms that are slow moving, and to tie together platforms that otherwise wouldn't talk to each other for political reasons.
A company making the case that their Terms of Service or definition of Acceptable Use applies to users manipulating the data that is sent once it is in the user's browser is a terrible way to go. We should always have the tools and the means to add features and change the display format of data being sent to us.
This situation all but confirms that Slack has well and truly become a investor-first, user-second company. Which is a shame because I only just finished listening to an episode of "How I Built This" where they interview Stuart Butterfield who founded Slack out of his failed gaming company and it was a great story.
When you have Fortune 500 companies using you, you know you're not a startup or company for the common folk anymore. As for hostility towards developers, we only have to look at how well that worked out for Twitter when they turned up hositility to 11 towards their developers. Different situation, but same premise of cutting off developers making your product better.
As for Slack, I loved it in the early days. But now, I find is distracting. The numerous bots you can enable on it (most of which are counterproductive) are annoying or distracting (like the Gif bot). I dread opening up Slack because it's not a nicely designed product and it is starting to become dated.
We've been using Microsoft Teams where I work and I must say that it is amazing. You get so much out-of-the-box with it without needing to add in bots and it's more customisable.
> This situation all but confirms that Slack has well and truly become a investor-first, user-second company.
You know how to predict if this will happen? It's pretty easy. It will if the company's product or service is proprietary and centralized. It's just a matter of time.
> Injecting javascript into Slack via Chrome extension can have an impact on the privacy and security of our customers and our product.
So can taking screenshots of messages. If injecting JS can possibly affect the security of your platform then that's a vulnerability you should fix, not send a C&D to some developer about.
They're not saying that their server will leak data, they're saying that an ecosystem of Slack Chrome extensions injecting arbitrary JS is fundamentally much, much less secure than an ecosystem of integrations using official Slack APIs. It's debatable whether Slack has the authority to disallow Chrome extensions, but it's certainly in their interest to discourage them.
If everyone gets used to installing 5 Chrome extensions from unknown developers adding little themes and tweaks to Slack, then some of those extensions are going to be malicious and a lot of people are going to have their accounts stolen. Third-party software should only request as much access as it needs, and Chrome extensions are just bad architecture for this sort of problem, since you can't say "this extension gets to make benign visual tweaks to the page but doesn't get to steal my Slack account". I haven't worked with Slack's API, but nearly every API like it provides granular access and certainly doesn't let you steal the user's account, and all actions are done via an API token that can be tracked and revoked by Slack if your app is malicious.
If your security depends on people not using browser features, maybe don’t use a browser then. Ultimately, if your security depends on the client being unmodified, you basically lost. You can make it harder for an attacker, but that’s the problem DRM tries to solve (and consistently fails to)
But that's utterly ridiculous. All the data Slack sends to my browser is already mine to view, so if there's an issue of "privacy and security", it's on their end.
I wonder how much longer Slack’s web client is going to remain a first class product? Clearly, it was a good way to drive adoption, but seems that at this point they want ever more control.
> I wonder how much longer Slack’s web client is going to remain a first class product?
It never was? The Android client takes 10 seconds to start, runs my device hot and the UI is so bad that the first time I tried to respond to a thread I couldn't figure out how to get out of the thread view.
The desktop client uses 1GB of memory gobbles my CPU and takes 20 seconds to start.
The "least bad client", the web client still takes 10 seconds to start, for no obvious reason. Last week I looked into it, it turns out that every time the client makes a request to the server it the TTFB is 300 to 500ms, on a connection with 40ms ping. So their backend is just as fucked as all their clients.
Even their email notifications don't work: every time I click on the link they send me it doesn't take me to the mention!!!
They did corner the market so clearly they must be doing something, but really I just can't see it. I'm completely stumped.
>They did corner the market so clearly they must be doing something, but really I just can't see it. I'm completely stumped.
I've been wondering about this for a while now. Slack feels more like "just good enough" in terms of UX than anything special. It's just a chat application with terribly slow clients but somehow everyone is using it.
> They did corner the market so clearly they must be doing something, but really I just can't see it. I'm completely stumped.
One of the reasons is the lack of competition, e.g., we use Microsoft Teams instead, but its also an electron app with the same problems (and takes ages to start).
I guess this must be it. IRC could in theory do everything Slack does but setting up a server is a pain and shiny clients are rare...
I wonder about the rest of the competition, for a while everybody was using hipchat, I never used it myself, I wonder why nobody talks about it anymore.
There are many enterprises that have web-only workflows. Eliminating the web client for Slack would be like eliminating the web client for Google Docs.
now that they got all that money, I wouldn't be surprised if they killed the web app and moved away from Electron to do native apps that are harder to be messed with.
I'd love a better-performing, less memory-intensive and, well, more native Slack app; I'm all for that part. The "harder to mess with" part is a little more concerning.
(I didn't catch the original mention of BetterSlack a few days ago, so ironically, your "Welp, gotta withdraw this!" message here is the first I've heard of it. This seems to be my usual timing with such things, though...)
> to do native apps that are harder to be messed with
As someone who messes with native apps: this really isn't true, at least in my experience. Native apps tend to follow platform paradigms, which usually make them reasonably well designed and structured–sometimes more so than web applications. Usually adding functionality is simply a matter of finding the class that manages the component, rather than digging thorough a bunch of broken CSS (for IE 6 support) and minified goop.
You do it the same way exploit writers do. Attach a debugger to the process, find the memory address of the resource you want to modify, overwrite the address with the address of the modified resource you want to execute. You could also just use the debugger to force the program to execute functions with arguments you specify, that way you don't have to worry about mucking with the memory.
Usually you'd create a dynamic library that interposes a function, so you don't have to much around with using a debugger. This way you have a persistent modification that's much more resilient to changes caused by app updates. Exploit writers generally have different goals: their thing only really needs to work once, and only with the current configuration, since usually the bug they're relying on gets patched in the next version.
Also, depending on the platform, if a native application is following the platform guidelines, then quite a lot of things you want to change might be located in data files or "resource" section of the executable.
I haven't been messing much with Windows executables for quite a while, but back in the day, I'd "improve" many programs by just editing their resources.
> I didn't know one Electron app could target the other.
An Electron app consists of two parts: HTML5 (which can run Javascript, but within a browser-like sandbox), and native Javascript code, running under Node.js with no sandbox whatsoever. The native half of an Electron app can do anything to your filesystem (including the parts that contain other applications) that any other native app can do.
I'm not sure how easy that would be since you're dealing with ASAR (just a binary encoding but definitely not as easy as modifying plain JS files) and code signing.
There is a node-js package to pack and unpack asar files. You can modify any asar archive by unpacking, copying/editing and re-packing. The signature would obviously change, but most electron apps really don't check for that (yet).
> I didn't know one Electron app could target the other.
A year ago or so, I was able to start desktop Slack with a param to open the dev tools port open and use something like puppeteer to control it (at the least, I opened dev tools inside of Slack's Electron app). Not sure if that is still the case.
…or maybe just stop trying to play with the cat tail if you don't want to get scratched.
There is plenty of solutions out there to do chat messaging "kinda like" or maybe better than Slack. I'm using Slack daily and I can't find what this platform has something so magical about it.
I am personally building a communication client that can do IM, video-conferencing, file sharing, posting articles… all based on XMPP. It works in the browsers and we are proposing now apps for Android and macOS/Windows/Linux. It's way lighter than Slack, can be deployed easily on a VPS or in your company and is fully compatible with many other XMPP clients/bots (Github is proposing a XMPP bot for MUCs for example :)). If you want to try it out or know more: https://movim.eu.
If you don't like Movim, I still invite you to find open platforms that can be tuned/hacked/adapted to your needs, there's plenty of them in the wild ;)
I like what Zulip tries to be in theory (the "topics" feature is really great), but there are two knocks against it, in my opinion:
1. They do not support self-hosting the code on a system with anything else hosted on it. You are strongly recommended to dedicate a server (VPS, Docker, whatever) to your Zulip installation. You can try to install it on an existing server, but it is far from trivial, and doing so is unsupported.
I just want to say thanks for putting this followup and their email up. I like having these things to point to when I choose alternative services or convince companies to stop doing business with other companies.
they don't want people injecting javascript on their website. That's all there's to it. I'm not sending anything anywhere. I'm not storing anything. I'm not profiting from it.
...and then notify every ISP, every place that offers free public Wi-Fi, every airline that has Wi-Fi on their planes, anyone else who injects code into web pages...
Don't think they can enforce this at all, I would just change the name and call it a day.
The burden is on you though, certainly no one can force you to make decisions. :)
One of the nicest cease and desist letters I've ever seen. I think what they're asking in the name change is more than fair, and providing guidence on changing the functionality to comply with their api seems like a good approach. Kuddos to Slack legal for keeping the matter human and civil.
>providing guidence on changing the functionality to comply with their api
Nice or not, that isn't what this is about at all. They effectively told the dev he's not allowed to do what he's doing -- their api doesn't support anything the author changed. Seems they just linked to their api docs for giggles.
No, they're bullying a developer who created something useful so they can keep control of their product. They're misleading him by saying that building a Chrome extension for a website somehow makes you agree with that website's Acceptable Use Policy
They didn't provide any real guidance, there's no way the extension could work using the official API.
The name was always going to be an issue when the extension got traction and publicity (via HN etc).
And the issues with script injection will always be an issue. But that is not a Legal department decision. They simply will be told to write the C&D letter.
And this letter was the most polite and flexible I have seen. Usually, other companies' C&Ds are totally inflexible, technically inept and unrealistic overdramatic.
Yes, Slack the company (and not the legal department's responsibility) can handle this in different ways. They can reach out and suggest alternatives, they can hire the creator to implement some of the features, they can extend the APIs for more legal interactions, etc. Or they cut him off and "Teflon shoulder" it to their forums as they seem to have done.
Slack's legal department has done their job, and as I can see in the best possible matter once they got told to do so. Up to the company what they do next. If anything.
This is why you should not use Slack. Open protocols with open servers/clients is what we need such as IRC, Matrix or XMPP. Slack removed the IRC gateway just so they can stop people from using the service as they see fit and instead force on the users what they think it should be.
While I completely understand your decision to pull it; both their decision to flex their legal arm and your decision to not stand your ground are equally disappointing.
How dare you choose not to put yourself in legal jeopardy for the sake of random people on the internet!
Please feel free to ignore everyone here. You made a Cool Thing, it didn't work out, whatever. You'll probably make more Cool Things in the future and I hope they'll stick!
I don't think we need people who can actually create things to waste time in bureaucratic legal battles. Go make other things; there's obviously no way to make Slack better.
I completely understand the decision to not stand their ground. Going up against Slack means going up against a multi-billion dollar company, and potentially all the legal firepower that entails. Even if every monetary cost were covered, there's still the time and opportunity cost of dealing with legal headaches.
How is an acceptable use policy even relevant to the developer of this application? Its the users of the app who would be breaking the policy. At worst they can argue that he broke it while developing it... so they can go ahead and shut down his Slack account. Totally fair.
Change the name, obviously. But fuck these companies like Slack who think they run the world and that gives them the power to control what code you run on your computer.
IANAL either, but it seems like that only applies in the case of malicious action on behalf of the accused toward the contract signatory; essentially coercion.
If someone made a Chrome extension which enhanced our users experience of SabreCMS I'd send them a wholehearted thankyou and probably try to hire them.
except to the extent such restrictions are prohibited by applicable law
...and here is the key. AFAIK reverse-engineering for interoperability is protected in the EU. IANAL.
As a long-time user (and developer) of web filtering proxies and related software, I also say you should fight this, because it otherwise sets a bad precedent.
Viewing the source code of a webpage is not a crime, nor is changing bits in the memory of the hardware you own.
Also, I know it's too late for that now, but sometimes it's better to be pseudoanonymous when releasing software that you think is somewhat in the gray area.
OP: since Slack is saying they own the execution environment running in your browser, send them a hosting bill for running their application in your computers. Multiply it times every user on your instance.
For everyone complaining about g3rv4 not (very understandably) taking a stand against slack, I'd advise you to clone it, and keep it live. That way we remove focus from g3rv4, but we keep alive the great extension that he built.
(I'm not in a country that would take Slack's illegitimate takedown seriously).
I worked at a medium-sized company during the transition from IRC to Slack. The problem the company had was a split in comms networks. There was a lack of will on the part of engineers to move to GChat, and non-engineers were unwilling to respond/engage on IRC. Marketing, Sales, and Admin were using GChat, while engineering used IRC. Getting everyone on the same comms platform was a major improvement. I'm not saying it's ideal, but it wasn't dumb.
I worked at Cisco, who had their own awful IM client. Our team used Hangouts instead with great success.
Company-wide conferences were a ball-ache. The corporate solution didn't mute by default, so with 40000 people in a conf it devolved into a "TURN YOUR MIC OFF" shouting match for the first 10 minutes.
> I worked at Cisco, who had their own awful IM client.
Which one? Webex, Jabber or whatever they use for their 50k€+ videoconferencing systems? I have only had the honor with the first two and, jeez, it's a nightmare...
No, it was dumb, and I didn't stutter. It's an extraordinarily short-sighted move to switch to Slack. IRC may not be for everyone, but clients like The Lounge and alternatives like Matrix are quite friendly to non-engineers.
I've been contemplating putting The Lounge in front of my IRC servers. How well does it scale? i.e. how many web users can you support with {n} amount of memory/cpu?
I've used cgiirc, but it isn't pretty and some people want pretty and client-less.
>The problem the company had was a split in comms networks.
My new team is going through this. For comms, my machine came equipped with Skype for Business, Slack, Stride and Bria. It's a fun game rolling the dice when you need to ask someone a question figuring out which comms tool that person uses.
A game I've avoided playing altogether by just sending an email.
This is largely the same rational that was used at the company I work at to transition to Slack. From an engineer and developer point of view, I rarely, if ever, directly communicate with non-engineers over instant messaging.
For people who deal with different groups of people in the company, shouldn't it be up to them to handle communicating with different groups using different methods rather than compelling everyone to use the same communication platform for instant messaging?
I was responsible for getting several development teams on Slack.
You see, nowadays few people outside of us hardcore geeks will want to use IRC (my first option). And there are things that "modern" chat clients do better. For instance, our monitoring system can post messages to slack with links to images to allow us to display graphs inline, links to runbooks, and even buttons to take actions. IRC won't do that.
Second option was Matrix with its (rather cool) open protocol, but the immaturity of clients and lack of integrations was a problem. Almost everything supports Slack, but good luck finding Matrix support. For our own systems this is manageable, but not all are under our control. Also, we would have to host and manage the infrastructure ourselves.
XMPP would be great on the integration front (surprisingly, Slack still wins), but once again it's something we would have to manage.
There were other options. Rocket.Chat, Hipchat, Mattermost, you name it. Each one with their own drawbacks.
So when asked by my manager what should we use, I could just answer "use slack" immediately, no ifs or buts, and most people would be happy with it.Assuming you have nothing against the company, the biggest technical con is the memory hungry client. The other issues are way harder to justify – big companies rarely care about proprietary protocols as long as they have a vendor to yell at.
It's focused on simplifying Slack's interface so that it's easier to focus. It also only uses CSS and doesn't interact with Slack at all, so it is not against their terms of service.
All they can do is threaten or terminate your access. And even that is debatable. If I create a new browser with BetterStack as one of its features are they going to mandate which browsers I use? What monetary or image damage can they prove? None.
I hope not, but one could argue that the adage that a quality of a product reflects the company that makes is indeed true...
This might be a stupid question (it's been downvoted before), but can a user run chrome extensions within Electron apps? Or a debugger?
If not, could a simple website wrapper electron app therefore be much more favourable for a company to run whatever scripts, tracking, and adverts than the same website?
Can the same be said for Progressive Web Apps for mobile?
I was even thinking about shipping an app that tweaked the Slack app for you, but after this experience (and since I don’t really use it) it’s not worth the effort.
I would write back to them very politely, something like this:
Hello,
Thank you for your email. I initially reacted by pulling the extension, in fear of possible legal consequences. But on reflection I would like to propose a better solution.
There are hundreds of extensions that customise websites, in many cases to help 'power users', or to assist people with accessibility problems not provided for by the websites themselves. These extensions are often made by the websites' most avid users. A great example is the Refined GitHub extension, which GitHub itself has embraced as a proving ground and source of inspiration for new official features. [1][2]
That said, it is of course vital that people understand that such extensions are unofficial, and that they are unsupported and not endorsed by the website owner.
I would like to notify you of my intent to republish my extension with the changes outlined below, which I hope will satisfy your concerns.
• New extension title: "BetterSlack: Unofficial customizations for Slack"
• Modify store description to include an explicit warning that installation and use of the extension is at your own risk, and is not endorsed in any way by Slack, and that Slack offers no support for it.
In the interests of transparency I will publish all of our correspondence on my blog, as I think this is an important issue of interest to the wider community concerning the rights of individuals to control their own computers and customise their own experiences.
I totally agree you should conform to their request - remove the extension from the store(s?) and remove Slack from the name.
That said, if you can keep the code on GitHub, then everyone can download the zip and load the unpacked extension - you could even go one up and create a (shell?) script with a cron job that checks the diff e.g. once per day and updates the unpacked extension. With our without the script, there's a slight overhead for the end user, but as long as benefits outweigh the overhead, people will use it and everyone will be happy (or at least, not be able to do anything about it :D )
When you're spending more time/money sending cease and desist to people trying to make your product better than _actually making your product better_, you need to re-evaluate your priorities as a business.
really cool approach by slack. create an environment to look nice to open source community, and make it a commercial, and then close itself to open source. great job slack!
After reading this I am quite glad that we made the decision to leave Slack in our company. Moves like these seem either desperate or disconnected from reality to me.
I highly doubt it, particularly in the absence of any legal precedence.. I'm vaguely aware of a couple cases where EUAs were enforced, but I believe they were in the context of avoiding monetary compensation.
Mirror of the extension: https://my.mixtape.moe/byutfi.crx
I hate censorship. This isn't any kind of illegal (though the name I can understand, if not agree with). Hopefully Slack recants for being a bunch of twitbrains.
Could Slack just defend against people doing this? Similar to how companies defend against Ad Blockers, Password Managers etc? Those also allow you to modify/tamper with elements, hide annoying things etc. Do you join lerna and block everyone now?
I could agree with the name change, even if to not stir up a hornet's nest
Much quicker to have the legal team fire off the standard email threat than get the dev team to reverse-engineer the extension and block it (if this wasn't just an automated email).
Has anything like this ever been hashed out in court?
I'm curious where the line is from a legal perspective? Ad blocker (purposely deny some scripts from running)? Custom user styling? User scripts (greasemonkey/tamper monkey etc), browser "reader views"? Accessibility tools? The browser dev tools?
I've been working on and off on a native macOS slack client. It's showing some promise in terms of speed, RAM usage, it looks prettier because it can use system blurs etc. But yeah i also worry about their lawyers. So i probably won't finish it. Pity.
That's unfortunate, the only feedback I'd have for the creator who did a lot of good and with good intentions too I believe, is to pick a different, less "confrontational" name when doing stuff like this. Slack is now just being defensive.
That's ridiculous. It's your browser running your extension, you're interacting with Slack in a way they allow (downloading their HTML and JS and talking to whatever internal API they use). How in the world they can prevent you from doing that?
Why Slack? Why are their services used by anybody? It is like IRC never happened.
I have been on a couple of projects that used Slack and AFAICT there is nothing in their service that accounts for them being a hugely successful business.
I could hardly understand why do people use Slack at all. Once I've read the BetterSlack features list I've came up wit the idea that perhaps it could make Slack useful and I might re-visit it. Such a waste.
That is sad! My condolences. That was a very well written letter from Slack and I completely agree with them, but unfortunate for BetterSlack nonetheless. Always room to pivot!
This is such a big shame, especially since the native Slack app is consuming such a lot of processor and battery power and it runs much more efficiently in the browser!
I hate these emails. Why do corporations have to be so heavy handed? How about just a nice message explaining the problem and possible solutions. Love to read about something like that! I now hope someone keeps slack’s legal department busy. The product sucks anyways. It was down yesterday and it’s a poor excuse for a reliable chat platform.
With ZenHub, we worked with them even closer because we saw that our users were happier using GitHub + ZenHub. We made it super clear that UI changes would likely break their app but that would be a risk for them to evaluate. In the end, it worked out well since ZenHub invested alot in their UI and became a long term partner of GitHub's.
From a technical level, I'd also take issue with this. You're customizing the output of their services once it's in the browser at the request of the user. If you're still interacting with Slack through the API and being a good platform partner (i.e. respecting rate limits), then I think you should be allowed to keep on. Disclaimer: I'm running a company on the Slack platform [2]
[1] https://www.zenhub.com/ [2] https://geteventbot.com/