Notices by Tobias Fiebig (tfiebig@wybt.net)

"European universities urged to review dependence on top technology companies as Trump policies expose vulnerabilities" in Times Higher Education:

https://www.timeshighereducation.com/news/reconsider-reliance-us-tech-companies-universities-warned

Such discussions are increasingly taking place, Fiebig said, telling THE, “With the second Trump presidency, the risks [of depending on US providers] certainly did not change."

“What did, however, change is people's willingness to see that these risks are indeed real, and increasingly likely to materialise.”

https://boycott-ietf127.org/

@jospoortvliet @bert_hubert @niels @Karlitschek Ok, the bug is somewhat old. Something else must have changed. Change of default value?

@jospoortvliet @bert_hubert @niels @Karlitschek What I do know: How to turn it off:

Admin -> Sharing -> 'Federated Cloud Sharing' -> 'Allow people to publish their data to a global and public address book'

Which "mildly" understates the "sends for all users" part. -.-'

Brb, playing with my cats, feeding them, and then figuring out who all gets a data leak notification from me. -.-'

@bert_hubert @jospoortvliet @niels @Karlitschek to add on this: The data leaked may include:

name, email, address, website, twitter, phone, twitter_signature, website_signature, twitter_verification_status, and website_verification status.

I do not really see how one can get this data purged. This is... a disaster.

@jospoortvliet @bert_hubert @niels @Karlitschek See my post above; This seems to be something regular, constraint to specific time windows. Not relaly the maintenance window, though (at least not aligning with mine.)

@jospoortvliet @bert_hubert @niels @Karlitschek Current suspect: Notifications app ; it just got a push feature. And er... this sadly makes sense for that.

@bert_hubert @jospoortvliet @niels @Karlitschek https://github.com/nextcloud/server/issues/51335 << bug is there

@jospoortvliet @bert_hubert @niels @Karlitschek https://github.com/nextcloud/server/issues/25290 << digging here.

from: server/apps/lookup_server_connector/lib/UpdateLookupServer.php

/**
* check if we should update the lookup server, we only do it if
*
* + we have an internet connection
* + the lookup server update was not disabled by the admin
* + we have a valid lookup server URL
*
* @return bool
*/

@bert_hubert @jospoortvliet @niels @Karlitschek No worries; Real work starts now. -.-' Need to notify users, for that document this, file a nextcloud bug, report to the DPA etc. -.-' I just wanted a quiet weekend. -.-'

@jospoortvliet @bert_hubert @niels @Karlitschek We will know more shortly. Forcing all background-jobs to run actually triggers this. Now only about finding the right one.

@jospoortvliet @bert_hubert @niels @Karlitschek Job class: OCA\LookupServerConnector\BackgroundJobs\RetryJob is the culprit.

Ephemeral jobs, only present for the userIds for which the suspicious callback was seen during a run.

@jospoortvliet @bert_hubert @niels @Karlitschek Then again, why is there a commit from 2021 at the top of the history from a user that has zero other commits to server?

@jospoortvliet @bert_hubert @niels @Karlitschek FOR FUCKS FUCKING SAKE.

Ok, this is a new default setting for the new sharing integration, defaulting (seemingly? now? need to dig further... -.-') to 'yes'.

code:
https://github.com/nextcloud/server/blob/06119eda7a05f2b2861737532b84cef93af53f21/apps/federatedfilesharing/lib/Settings/Admin.php#L42

and

https://github.com/nextcloud/server/blob/06119eda7a05f2b2861737532b84cef93af53f21/apps/federatedfilesharing/lib/FederatedShareProvider.php#L1009

Latter touched in a recent clean-up effort:
https://github.com/nextcloud/server/commit/669e6cadd6bcb73df3f2cf8774e8ee2e3bfb7c77

I do not _fully_ get why the behavior change occured yet, though.

@burningTyger @bitboxer Well, the underlying truth is that the holocaust was fundamentally enabled by what we call "IT people" today.

And for some reason, nobody in IT got that memo and happily collects (meta) data without thinking about the possible dire consequences.

You can't lose data you don't have.

@bitboxer Actually; Even more so in the Netherlands. The Dutch had migrated to a fully IBM/Hollerith Machine backed public administration ('digital' first, bedenken second oder so) before the invasion. After the invasion, the German's were just like "uuuuh, we know these machines! Got a query to run, let's call our IBM consultant!";

This is why (by %/population) so many more were murdered in NL; And why the Dutch resistance burned archives:

https://www.annefrank.org/en/timeline/128/the-resistance-attacks-the-population-register-of-amsterdam/
https://en.wikipedia.org/wiki/1943_Amsterdam_civil_registry_office_bombing

@GossiTheDog It appear, after careful evaluation, that I am an idiot; Sorted by count and there was a large cluster of small things and no 3320 in there. *hide*

cat ips_bttf|grep -E '"ASN":[0-9]*' -o --color|sed s/'"ASN":'//|sort | uniq -c|sort -n|less

@GossiTheDog I have to say, I only had the second post show up in my feed. With both messages, of course you are not. 🙂

@GossiTheDog As i said, so is AS3320, so it may also be the Germans by that reasoning.

Also, i don't suspect Iran to be that... well... simple to just scrap themselves. Scrapping a usual suspect from a dataset to poke suspicion, though... might also be on the plate for some. ;-P

In any case, I'd be a bit more conservative with attribution. ;-P

@tdp_org @GossiTheDog I find the absence of, e.g., 3320 in that list a bit odd.