Security Module FAQ
What is timestamping actually for? Can it help me "register copyright"?
No. Timestamping is not copyright registration. Copyright arises automatically the moment a work is completed, and no registration is required.
What timestamping does is lock down the time and the file's state. When your creation date or the integrity of your work is challenged, the timestamp package provides cryptographic proof: "I already possessed this exact, identical file before point in time X."
It's more like a "birth certificate" than an "ID card."
If I post directly to a social platform, isn't there already a time record?
A social platform's timestamps can be forged, tampered with, or erased, so they can't stand on their own as evidence.
1. Placeholder-edit attack
Most platforms (Weibo, Twitter/X, Pixiv, ArtStation, etc.) let you edit already-published content, and the publish time does not change retroactively after an edit.
This means an attacker can:
- Post a blank placeholder image in 2023
- Steal your work in 2025
- Edit the old post and replace the placeholder with your work
- The platform still shows a publish time of 2023
From your side, they present a link that "was published three years ago," but you have no way to tell from the outside whether it's the original post or a later edit-and-swap.
2. Edit markers can be hidden or ignored
Some platforms (such as Twitter/X) display an "edited" label after an edit, but:
- The label can be cropped out of a screenshot
- Not every platform shows edit history (Weibo keeps no public edit record)
- Third-party archive services (such as the Wayback Machine) usually do not preserve edit history when they crawl a page
3. The platform is not your notary
| Risk | Explanation |
|---|---|
| Post deletion | The platform can remove content at any time, and your "proof of time" simply vanishes |
| Account ban | Once an account is banned, all of its past posts become invisible to the public |
| Image transcoding | The platform automatically compresses, reformats, and strips metadata, which changes the file's hash |
| Adjustable server time | Internal clock errors, time-zone confusion, even deliberate adjustment on the platform's side are all beyond your control |
| Service shutdown | If the platform shuts down (like Google+, or Tumblr in certain regions), the records disappear with it |
4. Account ownership can't be proven
- An account can be bought, sold, transferred, or shared
- An account can be hijacked and used to post content
- One ID can register multiple accounts
"This account posted this image in 2023" ≠ "the real, named person behind this account originally created this image in 2023."
What makes timestamping different?
| Dimension | Platform publishing | Nephele digital timestamping |
|---|---|---|
| Source of time | Platform server clock (unilaterally controlled) | Third-party TSA (RFC 3161, an independent authority) |
| Resistance to edit-forgery | ❌ Time stays the same after editing | ✅ The hash is bound to the original file and cannot be swapped |
| Resistance to deletion | ❌ Gone the moment the platform deletes the post | ✅ The timestamp package lives locally and doesn't depend on the platform |
| Integrity | ❌ Platform compression/transcoding corrupts the file | ✅ A SHA-256 hash chain — any single byte change breaks verification |
| Independence | ❌ Relies on a single commercial entity | ✅ Backed by multiple TSA authorities, fully independent of any content platform |
注意
At most, a platform's publishing record can serve as supporting evidence (proving you have an active account on that platform). It cannot serve as independent proof of creation time and file integrity. The whole value of timestamping is precisely that it is decoupled from any platform.
If a thief timestamps my work first, can he prove the piece is his?
No, but he can create confusion. In the end it comes down to whose timestamp is earlier + whose chain of evidence is more complete.
Timestamping does not verify authorship
Nephele's timestamp only records: "someone held hash Y of some file at point in time X." It does not verify whether that person is the creator, nor whether they copied the file from someone else.
In theory, anyone can take any file and timestamp it.
Why a thief timestamping first usually doesn't hold up
1. Chronological order is a hard metric
If your timestamp is 2023-06-01 and the thief's is 2024-03-15, then the thief's timestamp actually proves he obtained the file after you did. Once a timestamp is issued, its date cannot be backdated or forged (the TSA signs with its own private key, and you cannot generate a valid TSA token for a past time).
2. The source file is decisive
A thief usually only has your finished image (PNG/JPG), whereas the original creator has:
- PSD / CSP / SAI / KRA / Procreate source files (with layers, stroke data, undo history)
- Work-in-progress drafts, sketches, line art
- Screen recordings or screenshots of the creative process
- Earlier timestamp packages (containing all of the above)
Nephele's "full timestamp" mode automatically detects source files and upgrades the report, clearly noting that "the creator can provide the original project files." A thief can't do this.
3. Cross-referenced chain of evidence
Beyond the timestamp, you can also provide:
- Historical posting records on social media (even if platform timestamps are unreliable, cross-referenced records across multiple platforms still carry weight)
- Transaction records from commission platforms
- Correspondence with clients or editors
- Records of the work being featured in art books, exhibitions, or competition submissions
Worst case: what if the thief really did timestamp before you?
If the thief obtained your source file before you timestamped it (for example, you once sent the source file to them, or your device was compromised) and made a full timestamp, that genuinely is a thorny scenario. But even so:
- If you can prove the source file was created on your own device (such as Photoshop history, an iPad creation timeline, or cloud-service sync logs), that is still more persuasive than a bare timestamp.
- If you can prove the other party had access to your source file (such as email send records or cloud-drive share records), that points directly to infringement or a leak.
- The combination of timestamp + source file + creation-environment evidence far outweighs a lone timestamp package.
提示
Timestamping is not "whoever timestamps it owns it." It is a cryptographic time anchor, and it delivers its full force only within a complete chain of evidence. For the original creator, the earlier you timestamp, the better — not because having a timestamp guarantees a win, but because not having one leaves you extremely exposed in a dispute.
If I modify the file after timestamping, will it still pass verification?
No.
Verification requires the original file as it was at the time of timestamping. Any modification — including re-exporting, resizing, adding a watermark, or adjusting compression quality — will change the SHA-256 hash and cause verification to fail.
This is exactly why we recommend timestamping the source file and the finished work together. If the finished work needs to be re-exported, the source file is still inside the package and available for verification.
How big is the difference between a local timestamp and a TSA timestamp?
| Type | Evidentiary weight | Use case |
|---|---|---|
| RFC 3161 TSA | High — backed by a third-party authority | Formal enforcement, commercial delivery, competition submissions |
| Local timestamp | Low — only proves your computer had this file at this time | Temporary backup during a network outage |
If you see proof.json instead of proof.tsa when timestamping, we recommend re-timestamping once your network is restored. A local timestamp cannot prove "this page on the internet existed at this time"; it only serves as an emergency backup.
My enforcement-evidence screenshot only shows the browser's first screen — will a court accept it?
The screenshot is just one part of the evidence package. A complete .nep evidence package also contains:
- The page source (proving the content really comes from that URL)
- The TLS certificate (proving you connected to the genuine server)
- A HAR network-traffic log (proving the image really loaded from that domain)
- An RFC 3161 timestamp (proving the time of collection)
If the page is very long (such as an infinite-scroll feed), the first-screen screenshot genuinely can't cover all the infringing content, but the HTML source preserves the entire content in full. For formal litigation, we recommend supplementing it with notarization when necessary.
Does the timestamp package need password protection?
It depends on the scenario:
- Sharing it or uploading it to cloud storage: we recommend setting AES-256 password protection to prevent third parties from directly unzipping it and viewing your original work.
- Local backup only: you can skip the password for the convenience of verifying it at any time.
Note: once the password is lost, the files inside the package cannot be recovered.
What if I lose the timestamp file (.nep)?
It's serious, but not entirely beyond repair:
- If you have the
manifest.jsonor PDF report from inside the.neppackage (saved separately), it records the root hash and the file manifest. - But if you've also lost the original file, the timestamp itself loses its meaning — verification must rely on the original file as it was at the time of timestamping.
We recommend storing the .nep file and the original work separately (such as a local NAS + cloud drive) to create redundant backups.
Should timestamping and evidence collection be used together?
Yes. The best practice is:
- On the day a work is finished — make a digital timestamp to lock down the original creation time and file state.
- After discovering infringement — immediately collect enforcement evidence to lock down the state of the infringing page.
- When you need to file suit — bundle the two into a chain of evidence (original-work timestamp + infringement-evidence collection + similarity comparison report).
Using either one on its own weakens its evidentiary weight.