debanqued

cross-posted from !gdpr@sopuli.xyz : https://beehaw.org/post/21385410

As I mentioned in another post, many data protection authorities are deadbeats. Knowing that my Art.77 complaints are in vain, my question is how the complaints might be made useful. Suppose we just use the DPA as a prop. We file an Art.77 complaint and CC the data controller a copy of the complaint.

Normally it might be a bad strategy to show the data controller your hand. But when you essentially expect the DPA to be a dead-end anyway, perhaps our best move among shitty options is to use art.77 to get the data controller’s attention on the off chance that the data controller does not know the DPA is a deadbeat.

As I mentioned in another post, many data protection authorities are deadbeats. Knowing that my Art.77 complaints are in vain, my question is how the complaints might be made useful. Suppose we just use the DPA as a prop. We file an Art.77 complaint and CC the data controller a copy of the complaint.

Normally it might be a bad strategy to show the data controller your hand. But when you essentially expect the DPA to be a dead-end anyway, perhaps our best move among shitty options is to use art.77 to get the data controller’s attention on the off chance that the data controller does not know the DPA is a deadbeat.

cross-posted from !gdpr@sopuli.xyz : https://beehaw.org/post/21385256

Many data protection authorities are deadbeats. They do the legal minimum, which is to accept complaints, file them, and acknowledge them. Then do nothing. So stale cases just rot.

Data subjects have a right to complain (Art.77) at no cost, but they apparently do not have a right to a free appeal and the art.78 right to sue is not gratis either.

Unlawful inaction can legally be appealed but appeals are costly. DPAs know this, so they enjoy getting away with neglecting to act on Art.77 complaints.

So first I wonder if my legal theory is sound: If we have a right to complain under art.77 at no cost and the DPA neglects to investigate, then by extension we could argue that a right to complain at no cost implies a right to appeal inaction at no cost. Is that a weak argument? Do we need to ask EU lawmakers to specifically guarantee the right to a free appeal of DPA inaction?

Many data protection authorities are deadbeats. They do the legal minimum, which is to accept complaints, file them, and acknowledge them. Then do nothing. So stale cases just rot.

Data subjects have a right to complain (Art.77) at no cost, but they apparently do not have a right to a free appeal and the art.78 right to sue is not gratis either.

Unlawful inaction can legally be appealed but appeals are costly. DPAs know this, so they enjoy getting away with neglecting to act on Art.77 complaints.

So first I wonder if my legal theory is sound: If we have a right to complain under art.77 at no cost and the DPA neglects to investigate, then by extension we could argue that a right to complain at no cost implies a right to appeal inaction at no cost. Is that a weak argument? Do we need to ask EU lawmakers to specifically guarantee the right to a free appeal of DPA inaction?

The documentation of every FOSS tool I encounter leaves something significant to be desired. The state of docs in software (FOSS and non-FOSS both) are mostly a shit-show across the board.

But exceptionally, the gnucash project demonstrates exceptionally good docs. There is a separate package for the docs in Debian (gnucash-docs), which is what the Debian project suggests when the docs are significant in size. The /usr/share/doc/gnucash-docs dir has:

AUTHORS
changelog.Debian.gz
changelog.gz
copyright
gnucash-guide-de/
gnucash-guide-de.pdf.gz
gnucash-guide-en/
gnucash-guide-en.pdf.gz
gnucash-guide-it/
gnucash-guide-it.pdf.gz
gnucash-guide-ja/
gnucash-guide-ja.pdf.gz
gnucash-guide-pt/
gnucash-guide-pt.pdf.gz
gnucash-help-de/
gnucash-help-de.pdf.gz
gnucash-help-en/
gnucash-help-en.pdf.gz
gnucash-help-it/
gnucash-help-it.pdf.gz
gnucash-help-pt/
gnucash-help-pt.pdf.gz
NEWS.gz
README.gz

PDFs are great because web browsers and HTML have become such a shit-show. PDFs nearly guarantee you will see the doc as intended by the creator, without any dependency on a functional cloud with hosts that never change. There is also an HTML version that simply works offline, images and all (unlike ImageMagick, where the offline HTML is totally dysfunctional). The app’s built-in help goes straight to the topic seamlessly. It’s quite thorough documentation. They have 184 figures.

The only thing they seemed to have missed:

$ man gnucash
No manual entry for gnucash

Oops! Can’t get everything right.

One of the shittiest things I’ve seen on a lot of projects are docs that reference Cloudflare sites. 🤦 So you not only need Internet access, but you also need to lick Cloudflare’s boots, dance for the captchas, etc. And the Debian project is okay with that - yikes! I don’t think gnucash does that anywhere.

Anyway, before documenting a FOSS package, please look at gnucash for a good example (but of course there should always be a man page).

Front-desk receptionists installed in the buildings of gov agencies, news offices, and large companies sometimes have (or act like they have) a strict protocol of tasks that they can or cannot do. If I ask them to page/call relevant staff for something, or to sign for a delivery, they answer to the effect of:

“That is not in my job description…”

or

“Nope, not on my list… I have no scripted process or procedure for that…”

Some receptionists will say “do you have an appointment?”, to which I answer “if an appointment is needed, please make one for me”. They can never handle that. They say call or email, which of course excludes¹ people.

It’s increasingly more common for the outsourced security receptionist to be dumbed down to know nothing about the org they are keeping a gate for, to have no visibility on schedules and no ability to page people. These “people” typically have no capability beyond writing a call center phone number or URL on a post-it note.

I have to wonder, if these unskilled people are going to be so stripped of basic capability, unable to cater for the needs presented in a situation, why even have them? They are good candidates to be replaced by robots, or even just a sign-posting with a QR code on it².

It’s in everyone’s interest for that threat to be looming, and for such receptionists to come to realise that their own job security relies on being customer oriented (not their boss as a customer, but the ultimate customer, who won’t give a shit if a robot replaces a human that acts just like a robot anyway).

Consider the insideous #forcedBanking dimension to this. Making the front desk helpless enables the org/agency to essentially maintain a non-physical presence, which they use as an rationale for refusing cash payments. The outsourced recepionist can be passed off as someone who does not represent the org/agency and thus cannot handle cash payments.

¹ Calling excludes people because call centers have a limit number of languages they can handle, and even if you’re lucky enough to get someone with a compatible language, you lose the possibility of body language, a bad quality signal makes rough language rougher, and if one side gets tired of speaking a non-native language it’s easy enough to just hang up. Calling also is not free. And email is also exclusive

² (in fact I’ve seen it happen.. a gov office receptionist got replaced with a QR code pointing to a dysfunctional website)

Call to action

Maybe print this rant on a flyer that starts with “Dear receptionist…” and keep a copy when you approach a front desk. If they turn out to be a human acting like a bot, give them the flyer. Suggest they read it and share it with their boss.

cross-posted from: https://beehaw.org/post/20493770

^ indeed this is cross-posted back to the same community it originated, because slrpnk.net was offline when the post was introduced and Lemmy is not advanced enough to sync caches with original communities.

Email is a non-starter for reasons such as not being in control over who the other party chooses as an email supplier (thus resulting in Microsoft being fed all email traffic).

So snail-mail is the winner. My snail-mail obviously gives a mailing address. From a practical standpoint, that’s all I need. But it would be good to show some kind of electronic means of communication in the letterhead. Not directly for practical use but more of an expression that says “I’m not a luddite but you need to fix your shit” (in so many words).

Requirements:

• must be secure. A low standard of security is fine; it just cannot be so shitty that giant surveillance capitalists can see and exploit the payloads.
• must not rely on any non-standard or proprietary protocols.
• must have at least one FOSS toolchain available.
• must be suitable for documents sent asynchronously.
• ideally a different unique address can be furnished to each recipient.

Candidates:

• XMPP
• onion e-mail (email service by surveillance capitalists cannot send to @*.onion addresses)
• (hypothetical) clearnet email address hosted by a server that blocks inbound MS & Google server connections
• fax number

One problem with the above candidates is I don’t think the 1st two options have any kind of aliasing (I only know of one onion email service that deliberately lacks a clearnet alias, and it does not have aliasing on the userid portion). So I would have to create many accounts and they would never actually get traffic. They would just be symbolic. And the third candidate does not even exist AFAIK.

Problems with the fax number: these are not cheap and I would need a fax number for different countries. Also fax services are gatewayed so some senders send an email to a fax service the dispatches a fax, in which case Microsoft would still see the payload.

Email is a non-starter for reasons such as not being in control over who the other party chooses as an email supplier (thus resulting in Microsoft being fed all email traffic).

So snail-mail is the winner. My snail-mail obviously gives a mailing address. From a practical standpoint, that’s all I need. But it would be good to show some kind of electronic means of communication in the letterhead. Not directly for practical use but more of an expression that says “I’m not a luddite but you need to fix your shit” (in so many words).

Requirements:

• must be secure. A low standard of security is fine; it just cannot be so shitty that giant surveillance capitalists can see and exploit the payloads.
• must not rely on any non-standard or proprietary protocols.
• must have at least one FOSS toolchain available.
• must be suitable for documents sent asynchronously.
• ideally a different unique address can be furnished to each recipient.

Candidates:

• XMPP
• onion e-mail (email service by surveillance capitalists cannot send to @*.onion addresses)
• (hypothetical) clearnet email address hosted by a server that blocks inbound MS & Google server connections
• fax number

One problem with the above candidates is I don’t think the 1st two options have any kind of aliasing (I only know of one onion email service that deliberately lacks a clearnet alias, and it does not have aliasing on the userid portion). So I would have to create many accounts and they would never actually get traffic. They would just be symbolic. And the third candidate does not even exist AFAIK.

Problems with the fax number: these are not cheap and I would need a fax number for different countries. Also fax services are gatewayed so some senders send an email to a fax service the dispatches a fax, in which case Microsoft would still see the payload.

Indeed, MS only makes GDPR rights available to people who are willing and able to solve their graphical CAPTCHA. You must execute their JavaScript and have image rendering enabled in your browser.

For sighted people it’s not the more shitty varieties of CAPTCHA. Looks easy. But still fucked up that there is a barrier to exercising GDPR rights.

Suppose you have the following parties to an email conversation:

• badDebtorOffice@douchebank.com (alias for bdo@douchebank.mail.protection.outlook.com)
• alice@freedomRespectingProvider…org

Douche Bank¹ manages to collect Alice’s email address either legitimately from her or illegitimately without her consent. DB sends her an email like this:

From: "Douche Bank" 
To: "Alice Marie Smith" 
Subject: Your unpaid debt of €20,000 on account № 354-987-156

Pay up.

Alice did not choose to do business with Microsoft Corporation and does not trust MS in the slightest. Yet Douche Bank has exposed sensitive financial information about Alice to MS, potentially without her consent. She may or may not have supplied an email address to D/B but certainly she opposes MS receiving her sensitive data, which it will then exploit to the fullest for surveillance marketing or otherwise.

Alice has no control over her bank’s choice of email provider. But in principle the GDPR is expected to give her control over her data exposure. If she makes an art.17 request to erase the privacy-abusing email, it’s too late b/c MS already saw it. The bank would not erase it because they have a legit need to track the fact that they sent a payment reminder. The bank /can/ mirror Alice’s art.17 request to MS if they are motivated, but most likely they will not, particularly if the bank is not treating the art.17 request themselves. And most likely MS would ignore it anyway.

If Alice sends a GDPR request direct to MS to erase MS’s copy of the email, MS would naturally respond with something like ”who are you? You are not our customer. Therefore we cannot properly identify you in accordance with GDPR rules. Also, we are just a “data processor” not a “data controller”. Sorry.. you can fuck off now.” (in so many words)

If Alice were to complain to the Data Protection Authority of Germany (where MS is headquartered), they would be helpless in this situation. I mean, there is Art.32 which requires processing to be secure, but most data controllers seem to be ignoring Art.32 w.r.t Art.77 requests. EDPB said in their “Contribution of the EDPB to the report on the application of the GDPR under Article 97” report:

“fines were imposed … for failure to comply with the obligations with regard to the rights of the data subjects (Article 12 to 22 GDPR),”

IOW, infringements on Articles outside the Art.12-22 range are not considered by the EDPB as “rights of the data subjects”. I’ve seen a similar sentiment expressed in other places.

¹fictitious name inspired by Deutche Bank/Bank of America

I read somewhere that GDPR requests for restricted processing (Art.18) cannot be combined with any other topic or request. E.g. If you request that they not use your e-mail for marketing purposes.

WTF. Yes, I understand the idea is that if the request stands on its own, it cannot be overlooked. But #GDPR requests are ignored so often that I deliberately combine a GDPR request with another request that is more difficult to ignore. That way when they ignore the GDPR request but treat the non-GDPR request from the same letter, it proves that the data controller received my letter. When a GDPR request is made on its own, they can more easily claim the letter never came and shift the proof-of-delivery burden onto me.

For the past four months beehaw has been unreachable to those of us on the Tor network. Glad to see access was finally restored. Was there an attack?

I could really use a way to periodically backup my posts to my local disk so if Tor is spontaneously blocked again I at least have my history. I’ve not found a Lemmy equivalent for Mastodon Archive.

(edit) For security, it would be a good idea to setup an onion instance. The Tor network has built-in DDoS protection for onion hosts.