Practical Data Security, Data Leaks, Linux Desktop Touchscreen Calibration

Post date: Sep 25, 2016 3:22:24 PM

• Laughed at 'practical data security procedures' which are actually being followed. Bunch of laptops bought from on-line bankruptcy auction contained everything, absolutely everything from the previous business it had been used at. I got work applications, contract of employment data, so much email I didn't bother to go through it. Sales and purchase orders, salary information. Employee identity data and stuff like that. All the usual 'business data'. I didn't even bother to run forensics tools because all this data was directly available. - So this is the business as usual. Everything leaks out just as it is. When someone says that can't happen. That happens all the time and continuously. What's there's to wonder about it or why to deny it? Because they already leaked everything to 'unauthorized' part, I could have just created one big torrent about that and released it for fun. They leaked the data, I just made it 'bit more available'. Or maybe something that I could explain as mistake, install web server which shared root path publicly and Google can then come and index everything. It's not malice, it's just incompetence. I wanted to see how web server works. I wonder what they would have thought about that. I haven't signed any NDA about that data, so it's not protected by any agreement. The purchase from on-line auction didn't say anything about using or protecting any potentially passed data. Well, I actually wiped the drives and removed the data. But this should work just as a reminder, that you'll never know what happens if you do stupid things like that. Business was bankrupted anyway, but what about all the employee data, vendor contracts etc 3rd party data which could have been exposed in the process. Usually when I talk about stuff like above, people just laugh. They think it's some kind of NSA, CIA or secret agent hacker movie stuff. It's so ridiculous to talk about data security, nobody actually cares about that. - Or maybe the audience isn't just the right one? - Try talking about Olympic athlete nutrition in local alcoholism as a way of life bar.
• This is one of the great cultural examples I've talked earlier. Is the problem that there are constant data leaks, or is the problem the person who raises an alarm about data leaks and says that these should be obviously blocked. Which one is the real problem? In many organizations it seems that the problem is the talk about the problem. The data leak issue can be largely ignored, until something really massive blows up. So it doesn't matter. And following proper data security procedures would just add more expensive work and non productive overhead. It's wonderful how often people believe that 'having password' or 'deleting files' will secure data in some way. This seems to be pretty common misunderstanding even with professionals.
• Stuff above just made me kind of laugh, all that high tech data security marketing stuff and then there's the actual reality. Just like being said about cloud services. You'll never know where your data will end up, nor you can ever delete it. Only way to make the process bit harder, is proper pre-cloud encryption, which basically means that they're now able to do anything with the data even if it leaks.
• Got bunch of old Atom silent computers, which could be used as Linux servers / desktops for small loads / random use. It's interesting to notice that those computers with 4 GB ram and Atom CPU are clearly slower with 64 bit version than 32 bit version. I guess that's also complex question, but in this case, it was very visible difference, not just a few percents, but like tens of percents. Didn't time it. But lag was very clearly noticeable with GUI.
• Ubuntu touchscreen calibration, It just worked beautifully. Really nice! Worked like a charm. Just put the xinput calibration commands in .profile . There was also a secondary trap, the device name contained unicode (tm) which is bit hard to deliver on command line. And the xinput_calibration uses device names by default. This was easily fixed by using device XID instead of it's name. After that everything was working perfectly!
  • sudo apt-get install xinput-calibrator x
  • input_calibrator --output-type xinput