Traumflug

When we are talking about GDPR, we should stick to the text of GDPR law. You can do that in a forum for lawyers. Laws always have to be interpreted and if you think you can do this interpretation better than actual lawyers, that's pretty bold. For my part I'll stick to how independent/neutral lawyers interpret this law. Especially if such an interpretation follows simple logic more than some personal interpretation. Above I've shown you how persistent cookies can be used to track visitors, you ignore this totally.

Um Min. 44:30 erklärt Jan Phillip Albrecht, dass es "viel zu einfach ist, für Abmahnungen Gebühren zu kassieren". Um 1:08:40 wiederholt er diese Ansicht noch mal. Das stimmt doch mal vorsichtig zuversichtlich, dass diese kostenpflichtigen Abmahnungen in absehbarer Zeit verschwinden. Denn wo immer man die Diskussion um die DSGVO beobachtet, es geht mehr um die Sorge vor Abmahnungen als um das eigentliche Gesetz.

I don’t care about that. Obviously. If you don't trust EC lawyers you probably trust my word much less, so its moot to continue this discussion.

@smarterweb, some quick research found that PHP handles file modes differently on Windows vs. a Unix-type OS. Which kind of OS is your server running?

@datakick said in PGRD Compliancy Module: Basically, any collected information that can be used to identify natural person is subject to GDPR. That's true, and that's exactly the reason why any such collection needs user consent. Simple message: don't collect.

@datakick said in PGRD Compliancy Module: @traumflug said in PGRD Compliancy Module: Persistent cookies are considered to be personal data for their sheer existence. It doesn’t matter what’s inside. This is nonsense. Show me where, in the GDPR text, is this written. It's written here: http://ec.europa.eu/ipg/basics/legal/cookies/indexen.htm#section2 The ePrivacy directive [...] requires prior informed consent for storage or for access to information stored on a user's terminal equipment. In other words, you must ask users if they agree to most cookies and similar technologies (e.g. web beacons, Flash cookies, etc.) before the site starts to use them. And then a couple of exemptions are noted. Common to all those exemptions: they're not persistent. The reason why a persistent cookie is personal information regardless of its content is simple: it's stored on the user's PC and sent on subsequent visits. In your example this means, if the server finds a cookie which sets the theme, it sees "Hey, this user was here earlier". If your theme doesn't use such cookies maliciously its entirely fine, still you have to ask for consent. Or use session cookies.

Great thing! And yes, one of the long standing enhancement requests: https://github.com/thirtybees/thirtybees/issues/397

Do you have non-standard modules installed? Causes for trouble are pretty often found there. But this also gives the opportunity to narrow down that trouble by disabling all the non-thirty-bees modules, then to turn them back on one by one, while exercising what went wrong before.

What?! And what evidences can we have in case of abuse [without recorder IP addresses] ? Regarding Apache/Nginx logs and such stuff, recording them for a "limited persistent duration" is explicitly allowed. See http://ec.europa.eu/ipg/basics/legal/cookies/indexen.htm#section2 , 5th bullet point. Which means, just rotating logs fast enough should bring compliance. If IP addresses disappear from logs after a week it should be compliant with GDPR. And to be honest, one doesn't really need logs older than a week for fighting abuse, right?

Not to upset your lawyers, but not every lawyer understands how cookies work. Persistent cookies are considered to be personal data for their sheer existence. It doesn't matter what's inside. Solution: either make it a session cookie, so the browser deletes it after the session, or ask the user for permission to store this cookie. Maybe you do this already, which is why your lawyers agree.

No FB, no newsletter, no OPT-in. Nothing. Just basic shop. Excellent, congratulations! Drawback: too simple, no module needed: https://forum.thirtybees.com/topic/1796/gdpr-panic-meets-rational-thinking

As we all know, goal of the GDPR is to reduce storage of personal data, especially for extended periods of time. Simple and obvious (but rational) solution is to remove such storage from the software. Done for DokuWiki yesterday, made a nice post, along with a HowTo, providing patches: DokuWiki Issue Comment What happened? Well, Extensive explanations why every single piece line of code has to stay the way it is and why months of head scratching about legal fine print is much more appropriate than applying a patch and solving the underlying problem. The issue gets closed and locked. Without changing the software, of course. Out of sight, out of mind. With this kind of experience I wonder whether it makes sense to solve the underlying problem for thirty bees. In the weeks of discussions here and hundreds of posts, only one link came along with what I think is the right direction: http://ec.europa.eu/ipg/basics/legal/cookies/indexen.htm#section2 Thanks to the person posting it, very helpful. It boils down to "Take law makers by their word". They do want e-commerce (and other types of websites) to be successful. But what should thirty bees do? Let people stick in their panic**? Provide some important looking band aid? Actually solve the problem and risk that nobody believes in such a solution? I don't want merchants using thirty bees to get upset in a fashion similar to the DokuWiki guys. I'm not sure. Opinions welcome. **) I hope I didn't upset people by just telling about the behavior I think I've detected.

Let's track this on Github: https://github.com/thirtybees/thirtybees/issues/522

Unexpected token < in JSON at position 0 This means some Ajax callback delivers HTML instead of JSON. Usually an error page. Last time this was seen it was solved by re-uploading all the distribution files, deleting the database and starting over. If this doesn't help, more information is needed. If you don't feel like entering Firefox' developer toolbox for looking up what that non-JSON is, I'd ask for web access, so I can attempt an install myself.

No votes? Also no complaints, so forwarded this to the 1.0.x branch to get it into the next release.

Ich war früher aush sehr angetahn für Kontaktformular Checkbox. Aber jetzt nich mehr. Weil da gibt es auch mein handynummer und meine adresse auf meine seite. Eine Checkbox am Kontaktformular? Sehe ich keinen Grund für. Wenn mir jemand eine Frage schickt und die Email-Adresse beilegt ist es doch klar, dass er damit eine Einwilligung für eine Antwort gibt. Sonst macht eine Frage ja keinen Sinn. Bestenfalls ein kleiner Text, der die Leute nochmal an diesen Zusammenhang erinnert. Wenn man die eigene Telefonnummer angibt sollte das auch kein Problem sein. Ist ja nicht die Nummer des Kunden/Besuchers.

Das update auf 1.0.4 ist auch "ganz normal". In dem Sinn, dass man den gleichen Weg beschreitet wie jemand, der mit thirty bees angefangen hat. Dass das ein bisschen umständlich ist, ist eben im Moment so. Ist ja gerade in Arbeit.

I read some article that css grid is better than bootstrap, available natively in the browser, cleaner html, more flexibility, and it will be the future of web layouting. I looked into this article and it basically recommends stepping back to having no formatting in HTML. Just like it was recommended before Bootstrap arrived. All this with the knowledge that modern browsers ( < 1 year old) now support reasonable formatting. While this is certainly a way to consider, it also requires formatting rules for every situation ever happening. Less HTML, much more CSS. Unless you have a very standardized layout like e.g. Wikipedia. My $0.02.

Die Erfahrung zeigt, dass es ohne harte Einschnitte nicht geht. Das Gesetz ist ja inzwischen 2 Jahre alt, trotzdem klammert sich so ziemlich jede Software and den vorherigen Gewohnheiten fest. So ist das eben mit den Menschen.

Wie sieht denn das Upgrade aus? Es gibt ein Modul in Version 1.0.0 https://github.com/thirtybees/psonesixmigrator/releases/tag/1.0.0 Bisher konnte ich aber nicht viel darüber erfahren außer das es seit dem 26 Apr 2017 nicht mehr geupdatet wurde. Läuft es Stabil? Ja, das läuft stabil. Dass es manchmal trotzdem Probleme gibt liegt in der Regel an einzelnen Modulen. Prinzipiell funktionieren zwar alle Module für PS 1.6.1.x auch mit thirty bees, doch der eine oder andere Entwickler hat dann eben doch irgendwelche dirty tricks eingebaut. Ein "beliebtes" Problem sind auch Module für einfachere URLs. Bei PS ist da ja immer eine Referenznummer vorne dran. Dazu gibt es Module, die diese Nummer verschwinden lassen. In thirty bees sind diese Module einfach überflüssig, denn diese Funktionalität ist fest eingebaut. Also das Module einfach entfernen, dann geht's wieder. Will man einen schon laufenden Shop migrieren, ist es eine gute Idee, erst mal eine Kopie zu migrieren um zu sehen, wie gut das funktioniert.

Dezeit gibet es auch kein modul für direkt migration von PS 1.6.xx zum TB 1.0.4, aber ich denke das soll sich auch bald ändern. Ähm, das bleibt eher so. Ist ja auch kein Problem, denn wenn man zu 1.0.1 migriert hat, kann man ganz normale thirty bees Updates machen.

How about this, see the distinction? Is this helpful or more confusing due to the additional distraction? Related commit: https://github.com/thirtybees/thirtybees/commit/5f1a6add33a4ed70cfa572c3328b3e12d6628c53

@wakabayashi said in DSVGO ThirtyBees Modul: Ich lese gerade ein Interview: https://www.zeit.de/digital/datenschutz/2018-05/vera-jourova-eu-kommissarin-datenschutz-grundverordnung-dsgvo/seite-2 Was soll man dazu noch sagen? :dizzy_face: Zitat: ZEIT ONLINE: Die großen Konzerne können einfach einen Anwalt anrufen, um die DSGVO umzusetzen. Aber kleinere Betreiber, gerade Blogger und Vereine, haben oft nicht das Geld und wissen nicht, wie sie alle Kriterien umsetzen sollen. Jourová: Die sollen mir eine E-Mail schicken. (E-Mail: [email protected]) Was man dazu sagen soll? Ich muss gestehen, dass ich mit der DSGVO auch nicht gerade unüberwindliche Hürden sehe. Soweit ich das bislang überblicke, kann man das schon alles machen. Das Problem sehe ich eher darin, dass all die verfügbaren Softwaren bislang einfach wie verrückt Daten gesammelt haben. "Kostet ja nichts, vielleicht kann man's mal brauchen" oder "Ist einfacher" oder so ähnlich. Entsprechend braucht es jetzt eine recht grundsätzliche Änderung der Denkweise. Das ist die grösste Hürde, die ich sehe. Da muss seit Jahren existierender und einwandfrei funktionierender Code überdacht werden, total entgegen dem üblichen "funktioniert doch!", das üblicherweise als höchste denkbare Qualitätsstufe angesehen wird (tatsächlich jedoch das unterste akzeptable Minimum darstellt).

We will have to get used to use true session cookes Sounds reasonable. I'd even say there's no reason to set a cookie until the visitor puts something into the cart. And then one can make the consent part of the click on 'buy'. Zero additional hurdles. That said, I certainly see how hard it is for many to say bye-bye to cookies which are simply there, for years.

Unless you uploaded manually crafted thumbnails it's safe to simply regenerate them. The sum of product images is pretty big, because themes need so many different sizes. By default there are 8 sizes for each product image, plus another 8 sizes for high resolution images (if enabled), plus the original.