Web, mail, IRC, IM, hálózatok

Német agybaj újratöltve: Illegálissá válhat a reklámblokkolás, börtön is járhat majd érte

Illegálissá válhat a reklámblokkolás, börtön is járhat majd érte Európában?

Hamarosan illegálissá válhat a reklámok blokkolása a weboldalakon, amiért akár börtönbüntetést is járhat majd - legalábbis Németországban. Egy, a napokban meghozott döntésével ugyanis a német Szövetségi Legfelsőbb Bíróság (BGH) kimondta, hogy a weboldalak kódja is lehet a szerzői jog által védett alkotás, amik engedély nélküli módosítása a szerzők engedélye nélkül így kimerítheti a szerzői jog megsértésének bűncselekményét is.

Is Germany on the Brink of Banning Ad Blockers? User Freedom, Privacy, and Security Is At Risk. – Op [blog.mozilla.org]

Springer vs Adblock Plus enters another round

(Láthatóan a forrás pcforum mint malac a jégen küzd az reklámblokkolás ellen, de nem sok sikerrel :-)

Phishing a Cisco támogatásával

Honeypotom kellemes esti szórakozást dobott fel egy phissing levél képében. A levelező szerverem adminja tájékoztatott, hogy 7 levelem van visszatartva és klikkeljek a lenti linkre:
https://secure-web.cisco.com/1aur891QxqfxRaoPbe2SixJVRc1OGSqy0cvne9f52k…

Lévén a levelező szerveremnek én vagyok az adminja és a melóhelyen még nem szívtam annyi hidrazint, hogy magammal levelezzek, utánatúrtam a linknek.
A dolog innen kezdve a klasszikus pingpongos, javascriptes átküldözgetéses történetbe torkollik, ami a grillráccsos hosttól a tinyurl-en keresztül egy https://u64.rspglmb.org/sec oldalra landol, ami szintén egy faék egyszerű javascriptes oldallal próbálja behúzni a emailünkhöz tartozó jelszót.

A dologban nincs újdonság, egyedül az induló link csomagolása.
 

Halva született kezdeményezés az EU 18 éves kort ellenőrző "pornókapu" app-ja

Ahogyan az várható volt, már szinte születése pillanatában kijátsszák az EU bürokratáknál láthatóan sokkal értelmesebb és leleményesebb tini gyerekek a pornó-kaput:

https://cyberplace.social/@GossiTheDog/114915518256108559

A videójátékok segítettek a rendszer kijátszásában. 

Logrotate.d: napi rotálás kimaradása

Be van állítva a mail.log fájlra, hogy a logrotate naponta rotálja, mégis tegnap egy napot kihagyott. Előtte is rotált, ma is rotált. Mi lehet az oka?

A logrotate.d/mail fájl tartalma:

/var/log/mail.log
{
    rotate 378
    daily
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

A /var/lib/logrotate/status fájlban minden nap, azaz tegnap is bekerült az aktuális napi dátum.

A naplóban mindhárom napon szerepelnek a következő sorok:

Starting logrotate.service - Rotate log files...
logrotate.service: Deactivated successfully.
Finished logrotate.service - Rotate log files.

Néha még a "logrotate.service: Consumed 2.218s CPU time." sor is szerepel, de más nem, azaz hibaüzenet sincs.

A cron naplójában sem látok semmi furát, eltérést a napok között, nincs hibaüzenet.

Az /etc/logrotate.conf fájlban nincs globálisan megadva a "size" paraméter.

A nem rotált naplóból látszik, hogy minden nap sok sor kerül bele, így a "notifempty" opció sem okozhatta.

Van ötletetek, miért marathatott egyben a tegnapi és a tegnapelőtti log?

Kinek kell az APNG?

Ennek a topiknak a kapcsán gondolkodtam el, hogy mégis, mi haszna? Használná valaki?

Mert hát, ha egy weblapra valami kis izgő-mozgó biszbasz kell, arra sokkal jobb és hatékonyabb a GIF. De még rövid videókra is, mert elég sokat fejlődtek a kvantáló és dithering algoritmusok (aki nem hiszi, látogasson el a giphy-re).

Ha meg valakinek tényleg szűkös a GIF, azoknak régóta ott a WEBP, ami szintén elérhető minden böngészön, kezel palettás képeket, true-color képeket, alfa csatornát és animációt is (nem összekeverendő a WEBM-mel, ami csak videókra jó, transzparens animációkra nem). Egyszóval mindent tud, amit az APNG akar nyújtani, csak hát sokkal jobb a tömörítése.

Szóval a kérdés az, lát-e valaki gyakorlati hasznot abban, hogy szabvány lett az animált PNG? Szerintetek meg fog ugrani az APNG képek száma a wenoldalakon ezután, ha ezidáig elhanyagolható volt annak ellenére, hogy eddig is támogatták a böngészők?

ps: az, hogy az APNG nem hatékony és szar, nem újdonság. Az eredeti PNG fejlesztők is így gondolják, ezért inkább átdolgozták, és a hivatalos PNG oldalon is az MNG-jüket próbálják propagálni helyette (ez se mai gyerek, 1998-as, mégse volt képes ledönteni a GIF-et ez se a trónról).

Exim: túl sok hibás címzett blokkolása ip alapon

Próbálom Exim alatt korlátozni, hogy egy IP címről csak mondjuk 5 hibás címzettre tudjon megpróbálni levelet küldeni valaki. Sajnos az eddig próbálkozásaim nem sikerültek. Az exim kézikönyvben nem is látok per_ip opciót a ratelimit-hez.

Ha valaki csinált már ilyet, megköszönnék egy működő szabályt.

Nincs tovább YouTube autoplay on/off gomb ? [MEGVÁLASZOLVA]

2-3 napja eltűnt a YT-videók automatikus lejátszást ki-bekapcsolásának dedikált gombja  (a beállítások gombtől balra volt 1-2 cm-re).

Kicsit szétnéztem, és több friss reddites bejegyzés alapján többek szerint, ez a Google válasza az adblock kiegészítőkre, mivel az adblock kipacsolása után egyeseknél ismét volt leállítási lehetőség az autoplayre.... Valamint a YT automatikusan összeállít egy lejátszási listát a jobb oldali oszlopban, ami véglegesen lelőni sem lehet (ekkor csak összecsukódik).  Ha pedig e lista kerete alatti "szóló" klippre kattintok, akkor új listát állít össze.

Firefox-ESR alapú LibreWolfot használok MX Linuxon incognito módban,  de mivel ez több böngészőben (Chrome, Brave, Firefox)  és Windows alatt is fenáll,  így nemigen nálam lesz a hiba.

Reklámblokkolónak a uBlock Originalt használom, pliuszban még a CanvasBlockert van fenn, de ha uBO-t kikapcsoltam majd a böngésző gyorsítótárának tartalmát törölve (teljes) újrabetöltöttem a YT-ot, akkor sem jelent meg az autoplay on/off gomb.

Tehát akkor vagy nem az adblock miatt van ez, hanem ez egy új "feature" a YT-on, tessék neki örülni.  Vagy pedig valahogy a Google  mégiscsak  valahogy be tud azonosítani a valótlan canvas-adatok és az incognitó-mód ellenére is, és a korábbi blokkoló-használat miatt már listán vagyok, és így nálam már sosem lesz autoplayt kikapcsoló gomb ? ... Ez utóbbi valószínűtlennek gondolom, de sosem tudni. Elvégre "a Google a legjobb barátod",  nem igaz ?

Keresgéltem a Firefox addon-ok közt, de nem igazán találtam olyat, ami:

-- kicsi  (50-60 kB-nál nem nagyobb),

-- ténylegesen kikapcsolja/blokkolja az automatikus lejátszást mellékhatások és a uBlocK Origin kikapcsolása nélkül is,

-- és  lehetőleg nyílt forráskódú.

Általában már az első két feltételen elvéreztek a beépülők.

 

Tud bárki valami  megoldást, pl. kerülőutasat  az about:config beállításai közt,  vagy akár egy olyan addont, ami valóban blokkolja az automatikus lejátszászt, nem több száz kB-os, nem akad össze az uBO-nel, és lehetőleg opensource is ?

Akár alternatív YT-böngészőt is ajánlhattok.  Minitube-ot próbáltam a böngésző helyett, de olyan kevés funkció van benne, hogy egyelőre nem használnám, ha egy mód van rá.  (Pl. a keresés eredményeként valószínűleg szintén a YT-által összeállított listát tölti be, és pl. a "Kistehén"-re keresve, a listába már nagyon sok nem odaillőt is berak  (az hagyján, hogy más hasonló, "alternatív" zenekarokat is betett a listába, de mikor a "zsiguzsululés cigánygyereket tolta a képembe, az már sok volt).

 

Köszi minden tippet !

[Megoldva] Nextcloud SSL gond

A problémám a következő: Nextcloud telepítve proxmox VM-ben. Innen. (Egyébként szuper munka, ha valakinek kell egy előkonfigurált natív nextcloud vm, jó szívvel ajánlom. A post install script is zseniális!) A VM importálása és a telepítés is simán zajlott. Http-n tökéletesen üzemel. Szerettem volna saját tanúsítvánnyal validálni. Ehhez ezt a leírást követtem. Feltöltöttem a megfelelő könyvtárakba a pem és a key fájlokat, módosítottam a default-ssl.conf állományt. Majd amikor újraindítottam az apache2 service-t akkor ezt kapom:

Jun 06 10:48:53 nextcloud systemd[1]: Starting apache2.service - The Apache HTTP Server...
Jun 06 10:48:53 nextcloud apachectl[2031]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Jun 06 10:48:53 nextcloud systemd[1]: apache2.service: Control process exited, code=exited, status=1/FAILURE
Jun 06 10:48:53 nextcloud systemd[1]: apache2.service: Failed with result 'exit-code'.
Jun 06 10:48:53 nextcloud systemd[1]: Failed to start apache2.service - The Apache HTTP Server.
root@nextcloud:~# systemctl start apache2.service 
Job for apache2.service failed because the control process exited with error code.
See "systemctl status apache2.service" and "journalctl -xeu apache2.service" for details.

Itt ugye az a helyzet, hogy saját fix ip-n van a szolgáltatás (illetve van FQDN is), de ő a 127.0.1.1 címen keresi. Vagy más a hiba?

Mit kell tennem, hogy működjön?

Mi a hivatalos módja egy gépen a saját cert importálásának?

Köszönöm!