Feature Request and then server implementation to be put forward to w3c
Philip Clarke
Okay that sounds very grandiose, but it's a combination feature request
and concept that can be implemented in Firefox immediately and then
ratified later.
I suggest that firefox opens up a Private Browsing session immediately
upon receiving a header from a web server like
X-privacy: Private
There's been a lot of discussion about user tracking and the browser
sending a header which the "website" (whomever is running it) may or may
not respect and whether this is enforceable in any way. This is
different in that it's a client side response to a server request.
The idea behind it is that organisations for child abuse, spousal abuse,
crime reporting websites etc... could implement this code extremely
easily at either the server or module/ scripting language level and it
would help ensure the safety/ privacy of the internet user without them
needing any further action. The problem is that currently people have to
be aware of the Private Browsing system (or incognito etc...) and have
to deliberately choose the option. The average user doesn't clear their
history, check for cookies labelled from websites etc... and across the
internet we have many different instructions for each browser which
sometimes a user may not be able to follow.
Possibly - one may wish to implement an "Optional" setting so that users
can select
X-privacy: Optional
which would pop up a user "would you like to open a private browsing
session?" which may be useful for developers etc... but the Private
option (and this may grate against some people's opinion) should be
enforced without notification. People do not get asked if they would
like a secure https:// connection they may be notified if something on a
page is not part of the protocol and I believe that the well being of
the individual should be the concern and made a priority.
--
www.howtogetdivorced.com - opening soon.
Ehsan Akhgari
are a couple of quick questions that come to my mind right now:
1. What should happen if only parts of the resources for a website send
this header? Or what would happen if some of the resources on a domain
send this header?
2. Would this not be surprising to users if later on they find out that
they can't find a website that they have visited recently in their history?
Cheers,
Ehsan
Philip Clarke
On 27/08/11 23:46, Ehsan Akhgari wrote:
> Are you proposing that this should happen transparently to a user? Here
> are a couple of quick questions that come to my mind right now:
>
> 1. What should happen if only parts of the resources for a website send
> this header? Or what would happen if some of the resources on a domain
> send this header?
I believe that a Private Browsing session is a Private browsing session
and so would clear all the date including date from external resources
from the cache after the session is closed, but I am not an expert on
the innards of firefox. I think that the implantation has to be that the
website in the address bar be the one to initiate the Private Browsing
session, also I would question whether Mozilla should expose a
navigator.privateBrowsing flag to the webiste so that a website can
choose to then display a message to the user saying "oi you could be
surfing privately" and I also put in a request to the extensions group
(no response so far) to see if they could build an extension to
implement the functionality for backwards compatibility so that a
website detecting firefox and no private browsing could point the user
in the direction of an add-on.
> 2. Would this not be surprising to users if later on they find out that
> they can't find a website that they have visited recently in their
history?
I think Private Browsing when activated is quite clearly marked and I'm
think of the eleven year old child who wants the childline phone number
and doesn't want to get found out. I don't think they would be overly
concerned. For other websites like the police, then the X-privacy:
optional header clearly asks the user if they want to initiate Private
Browsing so they would be informed, and of course the website can always
choose which setting is the more appropriate.
Ehsan Akhgari
>
>
> On 27/08/11 23:46, Ehsan Akhgari wrote:
> > Are you proposing that this should happen transparently to a user? Here
> > are a couple of quick questions that come to my mind right now:
> >
> > 1. What should happen if only parts of the resources for a website send
> > this header? Or what would happen if some of the resources on a domain
> > send this header?
>
> I believe that a Private Browsing session is a Private browsing session
> and so would clear all the date including date from external resources
> from the cache after the session is closed, but I am not an expert on
> the innards of firefox. I think that the implantation has to be that the
> website in the address bar be the one to initiate the Private Browsing
> session, also I would question whether Mozilla should expose a
> navigator.privateBrowsing flag to the webiste so that a website can
> choose to then display a message to the user saying "oi you could be
> surfing privately" and I also put in a request to the extensions group
> (no response so far) to see if they could build an extension to
> implement the functionality for backwards compatibility so that a
> website detecting firefox and no private browsing could point the user
> in the direction of an add-on.
We go to great lengths to try to hide whether the user is in private
browsing mode from websites. Having a global flag on the navigator
object would defeat that protection.
But my original question here remains. Currently, private browsing as
implemented by Firefox is a global mode, and it's definitely not
acceptable for one website to affect the environment in which other
websites live.
But apart from the implementation details of Firefox, one should clearly
define what should happen in those situations before we can decide
whether we want to add this functionality to Firefox or not...
> > 2. Would this not be surprising to users if later on they find out that
> > they can't find a website that they have visited recently in their
> history?
>
> I think Private Browsing when activated is quite clearly marked and I'm
> think of the eleven year old child who wants the childline phone number
> and doesn't want to get found out. I don't think they would be overly
> concerned. For other websites like the police, then the X-privacy:
> optional header clearly asks the user if they want to initiate Private
> Browsing so they would be informed, and of course the website can always
> choose which setting is the more appropriate.
Are you proposing that we should switch the entire session to be private
by prompting the user when they visit a website which sets the X-Privacy
header? That would disrupt the operation of all other tabs that the
user has open. Think of a malicious website setting that header just to
annoy users. We need a better interaction model here.
Cheers,
Ehsan
Philip Clarke
On 29/08/11 21:06, Ehsan Akhgari wrote:
> On 11-08-27 8:38 PM, Philip Clarke wrote:
>>
>>
>> On 27/08/11 23:46, Ehsan Akhgari wrote:
>> > Are you proposing that this should happen transparently to a user? Here
>> > are a couple of quick questions that come to my mind right now:
>> >
>> > 1. What should happen if only parts of the resources for a website send
>> > this header? Or what would happen if some of the resources on a domain
>> > send this header?
>>
>> I believe that a Private Browsing session is a Private browsing session
>> and so would clear all the date including date from external resources
>> from the cache after the session is closed, but I am not an expert on
>> the innards of firefox. I think that the implantation has to be that the
>> website in the address bar be the one to initiate the Private Browsing
>> session, also I would question whether Mozilla should expose a
>> navigator.privateBrowsing flag to the webiste so that a website can
>> choose to then display a message to the user saying "oi you could be
>> surfing privately" and I also put in a request to the extensions group
>> (no response so far) to see if they could build an extension to
>> implement the functionality for backwards compatibility so that a
>> website detecting firefox and no private browsing could point the user
>> in the direction of an add-on.
>
> We go to great lengths to try to hide whether the user is in private
> browsing mode from websites. Having a global flag on the navigator
> object would defeat that protection.
Why ? what is the justification for hiding that a browser is private
mode when it is clearly exposed that for example a user is browsing
using https:// I'm not trying to be provocative here, I understand that
historically there have been incidents of user tracking, respawning
cookies and that mozilla has been working hard on solving the link
colour history issue that enable hackers to guess where user's had been.
> But my original question here remains. Currently, private browsing as
> implemented by Firefox is a global mode, and it's definitely not
> acceptable for one website to affect the environment in which other
> websites live.
Yes but I believe the development road map for firefox is to implement
private tabs and windows without the need to close all the windows in
the rear and this can be implemented as those changes are made. I
believe Opera already has this facility and one Chrome spawns a new
window leaving the others open in the background.
> But apart from the implementation details of Firefox, one should clearly
> define what should happen in those situations before we can decide
> whether we want to add this functionality to Firefox or not...
I'm sorry, which situations ? I have published draft specifiation at
http://www.x-privacy.org/content/draft-specification about expected
behaviour, optional behaviour and amendments mentioned in this thread.
>> > 2. Would this not be surprising to users if later on they find out that
>> > they can't find a website that they have visited recently in their
>> history?
>>
>> I think Private Browsing when activated is quite clearly marked and I'm
>> think of the eleven year old child who wants the childline phone number
>> and doesn't want to get found out. I don't think they would be overly
>> concerned. For other websites like the police, then the X-privacy:
>> optional header clearly asks the user if they want to initiate Private
>> Browsing so they would be informed, and of course the website can always
>> choose which setting is the more appropriate.
>
> Are you proposing that we should switch the entire session to be private
> by prompting the user when they visit a website which sets the X-Privacy
> header? That would disrupt the operation of all other tabs that the user
> has open. Think of a malicious website setting that header just to annoy
> users. We need a better interaction model here.
At the moment firefox (6.0 on Ubuntu) does disrupt the user by switching
to private browsing as it closes all the tabs that are currently open
and then opens a new window when the user already chooses the option. As
mentioned above I believe that the roadmap is to change this behaviour
and to allow concurrent private tabs and windows as implmented by Opera
and to come extent Chrome. My suggestion is that when the road map is
implemented and the code is being examined anyway, that X-privacy be put
in. This then negates the malicious website model
X-privacy: Optional could be implemented faster though because then a
user has the choice to open a "malicious website" in private browsing
mode or not.
Thank you.
Ehsan Akhgari
We do this in order to preserve user's privacy. Some of the users might
not want a website to know that they're browsing it in a special
browsing mode (private browsing) in case the website can guess why they
are doing that.
>> But my original question here remains. Currently, private browsing as
>> implemented by Firefox is a global mode, and it's definitely not
>> acceptable for one website to affect the environment in which other
>> websites live.
>
> Yes but I believe the development road map for firefox is to implement
> private tabs and windows without the need to close all the windows in
> the rear and this can be implemented as those changes are made. I
> believe Opera already has this facility and one Chrome spawns a new
> window leaving the others open in the background.
While we have thought about providing this feature, we still have a lot
of technical challenges to solve in order to get there.
>> But apart from the implementation details of Firefox, one should clearly
>> define what should happen in those situations before we can decide
>> whether we want to add this functionality to Firefox or not...
>
> I'm sorry, which situations ? I have published draft specifiation at
> http://www.x-privacy.org/content/draft-specification about expected
> behaviour, optional behaviour and amendments mentioned in this thread.
Let me quote myself from my first reply to this thread:
>>> > 1. What should happen if only parts of the resources for a website
>>> send
>>> > this header? Or what would happen if some of the resources on a
domain
>>> > send this header?
>>> > 2. Would this not be surprising to users if later on they find out
>>> that
>>> > they can't find a website that they have visited recently in their
>>> history?
>>>
>>> I think Private Browsing when activated is quite clearly marked and I'm
>>> think of the eleven year old child who wants the childline phone number
>>> and doesn't want to get found out. I don't think they would be overly
>>> concerned. For other websites like the police, then the X-privacy:
>>> optional header clearly asks the user if they want to initiate Private
>>> Browsing so they would be informed, and of course the website can always
>>> choose which setting is the more appropriate.
>>
>> Are you proposing that we should switch the entire session to be private
>> by prompting the user when they visit a website which sets the X-Privacy
>> header? That would disrupt the operation of all other tabs that the user
>> has open. Think of a malicious website setting that header just to annoy
>> users. We need a better interaction model here.
>
> At the moment firefox (6.0 on Ubuntu) does disrupt the user by switching
> to private browsing as it closes all the tabs that are currently open
> and then opens a new window when the user already chooses the option. As
> mentioned above I believe that the roadmap is to change this behaviour
> and to allow concurrent private tabs and windows as implmented by Opera
> and to come extent Chrome. My suggestion is that when the road map is
> implemented and the code is being examined anyway, that X-privacy be put
> in. This then negates the malicious website model
My point was that it would be pretty bad if *navigating to a website*
can trigger that interaction.
Cheers,
Ehsan
Ehsan Akhgari
Philip Clarke
On 30/08/11 20:58, Ehsan Akhgari wrote:
<snip />
>>> We go to great lengths to try to hide whether the user is in private
>>> browsing mode from websites. Having a global flag on the navigator
>>> object would defeat that protection.
>>
>> Why ? what is the justification for hiding that a browser is private
>> mode when it is clearly exposed that for example a user is browsing
>> using https:// I'm not trying to be provocative here, I understand that
>> historically there have been incidents of user tracking, respawning
>> cookies and that mozilla has been working hard on solving the link
>> colour history issue that enable hackers to guess where user's had been.
>
> We do this in order to preserve user's privacy. Some of the users might
> not want a website to know that they're browsing it in a special
> browsing mode (private browsing) in case the website can guess why they
> are doing that.
Yes but this is easy to get around. a) set a cookie in PB and store it
attached to the user agent and ip address, b) if they surf later and the
cookie doesn't turn up you have a 50 to 1 chance that the user is a
private browser (based on ISP's contention ratio in the UK, but that is
a very old figure from the late 90's) *or* a) set a cookie on logging in
an register that the person logged in, b) if they turn off PB then they
would need to log in again, the cookie would still be "active" but not
presented by the browser, so either they cleared their cookies or the
previously were using PB. So that;s two ways of knowing historically if
a user tends to use PB.
>> I'm sorry, which situations ? I have published draft specifiation at
>> http://www.x-privacy.org/content/draft-specification about expected
>> behaviour, optional behaviour and amendments mentioned in this thread.
>
> Let me quote myself from my first reply to this thread:
>
> >>> > 1. What should happen if only parts of the resources for a website
> >>> send
> >>> > this header? Or what would happen if some of the resources on a
> domain
> >>> > send this header?
The web page sends the header, not any images, not included javascript
or css all of which may be rewritten by mod_pagespeed. If certain pages
on the site send the header then private browsing is initiated then.
After version 1.x of the specification is applied it's then time to
think about clearing out history and autocomplete for the rest of the
site. It would be logical to assume that on sites where reporting is
abuse is the purpose, that the X-privacy header would be sent on every
page, so that at every entry point either optional or private is
trigger. *but* I've just realised, this is a problem.
1) Either the navigator.privateBrowsing object is going to have to be
exposed or the user would be asked on every page opened,
2) or the session (server side) is going to have to store that the
header has already been sent
3) the browser ignores the X-privacy header on that domain after being
asked the first time and needs to keep an encrypted list, not accessible
to the browser user, otherwise it would be another history list.
Non X-privacy implementing browsers will ignore then header all the
time. Version 1.3 will be ready by 10am to take these options into
account. After I've had a cup of tea and had a think about the best
method of recommendation for the specification.
>> At the moment firefox (6.0 on Ubuntu) does disrupt the user by switching
>> to private browsing as it closes all the tabs that are currently open
>> and then opens a new window when the user already chooses the option. As
>> mentioned above I believe that the roadmap is to change this behaviour
>> and to allow concurrent private tabs and windows as implemented by Opera
>> and to come extent Chrome. My suggestion is that when the road map is
>> implemented and the code is being examined anyway, that X-privacy be put
>> in. This then negates the malicious website model
>
> My point was that it would be pretty bad if *navigating to a website*
> can trigger that interaction.
and I agree so first of all X-privacy: optional is implemented to negate
the malicious behaviour, and then when Mozilla does switch to mixing PBS
tabs and windows then it become a non-issue to implement X-privacy:
Private. There was also a comment about being able to turn the whole
thing off, I think that it's an idea, but that if X-privacy: Private is
disabled (by an abusive parent who is snooping), that a status message
be displayed every time on a per domain basis, every time an X-privacy
header is received, i.e. turning it off just means nothing happens, no
private session is spawned, but it always runs in the background to keep
the user informed that a) it's an option on some websites b) the abuser
cannot hide it away from the people it is supposed to protect.
Ehsan Akhgari
Both of these situations can also happen because of other reasons
besides the user being in private browsing mode. Please note that I'm
not saying that it's impossible for a web page to get its hands on this
information, but it's not easy either. Therefore, exposing this
information from an API would not be an option, unfortunately.
>>> I'm sorry, which situations ? I have published draft specifiation at
>>> http://www.x-privacy.org/content/draft-specification about expected
>>> behaviour, optional behaviour and amendments mentioned in this thread.
>>
>> Let me quote myself from my first reply to this thread:
>>
>> >>> > 1. What should happen if only parts of the resources for a website
>> >>> send
>> >>> > this header? Or what would happen if some of the resources on a
>> domain
>> >>> > send this header?
>
> The web page sends the header, not any images, not included javascript
> or css all of which may be rewritten by mod_pagespeed. If certain pages
> on the site send the header then private browsing is initiated then.
Let's also think about the pathological case of an ad network serving
that header every time it sends a page to the browser embedded in an
iframe on another web page. Or alternatively, multiple applications
hosted on the same domain, where only one of them requires private
browsing mode.
> After version 1.x of the specification is applied it's then time to
> think about clearing out history and autocomplete for the rest of the
> site.
I would rather us keeping the discussion limited to the simple case for
now, and think about future improvements once we get the first iteration
right. :-)
> It would be logical to assume that on sites where reporting is
> abuse is the purpose, that the X-privacy header would be sent on every
> page, so that at every entry point either optional or private is
> trigger. *but* I've just realised, this is a problem.
>
> 1) Either the navigator.privateBrowsing object is going to have to be
> exposed or the user would be asked on every page opened,
> 2) or the session (server side) is going to have to store that the
> header has already been sent
> 3) the browser ignores the X-privacy header on that domain after being
> asked the first time and needs to keep an encrypted list, not accessible
> to the browser user, otherwise it would be another history list.
The first case is not an option, as I described above. The 3rd case
will fail in the case of multiple web applications hosted on the same
domain.
The second case would work, but it requires the web page to have a
notion of the "first time" that the user is visiting it. Existing ways
of tracking this information (for example, setting a cookie) are not
reliable unfortunately (for example, if the user clears cookies, or does
not accept them at all).
> Non X-privacy implementing browsers will ignore then header all the
> time. Version 1.3 will be ready by 10am to take these options into
> account. After I've had a cup of tea and had a think about the best
> method of recommendation for the specification.
User agents are supposed to ignore HTTP headers that they do not
understand, so we would get this for free.
>>> At the moment firefox (6.0 on Ubuntu) does disrupt the user by switching
>>> to private browsing as it closes all the tabs that are currently open
>>> and then opens a new window when the user already chooses the option. As
>>> mentioned above I believe that the roadmap is to change this behaviour
>>> and to allow concurrent private tabs and windows as implemented by Opera
>>> and to come extent Chrome. My suggestion is that when the road map is
>>> implemented and the code is being examined anyway, that X-privacy be put
>>> in. This then negates the malicious website model
>>
>> My point was that it would be pretty bad if *navigating to a website*
>> can trigger that interaction.
>
> and I agree so first of all X-privacy: optional is implemented to negate
> the malicious behaviour, and then when Mozilla does switch to mixing PBS
> tabs and windows then it become a non-issue to implement X-privacy:
> Private. There was also a comment about being able to turn the whole
> thing off, I think that it's an idea, but that if X-privacy: Private is
> disabled (by an abusive parent who is snooping), that a status message
> be displayed every time on a per domain basis, every time an X-privacy
> header is received, i.e. turning it off just means nothing happens, no
> private session is spawned, but it always runs in the background to keep
> the user informed that a) it's an option on some websites b) the abuser
> cannot hide it away from the people it is supposed to protect.
Once we have an implementation of private browsing which can be turned
on per tab, then we can think of what it means to support this header in
terms of that implementation. But at least for Firefox, we have to move
within our current limitations, at least for now. :(
Cheers,
Ehsan
Philip Clarke
Which would do noting if the right to issue X-privacy was only given to
the domain in the address bar. Firefox then ignores X-privacy for that
domain if it is in private browsing, but a list would need to be kept
inside of firefox for the case of "optional" where the user elected not
to use Private Browsing, otherwise firefox would not ignore it.
>> After version 1.x of the specification is applied it's then time to
>> think about clearing out history and autocomplete for the rest of the
>> site.
>
> I would rather us keeping the discussion limited to the simple case for
> now, and think about future improvements once we get the first iteration
> right. :-)
>
> > It would be logical to assume that on sites where reporting is
>> abuse is the purpose, that the X-privacy header would be sent on every
>> page, so that at every entry point either optional or private is
>> trigger. *but* I've just realised, this is a problem.
>>
>> 1) Either the navigator.privateBrowsing object is going to have to be
>> exposed or the user would be asked on every page opened,
>> 2) or the session (server side) is going to have to store that the
>> header has already been sent
>> 3) the browser ignores the X-privacy header on that domain after being
>> asked the first time and needs to keep an encrypted list, not accessible
>> to the browser user, otherwise it would be another history list.
>
> The first case is not an option, as I described above. The 3rd case will
> fail in the case of multiple web applications hosted on the same domain.
> The second case would work, but it requires the web page to have a
> notion of the "first time" that the user is visiting it. Existing ways
> of tracking this information (for example, setting a cookie) are not
> reliable unfortunately (for example, if the user clears cookies, or does
> not accept them at all).
case 1) I still fail to see them implications of knowing that someone is
browsing privately when it is trivial to find out anyway. I believe that
firefox solved the link colour/ history hack recently so all the web
master needs to do is check the link color to see that history is not
active and they then know (they use an ajax request to "visit a page"
embedded in the pages and hidden divs to check link colour).
case 2) easy, session established $_SESSION['SOMEVAR'] = true means
header was sent. No session, gets sent again. The user would have to
clear the cookies half way through visiting the site to initiate the
x-privacy, this is trivial in PHP not even requiring cookies if necessary.
case 3) see above it could be considered as a safety net though
>
>> Non X-privacy implementing browsers will ignore then header all the
>> time. Version 1.3 will be ready by 10am to take these options into
>> account. After I've had a cup of tea and had a think about the best
>> method of recommendation for the specification.
>
> User agents are supposed to ignore HTTP headers that they do not
> understand, so we would get this for free.
Yes.
The specification including your comments/ amendments is here:
http://www.x-privacy.org/content/draft-specification
there are test domains at
http://xpo.x-privacy.org - optional Private Browsing header
http://xpp.x-privacy.org - enforced Private Browsing header
http://xpo.x-privacy.org - strict, business orientated no save, copy,
print Private Browsing header
I guess I give up on this list the,
Thank you for your time.
Ehsan Akhgari
>> Let's also think about the pathological case of an ad network serving
>> that header every time it sends a page to the browser embedded in an
>> iframe on another web page. Or alternatively, multiple applications
>> hosted on the same domain, where only one of them requires private
>> browsing mode.
>
>
> Which would do noting if the right to issue X-privacy was only given to
> the domain in the address bar. Firefox then ignores X-privacy for that
> domain if it is in private browsing, but a list would need to be kept
> inside of firefox for the case of "optional" where the user elected not
> to use Private Browsing, otherwise firefox would not ignore it.
Am I missing something? How would the right to issue X-Privacy be given
to only a single domain? I thought that this is something that the
server requires by setting X-Privacy: Optional.
Also, I couldn't tell if your response was to my first or second point
in the quoted paragraph, but I _think_ you're replying to my second point.
>> > It would be logical to assume that on sites where reporting is
>>> abuse is the purpose, that the X-privacy header would be sent on every
>>> page, so that at every entry point either optional or private is
>>> trigger. *but* I've just realised, this is a problem.
>>>
>>> 1) Either the navigator.privateBrowsing object is going to have to be
>>> exposed or the user would be asked on every page opened,
>>> 2) or the session (server side) is going to have to store that the
>>> header has already been sent
>>> 3) the browser ignores the X-privacy header on that domain after being
>>> asked the first time and needs to keep an encrypted list, not accessible
>>> to the browser user, otherwise it would be another history list.
>>
>> The first case is not an option, as I described above. The 3rd case will
>> fail in the case of multiple web applications hosted on the same domain.
>> The second case would work, but it requires the web page to have a
>> notion of the "first time" that the user is visiting it. Existing ways
>> of tracking this information (for example, setting a cookie) are not
>> reliable unfortunately (for example, if the user clears cookies, or does
>> not accept them at all).
>
> case 1) I still fail to see them implications of knowing that someone is
> browsing privately when it is trivial to find out anyway.
You are making the incorrect assumption that it's trivial for a website
to tell whether the user is in private browsing mode or not, and you're
basing your conclusion on that assumption! :-)
> I believe that
> firefox solved the link colour/ history hack recently so all the web
> master needs to do is check the link color to see that history is not
> active and they then know (they use an ajax request to "visit a page"
> embedded in the pages and hidden divs to check link colour).
That's not correct. Currently, no web page can query the link color to
determine whether it's been visited or not, irrespective of private
browsing.
> case 2) easy, session established $_SESSION['SOMEVAR'] = true means
> header was sent. No session, gets sent again. The user would have to
> clear the cookies half way through visiting the site to initiate the
> x-privacy, this is trivial in PHP not even requiring cookies if necessary.
Things like the PHP $_SESSION variable work by sending a cookie to the
browser.
> case 3) see above it could be considered as a safety net though
But it's still going to fail for some web applications.
Cheers,
Ehsan