Dear Email Industry, We’ve Got a GDPR Problem • Hacker News Board

Re: Dear Email Industry, We’ve Got a GDPR Problem

#211

Post by xamolxix » Fri, Sep 20, 2019, 5:00 PM UTC

mytailorisrich wrote: post #207

isostatic wrote: post #201

Earlier quoted context omitted.

> Now, what additional personal data are collected by tracking pixels? If I read it, when I read it, where I read it from (location, device, etc)

None of these are personal data if not liked to the email address, which they do not have to. If linked to email address and considered personal data then the argument is what is covered by consent to receive email marketing? IMHO tracking whether the email was opened is covered (in the same way as agreeing to receive phone marketing should imply they can track whether you answered the phone...). They will also obvio…

> in the same way as agreeing to receive phone marketing should imply they can track whether you answered the phone.

But agreeing to receive a snail mail does not imply consent to track if it was read. I feel that email is closer to that.

Re: Dear Email Industry, We’ve Got a GDPR Problem

#212

Post by danaris » Fri, Sep 20, 2019, 6:29 PM UTC

robin_reala wrote: post #177

danaris wrote: post #134

Earlier quoted context omitted.

I’ve had several groupings of unsolicited marketing emails over the years where I’ve clicked Unsubscribe and ended up on what’s very clearly a Totally Not That Email List, Honest...but it’s advertising the same things, in the same way, just from a slightly different email and possibly different company name. They have all been American in origin.

Easy enough to fix: use a unique address for a company, unsubscribe, then take the related company to court later. Works even better in a GDPR location.

Right; with my unlimited resources, time, and understanding of the legal system.

I mean, I'd love to be able to, but do you think I'd even be able to determine what the company's actual address is?

Re: Dear Email Industry, We’ve Got a GDPR Problem

#213

Post by mytailorisrich » Fri, Sep 20, 2019, 8:09 PM UTC

xamolxix wrote: post #211

mytailorisrich wrote: post #207

Earlier quoted context omitted.

None of these are personal data if not liked to the email address, which they do not have to. If linked to email address and considered personal data then the argument is what is covered by consent to receive email marketing? IMHO tracking whether the email was opened is covered (in the same way as agreeing to receive phone marketing should imply they can track whether you answered the phone...). They will also obvio…

> in the same way as agreeing to receive phone marketing should imply they can track whether you answered the phone. But agreeing to receive a snail mail does not imply consent to track if it was read. I feel that email is closer to that.

It's impossible to track letter so the point is moot.

The point is that tracking emails, like tracking phone calls, is inherent to that communication medium and there is absolutely nothing wrong with it.

Re: Dear Email Industry, We’ve Got a GDPR Problem

#214

Post by ericb » Fri, Sep 20, 2019, 10:07 PM UTC

satanspastaroll wrote: post #190

ericb wrote: post #150

Earlier quoted context omitted.

> GDPR only affects the companies abusing current system for unsoliticed advertising No. Have you looked at the thing? It affects every organization willing to do business or communicate with the EU.

The rules dictated in GDPR have been the best practices this far, now they're simply being enforced by law. The only ones that are (negatively) affected are the companies that are not wanted by the EU in the first place.

> The only ones that are (negatively) affected are ...

Not true. GDPR imposes costs on every company. Specifically there are the legal compliance costs, software compliance costs, support costs, and that's if you're a "good guy."

Re: Dear Email Industry, We’ve Got a GDPR Problem

#215

Post by barrkel » Sun, Sep 22, 2019, 5:53 PM UTC

chrismorgan wrote: post #198

barrkel wrote: post #118

Earlier quoted context omitted.

In principle, using resolution-independent units like points should be fine; it's using px instead of pt that leads to problems. (And the site is using px; it shouldn't.)

You are incorrect. All CSS units are defined in a resolution-dependent way. (I think there has only every been one exception to this, an experimental unit `mozmm`, now discontinued, that attempted to be resolution-independent, representing one physical millimetre.) On screen, the px unit is king, being defined however the device chooses to define it—most commonly one or two device pixels. All other units are defined…

I'm sure you're right - I am only ever a front end CSS dev in an emergency, and then only for desktop. That said, when I see a relative discrepancy between sizes on different media, px vs pt is where I'd look. That is, two things that might e.g. look the same size on a desktop browser but look different sizes on mobile.