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:

document.write() Intervention!

The use of document.write() has always been a bad “code smell” in JavaScript. Most web performance guides such as WebPageTest and Yahoo Exception Performance have warned against this practice.

In most cases, document.write() can be replaced by inserting innerHTML into an empty element after the rest of the page loads. This approach also allows the developer to “think” about how the page might react in cases where JavaScript is disabled or not available on the client.

Google has recently changed the default behavior, such that when on a slow (currently 2G) connection, but discussions have also leaned toward including any slow connection.
As such, right now, the following will occur on slow (2G) connections:

  • Chrome 53+ (warning displayed in debugger console)
  • Chrome 55+ (blocked – code will not execute, warning message will appear in debugger console)

For users on slow connections, such as 2G, external scripts dynamically injected via document.write() can delay the display of main page content for tens of seconds, or cause pages to either fail to load or take so long that the user just gives up. Based on instrumentation in Chrome, we’ve learned that pages featuring third-party scripts inserted via document.write() are typically twice as slow to load than other pages on 2G.


My advice – remove all use of document.write() for required content in your code now, as your users MAY NOT see that content if you do not.

REFERENCES:

Defining word-break and word-wrap in CSS

I recently found a case where WebKit (Chromium, and Safari) was acting as if ‘overflow-x:visible;‘ was set in cases where text could not be wrapped inside a DIV due to a lack of spaces or hyphenation as it was a java stack trace. In this case I had to explicitly set the ‘word-wrap:break-word;‘ attribute for the problematic DIV.


.breakword { word-wrap: break-word; }

Also, for Unicode languages where there are other rules to complex to describe here…

.wordbreak { word-break: keep-all; }