I couldn’t access my privacy settings on LinkedIn. Their page was broken. The fix I did was simple for a web developer like me, but before I thought of it, I walked down a rabbit hole.
It started in October 2025. I started noticing articles about LinkedIn beginning to employ user data to train their AI, and people were already automatically opted in without consent.
Turns out in September 2024, LinkedIn had already begun using member data for AI training through a new opt-out system of which many users weren’t aware. They quietly updated their privacy policy shortly after.
Well, anyway, I didn’t want that. So, on my Mac, I logged on my LinkedIn account, headed to “Settings & Privacy,” then clicked “Data privacy.” But what I got… was a 404 page.
Conspiracy?
Huh? “This page doesn’t exist”? Oh, come on… You’re really telling me LinkedIn left a broken link in their settings? Or… perhaps they even did it on purpose so people couldn’t get on and take away their data from their poor AI?
I tried the first things that came to mind and, I think, most people would try. Is it working in other browsers? Nope. Is it any different on mobile? No, same. Is it working if I log out and log back in? Nada. What if we start from a blank slate and clear cookies and cache or try from a private tab? Still nothing. Perhaps if I deactivate and reactive my account? No help there.
Okay… I remembered I have a second account on there which I barely ever used. It wouldn’t affect my main account but, can I access that page from that account? Is it broken for everyone?
Well, turns out, it was just me. That account’s “Data privacy” page was loading just fine.
Then I logged back into my main account… Still broken.
Privacy policy violation
Now, okay, my paranoia subsided, I can now see only my account is broken. But now, that means I can’t access my settings for any privacy matters. Simply put, I don’t like this. Shouldn’t I be able to always adjust those settings about my personal data?
Even as of 5 May 2026, LinkedIn’s privacy policy seems to agree with me:
“We offer our users choices about the data we collect, use and share…”
“Where we rely on your consent to process personal data, you have the right to withdraw or decline your consent at any time and where we rely on legitimate interests, you have the right to object.”
“We provide many choices about the collection, use and sharing of your data, from deleting or correcting data you include in your profile and controlling the visibility of your posts to advertising opt-outs and communication controls. We offer you settings to control and manage the personal data we have about you.”
Okay, then, let me access my own data!
Finding help
A few months later, I came back, and found the missing page still didn’t come back.
Time to message LinkedIn’s support team to see what they’ll do about it. My guess is they’ll just try to shove that issue on the side. But if I’m going to complain about a system, I might as well try it and test it first.
However, one thing I’m sure of, is like any other big company out there, they’ll make it as hard as possible for me to contact them, hiding links under dark patterns.
And that, I was right.
Here’s the path I had to take to finally be able to submit a support ticket:
- Go to LinkedIn’s top page.
- Click my profile icon in the top nav bar, and click “Help”.
- On the LinkedIn help site, scroll all the way down, and click “Contact us” at the bottom.
- Click “Create a support ticket.”
- Under “How can we help?,” click “Other.”
- A field labelled “What do you need help with?” appears. Input “data privacy” and submit.
- A list of search results will appear. Scroll all the way down and click “Create a support ticket.”
- Then, finally, there’s the form to submit an actual support ticket.
Alright, I guess that wasn’t so bad. I mean, it’s fairly standard for any support site to make you go through something like this to be sure you actually tried to resolve the issue yourself if the problem is common.
However, it’s easy to enumerate the steps today once you know them. The first time, it’s not so obvious, and you will spend sometime doing circles.
Lack of support
I opened three support tickets with LinkedIn since early February.
As I expected, the first time, they tried to turn this problem on me and basically just told me to ensure I use a supported browser, update it, clear its cache, and try again.
The second time, in April, I told them I already tried everything I could with my browser and I couldn’t fix it. I mentioned to them all the steps I described in this article earlier.
A quote from their answer:
Thank you for your patience. We have confirmed the issue and have escalated it to our Technical Escalations and Engineering teams for investigation. At this time, there’s no estimate as to how long it might take to resolve. We’ll do our best to provide progress updates as they become available.
Yet, they… still closed the ticket.
My interpretation: “Okay, sure, we’ll look at the problem when we feel like it. Don’t expect it fixed anytime soon.”
I opened a third ticket a week after that one. I asked, “Why was it closed? The issue wasn’t even resolved at all. According to your terms, I should be able to modify my privacy settings at anytime. Is it better if I just delete my account from LinkedIn or contact your legal team?”
They replied, but ignored my question:
[Your previous ticket] was not closed. It was under our technical team investigating.
At this time, there’s no estimate as to how long it might take to resolve. We’ll do our best to provide progress updates as they become available.
So I pressed the matter, “You ignored the question I asked.”
A quote from their reply:
We may be able to better understand what the issue is by accessing your account. Do we have your permission to log in to your account and where necessary, take action on your behalf to address the specific issue you are reporting? If yes, we won’t require any additional details (including your password) to securely access your account.
Funny enough, I did already give them permission in the second ticket to access my account. “Yes, I already gave permission for that in my previous ticket. Have you reviewed the previous tickets?”
Finally, someone from the “Trust and Consumer Support team” replied, mentioning their user agreement:
As noted in our User Agreement, while we aim to provide a consistent experience, LinkedIn does not guarantee that the service will always be free from technical interruptions or errors. That said, we do recognize the impact this has had on you and appreciate your patience while it’s being worked through.
I do get that. Nothing works 100% of the time. Yes, outages will happen every now and then. It seems LinkedIn’s last outage was actually just a bit over two years ago, so the platform is quite stable. But a settings page broken for half a year? Get real.
And that last ticket? Closed. Two weeks ago. With no option to re-open or reply. Of course.
Will I ever get an update about it? Probably not.
Jacking in LinkedIn
Yesterday, I was checking on the status of the privacy page. Still “not found.”
What will I need to do to get it to work and actually adjust my privacy settings? As their privacy policy suggested, I was thinking of contacting their Data Protection Officer. But then again, my confidence on having anyone at LinkedIn truly look into the matter and resolve it tanked.
“If you want something done right, do it yourself.”
I started my own investigation. What is actually broken?
Well, I opened the browser’s console (or “dev tools,” whatever browsers call it). In hindsight, I should have done from the beginning. But then again, didn’t, simply because I thought it’s their site so they should look into it, and it shouldn’t be my job to do so. Yet, here we are…
At this point, my assumption is the “missing page” wasn’t actually missing. I know very well from experience in building web apps myself that, sometimes, even if there’s an issue from server or authentication, instead of throwing a proper HTTP 500 or 403, we just toss a good old “404 Not Found” for security reasons or simply to save face.
If that sounds dishonest, I agree, but there are some legitimate reasons to throw a 404 instead of “403 Unauthorized.” For example, GitHub does it with private repositories when accessed from someone who doesn’t have permission to see them. Showing a 404 instead of 403 just tells the user the thing is doesn’t exist, even if it really does. That’s because not only you don’t want to let the user get data they aren’t allowed to access, but you also don’t want to divulge if they exist or not. Classic “need to know” basis.
Back to my missing page. When trying to access the “Data privacy” settings page, the console’s Network tab reports a URL from their API server, that indeed fails with 404. I right-clicked the URL and copied it as a fetch() request, which gave me this:
fetch(
'https://www.linkedin.com/mysettings-api/settingsApiSettingCards?keys=List(HOW_LINKEDIN_USES_YOUR_DATA,WHO_CAN_REACH_YOU,MESSAGING_EXPERIENCE,JOB_SEEKING_PREFERENCES,OTHER_APPLICATIONS)&q=subcategory',
{
cache: 'default',
credentials: 'include',
headers: {
Accept: 'application/vnd.linkedin.normalized+json+2.1',
'Accept-Language': 'en-CA,en-US;q=0.9,en;q=0.8',
'Cache-Control': 'no-cache',
'Csrf-Token': 'ajax:0123456789012345678',
Pragma: 'no-cache',
Priority: 'u=3, i',
'User-Agent':
'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.4 Safari/605.1.15',
'X-LI-Lang': 'en_US',
'X-li-page-instance':
'urn:li:page:d_flagship3_settings_account_preferences;FSAIWK4zW9ygyIknNsJZklfVa',
'X-LI-Track':
'{"clientVersion":"0.2.*","osName":"web","timezoneOffset":9,"deviceFormFactor":"DESKTOP","mpName":"settings-web","displayDensity":2}',
'X-RestLi-Protocol-Version': '2.0.0',
},
method: 'GET',
mode: 'cors',
redirect: 'follow',
referrer: 'https://www.linkedin.com/mypreferences/d/categories/account',
referrerPolicy: 'strict-origin-when-cross-origin',
},
)
(Note sensitive or private data is redacted from these code samples. The cookies don’t need to be masked, as they are not shown in these fetch() requests—{"credentials": "include"} already takes care of sending the cookies automatically.)
Interested. From the List(HOW_LINKEDIN_USES_YOUR_DATA,WHO_CAN_REACH_YOU,MESSAGING_EXPERIENCE,JOB_SEEKING_PREFERENCES,OTHER_APPLICATIONS) part, it looks like their frontend fetches settings data in bulk via API and aggregates it. That was failing.
The error:
Error: 404 {"data":{"exceptionClass":"com.linkedin.settingsapi.common.errors.SettingsUserVisibleException","errorDetailType":"com.linkedin.restli.common.ErrorDetails","message":"The requested Setting with settingKey: requireReferral not found","status":404,"errorDetails":{"code":"NO_RECORD_FOUND","details":"The requested Setting with settingKey: requireReferral not found"}},"included":[]}
“The requested Setting with settingKey: requireReferral not found.” Huh. It looked like some data was actually missing on my account. Okay, while personally I would have chosen to throw a “500 Internal Server Error” when the server trips on something, there was some data that was actually not found, so… “404.”
What if I tried to just get every category, one by one? Maybe I could pinpoint where the missing data were.
Before I did that, I needed some quick fetch() wrapper to just do the requests for me and unfurl the JSON data that was ought to come in. (I mean, it has to be JSON format… It’s practically the only format API servers use these days.)
function get(url, options = {}) {
const p = fetch(url, options).then((res) => {
if (!res.ok) {
return res.text().then((t) => {
throw new Error(`${res.status} ${t}`)
})
}
return res.json()
})
p.then(console.log).catch(console.error)
return p
}
This wrapper helps dealing with all the async I have to do with fetch and the data after. It returns the Promise itself returned by fetch(), but will also output the data in the console with console.log when the Promise resolves.
All I had to do now was, instead of fetch, call this get function, with the same arguments fetch would expect.
I broke down the list of categories and tried one by one. Here is what I got:
HOW_LINKEDIN_USES_YOUR_DATA✅WHO_CAN_REACH_YOU❌MESSAGING_EXPERIENCE✅JOB_SEEKING_PREFERENCES✅OTHER_APPLICATIONS✅
Ah… WHO_CAN_REACH_YOU was the only one that failed, with the same error I quoted earlier, the same missing requireReferral.
Alright, then. Maybe if I just updated my settings data to store that missing record, the “Data privacy” page will work again? But then, how is data saved?
It looked like changing any setting gets saved instantly—there is no Save, Submit, or Apply button. I tried the first setting I found: the “Page visit visibility” setting on the “Visibility” page.
fetch(
'https://www.linkedin.com/mysettings-api/settingsApiSettings/allowOrganizationToViewMemberPageVisits',
{
body: '{"value":"false","settingDisplayType":"TOGGLE","notationDescription":"When this setting is on, organizations will be able to see that you visited their Page. Information from your profile will also be shown, including your profile photo, name, location, job title, and industry, subject to your visibility settings. <a href=\\"/help/linkedin/answer/a6235456\\" target=\\"_blank\\" aria-label=\\"Learn more about page viewing options.\\">Learn more</a>","offValue":"false","entityUrn":"urn:li:settingEntity:20011503","a11yNotationDescription":"When this setting is on, organizations will be able to see that you visited their Page. Information from your profile will also be shown, including your profile photo, name, location, job title, and industry, subject to your visibility settings. <a href=\\"/help/linkedin/answer/a6235456\\" target=\\"_blank\\" aria-label=\\"Learn more about page viewing options.\\">Learn more</a>","key":"allowOrganizationToViewMemberPageVisits","onValue":"false","primaryDescription":"Do you want to allow organizations to see that you visited their LinkedIn Page?","toggleLabel":"Allow organizations to see when you visit their LinkedIn Page","a11yToggleLabel":"Allow organizations to see when you visit their LinkedIn Page","hasChild":false,"a11yPrimaryDescription":"Do you want to allow organizations to see that you visited their LinkedIn Page?"}',
cache: 'default',
credentials: 'include',
headers: {
Accept: 'application/vnd.linkedin.normalized+json+2.1',
'Accept-Language': 'en-CA,en-US;q=0.9,en;q=0.8',
'Cache-Control': 'no-cache',
'Content-Type': 'application/json; charset=utf-8',
'Csrf-Token': 'ajax:0123456789012345678',
Pragma: 'no-cache',
Priority: 'u=3, i',
'User-Agent':
'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.4 Safari/605.1.15',
'X-LI-Lang': 'en_US',
'X-li-page-instance':
'urn:li:page:d_UNKNOWN_ROUTE_member-settings-desktop.index;QE1fiE76Ll01Y0GygEtFgBpn7',
'X-LI-Track':
'{"clientVersion":"0.2.*","osName":"web","timezoneOffset":9,"deviceFormFactor":"DESKTOP","mpName":"settings-web","displayDensity":2}',
'X-RestLi-Protocol-Version': '2.0.0',
},
method: 'PUT',
mode: 'cors',
redirect: 'follow',
referrer:
'https://www.linkedin.com/mypreferences/d/settings/page-visit-visibility',
referrerPolicy: 'strict-origin-when-cross-origin',
},
)
Interesting. Of course, it’s a HTTP PUT request, which is commonly used for replacing a resource (or record) via API. I’m not sure why they send the whole body text back, to be honest, but here was an import part in the JSON data they sent to their server: "key":"allowOrganizationToViewMemberPageVisits","onValue":"false".
As I suspected, their frontend will send an update to an individual setting.
But now, that’s for allowOrganizationToViewMemberPageVisits. We’re looking for requireReferral. Which setting is that? Hard to tell since it was behind that broken “Data privacy” page of ours.
What if I go back to my other account and try from there?
So, I did, and I found the setting. Perhaps the least obvious of them all.
Turns out requireReferral was mapped to “InMail messages,” the feature recruiters can use to spam you even if you don’t want to be contacted via normal messages. It can be found on the “Data privacy” page, under “Who can reach you,” in “Messages you receive.” Not sure why the setting key is named that way, but whatever, I found it.
Now, what if I turn it off, what will the request be for it?
fetch(
'https://www.linkedin.com/mysettings-api/settingsApiSettings/requireReferral?doCustomUpdate=true',
{
body: '{"value":"false","settingDisplayType":"TOGGLE","notationDescription":"InMail allows you to directly message another LinkedIn member that you’re not connected to.","offValue":"true","entityUrn":"urn:li:settingEntity:300165","a11yNotationDescription":"InMail allows you to directly message another LinkedIn member that you’re not connected to.","key":"requireReferral","onValue":"false","primaryDescription":"Allow others to send you <a href=\\"/help/linkedin/answer/1584\\" target=\\"_blank\\">InMail</a>?","toggleLabel":"InMail messages","a11yToggleLabel":"InMail messages","hasChild":false,"a11yPrimaryDescription":"Allow others to send you <a href=\\"/help/linkedin/answer/1584\\" target=\\"_blank\\">InMail</a>?"}',
cache: 'default',
credentials: 'include',
headers: {
Accept: 'application/vnd.linkedin.normalized+json+2.1',
'Accept-Language': 'en-CA,en-US;q=0.9,en;q=0.8',
'Cache-Control': 'no-cache',
'Content-Type': 'application/json; charset=utf-8',
'Csrf-Token': 'ajax:0123456789012345678',
Pragma: 'no-cache',
Priority: 'u=3, i',
'User-Agent':
'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.4 Safari/605.1.15',
'X-LI-Lang': 'en_US',
'X-li-page-instance':
'urn:li:page:d_flagship3_settings_who_can_message_me;OtZKgyD3ZoOxauS97xWvqBi3k',
'X-LI-Track':
'{"clientVersion":"0.2.*","osName":"web","timezoneOffset":9,"deviceFormFactor":"DESKTOP","mpName":"settings-web","displayDensity":2}',
'X-RestLi-Protocol-Version': '2.0.0',
},
method: 'PUT',
mode: 'cors',
redirect: 'follow',
referrer:
'https://www.linkedin.com/mypreferences/d/settings/who-can-message-me',
referrerPolicy: 'strict-origin-when-cross-origin',
},
)
Looks like every setting also have their own ID, entityUrn (URN as in Universal Resource Name, I suppose), with something like urn:li:settingEntity:12345678. But anyway, that doesn’t matter much. I made note of the request to use it later.
I went back to my main account, and copied the fetch() I got from my main account to save the allowOrganizationToViewMemberPageVisits setting earlier. Then, I replaced its URL and body (the first two arguments) with what I just got now from my second account to save requireReferral. Finally, I submitted the modified fetch() call via the browser’s console. The data appeared to have been saved.
Was that it? Was the missing record now present in the database for my broken settings page to work again? Will it solve all my problems? OH, THE SUSPENSE! THE INTENSITY!!
I went back to the “Data privacy” page, and…
IT WORKED! 🎉 We’re back! Wow! WHAT A TIME TO BE ALIVE!
And now to rush to the setting to tell LinkedIn not to use my data for AI training…
For this setting, go to “Data Privacy,” and under “How LinkedIn uses your data,” follow “Data for Generative AI Improvement.”
(Note turning off that setting may not be enough—you may also need to submit an objection using their LinkedIn Data Processing Objection Form.)
Look at that. I didn’t need to find any loophole or unknown vulnerability to get it done—I just had to modify a request their frontend was already handling. To be clear, if it’s not obvious, I didn’t access anyone else’s account or bypassed any authentication—every request was done using my own authenticated settings using LinkedIn’s own APIs exposed through the browser’s developer tools.
Just 20 minutes of investigation to solve the issue. Far less time than what was needed to contact LinkedIn several times, check on the page again and again, read their privacy policy, and to even write this article. Maybe I should go tell LinkedIn’s support team now of my marvellous work—and hope maybe they’ll add a check somewhere in their code so it won’t brick anyone else’s settings.
Learning things the hard way so you don’t have to. If somehow you’re as unlucky as I am and hit the same snag, I hope you find this and it helps!