vraag 6-12

[Lemmont]

Hoi @maartenmarx ,

Ik ben bezig geweest met de witte ruimte op te vullen en heb dat inmiddels werkend voor pdfs gemaakt vanuit Microsoft word and gemaakt met XEP (bestanden zoals die van gemeenten, staatcourant en waterschappen worden allemaal hieruit gemaakt). Tekst wordt hiervan verwijderd, een placeholder tekst wordt ingevoerd en de ruimte wordt bijgesteld zodat het ten eerste voor het oog goed uitziet, maar ook zodat de oorspronkelijke lengte niet terug te halen is.

Daarnaast ben ik nu bezig met een ruis toevoegen aan de overige positionele aanpassingen zodat informatie daarover niet/minder terug te vinden is en het dus lastiger wordt voor aanvallers om letters te gokken (dit op basis van de Maxwell paper en zijn suggesties voor verdediging en zijn eigen github code/tool. ik vind het lastig hoe ik dit zelf ga bewijzen). Hierbij worden positie correcties die toegevoegd zijn door de 'producer' van het bestand (Word bijv.) met een willekeurige factor tussen 0.8 en 1.5 vermenigvuldigd.

Veel documenten (op basis van Woo) worden met andere tools gemaakt die een compleet andere opmaak krijgen dan de PDF documenten uit Microsoft word. Tools zoals Adobe PDF library, GPL, ITextSharp en overige maken gebruik van compleet andere manieren van text renderen in een pdf waarbij complexe operaties worden uitgevoerd om een positie te bepalen. Ik heb de beslissing genomen om sowieso niet hierin de witruimte bijstelling te ondersteunen ivm de complexiteit. Ik kan echter wel ruis aanbrengen in de positionele data van deze documenten en natuurlijk is de tekst verwijderd uit het bestand.

Mijn vraag gaat over het onderzoeksgedeelte en de 'test-documenten' die ik daarvoor ga gebruiken. Ik kan tot nu toe nog niet veel documenten vinden die vanuit word zijn gemaakt bij publicaties van overheidsinstanties. Wel kan ik veel documenten vinden die gebruik maken van XEP (zoals dus de documenten van gemeenten, staatscouranten en waterschappen). Voor word is mijn gedachten dus om zelf een setje te maken van documenten die ik kan testen (misschien op basis van wikipedia artikelen, of nagemaakte Woo bestanden).

Wat denkt u hierover? Heeft u wellicht een ander idee?

[maartenmarx]

Hi @Lemmont ,

• Dit klinkt als een zeer sterk en precies gewenst resuktaat! Goed gedaan joh.
• Ik geloof niet dat je zelf hoeft te bewijzen dat jouw aanpak werkt, want je kan gewoon naar Bland's paper verwijzen. Hij heeft die manier van aanvallen helemaal uitgedokterd, en op basis daarvan ook de manier van afslaan.
• Je schrijft Ik kan echter wel ruis aanbrengen in de positionele data . Sounds exciting! Kan je beargumenteren dat dat ook al een flink deel van de Bland bezwaren weghaalt?
  • Doe het in het Engels en leg je voorstel voor aan maxwell, en eens kijken wat hij ervan vindt.
  • probeer het enigzins formeel te doen: dus allicht kan je zeggen dat je in ieder geval dit en dit soort aanvallen kunt afslaan.
• Is dit allicht Word: https://openpub.ridderkerk.nl/wp-content/uploads/sites/3/2023/02/Woo-besluit_Juliana_van_Stolbergstraat_getekend-geanonimiseerd1.pdf Ik weet dat het eerst met word gemaakt is en daarna door een laktool gehaald, dus weet niet zeker hoeveel die dan weer aan de PDF veranderd heeft. Conrol I noemt word in ieder geval niet. Zo ja, dan kan je alle besluiten van Ridderkerk https://doi.wooverheid.nl/?doi=nl.gm0597.2i.2022 bekijken.

word files

• Ik ben effe voor je bezig geweest. ;-)
• Haal 'woo_documents.csv.gz' van https://surfdrive.surf.nl/files/index.php/s/NEpv6uiFwvigxqx met wachtwoord qIc*F5lL(JrW
• Run dan dit

  document_dataframe = pd.read_csv('woo_documents.csv.gz').set_index('dc_identifier')
  document_dataframe.foi_pdfCreator.value_counts()

  heel veel pdfs gemaakt door word! Of pdfProducer zit er ook in.

in de dc-source kolom zitten de urls, dus die download je zo.

Allemaal overheid en Woo, dus precies in ons straatje.

test/evaluatie

• Kan je allicht met een script automatisch stukken text selecteren om zwart te lakken, en dat dan over al die word files draaien, en dan ook automatisch checken of het goed ging?
  • dat is toch: wat weg moest is echt weg, en kan heel lastig re-engineered worden.
  • en de hele rest is er nog
• Je zou een soort verzameling "unit-tests" kunnen maken, met steeds lastiger en smeriger redacties (heel veel in dezelfde regel met steeds alleen een letter of zelfs een spatie of zo ertussen)
• Zoiets lijkt me een ideale manier van evalueren, en ook goed voor een artikel omdat je dan een vaste test-set hebt.

Reden in het weggehaalde deel.

• De weigeringsgrond dus
• heb je daar nog mee gespeeld?
• En ook met hoe je dit nu voor gehandicapten kunt oplossen? Dat het voor ze duidelijk is dat er een stukje is weggelakt als ze het tot zich nemen.

Al met al ben je volgens mij echt een heel eind gekomen!! te gek!

[Lemmont]

Hoi @maartenmarx,

Uiteraard weer bedankt voor uw feedback!

Je schrijft Ik kan echter wel ruis aanbrengen in de positionele data . Sounds exciting! Kan je beargumenteren dat dat ook al een flink deel van de Bland bezwaren weghaalt?

• Doe het in het Engels en leg je voorstel voor aan maxwell, en eens kijken wat hij ervan vindt.
• probeer het enigzins formeel te doen: dus allicht kan je zeggen dat je in ieder geval dit en dit soort aanvallen kunt afslaan.

Maxwell noemt het zelfs in de paper en past een sterkere variant toe!

Dit zegt hij over zijn eigen ontwikkelde 'tool' (niet echt een tool te noemen) : "dact9 protects vulnerable PDF redactions by first locating the trivial redactions and removing their underlying text from the PDF. dact9 then removes all non-redacted glyph displacements7 and converts the font to a monospaced one and scales the size to preserve readability. To protect nontrivial redactions, dact9 rounds up the size of all spaces between two words to some width, n×w, where n is some number of characters and w is width of a single character in the monospace font. Monospaced redactions leak less than five bits of information (Sec. 5). dact9 also removes any rectangular draw commands from the PDF so that the width of the redaction cannot be recovered by examining the width of any graphical box drawn to represent the redaction (see Appdx. G for an example leveraging this leak)."

Hierbij linkt hij naar zijn git. Ik heb al geprobeerd om hier iets mee te doen, maar het is complex en sluit niet heel goed aan op mijn methode.

Daarnaast heeft hij in zijn paper in hoofdstuk 8.1 over mogelijke 'defenses'. Hier geeft hij een vijftal suggesties voor verdediging: drie daarvan sprongen daar voor mij uit:

1. Ruis toevoegen (het voordeel is dat het document grotendeels leesbaar blijft. Dus een balans tussen kans op kraken en toegankelijkheid, zoals hij zelf zegt):

"Changing Glyph Displacements. Displacement scheme noise may be added to a line without effecting readability.12 If this noise is indistinguishable from legitimate glyph positioning information, accounting for it requires increasing the set of accepted redacted text guesses. Removing displacement scheme information altogether can also prevent information leaks, though this is less visually appealing."

2. De layout aanpassen (geen black boxes gebruiken bijv. ):

"Document Layout and Redaction Obfuscation. Modifying the PDF commands used to render the redaction complicates the process of automated redaction location. For example, our nontrivial redaction location algorithm relies on identifying a black box between two words in order to avoid large numbers of false positives."

3. Tekst weghalen en het gat opvullen:

"Adversarial Redactions One defense against deredaction is to change the document’s original text before it is redacted, for example, by replacing a sensitive name with the letter “X”. It is also possible to lie to deredaction by changing the redacted content to something seemingly valid, potentially misinforming an adversary."

• Ik geloof niet dat je zelf hoeft te bewijzen dat jouw aanpak werkt, want je kan gewoon naar Bland's paper verwijzen. Hij heeft die manier van aanvallen helemaal uitgedokterd, en op basis daarvan ook de manier van afslaan.

Ja dat leek mij ook!

test/evaluatie

• Kan je allicht met een script automatisch stukken text selecteren om zwart te lakken, en dat dan over al die word files draaien, en dan ook automatisch checken of het goed ging?

  • dat is toch: wat weg moest is echt weg, en kan heel lastig re-engineered worden.
  • en de hele rest is er nog
• Je zou een soort verzameling "unit-tests" kunnen maken, met steeds lastiger en smeriger redacties (heel veel in dezelfde regel met steeds alleen een letter of zelfs een spatie of zo ertussen)
• Zoiets lijkt me een ideale manier van evalueren, en ook goed voor een artikel omdat je dan een vaste test-set hebt.

Ik heb voor mezelf al een klein scriptje geschreven dat wat woorden voor mij selecteert die weggelakt kunnen worden. Een uitbreiding daarop lijkt me al een goed om over de word bestanden te draaien. Ik zou kunnen checken of het resultaat (dus de pdf weggelakt versie) niet de woorden bevat die weggelakt moesten worden idd en dan tenslotte van dit 'unit-tests' maken die mijn methode valideren. Hier kan ik wat mee. Bedankt voor het meedenken!

• heb je daar nog mee gespeeld?
• En ook met hoe je dit nu voor gehandicapten kunt oplossen? Dat het voor ze duidelijk is dat er een stukje is weggelakt als ze het tot zich nemen.

Ik heb er nog niet mee gewerkt. Het enige wat ik daarvoor moet uitvinden is de daadwerkelijke methode hoe een stukje tekst omgezet kan worden naar een ander nuttige stukje tekst op basis van de context. Moet iets doen met een neuraal-network/machine-learning die al voorgetraind is. Wel heb ik al test data voor een eventueel machine-learning achtige methode gevonden, maar ik moet nog kijken voor een voor getraind model.

Voor gehandicapten zou het al moeten werken. Als ik nu op een stukje weggelakte tekst 'weggelakt' neerzet, dan staat dat woord in de pdf. Andere methoden die tekst uitlezen zouden dat moeten kunnen oppikken, maar dat niet met zekerheid zeggen; ik heb zelf geen diepgaand onderzoek gedaan naar die methoden.

Allemaal overheid en Woo, dus precies in ons straatje.

Dat ziet er erg handig uit. Bedankt. Ik ga er naar kijken!