Sec.0a--Intro to pervasive computing 8.ppt

1
© 2007 by Leszek T. Lilien
Based on: M. Satyanarayanan, “Pervasive Computing: Vision and Challenges,” IEEE Personal Communications, 2001
Pervasive Computing vs. Distributed Systems & Mobile Computing (50)
Drilling Down - The Difficult Problems (27)
 4.7) [LTL:] Proactivity and Its Transparency [Paper: Balancing Proactivity and Transparency] – cont.2
 [LTL:] Hypothesis: Talking about “balancing proactivity and
transparency” (see the paper) seems author’s mistake
 Balancing of X an Y is needed only when:
 More X can be obtained by reducing Y AND More Y can be obtained
by reducing X
 Here can have 100% proactivity with either 0% or 100%
transparency
 [LTL:] Finding (“balancing”) proper level of transparency for
proactivity
 If too little or too much of proactivity transparency annoys a user
 => The goal of proactivity transparency is defeated
 Need careful PERV design
 Finding the proper transparency level by:
 System’s self-tuning
 A mobile user’s need & tolerance for proactivity (UNTP) are likely
to be closely related to his level of expertise on a task & his
familiarity with his environment
 A system that can infer UNTP by observing user behavior &
context is better positioned to find the proper balance

2
 4.7) [LTL:] Proactivity and Its Transparency [Paper: Balancing Proactivity and Transparency] – cont3
 Historically, transparency (not just for proactivity) was the ideal
in system design
 E.g., caching is attractive in distributed file systems because it is
completely transparent
 Ironically, sometimes users are hurt/annoyed by complete
transparency
 E.g., servicing a cache miss on a large file over a low-bandwidth
wireless network — so slow that most users would rather be
asked first by the system if they really need the file
 However, too many questions from file system can annoy the user
That is, again annoyed by too low level of transparency
 A solution to this dilemma (suggested by Coda File System [21])
 On a cache miss, Coda consults an internally-maintained user
patience model to predict whether the user will not be
annoyed by a transparent fetch request
 If so, the fetch is handled transparently (user interaction is
suppressed)
 Many subtle problems arise in designing a system that walks
the fine line between annoying visibility & inscrutable (hard to
understand) transparency

3
 4.7. Balancing Transparency in Proactivity – some research
problems:
 How are individual user preferences and tolerances specified and
taken into account?
 Are these static or do they change dynamically?
 What cues can such a system use to determine if [LTL:] transparency
level is too low/high?
 Is explicit interaction with the user to obtain this information acceptable?
 Or, would such explicit interaction to obtain be an annoyance too?
 Can one provide systematic design guidelines to application designers
to help in this task?
 Can one retrofit [transparency] balancing mechanisms into existing
applications?

4
 4.8) Privacy and Trust
 Privacy is greatly complicated by PERV
 Was already a thorny problem in DISTR and MOBI
 Some PERV mechanisms “spy” on user actions on an
almost continuous basis
 E.g., location tracking, smart spaces, use of surrogates
 As a user becomes more dependent on PERV =>
PERV obtains more information about the user
 I.e., about user’s movements, behavior patterns, habit, …
 Exploiting this information is critical to successful
proactivity & self-tuning
 Unless use of information is strictly controlled, it can hurt the user
 Illegitimate uses ranging from targeted spam to blackmail.
 Potential for serious loss of privacy may deter knowledgeable
users from using a PERV system

5
 4.8) Privacy and Trust - cont.
 Mutual trust between infrastructure & users in PERV
 Greater reliance on infrastructure => users must trust
infrastructure to a considerable extent
 Conversely, the infrastructure needs to be confident of
the users’ identity and authorization levels before
responding to their requests
 It is a difficult challenge to establish this mutual trust with
minimal intrusiveness (= mimnimal visibility & thus maximum
transparency)
 System identifies/authorizes users in intrusive (visible)
way

6
 4.8. Privacy and Trust - cont
 Privacy and trust are likely to be enduring problems in
pervasive computing
 Privacy and trust – some research questions:
 How does one strike the right balance between seamless system
behavior and the need to alert users to potential loss of privacy?
 What are the mechanisms, techniques and design principles relevant
to this problem? How often should the system remind a user that his
actions are being recorded? When and how can a user turn off
monitoring in a smart space?
 What are the authentication techniques best suited to PERV?
 Are password-based challenge-response protocols such as Kerberos
[36] adequate or are more exotic techniques such as biometric
authentication [15] necessary?
 What role, if any, can smart cards [14] play?
 How does one express generic identities in access control?
 E.g., how does one express security constraints such as ‘‘Only the
person currently using the projector in this room can set its lighting
level?’’ Or: ‘‘Only employees of our partner companies can negotiate
QoS properties in this smart space?’’

7
 4.9) Impact on Layering [of the System]
 A recurring theme in this paper: the merging of
information from diverse layers of a PERV system to
produce an effective response
 E.g., Scenario 1 shows the value of combining low-level resource
information (network bandwidth) with high-level context
information (airport gate information)
 Proactivity and adaptation based on corrective actions =>
exposure of much more information across layers
 Much more than is typical in systems today
 We want layering – it has benefits
 Cleanly separates abstraction from implementation
 Thus consistent with sound software engineering
 Conducive to standardization
 Encourages the creation of modular software components

8
 4.9) Impact on Layering [of the System] – cont.
 Deciding how to decompose a complex system into layers
or modules is nontrivial
 Remains very much an art rather than a science
 The two most widely-used guidelines for layering
 Parnas’ principle of information hiding [26]
 Saltzer et al.’s end-to-end principle[28]
Both developed long before pervasive computing was
conceived
 Parnas’ - early 1970’s
 Saltzer et al.’s - early 1980’s

Sec.0a--Intro to pervasive computing 8.ppt

More Related Content

Similar to Sec.0a--Intro to pervasive computing 8.ppt (20)

More from ahmadfaisal744721 (14)

Recently uploaded (20)

Sec.0a--Intro to pervasive computing 8.ppt