Tag: browser

Use of lower-case HTML5 DOCTYPE as a network micro-optimization

TLDR; using lowercase in markup improves the compression as the dictionary for the algorithm will be smaller. Most HTML/JS/CSS is case insensitive and can be optimized as lowercase.

micro-optimizations can be fun… or an utter pain.

I’ve been on both sides of this debate at times, at one time had sub-second SLA’s for a web based customer service app that ran out of a UK data-center with users in South America.

This helped build a thorough understanding of how to best use the browser cache, progressive page loading, and optimization of image and network compression.

Webserver extensions like Google mod_pagespeed definitely help automate some of this stuff on the output, but nothing is ever robust as just building the application with performance in mind.

As a java shop (at that time), JSP exposes a lot of config to eliminate white-space in generated output, that often saved up to several K per page. I’m always amazed when I find large companies that still do not utilize those features, as “bandwidth is cheap” for the provider… but not always for the end user.

REFERENCES:

Replacing Google Fonts with Bunny Fonts for GDPR compliance

Google is “free” for users as it is actively collecting and selling their user activity. There are some small steps you can take to better protect your customers/users from this tracking. One small step you can take is to use a different source for fonts. While it’s technically feasible to self-host fonts, it’s often best to use an external party to leverage their CDN and the users browser cache for improved performance.

The Bunny Fonts API was designed to be fully compatible with the Google Fonts CSS v1 API, making the switch as easy as changing the hostname.

Simply swap “https://fonts.bunny.net/css” in place of “https://fonts.googleapis.com/css” on your website’s source code and let your users enjoy better privacy.

If you’ve implemented Content-Security-Policy (CSP) HTTP Headers in your application, you will also need a variation of the following:

font-src https://fonts.bunny.net/; style-src https://fonts.bunny.net/css;

REFERENCES:

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: