You’ve drawn fifty versions of the same screen — and you still hate every one of them. Begrudgingly, you pick three, show them to your product manager, and hear: “Looks cool, but the idea doesn’t work.” Sound familiar? In this article, I’ll unpack why designers fall into detail work at the wrong moment, examining both process pitfalls and the underlying psychological reasons, as understanding these traps is the first step to overcoming them. I’ll also share tactics I use to climb out of that trap. Reason #1 You’re Afraid To Show Rough Work We designers worship detail. We’re taught that true craft equals razor‑sharp typography, perfect grids, and pixel precision. So the minute a task arrives, we pop open Figma and start polishing long before polish is needed. I’ve skipped the sketch phase more times than I care to admit. I told myself it would be faster, yet I always ended up spending hours producing a tidy mock‑up when a scribbled thumbnail would have sparked a five‑minute chat with my product manager. Rough sketches felt “unprofessional,” so I hid them. The cost? Lost time, wasted energy — and, by the third redo, teammates were quietly wondering if I even understood the brief. The real problem here is the habit: we open Figma and start perfecting the UI before we’ve even solved the problem. So why do we hide these rough sketches? It’s not just a bad habit or plain silly. There are solid psychological reasons behind it. We often just call it perfectionism, but it’s deeper than wanting things neat. Digging into the psychology (like the research by Hewitt and Flett) shows there are a couple of flavors driving this: Socially prescribed perfectionismIt’s that nagging feeling that everyone else expects perfect work from you, which makes showing anything rough feel like walking into the lion’s den. Self-oriented perfectionismWhere you’re the one setting impossibly high standards for yourself, leading to brutal self-criticism if anything looks slightly off. Either way, the result’s the same: showing unfinished work feels wrong, and you miss out on that vital early feedback. Back to the design side, remember that clients rarely see architects’ first pencil sketches, but these sketches still exist; they guide structural choices before the 3D render. Treat your thumbnails the same way — artifacts meant to collapse uncertainty, not portfolio pieces. Once stakeholders see the upside, roughness becomes a badge of speed, not sloppiness. So, the key is to consciously make that shift: Treat early sketches as disposable tools for thinking and actively share them to get feedback faster. Reason #2: You Fix The Symptom, Not The Cause Before tackling any task, we need to understand what business outcome we’re aiming for. Product managers might come to us asking to enlarge the payment button in the shopping cart because users aren’t noticing it. The suggested solution itself isn’t necessarily bad, but before redesigning the button, we should ask, “What data suggests they aren’t noticing it?” Don’t get me wrong, I’m not saying you shouldn’t trust your product manager. On the contrary, these questions help ensure you’re on the same page and working with the same data. From my experience, here are several reasons why users might not be clicking that coveted button: Users don’t understand that this step is for payment. They understand it’s about payment but expect order confirmation first. Due to incorrect translation, users don’t understand what the button means. Lack of trust signals (no security icons, unclear seller information). Unexpected additional costs (hidden fees, shipping) that appear at this stage. Technical issues (inactive button, page freezing). Now, imagine you simply did what the manager suggested. Would you have solved the problem? Hardly. Moreover, the responsibility for the unresolved issue would fall on you, as the interface solution lies within the design domain. The product manager actually did their job correctly by identifying a problem: suspiciously, few users are clicking the button. Psychologically, taking on this bigger role isn’t easy. It means overcoming the fear of making mistakes and the discomfort of exploring unclear problems rather than just doing tasks. This shift means seeing ourselves as partners who create value — even if it means fighting a hesitation to question product managers (which might come from a fear of speaking up or a desire to avoid challenging authority) — and understanding that using our product logic expertise proactively is crucial for modern designers. There’s another critical reason why we, designers, need to be a bit like product managers: the rise of AI. I deliberately used a simple example about enlarging a button, but I’m confident that in the near future, AI will easily handle routine design tasks. This worries me, but at the same time, I’m already gladly stepping into the product manager’s territory: understanding product and business metrics, formulating hypotheses, conducting research, and so on. It might sound like I’m taking work away from PMs, but believe me, they undoubtedly have enough on their plates and are usually more than happy to delegate some responsibilities to designers. Reason #3: You’re Solving The Wrong Problem Before solving anything, ask whether the problem even deserves your attention. During a major home‑screen redesign, our goal was to drive more users into paid services. The initial hypothesis — making service buttons bigger and brighter might help returning users — seemed reasonable enough to test. However, even when A/B tests (a method of comparing two versions of a design to determine which performs better) showed minimal impact, we continued to tweak those buttons. Only later did it click: the home screen isn’t the place to sell; visitors open the app to start, not to buy. We removed that promo block, and nothing broke. Contextual entry points deeper into the journey performed brilliantly. Lesson learned: Without the right context, any visual tweak is lipstick on a pig. Why did we get stuck polishing buttons instead of stopping sooner? It’s easy to get tunnel vision. Psychologically, it’s likely the good old sunk cost fallacy kicking in: we’d already invested time in the buttons, so stopping felt like wasting that effort, even though the data wasn’t promising. It’s just easier to keep fiddling with something familiar than to admit we need a new plan. Perhaps the simple question I should have asked myself when results stalled was: “Are we optimizing the right thing or just polishing something that fundamentally doesn’t fit the user’s primary goal here?” That alone might have saved hours. Reason #4: You’re Drowning In Unactionable Feedback We all discuss our work with colleagues. But here’s a crucial point: what kind of question do you pose to kick off that discussion? If your go-to is “What do you think?” well, that question might lead you down a rabbit hole of personal opinions rather than actionable insights. While experienced colleagues will cut through the noise, others, unsure what to evaluate, might comment on anything and everything — fonts, button colors, even when you desperately need to discuss a user flow. What matters here are two things: The question you ask, The context you give. That means clearly stating the problem, what you’ve learned, and how your idea aims to fix it. For instance: “The problem is our payment conversion rate has dropped by X%. I’ve interviewed users and found they abandon payment because they don’t understand how the total amount is calculated. My solution is to show a detailed cost breakdown. Do you think this actually solves the problem for them?” Here, you’ve stated the problem (conversion drop), shared your insight (user confusion), explained your solution (cost breakdown), and asked a direct question. It’s even better if you prepare a list of specific sub-questions. For instance: “Are all items in the cost breakdown clear?” or “Does the placement of this breakdown feel intuitive within the payment flow?” Another good habit is to keep your rough sketches and previous iterations handy. Some of your colleagues’ suggestions might be things you’ve already tried. It’s great if you can discuss them immediately to either revisit those ideas or definitively set them aside. I’m not a psychologist, but experience tells me that, psychologically, the reluctance to be this specific often stems from a fear of our solution being rejected. We tend to internalize feedback: a seemingly innocent comment like, “Have you considered other ways to organize this section?” or “Perhaps explore a different structure for this part?” can instantly morph in our minds into “You completely messed up the structure. You’re a bad designer.” Imposter syndrome, in all its glory. So, to wrap up this point, here are two recommendations: Prepare for every design discussion.A couple of focused questions will yield far more valuable input than a vague “So, what do you think?”. Actively work on separating feedback on your design from your self-worth.If a mistake is pointed out, acknowledge it, learn from it, and you’ll be less likely to repeat it. This is often easier said than done. For me, it took years of working with a psychotherapist. If you struggle with this, I sincerely wish you strength in overcoming it. Reason #5 You’re Just Tired Sometimes, the issue isn’t strategic at all — it’s fatigue. Fussing over icon corners can feel like a cozy bunker when your brain is fried. There’s a name for this: decision fatigue. Basically, your brain’s battery for hard thinking is low, so it hides out in the easy, comfy zone of pixel-pushing. A striking example comes from a New York Times article titled “Do You Suffer From Decision Fatigue?.” It described how judges deciding on release requests were far more likely to grant release early in the day (about 70% of cases) compared to late in the day (less than 10%) simply because their decision-making energy was depleted. Luckily, designers rarely hold someone’s freedom in their hands, but the example dramatically shows how fatigue can impact our judgment and productivity. What helps here: Swap tasks.Trade tickets with another designer; novelty resets your focus. Talk to another designer.If NDA permits, ask peers outside the team for a sanity check. Step away.Even a ten‑minute walk can do more than a double‑shot espresso. By the way, I came up with these ideas while walking around my office. I was lucky to work near a river, and those short walks quickly turned into a helpful habit. And one more trick that helps me snap out of detail mode early: if I catch myself making around 20 little tweaks — changing font weight, color, border radius — I just stop. Over time, it turned into a habit. I have a similar one with Instagram: by the third reel, my brain quietly asks, “Wait, weren’t we working?” Funny how that kind of nudge saves a ton of time. Four Steps I Use to Avoid Drowning In Detail Knowing these potential traps, here’s the practical process I use to stay on track: 1. Define the Core Problem & Business Goal Before anything, dig deep: what’s the actual problem we’re solving, not just the requested task or a surface-level symptom? Ask ‘why’ repeatedly. What user pain or business need are we addressing? Then, state the clear business goal: “What metric am I moving, and do we have data to prove this is the right lever?” If retention is the goal, decide whether push reminders, gamification, or personalised content is the best route. The wrong lever, or tackling a symptom instead of the cause, dooms everything downstream. 2. Choose the Mechanic (Solution Principle) Once the core problem and goal are clear, lock the solution principle or ‘mechanic’ first. Going with a game layer? Decide if it’s leaderboards, streaks, or badges. Write it down. Then move on. No UI yet. This keeps the focus high-level before diving into pixels. 3. Wireframe the Flow & Get Focused Feedback Now open Figma. Map screens, layout, and transitions. Boxes and arrows are enough. Keep the fidelity low so the discussion stays on the flow, not colour. Crucially, when you share these early wires, ask specific questions and provide clear context (as discussed in ‘Reason #4’) to get actionable feedback, not just vague opinions. 4. Polish the Visuals (Mindfully) I only let myself tweak grids, type scales, and shadows after the flow is validated. If progress stalls, or before a major polish effort, I surface the work in a design critique — again using targeted questions and clear context — instead of hiding in version 47. This ensures detailing serves the now-validated solution. Even for something as small as a single button, running these four checkpoints takes about ten minutes and saves hours of decorative dithering. Wrapping Up Next time you feel the pull to vanish into mock‑ups before the problem is nailed down, pause and ask what you might be avoiding. Yes, that can expose an uncomfortable truth. But pausing to ask what you might be avoiding — maybe the fuzzy core problem, or just asking for tough feedback — gives you the power to face the real issue head-on. It keeps the project focused on solving the right problem, not just perfecting a flawed solution. Attention to detail is a superpower when used at the right moment. Obsessing over pixels too soon, though, is a bad habit and a warning light telling us the process needs a rethink.

Jun 13, 2025Ravie LakshmananWeb Security / Network Security Cybersecurity researchers are calling attention to a "large-scale campaign" that has been observed compromising legitimate websites with malicious JavaScript injections. According to Palo Alto Networks Unit 42, these malicious injects are obfuscated using JSFuck, which refers to an "esoteric and educational programming style" that uses only a limited set of characters to write and execute code. The cybersecurity company has given the technique an alternate name JSFireTruck owing to the profanity involved. "Multiple websites have been identified with injected malicious JavaScript that uses JSFireTruck obfuscation, which is composed primarily of the symbols [, ], +, $, {, and }," security researchers Hardik Shah, Brad Duncan, and Pranay Kumar Chhaparwal said. "The code's obfuscation hides its true purpose, hindering analysis." Further analysis has determined that the injected code is designed to check the website referrer ("document.referrer"), which identifies the address of the web page from which a request originated. Should the referrer be a search engine such as Google, Bing, DuckDuckGo, Yahoo!, or AOL, the JavaScript code redirects victims to malicious URLs that can deliver malware, exploits, traffic monetization, and malvertising. Unit 42 said its telemetry uncovered 269,552 web pages that have been infected with JavaScript code using the JSFireTruck technique between March 26 and April 25, 2025. A spike in the campaign was first recorded on April 12, when over 50,000 infected web pages were observed in a single day. "The campaign's scale and stealth pose a significant threat," the researchers said. "The widespread nature of these infections suggests a coordinated effort to compromise legitimate websites as attack vectors for further malicious activities." Say Hello to HelloTDS The development comes as Gen Digital took the wraps off a sophisticated Traffic Distribution Service (TDS) called HelloTDS that's designed to conditionally redirect site visitors to fake CAPTCHA pages, tech support scams, fake browser updates, unwanted browser extensions, and cryptocurrency scams through remotely-hosted JavaScript code injected into the sites. The primary objective of the TDS is to act as a gateway, determining the exact nature of content to be delivered to the victims after fingerprinting their devices. If the user is not deemed a suitable target, the victim is redirected to a benign web page. "The campaign entry points are infected or otherwise attacker-controlled streaming websites, file sharing services, as well as malvertising campaigns," researchers Vojtěch Krejsa and Milan Špinka said in a report published this month. "Victims are evaluated based on geolocation, IP address, and browser fingerprinting; for example, connections through VPNs or headless browsers are detected and rejected." Some of these attack chains have been found to serve bogus CAPTCHA pages that leverage the ClickFix strategy to trick users into running malicious code and infecting their machines with a malware known as PEAKLIGHT (aka Emmenhtal Loader), which is known to server information stealers like Lumma. Central to the HelloTDS infrastructure is the use of .top, .shop, and .com top-level domains that are used to host the JavaScript code and trigger the redirections following a multi-stage fingerprinting process engineered to collect network and browser information. "The HelloTDS infrastructure behind fake CAPTCHA campaigns demonstrates how attackers continue to refine their methods to bypass traditional protections, evade detection, and selectively target victims," the researchers said. "By leveraging sophisticated fingerprinting, dynamic domain infrastructure, and deception tactics (such as mimicking legitimate websites and serving benign content to researchers) these campaigns achieve both stealth and scale." Found this article interesting? Follow us on Twitter  and LinkedIn to read more exclusive content we post. SHARE    

Things are warming up as Remedy’s FBC: Firebreak approaches its June 17 launch on PlayStation 5 as part of the PlayStation Plus Game Catalog. We chatted with Communications Director Thomas Puha, Lead Level Designer Teemu Huhtiniemi, Lead Designer/Lead Technical Designer Anssi Hyytiainen, and Game Director/Lead Writer Mike Kayatta about some of the fascinating and often hilarious development secrets behind the first-person shooter. PlayStation Blog: First, what PS5 and PS5 Pro features did you utilize? Thomas Puha: We’ll support 3D Audio, and we’re prioritising 60 FPS on both formats. We’re aiming for FSR2 with an output resolution of 2560 x 1440 (1440p) on PS, and PSSR with an output resolution of 3840×2160 (4K) on PS5 Pro. Some of the DualSense wireless controller’s features are still a work in progress, but we’re looking to use haptic feedback in a similar way to our previous titles, such as Control and Alan Wake 2. For example, we want to differentiate the weapons to feel unique from each other using the adaptive triggers. Going into the game itself, were there any other influences on its creation outside of Control? Mike Kayatta: We looked at different TV shows that had lots of tools for going into a place and dealing with a crisis. One was a reality show called Dirty Jobs, where the host Mike Rowe finds these terrible, dangerous, or unexpected jobs that you don’t know exist, like cleaning out the inside of a water tower. We also looked at PowerWash Simulator. Cleaning dirt is oddly meditative and really fulfilling. It made me wish a zombie attacked me to break the Zen, and then I’d go right back to cleaning. And we were like, that would be pretty fun in the game. Play Video Were there specific challenges you faced given it’s your first multiplayer game and first-person shooter? Anssi Hyytiainen: It’s radically different from a workflow point of view. You can’t really test it alone, necessarily, which is quite a different experience. And then there are times when one player is missing things on their screen that others are seeing. It was like, “What are you shooting at?” What’s been your favorite moments developing the game so far? Teemu Huhtiniemi: There were so many. But I like when we started seeing all of these overlapping systems kind of click, because there’s a long time in the development where you talk about things on paper and have some prototypes, but you don’t really see it all come together until a point. Then you start seeing the interaction between the systems and all the fun that comes out of that. Kayatta: I imagine there’s a lot of people who probably are a little skeptical about Remedy making something so different. Even internally, when the project was starting. And once we got the trailer out there, everyone was so nervous, but it got a pretty positive reaction. Exposing it to the public is very motivating, because with games, for a very long time, there is nothing, or it is janky and it’s ugly and you don’t find the fun immediately. Were there any specific ideals you followed while you worked on the game? Kayatta: Early on we were constantly asking ourselves, “Could this only happen in Control or at Remedy?” Because the first thing you hear is, “Okay, this is just another co-op multiplayer shooter” – there’s thousands of them, and they’re all good. So what can we do to make it worth playing our game? We were always saying we’ve got this super weird universe and really interesting studio, so we’re always looking at what we could do that nobody else can. Huhtiniemi: I think for me it was when we chose to just embrace the chaos. Like, that’s the whole point of the game. It’s supposed to feel overwhelming and busy at times, so that was great to say it out loud. Kayatta: Yeah, originally we had a prototype where there were only two Hiss in the level, but it just didn’t work, it wasn’t fun. Then everything just accidentally went in the opposite direction, where it was super chaos. At some point we actually started looking at Overcooked quite a bit, and saying, “Look, just embrace it. It’s gonna be nuts.” How did you finally decide on the name FBC: Firebreak, and were there any rejected, alternate, or working titles? Kayatta: So Firebreak is named after real world firebreaks, where you deforest an area to prevent a fire from spreading, but firebreaks are also topographical features of the Oldest House. And so we leaned into the term being a first responder who stops fires from spreading. The FBC part came from not wanting to put ‘Control’ in the title, so Control players wouldn’t feel like they had to detour to this before Control 2, but we didn’t want to totally detach from it either as that felt insincere. An external partner pitched a title. They were very serious about talking up the game being in the Oldest House, and then dramatically revealed the name: Housekeepers. I got what they were going for, but I was like, we cannot call it this. It was like you were playing as a maid!   FBC: Firebreak launches on PS5 June 17 as a day on PlayStation Plus Game Catalog title.

New York City’s Brooklyn-Queens Expressway is falling apart. Built between 1946 and 1964, the urban highway runs 12.1 miles through the heart of the two boroughs to connect on either end with the interstate highway system—a relic of midcentury car-oriented infrastructure, and a prime example of the dwindling lifespan of roads built during that time.  The degradation is most visible—and most pressing—in a section running alongside Brooklyn Heights known as the triple cantilever. This 0.4-mile section, completed in 1954, is unique among U.S. highways in that it juts out from the side of a hill and stacks the two directions of traffic on balcony-like decks, one slightly overhanging the other. A third level holds a well-loved park, the Brooklyn Heights Promenade.  This unusual layer cake of a freeway was a marvel of engineering in its day, though not without controversy. Masterminded by Robert Moses, the city’s all-powerful, often ruthless city planner for more than four decades, the roadway bisects working-class and immigrant neighborhoods that grapple with the health and environmental fallout to this day. Like the reputation of the man who built it, the triple cantilever has aged poorly. Its narrow width, (33.5 feet for the roadway in either direction) has made all but the most basic maintenance incredibly difficult, and its 71-year-old structure is constantly battered by the ever heavier automobiles and trucks. Designed to accommodate around 47,000 vehicles per day, it now carries more than three times that amount. Deteriorating deck joints and failing steel-reinforced concrete have led many to worry the triple cantilever is on the verge of collapse. An expert panel warned in 2020 that the triple cantilever could be unusable by 2026, and only then did interim repairs get made to keep it standing. [Photo: Alex Potemkin/Getty Images] The mounting concern comes amid a 50-year decline in direct government spending on infrastructure in the U.S., according to a recent analysis by Citigroup. Simply maintaining existing infrastructure is a challenge, the report notes. Meanwhile, the American Society of Civil Engineers’ grade for the country’s infrastructure has improved, from a D+ in 2017 to a C in 2025. Now even private credit firms are circling: As reported in Bloomberg, Apollo Global Management estimates that a boom in infrastructure deals help could grow the private debt market up to a staggering $40 trillion.   Independent urban designer Marc Wouters has an idea on how to fix BQE’s cantilever. He’s been working on it for years. “My process is that I always interview people in the community before I do any drawings,” he says. “So I really have listened to pretty much everybody over the past few years.” Unsolicited and developed in his own spare time, Wouters has designed an alternative for the triple cantilever that he named the BQE Streamline Plan. BQE Streamline Plan [Image: courtesy Marc Wouters | Studios/©2025] His concept, based on decades of experience in urban planning, infrastructure, and resilience projects in communities across the country, is relatively simple: extend the width of the two traffic-bearing cantilevers and add support beams to their outside edge, move both directions of traffic onto four lanes on the first level, and turn the second level into a large freeway cap park. Instead of major rebuilding efforts, Wouters’s proposal is more of a reinforcement and expansion, with a High Line-style park plopped on top. Though he’s not an engineer, Wouters is confident that his design would shift enough strain off the existing structure to allow it to continue functioning for the foreseeable future. (What actual engineers think remains to be seen.) “What I’ve done is come up with a plan that happens to be much less invasive, faster to build, a lot cheaper, and it encompasses a lot of what the community wants,” he says. “Yet it still handles the same capacity as the highway does right now.” So what will it take for this outsider’s idea to be considered a viable design alternative? This idea had been brewing in his mind for years. Wouters, who lives near the triple cantilever section of the BQE in Brooklyn Heights, has followed the highway’s planning process for more than a decade.  As complex infrastructure projects go, this one is particularly convoluted. The BQE is overseen by both the state of New York and New York City, among others, with the city in charge of the 1.5-mile section that includes the triple cantilever. This dual ownership has complicated the management of the highway and its funding. The city and the state have launched several efforts over the years to reimagine the highway’s entire length. In winter 2018, the city’s Department of Transportation (NYC DOT) released two proposals to address the ailing cantilever. Not seeing what they wanted from either one, Brooklyn Heights Association, a nonprofit neighborhood group, retained Wouters and his studio to develop an alternative design. He suggested building a temporary parallel bypass that would allow a full closure and repair of the triple cantilever. That proposal, along with competing ideas developed under the previous mayoral administration, went by the wayside in 2022, when the latest BQE redesign process commenced. Wouters found himself following yet another community feedback and planning process for the triple cantilever. The ideas being proposed by the city’s DOT this time around included a plan that would chew into the hillside that currently supports the triple cantilever to move the first tier of traffic directly underneath the second, and add a large girding structure on its open end to hold it all up. Other options included reshaping the retaining wall that currently holds up the triple cantilever, moving traffic below grade into a wide tunnel, or tearing the whole thing down and rebuilding from scratch. Each would be time-consuming and disruptive, and many of them cut into another well-loved public space immediately adjacent to the triple cantilever, Brooklyn Bridge Park. None of these options has anything close to unanimous support. And any of them will cost more than $1 billion—a price tag that hits much harder after the Federal Highway Administration rejected an $800 million grant proposal for fixing the BQE back in early 2024. BQE Streamline Plan [Image: courtesy Marc Wouters | Studios/©2025] Wouters is no highway zealot. In fact, he’s worked on a project heading into construction in Syracuse that will replace an underutilized inner-city highway with a more appropriately sized boulevard and developable land. But he felt sure there was a better way forward—a concept that would work as well in practice as on paper. “I just kept going to meetings and waiting to see what I thought was a progressive solution,” Wouters says. Unimpressed and frustrated, he set out to design it himself. Wouters released the Streamline Plan in March. The concept quickly gathered interest, receiving a flurry of local news coverage. He has since met with various elected officials to discuss it. But as elegant as Wouters’s concept may be, some stakeholders remain unconvinced that the city should be going all in on a reinterpretation of the triple cantilever. What might be more appropriate, critics say, is to make necessary fixes now to keep the triple cantilever safe and functional, and to spend more time thinking about whether this section of highway is even what the city needs in the long term. A group of local organizations is calling for a more comprehensive reconsideration of the BQE under the premise that its harms may be outnumbering its benefits. Launched last spring, the Brooklyn-Queens Expressway Environmental Justice Coalition wants any planning for the future of the BQE to include efforts to address its health and environmental impacts on neighboring communities and to seek an alternative that reconnects communities that have been divided by the corridor. One member of this coalition is the Riders Alliance, a nonprofit focused on improving public transit in New York. Danny Pearlstein, the group’s policy and communications director, says implementing a major redesign of the triple cantilever would just reinforce car dependency in a place that’s actually well served by public transit. The environmental justice coalition’s worry is that rebuilding this one section in a long-term fashion could make it harder for change across the length of the entire BQE and could increase the environmental impact the highway has on the communities that surround it. “This is not just one neighborhood. This is communities up and down the corridor that don’t resemble each other very much in income or background who are united and are standing together for something that’s transformative, rather than doubling down on the old ways,” Pearlstein says. [Photo: ©NYC DOT] Lara Birnback is executive director of the Brooklyn Heights Association, representing a neighborhood of roughly 20,000 people. Her organization, which worked directly with Wouters in the past, is circumspect about his latest concept. “It’s certainly more interesting and responsive to the kinds of things that the community has been asking for when thinking about the BQE. It’s more of those things than we’ve seen from any of the designs that New York City DOT has presented to us through their engagement process,” she says. “But at the end of the day, it’s still a way of preserving more or less the status quo of the BQE as a major interstate highway running through the borough.” She argues it makes more sense to patch up the triple cantilever and use the extra years of service that buys to do a more radical rethinking of the BQE’s future. (For example, one 2020 proposal by the Brooklyn-based architecture studio Light and Air proposed a simple intervention of installing buttresses on the open-air side of the triple cantilever, propping it up with a relatively small addition of material.) “We really strongly encourage the city to move forward immediately with a more short-term stabilization plan for the cantilever, with repairs that would last, for example, 20 to 25 years rather than spending billions and billions of dollars rebuilding it for the next 100 years,” Birnback says. Birnback says a major rebuilding plan like the one Wouters is proposing—for all its community benefits—could end up doing more harm to the city. “I think going forward now with a plan that both embeds the status quo and most likely forecloses on the possibility of real transformation across the corridor is a mistake,” she says. NYC DOT expects to begin its formal environmental review process this year, laying the necessary groundwork for deciding on a plan for what to do with the triple cantilever, either for the short term or the long term. The environmental process will evaluate all concepts equally, according to DOT spokesperson Vincent Barone, who notes that the department is required to review and respond to all feedback that comes in through that process. There is technically nothing holding back Wouters’s proposal from being one of the alternatives considered. And he may have some important political support to help make that happen. Earlier this month, Brooklyn’s Community District 2 board formally supported the plan. They are calling for the city’s transportation department to include it in the BQE’s formal environmental review process when it starts later this year. [Photo: Sinisa Kukic/Getty Images] Wouters argues that his proposal solves the pressing structural problems of the triple cantilever while also opening resources to deal with the highway’s big picture challenges. “The several hundred million dollars of savings is now funding that could go to other parts of the BQE. And there are other parts that are really struggling,” he says. “I’m always thinking about the whole length and about all these other communities, not just this one.” With a new presidential administration and a mayoral primary election in June, what happens with the triple cantilever is very much up in the air. But if the environmental review process begins as planned this year, it only makes sense for every option to fall under consideration. What gets built—or torn down, or reconstructed, or reinterpreted—could reshape part of New York City for generations.

Apple rejected nearly two million apps in 2024, cracking down harder than ever on fraud, spam, and low-effort software.The App Store saw 813 million weekly visitorsThe company rejected 1.93 million app submissions in 2024, according to its App Store Transparency Report, released in May 2025. The annual report outlines how Apple enforces App Store policies and manages content across its global platform.Apple reviewed approximately 7.7 million app submissions in 2024, rejecting over 1.9 million for failing to meet its standards. Nearly one in four were denied, typically for violating rules around performance, design, or business practices. Continue Reading on AppleInsider | Discuss on our Forums

Shenzhen-based 3D printer manufacturer Elegoo has introduced a new RFID Ecosystem for its upcoming printer line, including the upcoming Elegoo Saturn 4 Ultra. This system integrates RFID-tagged resin bottles, an Elegoo-designed scanner, and cloud-connected print profiles. Elegoo has opened a public feedback solicitation on its website and GitHub page to refine the implementation and encourage community input. The company is currently testing several use cases, such as automatic profile loading, material usage tracking, and batch traceability. Elegoo says these features aim to streamline workflow, reduce errors, and assist in quality assurance. However, in a GitHub post, the company emphasized that its RFID system is optional and will not lock users into proprietary materials. An open approach to a closed-loop trend? The Elegoo RFID Ecosystem enters a broader conversation in the additive manufacturing (AM) industry regarding material-locking strategies and proprietary ecosystems. As discussed in a recent 3D Printing Industry analysis, the proliferation of closed systems has triggered renewed debate about interoperability, user autonomy, and long-term value for manufacturers and end-users alike. Elegoo appears to be taking a middle-ground approach: providing automation and traceability features via RFID while maintaining support for third-party materials. In the Elegoo RFID Tag Guide, developers are encouraged to create and test custom tags, with detailed instructions and example code provided to the open-source community. Developer-centric rollout The Elegoo Saturn 4 Ultra, which serves as the first testbed for the RFID system, uses a dedicated RFID reader to retrieve data from tags affixed to resin bottles. These tags store encoded information such as resin name, type, batch number, and print profile metadata. The printer’s firmware can automatically sync this information with cloud-hosted slicer settings for optimal prints. According to the company, future updates may include compatibility with other Elegoo printers and additional features like usage history logging, tamper detection, and resin validation for regulatory compliance. Color scheme guide possibly used for tag classification or UI indication in Elegoo’s RFID material system. Image via Elegoo. A call for collaboration In its official blog post, Elegoo invited users, developers, and material manufacturers to contribute feedback and propose new applications. The company has not yet announced a formal launch date for the ecosystem or its associated hardware. Elegoo, known for its budget-friendly resin and FDM printers, has been expanding its R&D efforts in recent years. With the RFID ecosystem, it now joins other AM firms experimenting with embedded metadata and smart materials integration to support traceability, security, and ease of use. Interoperability and user autonomy The debate about open vs closed ecosystems has increasingly intensified in additive manufacturing discussions. For example, Bambu Lab’s controversial firmware update that introduced new authentication protocols, sparking concerns about third-party compatibility and user autonomy. Subsequent coverage highlighted pushback from the open-source community, including Orca Slicer developers, who rejected integration with Bambu Connect over transparency and access concerns. These cases underscore how interoperability is not only a technical issue, but a strategic and ideological one shaping the future of the AM sector.RFID in 3D printing While RFID integration is more common in logistics and supply chain management, researchers and companies are beginning to explore its potential in 3D printing. Scientists at Swinburne University developed biosensing RFID tags using 3D printed hybrid liquids, enabling applications in health diagnostics and environmental sensing. Meanwhile, materials firm Supernova unveiled a new resin cartridge system embedded with RFID to improve compatibility and process control in high-viscosity 3D printing platforms. These developments suggest that RFID could play a growing role in material authentication, traceability, and automated workflow management within additive manufacturing ecosystems.Subscribe to the 3D Printing Industry newsletter to keep up with the latest 3D printing news. You can also follow us onLinkedIn and subscribe to the 3D Printing Industry YouTube channel to access more exclusive content. At 3DPI, our mission is to deliver high-quality journalism, technical insight, and industry intelligence to professionals across the AM ecosystem.Help us shape the future of 3D printing industry news with our2025 reader survey. Featured image shows Elegoo RFID system displayed on a resin bottle, designed to communicate encoded material data to the printer. Image via Elegoo.

Sometimes, you've to set aside everything you've been taught in order to truly tap into your creativity. It's a brave move but one that has certainly led to big things for Berlin-based illustrator Marc Majewski. In 2024, he won the Best Illustrated Children's Book award from The New York Times and the New York Public Library for As Edward Imagined, and he's currently an in–demand artist in both children's publishing and editorial illustration. Marc grew up in the French Alps, near the border with Switzerland, surrounded by nature and with a great love of traditional picture book illustration, which was fed by his aunt. To reach his dream of becoming an illustrator, he trained the classical way, learning to paint highly realistic imagery – what everyone would call "good illustration". But something wasn't right. This just wasn't him. On the side, he would create the loose, playful sketches he loved but never conceived of them as proper illustrations. Marc's new book Parks is out 5 June. "Then I had a moment where I decided I wanted to paint and create with the same joy and freedom I had felt as a child," says Marc. "I stopped making pictures the way I'd been taught and started painting the way I did in my sketchbooks, directly with paint. The result was much livelier and more joyful illustrations." One epiphany was followed by another when he wrote and illustrated Butterfly Child. This wasn't the first book he'd worked on, but to Marc, it felt like it was. He continues: "The book touches on what it was like to be a queer kid in the countryside and on bullying – so parts of me felt like the child in the book. I think making any book is a vulnerable process, but creating something that explores more personal parts of ourselves can trigger a lot. In my case, the fear of being rejected, shamed, or bullied – which are experiences many kids, and especially queer kids, go through." Published in 2022, it has been translated into 10 languages and resonates with children around the world, supporting kids and encouraging them to express who they really are. From Butterfly Child. Marc is drawn to stories that bring that bring nature and creativity together. He grew up in the Alps, and nature continues to inspire him. In Butterfly Child, As Edward Imagined, and Peter Pan, he explores characters who build, craft, and imagine things, bringing their storybook worlds to life; his simple, Lowry-like figures burst with enthusiasm. Peter Pan is one of his favourites so far. "I knew the story before I started the project, but as I dove deeper into it, I began learning about Barrie's life and how much of it was woven into Peter Pan. That really resonated with me and my own work. I was also inspired by the author's playful spirit – how he balanced lightness and whimsy with meaning and depth," says Marc. From Peter Pan. Return of the Wolves. In future, he'd love to work on a film, and Hayao Miyazaki has always been a big influence. If there's one thing he wants to avoid, it's getting too comfortable or set in his ways. "It's important for me to stay connected to that feeling I had when I first embraced the childlike process of painting and to keep my mind open to playful exploration," says Marc.

The web is beginning to part ways with third-party cookies, a technology it once heavily relied on. Introduced in 1994 by Netscape to support features like virtual shopping carts, cookies have long been a staple of web functionality. However, concerns over privacy and security have led to a concerted effort to eliminate them. The World Wide Web Consortium Technical Architecture Group (W3C TAG) has been vocal in advocating for the complete removal of third-party cookies from the web platform. Major browsers (Chrome, Safari, Firefox, and Edge) are responding by phasing them out, though the transition is gradual. While this shift enhances user privacy, it also disrupts legitimate functionalities that rely on third-party cookies, such as single sign-on (SSO), fraud prevention, and embedded services. And because there is still no universal ban in place and many essential web features continue to depend on these cookies, developers must detect when third-party cookies are blocked so that applications can respond gracefully. Don’t Let Silent Failures Win: Why Cookie Detection Still Matters Yes, the ideal solution is to move away from third-party cookies altogether and redesign our integrations using privacy-first, purpose-built alternatives as soon as possible. But in reality, that migration can take months or even years, especially for legacy systems or third-party vendors. Meanwhile, users are already browsing with third-party cookies disabled and often have no idea that anything is missing. Imagine a travel booking platform that embeds an iframe from a third-party partner to display live train or flight schedules. This embedded service uses a cookie on its own domain to authenticate the user and personalize content, like showing saved trips or loyalty rewards. But when the browser blocks third-party cookies, the iframe cannot access that data. Instead of a seamless experience, the user sees an error, a blank screen, or a login prompt that doesn’t work. And while your team is still planning a long-term integration overhaul, this is already happening to real users. They don’t see a cookie policy; they just see a broken booking flow. Detecting third-party cookie blocking isn’t just good technical hygiene but a frontline defense for user experience. Why It’s Hard To Tell If Third-Party Cookies Are Blocked Detecting whether third-party cookies are supported isn’t as simple as calling navigator.cookieEnabled. Even a well-intentioned check like this one may look safe, but it still won’t tell you what you actually need to know: // DOES NOT detect third-party cookie blocking function areCookiesEnabled() { if (navigator.cookieEnabled === false) { return false; } try { document.cookie = "test_cookie=1; SameSite=None; Secure"; const hasCookie = document.cookie.includes("test_cookie=1"); document.cookie = "test_cookie=; Max-Age=0; SameSite=None; Secure"; return hasCookie; } catch (e) { return false; } } This function only confirms that cookies work in the current (first-party) context. It says nothing about third-party scenarios, like an iframe on another domain. Worse, it’s misleading: in some browsers, navigator.cookieEnabled may still return true inside a third-party iframe even when cookies are blocked. Others might behave differently, leading to inconsistent and unreliable detection. These cross-browser inconsistencies — combined with the limitations of document.cookie — make it clear that there is no shortcut for detection. To truly detect third-party cookie blocking, we need to understand how different browsers actually behave in embedded third-party contexts. How Modern Browsers Handle Third-Party Cookies The behavior of modern browsers directly affects which detection methods will work and which ones silently fail. Safari: Full Third-Party Cookie Blocking Since version 13.1, Safari blocks all third-party cookies by default, with no exceptions, even if the user previously interacted with the embedded domain. This policy is part of Intelligent Tracking Prevention (ITP). For embedded content (such as an SSO iframe) that requires cookie access, Safari exposes the Storage Access API, which requires a user gesture to grant storage permission. As a result, a test for third-party cookie support will nearly always fail in Safari unless the iframe explicitly requests access via this API. Firefox: Cookie Partitioning By Design Firefox’s Total Cookie Protection isolates cookies on a per-site basis. Third-party cookies can still be set and read, but they are partitioned by the top-level site, meaning a cookie set by the same third-party on siteA.com and siteB.com is stored separately and cannot be shared. As of Firefox 102, this behavior is enabled by default in the Standard (default) mode of Enhanced Tracking Protection. Unlike the Strict mode — which blocks third-party cookies entirely, similar to Safari — the Standard mode does not block them outright. Instead, it neutralizes their tracking capability by isolating them per site. As a result, even if a test shows that a third-party cookie was successfully set, it may be useless for cross-site logins or shared sessions due to this partitioning. Detection logic needs to account for that. Chrome: From Deprecation Plans To Privacy Sandbox (And Industry Pushback) Chromium-based browsers still allow third-party cookies by default — but the story is changing. Starting with Chrome 80, third-party cookies must be explicitly marked with SameSite=None; Secure, or they will be rejected. In January 2020, Google announced their intention to phase out third-party cookies by 2022. However, the timeline was updated multiple times, first in June 2021 when the company pushed the rollout to begin in mid-2023 and conclude by the end of that year. Additional postponements followed in July 2022, December 2023, and April 2024. In July 2024, Google has clarified that there is no plan to unilaterally deprecate third-party cookies or force users into a new model without consent. Instead, Chrome is shifting to a user-choice interface that will allow individuals to decide whether to block or allow third-party cookies globally. This change was influenced in part by substantial pushback from the advertising industry, as well as ongoing regulatory oversight, including scrutiny by the UK Competition and Markets Authority (CMA) into Google’s Privacy Sandbox initiative. The CMA confirmed in a 2025 update that there is no intention to force a deprecation or trigger automatic prompts for cookie blocking. As for now, third-party cookies remain enabled by default in Chrome. The new user-facing controls and the broader Privacy Sandbox ecosystem are still in various stages of experimentation and limited rollout. Edge (Chromium-Based): Tracker-Focused Blocking With User Configurability Edge (which is a Chromium-based browser) shares Chrome’s handling of third-party cookies, including the SameSite=None; Secure requirement. Additionally, Edge introduces Tracking Prevention modes: Basic, Balanced (default), and Strict. In Balanced mode, it blocks known third-party trackers using Microsoft’s maintained list but allows many third-party cookies that are not classified as trackers. Strict mode blocks more resource loads than Balanced, which may result in some websites not behaving as expected. Other Browsers: What About Them? Privacy-focused browsers, like Brave, block third-party cookies by default as part of their strong anti-tracking stance. Internet Explorer (IE) 11 allowed third-party cookies depending on user privacy settings and the presence of Platform for Privacy Preferences (P3P) headers. However, IE usage is now negligible. Notably, the default “Medium” privacy setting in IE could block third-party cookies unless a valid P3P policy was present. Older versions of Safari had partial third-party cookie restrictions (such as “Allow from websites I visit”), but, as mentioned before, this was replaced with full blocking via ITP. As of 2025, all major browsers either block or isolate third-party cookies by default, with the exception of Chrome, which still allows them in standard browsing mode pending the rollout of its new user-choice model. To account for these variations, your detection strategy must be grounded in real-world testing — specifically by reproducing a genuine third-party context such as loading your script within an iframe on a cross-origin domain — rather than relying on browser names or versions. Overview Of Detection Techniques Over the years, many techniques have been used to detect third-party cookie blocking. Most are unreliable or obsolete. Here’s a quick walkthrough of what doesn’t work (and why) and what does. Basic JavaScript API Checks (Misleading) As mentioned earlier, the navigator.cookieEnabled or setting document.cookie on the main page doesn’t reflect cross-site cookie status: In third-party iframes, navigator.cookieEnabled often returns true even when cookies are blocked. Setting document.cookie in the parent doesn’t test the third-party context. These checks are first-party only. Avoid using them for detection. Storage Hacks Via localStorage (Obsolete) Previously, some developers inferred cookie support by checking if window.localStorage worked inside a third-party iframe — which is especially useful against older Safari versions that blocked all third-party storage. Modern browsers often allow localStorage even when cookies are blocked. This leads to false positives and is no longer reliable. Server-Assisted Cookie Probe (Heavyweight) One classic method involves setting a cookie from a third-party domain via HTTP and then checking if it comes back: Load a script/image from a third-party server that sets a cookie. Immediately load another resource, and the server checks whether the cookie was sent. This works, but it: Requires custom server-side logic, Depends on HTTP caching, response headers, and cookie attributes (SameSite=None; Secure), and Adds development and infrastructure complexity. While this is technically valid, it is not suitable for a front-end-only approach, which is our focus here. Storage Access API (Supplemental Signal) The document.hasStorageAccess() method allows embedded third-party content to check if it has access to unpartitioned cookies: ChromeSupports hasStorageAccess() and requestStorageAccess() starting from version 119. Additionally, hasUnpartitionedCookieAccess() is available as an alias for hasStorageAccess() from version 125 onwards. FirefoxSupports both hasStorageAccess() and requestStorageAccess() methods. SafariSupports the Storage Access API. However, access must always be triggered by a user interaction. For example, even calling requestStorageAccess() without a direct user gesture (like a click) is ignored. Chrome and Firefox also support the API, and in those browsers, it may work automatically or based on browser heuristics or site engagement. This API is particularly useful for detecting scenarios where cookies are present but partitioned (e.g., Firefox’s Total Cookie Protection), as it helps determine if the iframe has unrestricted cookie access. But for now, it’s still best used as a supplemental signal, rather than a standalone check. iFrame + postMessage (Best Practice) Despite the existence of the Storage Access API, at the time of writing, this remains the most reliable and browser-compatible method: Embed a hidden iframe from a third-party domain. Inside the iframe, attempt to set a test cookie. Use window.postMessage to report success or failure to the parent. This approach works across all major browsers (when properly configured), requires no server (kind of, more on that next), and simulates a real-world third-party scenario. We’ll implement this step-by-step next. Bonus: Sec-Fetch-Storage-Access Chrome (starting in version 133) is introducing Sec-Fetch-Storage-Access, an HTTP request header sent with cross-site requests to indicate whether the iframe has access to unpartitioned cookies. This header is only visible to servers and cannot be accessed via JavaScript. It’s useful for back-end analytics but not applicable for client-side cookie detection. As of May 2025, this feature is only implemented in Chrome and is not supported by other browsers. However, it’s still good to know that it’s part of the evolving ecosystem. Step-by-Step: Detecting Third-Party Cookies Via iFrame So, what did I mean when I said that the last method we looked at “requires no server”? While this method doesn’t require any back-end logic (like server-set cookies or response inspection), it does require access to a separate domain — or at least a cross-site subdomain — to simulate a third-party environment. This means the following: You must serve the test page from a different domain or public subdomain, e.g., example.com and cookietest.example.com, The domain needs HTTPS (for SameSite=None; Secure cookies to work), and You’ll need to host a simple static file (the test page), even if no server code is involved. Once that’s set up, the rest of the logic is fully client-side. Step 1: Create A Cookie Test Page (On A Third-Party Domain) Minimal version (e.g., https://cookietest.example.com/cookie-check.html): <!DOCTYPE html> <html> <body> <script> document.cookie = "thirdparty_test=1; SameSite=None; Secure; Path=/;"; const cookieFound = document.cookie.includes("thirdparty_test=1"); const sendResult = (status) => window.parent?.postMessage(status, "*"); if (cookieFound && document.hasStorageAccess instanceof Function) { document.hasStorageAccess().then((hasAccess) => { sendResult(hasAccess ? "TP_COOKIE_SUPPORTED" : "TP_COOKIE_BLOCKED"); }).catch(() => sendResult("TP_COOKIE_BLOCKED")); } else { sendResult(cookieFound ? "TP_COOKIE_SUPPORTED" : "TP_COOKIE_BLOCKED"); } </script> </body> </html> Make sure the page is served over HTTPS, and the cookie uses SameSite=None; Secure. Without these attributes, modern browsers will silently reject it. Step 2: Embed The iFrame And Listen For The Result On your main page: function checkThirdPartyCookies() { return new Promise((resolve) => { const iframe = document.createElement('iframe'); iframe.style.display = 'none'; iframe.src = "https://cookietest.example.com/cookie-check.html"; // your subdomain document.body.appendChild(iframe); let resolved = false; const cleanup = (result, timedOut = false) => { if (resolved) return; resolved = true; window.removeEventListener('message', onMessage); iframe.remove(); resolve({ thirdPartyCookiesEnabled: result, timedOut }); }; const onMessage = (event) => { if (["TP_COOKIE_SUPPORTED", "TP_COOKIE_BLOCKED"].includes(event.data)) { cleanup(event.data === "TP_COOKIE_SUPPORTED", false); } }; window.addEventListener('message', onMessage); setTimeout(() => cleanup(false, true), 1000); }); } Example usage: checkThirdPartyCookies().then(({ thirdPartyCookiesEnabled, timedOut }) => { if (!thirdPartyCookiesEnabled) { someCookiesBlockedCallback(); // Third-party cookies are blocked. if (timedOut) { // No response received (iframe possibly blocked). // Optional fallback UX goes here. someCookiesBlockedTimeoutCallback(); }; } }); Step 3: Enhance Detection With The Storage Access API In Safari, even when third-party cookies are blocked, users can manually grant access through the Storage Access API — but only in response to a user gesture. Here’s how you could implement that in your iframe test page: <button id="enable-cookies">This embedded content requires cookie access. Click below to continue.</button> <script> document.getElementById('enable-cookies')?.addEventListener('click', async () => { if (document.requestStorageAccess && typeof document.requestStorageAccess === 'function') { try { const granted = await document.requestStorageAccess(); if (granted !== false) { window.parent.postMessage("TP_STORAGE_ACCESS_GRANTED", "*"); } else { window.parent.postMessage("TP_STORAGE_ACCESS_DENIED", "*"); } } catch (e) { window.parent.postMessage("TP_STORAGE_ACCESS_FAILED", "*"); } } }); </script> Then, on the parent page, you can listen for this message and retry detection if needed: // Inside the same onMessage listener from before: if (event.data === "TP_STORAGE_ACCESS_GRANTED") { // Optionally: retry the cookie test, or reload iframe logic checkThirdPartyCookies().then(handleResultAgain); } (Bonus) A Purely Client-Side Fallback (Not Perfect, But Sometimes Necessary) In some situations, you might not have access to a second domain or can’t host third-party content under your control. That makes the iframe method unfeasible. When that’s the case, your best option is to combine multiple signals — basic cookie checks, hasStorageAccess(), localStorage fallbacks, and maybe even passive indicators like load failures or timeouts — to infer whether third-party cookies are likely blocked. The important caveat: This will never be 100% accurate. But, in constrained environments, “better something than nothing” may still improve the UX. Here’s a basic example: async function inferCookieSupportFallback() { let hasCookieAPI = navigator.cookieEnabled; let canSetCookie = false; let hasStorageAccess = false; try { document.cookie = "testfallback=1; SameSite=None; Secure; Path=/;"; canSetCookie = document.cookie.includes("test_fallback=1"); document.cookie = "test_fallback=; Max-Age=0; Path=/;"; } catch (_) { canSetCookie = false; } if (typeof document.hasStorageAccess === "function") { try { hasStorageAccess = await document.hasStorageAccess(); } catch (_) {} } return { inferredThirdPartyCookies: hasCookieAPI && canSetCookie && hasStorageAccess, raw: { hasCookieAPI, canSetCookie, hasStorageAccess } }; } Example usage: inferCookieSupportFallback().then(({ inferredThirdPartyCookies }) => { if (inferredThirdPartyCookies) { console.log("Cookies likely supported. Likely, yes."); } else { console.warn("Cookies may be blocked or partitioned."); // You could inform the user or adjust behavior accordingly } }); Use this fallback when: You’re building a JavaScript-only widget embedded on unknown sites, You don’t control a second domain (or the team refuses to add one), or You just need some visibility into user-side behavior (e.g., debugging UX issues). Don’t rely on it for security-critical logic (e.g., auth gating)! But it may help tailor the user experience, surface warnings, or decide whether to attempt a fallback SSO flow. Again, it’s better to have something rather than nothing. Fallback Strategies When Third-Party Cookies Are Blocked Detecting blocked cookies is only half the battle. Once you know they’re unavailable, what can you do? Here are some practical options that might be useful for you: Redirect-Based Flows For auth-related flows, switch from embedded iframes to top-level redirects. Let the user authenticate directly on the identity provider's site, then redirect back. It works in all browsers, but the UX might be less seamless. Request Storage Access Prompt the user using requestStorageAccess() after a clear UI gesture (Safari requires this). Use this to re-enable cookies without leaving the page. Token-Based Communication Pass session info directly from parent to iframe via: postMessage (with required origin); Query params (e.g., signed JWT in iframe URL). This avoids reliance on cookies entirely but requires coordination between both sides: // Parent const iframe = document.getElementById('my-iframe'); iframe.onload = () => { const token = getAccessTokenSomehow(); // JWT or anything else iframe.contentWindow.postMessage( { type: 'AUTH_TOKEN', token }, 'https://iframe.example.com' // Set the correct origin! ); }; // iframe window.addEventListener('message', (event) => { if (event.origin !== 'https://parent.example.com') return; const { type, token } = event.data; if (type === 'AUTH_TOKEN') { validateAndUseToken(token); // process JWT, init session, etc } }); Partitioned Cookies (CHIPS) Chrome (since version 114) and other Chromium-based browsers now support cookies with the Partitioned attribute (known as CHIPS), allowing per-top-site cookie isolation. This is useful for widgets like chat or embedded forms where cross-site identity isn’t needed. Note: Firefox and Safari don’t support the Partitioned cookie attribute. Firefox enforces cookie partitioning by default using a different mechanism (Total Cookie Protection), while Safari blocks third-party cookies entirely. But be careful, as they are treated as “blocked” by basic detection. Refine your logic if needed. Final Thought: Transparency, Transition, And The Path Forward Third-party cookies are disappearing, albeit gradually and unevenly. Until the transition is complete, your job as a developer is to bridge the gap between technical limitations and real-world user experience. That means: Keep an eye on the standards.APIs like FedCM and Privacy Sandbox features (Topics, Attribution Reporting, Fenced Frames) are reshaping how we handle identity and analytics without relying on cross-site cookies. Combine detection with graceful fallback.Whether it’s offering a redirect flow, using requestStorageAccess(), or falling back to token-based messaging — every small UX improvement adds up. Inform your users.Users shouldn't be left wondering why something worked in one browser but silently broke in another. Don’t let them feel like they did something wrong — just help them move forward. A clear, friendly message can prevent this confusion. The good news? You don’t need a perfect solution today, just a resilient one. By detecting issues early and handling them thoughtfully, you protect both your users and your future architecture, one cookie-less browser at a time. And as seen with Chrome’s pivot away from automatic deprecation, the transition is not always linear. Industry feedback, regulatory oversight, and evolving technical realities continue to shape the time and the solutions. And don’t forget: having something is better than nothing.