• 35 Posts
  • 56 Comments
Joined 2 years ago
cake
Cake day: July 1st, 2024

help-circle
  • FWIW, as someone working in fintech in the EU, that “KYC over-achievement” is not as overzealous as you think it is.

    It is not as reckless in the EU as it is in the USA, but still overzealous in the EU. Examples:

    • Guy in Finland was refused a home mortgage because his bank transactions revealed that he buys a lot of wine. Alcohol consumption was tracked and seen as a risk for lending.
    • Some banks’ privacy policies openly admit that they keep records of the IP address for the purpose of tracking geolocation. Yes, in Europe. And yes, it violates GDPR Art.5 (data minimisation).
    • No GSM number? No account. Some banks don’t even just accept what number you give them – they demand proof from the GSM carrier that the number belongs to the applicant (even in a region that mandates GSM registration).
    • ID card on file at a bank expired. What does the bank do? They simply cut off the card, even if it’s a Friday and the bank doesn’t reopen until next week. That is how they communicate to the customer that they need to provide an updated document. No, people’s identity does not change. It is still the same person.
    • Some EU banks now refuse to give customers a statement of account on paper, thus forcing them online.
    • Some EU banks collect frivilous data for marketing purposes which they treat as “legitimate interest”. They write this in the privacy policy. People can opt-out, but for me it’s an abuse that it’s not the other way around. It should be opt-in.

    Not KYC but still an abuse: All EU banks with mobile apps force customers to obtain their closed-source app from Google or Apple, who then collects the IMEI number of the user, their GSM number, and tracks which apps they download so Google or Apple has a record of where people do their banking. Likewise, some banks choose Microsoft or Google for their email service and they never provide a PGP key. In this case MS or Google sees where people bank and their msg payloads.

    None of that privacy abuse is legally necessary or required to execute the contract.

    And, at least at my place of employment, we take the PII protection very seriously because of GDPR.

    You could only express that in terms of your own place of employment. The DPAs in most member states report annually being understaffed. They are up to their necks in an unsurmountable ocean of Art.77 complaints because the GDPR is widely ignored.






  • I’m not sure why you would regard black dots as invisible.

    The EFF warned that no printers are safe (or something to that effect), as they gave up on the project to document the models with tracker dots. I suppose the question is: have any black laser printers been concretely identified as having tracker dots?

    In any case, I think mono printers are safer simply because there is no legit cover story for that surveillance. So if someone gets caught doing something naughty, there would be a more reluctance to use the evidence if it reveals mono printers are compromised. A mono printer maker would have no defense for their anti-consumer design.






  • Thanks. I’ll have a look at some of those approaches.

    (edit) I used a feature in the KOMAscript pkg to produce circles that reach the edge of the paper. I also used one of the approaches in your link to create a frame at the point where the /expected/ boundary is, so that if the frame has any missing lines it would indicate where the specs may be wrong. But I must say I don’t trust LaTeX to produce an accurate frame because some lines are closer to the edge than others even though I asked for 4.2mm on all sides.



  • I could flood the page with color, then place a white box on top of that that covers all but 20mm around the border knowing that the unprintable region would not be bigger than that.

    What I had in mind was many lines terminating at many positions around the border, each line marked with how much gap it leaves. Then the first line to not go as far as the others would be the penultimate one. Your idea sounds a lot easier. But ideally the ideas could be combined if the doc were to be published for many to use for that purpose.












  • That would work if dates are not reused. But if you have a block of \DTMsavedate variables in the preamble and then refer to those dates throughout the doc by the variable name you assign, the spreadsheet would be more trouble than it’s worth because you would have to copy-paste all the dates into the spreadsheet, choose the new format, copy them back, and risk the update anomaly in the event that you revise a date in the preamble. Could be useful for some situations though. But I guess I would still rather replicate \DTMsetdatestyle{default}\DTMsetup{datesep=/} in every cell that needs it.





  • Literally just print as PDF on Windows, you can pick if you want greyscale or coloured…

    That’s a non-starter for the same reason I mention: color backgrounds are dithered and colored text becomes various shades of gray, not black. There are lots of dithering techniques to experiment with and some might yield black text, but if I am producing a PDF I would not want to impose that kind of expertise and experimentation on the end user.

    I am asking how to produce a PDF that has a mono mode and a color mode – and whether that technology even exists. If the PDF is rendered on the screen, it might have color backgrounds. But when printed to a mono device, the color backgrounds should be stripped out (or not, depending on my specification).

    If you want to produce a nice PDF from a markdown document, I recommend the knitr package in RStudio with R, and writing an .Rmd file such that you can just place all your graphs/code/text in it as you write, including LaTeX stuff.

    I am not starting from a markdown doc, but I would if that made a difference. I’ve never used RStudio. Does that produce a PDF that has two representations, mono and color?