7 Replies
      Latest reply on Feb 7, 2019 2:26 PM by cwoolf
      dmaclach Level 1 Level 1 (0 points)

        If I have a string in an os_signpost_* call that is not marked public such as:

         

        os_signpost_interval_begin(log, my_id, "name", "myName: %s", myName);

         

        what is actually able to see that? It appears to be showing up visible in Instruments just fine without any special effort on my part. The documentation I can find on os_signpost (and os_log for that matter) is incredibly vague about exactly how privacy works, and especially for doing instruments you often need configurable strings.

        • Re: Privacy in os_signpost logs
          cwoolf Apple Staff Apple Staff (50 points)

          I believe string constants are allowed to pass through.  Is "myName" ultimately pointing at a string constant?

            • Re: Privacy in os_signpost logs
              dmaclach Level 1 Level 1 (0 points)

              hmmm... in this case "myName" is actually class_getName([self class]);

                • Re: Privacy in os_signpost logs
                  cwoolf Apple Staff Apple Staff (50 points)

                  Seems like that could be encoded in a constant string section of the binary.  Generally speaking, logging does its best to log as much information as possible, but will stop short if there is a risk of leaking personal information.  Numbers are generally safe, and I think string constants are, but strings on the heap are not.  If you have a string that you know doesn't leak personal information, then you should as a habbit mark it as public.

                    • Re: Privacy in os_signpost logs
                      dmaclach Level 1 Level 1 (0 points)

                      Interestingly if I mark the string as "private" (%{private}s) it still shows up in instruments. What actually controls whether or not private strings are emitted?

                       

                      I want developers to be able to see these strings, but I really don't want people to be able to log them when we release our app. In C/C++ I could possible define them out with the preprocessor (although I hate doing this), but I really don't have a great solution for our swift code.

                        • Re: Privacy in os_signpost logs
                          cwoolf Apple Staff Apple Staff (50 points)

                          Thanks for the heart attack   I had to go back and recheck everything to make sure we didn't drop the ball.

                           

                          So yes, Instruments is allowed to record all private data if that private data comes out of a debuggable process.  If you can attach a debugger to it, then private data is fair game.  Applications that are distributed through the App Store are signed in a way that prevents the recording of private data, period.  That means it can't be seen by anyone, including Instruments.  In Instruments, you'll see "n/a" in places where the private data should be in the metadata string for logs and signposts.

                            • Re: Privacy in os_signpost logs
                              dmaclach Level 1 Level 1 (0 points)

                              Thank you! Really appreciate it. Just to clarify again, when you say "Applications that are distributed through the App Store" do you mean both iOS and macOS?

                                • Re: Privacy in os_signpost logs
                                  cwoolf Apple Staff Apple Staff (50 points)

                                  Correct.  Correct'ish.  It's complicated...

                                   

                                  For sure, when you ship an application on iOS's App Store, it will be "restricted" which means you can't attach a debugger to it.  When Xcode builds and deploys an app for debugging or profiling on your test device, it will silently slip a debugging entitlement on it that allows debuggers or Instruments to attach.  You might have noticed.

                                   

                                  I say it's complicated because I personally don't know how formal the Mac App Store has become these days.  They get closer and closer to the security model of iOS, but I don't know if they will outright reject apps that are not explicitly restricted.  Also, whether or not SIP is enabled on that system will change what you can and cannot do with apps that are not explicitly restricted, but not explicitly debuggable.

                                   

                                  The safest bet would be explicitly restrict your apps going to the Mac App Store rather than relying on the review process to catch it.