今日已更新 302 条资讯 | 累计 41076 条内容
关于我们

标签:#an

找到 3028 篇相关文章

AI 资讯

SOC 2, CRA, NIS2: they all ask your cluster the same five questions

In eleven days, on 11 September 2026, the reporting obligations of the EU Cyber Resilience Act start applying to anyone who puts a product with digital elements on the European market. Not the full regulation. Just the part where, if you find out an actively exploited vulnerability is in your product, you have 24 hours to tell ENISA about it. I have watched a lot of engineering teams meet this class of deadline for the first time. It usually goes the same way. Somebody in sales gets a security questionnaire. Somebody in engineering gets forwarded the questionnaire. Three weeks later there is a shared folder called evidence-final-v3 with 200 screenshots in it, and nobody can tell you which screenshot answers which question. I have spent the last several months building a tool whose entire job is that folder, so I read the instruments properly. This is what I found out. It is written for engineers, not for a compliance team, and I try to be specific about what the text says rather than what a vendor blog says it says. Where SOC 2 came from, and why that still shapes it SOC 2 exists because of a misuse. In 1992 the AICPA published SAS 70, an auditing standard for service organisations. Its purpose was narrow: if you outsourced your payroll, your auditor needed some assurance that your payroll provider's internal controls did not corrupt your financial statements. It was an accounting instrument, for accountants, about financial reporting. Then the industry outsourced everything else. By the mid-2000s companies were sending their customer data to service providers, and they wanted assurance about that , not about financial reporting. There was nothing designed for it, so they asked for the thing that existed. Vendors started waving SAS 70 reports around as proof they were secure. They were not proof of that. SAS 70 had no defined control set at all: the service organisation wrote its own control objectives, and the auditor tested against whatever had been written. Two S

2026-08-31 原文 →
AI 资讯

Mainstreaming RakuAST

Yes, it looks like the next release of Rakudo (2026.09, tentatively planned for 26 September) will be the first Rakudo release that will use the new Raku backend (based on a new grammar producing RakuAST) as the default when compiling a writting in the Raku Programming Language . Until then one had to specify the RAKUDO_RAKUAST=1 environment variable to activate the new backend. It is a major step towards releasing the next Raku language level, tentatively still called "6.e" for historical reasons, later this year. Note that the 2026.09 Rakudo release will not remove the old backend from the core just yet: you will be able to activate the old backend by specifying the RAKUDO_LEGACY=1 environment variable. However, the old backend will be removed when the 6.e Raku language level is released. So it is very important to check what these changes will mean for you! Immediate effects So what will a user of this Rakudo release notice with their apps and libraries? Nothing In the past weeks the Raku ecosystem has been thoroughly scoured for code that would stop functioning in RakuAST. Some finds turned out to be omissions / errors in the RakuAST implementation (which then have been fixed). Others turned out to be modules doing (semi-)naughty things, for which Pull Requests were made to ensure they will continue to operate in RakuAST. Running slower It could well be that your code is running without issues, but all of a sudden runs slower than before. Years of optimizing the old backend were mostly lost in RakuAST. And had to be re-created in the RakuAST-based backend. Which may have lost a few nooks and crannies that affect the execution speed of your code. Slower execution should be reported as a bug, so that it can be fixed! Running faster One of the goals of the RakuAST projects was to be able to provide better optmizations. Some of the ideas for these optimizations have already been implemented in RakuAST. And as a part of this work, a lot of aspects of the runtime have

2026-08-31 原文 →
AI 资讯

Moving a password to another device without syncing your vault

The password is in your password manager, exactly where it should be. The login prompt is on a different device. Perhaps you are preparing an Android device for a maintenance task. It needs one service password. You do not want to sign it into your email account or give it access to the rest of your password vault just to fill in that field. Typing the password manually is an option. Sending it to yourself is another. Neither is particularly appealing when the value is long, the task is temporary, and you are trying to avoid creating unnecessary copies. We build WithinCells at schukai for this kind of handoff. The question behind it is deliberately narrow: how do you get one secret onto the device that needs it, without setting up more access than the task requires? Transfer is a different job from storage I do not see a handoff tool as a replacement for a password manager. Your vault should remain the place where you organise and retrieve credentials. A transfer tool has a smaller job: help you deliver a selected value to a selected destination. Where your existing password manager already handles that well, use it. There is no benefit in adding another application just to repeat a working process. The interesting case is the exception: a temporary device, a one-off setup, or a login where the usual workflow is unavailable. That is also where I would draw the line. Manually moving a credential for one maintenance task is different from distributing secrets across a fleet. For the latter, use managed provisioning and automated secrets management rather than scaling up manual transfers. OWASP recommends reducing human handling of secrets where possible. ¹ The QR code is the package, not a download link WithinCells uses QR-based device pairing. Transfers are encrypted for the chosen recipient and signed by the sender. In QR mode, the code holds the encrypted transfer itself, rather than a URL for retrieving it. The handoff needs neither a shared network nor a cloud ac

2026-08-31 原文 →
AI 资讯

Automating Excel Merges with Power Automate: A Deep Dive into Workflow Automation and Data Cleaning

Dealing with multiple Excel or CSV files is a common task in business. Whether it is sales reports from different regions, customer data across various campaigns, or financial records by month, the need to combine these files into a single, cohesive dataset is constant. Manually copying and pasting or even using complex formulas can quickly become a time sink, prone to errors, and a source of frustration. What if you could automate this repetitive process? Imagine setting up a workflow that automatically merges your Excel files for you. That is where Microsoft Power Automate comes in. And when your data is messy, inconsistent, or riddled with duplicates, AI tools can take your automation to the next level. This guide will walk you through building robust workflows in Power Automate to combine your Excel workbooks. We will also explore how AI can address the often overlooked challenge of data cleaning and standardization, turning disparate data into a clean, unified source. Why Automate Excel Merges? The benefits of automating Excel data consolidation extend beyond simply saving time. Consider these advantages: Time Savings: Free up hours spent on manual data handling, allowing you to focus on analysis and strategic tasks. Reduced Errors: Eliminate human error from copy-pasting, formula mistakes, or missing data. Consistency: Ensure data is merged and formatted uniformly every time, regardless of who runs the process. Scalability: Easily handle increasing volumes of files without proportional increases in manual effort. Timeliness: Get up-to-date consolidated reports faster, enabling quicker decision-making. The Old Way: Manual Merges and VBA Limitations For years, consolidating data meant either painstaking manual copy-pasting, using VLOOKUP or INDEX/MATCH across sheets, or resorting to VBA (Visual Basic for Applications) scripts. Manual methods are slow and error-prone, especially with large datasets or many files. VBA offered a significant improvement, providing c

2026-08-31 原文 →
AI 资讯

Foundry Model Router Expands from Two Regions to 28, Refreshing Its Model Pool

Microsoft expanded Foundry's model router from two regions to 28 for global standard and 21 for data zone deployments, while adding Claude Opus 4.8 and GPT-5.6 and removing four deprecated models. Default deployments receive pool changes automatically; configured subsets exclude new models until added. The effective context window equals the smallest model in the pool. By Steef-Jan Wiggers

2026-08-31 原文 →
AI 资讯

Building Shoots: a hybrid event-driven agent system for photography

I created this article for the purposes of entering the All Things Agentic Hackathon. Shoots is an Android and web photography Companion. A photographer takes ordinary Shots. Shoots reviews them in the background, preserves the Evidence behind its reading, and can offer one optional Experiment when the record supports it. This is the technical version of the project. It is about how a file becomes a durable learning record, how the agents communicate, and where I deliberately refused to let a model make the decision. The design in one sentence The model panel reads a single Shot. The system around it does the work: it creates a durable Run, moves tiny events through independently retryable stages, re-reads state at every boundary, records every outcome, and only settles a Shoot after every member Run is accounted for. That distinction matters. I did not want a chain of agents passing prose to one another until it sounded convincing. I wanted constrained model calls inside a workflow whose state, retries, and outputs could be inspected later. Repository structure The codebase is deliberately split by responsibility rather than by screen or agent name: android/ phone/ # approved Camera media work/ # background upload and retry data/ # cache, API, identity ui/ # Android screens backend/app/ api/ # FastAPI ingress and push endpoints domain/ # pure rules and state transitions imaging/ # EXIF, pixels, visual artifacts agents/ # ADK agents and prompts services/ # workflow orchestration infra/ # storage, Pub/Sub, Drive, secrets frontend/src/ stores/ # API and SSE state pages/ # web audit desk components/ # receipts and visual Evidence infra/ # Google Cloud deployment and Scheduler The important boundary is domain/ . It has no I/O. It owns the rules that must be reproducible: grid-cell conversion, taxonomy validation, panel consensus, Criteria checks, Technique Map projections, and Run state transitions. services/ can call models and storage. domain/ cannot. Two kinds of orc

2026-08-31 原文 →
AI 资讯

SskCore: Turning Production Pain Into an Android Platform [PART-7]

Text-to-Speech Is Not a speak() Call The challenge 🧪 If you have ever assumed Text-to-Speech on Android is straightforward, this article is for you. But first, let us test your skills. Think you can make this speak on Android? 🙏 अव्यक्तोऽयमचिन्त्योऽयमविकार्योऽयमुच्यते । "Invisible, beyond thought, unchanging." — Krishna describing the nature of the self. Today is World Sanskrit Day, so the timing is fitting. 🕉️ Try playing it on the plain TextToSpeech API that Google provides — but specifically with a Sanskrit voice. Build a minimal Android app, initialize the TTS engine, set the language to Sanskrit, and call speak() on this string. Chances are it will not speak anything. Not even a single letter would be uttered. 🔇 That is the moment when a developer realizes that TTS is not a simple API call. The twist 🔄 Use a Marathi or Hindi voice instead. Same engine. Same text. Same API call. It plays perfectly. 🗣️ Same engine. Same verse. Different voice. Completely different result. The boundary between "speakable" and "not speakable" is not at the engine level. It is at the voice level within the engine. The Sanskrit voice within Google's TTS engine cannot handle this verse. But the Marathi voice — which shares much of the same Devanagari character set — handles it without issue. This changes how you think about TTS integration. What happened in production 🏭 This is not a theoretical exercise. This is what we actually hit. In Bhagavad Gita, the player screen uses TTS to read verses aloud. The experience is designed to feel like playing a media file: continuous, flowing, uninterrupted. But certain words — especially compound words and special conjunct characters — were being silently skipped. Not errored. Not logged. Just... silent. The engine would skip the entire word if it couldn't speak something in it. So a verse that should take 15 seconds to read would finish in 8. The user would hear a flowing recitation with missing pieces and never know what was lost. 😶 The worst

2026-08-31 原文 →
AI 资讯

Android Developer Verification hits Brazil on September 30

Google's developer verification requirement starts enforcing in about a month, and Brazil is one of the four countries it lands in first. If you work here, this is not a 2027 problem you get to read about later. Most of the coverage I've seen frames this as a sideloading story, or an F-Droid story, or an "Android is losing its freedom" story. Those are real arguments, but they're not the thing that's going to interrupt my week. The thing that's going to interrupt my week is much smaller and much more annoying: how a build gets onto a QA engineer's physical phone. The rule, in one paragraph From September 30, 2026, apps installed on certified Android devices in Brazil, Indonesia, Singapore and Thailand must be registered to a verified developer. Certified devices are roughly 95% of Android outside China. The requirement applies whether the app came from Play, from an alternative store, or from an APK you downloaded off a link. Verification means an identity check plus registering each package name against the SHA-256 fingerprint of its signing key. Global rollout follows in 2027. Two things matter for how you read that. It's the package name that gets registered, not the app in some abstract sense. And it's tied to a specific signing key. What does not break Before the panic, the exemptions are wide, and if you only skim one section, skim this one. ADB installs are unaffected. Local development and testing over adb install keep working exactly as they do today. Google has been explicit about this. Enterprise deployment is exempt. Apps installed through an EMM Device Policy Controller, or published as private apps in Managed Google Play, are exempt indefinitely. If your organization ships to managed clinic devices through an MDM, that path is fine. If you're already on Play, you're probably already done. In March 2026, Google auto-registered package names and signing keys for the large majority of existing Play apps under the accounts that own them. Worth confirming i

2026-08-31 原文 →
AI 资讯

I Built an Autonomous AI Agent That Hunts Bounties. Here's What Happened.

I Built an Autonomous AI Agent That Hunts Bounties. Here's What Happened. The Setup I gave an AI agent one job: find paid work online, build the deliverable, and earn money — autonomously. Not a chatbot. Not a copilot. An agent that scans 232+ listings across multiple platforms, filters out scams and ghost sponsors, writes proposals, generates deliverables with real market data, and queues everything for human approval. Here's what happened in the first 48 hours. The Stack (All Free) Python core — pipeline orchestration, economic gate, critic Ollama + qwen3:4b — local LLM for analysis writing (no API costs) Chart.js — dashboard visualizations Public APIs — CoinGecko, DeFiLlama, Solana RPC (all keyless) GitHub Pages — free hosting for the portfolio Windows Task Scheduler — runs every day at 9 AM + every 4 hours Total infrastructure cost: $0/month. What the Agent Actually Does Every Morning 09:00 — Wake up ├── Check-in on AgentHansa (earn $0.01 USDC daily drip) ├── Scan Superteam Earn (232 live listings) ├── Scan Clawlancer/TaskForce/MoltJobs for gigs ├── Scan GitHub for paid issues ($20-500 fixes) ├── Filter through 7 anti-scam layers: │ geo restrictions, human-presence demands, │ ghost sponsors (no web/twitter/verification), │ unverified payers, real-money requirements ├── Economic gate: expected value must be positive ├── Local LLM critic reviews against actual page content └── If candidate passes everything: → Build deliverable (report/dashboard/thread draft) → Generate proposal text → Send Telegram alert with approval command The Filters That Saved Me In the first 24 hours, the agent found 232 listings. After filtering: Filter Killed HUMAN_ONLY access 216 Ghost sponsors (no identity) 1 (would've wasted hours) Real-money deposit required 1 ($1000 bug bounty trap) Country walls 1 (Superteam Canada only) Already claimed/stale Rest Without these filters, I would have wasted days on bounties that were never going to pay. The First Deliverable The agent found a $500 bo

2026-08-31 原文 →
AI 资讯

Production Flutter Networking Without the Boilerplate: Reactive Repositories with BlocSignal

The Networking Architecture Dilemma in Production Flutter If you survey ten seasoned Flutter developers about how they structure networking in production, you will almost certainly see the same multi-tiered pipeline: ┌────────────────────────────────────────────────────────────────────────┐ │ Traditional Flutter Networking Pipeline │ ├────────────────────────────────────────────────────────────────────────┤ │ [Dio / HTTP Client] ─▶ [API Service] ─▶ [Repository Layer] ─▶ │ │ [Cubit / BLoC] ─▶ [UI Builders & Banners] │ └────────────────────────────────────────────────────────────────────────┘ The underlying architectural principles are sound: separation of concerns, testability, and isolating network transport details from UI widgets. However, in practice, this classical layered stack demands an enormous amount of repetitive boilerplate: Async State Union Ceremony : Defining four separate state classes ( Initial , Loading , Success(data) , Failure(error) ) or union types for every single API endpoint. Race Conditions & In-Flight Cancellation : When users type queries or switch tabs rapidly, requests finish out of order. Preventing stale responses requires complex Dio CancelToken plumbing or heavy rxdart switchMap streams. Offline Caching & "Stale-While-Revalidate" : Showing cached data on Frame 1 while fetching fresh updates in the background usually requires database synchronization and stream merging logic. The Repository vs. Controller Divide : Repositories hold data and caching logic, while BLoCs or Cubits hold reactive state. Because Dart only allows single inheritance, developers end up maintaining two separate class hierarchies connected by verbose dependency injection glue. With bloc_signals , we can preserve complete separation of concerns while eliminating 70% of the friction. Let us examine how to architect a modern, clean, production-ready networking layer using CubitSignalMixin , HydratedMixin , and .toAsyncBlocSignal() . ⚡ 1. Symmetrical Async Projection

2026-08-31 原文 →
AI 资讯

Hybrid encryption: why combine classical and post-quantum cryptography

When a new cryptographic algorithm appears, a tension shows up: classical algorithms such as X25519 or Ed25519 have resisted attacks for years, but are vulnerable to a future quantum computer; post-quantum ones such as ML-KEM or ML-DSA resist quantum attacks, but are newer and less tested. Hybrid encryption resolves the tension: use both at once . The idea in one sentence Combine a classical and a post-quantum algorithm so that the system only breaks if both fail simultaneously . A classical attacker would have to break the post-quantum algorithm; a quantum attacker would have to break the classical one and the post-quantum one. You gain security against the future without betting everything on a young algorithm. Two places to apply it Key exchange (encrypting for a recipient). You combine: X25519 — classical key exchange, fast and heavily tested. ML-KEM-1024 — NIST's post-quantum key encapsulation mechanism, at its highest level. The two resulting keys are mixed with a context-bound derivation function (HKDF), so that neither one alone is enough. Digital signatures (authenticity). You combine: Ed25519 — classical signature. ML-DSA-87 — NIST post-quantum signature. The message is accepted only if both signatures verify — an AND combiner. One principle that never breaks There is a golden rule in cryptography, Kerckhoffs's principle : a system must be secure even if the attacker knows its entire design; security lives in the key , not in hiding the format. A good hybrid system uses public, audited primitives — XChaCha20-Poly1305 to encrypt, Argon2id to derive keys from passwords, HKDF to separate domains — and never invents its own cryptography . How Quipu applies it Quipu is a free library implementing exactly this approach for data at rest : hybrid X25519 + ML-KEM-1024 encryption, hybrid Ed25519 + ML-DSA-87 signatures, and only verified primitives underneath. It targets NIST security level 5 (CNSA 2.0) and is open source, so anyone can review how it works. An honest

2026-08-31 原文 →