Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[Ehsan Akhgari]

*Summary*: As part of the anti-tracking project, we'd like to experiment
with a new feature in order to mitigate the impact of third-party tracking
scripts running in top-level documents.  As we are planning to start
removing the storage capabilities of third-party trackers, which removes
their ability to store unique identifiers for each client in cookies which
would be transmitted to servers across websites, a number of cross-site
trackers have started to switch to using first-party cookies to store their
unique identifiers.  The way that this works typically is through
annotating outbound links to the target website with a unique query string
parameter, and then reading and storing that unique parameter in the
first-party cookie storage through the third-party scripts that they
control which are running in the context of the top-level target site when
the user follows such a link.

This is bad because it would allow cross-site trackers to keep tracking the
user through a unique identifier, but it would also expose the unique
identifier used by tracker1 to all of the other trackers that have active
code running on the page, which would allow them to sync up each others'
tracking identifiers without resorting to practices such as cookie syncing <
https://clearcode.cc/blog/cookie-syncing/>.

We'd like to experiment with imposing a short maximum life-time on cookies
set through document.cookie in order to ensure that these unique
identifiers would expire relatively quickly once they are established, and
wouldn't allow cross-site trackers to establish a pervasive permanent
unique identifier.  We're picking seven days to be compatible with Safari
which has been shipping this for a while now <
https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/>.

*Bug*: This was implemented originally in (disabled by default)
https://bugzilla.mozilla.org/show_bug.cgi?id=1529836.  The bug to enable
this on Nightly is https://bugzilla.mozilla.org/show_bug.cgi?id=1533584.
*Link to standard*: No public standard change has been made for this
feature yet.  We should modify the cookie RFC when we know more about
whether we would like to ship this change or not given that we would be the
second web engine doing so.
*Platform coverage*: where will this be available? Everywhere.
*Estimated or target release*: in which version do you want to/plan to
release this? Getting enabled in Nightly in 67, staying Nightly only for
now in order to collect some early feedback.  No estimated target release
available yet since this is an early exploration.
*Preference behind which this will be implemented*: if applicable, how can
interested parties test this before it ships pref'd on by default? The
preference for this feature, available in Nightly right now, is
privacy.documentCookies.maxage.  The value of this pref is the maximum
life-time cap in seconds.  A value of 0 would disable enforcing a cap (0 is
the current default.)
*Is this feature enabled by default in sandboxed iframes?* If not, is there
a proposed sandbox flag to enable it? If allowed, does it preserve the
current invariants in terms of what sandboxed iframes can do? I'm proposing
to enable this feature in sandboxed iframes by default.  It will preserve
the current invariants.
*DevTools bug*: No specific bug, since devtools already supports showing
the expiry date of cookies and once this feature gets enabled it will
correctly display the expiry date for those cookies where Firefox would
enforce this cap on.
*Do other browser engines implement this?* Answer with: Safari shipped
(since version 12.0.x, tested in 12.0.3, announced as part of ITP 2.1
recently: ).

*web-platform-tests*: This is an intervention which different engines do
not agree on yet.  Creating a web-platform-test for it would be very simple
but it will be failing in the engines that do not agree with the
intervention.  I'm not sure what the recommendation for testing these types
of changes is, would be happy to submit a test if there is a path for
getting them accepted into wpt.

*Is this feature restricted to secure contexts?* It is not.  This is an
intervention which is trying to protect the user's privacy, and we would
like to ensure the protections would be applicable to non-secure contexts
as well.  Arguably these protections are even more important for non-secure
contexts given the fact that cookies set through document.cookie would be
visible to network MITM attackers after that point.

Here are the answers to a few other questions which you may have on your
mind regarding this proposed change.

*Would this change cause people to get logged out of services?* We believe
the answer to that should be no, at least for services with secure logins.
Authentication cookies should be marked as Secure and HttpOnly, and if
they're set through document.cookie they can't be HttpOnly by default and
are therefore vulnerable to XSS attacks.  There

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[zan]

On Fri, Mar 8, 2019, at 1:31 AM, Ehsan Akhgari wrote:
> *Summary*: As part of the anti-tracking project, we'd like to experiment
> with a new feature in order to mitigate the impact of third-party tracking
> scripts running in top-level documents.  As we are planning to start
> removing the storage capabilities of third-party trackers, which removes
> their ability to store unique identifiers for each client in cookies which
> would be transmitted to servers across websites, a number of cross-site
> trackers have started to switch to using first-party cookies to store their
> unique identifiers.  The way that this works typically is through
> annotating outbound links to the target website with a unique query string
> parameter, and then reading and storing that unique parameter in the
> first-party cookie storage through the third-party scripts that they
> control which are running in the context of the top-level target site when
> the user follows such a link.
> 
> This is bad because it would allow cross-site trackers to keep tracking the
> user through a unique identifier, but it would also expose the unique
> identifier used by tracker1 to all of the other trackers that have active
> code running on the page, which would allow them to sync up each others'
> tracking identifiers without resorting to practices such as cookie syncing <
> https://clearcode.cc/blog/cookie-syncing/>.
> 
> We'd like to experiment with imposing a short maximum life-time on cookies
> set through document.cookie in order to ensure that these unique
> identifiers would expire relatively quickly once they are established, and
> wouldn't allow cross-site trackers to establish a pervasive permanent
> unique identifier.  We're picking seven days to be compatible with Safari
> which has been shipping this for a while now <
> https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/>.
> 
> *Bug*: This was implemented originally in (disabled by default)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1529836.  The bug to enable
> this on Nightly is https://bugzilla.mozilla.org/show_bug.cgi?id=1533584.
> *Link to standard*: No public standard change has been made for this
> feature yet.  We should modify the cookie RFC when we know more about
> whether we would like to ship this change or not given that we would be the
> second web engine doing so.
> *Platform coverage*: where will this be available? Everywhere.
> *Estimated or target release*: in which version do you want to/plan to
> release this? Getting enabled in Nightly in 67, staying Nightly only for
> now in order to collect some early feedback.  No estimated target release
> available yet since this is an early exploration.
> *Preference behind which this will be implemented*: if applicable, how can
> interested parties test this before it ships pref'd on by default? The
> preference for this feature, available in Nightly right now, is
> privacy.documentCookies.maxage.  The value of this pref is the maximum
> life-time cap in seconds.  A value of 0 would disable enforcing a cap (0 is
> the current default.)
> *Is this feature enabled by default in sandboxed iframes?* If not, is there
> a proposed sandbox flag to enable it? If allowed, does it preserve the
> current invariants in terms of what sandboxed iframes can do? I'm proposing
> to enable this feature in sandboxed iframes by default.  It will preserve
> the current invariants.
> *DevTools bug*: No specific bug, since devtools already supports showing
> the expiry date of cookies and once this feature gets enabled it will
> correctly display the expiry date for those cookies where Firefox would
> enforce this cap on.
> *Do other browser engines implement this?* Answer with: Safari shipped
> (since version 12.0.x, tested in 12.0.3, announced as part of ITP 2.1
> recently:  >).
> 
> *web-platform-tests*: This is an intervention which different engines do
> not agree on yet.  Creating a web-platform-test for it would be very simple
> but it will be failing in the engines that do not agree with the
> intervention.  I'm not sure what the recommendation for testing these types
> of changes is, would be happy to submit a test if there is a path for
> getting them accepted into wpt.
> 
> *Is this feature restricted to secure contexts?* It is not.  This is an
> intervention which is trying to protect the user's privacy, and we would
> like to ensure the protections would be applicable to non-secure contexts
> as well.  Arguably these protections are even more important for non-secure
> contexts given the fact that cookies set through document.cookie would be
> visible to network MITM attackers after that point.
> 
> Here are the answers to a few other questions which you may have on your
> mind regarding this proposed change.
> 
> *Would this change cause people to get logged out of services?* We believe
> the answer to that should be no, at least for serv

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[zan]

Apologies, this was the outcome of a poor FastMail mobile UI interaction.

On Fri, Mar 8, 2019, at 9:48 AM, z...@falconsigh.net wrote:
> 
> 
> On Fri, Mar 8, 2019, at 1:31 AM, Ehsan Akhgari wrote:
> > *Summary*: As part of the anti-tracking project, we'd like to experiment
> > with a new feature in order to mitigate the impact of third-party tracking
> > scripts running in top-level documents.  As we are planning to start
> > removing the storage capabilities of third-party trackers, which removes
> > their ability to store unique identifiers for each client in cookies which
> > would be transmitted to servers across websites, a number of cross-site
> > trackers have started to switch to using first-party cookies to store their
> > unique identifiers.  The way that this works typically is through
> > annotating outbound links to the target website with a unique query string
> > parameter, and then reading and storing that unique parameter in the
> > first-party cookie storage through the third-party scripts that they
> > control which are running in the context of the top-level target site when
> > the user follows such a link.
> > 
> > This is bad because it would allow cross-site trackers to keep tracking the
> > user through a unique identifier, but it would also expose the unique
> > identifier used by tracker1 to all of the other trackers that have active
> > code running on the page, which would allow them to sync up each others'
> > tracking identifiers without resorting to practices such as cookie syncing <
> > https://clearcode.cc/blog/cookie-syncing/>.
> > 
> > We'd like to experiment with imposing a short maximum life-time on cookies
> > set through document.cookie in order to ensure that these unique
> > identifiers would expire relatively quickly once they are established, and
> > wouldn't allow cross-site trackers to establish a pervasive permanent
> > unique identifier.  We're picking seven days to be compatible with Safari
> > which has been shipping this for a while now <
> > https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/>.
> > 
> > *Bug*: This was implemented originally in (disabled by default)
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1529836.  The bug to enable
> > this on Nightly is https://bugzilla.mozilla.org/show_bug.cgi?id=1533584.
> > *Link to standard*: No public standard change has been made for this
> > feature yet.  We should modify the cookie RFC when we know more about
> > whether we would like to ship this change or not given that we would be the
> > second web engine doing so.
> > *Platform coverage*: where will this be available? Everywhere.
> > *Estimated or target release*: in which version do you want to/plan to
> > release this? Getting enabled in Nightly in 67, staying Nightly only for
> > now in order to collect some early feedback.  No estimated target release
> > available yet since this is an early exploration.
> > *Preference behind which this will be implemented*: if applicable, how can
> > interested parties test this before it ships pref'd on by default? The
> > preference for this feature, available in Nightly right now, is
> > privacy.documentCookies.maxage.  The value of this pref is the maximum
> > life-time cap in seconds.  A value of 0 would disable enforcing a cap (0 is
> > the current default.)
> > *Is this feature enabled by default in sandboxed iframes?* If not, is there
> > a proposed sandbox flag to enable it? If allowed, does it preserve the
> > current invariants in terms of what sandboxed iframes can do? I'm proposing
> > to enable this feature in sandboxed iframes by default.  It will preserve
> > the current invariants.
> > *DevTools bug*: No specific bug, since devtools already supports showing
> > the expiry date of cookies and once this feature gets enabled it will
> > correctly display the expiry date for those cookies where Firefox would
> > enforce this cap on.
> > *Do other browser engines implement this?* Answer with: Safari shipped
> > (since version 12.0.x, tested in 12.0.3, announced as part of ITP 2.1
> > recently:  > >).
> > 
> > *web-platform-tests*: This is an intervention which different engines do
> > not agree on yet.  Creating a web-platform-test for it would be very simple
> > but it will be failing in the engines that do not agree with the
> > intervention.  I'm not sure what the recommendation for testing these types
> > of changes is, would be happy to submit a test if there is a path for
> > getting them accepted into wpt.
> > 
> > *Is this feature restricted to secure contexts?* It is not.  This is an
> > intervention which is trying to protect the user's privacy, and we would
> > like to ensure the protections would be applicable to non-secure contexts
> > as well.  Arguably these protections are even more important for non-secure
> > contexts given the fact that cookies set through document.cookie would be
> > visible to ne

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[Boris Zbarsky]

On 3/7/19 7:31 PM, Ehsan Akhgari wrote:

*web-platform-tests*: This is an intervention which different engines do
not agree on yet.  Creating a web-platform-test for it would be very simple
but it will be failing in the engines that do not agree with the
intervention.  I'm not sure what the recommendation for testing these types
of changes is, would be happy to submit a test if there is a path for
getting them accepted into wpt.


Other vendors have been landing tests with ".tentative" as the last part 
of the filename before the suffixes the test harness expects (so e.g. 
"web-locks/mode-shared.tentative.https.any.js").


I think doing that here is fine; we may want the tests or the commit 
message involved to point to an explainer or something tracking the need 
for a spec change or something like that...


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[James Graham]

On 08/03/2019 15:06, Boris Zbarsky wrote:

On 3/7/19 7:31 PM, Ehsan Akhgari wrote:

*web-platform-tests*: This is an intervention which different engines do
not agree on yet.  Creating a web-platform-test for it would be very 
simple

but it will be failing in the engines that do not agree with the
intervention.  I'm not sure what the recommendation for testing these 
types

of changes is, would be happy to submit a test if there is a path for
getting them accepted into wpt.


Other vendors have been landing tests with ".tentative" as the last part 
of the filename before the suffixes the test harness expects (so e.g. 
"web-locks/mode-shared.tentative.https.any.js").


I think doing that here is fine; we may want the tests or the commit 
message involved to point to an explainer or something tracking the need 
for a spec change or something like that...


Yes, this seems correct to me too; a .tentative. test is the right way 
to land a test for something that isn't yet standardised, and it should 
somehow link to the relevant discussion but there isn't an explicit 
convention for how that should happen (commit message vs comment vs link 
element, for example). See the end of [1] for the documentation.


[1] https://web-platform-tests.org/writing-tests/file-names.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[Ehsan Akhgari]

On Fri, Mar 8, 2019 at 11:54 AM James Graham  wrote:

> On 08/03/2019 15:06, Boris Zbarsky wrote:
> > On 3/7/19 7:31 PM, Ehsan Akhgari wrote:
> >> *web-platform-tests*: This is an intervention which different engines do
> >> not agree on yet.  Creating a web-platform-test for it would be very
> >> simple
> >> but it will be failing in the engines that do not agree with the
> >> intervention.  I'm not sure what the recommendation for testing these
> >> types
> >> of changes is, would be happy to submit a test if there is a path for
> >> getting them accepted into wpt.
> >
> > Other vendors have been landing tests with ".tentative" as the last part
> > of the filename before the suffixes the test harness expects (so e.g.
> > "web-locks/mode-shared.tentative.https.any.js").
> >
> > I think doing that here is fine; we may want the tests or the commit
> > message involved to point to an explainer or something tracking the need
> > for a spec change or something like that...
>
> Yes, this seems correct to me too; a .tentative. test is the right way
> to land a test for something that isn't yet standardised, and it should
> somehow link to the relevant discussion but there isn't an explicit
> convention for how that should happen (commit message vs comment vs link
> element, for example). See the end of [1] for the documentation.
>

Thanks for the suggestion, sounds good.  I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1533827 to track this.

-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[Ehsan Akhgari]

On Thu, Mar 7, 2019 at 7:31 PM Ehsan Akhgari 
wrote:

> *Estimated or target release*: in which version do you want to/plan to
> release this? Getting enabled in Nightly in 67, staying Nightly only for
> now in order to collect some early feedback.  No estimated target release
> available yet since this is an early exploration.
>
Minor correction, in order to avoid conflicting with the soft freeze I will
hold off to enable this in the beginning of the next cycle.

Thanks,
-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[olivier . vit]

Hi

Sorry but I don't read the webkit.org blog post in the same way
https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/

"The **beta** releases of iOS 12.2 and Safari 12.1 on macOS High Sierra and 
Mojave include an updated version of Intelligent Tracking Prevention (ITP). For 
purposes of developer communication, we’ll refer to it as ITP 2.1."

=> this is being shipped in **beta** version of Safari 12.1 and iOS 12.2, this 
is not announced as part of Safari 12.0.3 which looks to be a security update 
only https://support.apple.com/en-us/HT209449 

https://developer.apple.com/documentation/safari_release_notes/safari_12_1_beta_3_release_notes

https://developer.apple.com/documentation/ios_release_notes/ios_12_2_beta_6_release_notes

then this is not live yet in a fully released product
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[Ehsan Akhgari]

On Tue, Mar 19, 2019, 6:15 PM ,  wrote:

> Hi
>
> Sorry but I don't read the webkit.org blog post in the same way
> https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/
>
> "The **beta** releases of iOS 12.2 and Safari 12.1 on macOS High Sierra
> and Mojave include an updated version of Intelligent Tracking Prevention
> (ITP). For purposes of developer communication, we’ll refer to it as ITP
> 2.1."
>
> => this is being shipped in **beta** version of Safari 12.1 and iOS 12.2,
> this is not announced as part of Safari 12.0.3 which looks to be a security
> update only https://support.apple.com/en-us/HT209449
>
>
> https://developer.apple.com/documentation/safari_release_notes/safari_12_1_beta_3_release_notes
>
>
> https://developer.apple.com/documentation/ios_release_notes/ios_12_2_beta_6_release_notes
>
> then this is not live yet in a fully released product
>

Hi Olivier,

What I said in my email was based on manually testing that version of
Safari on a macOS machine. You're welcome to give it a test yourself. Not
sure about the reason behind the discrepancy with the blog post.

Cheers,
Ehsan

___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[olivier . vit]

Hi Ehsan,

Thanks for the follow up.
I don't have access to a macOS computer with that 12.0.3 version of Safari

On the other hand I have access to Google Analytics data for multiple sites, 
not the top 100 Alexa, but I don't see any evidence of a shift introduced by 
Safari 12.0.3 , for example through an increase in the share of new visitors 
with that version

See that example https://photos.app.goo.gl/FTJoDLsYiJ17SPY46 

The Mozilla organization probably has access to similar data.

Instrumentation could also be a good option to assess the impact of such type 
of change.

What I don't get is what is the assessment process in place to understand how 
such a change will be circumvented. Because it will. As many of the previous 
changes put in place by Safari ITP initiative.

And the impact on the digital advertising ecosystem. The biggest ad networks 
might suffer. But will provide solutions, estimates, alternatives... And most 
of the smaller networks, with less agility, less money and resources, less 
skills, may break, get sold to the biggest, may close.

Is the goal of this change really to enforce the role of the largest ad 
networks ? Why not. They tend to honor laws more likely than others...

Questioning anyway...

This no just a technical decision about a web browser dropping an internet 
standard.

What do you think ?
What does the community thinks ?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[Ehsan Akhgari]

On Fri, Mar 22, 2019 at 1:55 PM  wrote:

> Hi Ehsan,
>
> Thanks for the follow up.
> I don't have access to a macOS computer with that 12.0.3 version of Safari
>
> On the other hand I have access to Google Analytics data for multiple
> sites, not the top 100 Alexa, but I don't see any evidence of a shift
> introduced by Safari 12.0.3 , for example through an increase in the share
> of new visitors with that version
>
> See that example https://photos.app.goo.gl/FTJoDLsYiJ17SPY46
>
> The Mozilla organization probably has access to similar data.
>
> Instrumentation could also be a good option to assess the impact of such
> type of change.
>

See
https://developers.google.com/analytics/devguides/collection/analyticsjs/cookie-usage#analyticsjs.
Google Analytics relies on two user identifier cookies, one expiring in 24
hours and one expiring in 2 years.  I'm not sure how the two identifiers
are linked together but it seems that they already treat repeat visitors
who come back to the site in less than 24 hours in a special way.  That may
explain why you haven't seen any impact as a result of this change.


> What I don't get is what is the assessment process in place to understand
> how such a change will be circumvented. Because it will. As many of the
> previous changes put in place by Safari ITP initiative.
>
> And the impact on the digital advertising ecosystem. The biggest ad
> networks might suffer. But will provide solutions, estimates,
> alternatives... And most of the smaller networks, with less agility, less
> money and resources, less skills, may break, get sold to the biggest, may
> close.
>

I'm not sure why you think this change will affect companies of different
sizes in a different way.  That is a strange proposition.

If you have any concrete worries please do share and I will be happy to
discuss.  Vague concerns like this usually read like the fear of the
unknown and are usually not helpful for having a productive discussion.


> Is the goal of this change really to enforce the role of the largest ad
> networks ? Why not. They tend to honor laws more likely than others...
>

It is not.  The goal of this change is to ensure that third-party scripts,
when running in the context of a top-level site, cannot abuse its cookie
jar to store cookies that can uniquely identify visitors and can be used to
keep a record of their browsing history across websites.  This change
achieves the goal by ensuring that such identifiers, once stored in the
top-level site's cookie jar, will expire in one week maximum, and therefore
the risk of the user being tracked by the companies that serve those
third-party scripts will be restricted to that window of time.


> Questioning anyway...
>
> This no just a technical decision about a web browser dropping an internet
> standard.
>
> What do you think ?
> What does the community thinks ?
>

If you have more feedback to share, this is the right place.  I would
recommend to keep the discussion focused on concrete technical issues
please and avoid FUD (
https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt) through
referencing claims such as dropping an internet standard or enforcing the
role of certain companies.  I would love to continue to have a discussion
around the technical merits of this feature.

Thanks,
-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[olivier . vit]

Hi,

I know Google Analytics very well, only the _ga cookie is used to recognize a 
web browser across visits.

If this is the right place to discuss this change, I'm surprised there is so 
few people participating regarding the impact of such a change on the internet 
ad ecosystem.

You don't take the point about how ITP has been circumvented so far by the 
large ad networks.
Google Ads, Facebook Ads and Bings Ads have deployed huge human ressources, 
have updated their ad delivery and tracking systems to be in a situation where 
they keep tracking ad conversion but some have lost capabilities in remarketing 
/ targeting the proper audience.

Give 3 names in the smaller ad networks that have done similar changes to adapt 
their technologies and platforms !
Even Criteo didn't update its tracking.

Here is an article in French that explores that point with more facts
https://www.journaldunet.com/ebusiness/publicite/1422902-apple-est-il-en-train-de-tuer-la-pub-web-sur-mobile/

Of course today there are abusive usage of cookies, cross domain cookie 
tracking, cookie sync operations, obscur third party data sharing with partners 
who are not identified, that don't get user consent, nor advertiser consent.

I don't see a chance of stopping these without:
- better legal rules where ad networks are responsible, not just advertisers or 
inventory providers
- a common standard implemented in every modern web browser that allows to 
control which data is exposed to which tag / resource

The patch you propose sounds to me like a try and error change.
But it forgets completely to study the impact on user experience and on the ad 
ecosystem.
I'm not a fan of advertising, but it fuels lots of money into internet content, 
services and technologies. Without ads, many sides of internet as we know it 
will collapse and disappear.

Better governance is needed. Experiments without clear problem statement and 
solution design can be disastrous.

Another good read, in English
https://www.fastcompany.com/90308068/how-the-tragic-death-of-do-not-track-ruined-the-web-for-everyone
 

PS: I see no evidence that the Safari 12.1 that has been released eventually 
incorporates ITP 2.1 as described in beta

Safari
https://support.apple.com/en-us/HT209603
iOS
https://developer.apple.com/documentation/ios_release_notes/ios_12_2_release_notes
 
OSX
https://developer.apple.com/documentation/macos_release_notes/macos_mojave_10_14_4_release_notes
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[Ehsan Akhgari]

On Tue, Apr 2, 2019 at 6:25 AM  wrote:

> Hi,
>
> I know Google Analytics very well, only the _ga cookie is used to
> recognize a web browser across visits.
>

Great, thanks for confirming this.  So based on the data you cited before
it looks like this change hasn't made any significant impact on GA output
for Safari, so we should expect the same for Firefox.  That is good news.


> If this is the right place to discuss this change, I'm surprised there is
> so few people participating regarding the impact of such a change on the
> internet ad ecosystem.
>

This is the right place.


> You don't take the point about how ITP has been circumvented so far by the
> large ad networks.
> Google Ads, Facebook Ads and Bings Ads have deployed huge human
> ressources, have updated their ad delivery and tracking systems to be in a
> situation where they keep tracking ad conversion but some have lost
> capabilities in remarketing / targeting the proper audience.
>

Yes, I am aware of some of those efforts you're alluding to.  I won't get
into the details since that involves discussing the business of other
companies.


> Give 3 names in the smaller ad networks that have done similar changes to
> adapt their technologies and platforms !
> Even Criteo didn't update its tracking.
>
> Here is an article in French that explores that point with more facts
>
> https://www.journaldunet.com/ebusiness/publicite/1422902-apple-est-il-en-train-de-tuer-la-pub-web-sur-mobile/
>
> Of course today there are abusive usage of cookies, cross domain cookie
> tracking, cookie sync operations, obscur third party data sharing with
> partners who are not identified, that don't get user consent, nor
> advertiser consent.
>
> I don't see a chance of stopping these without:
> - better legal rules where ad networks are responsible, not just
> advertisers or inventory providers
> - a common standard implemented in every modern web browser that allows to
> control which data is exposed to which tag / resource
>

The second avenue of efforts is what we are working towards here.  I agree
with you that a complete solution probably would include other
non-technical measures but that's beyond my expertise.


> The patch you propose sounds to me like a try and error change.
> But it forgets completely to study the impact on user experience and on
> the ad ecosystem.
> I'm not a fan of advertising, but it fuels lots of money into internet
> content, services and technologies. Without ads, many sides of internet as
> we know it will collapse and disappear.
>

In the interest of having a productive conversation, I will ignore the
unfounded assertions you're making about our efforts here.

Can you please clarify what exact impacts on user experience and on the ad
ecosystem you are worried about as a result of this change?

>
> Better governance is needed. Experiments without clear problem statement
> and solution design can be disastrous.
>
> Another good read, in English
>
> https://www.fastcompany.com/90308068/how-the-tragic-death-of-do-not-track-ruined-the-web-for-everyone
>

Another topic which has absolutely nothing to do with the topic under
discussion.  :-)  No matter how many off topic issues you link to, the only
issue that I am interested to discuss in this thread is changing the
maximum lifetime cap of cookies set through document.cookie to seven days
in Firefox Nightly.


> PS: I see no evidence that the Safari 12.1 that has been released
> eventually incorporates ITP 2.1 as described in beta
>

If you're looking for evidence, may I suggest testing the lifetime of
cookies in that version of Safari?

Cheers,
-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[alex . asigno]

Hi, is there an expected date for the cookie change to go to production?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

[Ehsan Akhgari]

On Wed, Apr 3, 2019 at 7:15 PM  wrote:

> Hi, is there an expected date for the cookie change to go to production?
>

No, this is only an experiment turned on for Firefox Nightly at this
point.  You can watch this mailing list for future updates as we make
future plans about it going forward.


> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>


-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform