Anonieme verificatie: upload of alleen hash?

[murynowicz]

Hoi,

Ik bouw een publieke verificatie-endpoint voor digitale bestanden en bestandspakketten, en ik ben benieuwd wat volgens jullie praktische standaardkeuzes zijn.

De use case is simpel:

* een gebruiker maakt een proof record voor één exact bestand of pakket
* dat levert een publiek tijdgestempeld record op voor die exacte versie
* later kan iemand een kopie van het bestand controleren, zien of het match of mismatch is, en bevestigen wanneer die versie is vastgelegd

Een paar ontwerpkeuzes maken dit net anders dan normale file sharing:

* standaard is het hash/metadata-only, dus het originele bestand hoeft niet opgeslagen te worden
* publieke verificatie is bewust simpel: match / mismatch
* het publieke record moet laten zien dat een specifieke bestandsversie op een bepaald moment bestond
* uitgebreidere outputs blijven alleen beschikbaar voor ingelogde gebruikers
* afhankelijk van de use case kan bepaalde metadata publiek zijn, terwijl andere metadata verborgen of beperkt blijft

Het doel is om versieverificatie en timestamping simpel te houden, zonder dat de publieke endpoint meteen een makkelijk doelwit voor misbruik wordt.

Ik probeer hier verstandige defaults voor te kiezen.

Mijn vragen:

1. Zouden jullie anonieme gebruikers direct een bestand laten uploaden voor verificatie, of zouden jullie alleen hash-only checks toestaan?
2. Zijn er praktische caching-patronen die hier helpen om cloudkosten te drukken (bijvoorbeeld DB/query-caching, result caching of tijdelijke hash-lookups), zeker als je op DigitalOcean draait?

Ik zoek vooral advies over dingen die je goedkoop en eenvoudig kunt invoeren, zonder grote ingrepen of meteen dure third-party diensten nodig te hebben, tenzij dat echt niet anders kan.

[jurroen]

Is het een optie om de hash client-side te laten berekenen of is het een keiharde must om dit server-side te doen?

[Onbekend]

Ik zou zoveel mogelijk controles bij de client laten doen. Deze heeft er immers baat bij dat de controle goed wordt uitgevoegd, dus kleine kans dat deze het e.e.a. zal manipuleren. De hash die de client heeft berekend kan worden opgevraagd en bij een match zou je een aantal details zoals datum/tijd, originele bestandsnaam, versie en auteur terug kunnen geven.
Het voordeel om het bij de client te laten doen is dat je maar een beperkte hoeveelheid dataverkeer hoeft af te handelen doordat alleen de hash wordt opgestuurd en de server niet het complete bestand hoeft te verwerken. Zorg er wel voor dat je een limiet per gebruiker of ip-adres op het aantal requests zet. Bijvoorbeeld max. 20 per uur voor ingelogde gebruikers en 5 per uur voor anonieme gebruikers.

Caching of andere optimalisaties is vaak voor een beperkte dataset niet echt nodig. Alleen een index aanmaken op de hash-kolom is wel aan te raden.
Pas als je zelf performanceproblemen ziet ontstaan zodra de tabel miljoenen records gaat bevatten zou je een kleine optimalisatie kunnen maken door de data in meerdere kleinere tabellen op te slaan.