User Tools

Site Tools


Privacy Policy for On-Premises & Web Services


Hey there!

Apologies for the inconvenience, we only have just the draft of a privacy policy but be assured it's already being enforced.

Here's the TLDR We don't care about your private data for better or worse .

However, We operate by a let's-not-be-dicks-to-eachother principle and in the hopes one day you grace us hosting our stuff, you respond in kind; so we will attempt to do the most in our power so this data is available only to you or to whom you chose to share it, if the service in question provides a way do to it. Furthermore, if on a pinch; we'll delete it rather than let it fall in third parties' hands.

Why is it “free” Our services are provided because hosting Microsoft Exchange Server for a handful of people is incredibly expensive and wasteful. On the other hand negligible to increase the number of accounts. Some things are wa

Exchange needs Active Directory which is a tree-like structured database for user accounts (regular databases use tables — rows, columns — not trees), also known as a Directory Service. Directory Services are the backbone of group computing, they're everywhere even in the computer right now if it's not an enterprise machine it's logged in to the local account, if it's a cellphone, the telephone number is structured like a tree, first it's the country code, then the area code, zone, “number”. In landlines when you're using an extension number, that service (the PBX) uses another directory service too, a lot of times their own, but the big ones can use Active Directory.

Active Directory cannot be “seen”. There's no page that would have the AD logo in it, yet it's used for everything because it authenticates user, service and machine accounts. In other words, when you enter a password in a somewhere (e.g; to unlock a domain-joined computer or in a website) it would connect to AD to authenticate you.

At the same time, user passwords are never saved in Active Directory. It stores a hash value of it: a fixed-length encryption of it very quick to calculate forward but nearly impossible to calculate in reverse which is why it's though as 1-way only. The only way to get your password would be to capture it in transit but the only way for somebody to do that would be by placing a proxy and getting you to trust its certificates as we offer no authenticated services over unencrypted connections.

Federation User accounts, if you didn't know, are usually stored in special databases called directory services then a directory server runs this. Perhaps you've heard of LDAP or Active Directory, these are directory services, Both of which we use. We have federated (linked) our directory service with Microsoft's Azure AD and Azure AD B2C at least five times before always looking for new features to try, during these occasions our user directory and hashed user passwords get automatically synchronized with Azure before we can opt out of it, but, we promptly deactivate it and opt for a federated authentication instead: this means that you might use the services we contract with Microsoft but to authenticate yourself you must do it with our local servers which do some voodoo with Microsoft's so they trust what the other say so our servers issue a ticket/token that serves to authenticate you with their servers but they don't get your password at all, Not even we can get it, it's hashed which basically mean it's encrypted one-way-only, when you enter your actual password during authentication it unlocks the saved hash, so to say. Perhaps you've seen this when sign in to some service using social network credentials, it's the same thing. It's commonly known as Single Sign-On referring to the fact not that you sign-in once, but actually in one service. What actually happens is that you sign in automatically multiple times through series of redirection from in your web browser that most of the time aren't even noticeable.

Regardless, we drilled down setting by setting to forbid Microsoft from gathering out and abusing our directory's data. They say phrase sentences to imply they respect it but let's be real, they always manage to be great assholes in the end. Without even getting to their own privacy policy which is extremely open ended, they already give themselves enough legal leeway to abuse you in any and every way the please, “ for the best experience.” As they frequently put it. They're not wrong either, they just fail the mention the “best experience” is not going to be yours.

In the past we've federated with Twitter, Facebook, Google, GitHub, AWS and other companies/services so it's easier for our users to log in. Since then we've stopped that and blocked most traffic to these networks too. We don't think it's worth it to renounce to your privacy for a quicker sign up. You'd still have to log in anyway. Instead we're focusing on strengthen things to allow secure, no-confirmation sign ups ether with an existing email account or an outbound-restricted account from our domain–we can't risk getting blacklisted on spam lists. The ideal solution would be implementing Open ID URI logins; unfortunately it didn't seem to catch on and some of the biggest adopters, like Stack Exchange Inc, have already removed support for it.

As for us, rest assured we have no intentions of monetizing nor making any sort of abuse with your personal data if you chose to share any–we don't need any. If we find ourselves in the condition where we were obligated to do such thing you will get a notice and, if we were to run out of time or get a sudden notice we will immediately erase your account and associated data in an effort to protect it, time permitting. Luckily, there's low chance of that occurring because the servers reside in a country were there aren't any invasive laws such as those in the US. While our front end server is located in the US, it's only a gateway, from there data is tunneled into our datacenter, no data is stored in the server located in the US. Your data in regards to other users and hackers

We can't control what you do, with whom you share data, or if you're mislead or tricked into giving away your information by another user hence we take no responsibility for it. Data transmission is encrypted and we use services from big name network providers such as Cloudflare for a bit of extra protection but we simply don't have the resources to take responsibility for your data. We can only promise we do our best but that's it. It is up to you to decide if you wish to continue using the services without warranty. To stress this point: if you continue connecting in any way to our servers you are agreeing that you won't take any action –legal or otherwise– if we failed to protect our systems and therefore your data.

The gist

Although that last bit sounds very menacing, in reality we would be flattered if you were to chose to continue and rest assured we'd do as much as we can to assist you recovering data or tracing back recent access to it if possible. For more about this we encourage you to take a look at our terms and conditions following by this hyperlink.

Hackers get such a bad rep anyway, the bad ones are mostly uninterested in small, unprofitable targets. The real bad actors nowadays on the Internet are corporations like carriers/ISPs, oppressive governments and developers of “free” and freemium apps. The first bunch can be dealt with by encrypting the data while it travels through the open Internet, as for the developers: do not download free apps and either free or paid apps with in-app purchases as you are giving it direct access to your data.

VitaNetworks has a somewhat large collection of apps you can use to access its services but these are only for convenience. No app is necessary to access our services. Certain services, VitaNetworks Cloudia's ability to sync data and location from a smartphone for example, are limited for your own viewing or use and no other user or administrator has access to this data unless you explicitly choose to share it.

This is were we stand. Any data pertaining a person, no matter if public or private shouldn't be collected without the person's consent even though if it is to improve a product “for the greater good”, specially a product from which enterprises monetize on.

Fuck data collection.


pol/start.txt · Last modified: 2022/06/10 09:50 by webmaster