Clear-Site-Data HTTP Header

In an effort to improve security on the client-side modern browsers have introduced a means to allow for web applications request a client to remove persisted data. Of course, not supported in any version of MSIE or Safari, but all modern browsers Chrome 61+, Edge 79+, Firefox 63+ support.

This approach can be useful at logoff or session invalidation to remove data from the client-side, particularly in cases of persistent or reflected XSS.

Clear-Site-Data: “cookies”
Clear-Site-Data: “cache”, “cookies”, “storage”, “executionContexts”

REFERENCES:

Global Privacy Control (GPC) – Sec-GPC HTTP Header – /.well-known/gpc.json file

GPC is the latest attempt at allowing customers to specify how their browsing data is to be shared online, the previous attempt referred to as DNT was a relative failure.

Like with DNT, once the user specifies their preference the browser adds an additional HTTP request header:
Sec-GPC: 1

This can be checked with javascript on the page with the following
const gpcValue = navigator.globalPrivacyControl

Additionally, websites can define that they respect the GPC request by posting a file in a file /.well-known/gpc.json
Content-Type: application/json
{
"gpc": true,
"version": 1,
"lastUpdate": "2021-11-01"
}

Examples:

GPC is currently implemented by default in:
Brave = https://spreadprivacy.com/global-privacy-control-enabled-by-default/

In Firefox, you currently have to enable it manually:
about:config globalprivacycontrol boolean true

REFERENCES:

SameParty cookie attribute

While Google has made strides to remove cookies, there was a recent addition to the Chromium product upon which Chrome, Safari, and Edge are based.

I saw this written up as the following:

The SameParty attribute takes no value, and requires that the cookie also specify the “Secure” attribute, and not specify “SameSite=Strict”. If either of these constraints is violated, the cookie will be considered invalid, and will not be set. “SameSite=Strict” is not supported because “SameSite=Strict” is intended as a security boundary, rather than a privacy boundary (which First-Party Sets aims to establish). Valid use-cases of “SameSite=Strict” in cross-site contexts should not be loosened even when the sites are same-party.

Better stated…

  • The SameParty attribute is specified without a value (as are Secure and HttpOnly) as ;SameParty;
  • The Secure attribute is required in order to use the SameParty attribute. Any cookie specifying SameParty without Secure will be rejected as invalid.
  • Additionally, any cookie specifying SameParty in the presence of SameSite=Strict will be rejected as invalid.

While I’ve seen this implemented in versions of Chrome 89+, it is not yet adopted in Firefox (and may never be).

References:

Cookie Priority attribute

While Google has made strides toward removing cookies, this new feature was recently added in Chrome 81+ in what appears to be a method for developers to better manage cookie lifespans when the browser client limit is being reached. This value can be seen in the DevTools, it appears that some cookies can be elevated even when the attribute is not specified.

This is added to the cookie string like any other attribute with value:
;Priority=High;

NOTE: this appears to be implemented only in Google Chrome.

References

Google Federated Learning of Cohorts (FLoC) – optout

Google Chrome 89 and other browsers based upon it such as Chromium Edge have introduced a new capability known as FLoC. This approach removes the need for third-party cookies by passing a group identifier in the HTTP Headers in a manner similar to how Cookies are exchanged. While FLoC should allow for users to remain more anonymous as advertisers only receive a group identifier for the user, it would not be difficult to use their IP address or other features available via device fingerprinting to track the individual.

As a web user, you would need to use several approaches to avoid this:
1. Use a browser without FLoC support. Hopefully, this will be added to the configuration menus to allow users to prevent it, similar to DNT.
2. Use a browser plugin (or other software/proxy) to remove the FLoC headers.

As a web-developer, you can add configuration to opt-out of all FLoC cohort calculation by sending the following HTTP response header:


Permissions-Policy: interest-cohort=()

If you really want to see the data, the following javascript will expose it:

const { id, version } = await document.interestCohort();
console.log('FLoC ID:', id);
console.log('FLoC version:', version);

REFERENCES:

Javascript let keyword

ECMAScript 6 (ES2015) added the ‘let’ keyword. let works a lot like the legacy ‘var’ keyword, but adds scoping capabilities.

Unfortunately, support cannot be retrofitted to older browsers with a polyfill, supported by IE11(with limitations), Edge 12+, Firefox 44+, Chrome 49+, Safari 10+. If you still need to support older browsers or devices you may want to stick with var.

REFERENCES:

Javascript const

Formally introduced in ES6, const was introduced in JavaScript 1.5 and was a Mozilla-specific extension and not part of ECMAScript 5.

Unfortunately, support cannot be retrofitted to older browsers with a polyfill, supported by IE11+, Edge 12+, Firefox 36+, Chrome 21+, Safari 5.1+. If you still need to support older browsers or devices you may want to stick with var.

NOTE: some initial implementations may have thrown different exceptions on reassignment, were not limited in scope, or treated const like ‘var‘.

Name may start with letter, underscore or $ character.

REFERENCES:

Enabling HTTP/3 (QUIC) in browsers for improved network performance

Back in 2015, Google introduced SPDY as a method of improving TCP connections. HTTP/3 now improves upon that by removing the blocking of TCP with the use of UDP (QUIC).

Firefox: currently disabled by default in version 85, to enable use about:config and set network.http.http3.enabled = true

IOS Safari 14+: currently disabled by default, but can be enabled under Settings > Safari > Advanced > Experimental Features > HTTP/3

Chrome/Chromium: current versions 88+ are currently implementing by default.

Chromium Edge: as new versions are based upon Chromium, support should follow Chrome.

MSIE: was never and will never be implemented.

REFERENCES:

After a very long run, Adobe Flash is dead!

This was very long overdue for a variety of reasons. While Flash became almost ubiquitous on the web under Macromedia before being acquired by Adobe, it was also full of .
Apple never offered Flash on it’s mobile devices and helped to drive developers to make use of modern HTML5 to accomplish many of the same effects.
Flash “cookies” were buried deep within the application and were not easily removed by users making them very useful for tracking users.

Timeline:

Step Date
End of Life Announced July 25, 2017
End of support December 31, 2020
Flash blocked January 12, 2021

Support:

Browser Blocked Removed
Chrome 76 88
Firefox 69 85
Safari 14

 

Microsoft Silverlight

Silverlight was a browser extension that was backed by Microsoft’s .NET product on many platforms, it provided media capabilities similar to Macromedia/Adobe Flash.  Similar to Flash, it has had it’s own share of security problems over the years.

Introduced in 2007 and currently in a deprecated state. Once supported on Windows XP (IE6) to Windows 10 (IE11), MacOS and Ubuntu. Now only supported in MSIE. Edge never provided support. Modern versions of Chrome, Firefox, Safari, and Opera no longer support.

HTML Markup example:

<object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%">
<param name="source" value="MySilverLightControl.xap"/>
</object>

REFERENCES:

https://en.wikipedia.org/wiki/Microsoft_Silverlight

https://www.microsoft.com/Silverlight/

https://docs.microsoft.com/en-us/previous-versions/windows/silverlight/dotnet-windows-silverlight/mt788654(v=msdn.10)