• 河北南和县:芒种时节农事忙 2020-01-18
  • 老外假装施工事故整蛊路人,一个个真吓得不轻(上) 2020-01-18
  • 习近平为传统文化“代言” 2020-01-18
  • 迎泽大街下穿火车站通道顶进过半 2020-01-18
  • 游客被指捡石子砸老虎 北京野生动物园:正在核实 2020-01-17
  • 戏曲进校园 宣传十九大又传承民族文化 2020-01-17
  • 《人民日报》创刊70周年 各界人士送祝福 2020-01-15
  • “暗剑”无人机相关新闻 2020-01-15
  • 习近平:在深入推动长江经济带发展座谈会上的讲话 2020-01-12
  • 打造科技创新领域的竞争优势 2020-01-12
  • 读书、看展成潮流 山城端午文化热 2020-01-08
  • 重庆市公安局交通管理局互联网交通安全服务管理平台 2020-01-08
  • 《鬼神童子》漫画家黑岩善宏因心肌梗塞于本月8日去世 2020-01-08
  • 第八届全国税收宣传漫画大赛评选结果揭晓 2020-01-07
  • 习近平会见美国国务卿蓬佩奥 2020-01-03
  • 白小姐特码信封料

    2013年香港特码生肖表:Next steps on trust and permissions for Web applications

    3–4 September 2014, Paris, France

    Host

    W3C gratefully acknowledges Gemalto, for hosting this meeting.

    Gemalto

    HTMl5Apps Thanks also to support from the European Union through the Seventh Framework Programme (FP7/2013-2015) under grant agreement n° 611327 - HTML5 Apps.

    Meeting Essentials

    The meeting took place as planned and the minutes are now available. These include plans for future work.

    Hashtag
    #webpermission
    What
    This meeting is an initiative of the System Applications Working Group, whose charter expires 1 October 2014. The goal of the meeting is to discuss next steps for work on standards for trust and permissions, based upon insights gained from experience with native app platforms, hybrid and proprietary web platforms.
    Who
    • This meeting is open to participants of the Systems Applications Working Group and guests from a small number of other W3C Working Groups, invited on behalf of the System Applications Working Group Chairs
    • Due to space limitations, attendance is limited to 1 person per organization.
    • If you are interested in attending the meeting, please email Dave Raggett by 1 August 2014.
    When
    3-4 September 2014
    09:00-18:00 each day
    Where

    6 rue de la Verrerie
    CS 20001
    92197 Meudon sur Seine
    FRANCE

    See also google maps for walking routes.

    Getting to Gemalto

    The best means of getting to Gemalto depends on where you're coming from. You can plan your journey with www.transilien.com. Here are some options:

    Meudon-sur-Seine and Brimborion (Zone 3) are nearby tram stops on Tram line T2 and within easy walking distance. This line runs between Porte de Versaille and La Défense.

    Slightly further away, but still walkable, is Gare de Meudon which can be reached from Paris Montparnasse via the SNCF Transilien line N. Note that Meudon is in Zone 3, when it comes to purchasing a ticket.

    Another option from central Paris is to take RER line C to either Issy (Zone 2) or Gare de Meudon Val Fleury (Zone 3), and then get a taxi to Gemalto.

    Triadvisor provides some helpful info on zones and fares.

    Attendees

    The following people have indicated their intention to attend the meeting:

    • Dave Raggett, W3C
    • Dom, W3C (remote)
    • Robin Berjon, W3C (webapps etc.)
    • Wendy Seltzer, W3C (security, privacy) 2nd day only
    • Mike O'Neill, Technical Director, Baycloud Systems, Oxford Centre for Innovation
    • Daniel Appelquist, Telefonica (remote)
    • Stefan H?kansson, Ericsson (Co-chair Media Capture TF, WebRTC)
    • Philipp Hoschka, W3C
    • Giridhar Mandyam, Qualcomm
    • Claes Nilsson, Sony Mobile
    • Wonsuk Lee, Samsung
    • Vadim Draluk, GM (automotive)
    • Adrienne Porter Felt, Google
    • Jonathan Jeon, ETRI
    • Steven Woolcock, Apple
    • John Hazen, Microsoft
    • Stephanie Ouillon, Mozilla
    • Woosung Kim, LGE (remote)
    • Kenneth Rohde Christiansen, Intel
    • Olivier Potonniee, Gemalto
    • Renato Iannella, Semantic Identity (remote)

    Note that Dom, Daniel, Woosung and Renato expect to attend remotely.

    Remote Participation

    Olivier Potonniee has booked a for remote participants. People can either connect through Lync (by clicking link above) if they have this software installed (Silverlight 4.0), or by a simple phone call, using the closest phone number. The Conference ID is: 77634672.

    Agenda

    This is not a meeting about the current work of the Systems Applications Working Group, but rather a 2-day discussion about next steps in this space, in light of the fact that the group's charter expires 1 October 2014. This two-day meeting will review the limitations of existing standards, and discuss insights gained from experience with native app platforms, hybrid and proprietary web platforms.

    As the Open Web Platform expands, new capabilities are likely to require new ways of managing permissions. Some platforms, e.g. Android, ask users upfront for permission when an app is installed or first run, whereas others like iOS ask users for permission when the application is attempting to use a given capability. Rather than asking the user for permission in advance, another approach is to invite the user to continue or to cancel an action after it has occurred, i.e. asking for forgiveness rather than permission -- this is the approach taken in the Fullscreen API, see the explanation by Chris Pearce. In some cases, the user's actions can be taken as implicitly granting permission, for a detailed analysis of this approach, see Roesner et al. A further approach is for users to delegate decisions on permissions to a trusted 3rd party (if it's okay by them, it's okay by me). What is needed to arrive at a consensus for a cross vendor solution?

    Here is a draft agenda that we can tweak as needed at the start of the meeting:

    1. Introductions
    2. Logistics and agenda tweaking
    3. Review of existing practices for the Open Web Platform (OWP)
    4. Review of approaches used by other platforms (web and native)
    5. What lessons come out of academic studies, e.g. Porter Felt, et al. and Roesener et al.
    6. Discussion of what considerations are important for the OWP
    7. A detailed look at some proposals
    8. Plans for future work - e.g. chartering a CG, Cross WG Task Force, ...

    Some further reading:

    Note: this is just a sample, and not intended to be authoratative.

    Sample discussion topics

    Group 1: User Consent

    • What criteria are there for choosing between asking users upfront for permissions, asking at the time of use, asking for forgiveness rather than permission, implicit approval via user actions, or mediated by the platform or trusted 3rd party?
    • Is it practical to offer users clear explanations about how capabilities will be used prior to being asked to make decisions on whether or not to grant applications permissions for these capabilities? What is the basis for users to trust these explanations?
    • How can developers tailor the user experience, e.g. the presentation of justifications of the need for a given capability prior to asking the user for permission? This necessitates a means for apps to discover whether the user has previously granted permission, has previously declined to grant permission or has yet to be asked.
      • Standards are needed for common capabilities and how these are named in order to provide developers with good expectations of interoperability, and to give users a consistent and understandable experience across different applications and devices.
    • What are the implications that different approaches have for API design? For instance, the implicit approach could enable APIs only in execution contexts triggered by user interaction, e.g. a click, tap or keyboard short cut. This, however, is open to abuse by mislabeling UI controls to fool users to into initiating actions without their knowledge.
      • 白小姐特码信封料 provide a comprehensive solution for intent based access control based upon Access Control Gadgets (ACGs)
      • What are the implications for app developers when the user has granted some but not all permissions requested by an app? This relates to proposals for returning a promise when testing if permissions have been granted.
    • Can we reach a consensus on a consistent approach to whether users are offered the chance to apply their decision for the rest of this session and subsequent sessions? This should depend on the level of trust in the application, e.g. whether it was accessed over an encrypted connection, whether it is from a trusted website, whether it has a high reputation, and so forth.

    Group 2: Delegated Trust

    • What roles are there for trust delegation? This could, for example, be exploited to avoid asking users for permissions for capabilities that are hard to explain. Apps stores may be trusted on the basis of their vetting procedures. Well known websites, that host their own apps, may be trusted on the basis of their brand. Other sites may find it advantageous to have their apps endorsed by a trusted third party. What kinds of limits can be imposed for trust delegation? For instance, limiting delegation to given categories of apps, and excluding apps featuring in-app payments.
    • Web apps have the unique ability to embed one another (through e.g. iframe); how does this embedding affect the ability of a Web app to request permission? how does an app with privileges indicates its willingness to be used with privileges once embedded? how does an app prevent an embedded app to request privileges (e.g. with the sandbox attribute of an iframe)?

    Group 3: Permission Management

    • When and how does the user know that a Web site has access to a given permission? how to deal with indicators in the browser chrome on mobile screens (with limited screen real estate), or when they app is running full screen?
    • Is there a need to inform apps when the user revokes a permission, e.g. to enable the app to dynamically adapt the user experience to match?
    • How should browsers adapt their permission models to the security environment of the app? How does the use of HTTPS, Content-Security-Policy, script integrity, cross-origin requests affect the permissions an app may be granted?
      • with the emergence of ServiceWorker, a number of Web app will be able to run in the background; how does the operation in background/foreground of an app affects its privileges?
      • some mobile platforms restrict some permissions to certified apps, to which other apps need to delegate the privileged operation; how does that model apply to the Web? How does it relate with proposals around integration of third-party apps such as the late Web intents, or registerProtocollHandler()
    • What level of granularity is appropriate for permissions? Too low a level will make it hard to explain to users, whilst too high a level will limit the end user's freedom of choice. Furthermore, the granularity of permissions will have consequences for developers in how they deal with the cases where users decline to grant particular permissions.
    • Some capabilities are very specific to a given platform and as such are inappropriate for standardization. Conversely, there is pressure to agree on a standard where many developers are seeking a cross-vendor solution.
    • Access to some capabilities may be restricted, e.g. consider the case where an application can only access the engine related API in a car if the application is signed by the car manufacturer.

    Group 4: Miscellaneous Topics

    • How much leeway should be left to individual implementors of the Open Web Platform? For example, does it make sense for the application manifest to list the permissions needed by the application, but leave it up to the platform implementation to determine whether to ask upfront or at the time of use?
    • It may take some time to arrive at a consensus for a detailed solution, so can we reach some initial agreements that enable work to proceed in parallel on standards for APIs for specific capabilities?

    Expected Outcome

    At the end of the meeting we would like to have a clear idea for next steps:

    • Areas where we have a rough consensus and need to work on the details?
    • Areas where we are still some way apart and what steps can be taken to close the gap?
    • What can be ruled as out of scope for W3C work on trust and permissions in the open web platform?
    • Whether we want to set up a Community Group, a Cross Working Group Task Force or some other approach?
    • What design rules can we give to allow work to proceed in parallel on APIs and trust & permissions?

    Questions? Email Dave Raggett.

  • 河北南和县:芒种时节农事忙 2020-01-18
  • 老外假装施工事故整蛊路人,一个个真吓得不轻(上) 2020-01-18
  • 习近平为传统文化“代言” 2020-01-18
  • 迎泽大街下穿火车站通道顶进过半 2020-01-18
  • 游客被指捡石子砸老虎 北京野生动物园:正在核实 2020-01-17
  • 戏曲进校园 宣传十九大又传承民族文化 2020-01-17
  • 《人民日报》创刊70周年 各界人士送祝福 2020-01-15
  • “暗剑”无人机相关新闻 2020-01-15
  • 习近平:在深入推动长江经济带发展座谈会上的讲话 2020-01-12
  • 打造科技创新领域的竞争优势 2020-01-12
  • 读书、看展成潮流 山城端午文化热 2020-01-08
  • 重庆市公安局交通管理局互联网交通安全服务管理平台 2020-01-08
  • 《鬼神童子》漫画家黑岩善宏因心肌梗塞于本月8日去世 2020-01-08
  • 第八届全国税收宣传漫画大赛评选结果揭晓 2020-01-07
  • 习近平会见美国国务卿蓬佩奥 2020-01-03
  • 股票停牌是什么意思 朝朝暮暮打一生肖 365彩票官网 河南22选5 自贡农村做什么赚钱 广西快乐十分走势图官方网站 新加坡二分彩计划软件 新版的内蒙古十一选五开奖 nba常规赛 体彩20选5最新开奖结果查询结果