Safe harbour
If you are testing SparkStream within this policy, you have our authorisation to do it, and we will not take legal action against you for it.
That includes the Computer Misuse Act 1990. We treat work done inside this policy as access we have authorised, so we will not report you to the police over it, we will not bring a civil claim, and we will not ask anyone else to do either. If a third party comes after you for something you did here, tell us. You were acting with our permission, and we will say so.
This holds as long as you stayed inside the scope and the rules below and acted in good faith. Good faith includes getting it wrong. If you overstep while genuinely trying to stay inside the lines, tell us what happened and we will treat it as an honest mistake, because that is what it is. What is not good faith: taking or selling data, breaking the service on purpose, going after our users, or holding a finding over us for money.
We can only speak for ourselves. Twitch, Stripe and our hosting provider each have their own policies, and this one does not authorise you to test theirs.
The closed-source part
Reverse engineering, and the limit on it
SparkStream is closed source, and our Terms say you may not reverse engineer it. This is the narrow exception to that clause for security research, and it is a real one.
Starting with the honest part. SparkStream is an Electron app, so once it is installed on your machine, most of it is sitting on your disk in an archive anyone can open. That is simply how desktop apps of this kind work. A policy that depended on you not noticing would waste your time and insult your intelligence, so we are not going to write one.
So while you are looking for a security problem, you may take the app apart on a machine you own. Unpack the installer and read what is in it. Open the archive and read what ships inside. Watch what the app does: its network traffic, the overlay server it runs locally, what it writes to disk, what it asks your operating system for. Attach a debugger. All of that is testing, and all of it sits inside the safe harbour above.
What the exception does not cover is everything that is not security research. Do not publish our source or our assets, do not redistribute SparkStream or a modified build of it, and do not use what you find to build something else. Reading the code to find a flaw is what this permission is for. Taking the code is not, and nothing on this page changes that.
The Terms say you may not reverse engineer SparkStream except where the law expressly allows it. That clause is there to stop people copying the product, not to stop people finding holes in it. This page is us saying, in advance and in public, that we will not treat good-faith security research as a breach of it. Some of what is described above you would very likely be entitled to do anyway; we would rather say yes plainly than leave you working out which half.
There is a second clause, and it matters more if you are testing the server rather than the app. The Terms also say not to probe the SparkStream server or try to reach data that is not yours. Testing inside this policy is our exception to that as well. You may probe the service, and you may show that another account's data is reachable, because that is what an authorisation flaw looks like when it is demonstrated properly. What stays off limits is reading, copying, changing or deleting that data once you have shown you could get to it. That line is drawn in the rules below, and it is the same line: showing you could reach something is the finding, going in is not.
Where to look
What you can test, and what is off limits
Three things are in scope: the app, the server, and this website. The out-of-scope list is short, and it is meant literally rather than as a formality.
SparkStream for Windows, as we publish it. The installer, the app itself, the overlay server it runs on your own machine, and the way it talks to Twitch and to us.
The SparkStream server: accounts, licences, support tickets, the hosted chat bot, and every endpoint behind them.
This website, including the moderator panel, the approval queue, and public channel pages.
No flooding, no load testing, no resource exhaustion, and nothing else whose point is to make the service worse for the people using it. Telling us that something could be overwhelmed is welcome. Overwhelming it is not.
Bulk mail through our forms, sign-up floods, and filling the support queue to see what happens.
Phishing or pressuring anyone: us, our suppliers, streamers who use SparkStream, or their moderators. That includes trying to talk support into giving you access.
Anything involving premises, post, hardware, or people in person.
This policy covers testing us. It does not cover testing them. Their accounts, their machines, their channels and their viewers are off limits, and a finding that only works by attacking a real streamer is not one we can accept.
We rely on Twitch, Stripe and Railway, and they are not ours to authorise. If you find something inside one of them, report it to them. If it is something about the way we use them, that is ours and we want it.
Our Terms of Service contain two clauses that, read on their own, would tell you not to do some of what is in scope here. Both are answered above, under Reverse engineering.
How to test
Rules of engagement
These exist because SparkStream runs on real people's machines while they are live in front of an audience. Nearly all of it comes down to one idea: prove the problem, do not exploit it.
Send it to us before you send it anywhere else, and give us a chance to fix it. There is more on timing further down, and it is a request rather than something we will hold over you.
Test against accounts you control. If you need two, make two. Signing in as somebody else is not testing.
Do not read, copy, change or delete anything belonging to another user. Showing that you could reach it is the whole finding. Actually reaching into it adds nothing we needed and takes you outside this policy.
It happens, and it is often how the bug gets noticed in the first place. Stop there, do not save or share what you saw, and tell us what it was and how you got to it. We will treat that as you helping us, because it is.
Do not delete, corrupt or lock anything. Do not test in a way that disrupts a live stream: for most of our users the app is running while they are on air, and an outage at that moment is not an inconvenience, it is their show.
The smallest thing that demonstrates the problem is the best version of it. One request that shows the flaw is worth more to us than ten thousand that hammer it.
Once you have shown you can get in, stop. Chaining a finding into as much access as it will give you is not extra evidence, it is extra harm.
Our side of it
What we owe you back
A disclosure policy that only lists your obligations is not a policy, it is a disclaimer. Here is what you get from us.
A real reply from a person, confirming we have your report and have read it. Five is the number we can keep in a bad week, and there is a note below on why we did not say twenty-four hours.
Whether we could reproduce it, what we think the impact is, and what we intend to do about it. If we decide not to fix something, we will say so and say why, rather than going quiet and hoping you lose interest.
At least once a fortnight until it is closed, even when the update is that we are still working on it. You should never have to chase us to find out whether your report went anywhere.
You hear from us at the end, not only at the start.
Your name, a handle, or a link, on the acknowledgements page, and we will show you the wording before it goes up. Staying anonymous is the default: we will not list you unless you tell us to.
Because SparkStream is one person, and twenty-four hours is a number we could hit most of the time and then miss on exactly the week it mattered. A window we keep is worth more than a window that sounds impressive. In practice you will usually hear back much sooner.
We would like ninety days to fix something before you write it up, and we will normally be far quicker than that. This is a request, not a condition of the safe harbour above. If ninety days pass, or we stop replying to you, publishing is your call and we will not hold it against you. We would rather be embarrassed in public than have a policy that lets us stall forever.
Money
We cannot pay you, and we are not going to pretend otherwise
There is no bug bounty here. No reward pool, no tiers, and no payment for a report, however good it is.
SparkStream is one person and it is not yet profitable. Paying for reports would mean promising money we do not reliably have, and a bounty we cannot honour is worse for you than no bounty at all. So what a report earns here is credit, if you want it, a real answer from a real person, and the thing actually getting fixed.
This may change. If SparkStream gets to the point where paying for reports is honest rather than aspirational, this page is where it will be said, and it will apply to everybody rather than being arranged quietly case by case. Until then, please read the absence of a bounty as us being straight with you rather than as a hint that reports are unwelcome. They are very welcome.
Get in touch
How to report something
Email us. You do not need an account, you do not need the app installed, and there is no form to fill in.
What you found, how you found it, and what somebody could do with it. Steps we can follow ourselves are the most useful thing in any report: a short description with them beats a long one without. A screenshot, or the request and the response, helps.
If your proof involves somebody else’s information, describe it rather than pasting it. Never send card numbers, anyone’s or your own. We refuse anything containing one and will ask you to send it again without.
Say so, and tell us the name, handle or link you want used. It goes up once the fix is out. If you say nothing, we will assume you would rather stay anonymous.
People we have credited are listed on the acknowledgements page. The machine-readable version of this policy is at /.well-known/security.txt.