Skip to main content

Filter by idea status

10000+ Ideas

DRM Signature Upgrade for PDF and other Adobe FormatsOpen for Voting

Feature Request: PDF Provenance Compiler with Signed Revision Lineage and Copy-Aware MarkersSummaryI propose a new Adobe Acrobat and PDF-platform capability called the PDF Provenance Compiler.Its purpose would be to create a cryptographically verifiable genealogy of PDF documents. Instead of treating every exported or edited PDF as an isolated file, the compiler could bind each new revision to an anonymized commitment representing its predecessor.The result would be a chain of evidence that can connect drafts, approved versions, edited derivatives, screenshots, copied text passages, and exported graphics without publicly exposing every earlier document.The central idea is simple:Every new PDF revision can carry a signed and privacy-preserving reference to the document state from which it originated.This would extend digital provenance beyond conventional metadata. It could be useful for professional authors, publishers, designers, research and development departments, healthcare organizations, government agencies, law-enforcement environments, archives, legal workflows, and other institutions that need to distinguish authentic document evolution from unexplained modification.The Current ProblemPDF already supports digital signatures, certificates, embedded metadata, document restrictions, layers, and provenance information. These mechanisms are valuable, but they do not automatically create a comprehensible relationship between successive files.When a document is edited, exported under a new name, converted, partially reused, or passed through several applications, its history often becomes a loose collection of files: Draft.pdf Draft-final.pdf Draft-final-corrected.pdf Draft-final-corrected-2.pdf Names are not evidence. Timestamps can be changed. Metadata can be stripped. A conventional hash identifies one exact file but does not explain how a later revision relates to an earlier one.A digital signature can confirm that one specific revision has not changed since signing. It does not necessarily describe the document’s ancestry.The missing feature is therefore not another editable history list. It is a signed relationship between document states.Proposed Feature: PDF Provenance CompilerThe PDF Provenance Compiler would process: The current PDF document. An optional predecessor PDF or predecessor proof. The intended transformation or revision class. The selected trust and privacy profile. Optional text, graphic, hardware-key, or platform-attestation settings. It would then generate a signed provenance record for the new revision.A simplified record could contain:PDF_Provenance_Record { scheme_version, chain_id, current_document_digest, predecessor_commitment, revision_class, page_binding, issuer_key_reference, creation_time, trust_profile, optional_copy_marker_profile, optional_graphic_marker_profile, nonce, signature}The compiler would not simply copy the raw hash of the predecessor into the new PDF. That could permit unwanted comparison, guessing, or tracking.Instead, it would create a salted and domain-separated predecessor commitment:predecessor_commitment = HASH( predecessor_digest || private_salt || chain_id || branch_information || scheme_domain )A party possessing the predecessor file and the corresponding disclosure material could later prove the relationship. Anyone without that material would see only an opaque commitment.This creates an anonymized document genealogy rather than a publicly searchable trail.Why the Revision Chain Is the Main StrengthThe strongest part of the proposal is not the watermark itself. It is the aging of the document through successive digital states.Every legitimate revision becomes a new cryptographically signed link.The system could distinguish between: A verified predecessor relationship. A predecessor that has not been disclosed. A missing link. A legitimate branch. An unexplained fork. A rollback to an earlier state. A document with no known predecessor. A document whose current contents no longer match its signed state. This would make the document history selectively provable without requiring the entire working archive to be published.A professional author could prove that a published manuscript descended from an earlier draft without revealing every private draft.A research department could establish that a released report came from a specific internal review chain.A healthcare organization could verify the relationship between an approved document and a later redacted version without embedding confidential predecessor content.A government or law-enforcement workflow could distinguish an authorized derivative from an unexplained reconstruction while keeping sensitive earlier files compartmentalized.The system would not prove that the content is true. It would prove that a particular document state was cryptographically linked to another document state by an authorized key.That distinction is essential.Integration with Adobe AcrobatAdobe Acrobat Pro could provide a new Provenance panel containing: Current document digest. Current chain identifier. Verified or undisclosed predecessor state. Revision and branch information. Issuer and signing-key status. Timestamp status. Page completeness. Optional hardware-backed key status. Optional copy-marker status. Detected gaps, forks, rollbacks, or invalid transitions. A function for selectively proving a predecessor. A function for compiling the current document as a new signed revision. The basic workflow could be: Open the current document. Choose Compile as New Provenance Revision. Select a predecessor file or predecessor proof. Choose the transformation class, such as edit, redaction, translation, approval, publication, or archival conversion. Select a trust profile. Review the information that will be included. Sign and save the new revision. Adobe Reader could provide read-only verification.Adobe InDesign and Illustrator could offer the compiler during PDF export. Adobe PDF Services API could support server-side compilation and verification for organizational workflows.The file should remain an ordinary readable PDF. Proprietary verification must not become a requirement for opening or displaying the document.Latent Visual Marker for Digital DerivativesAs an optional component, the compiled PDF could include a Latent Visual Signature Layer.This would be a visually unobtrusive, machine-readable pattern bound to the current chain tip and distributed across the rendered page.Its primary digital purposes would be: Identifying screenshots derived from a protected page. Recognizing rasterized page exports. Connecting flattened derivatives to the originating revision. Detecting some forms of page substitution or recomposition. Preserving a short signed provenance reference when metadata is removed. The marker should not be implemented merely as a switchable PDF layer. A removable named layer would be convenient for authoring and debugging but too fragile as the actual carrier.During final export, the marker would need to become a subtle part of the ordinary rendered page representation.The system should adapt its strength to local content. Fine typography, faces, QR codes, barcodes, medical imagery, formulas, and safety-critical diagrams should be protected by exclusion masks.The marker must remain subordinate to readability and visual quality. If a page cannot safely carry it, Acrobat should report that limitation rather than silently increasing its strength.Provenance-Aware Copy ExportA second optional component could protect the provenance of extracted text.When Provenance-Aware Copy Export is enabled, supported copy and export operations could generate a marked text derivative.The original text stored in the PDF would remain canonical. Visible glyphs, accessibility text, search text, ToUnicode mappings, tags, and ActualText would not be altered.Only the explicitly controlled clipboard or export result would receive a sparse codeword.Possible marker families could include carefully selected variants of: Ordinary spaces and selected Unicode spacing characters. Uppercase I, lowercase l, and the digit 1. Uppercase O, the digit 0, Greek Omicron, or Cyrillic O. Other font-tested confusable characters. This mechanism requires severe restrictions.It must never alter: URLs. Email addresses. Passwords. Source code. Hashes. Account numbers. Legal citations. Medical dosages. Measurements. Mathematical formulas. Product identifiers. Serial numbers. Accessibility content. One unusual character must never be treated as evidence.A valid detection would require: Multiple marker positions. A valid positional codeword. Error-correction consistency. A document or edition reference. A nonce. A cryptographically valid signature or message-authentication value. Possible detection states should include: No marker. Candidate pattern. Verified provenance marker. Damaged or ambiguous marker. Verified policy event. A verified marker could indicate that a text passage probably originated from a protected Adobe copy or export operation.It could not, by itself, prove that the copying was illegal or unauthorized.Private installations should retain a visible opt-out. Managed organizations could configure transparent policies and local auditing, provided that the users, purpose, and scope are clearly disclosed.Signature and Graphic Copy MarkersThe same principle could be applied to copied signatures, seals, stamps, logos, and other high-value graphics.The graphic stored in the PDF would remain unchanged.When a supporting Adobe application copies or exports the graphic, it could produce a subtly marked derivative containing a Signature Graphic Provenance Marker.Possible carrier regions include: The interior of sufficiently wide strokes. Antialiasing edges. Near-neutral color-channel modulation. Redundant cells immediately surrounding the graphic. Texture already present in the image. The marker could be bound to:Graphic_Provenance_Record { chain_tip_reference, graphic_asset_digest, page_region, export_route, copy_nonce, signed_reference}A successful verification could indicate that an image was probably derived from a particular protected graphic in a particular document revision.It must not claim that: The person shown or named created the graphic. A handwritten signature is genuine. The signer consented to the later use. The graphic constitutes a qualified electronic signature. The surrounding document is authentic merely because the graphic was copied from an authentic source. The feature would establish probable graphic provenance, not legal intent.Optional Hardware-Protected SigningFor explicitly protected PDFs, Adobe could optionally use hardware-backed signing keys.On private systems this should be: Disabled by default. Activated only through an explicit document or template setting. Clearly shown before signing. Removable from future workflows through an opt-out. Free of raw, globally correlatable hardware identifiers. The provenance record should contain only a scoped attestation reference or pseudonymous organizational key reference.In managed high-security environments, an organization could require TPM- or HSM-protected signing as part of a documented policy.Possible environments include: Government agencies. Law-enforcement organizations. Healthcare institutions. Critical research. Security-sensitive development departments. Regulated publishing or documentation systems. Hardware attestation would support the statement that a protected key and an expected platform state participated in creating the signature.It would not prove the truth of the document, the identity of the human author, or the absence of compromised software.Optional Future Platform AttestationA later interoperability extension could allow Microsoft, Apple, and Linux environments to provide a voluntary platform-level participation attestation.Such a system might use short-term patterns derived from: Typing cadence. Key dwell and flight time. Pauses. Correction rhythm. Cursor acceleration. Cursor curvature. Micro-pauses. Click or touch sequences. Raw interaction events and behavioral templates must remain on the local device.The PDF should receive only a revocable, one-time statement containing information such as: Purpose. Current chain tip. Confidence band. Template version. Consent receipt. Time window. Platform signature. This would be a probabilistic participation signal, not proof of identity or authorship.It should be disabled by default, explicitly voluntary, revocable, and replaceable by an equivalent non-behavioral signing method.Because illness, stress, fatigue, injury, new hardware, or accessibility software can change interaction behavior, such an attestation must never be the sole basis for rejection.This platform component is not required for an initial Adobe implementation. It is a possible future interoperability layer.Privacy and Accessibility RequirementsThe default provenance profile should contain no: Personal identifier. User account name. Recipient identifier. Location. Permanent device identifier. Raw hardware identity. Raw behavioral data. Cross-document tracking identifier. The system should identify the document state, page, edition, issuer, and revision chain—not the reader.Acrobat should openly disclose when provenance markers are present.Accessibility and canonical document semantics must take priority over copy markers. Screen readers, search systems, assistive software, and archival extraction should receive the intended original content.Private users should be able to disable optional markers and attestations.Organizational profiles should state clearly: Which components are mandatory. Why they are required. What information is stored. Who can verify it. Whether an event is logged. How long records are retained. Which alternative procedures are available. No single glyph, pixel anomaly, behavioral score, or weak watermark detection should automatically trigger an accusation or sanction.An alert should begin a review. It should not deliver a verdict.Technical LimitationsThis proposal should not be presented as an unbreakable protection mechanism.A third-party raw PDF extractor may bypass copy-aware export and recover canonical text.Unicode normalization, retyping, translation, OCR, or manual transcription may remove text markers.Cropping, binarization, redrawing, re-vectorization, heavy compression, or image reconstruction may destroy graphic markers.A determined attacker may damage or remove a latent visual pattern, especially when visible quality loss is acceptable.Behavioral signals are probabilistic and can drift or be imitated.Hardware-backed signing strengthens key protection but cannot certify the truth of content.The goal is therefore not absolute prevention.The goal is to make document lineage, derivative provenance, tampering, and unexplained transformations more measurable while reporting uncertainty honestly.Suggested First ImplementationA realistic first Adobe prototype could focus on four components: Signed revision lineage Compile a new PDF revision with a salted commitment to a selected predecessor. Selective predecessor disclosure Prove one predecessor relationship without publishing the entire document chain. Acrobat verification panel Display chain status, signature status, page binding, gaps, branches, and invalid transitions separately. Optional provenance-aware export Add cryptographically verifiable markers to supported text and graphic export operations while preserving the canonical source document. Hardware-backed signing could follow as an enterprise extension.The latent visual marker and platform-level participation attestation could be evaluated as separate experimental modules.Expected ValueThis feature could give Adobe a document-provenance capability that extends beyond conventional signatures and editable metadata.Potential users include: Professional authors and publishers protecting drafts and released editions. Designers proving the lineage of exported documents and visual assets. Companies tracing approved technical documentation. Research and development departments managing sensitive revisions. Healthcare organizations distinguishing authorized document derivatives. Government and law-enforcement environments requiring auditable document evolution. Archives preserving relationships between originals, redactions, translations, and later editions. Legal and compliance teams reviewing document history without exposing every confidential predecessor. The commercial value would depend on successful implementation, interoperability, usability, privacy safeguards, and independent security testing.This proposal describes a target architecture. It is not a claim that the technology has already been implemented, standardized, or experimentally validated.Core PrincipleA PDF should not have to forget where it came from merely because it became a new file.The PDF Provenance Compiler would allow each revision to carry a cryptographically verifiable but privacy-preserving trace of its ancestry.Optional visual, textual, and graphic markers could extend that provenance into digital derivatives without altering the canonical source document.Authorship, Contact, and Request for Fair RecognitionThis feature concept originates from Heinrich Görzen and is being shared in good faith as a constructive proposal for Adobe.If Adobe decides to evaluate, develop, or materially incorporate this concept into a commercial product—particularly for professional publishing, healthcare, law enforcement, government, enterprise, or other security-sensitive environments—I respectfully ask Adobe to contact me regarding appropriate attribution and fair recognition of the contribution.Considering the potential commercial and institutional value of such a feature, I would regard a modest four-figure honorarium together with non-expiring access to Adobe Photoshop, or an equivalent Adobe plan, as a fair and proportionate gesture.This is intended as a respectful request for dialogue rather than a demand or an assertion that the proposal is already an implemented or commercially validated technology.Heinrich GörzenContact: [email removed as per forum guidelines](Co-writer ChatGPT)

ArcEarth
ArcEarthParticipant

Add a fully offline Local workflow to Lightroom for iPad, allowing photographers to browse, cull, rate and edit RAW files directly from an external SSD without importing them to Creative Cloud.Open for Voting

I am a professional wildlife photographer and safari guide, and I regularly spend extended periods working in remote parts of Africa where internet access is extremely limited or completely unavailable.On a typical trip I can generate hundreds of gigabytes of RAW files, and sometimes close to 1 TB. A cloud based workflow is therefore simply not practical. Even when some internet is available, uploading that volume of data from a remote safari camp is impossible.I would love to replace my laptop with an iPad Pro for much of my field workflow. The iPad is powerful, has an excellent display and would significantly reduce the amount of equipment I need to carry. As a photographer already travelling with multiple camera bodies, large lenses, storage drives and other equipment, removing a laptop from my kit would make a genuine difference.What prevents me from doing this is Lightroom’s dependence on importing images into its cloud based ecosystem.I would like Lightroom for iPad to have the same type of Local workflow available in Lightroom desktop.My ideal workflow is very simple:Camera cards > external SSD > iPad Pro > Lightroom > Lightroom Classic at home.I want to connect an external SSD containing my RAW files and browse those files directly in Lightroom without importing, duplicating or uploading them to Creative Cloud.While travelling, I need to be able to:• Browse RAW files directly on the external SSD• Quickly cull images using Pick, Reject and star ratings• Edit selected RAW files using Lightroom’s normal editing tools• Keep the original RAW files on the external SSD rather than duplicating them onto the iPad• Work completely offline• Store ratings, metadata and edits locally, ideally using XMP or another Lightroom Classic compatible method• When I return home, connect that same SSD to my Mac, import the trip into Lightroom Classic and retain the ratings, selections and edits I made on the iPadThis is not really a request to put the entire Lightroom Classic application on iPad. It is a request to allow Lightroom for iPad to become a genuine professional field companion to Lightroom Classic.The iPad Pro hardware is more than capable of being an exceptional field photography device. For photographers working in wildlife, travel, expeditions, sports, events and other high volume environments, however, requiring hundreds of gigabytes of RAW files to enter a cloud based library makes that workflow impractical.Lightroom already has much of the functionality required. Bringing Local file browsing and editing to iPad, with metadata compatibility with Lightroom Classic, would allow photographers like me to travel lighter, work offline and make productive use of the time we have in the field without changing our primary Lightroom Classic workflow when we return home.

deecentParticipant

The frustration of FILE TABS!Open for Voting

I'm sure like me, you all have multiple Photoshop documents/projects on the go at the same time. Well as soon as you get to around 5 or more documents open at once, the tab list of documents no longer fit across the toolbar.It's also equally frustrating that the active tab you're currently working on doesn't just display the name of the psd, but also displays the name of the currently selected layer (like I care), the zoom level (why on earth?!) and the colour mode (meh?). I'm confident that there are ways in which Adobe could change the layout of the tabs and I have a few ideas which could work. Let me know what you think. And if you have any other good ideas, leave a comment: Note, I've listed these in order of 'usefullness'. The first being less helpful and the final option being most useful. The least effective, but simplest change:This update would not solve the issue, certainly not for me but others may disagree. However, it would make a small difference. At the very least, why not just remove the unnecessary text/information from the tab (selected layer, zoom level, colour mode). It's not helpful in any way, shape, or form. and all tabs would be the same size, regardless of whether they're active or not. Extra small text:I found that in preferences - workspace there is an option for large tabs which is turned on by default I turned this off and it the tabs are made smaller. Yay, right!...No. The tab is adjusted by its height and not the width 😞So, how about an extra option called something like, "Extra Small Tabs" which just reduces the text size on the tab, thus making it smaller and more will appear across the toolbar. Scroll tabs:So this one I'm dubious about as there's room for user error. But an option to allow the ability to scroll across the tab toolbar would help. When you hover the cursor over the toolbar and scroll your mouse wheel, the tab bar would scroll left and right. Again, user error could be an issue here. I would certainly find it annoying if I accidentally moved by mouse to the wrong part of the screen when it's 3am and I'm sleep deprived, only to see tabs moving around! Still, food for thought. Tab width slider:This edit would be a fantastic approach, in my opinion. An option in the preferences to allow users to slide the width of the tabs down. Think MS Excel and altering the column width. Hey presto! Span the tabs toolbar to the entire window widthAllow the tabs toolbar to span across the entire width of the window = more visible tabs! 5/6 visible tabs now become 9/10 tabs. I honestly don't know why this isn't a thing anyway to be honest. It's possible to move all other groups/toolbars/windows/etc. So why not the file tabs?!  Stacked tabs!Now this one, I'm most proud of. It's sooooo simple and the effect would be great. Also, combine it with the point above and you're onto a winner! As soon as the amount of tabs open becomes too many for the width of the space, why not stack the tabs on top of each other. I'm sure I've seen web browsers do this in the past. Maybe on Firefox or Opera, or one of those dormant browsers. Yes, the stacked tabs would start to eat into your workspace. But, combine it with the ability to have tabs fill up the entire screen width AND combine it with the aforementioned 'Large Tabs' option currently available in preferences and this is gold. Let me know what you think. Add suggestions. Rip my ideas apart if you want, I don't really care. Let's just try and see if we can change this, once and for all!

LesHarveyParticipant

Automatic Puppet Warp pin placement and edge straightening for large textile photography.Open for Voting

I photograph the winning entries in a national quilt competition every year, and I process around 100 quilt images in Photoshop. Each quilt needs to be corrected for sagging, buckling, uneven hanging, and perspective issues — all without distorting the quilt’s design.My workflow for every image includes: Straightening using ACR guides Perspective Warp for planar correction Puppet Warp for fine straightening Cropping Cloning to fill gaps created by warping Adding a consistent border for presentation This takes 20–25 minutes per quilt, adding up to 40–50 hours of manual editing. The most difficult and time‑consuming part is Puppet Warp, where I must manually place 40–50 pins around the quilt edges and then nudge each one to straighten the lines. This repetitive work causes significant neck and shoulder strain over multi‑day sessions.Feature RequestI would love to see a new Photoshop feature that: Automatically detects the object boundary (similar to Select Subject). Automatically places Puppet Warp pins along the edges of the object. Optionally straightens those edges by adjusting the pins inward/outward. Allows manual refinement afterward. Why This MattersLarge textile photography (quilts, tapestries, banners, garments, museum textiles) often requires precise geometric correction without altering the artwork. Manual Puppet Warp pin placement is extremely slow and physically demanding, especially when repeated hundreds of times.An automatic pin‑placement and edge‑straightening feature would: Save dozens of hours per project Improve consistency Reduce physical strain Make Photoshop far more capable for textile, product, and archival photography Thank you for considering this enhancement — it would make a huge difference for anyone working with non‑rigid planar objects.