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

@Joel, @Crispin: Thanks for the comments; I do see your point of views.
I've responded to some of your comments inline:

> Why effectively ban that for users who want [NSFW links in browsing
history]?
> The web site has no business telling the browser whether or not to
preserve this browsing history. [...] I would be REALLY offended if a web
site turned off my history for me.
However, the use cases I had in mind were a bit more nuanced. I do see
websites offering different "modes" through user-preferences (site
specific, not browser specific): the default one keeps opening pages via
target="_blank" or target="_new" and the alternate mode sets
target="_private".
So this feature will, just like almost all other features, need buy in by
vendor sites.

On a side note: I am not sure how the other browsing contexts (i.e.
"_blank" or "_new") came to be: perhaps they exist only for legacy reasons.
I'm afraid I haven't done my homework there. >_<

> Gay sites don’t need to be in-private at all if you are George Michael,
but they really need to be in-private if you are Larry Craig.
This sounds like user preferences which George Michael and Larry Craig may
want to set on the sites they browse. Currently, they _cannot_ do that. Not
without third-party plugins anyway.

>   Shopping for jewelry: not normally salacious, but one might want to do
it in-private if shopping for a spouse’s surprise gift, and especially if
one is shopping for a secret mistress’s gift.
Indeed. So these websites will almost never willingly set target="_private"
on their links. The browsers will still continue to let the user switch to
incognito mode if they want to.

> That sounds more like a feature request for making it easier to get into
private browsing mode. I think Chrome already does that by adding the "open
in incognito" right-click menu item.
I agree: this is a sort of a feature request which reduces UI/UX friction
rather than do something which cannot be done at all otherwise. They way I
see it: if the website **knows** that the user wants to open a link in
incognito mode and wants to give the browser this "hint", then the browser
should be able to make use of it. That was the purpose of my extension as
well: making it easier than Right-click + mouse movement + click to open
something in incognito mode. On a mobile device, personally, the effort
required is even more (long tap + open incognito + tab switch). I'd be
happy if the browser switches "Open in incognito mode" and "Open link" in
the context menu when target="_private" is set. Perhaps there is an easier
way of doing this (i.e. passing hints from the website to the browser)?

@Patrick:

> I was more thinking about maliciousness between browsing contexts. [...]

Interesting suggestion. Perhaps standardizing the Incognito behavior will
help in mitigating such attacks?


~
ut



On Tue, Jan 12, 2016 at 12:19 AM, Joel Weinberger <jww@chromium.org> wrote:

> They make sense, but I don't find them terribly convincing ;-) I've
> inlined some responses below.
> --Joel
>
> On Mon, Jan 11, 2016 at 3:03 PM Utkarsh Upadhyay <musically.ut@gmail.com>
> wrote:
>
>> Thanks for the feedback and the lively discussion!
>>
>>  > In any case, I'd like to better understand the use case of when a site
>> knows that a link should be opened "privately" and it shouldn't be the
>> users choice before we go too far down this path.
>>
>> I haven't thought about it exhaustively but have accumulated a few use
>> cases from the experience of developing an extension to help users with
>> switching to incognito mode.
>>
>> First use case was of websites knowing *risky clicks* and providing a
>> _safe_ way to make sure that the user doesn't have to clean up after
>> himself, i.e. NSFW links on their content. Reddit was an example I provided
>> in my original mail but other news sites will probably also find use for it.
>>
> It seems like the "right" thing to do is to mark the links as NSFW and let
> the user decide if they want them in their browsing history. Heck, some
> people might *want* that in their history for many reasons. Why effectively
> ban that for users who want it?
>
>>
>> Second use case was being able to give users clearer instructions. An
>> example of such a case I recently ran across was here:
>> https://support.google.com/accounts/answer/6160500?hl=en
>>
>> Relevant part of the page:
>>
>> > Sign in to your Google Account on android.com/devicemanager
>> <http://www.android.com/devicemanager>. If you're helping a friend with
>> their lost device, we recommend opening an incognito tab in Chrome
>> <https://support.google.com/chrome/answer/95464> and having them sign in
>> to the Google Account they use on their mobile device.
>>
>> Such instructions can be simplified by linking to the website with
>> target="_private". Other links which may accidentally reveal personal
>> information (think direct links to bank account balance page) can also be
>> made save by setting target="_private".
>>
> The key word in that is "recommend". Again, there may be valid reasons for
> a user to *not* go into private browsing.
>
>>
>>
>> Thirdly, and what prompted me to think of this proposal, was that opening
>> an incognito window through an extension on Chrome is rather convoluted
>> (uses background scripts) and fragile. It may not continue to work, for
>> example, when
>> https://developer.chrome.com/extensions/manifest/externally_connectable
>> is enforced. In any case, the extension requires permissions to access
>> _all_ data across _all_ websites, which already should be raising eyebrows.
>> I'd rather have this provided by the site + the browser, both of which I
>> trust more than a third party plugin.
>>
> That sounds more like a feature request for making it easier to get into
> private browsing mode. I think Chrome already does that by adding the "open
> in incognito" right-click menu item.
>
>>
>> Do these make sense?
>>
>> ----
>>
>> > This feature would require formalizing these modes, and that seems
>> tricky at best, since the user agents are not necessarily providing the
>> same guarantees.
>>
>> If several browsers are providing independent implementations of features
>> which _sound_ similar, isn't this is a good time to standardize it, even if
>> it takes a bit of effort?
>>
>>
>> ~
>> ut
>>
>>