Changelog

• The 2.0 desktop recording client will now rely on the browser specific API (window. isSecureContext) to determine if it is run in a secure context or not. This means it will consider more origins/contexts as secure including file:// and subdomains of localhost. We’ve also added a new docs section on the topic.

• Firefox will now show a red microphone icon when the user revokes any of the mic or cam permissions.

We realized the internal logs retention period (basically 30 days 31 days inclusive of today) for our storage, webhooks, and getUserMedia() logs was not immediately obvious. So, we added it to many relevant locations in the account dashboard and documentation.

A new WordPress plugin with minor updates is now available as version 1.0.1 . You can read more about it in the documentation.

We’ve updated the desktop recording client with a new multi-bar microphone input animation that reflects audio frequencies in real-time, replacing the single-bar design. In audio-only mode, additional bars are displayed in the video area. The animation is sensitive enough to detect subtle sounds, helping users identify and troubleshoot low or missing microphone input before recording. You can read more about it in the official blog post.

The 2.0 desktop recording client now includes several outlines for better positioning your head & body during video recordings. The feature can be turned on by setting the new embed code option outline to one of the following values:

• face (face outline)
• dotted face (dotted version)
• avatar (full torso outline)

The zoom of the outline can be adjusted by using the outlinezoom embed code option that takes values from 1 to 100 (1% - 100%). The default value is 60 (meaning 60%).

The opacity of the outline is currently fixed at 50% and the color is white.

Read more about it in this blog post.

Starting today, expired trial accounts will have access to most dashboard pages:

• recordings page
• S3, (S)FTP, FTPS & Dropbox pages
• environments, webhooks, logs, etc.

Until now, access was allowed only to account management pages.

All the buttons in the account dashboard that make a request and wait for a response now have a working state with a relevant label and animation.

The webhook page in the account dashboard received several updates:

1. creation time and last modified time are shown, when available, in your account’s timezone
2. pagination has been added, 50 webhooks per page
3. refactored the View Schedule, View Logs, Simulator, and Settings buttons into links (they were links all along)

A new npm package called @addpipe/react-pipe-media-recorder is now available. This package simplifies the integration of the Pipe recorder into React applications by streamlining the setup process, making it faster and more straightforward to embed Pipe’s recording client within React projects.

For more details, check out our blog post and the official NPM page.

Our latest build includes styling updates to ensure consistent appearance across various style libraries, such as Tailwind and Bootstrap.

You can now control what PII data Pipe will collect and store together with each recording:

1. Camera name
2. Microphone name
3. Referer (via window.location)
4. User agent header
5. IPv4

By default, Pipe collects all of it.

You can access this new setting by editing any of your existing environments or when creating a new environment.

For this setting to work correctly for the referer, camera name and microphone name, you need to use the latest version of the 2.0 recording client (pipe.js hosted by us). If, for some reason, you’re self-hosting pipe.js, you need the 21st of October 2024 release or newer.

For a more in-depth look at the feature, read the blog post.

Today, we are launching a new recording region: Canada or CA1 for short.

You can select this new region when creating a new environment or by editing an already existing environment from your account dashboard.

CA1 region details:

• region is opt-in for now
• recordings will be made and processed against servers located in Toronto hosted with DigitalOcean
• If you choose to store the recordings on Pipe’s complimentary storage, the recordings will be stored in an Amazon S3 bucket located in Montreal.
• webhooks will be fired, and recordings will be pushed to your storage from the IP 165.227.38.98
• Amazon S3 bucket storage link example: https://ca1-addpipe.s3.ca-central-1.amazonaws.com/ACCOUNT_HASH/RECORDING_NAME.EXTENSION
• recordings made against this region will be labeled with ca1

le: blog post is available with more details

We have improved how the desktop recording client responds to situations where audio or video data becomes unavailable.

This can occur, for example:

1. on Firefox when the user clears previously granted permissions
2. on Chrome when the user resets previously granted permissions
3. on Chrome when a computer goes into sleep mode while the desktop recording client has access to the camera and/or microphone.

With this update:

1. The recording process will automatically stop if both audio and video data captured are no longer available during a recording.
2. If only audio is being recorded, the recording process will stop if the audio data becomes unavailable.
3. If data becomes unavailable while the recording client is idle, the desktop recording client will automatically request permissions again when the user attempts to start a new recording.

A new WordPress plugin called “Pipe Recorder” is now available.

The plugin makes the integration process much easier and straight forward.

You’ll find more information in the blog post.

There’s also a new documentation section that covers it.

We resolved an issue where, while recording, oversized chunks (recording slices) were created by the browser, but, because of their size, they were refused by our ingestion servers. This caused the desktop recording client to fall into a re-connection loop and the oversized chunk and further chunks were never received by the server.

We implemented a new client side mechanism to split these huge chunks - that exceed the maximum size we accept on the ingestion server - into smaller pieces before sending them to our ingestion servers.

Generating such a large recording chunk was a very rare issue. Even though it happened on vanilla browsers (Chrome on Windows, Chrome on Andorid, etc.) we were only able to replicate it and find the root cause (a browser bug) on Safari on macOS/iOS.

le: we were also able to generate large chunks on:

1. Chrome on Android by locking the screen while recording: large chunk is generated when you unlock the phone
2. Chrome on macOS/Windows by entering sleep mode: large chunk is generated when you stop the recording

We also wrote a blog post on the subject.

Every webhook payload now additionally contains the environment code of the environment in which the recording was made. It can be retrieved using the new envCode attribute.

The environment code is the unique alphanumeric string identifier of the environment. You can find this value in your Pipe account dashboard in the environment settings.

We resolved an issue where the “timeout” message appeared in the Recording Client on very slow internet connections, causing it to become unresponsive with no further reconnection attempts. Now, if a disconnection occurs, the Recording Client will automatically attempt to reconnect up to 30 times.

A new embed code option called hidesave has been added to the 2.0 Recording Client. When set to 1, it hides the save button that appears when autosave (asv) is disabled (asv = 0). The default value of hidesave is 0.

Previously, when autosave was disabled, a save button was visible by default without the possibility of hiding it. Now, the save button will still be visible when disabling autosave, but it can also be hidden by setting hidesave to 1.

If both autosave (asv = 1) and hide save (hidesave = 1) are enabled, the recording still saves automatically as usual.

In the dashboard, under /recordings, we’ve fixed the date filter so that:

1. it allows you to show the recordings from just 1 day
2. when selecting an interval, the recordings from the last day of the interval will also be shown

In the dashboard, under /recordings:

1. JSON payloads don’t break all the payload buttons on the page and show up correctly in the modal
2. White space characters (spaces, tabs, newlines, etc.) in payloads are now visible in the payload modal. Previously, such characters collapsed into one space.

We have updated our audio processing pipeline for our inline recording client by switching from ScriptProcessorNode to AudioWorkletNode. This change was necessary as ScriptProcessorNode is deprecated and might no longer be supported in future browser versions.

This change also bumps up the browser requirements for our inline recording client:

• 💻 On Desktop Devices:
  • From Chrome 63+ to Chrome 66+
  • From Firefox 52+ to Firefox 76+
  • From Safari 14.0.2+ to Safari 14.1+
• 📱 On Mobile Devices:
  • From Chrome 63+ to Chrome 66+
  • From Safari on iOS/iPadOS 14.3+ to Safari on iOS/iPadOS 14.5+

We’ve implemented a new password policy.

It is now mandatory that all new Pipe account passwords respect the following:

• have at least 8 characters in length
• have at least 1 lowercase character
• have at least 1 uppercase character
• have at least 1 number
• have at least 1 special character

This new policy is enforced in the following cases:

1. when signing up
2. when changing a password as a result of forgetting your password
3. when updating or setting up a password from the account dashboard

We have a new publicly available, manually updated status page available at https://addpipe.instatus.com/ .

A client side fix and UX improvement from 3 days ago for the 0 byte recordings created from WebKit browsers (Safari, Chrome on iOS, Firefox on iOS, etc.) was not immediately effective because some of our clients self host the pipe.js library so they don’t get pipe.js updates right away.

Also, just short of 10% of all 0 byte recordings did not originate from Safari/WebKit.

As a result, we’ve now implemented a server side fix that stops recovering any 0 byte recording.

On Safari on macOS, Safari on iOS, and Chrome on iOS it is easy to revoke camera and microphone permissions after you’ve given them.

For example, on Safari on macOS you can:

1. click the grey camera icon in the browser tab OR
2. click the red camera icon in the address bar and choose Pause

to temporarily revoke permissions.

Safari on iOS on the other hand has an easily accessible “Stop Using Camera” option.

Chrome on iOS also makes it relatively easy to revoke permissions

If a user started recording after permissions were revoked, the recording client temporarily showed the “Waiting for data…” message and then “Device error: no audio or video data”. It also created a 0 byte file.

These scenarios have now been improved. The 0 byte recording is not created anymore and the desktop recording client immediately acknowledges the loss of permissions and gives basic instructions to the user.