Hacker News new | past | comments | ask | show | jobs | submit login
Bye bye BetterSlack (g3rv4.com)
839 points by g3rv4 6 months ago | hide | past | web | favorite | 383 comments

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]

[1] https://www.zenhub.com/ [2] https://geteventbot.com/

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.

[1] https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Leg...

[2] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

That is because an API should express high-level concepts, not low-level implementation.

Just as the new WebExtensions API does. And as any hypothetical Slack API should.

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...

That’s a good point. I’ll def ask after I take it down and let them know. Thanks!

Worth mentioning that github ended killing ZenHub, by introducing github projects, which is essentially copycat of the only useful feature ZenHub had.

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.

As a daily user of ZenHub for over a year, I would strongly disagree that GitHub projects offers the same feature set. A Kanban view, yes.

Also a Zenhub customer. I can't but assume features would be coming stronger and faster had GitHub not implemented projects.

Remind me of f.lux on MacOS and iOS

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

I read that as "Get Even Bot." Which would be a cool slack bot service as well...

That's a great idea! Hmm, I wonder what the Slack equivalent of glitter bombs are... emoji bombs?

A browser plugin that changes all applicable text to their respective emoji.

Obviously GITer bombs

Aww thanks Alex! Appreciate the note and glad you checked out Eventbot

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 used ZenHub for a long time, but being forced to use Chrome was a dealbreaker for me.

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.

There isn't even a threat to sue yet. I'd at least wait until they escalate and post everything publicly as we go.

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.

How exactly would they ban you? It's not like Slack verifies your identity upon signup. A new email would be sufficient.

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.

That is not that absurd, they actually tried that. https://www.reuters.com/article/us-germany-trial-adblocking/...

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.

Do you know about an instance where something like that already happened?

Which part? Not going after users or T&Cs that include a prohibition on reverse engineering? If the latter, yes this is pretty common.

I mean suing someone who created a web extension alleging reverse engineering is against ToS

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.

Yalp Store is a great app! Incidentally, it violates the Play Store ToS (this is even written in their FAQ[0])

[0] https://github.com/yeriomin/YalpStore#faq

Try using Slack in a browser on Android. It doesn't work.

It does work on Firefox for Android, if you enable Request Desktop Site. It's not optimized for small screens, though.

I tried exactly that a few weeks ago and couldn't get to the messages interface.

Worksforme :)

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.

What browser are you using and are you upto date. Many sites don't work on mobile chrome.

I find it hard to believe they would redirect you to a pirate site. Are you sure it was a pirate site and not just a third party site hosting apks

Firefox on Android. Per my other comment at https://news.ycombinator.com/item?id=17874566 it was a mirror site, though I didn't save the chat log so I can't remember which one.

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)

Oh no, we might have to use one of the thousands of other chat apps with identical or superior functionality but inferior marketing teams.

People who work at companies that use slack don’t have a choice.

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:



> You are not modifying slack (their product)

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. :)

Because people who zoom do not deserve to be on the internets.

I hope your eyesight stays 20/20 for the rest of your life.


He was being sarcastic... I think.

No you are modifying that rendered part. A website can't control what you do with the output.

>Blocking ads is not quite the same thing as modifying a product


> 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.

They don't sue adblockers because they wouldn't win.

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].

[1] http://www.oxfordscholarship.com/view/10.1093/acprof:oso/978...

[2] https://www.bristows.com/news-and-publications/articles/bris...

How many companies do you think have successfully sued ad blockers?

There's far more of a financial incentive there.

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.

Being "right", sometimes, is not worth the fight.

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.

A binding agreement? Why would he sign one of those?

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.

The Wikipedia article on "clickwrap" have reference to 10 different cases clickwrap license upheld by court.

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.

You don't have to literally sign something to be bound by an agreement.

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).

This extension doesn't use the API. It just injects some JavaScript. Just like every adblockers and password manager does.

I know. I think the author might have been interested in the API and signed up separately, though.

> You don't have to literally sign something to be bound by an agreement.

That's only in the US as far as I know, everywhere else you can't be bound by an agreement without signing anything.

This is absolutely false.

Regardless of where you are, the majority of the agreements you enter into are not only not signed, they are not even explicit (but rather implied).

Case in point: practically everytime you buy something and pay with cash, you have entered into a purchase agreement without having signed anything.

These are not terms of use but laws.

"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.

Ah yeah sorry, there's been some misunderstanding, I agree with you.

Well here in the EU you can easily make a contract without signature. Even handshake contracts could be binding.

So thats not true.

"in the EU" is false. There are many different countries and several of those do not accept handshake agreements as contracts at all.

this was a bunch of Tampermonkey scripts... but I don't want to ignore their cease and desist. I... just don't do it.

changing the name is not an issue... however, if I have to take it down, that's moot.

"I... just don't do it."

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 :)

Because... I have lots of things to work on, lots of things I want to build, lots of people I want to talk with.

None of them involve talking with a lawyer in a different country over something that's really not that important in my life.

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.

Especially since anyone thinking it should continue can just fork and do so.

Especially someone who has no existing contractual, customer, or ToS relationship with Slack.

Once he delete it, everyone will lose their fork if they don't have a local actual independent copy from Github

"Deleting a public repository

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 sued another company that extended its listings with their own code and, as I recall, won.

I assume you mean this:


It seems unlikely to apply to a Chrome extension:

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.

What would keep it from applying to an extension? It says sufficient, not necessary and sufficient.

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.

There may be other laws, precedents, and circumstances that are relevant. That doesn't mean that this case is.

> different country

If you are in a different country than US I wouldn't worry at all. I would just avoid using the name "Slack".

Maybe let other people continue it? Shame to throw stuff away. Plenty of countries where that cease and desist would go straight to thrash.

Nothing is stopping other people from doing that now.

> 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.

(I'm agreeing with you.)

It's our right as developers to modify and upgrade the tools we use. It's important to ensure that this remains true both today and in the future.

I wanted to give you a moral boost, in case you were looking for a reason to take a stand. But if you don't want to, that's entirely valid.

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.

They do when you want to redistribute it with their name, which is the whole point of this discussion.

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.

The heart of their complaint was not the name. It was the fact that the extension injects code into their site.

I'm not sure I'd say it injects code in to 'their site', as slacks site never sees the code.

It injects code into the dom model of the users browser.

> the extension injects code into their site.

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?

So, even more nefarious, and in violation of their terms?

That’s what we’re arguing. Slack should not be able to restrict me from modifying the experience on my hardware.

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.

If you are using IE to browsing slack, and IE couldn't correctly render it. It is illegal?

matzy 6 months ago [flagged]

JavaScript runs on the client genius, not the server. You're not changing their product, your modifying how it is run on your personal machine.

@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.

> But I also understand their reaction.

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.

I get it... but literally, there are THOUSAND extensions already injecting javascript on their site.

are they going after all of them? if that's the case, I'd understand.

> 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?

And by writing that way they likely underweight the PR risk to their business. It's their choice, but it sure as hell just turned me off.

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.

Reminds me of when Facebook sent an order to Unfriendfinder:


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.

[1] Here's a fun analogy in a tort law case cited at https://cyber.harvard.edu/bridge/Analogy/analogy3.htm:

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.

Analogies are used a lot in law:


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"

What he needs is to host it anonymously or give it to someone else to host. Corporate vultures can't get you if they can't find you.

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

> My company of 500 with only 30 devs uses it.

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.

Its the opposite at my workplace. Mostly the developers use Slack. What do your devs use instead?

Another Mattermost user here.

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.

We use bonfire, which is the same tool the community at Stack Overflow uses to interact.

Is there a link to bonfire somewhere? You're not talking about Facebook's video call app are you?

it’s this: https://chat.stackoverflow.com but unfortunately, it’s not open source or available for other teams to use in private.

Oh god it's an ugly, slow mess.

- Why does it have list of users with their avatars and everytime new person comes in it has a huge, slow animation lol

- ads for other rooms and quarter of the screen is "best comments top list"

- the chat user avatars are unaligned, some are bigger, some smaller, some have usernames under avatare, some on the right.

I'm not sure if it's a late april fools joke or what's going on here.

This is as far as I've gotten with Google on a mobile phone. http://dev.bonfire.stackoverflow.com/beta-access

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.


I see your 500:30 and raise you with 30:5 at my company. It's complete overkill.

I'm hardly a Slack fan, but, in fairness, I've never considered Slack to be slow or resource intensive. Either the web UI or the (OSX) desktop app.

Or are you referring to audio calls and video calls?

Slack is ludicrously chuggy for basic operations. Why does it take so insanely long to start up?

My company of I dunno, with some 2000 devs uses it. Mainstream is the right word.

Embrace Extend <- we are here Extinguish

MS Teams has become pretty popular, but they haven't marketed it nearly as much as Slack.

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).

Out of curiosity, how do you feel about discord?

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.

Oh you can set up mandatory Slack channels too.

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.

Discord is no better than Slack.

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".

Little late with the reply and it's probably disappointing too. I don't use discord so I don't have any opinions about what their product or future is

It worked out so well for Twitter, why not duplicate that success!

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.

well, his is the second comment in a week that i’ve seen (unrelated to betterslack) that mentioned this point. he’s certainly not the only one!

First time I heard about slack, I thought it was a kind of homage to the distro. I Guess I was also fooled.

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.

Wow a subgenius! That sure brings back memories.

> 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.

This. Who the hell goes to legal and creates PR risk instead of just hiring the dude?

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.

Yep, dead to me too. I decide what code runs on my hardware.


Here's a spiffy new fork: https://github.com/betterlimp/betterlimp

The slogan should be "better Limp than never."

I like it.

Huge thanks for this. Made a fork myself. What is Slack thinking?

I see you've taken it down. Also bullied?

No -- the original author is continuing to maintain BetterSlack as BitterSweet, albeit without publishing to the Chrome store.


I felt it was better to unpublish my (likely to be unmaintained) fork. Probably should have left up a note to redirect folks.

Can't stop laughing right now.

Haha, the diff on the package.json is brilliant!

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."

wow... you turned down an interview at a place you liked because of their tools?

you certainly have stronger feelings about it than I do :)

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.

* Privacy policy does not seem to prohibit much data mining

That, data mining, must be part of the business case. Especially the friend maps they can generate.

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.

There are two problems with this approach:

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.

I dont think they can, or all the adblockers would have been removed already.

Any extension that Interacts with pages. I have so many of them. Vimium injects itself onto every page.

I don't know and I also don't want to figure it out :)

> 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.

change it to 'SlackSucks'. Make it change the logo to a toilet or some sticks of ram that are on fire. It's now a parody.

On a side note, cool to see Uruguayans at the top of HN. Sorry it's under this circumstances.

Congrats on your Stackoverflow job :)

You wouldn't happen to have any recommendations for hiring web-devs here in Uruguay for a small startup? It's CRAZY HARD.

GO 🇺🇾! nope, I’ve never worked for a Uruguayan company ¯\_(ツ)_/¯

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]

[0]: https://github.com/arthurpham/wsjUnblock

that’s def something I’d like to try if they are ok with it

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]

[1] https://www.bristows.com/news-and-publications/articles/bris...

[2] https://www.bbc.co.uk/news/technology-39490317

[3] http://gameslaw.org/bots-and-buddies-the-blizzard-v-bossland...

I'd say a large part of blizzard winning this case was the intent of the software. The interfering software was intended to facilitate cheating.

I think it would be unlikely to have won, had the software been made to streamline the game or make it run faster.

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.

There's some excellent analysis of this sort of case here https://ir.law.fsu.edu/cgi/viewcontent.cgi?article=1101&cont...

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.

[1]: https://developer.chrome.com/webstore/terms

What if it's a greasemonkey script?

greasemonkey doesn't target specific website. It's a generic approach.

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.

The user script typically does, though.

I'd love to hear more about this from someone with legal expertise.

It makes no sense for them to claim that every extension published on the Chrome store needs to comply with their acceptable use policy...

If that were true, then wouldn't 1Password and any other extension that uses a content script also be considered unacceptable?

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.

[1]https://riot.im/ [2]https://matrix.org/blog/home/

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.

woooooowwwwwww so... I could use riot to connect to my company’s slack?

that’s a dream come true!!! I’ll def check it out

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.

you will def see me there

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.

[0]: https://homeworkhomie.com

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 I make a browser extension that grabs your auth token and all of your messages and sends it to my server. How is slack meant to fix that?

I can ask you for your slack password, and you can then tell it to me. How can slack fix that?

Any extension that asks for the permission to read data off webpages can read data off webpages, yes.

It's the user's responsibility to not install such an extension, not the company's responsibility to do whatever the hell they're doing here.

Anyways, this extension wasn't malicious. Its source code was available freely, and auditing it reveals nothing malicious.

Hard to solve that if the browser allows that via the extensions mechanism.

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 is competition out there, they just haven't made enough noise yet. See Fleep for example: https://fleep.io/, Rocket Chat etc.

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.

Does Google Docs have a non-web client (besides mobile)?

But I agree. And even outside enterprise, their web client is the least bad option if you have to use Slack.

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.

are you thinking about opensource? I don't think it would be opensource

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.

Nope. There are ways to reverse engineer closed source apps and inject code into them.

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.

oh, yeah... that's something I want to look into

Anything that moves away from Electron is a plus in my book

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact