WebKit, the open source browser engine that powers Apple’s Safari, is in the very early stages of testing an API that would give browser operators the ability to see whether users are logged in to a website or not.
Steven Francolla, head of global publisher strategy at LiveRamp, recently came across a reference to the “navigator.setLoggedIn” API in the Safari codebase and surfaced it during a session at AdExchanger’s Programmatic I/O conference in New York last week.
If a browser has purview into a user’s logged-in status, it can make more specific decisions about how to handle first-party cookies in different situations. In the case of logged-in traffic, cookies could have a longer lifespan, for example, while cookies associated with anonymous traffic could either have a shorter timeline or be automatically purged.
In Safari’s view, and according to the WebKit tracking prevention policy, the act of logging in to multiple first-party sites or apps using the same account is akin to “implied consent” for identifying the user as having the same identity in all of those places.
To confirm a user’s intent to stay logged in, Safari is toying with the idea of sending an automatic notification after a set amount of time has elapsed. That could be something like, “Do you want to stay logged in to news.example?”
Browsers need a standardized way to manage logged-in status to counteract sites that keep users logged in by default for client-side storage, wrote WebKit security engineer John Wilander in a note last month to the Web Application Security working group of the World Wide Web Consortium (W3C).
Websites often drop first-party cookies on users to manage identity even if they haven’t logged in. One common reason is to track the number of articles someone has read so a publisher knows when to engage its paywall.
But if the browser can’t tell the difference between whether someone has actively logged in or is logged in by default by a webpage, it has no other choice than to treat the user as logged in to that site.
“That is a serious privacy issue,” Wilander wrote. “Long-term storage should instead be tied to where the user is truly logged in.”
Collaboration?
Although the API isn’t live yet, WebKit engineers, led by Wilander, a main architect of Safari’s Intelligent Tracking Prevention (ITP) technology, presented a proposal to W3C in September explaining how it could work. That’s significant, said Andraz Tori, head of recommendations and data science at Outbrain.
W3C is an international organization that develops standards and protocols for the web. By making a formal proposal for an official browser API, Apple is looking to collaborate rather than doing something Safari-focused like with ITP, which severely limits the use of first-party cookies, but only in browsers based on WebKit.
“Apple is more eager to work through industry working groups to advance its cause,” Tori said. “Previously, the emphasis was on unilateral action with Intelligent Tracking Prevention in Safari.”
Apple’s approach to ITP has ruffled advertiser and publisher feathers along the way. Publishers were particularly thrown off balance by ITP 2.2, which deprecates certain first-party client-side cookies after just 24 hours.
“Apple got a lot of pushback from publishers after ITP 2.2, but this is a way to fortify how identity is managed across browsers,” said Nishant Desai, director of technology and partnerships at Xaxis. “If a user is logged in and the browser can query to see that, there is a signal that a person intended to interact with that site and a better understanding of whether a cookie should persist or not.”
As to what the IsLoggedIn API could mean for ITP and future iterations of the technology, it appears to set the foundation for stricter policies on first-party cookie deletion, Tori said.
As to whether the API will become a standard for other browsers beyond Safari also remains to be seen. Even if the proposal is blessed by the W3C, “browser adoption could be a real holdup,” Desai said.
“Implementation from the publisher side wouldn’t be super complex, but first the browsers will actually have to support this and implement it,” he said.
A Mozilla spokesperson told AdExchanger that it sees “value in exploring the types of problems Apple’s proposal is trying to solve, namely giving the browser a better signal for deciding when website data is likely to be important to a user,” but that it’s too early in the process to share a firm opinion on the API.
