找到 283 篇相关文章
A preview of the September cohorts of the InfoQ Online Certification Programs, and the facilitators leading them: Luca Mezzalira, Michelle Brush, Zichuan Xiong, and Premanand Chandrasekaran. By Artenisa Chatziou
Zero-knowledge proofs let a verifier confirm a face matches an ID, or that a liveness check passed, without ever holding the raw biometric data. Here's how the mechanism actually works, what it prevents, and how close the identity industry is to shipping it in production KYC. Every biometric verification vendor holds a face. Somewhere in its pipeline, encrypted at rest or not, sits the selfie captured at onboarding, or at minimum the feature vector extracted from it, the data a face-match algorithm needs to compare against an identity document's photo. That data has to exist somewhere for the comparison to run, or so the assumption goes, and it's the assumption behind every biometric vendor's retention policy, every breach-notification clause in a KYC contract, and every regulator's demand for encryption-at-rest audits on data GDPR already classifies as special category. Zero-knowledge proofs applied to biometric data start from a different premise: the comparison can happen and a verifier can trust the result without the verifier, or anyone downstream of the enrollment step, ever holding the raw face data that produced it. This is a narrower and newer problem than the zero-knowledge work most identity teams have already encountered. Verifiable Credentials and Zero-Knowledge Proofs, Explained covers zero-knowledge proofs applied to a credential's fields, proving a birthdate claim without revealing the birthdate itself. Applying the same cryptographic idea to biometric data, a face template or a liveness result rather than a declared attribute, is a different and less-covered piece of the same puzzle. This post works through what zero-knowledge biometric verification actually is, how it differs from the credential-level version, and how close the identity industry actually is to shipping it in a production KYC flow rather than a research paper. Biometric Verification vs. Zero-Knowledge Proofs: Where They Meet Biometric verification today runs the same basic pipeline
Disclosure: I work on Tessera, which is self-hosted. That is the position I am arguing from, and the costs of that position are in the last section. Security questionnaires ask where customer data is processed. Access-control tools tend to get a shallow answer to that question, because people think of them as gatekeepers rather than as data processors. They are both. Here is what a hosted access broker necessarily knows about you. Your infrastructure inventory. Every registered target: hostnames, addresses, cluster endpoints, database names, environment labels. That is a map of your estate, and it is the document an attacker would most like to read before deciding where to spend effort. Your organisational structure. Who has access to what, which teams exist, who approves for whom, who was granted production access at 2am during an incident. Org charts are inferable from access graphs with unpleasant accuracy. Your session content, if recording is on. Every command, every query, every screen of output. That includes whatever your engineers pasted into a terminal, which — be honest about your own estate here — includes secrets sometimes. Timing. When your incidents happen, how long they last, who gets pulled in. That is commercially sensitive on its own. None of that requires the vendor to hold your credentials. It is the metadata, and the metadata is the part that survives every architectural mitigation. Where this shows up GDPR and processor chains. Session recordings contain personal data — identified individuals performing identified actions at identified times. A hosted vendor is a processor, which means a DPA, transfer mechanisms if data leaves the EEA, and a sub-processor list you have to monitor. It also means their sub-processors become your problem, which is a chain you do not control and cannot easily audit. Sector rules. Financial services, healthcare and public sector procurement in most European jurisdictions have specific requirements about where data
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
James Hall discusses the strategic and technical imperative of moving AI workloads from cloud providers to local edge devices. He shares practical approaches using WebGPU, Transformers.js, and DuckDB to achieve near-native performance in JavaScript. Through real-world case studies, he explains how to minimize data privacy risks, optimize browser inference, and build rigorous evaluation suites. By James Hall
If you ship anything that touches AI-generated images — a thumbnail pipeline, a user-upload feature, a design tool — you've probably noticed something: the images your model spits out are heavier than they should be, and they carry baggage you never asked for. That baggage is provenance metadata. Modern generators (GPT Image / DALL·E, Google's Nano Banana / Gemini, Midjourney, many hosted Stable Diffusion endpoints) stamp each output with tags that mark it as machine-made. Some of it is harmless. Some of it survives a Photoshop round-trip. And most developers have no idea it's even there until a downstream platform flags an image or a QA person asks "why does this PNG have a certificate chain in it?" This is a hands-on guide to seeing that metadata and removing it — from the CLI, from Node, from Python, and (when you just want it gone) from the browser. What actually gets embedded There are four layers worth knowing about, because they don't all come off the same way: EXIF fields — the classic camera-metadata block. Generators repurpose fields like Software , ImageDescription , or a custom Make / Model to identify themselves. Trivial to read, trivial to strip. XMP packets — an XML blob (Adobe's format) holding richer provenance: model name, generation timestamp, sometimes a prompt hash. Lives in its own segment of the file. C2PA manifests — the interesting one. The Coalition for Content Provenance and Authenticity standard embeds a cryptographically signed manifest (stored in a JUMBF box) that records the asset's origin. Because it's signed, it's designed to be tamper-evident — which also means naive metadata strippers often miss it. Pixel-level watermarks — e.g. SynthID-style signals baked into the pixels themselves. These are not metadata at all; no EXIF tool touches them. (More on the limits below.) The mistake I see repeatedly: someone runs a one-liner that clears EXIF, sees "no EXIF" in their viewer, and assumes the image is clean. The C2PA manifest and XMP pac
Testing 100 companies found privacy requests often led to confusion and dead ends.
Brave's browser begins testing an email alias feature that lets you keep your main email info private.
The backlash against license plate readers comes amid a wave of police abuses of surveillance cameras.
Meta fixes AI glasses to stop recording any time users cover up the safety light.
California residents have a legal right to access the data that companies collect about them. Actually exercising that right is a burdensome nightmare.
Most "free online tools" have a dirty little secret: the moment you drop a file in, it gets uploaded to someone else's server. Your tax PDF, your ID photo, your client's contract — all sent off to be processed on a machine you'll never see, by a company whose privacy policy you didn't read. For a quick image resize, maybe you don't care. But it adds up. And the wild part is that for most everyday tasks, that upload is completely unnecessary. Modern browsers are powerful enough to do the work right on your own device — no server round-trip, no copy of your file sitting in someone's cloud. Here's how that works, and how to actually use it. Why do so many tools upload your files? Two reasons, mostly. The first is habit: it's easier for developers to send a file to a server, run some code there, and send the result back. The second is business: once your file is on their server, they can log it, analyze it, or use "free" as a funnel toward a paid plan. Watermarks, file-size limits, and "sign up to download" walls all come from this model. The alternative — processing files client-side , meaning inside your browser — has quietly become viable for a huge range of tasks thanks to two technologies: JavaScript (which every browser runs) and WebAssembly (which lets browsers run fast, compiled code at near-native speed). Together they can compress an image, merge a PDF, or transcode data without your file ever leaving the tab. What you can do entirely in your browser You'd be surprised how much works locally now: Images — compress, resize, convert between PNG/JPG/WebP, remove backgrounds, strip metadata. PDFs — merge, split, rotate, compress, and convert to or from images. Text and code — format or minify JSON, count words, change case, generate QR codes, encode/decode Base64. Everyday math — loan, BMI, age, and currency calculators that don't need a server at all. None of these require your data to travel anywhere. The tool loads once, and from then on it's just your CPU doin
Alpharetta, Georgia, cops share data with thousands of Flock users, ranging from federal agencies to a fish and wildlife commission. The reasons why show how vast—and invasive—the network has become.
A recent discovery revealed that AliExpress employs silent audio streams for device fingerprinting, leveraging the Web Audio API. This technique involves analyzing hardware-specific audio processing to distinguish user devices. Privacy-focused browsers have developed countermeasures, highlighting a security gap in current web standards regarding audio context initialization and user privacy. By Olimpiu Pop
After an affair with a fellow police officer ended, a Georgia cop used Flock to track her movements—and those of a man whose vehicle often showed up near hers, internal investigation records show.
Americans have declared war on Flock cameras. They've protested them, damaged them, and destroyed them. This is only the beginning. The spontaneous and decentralized nature of the vigilante protests is also what makes them difficult to suppress. There isn't a uniform method of disruption; people have done everything from unplugging, smashing, stealing, and spray-painting the […]
Open ChatGPT this week and, without any announcement in the chat window, it may already have formed an opinion about how old you are. From 18 August, OpenAI began rolling out “age prediction” on its consumer plans: a system that guesses whether your account belongs to someone under 18 and, if it decides you’re a minor, quietly switches you into a restricted version called ChatGPT for Teens. You are not asked. If the guess lands on “teenager,” the guardrails go up by default. Answer first, because the mechanism matters more than the alarm: the guess is behavioural, and it is admittedly imperfect. By OpenAI’s own account the system reads “general topics you talk about, the times of day you use ChatGPT, how and when your account is used, and how long your account has existed.” And the way to make it stop guessing is not a toggle. It is to prove your age to a third-party verifier called Persona, with a live selfie, a government ID, or both. The choice on offer isn’t whether to be identified. It’s how. None of this arrives from nowhere, and we’ll be fair about why in a moment. But a change that infers a protected characteristic from the content of your conversations, applies real restrictions on the strength of a guess, and offers identity verification as the only exit is worth reading slowly — especially for the adults who will be misclassified, because OpenAI says plainly that some will be. What OpenAI actually switched on The launch has two parts. The visible one is ChatGPT for Teens , announced on 18 August: a version with study-focused features and stronger safety defaults for under-18s. The consequential one is age prediction , the system that decides who gets dropped into it. In OpenAI’s words, “If our system estimates someone is under 18 or they state their age is between 13 and 17, they are automatically placed into ChatGPT for Teens.” It is rolling out globally, with the EU following “in the coming weeks” to fit regional rules. What does the teen experience act
Ring says users can still opt for end-to-end encryption.
Meta settled its latest kids online safety trial with a group of 29 state attorneys general, sparing it from the remainder of a trial that could have cost it hundreds of billions of dollars. Under the terms of the settlement, which resolves claims by a larger group of 47 states and several districts and territories, […]
Ring has a new way to protect your videos. It's developed an encryption method called TAKE, short for Throw Away the Key Encryption, that the Amazon-owned company says will protect your videos without traditional end-to-end encryption. TAKE limits when and why Amazon's cloud can access those videos, while still providing features like smart alerts for […]