3 ms·

How would the browser be able to enforce what the Actual server does with the data? This would work only for those binary track everything/don't track anything

by cowl 5y ago

How would the browser be able to enforce what the Actual server does with the data? This would work only for those binary track everything/don't track anything scenarios. Those are rare cases. What the the majority of us want and the whole purpose of the GDPR is, is the "informed consent" part. A detailed list of what information is gathered and how it is going to be used. A browser can not really enforce "I give you consent to use my data for "Use-case" in this site but don't use it for advertising or sell it". And since the potential uses are thousands, a generic form can not be used as a real consent form. The only way is the planned way. Every site/App Declares what/how they are using the collected data and take legal responsibility in case of infraction.

jeroenhd 5y ago
It wouldn't be able to control anything on the backend, but neither can it control the tracker behabvour in the cookie popups. That's where the border between technical and legal issues is crossed. My idea for consent would be a sort of challenge/response protocol, where the sending party sends a request for consent with all the details they need and the browser approves or denies it. Preferably, this would be done automatically based on the user's settings. It could even be part of the CORS system, leveraging the browser's "firewall" to ensure no data gets leaked to misconfigured trackers and forcing companies to comply. The thing about consent is that it must be freely given. Therefore, it should always be opt-in. The user can opt into certain stuff from some kind of simple control after reviewing the requests the other party sends, but that stuff should be hidden and denied by default. A general declarative method would probably lack some finesse. For example, when your user account has a certain country set, a server might load in payment providers on the fly, and the manifest should reflect that. The manifests we have today would get cached way too quickly, I think.

by cowl 5y ago

jeroenhd 5y ago

It wouldn't be able to control anything on the backend, but neither can it control the tracker behabvour in the cookie popups. That's where the border between technical and legal issues is crossed. My idea for consent would be a sort of challenge/response protocol, where the sending party sends a request for consent with all the details they need and the browser approves or denies it. Preferably, this would be done automatically based on the user's settings. It could even be part of the CORS system, leveraging the browser's "firewall" to ensure no data gets leaked to misconfigured trackers and forcing companies to comply. The thing about consent is that it must be freely given. Therefore, it should always be opt-in. The user can opt into certain stuff from some kind of simple control after reviewing the requests the other party sends, but that stuff should be hidden and denied by default. A general declarative method would probably lack some finesse. For example, when your user account has a certain country set, a server might load in payment providers on the fly, and the manifest should reflect that. The manifests we have today would get cached way too quickly, I think.