Blogger

by: Daniel Schwarz Fri, 12 Dec 2025 14:38:18 +0000 I’ll admit, when container queries first shipped back in 2022, I didn’t really pay attention. I mean, why container size queries when we already have media queries? Why container style queries when custom properties inherit anyway (they don’t work with standard properties… yet)? Their use cases seemed like edge cases to me, enabling us to do things that we could already do but in a different way. Here’s a container size queries demo by Kevin Powell. As a note, all major browsers support size queries in the following demo, but other demos in this article may require the latest Chrome. CodePen Embed Fallback Container style queries (with the new range syntax) demo by, uh, me: CodePen Embed Fallback And more recently, we’ve seen a couple more types of container queries pop up. Container Scroll-State Queries Container scroll-state queries came along with their unique capabilities — the ability to find out whether a container is scrollable, or is scroll-snapped to a scroll target, or has position: sticky and is ‘stuck.’ Literally, as I’m writing this, Chrome announced scrolled support, which is a bit different to scrollable. Container scroll-state queries demo by our very own Geoff Graham: CodePen Embed Fallback And that’s not all we’ve got… Anchored container queries The latest container query feature is anchored container queries, which enable us to query fallback positions. Imagine that you anchor-position a tooltip caret to the left side of a tooltip, but then there’s no room to display the tooltip, so you flip it to the opposite side of whatever triggers it using position-try-fallbacks: flip-inline. Well, an anchored container query can detect when the tooltip position is flipped so that we can also flip the tooltip caret to the opposite side of the tooltip. CodePen Embed Fallback What else? So, it got me thinking, how far can we really go with container queries? There are dozens of media queries now, so what if there were dozens of container queries as well? What could we use them for? Get any computed value Recently I was exploring the current and future methods of getting the value of a CSS property and using it with another property, and as you can imagine, container size queries were mentioned since they unlock container query units. I mean, have you ever added a wrapper element or defined an existing one as a container just to access container query units? <parent> { /* Gimme container query units! */ container-type: inline-size; <child> { width: 100cqi; } } Now, I don’t love container queries as a means of getting values because the syntax can be a bit long-winded for that (longer than the example above, and size queries in particular are a bit quirky), but the fact that we can use them to do a little more than querying is testament to how versatile they are as a feature. As an alternative, I suggested a CSS function called compute(), where if you wanted the height of something (or the “something” of anything), we could steal it from another element like this: <parent> { <child> { /* Computed height of <child> */ property: compute(height, self); /* Computed height of the parent */ property: compute(height, inherit); /* Computed height of #abc element */ property: compute(height, #abc); } } This would save us from having to implement a container size query just to use its container query units, and would also apply to all properties. Besides, a container size query wouldn’t help us to acquire the un-computed declared value that we actually typed out. For that, the inherit() function has been proposed and Roma even shows us how to use it in Chrome Canary. To add, I really like the keyword approach and would love to see more keywords like currentColor (e.g., currentBackgroundColor has been proposed). Still, if container queries could be extended to get the value of any CSS property, I definitely wouldn’t say no to that! The flexibility to pass properties/values between elements is way too enticing. Query any CSS property This feature has actually been on the slate since container style queries were first proposed, but there’s no telling when it will arrive. This container style query upgrade will enable us to query the (un-computed/declared) value of any CSS property instead of just custom properties (although you won’t be able to ‘get’ and use those values, at least as far as I know). Any CSS property? Uh, doesn’t that make all of the other container queries redundant? Not quite, no. Container scroll-state queries detect snapping and stickiness, for which there are no pseudo-classes — but maybe there should be? They also detect scrollability, since, for example, overflow: scroll and overflow: visible doesn’t mean that the content is actually overflowing, only that we’re allowed to scroll the container if it does. Finally, anchored container queries don’t query the position-try-fallbacks value, they detect when, for example, the position-area is flipped. So, you know, they do a whole bunch of stuff, and that’s why this upgrade for container style queries won’t replace them. In fact, I can totally see dozens of new container query features hitting the web within the next few years. So, what else could container queries do? Before container queries were even a thing, great ideas were being put forward. Of course, some of them actually became container queries whereas others are still just that — great ideas that haven’t gone anywhere (again…yet?). Adam Argyle suggested some interesting things that would later become scroll-state queries, in addition to being able to query whether something’s on-screen, wrapping, or ellipsing, which I’d love to see. Adam also suggested being able to count child nodes, an idea that later became sibling-count() and sibling-index(), although I’d still like to see the container query approach. In a similar vein, Matthew Dean pointed out that some container queries could instead or also be pseudo-classes, which I agree with. Matthew also suggested that container queries could be used to query whether a flex container is wrapped, and which row/column of a flexbox/grid container we’re in. I’m confident that we’ll see these ideas realized at some point, either as container queries or as some other syntax. Heck, since it’s December, I’ll make it my prediction for 2026: container queries will rule 2026. What else do you want container queries to do? References Learn container queries with interactive examples (Ahmad Shadeed) Detect fallback positions with anchored container queries from Chrome 143 (Una Kravets) Play With Inherit Function (Roma Komarov) On Inheriting and Sharing Property Values (Daniel Schwarz) Browser support for current and future container queries (CanIUse) What Else Could Container Queries… Query? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

by: Sourav Rudra Fri, 12 Dec 2025 19:42:52 +0530 After years of development, System76's Rust-based desktop delivers.

by: Abhishek Prakash Fri, 12 Dec 2025 16:31:28 +0530 I have been exploring the options to offer replayable playgrounds to complement the text and video learning resources. Is this something you would be interested in? Personally, I prefer trying things on my own machine but these playgrounds also help a learner jump straight into a pre-configured environment to focus on a specific task. Let me know what you think of it.       This post is for subscribers only Subscribe now Already have an account? Sign in

by: Sourav Rudra Fri, 12 Dec 2025 13:29:18 +0530 The update also introduces notification badges and theme categorization.

by: Hangga Aji Sayekti Fri, 12 Dec 2025 13:22:51 +0530 Most people know Kali Linux for its tools, but one of its most underrated strengths is the collection of wordlists it ships with. These wordlists are carefully curated from real breaches, common naming patterns, predictable directory names, and default credentials. They form the backbone of most brute force and fuzzing attacks. When I started learning offensive security, I used to download random wordlists from the internet because everyone recommended “bigger lists mean better results.” The truth is different. Kali’s default wordlists are already powerful, practical, and more than enough for real-world scenarios. You do not always need millions of lines to find something meaningful. Why wordlists still matter?Brute forcing is often misunderstood. It is not about trying every possible combination from aaa to zzzzzz. Modern brute force attacks are driven by smart, context-aware wordlists. A strong wordlist gives you: • Higher success probability • Shorter attack time • More realistic test coverage • Reduced noise during assessments This matters because weak, default, and leaked passwords are still extremely common in real systems. Large-scale attacks like the Mirai botnet and malware families such as Remaiten and BrickerBot succeeded largely by testing small sets of predictable credentials. Honeypot studies also show that attackers continue to reuse passwords found in public leaks, especially entries from the RockYou list that is included in Kali Linux. As long as weak passwords remain widespread, high-quality wordlists will stay essential for both attackers and penetration testers. Where does Kali stores its wordlists?Kali keeps most of its wordlists here: ls -lah /usr/share/wordlists/ You will find several directories, each maintained by different tools. Some lists are massive, others small and focused. All of them serve a purpose. Most important default wordlists with detailsThe table below gives a clean, SEO-friendly overview of the most useful wordlists included in Kali. Wordlist Name Location Size Best For Description RockYou /usr/share/wordlists/rockyou.txt.gz ~14M entries Password brute forcing Real leaked passwords. One of the most successful lists ever used in pentesting. Must be unzipped first. DIRB Wordlists /usr/share/dirb/wordlists Various Directory and file discovery Contains common folder names, web paths, extensions, admin routes, and CMS directories. WFuzz Wordlists /usr/share/wfuzz/wordlist Various Parameter fuzzing Includes parameter names, API tokens, headers, and predictable variables. Metasploit Wordlists /usr/share/metasploit-framework/data/wordlists Small Default credentials Good for testing weak or factory-default logins. Useful on internal environments. These lists cover most real-world pentest flows without requiring any external downloads. Preparing the RockYou wordlistRockYou is compressed, so unzip it first: sudo gzip -d /usr/share/wordlists/rockyou.txt.gz You can glance at the first entries: head /usr/share/wordlists/rockyou.txt This list is extremely effective for testing weak or common passwords on login forms. Understanding the targetLike all the practice exercises in our PenTest lab, we are going to use vulnweb.com, as this site exists specifically for security testing, so everything here is ethical and allowed. For demonstration, we will attack this intentionally vulnerable login form: It includes two POST parameters: unamepassYou can confirm the fields by viewing the HTML: This simplicity makes it a perfect example for beginners practicing brute forcing with Hydra. Brute Forcing The Login Using Hydra And RockYouHydra is preinstalled in Kali and optimized for speed. The basic syntax is not too complicated: hydra -l <username> -P <wordlist> <target> <module> <options> Let us start with a common username such as admin and attack this form on the target website: hydra -l admin -P /usr/share/wordlists/rockyou.txt \ testphp.vulnweb.com \ http-post-form "/login.php:uname=^USER^&pass=^PASS^:Invalid username" Let's see the results: 📋Hydra reports every password that does not trigger the failure string as a valid hit. Because the demo target at testphp.vulnweb.com is intentionally vulnerable, it accepts many common RockYou passwords as “correct,” which is why you see multiple successful results. In real environment, you normally expect only one valid password. The output also confirms the number of attempts, parallel tasks, and the module configuration Hydra used during the attack. Customizing wordlists for faster and smarter brute forcingSometimes RockYou is too large for a quick test. You can easily create more targeted wordlists. For example, extract passwords with exactly six characters: sudo awk 'length($0) == 6' rockyou.txt | sudo tee rockyou-6.txt Or, filter only alphanumeric passwords: grep -E "^[A-Za-z0-9]+$" rockyou.txt | sudo tee alphanumeric.txt Shorter lists allow you to test quickly without sacrificing relevance. Directory discovery with DIRB wordlistsKali’s DIRB lists are excellent for web exploration. Example scan: dirb http://testphp.vulnweb.com /usr/share/dirb/wordlists/common.txt These lists often reveal hidden paths such as admin routes, backup directories, or exposed config files. Parameter discovery with WFuzz wordlistsWFuzz excels at fuzzing parameters and variables. wfuzz -c -w /usr/share/wfuzz/wordlist/general/common.txt \ -u "http://testphp.vulnweb.com/login.php?FUZZ=test" This technique helps uncover hidden parameters that are not visible in the page’s HTML source. ConclusionKali Linux quietly ships with some of the most practical and battle-tested wordlists you can use as a beginner or professional pentester. From RockYou for classic password attacks to DIRB and WFuzz for exploring web applications, these lists cover nearly everything you need to simulate real-world scenarios. If you are learning cybersecurity, the best next step is simply to experiment. Choose a safe target, start with small wordlists, slowly increase complexity, and observe how your results change. Over time, you will learn which lists work best for which situations.

by: Abhishek Prakash Fri, 12 Dec 2025 12:33:39 +0530 Insights from an Interview with Hirdaypal Singh Lamba, Salesforce Consultant.

by: Sourav Rudra Thu, 11 Dec 2025 18:02:52 +0530 Arti, the Rust rewrite of Tor, brings circuit isolation and onion service improvements in its 1.8.0 release.

by: Sourav Rudra Thu, 11 Dec 2025 18:02:52 +0530 Arti, the Rust rewrite of Tor, brings circuit isolation and onion service improvements in its 1.8.0 release.

by: Abhishek Prakash Thu, 11 Dec 2025 10:01:55 +0530 Gearing up for Tuxmas season 🎅

by: Pulkit Chandak Wed, 10 Dec 2025 22:45:23 +0530 Building a NAS in your homelab? Here are the choices of operating systems you can use.

by: Preethi Wed, 10 Dec 2025 15:04:08 +0000 The CSS animation-timeline property accepts a view() function which, in turn, returns a timeline of how much of an element is visible in the part of a scroll container that’s viewable (formally known as a scrollport). In other words, rather than letting an animation run a linear progression based on how much time has elapsed, view() runs animations based on the visibility of the animated element within a scrollport. I like to equate it as the CSS version of JavaScript’s Intersection Observer. We can run an animation on an element as that element enters and exits the scrollport. Here’s an example: CodePen Embed Fallback Pretty neat, right? Depending on where an image is in the scrollable carousel, it goes from small and blurry at the far sides while getting larger and clearer when it hits the center. We have a little scroll snapping in there as well to make sure each image item makes a stop. It’s not that hard to do! I’ll show you how it’s really the same old animation you’re used to writing in CSS, only applied on a view timeline instead of a normal timeline. But first, the general layout All I’m making here is an element I’m calling .carousel: <main class="carousel"> <!-- scroll items --> </main> The elements in .carousel will lay out in a single row, which is a one-liner with flexbox. We’ll also make sure that any content overflowing its space is scrollable: .carousel { display: flex; width: max(480px, 50vw); overflow-x: auto; } And, of course, we need items in it that we can scroll around. A set of image slides. <main class="carousel"> <div class="carousel-slide"> <!-- (optional) empty bookend slide --> </div> <div class="carousel-slide"> <img src="image-1.jpeg" alt="alt text for image 1"> </div> <div class="carousel-slide"> <img src="image-2.jpeg" alt="alt text for image 2"> </div> <!-- etc --> <div class="carousel-slide"> <!-- (optional) empty bookend slide --> </div> </main> As far as styling those items, each one will be one-third the size of the available space so that we see three items at a time when scrolling: .carousel { /* same as before */ .carousel-slide { flex-shrink: 0; width: calc(100% / 3); /* show three at a time */ aspect-ratio: .8; img { width: 100%; } } } Then the scrolling We’ve already set overflow-x on the .carousel, officially making it our scroll container. We can drop in a little scroll snapping to make sure we’re only scrolling one item at a time. .carousel { /* same as before */ scroll-snap-type: x mandatory; scroll-behavior: smooth; /* optional for smooth scrolling */ scrollbar-width: none; /* optional to hide the scrollbar */ } We want to make sure that the slides are aligned to the center of the scroll container when snapping into place: .carousel-slide { /* etc. */ scroll-snap-align: center; } Here’s what we have so far: CodePen Embed Fallback Next, the animation Here’s the really cool thing I mentioned at the very start: a view timeline animation is really the same thing as any other CSS animation you write with keyframes. In this case, we want keyframes where the carousel items are small and blurry at the start and end, but become larger and clearer right smack dab in the middle of the animation. @keyframes slide { /* from start to 45%, and to the end (100%) */ 45%, 100% { transform: scale(0.5); border-radius: 20px; filter: blur(6px) brightness(.8); } /* middle */ 50% { transform: scale(1); border-radius: 4px; filter: none; } } Looks familiar, right? This is the sort of CSS you’ve been writing forever! And guess what? We set the animation on the element we’re animating just as you normally would as well: .carousel-slide { /* etc. */ animation: slide; } The only difference is that we want the animation to run on a timeline based on the element’s current view() instead of the regular timeline. That’s where the animation-timeline property comes into play: .carousel-slide { /* etc. */ animation: slide; animation-timeline: view(inline); } Now, technically speaking, we could slap that timeline directly in the animation shorthand property like any other constituent animation property, e.g., animation-name, animation-delay, animation-duration, etc. But assigning a timeline function this way is not supported by any browsers yet. So, for now, your best bet is to declare it on its own. Just be sure to declare it after the animation shorthand, or else you may find yourself inadvertently overriding your view timeline with auto (the default property value) instead of view(). That completes our demo: CodePen Embed Fallback See that? All we’ve really done is set a CSS animation that runs on elements. However, instead of running on the default timeline, the animation runs when an element scrolls in and out of view. That’s the difference between standard and view timelines. view() vs. scroll() But wait! You may or may not know that view() timelines are part of a larger feature set called CSS Scroll-Driven Animations. And view() is not the only function supported by the animation-timeline property. We also have the scroll() function. The scroll() function creates a scroll progress timeline that’s tied to the scroll position of a container, whereas view() creates a view progress timeline that’s based on the visibility of an element within its container. Both functions are useful in their own ways! I generally think view() is better for item-specific reveal effects. So, for example, if we want to animate a slide only as that specific slide scrolls into the scrollport, then the view() function is the perfect fit. That’s why I’ve focused on it for our carousel example — we want to track an element’s position in the scrollport and run the animation accordingly. Inset parameter and animation-range You might also be wondering what the heck goes in the parentheses of the view() function. It’s a function, after all, so it must accept something in there, right? CSS view() takes two arguments: axis (block, inline, x, and y) and the inset. The inset parameter defines an offset from the scrollport’s edges within which the animated element is tracked. The official syntax looks like this: animation-timeline: view(<axis> <view-timeline-inset>); …which is merely a fancy way of getting specific with exactly what areas of the scrollport we want to trigger the animation. For some animations, starting and ending the timeline when element fully enters and exits the scrollport may cut things off. CodePen Embed Fallback That’s no good! We want each item to fully slide in when it fully enters the scrollport, not when it fully exits. That’s why all the items look so staggered — they’re all at different points in the view timeline. That’s where the inset parameter makes a big difference. We can be more specific about saying we want each element to start animation when it comes up from the bottom of the scrollport. animation: slide-in linear both; animation-timeline: view(100% 0%); Ah, much much better: CodePen Embed Fallback The animation-range property works along similar lines. animation-range: entry; /* same as: entry 0 entry 100%; */ CodePen Embed Fallback The animation-range property accepts a slew of other keywords, including exit (when the element leaves the scrollport), cover (when the element begins to enter begins to leave the scrollport), and contain (when the element fully enters then fully leaves the scrollport), among others. Geoff has published a bunch of notes and examples looking specifically at each one. One last carousel example Generally, carousels use effects like fade in-and-out, scaling, and parallax. However, since most CSS properties are animate-able, and even those who aren’t can be tricked into being so using registered CSS properties (like in the case of gradient lines), you have the option to explore more creative ways of using view() for carousels. Here’s an example where an animation of just the background position creates a nice movement in a carousel. CodePen Embed Fallback Creating Scroll-Based Animations in Full view() originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

by: Sourav Rudra Wed, 10 Dec 2025 19:39:28 +0530 The Divine D. is set to come with LoRa networking, hardware privacy switches, and local AI processing.

by: Sourav Rudra Wed, 10 Dec 2025 16:18:58 +0530 Canonical teams up with AMD to package ROCm directly in Ubuntu.

by: Sourav Rudra Wed, 10 Dec 2025 15:08:07 +0530 Anthropic's MCP, Block's goose, and OpenAI's AGENTS.md form the foundation of this new initiative.

by: Roland Taylor Wed, 10 Dec 2025 08:27:07 +0530 An in-depth look at 'another new Chromium-based web browser" that is "different from the other Chromium-based web browsers".