Here at the Gnar, we have a few major clients in the criminal background check business. As software engineers, this is a huge responsibility. We have to protect the public while at the same time respecting the privacy as much as possible of people who have trusted us with their data.
In fields like this, there’s a “minimum need to know” principle. Users of any website should only view the minimum necessary amount of other people’s personal data in order to do their jobs. A similar field where this applies is medical software, which I’ll use as the example for the remainder of this post. A user of medical software should not be allowed to view medical records of somebody they’re not treating, at least not without the patient’s prior consent.
This is one of the reasons why an audit trail is so important. Any time a user visits a patient’s page, there needs to be a record of it. If the user didn’t have a good reason to view that data, the user can face serious consequences.
Enter Hotwire Prefetching
Hotwire, which comes standard in new Rails apps 7 or above, comes with sensible defaults to improve perceived performance. In order to improve page load time, when a user hovers over a link, Hotwire makes an AJAX request in the background, fetching the contents of the link before the user has even clicked. Most users will have no idea that this is happening. They just notice that the page seems to load instantaneously, which, before Hotwire, would never happen.
Here’s the problem: the Rails logs can’t tell the difference between whether a user clicked on the page or merely hovered their mouse cursor over the link.
It can make it look like users were viewing patient data that they had no authorization to do so. Let’s say they hovered over the link to the medical data for “John Smith #1”, but their actual patient was “John Smith #2”. The browser prefetches both patients as the user’s browser hovers over each link.
Also, from a compliance perspective, IT DOESN’T MATTER whether the user clicked. As soon as a patient’s data is on an unauthorized user’s computer, a violation of privacy has taken place.
How To Disable Prefetching
If we want to disable prefetching on an individual link, we simply set a data attribute turbo-prefetch to false.
<a href="/patients/31415" data-turbo-prefetch="false">View Patient 31415</a>
If we want to enable prefetching, we set it to true.
<a href="/patients/31415" data-turbo-prefetch="true">View Patient 31415</a>
Setting this data attribute applies not only to this element but to ALL CHILD ELEMENTS. So if privacy and compliance are concerns as they are with healthcare and criminal background applications, we should set this attribute to “false” on the body, but we can still opt-in to pre-fetching for pages we know are safe:
<body data-turbo-prefetch="false">
<!-- We can opt into pre-fetching for pages with no personal info -->
<a href="/outstanding_tasks_for_user" data-turbo-prefetch="true">
Outstanding Tasks For User
</a>
<!-- No Prefetching For the Patient Link -->
<a href="/patients/31415">
View Patient 31415
</a>
</body>
This creates an opt-in system where we only prefetch when it’s done deliberately.
If we want to play it even safer, we can just set prefetch to false for the entire document.
<meta content="false" name="turbo-prefetch">Final Thoughts
This is yet another example where the bells and whistles of modern JavaScript can make for a slick experience in an app, but we still have to make sure we understand the fundamentals of what our app is actually doing first.
