FAQ - Real-Time Streaming

Frequently Asked Questions about Real-Time Streaming

---

Is there a limit to the number of data buckets I can stream to?

No. You are only limited by bandwidth and data rate as described here. You can have as many data buckets as you can fit in those limits.

 

 

Is there a limit to the number of data streams I can have in a data bucket?

No. You are only limited by bandwidth and data rate as described here. You can have as many data streams inside a data bucket as you can fit in those limits. That being said, too many data streams inside a single data bucket will be overwhelming and messy.

 

 

Is there a limit to the number of devices that can stream into my account or to a single data bucket?

No. There is no limit to the number of devices that can send data into your account or even into a single data bucket.  

 

 

How long is my streaming data retained?

Student accounts have 3 months of data retention and Individual accounts have 1 year of data retention.

 

 

Can I combine a data streams from different buckets into one Tiles or Waves view?

No. That is not a function that is available at this time.

 

 

Does Initial State focus on data security?

At Initial State, we take security very seriously. We're constantly re-evaluating current trends and vulnerabilities in the mechanisms available to insure the confidentiality and integrity of the data you and your devices and applications send to us.

 

 

How does Initial State protect confidentiality and integrity sending data over the Internet? 

We exclusively support TLS v1.0 and TLS v1.1 and higher. If you're performing any secured HTTPS connection to an Initial State API, you can assure that we do not allow the client to downgrade the protocol in the handshake to a lower version like SSLv1, SSLv2, or SSLv3.

 

 

Do you support SSL? And what's the difference between SSL and TLS?

In order to secure communications from client devices to Initial State's APIs, we utilize TLS (Transport Layer Security). TLS is the newer, more secure evolution of the SSL (Secure Socket Layer) protocol. SSLv3 has been around for nearly 18 years and therefore is widely supported by many legacy clients. Because of this, many servers will build support for SSLv3 in order to accommodate as many clients as possible.

However, SSLv3 was discovered to have a severe vulnerability that compromised it's confidentiality by some Google engineers back in 2014 in an attack they nicknamed POODLE. Because of this, security researchers recommended the immediate discontinuation of support and use of SSLv3. As of 2015, most major internet services discontinued their support and offering of SSLv3. Initial State discontinued support for SSLv3 as soon as POODLE was announced.

 

 

Why should I not use SSL, specifically SSLv3?

Disable SSLv3 is a website that provides some great resources to answer that question.

 

 

What can I do if my device has only implemented SSL and not TLS and I don't have the ability to implement support for TLS?

We recognize that some lower powered or under-supported devices and libraries may simply not have the ability to perform - at minimum - TLS v1.0 yet. As such, we've created an alternative endpoint only for streaming data to Initial State at http://insecure-groker.initialstate.com.

This alternate endpoint allows users in this situation who also do not have a confidentiality requirement or have accepted the great risk of no-confidentiality to still stream data to our service. However, as soon as it's hit our first piece of networking equipment, it's kept safe and secure from then on.

There are no APIs whatsoever for accessing data over a connection that is not a minimum of TLS v1.0. We call the endpoint insecure because we want to ensure that everyone who uses it understand's that data sent to that endpoint over the Internet is sent in plaintext.  

 

 

Wouldn't SSLv3 be better than nothing?