AOO PRIVACY Violation (Our Best Security Practice/Policy)

[O0jl]

This all came about because I was getting "Bad Allocation" that seems to have no real solution at the moment. Indirectly my thinking summarized inputs I received to this problem into learning just a little more technical stuff about AOO than I really wanted to entertain in my daily use of this Office Suite. I went looking for the, "profile" that was supposed to be in options. I never did find it in the 4.1.5 copy of AOO I re-installed a day or so ago. I did find Auto Recovery timing. Okay that I am trying now.

I noticed Tools->Options-Load/Save->General and a checkBox to, "Always create a backup copy." Under "HELP" it says that a file is created with a .bak type/extension. Then there was silence about other things like was .odt/.ods kept? Also the information about where it was stored was deafeningly silent (in my reading). I need to know this information.

Now this is the goodPart and the badPart!

The badPart was it took a little time to locate the address in Windows 10 for the storage location, to wit: c:\users\name\AppData\Roaming\OpenOffice\4\user\backup\nnnn.bak

An excellent job at burying the badPart!

Strangely, the goodPart, the work-around-fix, came about as a result of the badPart that located hidden/buried files that should have been deleted/removed when the AOO writer/calc session was concluded. These went backwards in time from the present through 2014. What I found in multiple computers, that were using AOO, would make a dead security person roll over in their grave. A security audit person would have a hay day with the many, many, files found containing personnel, intellectual, financial and more in the hidden backup folder.

So, "Thank You" to those that got me poking around. This "find" was extremely annoying, since, for some unknown reason, we were never aware of these hidden files and we look - Guess our best security-practice policy is going to get a make-over ASAP!

The Windows 10 "fix" is a shortcut to the offending location and training-for-all using AOO to clear any files found at the conclusion of an Apache Open Office session with calc or writer. We are unable to give any input on the other features though we suspect that the malady is across all AOO features?

[robleyd]

There is a lot of information on the user profile in [Tutorial]The OpenOffice User Profile

Note that the backup location is shown in Tools | Options | OpenOffice | Paths and can be changed there to an alternate location. Any .bak files there are a result of turning on Always create a backup copy in Tools | Options | Load/save | General
From the Help accessed from that location:

Always create a backup copy
Saves the previous version of a document as a backup copy whenever you save a document. Every time OpenOffice creates a backup copy, the previous backup copy is replaced. The backup copy gets the extension .BAK.
To change the location of the backup copy, choose Tools - Options - OpenOffice - Paths, and then enter a new path for the backup file.

These are backup files, not recovery files. It would be counter productive to create a backup, then delete once you close the document you are working on. If you choose to create backup files, using this or any other means - such as the Timestamp backup extension - you also need to manage them.

[O0jl]

Thank you. Noted and Points taken. As you may have surmised, my read apparently did not glean all that I should have gotten! I think it could be said that it may be intuitively obvious once known! Poking around is doing some good (?) and your input is helping to reduce the time-to-learn what I did not need to know at some earlier time. Now, if the "bad allocation" would just go away I could go back to doing what I do and simply "lurk" for the sake of curiosity when needed. Lately, this "Ain't happening!" So much to focus upon; and, so little time to study the detail in my meager existence .. what a pity; but, workable most of the time!

Again, Thank You for your help!

[RoryOF]

In any event, backup files, even if deleted, may be undeleted by malign persons who have either physical or remote access to the computer in question. Access to the backup files, whether present or undeletable, has to be seen in the context of the overall security of the computer system in question.

[Hagar Delest]

Note that a lot of application (including your internet browser) store personal data in the Windows \AppData\Roaming\ profile, same for other operating systems.
Thus, a true security process is the encryption of the whole area where user data can be stored, that means of course the standard My documents folder but also the other folders with configuration files.

[floris v]

A little learning is a dangerous thing;
drink deep, or taste not the Pierian spring:
there shallow draughts intoxicate the brain,
and drinking largely sobers us again.

In the early days of the personal computer and word processors and spreadsheets it was taken for granted that people would take some sort of training before they would professionally use it. It's the responsibility of the user to know the software well enough to be able to prevent privacy issues and the like.
The backup feature was introduced for largely one reason: if you make complex changes to a document, for instance "replace all", and it turns out that your action has unwanted side effects, you want to be able to revert to a version just before that edit. It was added when Undo wasn't as advanced as it is today. Changing the extension to .bak is also a relic from that time, when the backup file was saved in the same folder, then called directory, where the original file was saved.
You really do need to learn the basics of file management, like the folder system, file name extensions and the like. When you turn on options like Make a backup file, you should be aware that the backup file has to be stored somewhere. All office software has such features, MS Office too.

[O0jl]

It is a lively bunch on this item. The business of file management is, as many imply, is like having the responsibility of herding cats. You give it your best shot and seek advice and guidance to be able to do a better job each day. Your input is appreciated.

The latest "Patch Tuesday" Feature Enhancements (?) of a day or so ago may have added a bit of surprise. It did for us. We no longer get "bad allocation!" There is no jitter in the mouse cursor. AOO v4.1.5 just silently and quicker-than-a-flash terminates. The recovery process was a little more strange than unusual. Of the Four (4) open files three (writer) activities went as seen before. The third (calc) claimed the file was missing for several tries and then did the recovery.

Now, there was advice received and comments made that were put to use. In summary: the auto-save time had been changed to eight minutes (now to five minutes) from the default of 15. The backup box as mentioned had been checked.

Having gotten and implemented suggestions, comments, and recommendations, my work was not lost which surprised me to no end! Thank you to those taking the time to share the tid-bits of insight.

I am still scratching my head about the quirky set of files that were put into the backup folder. I'm not complaining. I am curious about them, the ordering, the names and the content. I'll watch this. I found it is important to look through all. The .bak was not of any use since it was a mirror of the initial file though its date/time group suggested that it was being updated since it had the most current time. There were numerous files with the .odt (writer) type/entension. They had 01, 02, ...nn numbers in their name showing, I would think, some sort of sequence. Some had zero (0) content that were after the writer session began. Likewise the situation was true for higher sequence numbers closer to the time the writer/calc session abruptly ended. At the moment, rhume or reason escapes me for the population-of-the-file behavior.

Of the many, I found one in the middle that had my "STUFF!" I was a very happy camper.

I have to remember to save more and send a "hug" to whomever made this procedure/feature (since I am not really sure what and how it is doing this).

I'm all ears. If it will get AOO to work with the wounded W10, bring-it-on.

Tomorrow (my time) is a big office suite day of writer and calc. Pulling hair is not a possibility. I hope to have a smooth day?

BTW I think I noticed that the password protection is removed from the files in the backup folder. I think our solution of deleting everything in the backup folder at the end of an AOO session or at the end-of-the use of the particular computer is the best solution for us to minimize leakage.

Though it may have been thought that we do not manage files, to the contrary. AES-256, amoung other tools, are our best protectors from the inquisitive. Herding security issues that affect us is our bane to recon with as best as we can!

Documents was mentioned. I am checking the other locations in "paths." We force known, to us, output to private folders, like this time "stuff" escaped that should have been caught -- again, a thank you to whomever gave us guidance on this matter.

[YODA]

Did some of the files you found look like: .~locktheoldsalt.odt? The .lock files are supposed to prevent more than one user at a time working on the same file.

[O0jl]

I have seen the one you show and conclude it is a normal part of the process. The ones in the backup folder I am seeing are formatted: fileName_n.odt where 'n' is a sequence number. These files are mutually exclusive of the original and the one typed as .bak. They have varying DTG groups and files sizes. The sizes are not consistent with the DTG as I would think they should be (i.e., as time passes and the document grows or maybe disminishes the size should reflect the change). The size can be zero, larger, smaller, or equal to the previous or the next iteration without regard to the size of the current file (one being used). The fileName_n.odt can be opened (R/W) and are independent of the current file.

There is also another file associated with the current file that has the format: ~lock.fileName.odt_n.odt# whose purpose and use is unknown to me.

Wish I could have just said, "Yes" to your question. Now you get to join me in my quandry about the curious files in the backup folder (well, at least "here") AND maybe you or someone will have an answer/solution?

Thank you for being curious and trying to give aid!
Regards ...

[RoryOF]

The lock file indicates that the file is open for editing by the first user. If a subsequent user tries to edit that file, it is marked as read only and he cannot make changes to it. This is to prevent confusion if two users (in, say, a business environment) try to make simultaneous edits to the file.