Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm working on a piece of software that creates a contract and captures the client's signature via gif and applies it to the contract (and spits out a pdf). Now, we're storing the data from the contract but when it comes to the signature, I'm not sure if I should.
Store it:
Pros: If the pdf document is lost, I can reconstruct the document instantly and easily for whomever needs it (us or client). (checked with the lawyers, reconstructing the document from data is legal and applicable as long as no data is or has changed)
Cons: Although I will never do anything with the stored signature, I can't be certain that, if I ever leave the company, my coworkers or replacements will honor that.
Don't Store it:
Pros: Ethical high ground, there's no option for anyone now or in the future to use that image and do anything with it. It keeps everyone honest.
Cons: Now there is no way to reconstruct the original document if the pdf is lost - which is a good possibility.
Talk to a lawyer.
If it's grey enough an area, I'd vote for don't-store-it.
Lawyers are the most important people to talk to in this case.
But I'd still say don't store it.
If necessary, I'd suggest storing the contract in a format from which you CANNOT extract the original GIF. Such as taking a png file for the whole document, or some other solution.
However, if you are storing the whole document with the signature embedded (and not extractable) then you have your ability to resend the signature, and you have no reason to store the unattached GIFs.
Ultimately, having the unattached GIFs is just providing an enormous opening to getting sued.
Storing them that way also opens you up to problems relating to 'pasting the wrong GIF' into a contract.
I would say that having the gif files in a way that does not EXPLICITLY bind them to the ONE contract they apply to is VERY dangerous.
EDIT
After reading your post again I would say that there isn't a point in storing the GIFs or the PDFs. You should have a hard copy somewhere of the signed document (and if you are losing hard copies of contracts, then there are SERIOUS organizational issues) and after that, you don't need the signed version anymore, you just need to know the terms of the contract. So as long as you can reconstruct the terms for reading over, then I don't see why you'd need the literal signature again. If you need to prove they signed it, go back to the hard copy.
Do you need to keep the signature for anything else? If not I'd store it only for as long as is required to produce the PDF, as there is no reason to keep it around.
In New Zealand the collection of personal data is governed by the Privacy Act and as such one of its requirements is the data is only stored for the length of time required for the reason the data was collected.
The signature can still be extracted from the PDF. So whether you store the original GIF does not seem to make a difference, security wise.
How about this for thought:
If it was an electronic signature, you would probably not be able/allowed to store it at all. You could store the signature+document (i.e. the crypto-signed hash of the initial document) and verify it with the public key, but to store a lot of client's private keys to be able to re-sign documents.
Imagine some one breaking in to the database and stealing those private keys (gifs or RSA/DSA keys). That store would be very useful/profitable to a criminal organization.
Do you want to expose yourself to that?
I don't know, a GIF can be re-created by anybody with a copy of the document and a scanner...not storing you lose the benefit of having it, without any real security value being added....
I would get legal advice on some text to place near the signature in the final document. Maybe something like:
John Hancock http://rightzinger.com/LibraryofProgress/FoundingFathers/John_Hancock_signature.gif
(electronically added signature)
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I understand Keychain is designed for saving Passwords, InternetPasswords, cryptographic keys, etc. However, why not just save small encodable models as well?
For example, an encodable and decodable structure that holds about 100 properties of user sensitive preferences.
I tried this and it worked pretty well. Although, there is not much concrete information available and I want to understand if there are any downsides to doing this.
Nothing actually prevents you from doing it, as the encoded data model will be in the form of Data/NSData. There may be a pair of points to keep in mind before going in that direction:
there’s an actual size limit per
single keychain item ( which I personally could not find officially stated, but I remember that writing a keychain item which data size was greater than about 2 MB, led to a keychain write error ). That means you should be careful on how big the data model is ( for example using short CodingKeys instead of the actual property names, would use less bytes in the resulting data block to be written )
keychain data does not get deleted when the user deletes the app. Whether this will stay like this forever or not I can’t tell, but is a fact as per now, and this means you may need to put a logic in your app to make sure that another installation on top of the previous one may not use the old/dirty data as unnecessary
I don’t discourage you from using the keychain for that, but in case, there are alternative approaches, like storing an encryption key on the keychain and using it to encrypt/decrypt your actual data models and write them securely in your app document folder. You can combine this with extra steps like NSFileProtectionComplete setting, make the encryption key in the keychain accessible only if the device is actually protected by passcode, and maybe, if you plan to store quite a lot of data, combine encryption and CoreData together.
Hope it helps
I am making a few apps that all require pre-set data to be loaded into the app. This data does not need to be changed or altered in any way as the app progresses - it is simply the data that the app runs on (to give more detail, it is questions for a quiz app). I have elected to use .txt files to store this data, but I wanted to know if this is the best way to do this? Text files allow me to easily change the data without coding. I can also copy and paste from normal documents. Is storing data in this way a good practice, or should I try to hard-code the data/ use a p-list?
The answer to this question depends a lot on how you want to implement your code.
.TXT files might work well, but what happens to the memory requirements when you pass a certain number of questions (e.g. more than 100, or even 10?). Also, what kind of structure are you using in memory to hold the question? If it's a NSDictionary or NSArray, perhaps a .plist file might work better for you.
Raw NSData, or some proprietary format, might work best if you have a lot of non-modifiable questions and you want to try to compress the data down as much as possible (which is a consideration on the low memory / low disk space iPhones).
CoreData might come in handy if you want to store a lot of questions and answers, especially those that users are manually entering in or managing.
For something like this, I will typically use JSON files, and then use Apple's JSON parsing framework.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am wondering if it is possible to make a completely new format. Mac use a .text file for text and .mov for movies so is it possible to make a new format that i can put into a iOS application that it will use off and export off, for example the application pages exports a .pages file, and if so what is a good tutorial site or script that u can use.
A few thoughts:
File extensions
If this is just a file that your app uses internally, it doesn't matter too much what extension you use. Use whatever you want.
If you're going to be sharing files, however, you should ensure that you pick an extension that you're confident is unique. For example, it looks like RCB extension is used by Easy Resume Creator Pro (I don't know it, but that's what a quick google of that extension reports).
How to do it.
I'd simply advise you refer to How to Import and Export App Data on Ray Wenderlich's site, which describes how you can define a UTI for your app's data files. Also refer to this Stack Overflow answer.
How to store the information.
In terms of how to store the data in the file, you can obviously do whatever you want, but I'd encourage you to consider, if dealing with text data, using an established format (even if you're using your own custom extension). For example, if dealing with simple Cocoa objects like arrays or dictionaries of strings, numbers, dates, etc., I might suggest using a property lists (see Apple's Property List Programming Guide which writes data in an XML format.
Alternatively, if using your own NSObject subclasses, you can use a binary property list format as enabled by NSKeyedArchiver and NSKeyedUnarchiver which are discussed in Apple's Archives and Serializations Programming Guide.
There are lots of other formats that are open to you, but these two approaches take advantage of well established interfaces for reading and writing data and can be done with a minimum of effort
Alternatives to new file format.
Depending upon precisely what you're trying to do, if you're exchanging trivial amounts of information, a custom URL scheme might be sufficient. This bypasses the issue of dealing with custom file formats and enables a few other workflows.
Hopefully this is enough to let you start researching the different alternatives.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have an app that showcases paintings, the number of paintings is about 600 ( so thats 600 png's ). The client wants me to include those images in the app build, so that they are always available to view even if the user if not online. Of course with every image comes some fields like description, painter, and price estimate, so this app will not stream anything and will have all of its data locally.
Anyway I am thinking of the best way to build this app, I thought of core data, and even encoding decoding, but since These images wil never change, I can put them in an images folder and on viewdidload just loop over contents of the folder and build my tableviewcells.
my question is :
1 : Is this a good architecture?
2 : I need to associate those images with the relevant description of them? whats the best way of doing this? If I jump into core data and create models I feel this would be an overkill.
Keep in mind that these images will never change, nor will the data be updated.
Thanks.
A couple of thoughts:
As discussed in your other question, I think that loading all of these images in the app has its disadvantages, given that you say that the app ends up being 300mb. If it is, indeed, going to be larger than 50mb, then I think you might want try to dissuade your customer from insisting that all of the images be included in the app, itself. I understand that you might not be able to convince them, but at least make sure they understand the implication of including all of these images (that it makes it harder to install the app and therefore, they may experience a lower adoption rate of their new app).
Storing the relevant description of the images in Core Data is a good approach. You could also use SQLite (e.g., via the FMDB wrapper), but I'd really encourage you to just use Core Data unless you have some other considerations you haven't shared with us. But a lot of other traditional solutions for simplified persistent data (plists, NSUserDefaults, etc.) might not be appropriate for this many records. Core Data is great and really isn't that complicated. Sure, the first time you use Core Data, it takes a little getting used to, but it seems well suited for this amount of data.
You talk about "encoding and decoding" of the images, and you haven't described anything that would lead us to suggest that sort of process. What encoding/decoding are you contemplating? It's probably easier to just store the images in the local file system (in the bundle if included in the app, elsewhere in the file system if you're downloading the images on the fly).
You mention that you might have "viewDidLoad just loop over contents of the folder and build my tableviewcells". Perhaps I'm reading too much into this (in conjunction with your other question's comments about receiving memory warnings), but given that you are talking about keeping the images descriptions in Core Data, you don't need to be iterating through anything in viewDidLoad. Your UITableViewDataSource methods will simply query the Core Data database and present the appropriate information. I don't see any need to be iterating through anything in viewDidLoad.
I did a similar kind of application some time ago. I used unique code names for the images and created a Core Data DB that would have one column associating the according line of data (description, author, ...) with the "code" name of the image (i.e., 2347.png).
My model was something simple like this:
NSNumber *imageCode // the number that you would use to associate to your images
NSString *name
NSString *author
NSString *description
I'm assuming that you know how to use Core Data.. if you don't, you can refer to this website: Core Data on iOS 5 Tutorial: Getting Started .. it is really helpful!
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
Some software has the option to collect anonymous usage data. How does that work? How is it collected and sent? I'd like to write a small test to try this myself, but I'm not sure where to begin.
Collecting data: You can accumulate whatever data you want to accumulate. For example, we wanted to know what forms our users were using (we have a lot of forms). So, in every form's FormCreate, we call code that appends Self.Name to a text file. Now we are tracking form creations, and the order in which our users visit the forms.
You could collect any data you wanted. For example, if you wanted to know how many times a user got a certain error message, whenever you show the error message, append the name of the error message to a file. If you wanted to know how long a user spent on a certain screen, you could note Now() when the form is opened and Now() when the form is closed and then write the difference to a data file.
Sending the data: You need to transfer either the raw data you collected to your server or you need to pre-process that data and send that. In our example above, we would just send the text file. You can use any internet library of your choice to upload a file to your server. We use Indy FTP, since it comes with Delphi. Upload the file, giving it a unique name (maybe a GUID if your server accepts that format?) to your server. (Choosing a good file name that hasn't already been uploaded to the server by another user's application is one of the challenges you'll have.) Be sure that you don't include anything in the file or file name that could be used to identify the user unless you've gotten permission to do so & understand any legal ramifications. Decide you want to upload the file maybe once a week, or once a day at a random time so all users aren't uploading at the same time. Of course you might want to pre-process the file before uploading it, collapsing the data in some way to make the file smaller.
Be sure your data collection file doesn't grow too big. You probably should delete it after uploading it. Also, if the upload file is big, it will cause a noticeable delay and freeze in your application unless you take steps to upload in the background, etc.
Note that if your users have very strict firewalls or security software, sending a file like this might be prohibited and could even cause your software to be flagged as malware. You'll need to carefully consider this issue and evaluate the various ways that data can be sent over the web in a way that is safe, unobtrusive and ANONYMOUS, and allowed by various security applications. For example, you will need to understand whatever protocol you use to upload and how much information that it might provide your server about the identify (like IP address, which might be vaguely personal with the right tools or search warrant.)
Then, at your server, over weeks (or whatever time frame you choose to upload files) you will have a lot of files that your software uploaded from users' machines. These files contain the names of the forms your users loaded, or the names of the error messages they got, or elapsed times, or whatever data you collected and uploaded. You would then decide how to process that data into a meaningful reports. Examining all the files, you might learn something like: 50% of our users never opened form X. Or: most users never saw error message #17 or only got error message #22 on form TForm3, or users spent an average of 45 seconds with Form4 visible.
I've simplified almost everything above. There are of course, for example, much better ways to save the collected data than appending to a text file. A text file might grow too big and too slow. There might be legal or ethical issues you'll need to consider.
But this is the general idea.
This is not a casual project to put into an application that others will use unless you fully understand all the issues and design and code it well. (That, I suppose, can be said about any coding!) But, as I noted, above I've written an overview of how you might do it for, say, an homework assignment or to just explore.)