3 ms·

idgi, is it harder for a malicious website to ask you if you accept cross site tracking cookies and then ignore your refusal than it is for them to ignore the s

idgi, is it harder for a malicious website to ask you if you accept cross site tracking cookies and then ignore your refusal than it is for them to ignore the same instruction from your browser?

Sebb767 6y ago
No, this is about boundaries, abstractions and context really. When a browser sets a bound, the website usually has no way to override that, as the browser is above it permission-wise. Similarly, if the OS sets a boundary, the browser looses out, since it's below the OS. Fittingly, when you deny crossing such a boundary, you'd expect it to be denied. Imagine, for example, if the dialog to allow push notifications for a website would be an UAC window. It would not make sense since a) the OS would ask for something which is clearly contained within the context of the browser and b) the OS has no reasonable [0] way to know whether a notification sent by the browser is on behalf of the denied/allowed website. Similarly, it makes sense to have the prompt for tracking data in the context of the website, since it is the only context in which it can reasonably [0] handle the response. It does change the difficulty or legality of circumvention, yes, but it is a bit less security theater. At least that's the technical reason. If we're being honest, the discussion never came up, because a) laws are bad for setting technical standards in many ways and b) most site owners prefer to build their own dark patterns to get the user to click accept anyway. [0] Excluding heuristics, of course, which would just start a game of cat and mouse yet again and would necessarily be flawed.
- imiric 6y ago
  That doesn't change the fact that the current implementation is user hostile. There's no reason that privacy laws couldn't enforce a user setting at the browser level that websites could access in a standard way. Similar to the "Do Not Track" header, but actually enforceable. That would be the user friendly approach, but would require a technical committee of browser vendors, advertisers and tech giants to be part of the design process. Unfortunately the reason this doesn't happen is because the technical team would be working against their own financial interests, so there's no incentive to stop exploiting the user. Which is why the modern web is hostile to the user, and likely won't change unless the business models drastically change.
- hnedeotes 6y ago
  > Imagine, for example, if the dialog to allow push notifications for a website would be an UAC window. It would not make sense since a) the OS would ask for something which is clearly contained within the context of the browser and b) the OS has no reasonable [0] way to know whether a notification sent by the browser is on behalf of the denied/allowed website. Similarly, it makes sense to have the prompt for tracking data in the context of the website, since it is the only context in which it can reasonably [0] handle the response. It does change the difficulty or legality of circumvention, yes, but it is a bit less security theater. I see these answers and I always get the feeling that they treat existing software (browsers, websites, os) like something that was handed down by God in the book of law. The browser already asks the user for permission through the OS - it does for location, webcam, filesystem, etc - there's no context needed because you're actively engaged with it, the browser or the os system don't need any more context than the user clicked Yes or No for this request. The other part of the implementation is fining the companies. I'm sure after a few millions every month they'll stop making SDK's that don't enforce collecting authorisation from the user before tracking.
  - Sebb767 6y ago
    > I see these answers and I always get the feeling that they treat existing software (browsers, websites, os) like something that was handed down by God in the book of law. There's two sides for this. For one, this is the infrastructure that already exists and that is out there in the wild. If you start selling 500V electric appliances, people can of course buy transformers or the state could upgrade its grid, but in reality, changing the existing infrastructure to suddenly support something different is a huge effort. It's far easier and more economical to treat the given infrastructure as fixed and working within its bounds. On the other hand, it usually adds a lot of needless complexity to break layers. Sometimes it is worth it (ZFS might be a good example), but usually it isn't. Imagine, for example, if Firefox needed to be patched to support SSDs or SD cards because it did some magic and accessed the HDD firmware directly - this would arguably be a bad idea. > The browser already asks the user for permission through the OS - it does for location, webcam, filesystem, etc - there's no context needed because you're actively engaged with it, the browser or the os system don't need any more context than the user clicked Yes or No for this request. Sure it does. The OS<->Browser boundary is basically about what the browser executable itself can do to the OS; the OS has no context on the finer granularity of websites. Going back to the electrical grid: My power company is worried about bringing electricity to my flat connection; turning specific appliances on or off is my part. It would be very strange if the power company would suddenly be in charge on whether my kettle specifically should have power. > The other part of the implementation is fining the companies. I'm sure after a few millions every month they'll stop making SDK's that don't enforce collecting authorisation from the user before tracking. I fully agree on that and we need more of that, but that is irrespective of how the user is asked whether he wants to accept cookies/tracking.

idgi, is it harder for a malicious website to ask you if you accept cross site tracking cookies and then ignore your refusal than it is for them to ignore the same instruction from your browser?

Sebb767 6y ago

No, this is about boundaries, abstractions and context really. When a browser sets a bound, the website usually has no way to override that, as the browser is above it permission-wise. Similarly, if the OS sets a boundary, the browser looses out, since it's below the OS. Fittingly, when you deny crossing such a boundary, you'd expect it to be denied. Imagine, for example, if the dialog to allow push notifications for a website would be an UAC window. It would not make sense since a) the OS would ask for something which is clearly contained within the context of the browser and b) the OS has no reasonable [0] way to know whether a notification sent by the browser is on behalf of the denied/allowed website. Similarly, it makes sense to have the prompt for tracking data in the context of the website, since it is the only context in which it can reasonably [0] handle the response. It does change the difficulty or legality of circumvention, yes, but it is a bit less security theater. At least that's the technical reason. If we're being honest, the discussion never came up, because a) laws are bad for setting technical standards in many ways and b) most site owners prefer to build their own dark patterns to get the user to click accept anyway. [0] Excluding heuristics, of course, which would just start a game of cat and mouse yet again and would necessarily be flawed.

imiric 6y ago
That doesn't change the fact that the current implementation is user hostile. There's no reason that privacy laws couldn't enforce a user setting at the browser level that websites could access in a standard way. Similar to the "Do Not Track" header, but actually enforceable. That would be the user friendly approach, but would require a technical committee of browser vendors, advertisers and tech giants to be part of the design process. Unfortunately the reason this doesn't happen is because the technical team would be working against their own financial interests, so there's no incentive to stop exploiting the user. Which is why the modern web is hostile to the user, and likely won't change unless the business models drastically change.
hnedeotes 6y ago
> Imagine, for example, if the dialog to allow push notifications for a website would be an UAC window. It would not make sense since a) the OS would ask for something which is clearly contained within the context of the browser and b) the OS has no reasonable [0] way to know whether a notification sent by the browser is on behalf of the denied/allowed website. Similarly, it makes sense to have the prompt for tracking data in the context of the website, since it is the only context in which it can reasonably [0] handle the response. It does change the difficulty or legality of circumvention, yes, but it is a bit less security theater. I see these answers and I always get the feeling that they treat existing software (browsers, websites, os) like something that was handed down by God in the book of law. The browser already asks the user for permission through the OS - it does for location, webcam, filesystem, etc - there's no context needed because you're actively engaged with it, the browser or the os system don't need any more context than the user clicked Yes or No for this request. The other part of the implementation is fining the companies. I'm sure after a few millions every month they'll stop making SDK's that don't enforce collecting authorisation from the user before tracking.
- Sebb767 6y ago
  > I see these answers and I always get the feeling that they treat existing software (browsers, websites, os) like something that was handed down by God in the book of law. There's two sides for this. For one, this is the infrastructure that already exists and that is out there in the wild. If you start selling 500V electric appliances, people can of course buy transformers or the state could upgrade its grid, but in reality, changing the existing infrastructure to suddenly support something different is a huge effort. It's far easier and more economical to treat the given infrastructure as fixed and working within its bounds. On the other hand, it usually adds a lot of needless complexity to break layers. Sometimes it is worth it (ZFS might be a good example), but usually it isn't. Imagine, for example, if Firefox needed to be patched to support SSDs or SD cards because it did some magic and accessed the HDD firmware directly - this would arguably be a bad idea. > The browser already asks the user for permission through the OS - it does for location, webcam, filesystem, etc - there's no context needed because you're actively engaged with it, the browser or the os system don't need any more context than the user clicked Yes or No for this request. Sure it does. The OS<->Browser boundary is basically about what the browser executable itself can do to the OS; the OS has no context on the finer granularity of websites. Going back to the electrical grid: My power company is worried about bringing electricity to my flat connection; turning specific appliances on or off is my part. It would be very strange if the power company would suddenly be in charge on whether my kettle specifically should have power. > The other part of the implementation is fining the companies. I'm sure after a few millions every month they'll stop making SDK's that don't enforce collecting authorisation from the user before tracking. I fully agree on that and we need more of that, but that is irrespective of how the user is asked whether he wants to accept cookies/tracking.