Re: [UI Security] iframe URL indicator

<hat=editor/chair> I think we could put together a separate spec that just
covers this, as almost a one-liner or in "incubation" mode, and inline it
into the appropriate part of HTML or whatever other spec if it gets
interoperably implemented.  I would really not want to block advancement of
the other tech in the UISecurity spec, or have to rev that work constantly,
based on this feature that we have every reason to believe will be
controversial to implement consistently in multiple browsers.</hat>

<hat=individual> I think that many of the scenarios that require this are
best re-imagined through technologies and experiences that are
consequence-free in the case of spoofing.  (e.g. pressing a "like" button
that's not really from Facebook can't do harm to the user at Facebook
vis-a-vis to what they expected to happen, or clicking login with a FIDO
authenticator is harmless when credentials are inherently origin-scoped)
 I'm willing to see the data from experiments, but my intuition says it
isn't reasonable to expect users to understand multi-address bar interfaces
when there is such a long history of difficulty and vulnerability, still,
after 25 years of the single-origin address bar. </hat>



On Mon, Feb 22, 2016 at 5:11 AM Bil Corry <bil@corry.biz> wrote:

> Is it possible for the specification to simply state that the in-focus
> iframe URL must be presented to the user and leave it up to the implementer
> to determine how best to do it?
>
> The specification solves the problem of visibility of the iframe, but as
> written, doesn't solve the problem of identifying the origin, which is what
> is required for secure iframe interactions where sensitive information is
> being entered (e.g. credentials to the iframed site).
>
> I agree that there are some challenges, such as user understanding or
> swapping out the legitimate iframe for a phishing iframe upon a click
> event, but hopefully we can understand those limitations with Dan's test
> platform.
>
>
> - Bil
>
>
>
> On Mon, Feb 22, 2016 at 10:05 AM, Dan Kaminsky <dan@doxpara.com> wrote:
>
>> Perhaps true, but there's wide classes of interactions that cannot be
>> secured without address bar management. I'm hoping to have a usable test
>> platform including this feature in the next 4-6 weeks.  Where I think
>> everyone would agree is that this feature needs user data before approval
>> in a way normal features might not.
>>
>> On Sunday, February 21, 2016, Brad Hill <hillbrad@gmail.com> wrote:
>>
>>> These kinds of decisions have proven in practice to be beyond the
>>> ability of groups like ours to specify well.  Our intuituons about users'
>>> understandings are not as good as data, may not be universal, or may need
>>> different treatment on different devices and experiences.  With my editor
>>> hat on, I'm inclined to leave this to each UA to experiment with and
>>> determine what is best for their userbase.
>>>
>>> -Brad
>>>
>>> On Sat, Feb 13, 2016, 5:21 AM Bil Corry <bil@corry.biz> wrote:
>>>
>>>> Hi,
>>>>
>>>> i was reviewing the UI Security draft [1] and wondered if there were
>>>> plans to incorporate IronFrame's URL indicator for the iframe domain [2].
>>>> That is to say, will a user be able to see the URL of the iframe that is in
>>>> focus?
>>>>
>>>> Thanks,
>>>>
>>>> - Bil
>>>>
>>>>
>>>> [1] http://w3c.github.io/webappsec-uisecurity/
>>>>
>>>> [2] Slide 72:
>>>> http://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickjacking/
>>>>
>>>
>