On Apr 17, 2012, at 8:19 PM, Maire Reavy wrote:
> It seems that one thing we've discovered is that we can't separate the
> security design and discussion from the UX/UI design itself. Our UX/UI teams
> would tell us that the most critical and interesting pieces of the UX/UI
> design is not a p
On 4/17/2012 8:47 PM, Lucas Adamski wrote:
On 4/17/2012 3:43 PM, Maire Reavy wrote:
It feels like we are designing most of the chrome UX/UI for this feature on
this thread -- instead of just calling out
the security requirements for a UX/UI design of the chrome. If we are
designing the UX/UI
On 18/04/12 04:18 AM, Zack Weinberg wrote:
I feel very strongly that we should initially attempt to design a system
where there are no install-time permission prompts, and more generally,
no prompts for which "remember this decision" is a desirable option.
As Adrienne has been pointing out, perm
On 4/17/2012 11:31 AM, Zack Weinberg wrote:
> On 2012-04-14 9:57 PM, Lucas Adamski wrote:
>> On Apr 13, 2012, at 8:20 PM, Zack Weinberg wrote:
>>
>>> On 2012-04-13 6:37 PM, Adrienne Porter Felt wrote:
I'm trying to brainstorm a new way to fit trusted UI into the
user's normal flow that wo
On 4/15/2012 1:32 PM, Adrienne Porter Felt wrote:
> Would the following suggestion solve the problem?
>
> * Applications may embed the "magic" photo or videorecord icons. As soon as
> the user presses the button, the app
> receives the data. A notification is present as long as the app is
> re
On 4/17/2012 3:43 PM, Maire Reavy wrote:
>
> It feels like we are designing most of the chrome UX/UI for this feature on
> this thread -- instead of just calling out
> the security requirements for a UX/UI design of the chrome. If we are
> designing the UX/UI on this thread, then we need
> to g
On 4/17/2012 4:15 PM, Randell Jesup wrote:
On 4/16/2012 11:14 AM, Jason Miller wrote:
That is one area where one could trust the app - the only way for it to
gain access to the camera would be to insert the button's DOM node
facade
(this is a secure mechanism, because the DOM node is not the bu
Comments in line below
On Apr 17, 2012, at 4:08 PM, Adrienne Porter Felt wrote:
>
>
> On Mon, Apr 16, 2012 at 7:42 PM, Jim Straus wrote:
> On Apr 16, 2012, at 10:24 AM, Adrienne Porter Felt wrote:
>
> > -- Changing the wallpaper or ringtone: Let all apps do it, but provide an
> > "undo" mecha
I like the original thinking that is going into trying to avoid specific
permission prompts and use implied consent. I have some questions and
concerns, so I'm going to go through a scenario and see if I'm understanding
correctly and solicit thoughts on some issues.
Scenario: A camera that ta
On Mon, Apr 16, 2012 at 7:42 PM, Jim Straus wrote:
> On Apr 16, 2012, at 10:24 AM, Adrienne Porter Felt wrote:
>
> > -- Changing the wallpaper or ringtone: Let all apps do it, but provide an
> > "undo" mechanism in Settings that changes it back to what it was prior to
> > that app altering it.
>
+1 to everything Zack said
Standard runtime dialogs that ask for Allow/deny are familiar, so system
designers seem to like them -- but a lot of literature establishes that
they don't work. Android tried moving them to install-time, which works
for a small minority of users sometimes. Unfortunatel
On 2012-04-14 9:57 PM, Lucas Adamski wrote:
On Apr 13, 2012, at 8:20 PM, Zack Weinberg wrote:
On 2012-04-13 6:37 PM, Adrienne Porter Felt wrote:
I'm trying to brainstorm a new way to fit trusted UI into the
user's normal flow that would enable preview modification,
without throwing up a standa
I feel very strongly that we should initially attempt to design a system
where there are no install-time permission prompts, and more generally,
no prompts for which "remember this decision" is a desirable option.
As Adrienne has been pointing out, permissions dialogs in general do not
work.
[ Reposting via mail interface because attempts to cross-post responses
in News appeared to cause my message to end up in approval queues for
the relevant mail lists - and no one appears to have approved them, at
least not in security and B2G ]
>Some followup issues that came up in conversatio
[ Reposting via mail interface because attempts to cross-post responses
in News appeared to cause my message to end up in approval queues for
the relevant mail lists - and no one appears to have approved them, at
least not in security and B2G ]
>Actually, a lot of apps need access to the previ
[ Reposting via mail interface because attempts to cross-post responses
in News appeared to cause my message to end up in approval queues for
the relevant mail lists - and no one appears to have approved them, at
least not in security and B2G ]
>The countdown annoyance could also be mitigated
> I don't understand these categories, could you explain them a bit further?
Lucas can correct me, but AIUI this is a model that Lucas has
developed for thinking about trust and apps. These categories may not
have concrete analogs in B2G.
There was previously a lot of talk about somehow requirin
On Mon, Apr 16, 2012 at 7:14 AM, Lucas Adamski wrote:
>
> == Regular web content (unauthenticated) ==
>
> == Trusted (authenticated by publisher) ==
>
> == Certified (vouched for by trusted 3rd party) ==
>
I don't understand these categories, could you explain them a bit further?
What is the di
18 matches
Mail list logo
