Pith. sign in

REVIEW 4 major objections 6 minor 71 references

Differentiated context-aware hook placement for different owners' smartphones

T0 review · 4 major / 6 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Prihook claims that personalized, context-aware privacy hooks in the Android Framework can be selected and placed automatically from a user's preference table, with no privacy violation found in tests on six typical preference tables.

desk verdict A clever engineering pipeline for personalized Android hook placement, but the 'no violation' claim rests on a narrow evaluation and an unproven coverage assumption. read the letter →

arxiv 1908.07679 v1 pith:GOA3WXGH submitted 2019-08-21 cs.SE

Tian Chen , Wang Ya Zhe , Liu Peng , Dai Rui Rui , Zhou An Yuan , Zhuo Xin Wang This is my paper · ORCID
classification cs.SE
keywords hookplacementAndroidFrameworkcontext-awareprivacyUserPreferenceTablePotentialMethodSetOperationAbstractLayersupportvectormachinesensor
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper sets out to make context-aware privacy enforcement on Android personal: instead of placing the same hooks for everyone, Prihook reads a user's privacy preferences and places hooks only on the Framework methods that matter for that user's rules. It claims this can be done automatically and at scale by learning a Potential Method Set of sensor-data access and control methods, then mapping simple words in a User Privacy Preference Table to those methods through an intermediate layer of abstract operations. On six representative preference tables, the authors report that their malicious test app could not obtain any disallowed sensor resource, and that each policy check costs less than two milliseconds. If right, the approach turns hook placement from a manual, expert task into a per-owner configuration step and avoids three recurring mistakes: hooks that can be bypassed, hooks that run inside an app's own process, and hooks that protect nothing.

What carries the argument

The load-bearing object is the three-layer mapping: User Privacy Preference Table words (resource plus control measure) to abstract operations in the Operation Abstract Layer, then abstract operations to methods in the Potential Method Set (SDAMs and SCMs). The Operation Abstract Layer is the semantic bridge that lets nonexpert users express concerns while letting engineers map those concerns to code. The Potential Method Set is itself produced by an SVM classifier over 143 semantic features (class, method, parameter, return type) applied to the Framework's Java and C++ services. Finally, a pick-and-remove step selects the deepest method for each abstract operation in each call chain, which is what keeps hook count low enough to avoid slowing apps.

What would settle it

Build a fully permissioned app that targets sensor sources outside the annotated training set, such as undocumented or newly added Framework methods that return sensor-derived data, and check whether any such method returns data without passing through a Prihook hook; finding one reachable method of this kind would refute the no-privacy-violation claim.

Watch

Extended reading notes

Core claim

The central claim is that personalized context-aware hook placement in the Android Framework can be fully automated. Prihook discovers a candidate set of sensitive methods with a machine-learning classifier, splits the gap between user words and Framework methods with an Operation Abstract Layer, and then for each call chain keeps only the deepest method performing a given abstract operation. Given a user's UPPT, it selects the matching methods, generates hooks from a template, and instruments the Framework. In evaluation, six differently filled UPPTs each produced a working instrumented image, and the authors found no privacy violation when a fully-permissioned malicious app tried SDK calls, reflection, and direct service communication.

Load-bearing premise

The load-bearing premise is that the Potential Method Set plus the preference-to-method mapping covers every path by which an app can obtain sensor data, since the classifier's recall is near 93 percent and the paper assumes missed methods are still called by discovered methods in the same call chain.

Editorial extensions

If this is right

  • Hooks are placed only where the individual user's rules require, so two owners with different UPPTs get different Framework images with different hook counts, from 19 to 92 in the reported UPPTs.
  • Because hooks sit at the deepest method for each abstract operation in each call chain, an app that reaches a sensitive resource through SDK calls, reflection, or direct service IPC still passes a hook before data is delivered.
  • The discovery pipeline can be rerun on a new Android version, and the classifier detects new and renamed SDAMs and SCMs (such as new scan variants) without manual re-inspection of the whole Framework.
  • A context check that returns DISALLOW or OBFUSCATE can be enforced at runtime, unlike the stock one-time permission grant, so a context change during a session can stop further data delivery.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The authors' own recall figures imply the Potential Method Set misses a small fraction of sensitive methods; their defense-in-depth argument is that missed methods are called by discovered methods in the same call chain, so a useful test would be to search specifically for chains where a missed method is reachable without any hooked ancestor.
  • A natural extension is to apply the same UPPT-to-method pipeline beyond sensors, to other privacy-relevant resources such as contacts or call logs, reusing the Operation Abstract Layer as long as the abstract operations can be named.
  • If the deepest-method rule is sound, then the hook count should scale with the number of distinct abstract operations a user's UPPT triggers, not with the number of Framework methods, which suggests the overhead grows with policy diversity rather than code-base size.
  • The portal-app interface could be validated by user studies comparing whether ordinary users can express their real concerns through the constrained UPPT lexicon; the current evaluation assumes the six volunteers' chosen words match their actual concerns.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper presents Prihook, an automated pipeline for placing context-aware privacy hooks in the Android Framework. It introduces a User Privacy Preference Table (UPPT) for users to express resource-context-policy concerns, an Operation Abstract Layer (OAL) to bridge the semantic gap between UPPT wording and framework methods, and a Potential Method Set (PMS) of Sensor Data Access Methods (SDAMs) and Sensor Control Methods (SCMs) discovered by SVM classification. Given a UPPT, Prihook maps words to abstract operations, selects specific SDAMs/SCMs from the PMS, keeps only the deepest method per abstract operation per call chain, and generates hooks automatically. The evaluation instruments six different UPPT-based system images, tests one malicious app using SDK APIs, reflection, and direct service communication, reports no privacy violation, and measures small runtime overhead. The paper also claims that this workflow avoids the bypass, no-isolation, and useless-hook mistakes found in prior work.

Significance. If the completeness and correctness claims were established, Prihook would be a useful contribution to personalized context-aware privacy enforcement on Android: it offers a clean abstraction (UPPT-OAL-PMS) for separating user-facing policy from framework internals, a concrete automation workflow, and a cross-version discovery method. The paper's strengths include its taxonomy of hook-placement mistakes, the use of a two-stage semantic mapping to avoid direct expert mapping, and an evaluation that covers three app-side attack strategies across six representative UPPTs. However, the evidence currently supports a promising prototype rather than a verified guarantee: the main claims of "no privacy violation" and correct selection of hook targets rely on unverified assumptions about PMS completeness and call-chain coverage.

major comments (4)
  1. [Section V-D and Section VI-D] The central correctness step is the construction of the hooked method set #FM, but the paper does not establish that #FM covers every app-reachable path to a protected sensor resource. In Section V-D, when two or more methods perform the same abstract operation in a call chain, Prihook keeps only the deepest method and removes the others; this is sound only if every path that reaches the abstract operation passes through the chosen deepest method. In Section VI-D, the SVM's false-negative method updateLinkProperties is dismissed because a discovered method addressUpdated in the same call chain is hooked, but that reasoning is an informal argument, not a systematic coverage guarantee. Since Table IV reports recall between 0.927 and 0.945, a meaningful fraction of SDAMs/SCMs may be missing from the PMS entirely; the statement in Section VI-B that no privacy violation was found does not resolve this, because the attack test does not enumerate unhooked paths. The paper should either prove the call-chain property under a stated threat model, replace the deepest-method rule with an explicit reachability analysis, or weaken the completeness claim.
  2. [Section VI-B] The privacy-protection evaluation uses a single self-built malicious app that obtains resources through three strategies: SDK APIs, Java reflection, and direct service communication. This is not a systematic enumeration of all entry points, Binder stubs, native/JNI paths, or methods missed by the SVM classifier. As a result, the reported outcome "no user privacy violation is found" is a property of the tested scenarios, not of the system in general. I recommend either adding a comprehensive reachability-based test that enumerates all framework paths from app-facing APIs to sensitive methods for the six UPPTs, or explicitly limiting the claim to the three tested strategies.
  3. [Section V-C and Section VI-D] The Layer 1 and Layer 2 mappings are load-bearing for selecting methods for a given UPPT, but their validity is established only through annotations made by the authors and recruited engineers. There is no inter-annotator agreement measure, no external ground truth, and no separate hold-out evaluation of the mapping; the statement that the OAL "reduces the chance of making mistakes" is not directly tested. Given that the same overall pipeline also produced the annotations used to test it, the paper should include a validation protocol with independent judges or a comparison against a hand-built gold-standard mapping for a subset of resources.
  4. [Section V-G and Section VI-D] The relationship between the classifier reported in the evaluation and the classifier actually used in the defense experiments is unclear. Section V-G says three students annotated 1000 training methods, while Section VI-D uses 5100 annotated methods for cross-validation; Section VI-D also says that "after adding some new features" Prihook would find updateLinkProperties, but it does not state whether the defense experiments used that later model or the earlier one. This ambiguity matters because recall of 0.927-0.945 is reported for the cross-validated classifier, and any improvement from new features should be reflected in the reported numbers or the evaluation should be repeated with the final model.
minor comments (6)
  1. [Throughout] The manuscript contains typographical errors such as "mehotds", "catogories", "non-trival", and "a acount"; the name "PriHook" is also used inconsistently with "Prihook".
  2. [Section V-G] The text states that the training set is "about 0.8%" of the test set, but the numbers given (1000 manually annotated methods and 384,296 total methods in Android 6.0) imply roughly 0.26%; please clarify the intended denominator.
  3. [Section VI-C] The text says MonkeyRunner was used to "download 150 user apps from the Android Market," but MonkeyRunner is a UI automation tool, not an app download service; please describe the actual app acquisition and installation process.
  4. [Appendix] Only two of the six UPPTs used in the evaluation are shown in the appendix; either include the remaining four or state why they are omitted.
  5. [Section VI-B] Figure 8 is referenced but its axes, legend, and scenario details are not described in the text, so the reader cannot determine what each panel represents.
  6. [Section V-B] The claim that the UPPT "can represent all policies in previous works on context-aware user privacy" is not substantiated; it should be supported by a table mapping each prior policy to a UPPT row, or the claim should be softened.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Prihook's hook placement pipeline is an empirical construction plus evaluation, not a derivation that reduces to its own inputs.

full rationale

The paper contains no formal derivation in which an output is defined in terms of the quantity it claims to predict. The Potential Method Set is generated by SVM classification of Android framework methods using hand-annotated training data, and the UPPT-to-method mapping is built by a manual engineer survey and a human-in-loop keyword iteration (Sections V-C and V-G); these are construction inputs, not fitted parameters that reappear unchanged as predictions. The 'no privacy violation' evaluation in Section VI-B tests the instrumented images with a purpose-built malicious app; while this does not prove completeness against all unexamined paths, it is an external behavioral test rather than a tautology, and the paper itself disclaims a guarantee that attackers cannot bypass hooks. No load-bearing self-citation or imported uniqueness theorem is present. The main weaknesses, such as SVM recall of 0.927-0.945 in Table IV and the informal assumption that hooking the deepest method in a call chain covers all entry points to an abstract operation, are correctness and coverage concerns rather than circularity.

Assumptions & free parameters 4 free parameters · 5 assumptions · 4 invented entities

The central claim rests on manually chosen thresholds, a hand-built semantic layer, and assumptions about Android code regularity and call-chain coverage. These are not derived from first principles or from external benchmarks, which limits the strength of the privacy guarantee.

free parameters (4)
  • Confidence threshold for Layer 1 mapping = 80 out of 100
    Section V-C: identifications are accepted only at confidence score 80 or higher; this hand-chosen threshold affects which operations map to each resource and control measure.
  • Agreement threshold for Layer 1 mapping = More than half of engineers
    Section V-C: a mapping is built only when more than half of the engineers agree; this design choice determines the UPPT-to-OAL mapping.
  • Number of abstract operations in OAL = About 70
    Section V-C: abstract operations were manually identified from Android Framework knowledge; their number and content determine the method buckets used for hook selection.
  • SVM feature set = 143 semantic features in 4 categories
    Section V-G: features were hand-selected; no independent feature-selection criterion or ablation is reported.
assumptions (5)
  • domain assumption Android Framework source code exhibits enough naming and structural regularity that SVM features generalize to unseen methods.
    Section V-G states that the framework 'follows a certain regular coding style' and contains redundancy, which is why machine learning can discover SDAMs and SCMs.
  • domain assumption The UPPT schema covers all relevant context-aware user privacy concerns.
    Section V-B derives the schema from prior privacy profiles but provides no guarantee for users whose concerns fall outside that summary.
  • domain assumption Hooking the deepest method for each abstract operation in a call chain is sufficient to block all sensitive accesses.
    Section V-D applies the pick-and-remove rule with no proof that every sensitive path passes through the deepest method.
  • ad hoc to paper Missed SDAMs and SCMs are called by discovered methods in the same call chain, so low recall does not cause leaks.
    Section VI-D justifies the leaked method updateLinkProperties by claiming addressUpdated, a discovered method, calls it. This is a specific mitigation not independently validated.
  • domain assumption A hook at the first line of a selected method can reliably attribute the call via Binder.getCallingPid and Binder.getCallingUid.
    Section V-E and V-F generate and place hooks without analyzing concurrency, Binder identity spoofing, or reentrant calls.
invented entities (4)
  • User Privacy Preference Table (UPPT)
    purpose: Provide a user-facing table for expressing context-aware privacy concerns in simple words.
    Internal interface design; the paper claims coverage based on prior profiles but provides no external validation with a broad user population.
  • Operation Abstract Layer (OAL) with abstract operations
    purpose: Serve as a semantic intermediate layer between UPPT words and Android Framework methods.
    The 70 abstract operations were manually identified by the authors and engineers, with no independent benchmark for completeness.
  • Potential Method Set (PMS)
    purpose: Candidate set of Sensor Data Access Methods and Sensor Control Methods from which hooks are selected.
    Produced by an SVM trained on student annotations; validated only through the paper's own cross-validation, not an external ground truth.
  • ContextAwarePolicyService
    purpose: New system service that checks policies and performs data obfuscation in generated hooks.
    Added to custom Android images by the authors; no independent deployment or formal verification is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Differentiated context-aware hook placement for different owners' smartphones." pith.science (2026). https://pith.science/paper/GOA3WXGH

@misc{pith2026190807679,
  author       = {Pith},
  title        = {Pith review of: Differentiated context-aware hook placement for different owners' smartphones},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GOA3WXGH}},
  note         = {Machine review of arXiv:1908.07679}
}
read the original abstract

A hook is a piece of code. It checks user privacy policy before some sensitive operations happen. We propose an automated solution named Prihook for hook placement in the Android Framework. Addressing specific context-aware user privacy concerns, the hook placement in Prihook is personalized. Specifically, we design User Privacy Preference Table (UPPT) to help a user express his privacy concerns. And we leverage machine learning to discover a Potential Method Set (consisting of Sensor Data Access Methods and Sensor Control Methods) from which we can select a particular subset to put hooks. We propose a mapping from words in the UPPT lexicon to methods in the Potential Method Set. With this mapping, Prihook is able to (a) select a specific set of methods; and (b) generate and place hooks automatically. We test Prihook separately on 6 typical UPPTs representing 6 kinds of resource-sensitive UPPTs, and no user privacy violation is found. The experimental results show that the hooks placed by PriHook have small runtime overhead.

Figures

Figures reproduced from arXiv: 1908.07679 by the authors.

Figure 1
Figure 1. Path-F is used by wifi, GPS. Path-N is used by [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Approach overview [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. All possible options currently implemented [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: A UPPT capturing a user’s privacy concerns [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: The overview of our mapping hardware or leads to a hardware action (e.g., camera focusing). We find that we are able to identify the abstract, high-level semantics of these sensitive operations. We call these high￾level semantics/words abstract operation. For example, …
Figure 7
Figure 7. Figure 7: A portion of keywords for abstract operations [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: The result of attacks on sensitive resources [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 9
Figure 9. Figure 9: The payment-sensitive UPPT filled by a high school [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]
Figure 10
Figure 10. Figure 10: The location&wifi-sensitive UPPT filled by a busi [PITH_FULL_IMAGE:figures/full_fig_p011_10.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

71 extracted references · 71 canonical work pages

  1. [1]

    Accesso ry: password inference using accelerometers on smartphones,

    E. Owusu, J. Han, S. Das, A. Perrig, and J. Zhang, “Accesso ry: password inference using accelerometers on smartphones,” in Proceedings of the Twelfth W orkshop on Mobile Computing Systems & Applications. ACM, 2012, p. 9

    work page 2012

  2. [2]

    Exploring sensor usage behav iors of android applications based on data flow analysis,

    X. Liu, J. Liu, and W. Wang, “Exploring sensor usage behav iors of android applications based on data flow analysis,” in Computing and Communications Conference (IPCCC), 2015 IEEE 34th Interna tional Performance. IEEE, 2015, pp. 1–8

    work page 2015

  3. [3]

    Gyrophone: Re cognizing speech from gyroscope signals

    Y . Michalevsky, D. Boneh, and G. Nakibly, “Gyrophone: Re cognizing speech from gyroscope signals.” in USENIX Security Symposium , 2014, pp. 1053–1067

    work page 2014

  4. [4]

    Inferri ng user routes and locations using zero-permission mobile sensors ,

    S. Narain, T. D. V o-Huu, K. Block, and G. Noubir, “Inferri ng user routes and locations using zero-permission mobile sensors ,” in 2016 IEEE Symposium on Security and Privacy (SP) . IEEE, 2016, pp. 397– 413

    work page 2016

  5. [5]

    Placeav- oider: Steering first-person cameras away from sensitive sp aces,

    R. Templeman, M. Korayem, D. J. Crandall, and A. Kapadia, “Placeav- oider: Steering first-person cameras away from sensitive sp aces,” in Network and Distributed System Security Symposium , 2014, pp. 23–26

    work page 2014

  6. [6]

    Smashed: Sniffin g and manipulating android sensor data,

    M. Mohamed, B. Shrestha, and N. Saxena, “Smashed: Sniffin g and manipulating android sensor data,” in Proceedings of the Sixth ACM Conference on Data and Application Security and Privacy . ACM, 2016, pp. 152–159

    work page 2016

  7. [7]

    When good bec omes evil: Keystroke inference with smartwatch,

    X. Liu, Z. Zhou, W. Diao, Z. Li, and K. Zhang, “When good bec omes evil: Keystroke inference with smartwatch,” in Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Secur ity. ACM, 2015, pp. 1273–1285

    work page 2015

  8. [8]

    Privacy risks emerging from the adoption of innocuous wearable sensors in the mobile environment,

    A. Ghosh, A. Ghosh, S. Kumar, and M. Srivastava, “Privacy risks emerging from the adoption of innocuous wearable sensors in the mobile environment,” in Sigchi Conference on Human Factors in Computing Systems, 2011

    work page 2011

Show all 71 references
  1. [9]

    Android permissions:user attention, comprehension, and behavior,

    A. P . Felt, E. Ha, S. Egelman, A. Haney, E. Chin, and D. Wagn er, “Android permissions:user attention, comprehension, and behavior,” in Eighth Symposium on Usable Privacy & Security , 2012

    2012

  2. [10]

    ipshield: A framework for enforcing cont ext-aware privacy,

    S. Chakraborty, C. Shen, K. R. Raghavan, Y . Shoukry, M. M illar, and M. B. Srivastava, “ipshield: A framework for enforcing cont ext-aware privacy,” in Proceedings of the 11th USENIX Symposium on Networked Systems Design and Implementation (NSDI 2014 , 2014, pp. 143–156

    2014

  3. [11]

    Smarper: Context-aware and automatic runtime- permissions for mobile devices,

    K. Olejnik, I. Dacosta, J. S. Machado, K. Huguenin, M. E. Khan, and J.- P . Hubaux, “Smarper: Context-aware and automatic runtime- permissions for mobile devices,” in 2017 IEEE Symposium on Security and Privacy (SP). IEEE, 2017, pp. 1058–1076

    2017

  4. [12]

    Crepe: Context -related policy enforcement for android,

    M. Conti, V . T. N. Nguyen, and B. Crispo, “Crepe: Context -related policy enforcement for android,” in International Conference on Infor- mation Security . Springer, 2010, pp. 331–345

    2010

  5. [13]

    Semadroid: A privacy-aware sensor man agement framework for smartphones,

    Z. Xu and S. Zhu, “Semadroid: A privacy-aware sensor man agement framework for smartphones,” in Proceedings of the 5th ACM Conference on Data and Application Security and Privacy . ACM, 2015, pp. 61–72

    2015

  6. [14]

    Viola: Trustworthy s ensor no- tifications for enhanced privacy on mobile systems,

    S. Mirzamohammadi and A. A. Sani, “Viola: Trustworthy s ensor no- tifications for enhanced privacy on mobile systems,” in International Conference on Mobile Systems, Applications, and Services , 2016, pp. 263–276

    2016

  7. [15]

    Aurasium: practical policy enfo rcement for android applications,

    R. Xu and R. Anderson, “Aurasium: practical policy enfo rcement for android applications,” in Usenix Conference on Security Symposium , 2012, pp. 27–27

    2012

  8. [16]

    What is app ops,

    J. Levi, “What is app ops,” https://pocketnow.com/app \discretionary{-}{}{} ops

  9. [17]

    Protect my privacy,

    SynergyLabs, “Protect my privacy,” https://repo.xposed.info/module/org.synergylabs.pmpandroid

  10. [18]

    Security enhanced (se) androi d: Bringing flexible mac to android

    S. Smalley and R. Craig, “Security enhanced (se) androi d: Bringing flexible mac to android.” in Network and Distributed System Security Symposium, vol. 310, 2013, pp. 20–38

    2013

  11. [19]

    Integrating flexible suppo rt for security policies into the linux operating system,

    P . Loscocco and S. Smalley, “Integrating flexible suppo rt for security policies into the linux operating system,” in Freenix Track: 2001 Usenix Technical Conference, June 25-30, 2001, Boston, Massachus etts, Usa , 2001, pp. 29–42

    2001

  12. [20]

    World- driven access control for continuous sensing,

    F. Roesner, D. Molnar, A. Moshchuk, T. Kohno, and H. J. Wa ng, “World- driven access control for continuous sensing,” in Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Secur ity. ACM, 2014, pp. 1169–1181

    2014

  13. [21]

    Audroid: Preventing attacks on audio channels in mobile devices,

    G. Petracca, Y . Sun, T. Jaeger, and A. Atamli, “Audroid: Preventing attacks on audio channels in mobile devices,” in Computer Security Applications Conference, 2015, pp. 181–190

    2015

  14. [22]

    rovo89, “Xposed,” https://github.com/rovo89/Xpose d

  15. [23]

    How can i update my phone?

    HUAWEI, “How can i update my phone?” https://consumer.huawei.com/cn/support/update/

  16. [24]

    Keep your mobile up-to-date, safely and quic kly,

    SAMSUNG, “Keep your mobile up-to-date, safely and quic kly,” https://www.samsung.com/africa en/support/fota/

  17. [25]

    Regulating arm trustzone devices in restricted s paces,

    F. Brasser, D. Kim, C. Liebchen, V . Ganapathy, L. Iftode , and A.-R. Sadeghi, “Regulating arm trustzone devices in restricted s paces,” in Proceedings of the 14th Annual International Conference on Mobile Systems, Applications, and Services . ACM, 2016, pp. 413–425

    2016

  18. [26]

    Reconciling mobile app pri vacy and usability on smartphones: Could user privacy profiles help?

    B. Liu, J. Lin, and N. Sadeh, “Reconciling mobile app pri vacy and usability on smartphones: Could user privacy profiles help? ” in Proceed- ings of the 23rd international conference on W orld wide web . ACM, 2014, pp. 201–212

    2014

  19. [27]

    Modeling users m obile app privacy preferences: Restoring usability in a sea of permis sion settings,

    J. Lin, B. Liu, N. Sadeh, and J. I. Hong, “Modeling users m obile app privacy preferences: Restoring usability in a sea of permis sion settings,” 2014

    2014

  20. [28]

    I’ve got 99 proble ms, but vibra- tion ain’t one: a survey of smartphone users’ concerns,

    A. P . Felt, S. Egelman, and D. Wagner, “I’ve got 99 proble ms, but vibra- tion ain’t one: a survey of smartphone users’ concerns,” in Proceedings of the second ACM workshop on Security and privacy in smartph ones and mobile devices . ACM, 2012, pp. 33–44

    2012

  21. [29]

    A survey of mobile phone sensing,

    N. D. Lane, E. Miluzzo, H. Lu, D. Peebles, T. Choudhury, a nd A. T. Campbell, “A survey of mobile phone sensing,” IEEE Communications magazine, vol. 48, no. 9, 2010

    2010

  22. [30]

    A survey of computational location privacy,

    J. Krumm, “A survey of computational location privacy, ” Personal & Ubiquitous Computing , vol. 13, no. 6, pp. 391–399, 2009

    2009

  23. [31]

    Location disclosure to social relations:why , when, & what people want to share,

    S. Consolvo, I. E. Smith, T. Matthews, A. Lamarca, J. Tab ert, and P . Powledge, “Location disclosure to social relations:why , when, & what people want to share,” in Conference on Human Factors in Computing Systems, 2005

    2005

  24. [32]

    Anonymizing user location and profile information for privacy-aware mobile services,

    M. Mano and Y . Ishikawa, “Anonymizing user location and profile information for privacy-aware mobile services,” in Acm Sigspatial In- ternational W orkshop on Location Based Social Networks , 2010

    2010

  25. [33]

    Grlach, A

    A. Grlach, A. Heinemann, and W. W. Terpstra, Survey on Location Privacy in Pervasive Computing , 2005

    2005

  26. [34]

    User needs for location-aware mobile ser vices,

    E. Kaasinen, “User needs for location-aware mobile ser vices,” Personal & Ubiquitous Computing , vol. 7, no. 1, pp. 70–79, 2003

    2003

  27. [35]

    Privacy in locat ion-aware computing environments,

    D. Anthony, T. Henderson, and D. Kotz, “Privacy in locat ion-aware computing environments,” IEEE Pervasive Computing, vol. 6, no. 4, pp. 64–72, 2007

    2007

  28. [36]

    Mix zones: User privacy in location- aware services,

    A. R. Beresford and F. Stajano, “Mix zones: User privacy in location- aware services,” in Pervasive Computing and Communications W ork- shops, 2004. Proceedings of the Second IEEE Conference on , 2004, pp. 127–131

    2004

  29. [37]

    Realms and states:a framework for loc ation aware mobile computing,

    A. K. Narayanan, “Realms and states:a framework for loc ation aware mobile computing,” in International W orkshop on Mobile Commerce , 2001

    2001

  30. [38]

    Myexperience:a system for in situ tracing and capturing of user feedback on mobile phones,

    J. Froehlich, M. Y . Chen, S. Consolvo, B. Harrison, and J . A. Landay, “Myexperience:a system for in situ tracing and capturing of user feedback on mobile phones,” in International Conference on Mobile Systems, 2007

    2007

  31. [39]

    Pers onalized location based services with respect to privacy:a user oriented appr oach,

    C. Patrikakis, A. V oulodimos, and G. Giannoulis, “Pers onalized location based services with respect to privacy:a user oriented appr oach,” in International Conference on Pervasive Technologies Relat ed to Assistive Environments, 2009

    2009

  32. [40]

    Y . A. Ridhawi, I. A. Ridhawi, L. Bruno, and A. Karmouch, Policy-Based Personalized Context Dissemination for Location-Aware Se rvices, 2010

    2010

  33. [41]

    Preserving location privacy by distinguishi ng between public and private spaces,

    J. Wood, “Preserving location privacy by distinguishi ng between public and private spaces,” in Acm Conference on Ubiquitous Computing , 2012

    2012

  34. [42]

    Preserving privacy in environments with location-based applications,

    G. Myles, A. Friday, and N. Davies, “Preserving privacy in environments with location-based applications,” Pervasive Computing IEEE , vol. 2, no. 1, pp. 56–64, 2003

    2003

  35. [43]

    Privacy in location-aware systems,

    J. C. Freytag, “Privacy in location-aware systems,” Sigspatial Special , vol. 1, no. 2, pp. 4–8, 2009

    2009

  36. [44]

    Privacy issues in location- aware browsing,

    M. L. Damiani and P . Perri, “Privacy issues in location- aware browsing,” in ACM Sigspatial International W orkshop on Security and Priv acy in Gis and Lbs, Springl 2010, November 2, 2010, San Jose, Califo rnia, Usa, Proceedings, 2010, pp. 60–64

    2010

  37. [45]

    Privacy-aware mobile locatio n-based sys- tems,

    L. Stenneth and P . S. Y u, “Privacy-aware mobile locatio n-based sys- tems,” pp. 79–88, 2011

    2011

  38. [46]

    Jano:speci fication and enforcement of location privacy in mobile and pervasive env ironments,

    R. C. Jos Simo, C. Ribeiro, and P . Ferreira, “Jano:speci fication and enforcement of location privacy in mobile and pervasive env ironments,” in International W orkshop on Middleware for Pervasive Mobile & Embedded Computing , 2010

    2010

  39. [47]

    Exploring end use r preferences for location obfuscation, location-based services, and th e value of location,

    A. J. B. Brush, J. Krumm, and J. Scott, “Exploring end use r preferences for location obfuscation, location-based services, and th e value of location,” Proceedings of Ubicomp , pp. 95–104, 2010

    2010

  40. [48]

    Taintdroid: an information flow tracking sy stem for real-time privacy monitoring on smartphones,

    W. Enck, P . Gilbert, B. G. Chun, L. P . Cox, J. Jung, P . Mcda niel, and A. N. Sheth, “Taintdroid: an information flow tracking sy stem for real-time privacy monitoring on smartphones,” in Usenix Conference on Operating Systems Design & Implementation , 2015, pp. 393–407

    2015

  41. [49]

    Taintart: A practical multi- level information- flow tracking system for android runtime,

    M. Sun, T. Wei, and J. Lui, “Taintart: A practical multi- level information- flow tracking system for android runtime,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Secur ity. ACM, 2016, pp. 331–342

    2016

  42. [50]

    On tracking info rmation flows through jni in android applications,

    C. Qian, X. Luo, Y . Shao, and A. T. Chan, “On tracking info rmation flows through jni in android applications,” in 2014 44th Annual IEEE/I- FIP International Conference on Dependable Systems and Net works (DSN). IEEE, 2014, pp. 180–191

    2014

  43. [51]

    Bitblaze : A new approach to computer security via binary analysis,

    D. Song, D. Brumley, H. Yin, J. Caballero, I. Jager, M. G. Kang, Z. Liang, J. Newsome, P . Poosankam, and P . Saxena, “Bitblaze : A new approach to computer security via binary analysis,” in International Conference on Information Systems Security , 2008, pp. 1–25

    2008

  44. [52]

    Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint ana lysis for android apps,

    S. Arzt, S. Rasthofer, C. Fritz, E. Bodden, A. Bartel, J. Klein, Y . Le Traon, D. Octeau, and P . McDaniel, “Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint ana lysis for android apps,” Acm Sigplan Notices , vol. 49, no. 6, pp. 259–269, 2014

    2014

  45. [53]

    Precise interproced ural dataflow analysis with applications to constant propagation,

    M. Sagiv, T. Reps, and S. Horwitz, “Precise interproced ural dataflow analysis with applications to constant propagation,” Theoretical Com- puter Science , vol. 167, no. 1-2, pp. 131–170, 1996

    1996

  46. [54]

    Practical ex tensions to the ifds algorithm,

    N. A. Naeem, O. Lhot´ ak, and J. Rodriguez, “Practical ex tensions to the ifds algorithm,” in International Conference on Compiler Construction . Springer, 2010, pp. 124–144

    2010

  47. [55]

    Third-party library security management for mo bile applica- tions,

    W. Hu, “Third-party library security management for mo bile applica- tions,” Ph.D. dissertation, Pennsylvania State Universit y, 2016

    2016

  48. [56]

    Estimating continuous distr ibutions in bayesian classifiers,

    G. H. John and P . Langley, “Estimating continuous distr ibutions in bayesian classifiers,” pp. 338–345, 2013

    2013

  49. [57]

    C4.5: programs for machine learning,

    J. R. Quinlan, “C4.5: programs for machine learning,” v ol. 1, 1992

    1992

  50. [58]

    Combining labeled and unlabel ed data with co-training,

    A. Blum and T. Mitchell, “Combining labeled and unlabel ed data with co-training,” in Conference on Computational Learning Theory , 1998, pp. 92–100

    1998

  51. [59]

    Xgboost documentation,

    XGBoost, “Xgboost documentation,” https://xgboost.readthedocs.io/en/latest/

  52. [60]

    Pscout: anal yzing the android permission specification,

    K. W. Y . Au, Y . F. Zhou, Z. Huang, and D. Lie, “Pscout: anal yzing the android permission specification,” in Proceedings of the 2012 ACM conference on Computer and communications security . ACM, 2012, pp. 217–228

    2012

  53. [61]

    Unsafe exposure analysis of mobile in-app advertisements,

    M. C. Grace, W. Zhou, X. Jiang, and A. R. Sadeghi, “Unsafe exposure analysis of mobile in-app advertisements,” in ACM Conference on Security and Privacy in Wireless and Mobile Networks , 2012, pp. 101– 112

    2012

  54. [62]

    Adsplit: separatin g smartphone advertising from applications,

    S. Shekhar, M. Dietz, and S. W. Dan, “Adsplit: separatin g smartphone advertising from applications,” in Usenix Conference on Security Sym- posium, 2012, pp. 28–28

    2012

  55. [63]

    Curbing androi d permission creep,

    T. Vidas, N. Christin, and L. F. Cranor, “Curbing androi d permission creep,” W2sp, 2011

    2011

  56. [64]

    On demystifying the android application fr amework: Re- visiting android permission specification analysis

    M. Backes, S. Bugiel, E. Derr, P . D. McDaniel, D. Octeau, and S. Weisgerber, “On demystifying the android application fr amework: Re- visiting android permission specification analysis.” in USENIX Security Symposium, 2016, pp. 1101–1118

    2016

  57. [65]

    Kratos : Discovering inconsistent security policy enforcement in t he android framework,

    Y . Shao, J. Ott, Q. A. Chen, Z. Qian, and Z. M. Mao, “Kratos : Discovering inconsistent security policy enforcement in t he android framework,” in Proc. 23rd Annual Network and Distributed System Security Symposium (NDSS16). ISOC , 2016

    2016

  58. [66]

    Effective inter-component communication mapping in android with epicc: an essential step towards holistic security ana lysis,

    D. Octeau, P . Mcdaniel, S. Jha, A. Bartel, E. Bodden, J. K lein, and Y . L. Traon, “Effective inter-component communication mapping in android with epicc: an essential step towards holistic security ana lysis,” in Usenix Conference on Security , 2013, pp. 543–558

    2013

  59. [67]

    Andro idleaks: auto- matically detecting potential privacy leaks in android app lications on a large scale,

    C. Gibler, J. Crussell, J. Erickson, and H. Chen, “Andro idleaks: auto- matically detecting potential privacy leaks in android app lications on a large scale,” in International Conference on Trust and Trustworthy Computing. Springer, 2012, pp. 291–307

    2012

  60. [68]

    Information flow analysis of android applications in droidsafe

    M. I. Gordon, D. Kim, J. H. Perkins, L. Gilham, N. Nguyen, and M. C. Rinard, “Information flow analysis of android applications in droidsafe.” in Network and Distributed System Security Symposium . Citeseer, 2015

    2015

  61. [69]

    Information flows as a permis sion mechanism,

    F. Shen, N. Vishnubhotla, C. Todarka, M. Arora, B. Dhand apani, E. J. Lehner, S. Y . Ko, and L. Ziarek, “Information flows as a permis sion mechanism,” 2014, pp. 515–526

    2014

  62. [70]

    Automatic placeme nt of authoriza- tion hooks in the linux security modules framework,

    V . Ganapathy, T. Jaeger, and S. Jha, “Automatic placeme nt of authoriza- tion hooks in the linux security modules framework,” in Proceedings of the 12th ACM conference on Computer and communications secu rity. ACM, 2005, pp. 330–339

    2005

  63. [71]

    Leverag ing choice to automate authorization hook placement,

    D. Muthukumaran, T. Jaeger, and V . Ganapathy, “Leverag ing choice to automate authorization hook placement,” in Proceedings of the 2012 ACM conference on Computer and communications security . ACM, 2012, pp. 145–156

    2012

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.