4 ms·
I feel if you are taking any personal information, including an email address, you should have some kind of terms of service. If you set cookies on a personal c
by mattbgates 9y ago
I feel if you are taking any personal information, including an email address, you should have some kind of terms of service. If you set cookies on a personal computer, that could warrant a terms of service.
You can find Terms of Service generators online and you just modify it to be even more simple terms. If I were a large corporation, like Apple, I'd probably have lawyers writing it for me, but I do my best not to store too much personal data, while informing my users of the data collected from them. And if I do store it, its encrypted. I can't read it or recover it.
It is good practice to spend a few hours, at least once before you develop a good program, to check out the terms of services on a bunch of websites. It helps to understand the types of language to use and what to mention or not mention, especially those websites closely related to whatever you are doing.
My personal opinion is that the shorter your privacy policy and terms of service, the better. No reason to put up content that you can't even understand, so you may as well write something that you and your visitors can easily understand.
Terms of Service: information about the usage of your product.
Privacy: information about your considerations when collecting and storing data from your visitors.
- ge96 9y agoThanks a lot that is really helpful. Interesting point about the encryption. Do you think IP's need to be encrypted? I sometimes get IPV6's but mostly IPV4. We don't collect/ask for emails yet at this point... pretty much just using IP (not even sure why we collect it) and generate a 12-char unique string set to cookie for analytics upload/lookup. I will have to take a look at some generators. edit: wait that part about encryption, if I can't read it, what use is it? You're talking same thing with passwords like don't store it as plaint text, store the hash? If that's the case yeah... but then the cost server-side to decrypt/run batch processing... I guess part of the job...
- mattbgates 9y agoIt is just common practice for me to encrypt most data that goes into the database. First and foremost, for security. Privacy is important too. And also, encrypting data actually saves more bytes, as the encryption method I use outputs a pattern of random characters. While it can be long at times, it tends to eliminate special characters, periods, spaces, etc. So I'd think the database is more optimized by practicing data encryption. Also, if you think about all the major companies that have gotten hacked in the past, with sensitive data leaks, you have to wonder how that data was able to get breached and then deciphered. At least if that happens to you, you can at least make it harder for the hacker. And people know about these data breaches.. yet it doesn't stop them from using those products, but that is because those companies are huge. A small business cannot afford to have a data breach and expect its reputation to remain stable. Edit: The thing about data encryption is that for some methods, you can encrypt two strings so they end up being the exact same thing when encrypted. Then you compare that data for a match or an unmatch. It is just a more secure way of doing things. It is up to you on how you want to store your data. Databases do come with some protection themselves, but encrypting data is just one additional step for security.
- ge96 9y agoWhat about performing operations on that encrypted data though? Is it still "indexable" Not disagreeing with you. Encryption is something I have to learn/get into I think I was looking at AES256, I mean I use the standard bcrypt with openssl for password/login.