EOL: Legacy Chat Embed


#1

TL;DR
If you are embedding the legacy Twitch chat URL (www.twitch.tv/<channel>/chat) in an iframe, this embed will not be functional after March 31.

Please update your embeds to the new URL: www.twitch.tv/embed/<channel>/chat

Why are we doing this?
The legacy Twitch chat is built on a separate codebase that is no longer being maintained.

How is the user impacted?
The new embed URL will introduce two changes:

  • The settings cog will be disabled.
  • The first time a user attempts to send a message, a popup will warn the user that they are sending a message to a Twitch chat channel. This setting is saved until the user refreshes the page.
    Both of these changes are required to address existing security concerns.

NOTE: When not embedded (such as clicking through a bookmark), the legacy URL will redirect to the full popout chat experience without these restrictions.

— UPDATE: 2018/04/06 —

tl;dr — We’re pushing back the legacy chat embed EOL to 4/20 to coincide with the EOL of legacy chat in its entirety. Embeds will continue to function until this time. On 4/20, legacy chat will no longer be available (as an embed, or otherwise). I know this is a tight timeframe for some folks, so please feel free to reach out if you need any assistance or additional clarification.

Also, just to reiterate; the primary motivation for this move is to protect the safety and security of our community. The legacy chat embeds are susceptible to attacks known as ‘clickjacking’. This is not a risk we feel is acceptable, and it is for this reason that we must continue with the EOL process.

There are currently no plans to reimplement the features which have been removed. We have been working closely with our security teams to ensure that we are only implementing features which don’t pose a security risk.

Some additional context for the curious:

Originally we wanted to have the Twilight (new) version of the embed out and deprecate the Ember (old) Popout in August when Twitch Everywhere launched. This was pushed back because people who used the popular extensions BetterTTV and FFZ were upset that their new extensions wouldn’t work in Twilight and thus needed the Ember Popout. Due to that, we left the Ember popout live for those users. A side effect of that was that the Ember Popout route still operated and was still able to be embedded. This was a known security risk, but one that we were okay with given the timeline to deprecate shortly in the future.


#2

Why not remove the settings cog instead of disabling it from the embed since it won’t be used anyway because it’s already disabled?


#4

Just to double clarify, this means nothing is changing in regards to the unembedded legacy chat, correct?


#5

Please allow us us to provide a token to skip this, cause this is incredibly annoying for the users. I don’t know how much you test these things, but I got a barrage of confused users constantly messaging me due to this popup implementation, and I had to switch over to the legacy embed because of it.

If the user dismisses the popup without reading it (which sites use those vanilla popups for anything else than spam in 2018 anyways?) their whole session is screwed, and there’s zero explanation on what’s going on. Messaging just won’t work.

Absolutely terrible experience for the users.


#6

I also have user experience concerns with the current implementation of the new embedded chat page.

Regarding the settings cog, you are preventing users from controlling the chat experience in ways that are not a security concern. Toggling timestamps or the dark theme are useful, and completely locked away now. There’s no need to ditch the whole menu just to hide the moderation tools.

And on the topic of the dark theme, the newer standalone chat endpoints don’t even offer a way to toggle the dark theme. Please bring that back.

I agree with moocat on this. Unfortunately, I understand that you pretty much have to use confirm() to avoid having your UI painted over by a malicious hosting frame. My main problem with it is that if a user does press Cancel and they try to send a message again, there’s no feedback at all. There should be a message explaining the situation to the user.

Some kind of token system or a white-list of good referrers to disable the elevated security level for pop-outs would be appreciated.


#7

I understand twitch wants to evolve, and progress, but legacy chat is still very much the stable staple, and since twitch won’t offer the same amount of moderation utilities, or user friendly integration, I see no real need to constantly place a tried and true system that is legacy chat under so much scrutiny and carelessness.

I would like some in-depth details on how or why legacy is a security risk, and why the wanton desire to remove and abolish it completely.


#8

@moocat, @SirStendec thank you for the feedback! I will make sure the team takes your concerns into consideration.

@Mozarts_Ghost I’ll do my best to gather additional clarity around the specific motivations behind these changes.


#9

I am in a similar position to @Mozarts_Ghost here.
My company migrated to the new embed and this change over has been a fairly large nightmare for my clients. It got to a point this weekend where we had to revert to the old embed just to curb the issue reports we were receiving surrounding it. All moderation is disabled, whispers are disabled, the visuals for raids are absent even though the raid triggers, the alert on first message is incredibly invasive, and we’ve had multiple reports of CSS bugs where chat goes blurry with screenshots to corroborate it.

Does bringing a functioning page to EOL before having it’s replacement in a fully functional state really make sense for the userbase? These changes are hindering companies that build solutions for broadcasters and viewers. It feels as if they have been made with no regard to third party developers and the broadcasting community. The proposed expectations of “just build your own” are unreasonable to say the least. If every company in the space had to maintain their own chat client no extensions, overlays, or other tools for broadcasters would ever be built.


#10

Thank you for your feedback, @Santa. I will make sure it’s received by the team!


#11

I completly agree. I mean if a user is authenticated and is a mod in a channel that user should be able to do his work in embedded chats also.

I can understand that twitch might be concerned about security on the third party sites embed the chat and therefore try to minimize the power a user has from that places but still a bit odd indeed


#12

I’ve been in communication with the chat team, and here is what we came up with.

Please let me know what you think. I will continue to ensure your feedback is taken into consideration.

The chat settings cog being disabled was a broad attempt to close a clickjacking vulnerability. However, we agree that many non-moderation settings are useful to all users. We’re aiming to re-enable some of the chat settings that have low user impact if clickjacked: chat color, badges, timestamps, and hide chat before 3/30. Moderator settings will continue to be hidden.

Dark mode is intentionally not settable in the embed because the intent is for web developers to use the light version or force the dark version (via the ?darkpopout query param, e.g. https://www.twitch.tv/embed//chat?darkpopout) to match the style of the surrounding page.

We 100% agree that feedback when a user presses “Cancel” on the popup is crucial. We will add some messaging (design pending, but likely around the input box) explaining the situation before 3/30. Unfortunately, the popup is a requirement in order to deter malicious websites from capturing keyboard input without the user’s knowledge.

As expected, forcing a more restrictive version of chat for embeds will be a controversial change. There are a two main reasons for EOLing the legacy version of chat:

  • Feature support: Chat on a Twitch channel page, the (non-legacy) embed chat, and popout chat all share the same React code with minimal differences, compared to the Ember code in legacy chat. New features, bug fixes, and overall maintenance are being contributed to the React codebase only.

  • Security: By allowing embedding of an unrestricted version of chat, a malicious webpage can trick users into making arbitrary clicks/keystrokes (See: https://www.owasp.org/index.php/Clickjacking). This exposes a risk to all users, specifically moderators and users with bits. This is the reason for the differences between React chat (hidden chat settings, alert popup).
    We’ve tossed around the idea of whitelisting domains and may revisit this in the future.

To address some other feedback:

whispers are disabled: This is a regression from migrating to the new JS framework. The intent is to bring this behavior back to embed/popout chat, but no ETA at this moment.
the visuals for raids are absent even though the raid triggers: We are aware of a bug that causes raid messages to not be shown in the target channel’s chat. If you’re referring to the raid overlay at the top of chat when a raid is initiated, that should be working in legacy and new chat. This bug should be fixed before 3/30.


#13

Thanks, really great to hear pretty much all these issues are getting fixed. :+1:

I do have to point out that I feel like that’s the only reason the legacy chat is so important and highly valued. It’s because the React version has made things so difficult for extension developers and the like that many are forced to rely on the legacy chat.


#14

Hello again, friends!

I just wanted to post an update after a great deal of internal discussion on the best way to proceed, based on your feedback.

tl;dr — We’re pushing back the legacy chat embed EOL to 4/20 to coincide with the EOL of legacy chat in its entirety. Embeds will continue to function until this time. On 4/20, legacy chat will no longer be available (as an embed, or otherwise). I know this is a tight timeframe for some folks, so please feel free to reach out if you need any assistance or additional clarification.

Also, just to reiterate; the primary motivation for this move is to protect the safety and security of our community. The legacy chat embeds are susceptible to attacks known as ‘clickjacking’. This is not a risk we feel is acceptable, and it is for this reason that we must continue with the EOL process.

There are currently no plans to reimplement the features which have been removed. We have been working closely with our security teams to ensure that we are only implementing features which don’t pose a security risk.

Some additional context for the curious:

Originally we wanted to have the Twilight (new) version of the embed out and deprecate the Ember (old) Popout in August when Twitch Everywhere launched. This was pushed back because people who used the popular extensions BetterTTV and FFZ were upset that their new extensions wouldn’t work in Twilight and thus needed the Ember Popout. Due to that, we left the Ember popout live for those users. A side effect of that was that the Ember Popout route still operated and was still able to be embedded. This was a known security risk, but one that we were okay with given the timeline to deprecate shortly in the future.


#15

I rescind my compliments. Maybe if Twitch had actually made some effort to help extension devs instead of just making their lives hell this wouldn’t be such a difficult transition. But comparing new chat to legacy chat w/ FFZ or BTTV…it’s not even close. There’s no way that gap is gonna close terribly much in two weeks, and any good amount it does will I’m sure come at the cost of a bunch more unappreciated late nights by SirStendec.

I think the injustice of how much unpaid dev time goes into fixing messes made by Twitch’s paid developers is what really boils my blood about the whole new chat ordeal.


#16

As much as I agree with you, this sort of thing is what happens when you depend on undocumented APIs and hacks to implement things.

Which when it comes down to it, that’s exactly what FFZ and BTTV are doing. Breakages should be expected.


#17

Yeah, but that tired argument ignores: 1) that there is no official alternative to providing features like these in a nice way, 2) how prominent these tools have become in the community – which itself demonstrates a huge demand for features that Twitch is failing to deliver on it’s own – and, 3) that breakages were always expected to some degree, but the nature of the new chat code requires something greater than even a complete rewrite.


#18

That you know of, that people can talk about due to NDA’s that they may or may not be under.

Stendec has commented publicly on how much of a “joy” React is to Traverse.

I anticipate that if you had access to the numbers, you’d find more people are using a platform that BTTV/FFZ doesn’t work on, than does. They are definitely “power user” tools.

Twitch Feature requests can be added to the Twitch Uservoice https://twitch.uservoice.com/

Given that Twitch changed from Ember to Twilight/React doesn’t surprise me at all…

Finally I’ll say this: there is more to consider about if (taking a single feature) highlight/banning words viewer/client side is a good thing or not, did you consider the possible routes of how people can use this to abuse other people.

Reference Firehose? How to get authentication token? this guy was using a tool he shouldn’t have had access to, to drop in and abuse/spam a chat about batman and deepbot support. For example (A poor one but highlights an abuse route).

Twitch has to consider what features to provide on all platforms, whilst also considering the safety of it’s users, since you also don’t want too much feature disparity between console and computer and mobile.

Which is before we even talk about common UI to update everything on all platforms.

Or we even get onto nigh unlimited emotes or gif emotes which have they own issues introducing lag into a browser, and interfering with the primary function of Twitch, the delivery of live video. (Gif emotes and unlimited emotes can dramatically increase the amount of memory a browser will use due to caching and the amount of painting the browser has to do, hardware acceleration other performance things aside) Thats why the cheermotes are static in the newish bits leaderboard for example. Why waste browser paint there.

Oh and now lets get onto the fact Twitch needs to work well on “most platforms that the analytics package says Twitch is being accessed on”. Not everyone is on the latest build of windows 10 at a sensible screen resolution running a recent browser. For example.

Gotta think beyond “just” providing extra chat features. Everything has to work for everyone, in a performant way, without things being “too” different across all platforms.

I could go on.

TLDR: theres more to consider about adding a feature to chat than you realise.


#19

No doubt, yet these tools still maintain a huge mindshare and are very important to many communities.

I would love for you to explain to me how censoring words for myself has any avenue of abuse. Is muting users abusive then? And comparing highlighting some messages in a chat you’re in to automated monitoring of all chats on the site is just nonsense. If you want to abuse along these lines then you just use a bot.

Agreed, although it’s kind of a joke considering how most platforms still don’t even support displaying chat at all. 2018 and I’m still stuck casting a whole screen to get Twitch with chat on my TV.

Which is why I’m pretty grateful for FFZ features like chat batching that actually decreases lag on my crusty old laptop, minimalistic UI to get rid of all the pointless padding that makes less of chat visible especially at smaller window sizes, and portrait mode which is an absolute godsend for my vertical monitor. Ironically, this setup makes Twitch on my desktop much more consistent with the mobile app’s layout…soooo, what was that about disparity between platforms? :thinking:

Trust me, I’m acutely aware of all that goes into supporting new features, and never suggested the hundreds of options these extensions bring should all be built-in. That’s precisely why they’re important. Still, there are clearly a ton of improvements that could be made to chat, and if some unpaid developers with no choice but to hack on a system working against them can accomplish so much, then it’s hard to make excuses for a team of six-figure devs backed by the largest company in the world.


#20

The embed looks to work better now, but there are some issues with the border.
There’s a left and right border on there, which makes it look very odd on light-theme (on the .tw-border-l class)

Would be great if that border would get removed so we can use our own borders, thanks!

Capture


#21

Also a problem with the background on dark theme, where it’s not properly set to the dark background, which results in problems when doing border-radius.

Should add this to fix it:

.tw-theme–dark.tw-c-background-alt-2 { background-color: #0e0c13!important; }