Browser versions in the recordings list are now a bit more accurate. Ohh and we've added the OS version as well!
More accurate Browser and OS info
Easier Screen Recording
- screen recording now works in both Chrome 72+ and Firefox 66+.
- screen recording now works without an extension
Thus you can now enable screen recording from the options menu in the Embed section of your dashboard:
Once enabled, the Record Screen button will show and you can start capturing the screen right away.
Check out the blog post for detailed info.
getUserMedia() Logs To The Rescue
We've just launched a new Logs section that gives you access to all the successful and failed attempts to access the camera and microphone with
This section is a very useful tool to help you give better customer support, get accurate analytics and look up user attempts to grant access to their camera and microphone.
You can find out more details in the blog post.
New Filters in the Recordings Section
2 updates to the Recordings section:
- you can search recordings by the device IP
- you can filter and show only Recovered recordings (recordings for which the connection was interrupted mid-recording and auto save was ON).
No longer will you need to sift through pages to find the elusive recordings :)
0 byte Files Are History
We've implemented a catch all mechanism for all of the situations that were producing 0 byte recordings coming from the HTML5 desktop recorder.
Previously, when a 0 byte file was made, the user that made the recording had no idea.
Now the user experience is much better. After clicking the record button if no incoming data is detected:
- For the first 2 seconds the message Waiting for data... is shown and the recording counter does not start, because nothing is actual recording.
- After 2 seconds if there is still no incoming data, the message Device error: no audio or video data is shown and the UI is reset, so that you can retry to record.
- The failed recording is not saved.
Better Camera & Microphone Access Messages
The messages that we were showing when our HTML5 desktop recorder was requesting camera and microphone access needed an improvement.
- We've updated the messages to be in line with the text used by the browsers. Words like access and webcam were replaced by the keywords use and camera respectively.
- When requesting access, we've added the domain name of the website in which Pipe is embeded in, for a better understanding of the context.
- In case the user blocks the camera and/or microphone, an additional message is shown which informs the user how to unblock the devices.
- Now when you record audio only, the messages refer just to the microphone device, in order to avoid any kind of confusion.
Begining of the Year Cleanup
With the start of the new year we've fixed the following:
- Fixed issue with some of the recordings being 1 second longer than the actual moment when the stop recording button was pressed
- Fixed issue with minimal number of accepted parameters and their default value for the Pipe embed code
- Added additional check to prevent the deletion of recordings in some rare cases when they were stuck in the storage queue
- Fixed issue with the YouTube integration no longer uploading videos.
Inline Recorder on Chrome on Android
We've just rolled out the new HTML5 desktop-like inline recorder to all Pipe accounts. It can be activated from the environment settings.
It will work on Chrome 63+ on Android on secure origins (https).
More details in the blog post.
We've set up these demos to help test various features and configurations. You can use them to test the new recorder on your Android device:
Some of the stuff we've fixed in this autumn:
- A new configuration option in the S3 bucket configuration page allows you to specify custom S3 endpoints.
- Removed the "Connecting..." message that shows up in the HTML5 recorder after pressing the RECORD button because the recorder is already connected at that point
- Reduced the incidence of duplicate entries in the db for the same recording
- Fixed issue with videos from mobile not being rotated according to their rotation metadata. This affected videos with H.264 video and AAC audio as on such videos we did minimal processing.
- Fixed an issue with the upload percentage going to 100% ahead of time and thus spending a lot of time at 100%
- On mobile we now show only a "Record" label instead of "Record or select a video file" when selecting an existing recording is disabled
- We've added the environment id to the body of the email sent on a new recording or when a push to storage fails for easier filtering in Gmail
- We've stopped using HTML forms in the 2.0 and 1.0 embed code as they conflicted with existing forms when embedding Pipe in an online form like those produced by GravityForms
- Solved issue with
TypeError: jQuery(...).ajaxSubmitbeing thrown if inserting jQuery in the page after the 2.0 Pipe code
Access-Control-Allow-Headers: Origin, X-Requested-Withto
precheck.phpand the .xml language files
- Better email validation on /signup and /invite
- Turned off
echoCancellationin our HTML5 recorder to make sure as little processing as possible is done on the audio
Tightened Security on the Pipe Platform
For some time now we've been working closely with a pen tester to tighten the security of the Pipe platform.
The work has been extensive and its ongoing work but briefly, I can say we went through:
- CSRF tokens used in the Pipe account area
- XSS filters on input and possible XSS exploits
- Escaping input data when shown or used
- SQL injection testing
- Spoofing most of the params sent to our account and recording client endpoints
- Brute forcing the sign in/sign up/reset password pages
- Brute forcing other endpoints
- CORS headers for the recording client files
- Website headers (we now get an A @ https://securityheaders.com/)
- Firewall rules protecting our servers
- Whitelist of extensions allowed when uploading existing recordings
- Server-side technology information disclosures