- From: Utkarsh Upadhyay <musically.ut@gmail.com>
- Date: Sat, 6 Feb 2016 15:14:56 +0100
- To: Tanvi Vyas <tanvi@mozilla.com>
- Cc: Crispin Cowan <crispin@microsoft.com>, Joel Weinberger <jww@chromium.org>, Anne van Kesteren <annevk@annevk.nl>, "timeless@gmail.com" <timeless@gmail.com>, Patrick Toomey <patrick.toomey@github.com>, Richard Barnes <rbarnes@mozilla.com>, WebAppSec WG <public-webappsec@w3.org>
- Message-ID: <CALh3q9xxQimp+9ZFU1rX1hTWJNr9hNKrhopYSPeAPEs_-D4=iw@mail.gmail.com>
Hi Tanvi, Thanks for bringing the previous discussion to my notice. The crux, if I am getting this right, was allowing websites to request the browser to open them in Incognito mode via headers. This compliments links which have target="_private" as the bowser can make use of both these hints. However, the scope of these two suggestions is slightly different: while sending of headers can be done when the user types in the URL himself, target="_private" covers only cases when the referrer *thinks* that the target website should be opened in incognito mode. Other than that, they share similar problems and benefits: both can be exploited for phishing attacks, both require (some) standardization of private mode browsing, and both make the private mode feature more discoverable. Following the discussion here, I have come to believe that giving websites ability to manipulate history in any way would be a Bad Idea (TM) and that if a user runs into a handful of links which require permissions pop-ups again and again, they would become annoying and will be ignored. I am still undecided about domain-wide time-limited ask-once permissions to allow private mode browsing. Nevertheless, as someone who would use this feature, I am happy that there is at least some interest in it. I hope that I was able to contribute a different, albeit incomplete, solution. :) ~ ut On Sat, Feb 6, 2016 at 2:41 AM, Tanvi Vyas <tanvi@mozilla.com> wrote: > Something similar to this was discussed a few months ago on this list: > https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0016.html > > The biggest issue I see is that this could be easily abused by > phishing/malware sites. > > The proposal considered sites that tailored towards victims of domestic > abuse. But if the victim found the page through a search engine, the > search terms would still be in their history. And hence opening the abuse > site in a private window may give victims a false sense of security. A web > API that caused the browser to ask the user if they wanted to clear that > last X minutes of their history may be more useful. > > ~Tanvi > > On 1/24/16 2:03 AM, Utkarsh Upadhyay wrote: > > So here's a summary of the discussion so far (the status of items with > question mark is not completely clear to me): > > Proposal: adding target="_private" to <a> tag spec and an explicit > "private mode" browsing context. > > Pros: > + Better UI/UX on some sites (e.g. some links on Reddit). > + Easier to give instructions when sites require a session/cookie-less > browsing context. > + Easier discoverability of the private browsing feature. > > Cons: > - Sites may conduct (phishing?) attacks on the user and not leave a > trace. > - Whether to go private or not should be strictly a user decision. > ? Will require standardizing Incognito/private mode across browsers. > - Unclear how to explain the risks involved in simple language to the > user. > > Compromises: > - Pop-ups for each click: too annoying and will be ignored. > ? One-off permission for domains, like the permissions for media access. > > Did I miss anything? > > ~ > ut > > > On Thu, Jan 14, 2016 at 2:29 AM, Crispin Cowan <crispin@microsoft.com> > wrote: > >> I basically disbelieve the premise of the idea. Whether any particular >> web browsing should be privatized/not-logged is not the web site’s >> business, that is a user decision. >> >> >> >> Regarding the prompt, I completely agree with Joel, that would become a >> nuisance prompt that users don’t understand, and quickly come to hate and >> ignore. >> >> >> >> *From:* Joel Weinberger [mailto:jww@chromium.org] >> *Sent:* Wednesday, January 13, 2016 5:27 PM >> *To:* Utkarsh Upadhyay < <musically.ut@gmail.com>musically.ut@gmail.com>; >> Crispin Cowan <crispin@microsoft.com> >> *Cc:* Anne van Kesteren < <annevk@annevk.nl>annevk@annevk.nl>; >> 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" >> >> >> >> That is now something Chrome would do, in part because we believe it >> wouldn't mitigate the risk. Users would become desnesitized and click >> through anyway, but even more importantly, there's no way to explain the >> attack in generally understandable terminology. >> >> >> >> On Wed, Jan 13, 2016, 4:01 PM Utkarsh Upadhyay < <musically.ut@gmail.com> >> musically.ut@gmail.com> wrote: >> >> > 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> >> 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> >> musically.ut@gmail.com] >> *Sent:* Tuesday, January 12, 2016 2:38 AM >> *To:* Anne van Kesteren < <annevk@annevk.nl>annevk@annevk.nl> >> *Cc:* Crispin Cowan < <crispin@microsoft.com>crispin@microsoft.com>; >> Joel Weinberger < <jww@chromium.org>jww@chromium.org>; timeless@gmail.com; >> Patrick Toomey < <patrick.toomey@github.com>patrick.toomey@github.com>; >> Richard Barnes < <rbarnes@mozilla.com>rbarnes@mozilla.com>; WebAppSec WG >> < <public-webappsec@w3.org>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> >> annevk@annevk.nl> wrote: >> >> On Tue, Jan 12, 2016 at 1:08 AM, Crispin Cowan < <crispin@microsoft.com> >> 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/>https://annevankesteren.nl/ >> >> >> >> >> >> > >
Received on Saturday, 6 February 2016 14:15:45 UTC