*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: <https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/
>).

*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.  Therefore we hope that most
services people log in to would already set their authentication cookies
through a secure HTTP response and would therefore be unaffected.

*Would this change cause people to see more EU cookie dialogs?*
Potentially, yes.  We've looked at a few such sites which show such banners
to see how they remember that the user has dismissed the dialog.  Many of
them seem to set a cookie on an HTTP response so should be unaffected by
this change.  Some, however, do set a cookie using document.cookie and
would therefore be probably affected, but it's unclear how widespread this
problem would be.  One of the reasons for enabling this feature on Nightly
is to get some early feedback on qualitative issues like this.

Please let me know if you have any questions or concerns.

Thanks,
--
Ehsan

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

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

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

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

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

--
Ehsan

On Thu, Mar 7, 2019 at 7:31 PM Ehsan Akhgari <ehsan....@gmail.com>
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

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,

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 ?

On Fri, Mar 22, 2019 at 1:55 PM <olivi...@gmail.com> 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

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

On Tue, Apr 2, 2019 at 6:25 AM <olivi...@gmail.com> 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

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

On Wed, Apr 3, 2019 at 7:15 PM <alex....@blue449.com> 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-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

--
Ehsan