1

Hello everyone!

First, I don’t kn ow if this thread really fits in this section of the community, if not, please feel free to warn me or a moderator to move it.

I’m new here, started playing with Spiceworks a month ago. I’m the “IT Manager” of a small Service Provider.

Our scenario: 35 customer(companies), from small business to medium sized. We also provide local support for two multinational companies.

We built a virtual environment to test Spiceworks, so far so good. I’m very satisfied with the change management we can do with it, thinking from a ITIL POV. The service desk management in general is very easy to operate, the multi site integration is the key feature for me.

Now comes the real question. I noticed some traffic from the Spiceworks servers that is not from it’s ports for operation. That raised some suspicious about what information are we really sharing about our customers. So I’ll leave some questions, please if there is a existing source of information just point me there.

1 - By using Spiceworks, which information are we sharing?

2 - Which information is collected?

6 Spice ups
2

start here…

what sort of traffic…

3

Basically you share very generalised summaries, but no specific data.

4

Thanks Martin2012!

So, the transmission is SSL protected, I hope with the hearthbleed fixed. Moving on…

That link don’t provide specifics about the information Spiceworks collect, it only specifies that “collects information about your environment” in general. Simple put, we don’t want information from our more than 1000 stations and 300 servers out in the air. Switches configurations and etc.

We have to provide various accounts, administrative ones, to populate the inventory. How secure is that information?

5

That is not shared at all.

It’s only a summary of your environment (how many HP switches, users, desktops etc) that is shared for marketing purposes.

1 Spice up
6

That info never leaves your local env, unless of course you have the send the DB to SPW if things go badly wrong.

7

For that part I would want to use an external DB on Spiceworks. But seems for no valid justification there is no support for external SGBDs, like MS SQL, MySQL or Oracle. For me is one the things holding the adoption of Spiceworks as our main management tool. As I said, we have more than 1000 stations, I read a lot of people reporting performance issues because of SQL Lite.

Would be better to specify that on the privacy declaration.

Martin2012 asked what type of traffic. Well, UDP transmissions on port 443, every time I run a scan. I believe is for data collection, that why I asked.

8

The app really isn’t made to handle more than 1,000 devices. You can keep adding and adding (I’ve seen some users with 5,000+ devices in their Inventory) but you’re going to see a big decrease in performance. We use SQLite for a number of reasons. Mainly, because it’s free, which means we can continue to give our software away for free too. :smiley:

Another big reason is that Spiceworks isn’t (I’m repeating myself, sorry) made for a large organization; its made for small to medium sized business who won’t need anything snappier than a SQLite engine. SQLite is much, much easier and faster to setup, which means our initial install/config to get the app running on your system stays minimal. This is very important in the eyes of the developers and the four dudes who founded the company.

As for what stuff leaves your network: nothing personal, and I promise you that. No passwords, no email addresses, no real names…nothing. Its like the other guys here said, its aggregate information about the kinds of devices that are on your network which is then used for marketing purposes. We aren’t the NSA. If we were, I wouldn’t work here.

1 Spice up
9

Oh, and also, WELCOME TO SPICEWORKS!

1 Spice up
10

Hi!

Sorry I have been busy lately.

Well, I know your target is companies around 500 stations. That’s not my point. My scenarios is comprised of 35 different infrastructures, with their own networks, servers, switches and all. We are a Service Provider. So, since no customer have more than 200 stations, performance will not be an issue for us, If understood right how the “Remote site” works.

About the database, the main reasons is your investment in changing Spiceworks to be compatible with other database engines. But I’d say is pretty standard in the world to develop a software at least supporting MS SQL Express, MS SQL and MySQL.

It is inevitable for Spiceworks to become a solutions available for big companies. You will have to implement support for other databases soon or later.

About cost, MS SQL Express is free and better to use and maintain than SQLLite, also this wouldn’t hurt the commercial partnership you must have with Microsoft.

As for what stuff leaves your network: nothing personal, and I promise you that. No passwords, no email addresses, no real names…nothing. Its like the other guys here said, its aggregate information about the kinds of devices that are on your network which is then used for marketing purposes. We aren’t the NSA. If we were, I wouldn’t work here.

Well, I suggest you specify that on the privacy declaration.

Even so, If I decided to not share our information automatically or not share at all, can we disable it?

11

This has been a recurring conversation for the last 5 years.

Even so, If I decided to not share our information automatically or not share at all, can we disable it?

Just block all outgoing traffic from that server to the big wide world.

1 Spice up
12

Just block all outgoing traffic from that server to the big wide world.

If I do that Spiceworks will stop working.

1 Spice up
13

Can you set it to only communicate with set IP addresses outside of your network?

That would also work I think (I’m not a network guru though)

1 Spice up
14

Setting the app so it is blocked from Internet traffic, or putting a policy in place that blocks it from connecting to our Community, technically violates the terms of service; so, please don’t do that.

We keep the lights on in this place by generating money from advertisement revenue. If we don’t show you ads on our website/in the app, we don’t generate revenue. If we don’t do that, we’d have to sell the app and then you’d be dealing with yet another company concerned about nothing more than how best to make money off of you guys. I don’t want that, and I’m pretty sure you don’t want that either.

The thing about Spiceworks being made to work on different versions of SQL is something that gets brought up all of the time. Its really not in our best interest to make the app run with a different database engine. What’s beneficial to some users does not necessarily make it beneficial to all users. To put it succinctly, our goal with this application is to make it run really great for most people that we’re trying to get to use it. I’m sure we could make it fly on MS SQL, or MySQL, but then we have to factor in licensing costs, additional support (we’re stretched thin as it is!) as we’d be on different versions of SQL at that point, and all sorts of other expenses that I can’t easily think of this early. It sounds like a cop-out, but it isn’t. If nothing else, just trust me on this; it wouldn’t be worth it in the long run.

15

You misunderstand me. I’m not at all against the advertising, as longs as it doesn’t bother the users on the help desk portal, you know, people find reasons for complaining in everything related to IT. Since we are third party, advertising showing to the users could even cause commercial problems.

My concern here is with the information contained in the database. The right of confidence between me and my customers. We deal with industry, with data related to products, research and the sort. Think about the effects of an administrative AD password leaking trough your database.

I know you stated more than once about the database being “password protected”, well, that’s different from encrypted.

Don’t take me personal, neither I’m trying to burn Spiceworks, I just want to clear some things before I adopt the solution here.

The thing about Spiceworks being made to work on different versions of SQL is something that gets brought up all of the time. Its really not in our best interest to make the app run with a different database engine. What’s beneficial to some users does not necessarily make it beneficial to all users. To put it succinctly, our goal with this application is to make it run really great for most people that we’re trying to get to use it. I’m sure we could make it fly on MS SQL, or MySQL, but then we have to factor in licensing costs, additional support (we’re stretched thin as it is!) as we’d be on different versions of SQL at that point, and all sorts of other expenses that I can’t easily think of this early. It sounds like a cop-out, but it isn’t. If nothing else, just trust me on this; it wouldn’t be worth it in the long run.

That’s why the DBMS choice should be left for the users(in this case us). You have 100 people in a room. 70 likes SQLLite, 30 wants a better DBMS because of necessity or because is their standard DBMS, both sides should have the option.
Also, for the frequency I found threads about this, 5 years of discussion is a hell of time to understand that this is necessary. If this is not a request from the majority of people, is requested from enough people. Just my POV anyway.
You could make MS SQL an standard option, at least would be better than just the SQLLite. What I get about this: You want to prevent people from seeing the database structure, tables, visions and etc. That’s also what raised my questions about what data is being sent from my database to you.

The fact that your terms of services requires me to share information, but no technical definition or specification on the data, that bugs me.

16

I’m not taking it personally, but if you block the Spiceworks application from communicating with our Community servers, it directly affects our bottom line: that is how we make money, which is how I get paid. You’re talking about how displaying ads in your Help Desk could affect you commercially. Well, to us, not showing those adds definitely affects us commercially; there’s really no argument here on this point. If you are interested in running Spiceworks in an ad-free environment, I would strongly recommend you take a look at MyWay .

And also, Spiceworks never has (and hopefully never will) display advertisements that could be visible to your end-users. You will only see ads when you log into the Spiceworks application; not by visiting the user portal to submit a ticket.

While the database itself isn’t encrypted, it is password-protected. However, all passwords in the DB do get encrypted, including your AD password. As for the security of your AD passwords, we think about this stuff daily. Which is exactly why it doesn’t leave your network: we don’t want it.

17

You will only see ads when you log into the Spiceworks application; not by visiting the user portal to submit a ticket.

That’s exactly what I said. We don’t have any problem at all with Advertising in our interface, but advertising to the end user portal could cause problems. I think we are clear and agreed on that.

Also, I never said anything about advertising, my concern is with data being sent to you. IF I can choose to share the data with you or not. If you want to show me banners of Dell, HP and etc, fine. What I asked is IF I can choose to not share information or at least control the flow and which information is shared.

While the database itself isn’t encrypted, it is password-protected. However, all passwords in the DB do get encrypted, including your AD password. As for the security of your AD passwords, we think about this stuff daily. Which is exactly why it doesn’t leave your network: we don’t want it.

Again, don’t take it personally. Think about my POV. I have to take your hand and accept your word on that, because I have no control over the information is sent to you.
The privacy declaration doesn’t state that, no technical information… If you collect hardware data, software data, licenses, switch model, software and firmware versions… you might say that information is harmless, it is not. It can be used for bad things in the wrong hands.