I would like to update my app to support the downloading of PDF documents, but am worried primarily about 2 things:
1: that the user will attempt to use my app to download non-PDF, or virus-riddled items.
2: that said virus riddled-items could infect the device.
I may just be paranoid, as I assume the sandbox would prevent most malware from escaping and screwing with the OS, Kernel or the Lower Level Processes but you can never be too sure. So my question is twofold: How can I (at least mostly) guarantee the download of only PDF's and do it as securely as possible.
(P.S. the download will be done through any generic website in a webView, not a server seeing as I shudder at the thought of web development).
Based on ozdrgnaDiies' answer, I have found this sample code; which I will be modifying to suit my needs, thank you. http://iphoneincubator.com/blog/server-communication/how-to-download-a-file-only-if-it-has-been-updated
From what I've gathered from your question, I assume you want to check if the file you are downloading is a pdf and not anything else? If so, you could check the header of the file to verify it is a pdf.
Example, the first thing in every .pdf (That I have myself) is:
%PDF-*.*
Where *.* is a version(?) number. For example, 1.2, 1.3, 1.5, etc.
Therefore, reading the first 5 characters from a downloaded pdf should result in "%PDF-", otherwise it is not a pdf.
As more examples, the first thing in a jpeg image is:
ﾘ・
And for an .exe it's:
MZ・
etc
iOS apps are sandboxed. Meaning, anything you do within the app should only affect your app. Unless you attempt to somehow run the downloaded content (which I believe is against the rules for the App Store). The only thing left would be maliciously crafted PDFs…
I personally don't think it would be a big issue.
Related
Note: Before asking i searched some on embedding but couldn't get exactly what i wanted.
I have a resume file in the pdf format that i would like to display in my website without storing anywhere like google or other but on my own. I have static website [which i made using Jekyll] lets say https://www.example.com and what i actually need is to display my resume accessible in the following link https://www.example.com/resume
Some of them have long permalinks and i actually hate them. (Just saying)
Upload the PDF into the website's / or assets/ directory.
To make a link for HTML:
CV
To make a link for Markdown:
[CV](<PATH>/cv.pdf)
On Chrome, this has been around for a long time and plagues webdevs to this day. There seem to be no plans to change that anytime soon because that's just the way it was built. Chrome behaves slightly different when not online, so offline/local-testing will not always produce expected result.
My answer to you, for this question, is a suggestion. In order to make it cross-browser compatible, your mode of implementation should be:
Modal or,
Lightbox
Whether or not you are using a SSG should not matter here. Look for a bootstrap or material implementation.
On the client-side, it is possible with extension. I reckon this isn't helpful to you; but I'm including this information for future readers.
I have an app in which the app bundle contains an image file (I mean that the file is dragged into XCode and appears in "Other Sources"), and I am using code like:
[[NSBundle mainBundle] pathForResource:#"Auto" ofType:#"jpg"]
to get a path to the image.
I found that when running on a device (iPod Touch), the name is case-sensitive, so that if the file is "Auto" and I use "AUTO", the poath returned is "file://(null)". However on the simulator, if I use "AUTO", it works the same as if I use "Auto".
I am thinking that the fact that the simulator has such a clear difference in behavior from the device is a bug. Do the more experienced users out there think that it is, and that I should report it to Apple?
Thanks.
The iOS-Filesystem is case-sensitive, whereas the OSX-Filesystem the Simulator uses isn't.
You have to be very careful with this, I've shot myself in the foot with this more than once.
This has more to do with NS/CFBundle itself than it does with the underlying file-system:
Directly from Bundle Programming Guide: The Bundle Search Pattern:
Important: The bundle interfaces consider case when searching for resource files in the bundle directory. This case-sensitive search occurs even on file systems (such as HFS+) that are not case sensitive when it comes to file names.
You should always, always be assuming case-sensitivity. Well, perhaps a better way to express that is to say, never assume Case-insensitive-while-case-preserving (which is what HFS+ is). In the not-so-distant future, case-sensitive HFS+ could become the default format for Mac OS X. (In general, it would be preferred over the current case-preserving HFS+, but if Apple were to switch it now, there would likely be hundreds of thousands of apps that would break because of developers who made assumptions they shouldn't have. The iPhone is a clear example of the preference for case-sensitive HFS+. With no legacy programs to worry about, the iPhone has always been case-sensitive).
You are editing your code and resource names right now, so take the time to assure they match.
I am thinking that the fact that the simulator has such a clear difference in behavior from the device is a bug.
In general, this does not necessarily indicate a bug.
Do the more experienced users out there think that it is, and that I should report it to Apple?
Yes. But the bug has nothing to do with the device at all. Specifically, the bug is simply "Simulator file paths are not case-sensitive". If you can reproduce this in a "sandbox" project, do so, and submit it along with your bug report.
This is a multi-part question to SO folks before I engage more with core team.
Summary: On OS X, pdfs should be created using quartz, not postscript. Files are smaller, anti-aliased better, OS fonts including opentype are readily available, encoding is less painful, overall I think it’s a better device. On other platforms, it would be reasonable to use cairo, again a more modern pdf-writing device.
Consider the behavior of the png() device. Although it is allegedly slated to move out of x11.R, it handles c("cairo", "Xlib", "quartz") with a default (options("bitmapType")) set by zzz.R (quartz if capabilities("aqua"), cairo if available, Xlib otherwise). PDF needs to behave the same way, so that in Sweave (or babel or whatever) my pdf figures can be generated using the appropriate device.
My Sweave png patch works because png() takes care of getting the device option. An earlier version of the patch (which I still use) flips the device in Sweave, but I was smacked down for this and I know it’s sort of the wrong the place to do it.
There’s some alias cairo_pdf() (also in x11.R) that probably should not be there, shouldn’t that be merged into a device-switching pdf() ?
One approach is to add option "pdfType", which in turn I think should probably be more general – there is already a default device, it’s just that pdf() ignores it! I’m especially wary of introducing new global options because they are more likely to be rejected by core.
I don't think you'd need to implement a device driver. Mostly it sounds like you want to alias pdf() so that it calls quartz() or cairo() as appropriate. The quartz() device already supports PDF output to a file (among others) on OS X.
For your own personal use (I doubt this would find its way into core) you could just alias pdf() to take the appropriate action on each of your platforms and bring it in as a package or in your Rprofile.
pdf.orig = pdf
pdf = function(...) {
// Insert code here
}
Cloud App has this neat feature wherein it automatically uploads new screenshots as they are added to the Desktop. Any ideas how this is done?
You can do similar things yourself without much in the way of programming. In OSX, you can configure "Folder Actions" to run a script, for example, when a new item appears in a folder, including the Desktop. You can then use the script to do whatever you want with the new files.
This article at TUAW includes an example of uploading files to a web server when they hit a particular folder.
So, basically, the answer is "Folder Actions", or "something's keeping an eye on the folder and sending notifications", at some level. Whether Cloud App uses Folder Actions or watches the folder itself at a lower level, using FSEvents/NSWorkspace, or the kqueue mechanisms (for which there's a nice wrapper class called UKKQueue, if I remember correctly -- don't know how current my knowledge is on that one though!) is another matter...
You could implement this at several different levels, depending on the outcome you want, how you want to design whatever it is you're actually doing, and even what kind of filesystem you're targeting. Fundamentally, in Cocoa/Objective C, I think you probably want to start looking at FSEvents.
Once you've got notifications of the file changes, I'd probably use something like ConnectionKit to do the uploading -- any library at all, really, that means you don't have to bother with the sockets level yourself -- but again, there's a lot of different ways.
Depends, really, what level you're looking to solve the problem at, and whether you want to build something for other people or get something working for yourself. If I just wanted to bash something together for myself, I could probably have something cobbled together using Coda's Transmit app, and Folder Actions, or maybe Hazel, and a minimal bit of Applescript, in a half-hour at most, that would do the job well enough for me...
I am not sure what you are asking for exactly. If you are asking for a way to take a screenshot programmatically in MacOSX, I suggest you have a look at the "screencapture" command (in the terminal, type "man screencapture" for doc).
If you want to do it the "hard" way, you should look at this.
I have a shell script stored in the resources folder of my Cocoa app. If used improperly it could be dangerous (even though I have taken precautions to reduce exploits, such as using the absolute path to commands) so is there any way to encrypt the script in binary format, then decrypt it when it needs to be used?
Thanks
It seems as if your concern is about people getting write access to the script and modifying it to run arbitrary code. You could keep a checksum for the script in the binary and compare that with the checksum of the script before you run it. Now, how do you stop people from editing the binary too? Code signing. In fact, if you keep the shell script in the app bundle then editing the script will break the signature of the bundle anyway.
This does not make a lot of sense. If an attacker has access to edit this script file, then they likely have access to edit any number of files, your application is less likely to be a security risk than any number of other things would be attacker could do.
No. If the user will decrypt it to use it, then she can see (and intercept) the clear text at some point. If you think you have "shell-like" things to do, do them in C/ObjC... This can be your friend.
What you're asking for is essentially DRM. A different purpose (“security” instead of thwarting copyright infringement), but the same approach, with the same problems.
In order for the user to be able to normally use the (music|video|script), they must be able to decrypt it. You would do this for them under only the right conditions in your (player|app), but that doesn't matter: no matter how well you hide it, you still have to provide the user with all the technology and keys necessary to decrypt the (music|video|script), so that your (player|app) can do that.
And then, since the user has all the technology and keys necessary to decrypt it, an attacker can and eventually will uncover them all and decrypt the (music|video|script) on their own.
I second Massa's suggestion of switching away from a shell script. This doesn't completely eliminate risk: If an attacker can gain access to write to your shell script, they can gain access to write to a Mach-O executable just as easily. But editing a Mach-O executable is not nearly as easy, so you are at least raising the bar that way.