W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2016

Re: Proposal to add a browsing context named "_private"

From: Utkarsh Upadhyay <musically.ut@gmail.com>
Date: Thu, 14 Jan 2016 01:01:22 +0100
Message-ID: <CALh3q9yqmw7TQvXwV4BYR2EPcyvr=erOZku69kZ9GwzFX5PJHw@mail.gmail.com>
To: Crispin Cowan <crispin@microsoft.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, Joel Weinberger <jww@chromium.org>, "timeless@gmail.com" <timeless@gmail.com>, Patrick Toomey <patrick.toomey@github.com>, Richard Barnes <rbarnes@mozilla.com>, WebAppSec WG <public-webappsec@w3.org>
> Let me put this another way: the _private proposal is an attack vector.
It lets a malicious web site block the user’s browser from recording
history data without the user’s consent.

What if we ask the user for consent before opening each link or make the
websites ask for user's permissions explicitly just like for media access?
Would that mitigate the security risk?

~
ut


On Tue, Jan 12, 2016 at 11:57 PM, Crispin Cowan <crispin@microsoft.com>
wrote:

> My comment about bookmarks was a joke: the point of private browsing is to
> not leave tracks on your PC that you have browsed to a particular place.
> Having a bookmark on your PC for “naughty salacious things” is itself an
> obvious trace, and so defeats the purpose.
>
>
>
> Let me put this another way: the _private proposal is an attack vector. It
> lets a malicious web site block the user’s browser from recording history
> data without the user’s consent. If someone were to ship such a feature in
> our browser, I would file a security bug to have it removed.
>
>
>
> *From:* Utkarsh Upadhyay [mailto:musically.ut@gmail.com]
> *Sent:* Tuesday, January 12, 2016 2:38 AM
> *To:* Anne van Kesteren <annevk@annevk.nl>
> *Cc:* Crispin Cowan <crispin@microsoft.com>; Joel Weinberger <
> jww@chromium.org>; timeless@gmail.com; Patrick Toomey <
> patrick.toomey@github.com>; Richard Barnes <rbarnes@mozilla.com>;
> WebAppSec WG <public-webappsec@w3.org>
> *Subject:* Re: Proposal to add a browsing context named "_private"
>
>
>
> > I know! How about letting the user specify that a bookmark should be
> opened in-private? … oh, right :P
>
>
>
> I understand that the comment was made to show that target="_private" will
> not solve all problems associated with opening links in private mode, but
> this set me thinking in another direction.
>
> As Crispin's comment points out, bookmarking is also a feature common to
> all browsers and which is, AFAIK, not standardized (notwithstanding the
> link type="bookmark", which doesn't address this feature of browsers
> explicitly).
>
> I don't see any immediate benefit of standardizing it and I actually
> wouldn't support it without some very very good reasons.
>
>
>
> However, the more I think about it, private mode browsing is the kind of
> feature which would really benefit from standardization: it would make the
> developers know what to expect and would make sure that users get the
> similar sort of guarantees across all conforming browsers.
>
> In that spirit, I think a new named browsing context is a good way to
> introduce such a standardization and a way of opening it up to web
> developers.
>
>
>
> ~
>
> ut
>
>
>
>
>
> On Tue, Jan 12, 2016 at 9:18 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
>
> On Tue, Jan 12, 2016 at 1:08 AM, Crispin Cowan <crispin@microsoft.com>
> wrote:
> > I think this whole area causes more problems than it solves. I can
> clearly
> > see the problems, much less clear on potential solutions, and really
> vague
> > on the problem it is trying to solve.
>
> It seems pretty clear to me. For some use cases, the website can offer
> better UI than the browser. E.g., for most social media that relates
> around sharing links, as OP suggested, the user could opt-in to
> opening certain links in a "private mode". This is much more
> discoverable than the equivalent feature in a browser and is also more
> usable as you don't have to right-click, hold down a set of keys, or
> some equivalent forgetful thing on your phone.
>
>
> --
> https://annevankesteren.nl/
>
>
>
Received on Thursday, 14 January 2016 00:02:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:17 UTC