Gradle dependency versions plugin

Developers often have a lot on their plates, maintaining current version of their library dependencies often takes a back seat to deliverables. Far too often, the only time a library is updated is when it becomes a problem, either as a vulnerability or as a headache that prevents other updates. Monitoring repositories and email lists can also be problematic.

To simplify some of the manual effort that often goes into this, use of build plugins can help. With them, each build, either on the developer desktop or as part of a CI (Continuous Integration) pipeline, can provide feedback to any developer that looks at the output.

Adding to a Gradle project only takes a few small changes:

In build.gradle:

plugins {
  id 'com.github.ben-manes.versions' version '0.51.0'
}

Then to invoke you can use:

./gradlew dependencyUpdates

To simplify for use with make, add to an existing step like ‘test’ in a Makefile like:

.PHONY: test
test: clean
  ./gradlew test dependencyUpdates

 

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:

security.txt files

Similar to robots.txt and humans.txt is a recent addition of a security.txt file. This is currently a draft proposal to provide a standardized way to define security policies for researchers. This is useful for bug bounty and disclosure programs. Government agencies were tasked to add these back in 2019, but COVID-19 likely delayed implementation and rollout.

This is usually applied in the root of a website at /.well-known/security.txt, but can also be immediately in the root at /security.txt. Personally, I put mine in /.well-known/ and put a redirect at the root to simplify maintenance.

For additional security, you can optionally sign the policy with PGP.

Details:

I did some searching around the web and found some examples (linked below):

File in the root path:

File in the preferred /.well-known path:

Some PGP signed examples:

Questionable, though as the files are meant to be read by humans, this would meet the most simple use case:

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

USB Data-Blocker aka USB Condom

I was recently reading Kevin Mitnick’s “The Art of Invisibility” and found that he’d also recommended these devices. I’ve been using them for several years as it was always unnerving to plug in a mobile device into a work computer to recharge only to see that there was a request to mount them. Additionally, my laptop would occasionally want to tether data via my cell phone. In an effort to block data transfer and leakage, something was required. These simple and cheap devices allow for power but no data to be transferred via the USB port.

WARNING: there’s always the possibility that any USB device could be compromised, including these… keep them in sight and under your control at all times.

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: