Around the time that Kraken was dying, I was doing something (I forget what, probably bits products), and found that the Twitch Developer Rig was totally hosed, since it was calling Kraken and hadn’t been patched. (It since has been but still being a little weird with some stuff with some of my Extensions, but I digress).
So I went and built my own tool, it’s part “API testing tool” part “useful things for managing Extensions”. And released Open Source over on GitHub under the WTFPL aka – “Do What the F*ck you Want to Public License”.
Main reason for making a tool rather than a bunch of test scripts, was I wanted to easily store and recall my Extension Client ID’s Extension secrets, and easily generate App Access Tokens for the relevant API’s that needed.
It should offer just about every “useful feature” from the Developer Rig, that there is a public API for, except for “Views” and “Start my servers for me”. For a easy summary of the Features Available, checkout the Readme on the GitHub!
Well it looks like Twitch is updating the rules around extensions! It’s a good change even if I do need do an update to pretty much EVERY single Extension I run….
You can read the details on the change over on the Twitch Developer forums but here is the long and short of it how I see it.
There has been a recent spate of “attacks” related to Extensions where a “compromised Extension”, allows “not the developer of the extension” to obtain the IP Address of an Extension User/Viewer. And it’s only made it onto the Twitch Reddit as it was continually abused when discovered rather than responsbily disclosed to Twitch.
Side Note: You can find out about Security and Responsible Disclosure over on https://www.twitch.tv/p/en/security/.
You find a problem?
Don't abuse it, report it responsibly and give time for Twitch to fix the problem before you go public.
The same applies when Disclosing Security issues to any site or tool, they will have a method to report security issues, and generally you give time for them to resolve before going public.
For all intents and purposes an Extension is just a Website, sat in an iFrame on a Twitch page, that could be on top of the player or below the stream.
Most Extensions usually involve calling an API or loading External images. This API and image storage service will generally be controlled and owned by the Extension Developer.
So for example, the IGDB.com Game information makes a call to my Extension Backend Service, which then proxies the request to IGDB’s API for data and checks a cache so I’m not hammering the IGDB API every second.
Side Note: In this case IGDB's API requires this route, as the API can't be called directly due to the Authentication Token requirement.
The IGDB extension will show images from IGDB’s CDN for cover art and screenshots, which means the users IP address is then passed to IGDB’s CDN, for the same tracking purposes.
The IGDB extension is configured to only allow images to be displayed from IGDB’s CDN or Twitch’s CDN (when I defer to using Twitch Cover art instead).
Now a given extension could directly call an API rather than going via an EBS/Server. Which means the IP Address may get collected by the API Logging. I avoid this route as I prefer to call my server and cache data, why go and get a players Game Inventory from the Game API if I already collected it 10 seconds ago? So save some time and use a cache, making a better experience for the Viewer/User of the Extension.
Now the “Exploit”
Now the “exploit” that has been occuring is from Extensions that allowed the broadcaster to add an image to the Extension to customise or theme it to their channel.
And what developers of these Extensions did here was let the broadcaster enter ANY URL. Which meant that an attacker could put an image URL to anything.
In this case, generally the old forum signature style PHP Image scripts that would do the “Hey you from Country” where the Country is GEOIP’ed from the users IP Address.
Personally if I was allowing broadcaster customisation using images, I’d have broadcasters uploading images to my server and my server then handles hosting and distribution. Which means I can then optimise that distribution of content (why send a huge image to mobile when I can auto resize and send a mobile optimised image) and plug this obvious “data leak”. And means my Privacy Policies are easier to write for GDPR compliance/etc, when I don’t have to say “data goes anywhere as I allow any hosting service”.
But Developers may avoid this as it means that their free to run extension now costs money to run. Using the config service to store config, which is configured from the config view all internal to Twitch using the Extension JS helper, for example. Then allow an external image from Imgur or any other Hosting provider. (This being the loophole/exploit)
But What can an attacker do?
Not a lot. Generally just scaremongering.
Barry Carlyon, yes quote me on this!
Sure, an IP Address can be used to obtain an approximate location of the person using that IP Address, but it’s often wrong (quite often my IP resolves to North Wales, and I’m sure as hell not in North Wales, which is funny when I get Spotify ads in Welsh).
And sure an attacker might throw out a DDoS Attack, but an ISP will mitigate that, and potentially take additional actions against the Attacker.
And in all cases, all they have is an IP Address, they don’t know whose IP Address they collected.
What is Twitch Doing?
2.12 You must provide all URLs that are fetched by the Extension front end on each version submission, this includes but is not limited to images, video, audio, and fetch/XHR requests.
Twitch is updating the Extensions Guidelines and Policies with Policy 2.12, included in full above.
Extension Developers are required to provide a list of domains that the extension will call, both for “What API domains are you calling” and “what image asset domains are you calling”.
It is an expansion on the CSP that was already in place, that prevents offsite JS and inline JS being executed.
So Twitch will now also provide CSP Directives for img-src, media-src and connect-src.
You can read about Content Security Policy over on MDN Web Docs. But heres the three items in a quick summary, please make sure to visit the MDN documentation for further reading!
media-src and img-src
In addition to this make sure to check out the Restrictions on content section of the Extensions Documentation for further reading on other limitations and restrictions!
Developers will be able to provide this domains and URLs, under the “Capabilities” tab in the Extensions Dashboard for a Version of an Extension. Heres a screenshot of the new fields, the placeholder test shows full domains including schema, but schema list domains are accepted. (Refer to the MDN Web Docs)
It’s a good change, and will help improve security for Streamers, Developers and Viewers alike.
I will be updating my blog series with a new Entry when I’ve updated my local test rigs to help simulate and test this new requirement! It should be a relatively straight forward thing to implement as I’ve been working with CSP’s on Websites I’ve been building to improve security and prevent CSRF attacks and the like.
January 25th 2022
Developers have until January 25th to get their updates in as that is when the CSP revisions go into place!
This will be the first post in a two/three parter on this extension since it also serves as a good example on how to utilise a number of Twitch and IGDB products/API’s to achieve the end solution! But today just an announcement post!
One of the features of the Dropped Frames Extension, that is used during Dropped Frames on itmeJP’s channel on Wednesday’s, is that I’ll push a Game Information box to the extension that shows information about the game the panel is talking about. That information box will collect information from the IGDB.com API and then present that information to the viewer. Heres a quick example screenshot for Mind Scanners:
You can see on the left the “box” with the cover art appears on the left over the Game name that is baked into the overlay and on user mouse over of the box the game information box is then displayed. Title, brief synopsis, cover art and store information are presented.
When I showed this off in the IGDB discord (prior to E3), I was asked, if this was a publicly available thing, and I replied, sorta but not really. Which then led me to go and create a seperate extension for anyone to use, during a smidge of down time I had recently!
So I present the IGDB.com Game Information Extension!
It is availble to both Twitch Mobile and Desktop users. On Desktop both Component and Panel are supported. I usually recommend the Component slot as it saves users having to scroll down, and it’s auto collapsed out of the way until a user clicks on the [IGDB] taskbar icon. And generally speaking most streamers have the Component slots free anyway. ITS FREE REAL ESTATE MAN!
Via the power of Twitch EventSub, it will even automatically self refresh if you change games during a stream and will gracefully fail back if you pick a game that is not on IGDB.com or a category that is not a game, such as Special Events or Just Chatting, it’ll just show the Twitch Box art/title instead.
Streamers will just need to link their Twitch accounts via the Extensions Configuration view, or the Extension Mini site, to enable auto updating!
To checkout the extension, or to see live streamers running the Extension, and to see the install instructions pop over to the mini site for the extension over at twitch.extensions.barrycarlyon.co.uk/igdb/ or visit the extension directly on Twitch.
The beauty of IGDB.com is that it POWERS Twitch’s categories and being crowd sourced, if the information is wrong, outdated or missing, anyone can submit a fix or change and await an IGDB Admin to accept the change.
Last week finally announced the deprecation data for Kraken also know as v5 Twitch’s legacy API.
You can find the details of which over on the Twitch Blog or TwitchDev’s Twitter at
For many Developers using Twitch API products this means little beyond there being a date to make sure you have moved everything you need to to Helix/New API. And that date is February 28th 2022.
Twitch will also be running a phased Shutdown timeline with periodic outages on the Legacy API of increasing length during the start February starting on the 7th at 11am PDT, and full details of that are on the earlier linked blog post.
For NEW developers looking to work with the Twitch API products, as of last week you can’t access the Legacy API at all, if you have never used the Legacy Twitch API you just can’t access it.
and those that have not made requests to the v5 API before July 15, 2021 will no longer be able to access v5.
Other things to note is the end of WebSub based Webhooks as well, that ends in September! Details about that are also on the Twitch Blog
So now is the time to get your feature requests for the New API and/or any missing features into the Twitch Uservoice theres a few new ones popped up recently for “missing” New API features. So get your voice heard on missing things. Or you can check out my super exiting Google Doc I have for tracking a number of User Voices I’m intersted in and/or have created you can find that here!
And if you need help on Migration from the Legacy API to New Twitch API, check the migration guide or Join Us on the TwitchDev Discord or Forums, see the Developer Support page for those links!
Update: This also effects a number of Extension EBS endpoints! Thankfully this sort of update won’t require extension review, since it’s EBS endpoints! Todays Announcement on that is here on the forums
If the Developer is new to building Twitch Extensions, it’ll also provide easy access to a number of Examples, which you can also find of the TwitchDev GitHub, but once you are into building your actual extension, you’ll be able to do the following things!
Interact with the Config Service, if used for your extension, without having to write custom scripts
Manage your Bits Products, if your extension uses Bits, the only place to manage your Products and pricing is via the rig
View your Extension under a variety of views, and view configurations.
The rig also does some other useful bits and pieces that developer may have a use for, it provides the ability to start/stop both Frontend and EBS/Backend servers/services, that may be needed when local developing an extension. The paths and start commands can be saved with the project, which will save you time when starting Development for the day.
How to use the Developer Rig
The Monetization tab we will cover later when we talk about Bits in Extensions, and the same for the Configuration Service when we cover that!
So we’ll focus on the big thing the Developer Rig does for you.
First the most important thing that developer needs to be aware of when using the Developer Rig, is that whenever you change any settings for your Extension on the Developer Console you need to let the Rig know you did this, and you can do that on “Project Details” and click “Refresh Manifest”. The Project Details section of the Project also allows you to select which Version you are working on, so if you just released Version 0.0.1 and you started Working on Version 0.0.2, don’t forget to update the rig! Otherwise your test Extension Views will show the live and released version of the Extension instead of your in development version!
Normally, if you wanted to Test a Video or Component Extension, the channel that you would want to test the Extension on would have to be live and Streaming, the developer rig negates that requirement.
Editors Note: Added/Updated 18th March: In a similar fashion, you can use the the devleoper rig to simulate mobile/tablet views in various Dimensions without having to have the device in front of you. Naturally when it comes to mobile/tablets you should test your extension on devices if possible!
Further more if you wanted to see what your Extension looks like to people whom are not even logged into Twitch you can’t test that on Twitch itself, since if you are logged out then you are not a valid member of the Allow List.
When creating a view, the rig will ask you which View Type you want to test, and what “feature flags” you want enabled, these feature flags, which we’ll cover in a later post, will let the Twitch Extension JS Helper know what is and is not available. As a short TLDR: lets the extension know if Bits Support is enabled, whether the extension should show the Bits Usage store in the extension or not for example.
It’ll ask you to set the Channel that the extension is “active on”, and ask you to set “who” is accessing the Extension. So you can easily setup any combination of views side by side, which is handy if you want to test what the extension looks like for different users on one page with a easy “Refresh All Views” button.
Finally the Extension View for a given view lets you easily send test context changes to an extension.
This will allow you to test how your extension reacts to subsequent calls to onContext easily.
onContext which we will cover more in a future post, is very powerful when you need you extension to react/respond to various things that could happen during the lifetime of a session of the page loaded. Do you need to resize your extension when the player changes dimensions? Do you need to show/hide your extension in response to the player controls being visible? Are two examples.
What can’t it do?
So we talked about what the Developer Rig can do for you, but since the Developer Rig is completely optional (except for Bits products management), why would you choose not to use it?
The Developer Rig will let you setup a view, and the user for that view, but it does not let you test Viewer State changes.
This would be, for example, a user whom is logged in on Twitch changing from “logged out of your extension” to “logged in to your extension”, commonly referred to as “Sharing your Twitch ID with the extension”. Or you the Developer calling the RequestIdShare function to prompt the user to login, which results in nothing happening in your Extension.
Bits Development can be somewhat difficult in the rig, in the rig you are limited to the loopback function which isn’t very useful for testing, but we’ll cover Bits testing Scenarios in a future post!
Config Service setting from the JS helper can be interesting in the rig, but thats more down to the helper function argument order rather than the rig! Personally I do all my configuration service work from the API, and we’ll cover that in a future post.
Next week I’m not sure what we’ll cover. I think we’ll actually start a little building and testing some features, and some ideas on making your own test Rig to host your front end code, in a way that will help you avoid some pitfalls that we’ve covered in this series so far!
BUT MOTHER I CRAVE VIOLENCE
Well, until I write the next part if you want to read more about the Developer Side of Extensions, you can pop a visit over the to the Documentation or take a look at Twitch’s Introductory Page and you can always join us on the “TwitchDev Discord Server”, visit the Developer Support Page for the current invite link!