4 ms·

I'm going to vote "no." Most security headers exist to enhance site security. This "security header" seems to exist solely to save site operators the trouble o

I'm going to vote "no." Most security headers exist to enhance site security. This "security header" seems to exist solely to save site operators the trouble of having to vet what third party resources do (mostly ads I assume). They seem to want to have their cake and eat it too (i.e. embed toxic content, without vetting it, while also disabling many of the more toxic tricks). Problem with that is that toxic ads pay more BECAUSE they're toxic, that's why you went with that ad network, higher CPM. How about you just do your job as a site owner and employ an ad network with a code of conduct/morals? Not to mention that this won't work, because real sites actually need some of these features.

neotek 8y ago
There's the fantasy reality we wished we lived in, and there's the pragmatic reality we actually live in, and if you only ever act as though you live in the fantasy reality then the pragmatic reality will always leave you disappointed. So unless you know of a way to force site operators to act against their best interests to service yours, I would much rather that we at least have this option available. Also, let's not forget that Google itself has been guilty of letting toxic ads slip through their vetting procedures. It's not as though there's some 100% foolproof way of ensuring that you only ever run ads that are completely benign in every possible sense without doing away with 90% of the things legitimate advertisers demand to have (rich ads, tracking, javascript, etc), so again, unless you've discovered a realistic way for site operators to fund the operation of their sites without having to erect paywalls, the threat of toxic content will always exist.
- Someone1234 8y ago
  > So unless you know of a way to force site operators to act against their best interests to service yours, I would much rather that we at least have this option available. You seem confused about this proposal. This doesn't provide the end user any more options, and isn't meant to. This is a proposal designed to allow site operators to embed dangerous content without vetting that content. Nothing more, nothing less.
dqv 8y ago
I guess I just prefer to take the optimistic approach to things like this :). I see it as another way for the browser to tell me, a site owner, if something got through that wasn't supposed to. My immediate thought was for better defense against an evil script. Yes, the evil script shouldn't have come up in the first place, but that doesn't mean I'm perfect and an evil script will never make it onto my site. Aside from disabling misuse of features, it also uses the Reporting API [0] which means that toxic ads violating the feature policy can be reported to the site owner and then potentially removed. That's what I would do if I were a site owner pushing ads -- check on my side to make sure they aren't doing anything questionable and address it immediately if it is. > How about you just do your job as a site owner and employ an ad network with a code of conduct/morals? How would this prevent a bad actor from making an ad that looks safe but isn't? [0] https://w3c.github.io/reporting/ https://w3c.github.io/reporting/
- move-on-by 8y ago
  Yes, defense in depth. Do your due diligence, vet what you can, and then lock it down where trust isn't even required. Sites get hacked, whether its CDNs, ad networks, or any other trusted 3rd party. A great example would be a website with webcam and audio abilities like a conferencing site. You might have 3rd party tools embedded like newrelic or sentry.io for client-side error detection and performance monitoring. Those scripts should NEVER access the webcam or microphone. But what if one of those sites get hacked? Your users have already approved the webcam and mic access to your site, after all its a conferencing tool. But now the hacked sentry script can also link into the webcam and microphone and send that data wherever they like. The client won't see anything different. They approved the access to their microphone and mic already, they won't see anything different. If you used this new header, you have another layer of defense against the hacked scripts. You can define that only scripts from your domains should have access to the microphone and mic, and the browser will deny access to the 3rd party. Beyond that, it also supports reporting, so you can get notifications that newrelic was trying to access users webcams and can enable your incident response team to begin their work responding to the hacked 3rd party.
  - greggman 8y ago
nothrabannosir 8y ago
But how do you feel about CSP? This seems analogous, and I don’t think CSP is a bad idea. What’s the difference?
nine_k 8y ago
Do you know why do aircraft pilots wear parachutes? So as not to have to use them. These headers can serve the same purpose: to add an extra layer of prevention, just in case. However well you may vet any 3rd-party content embedded on your pages, you cannot prevent a mistake from their side, at the very least. Let alone any outbreak of malicious code, because 3rd-parties' security is also necessarily imperfect. A presence of such a layer additionally disincentivizes attempts to add malicious / treacherous content, because it will just not get through. They say that good security is not like an eggshell, but like an onion.
- jessaustin 8y ago
  If I were getting on a plane and saw the pilot was wearing a parachute, I would get right back off.
  - nine_k 8y ago
    Airliner pilots don't wear parachutes, and can't jump off. Military aircraft personnel, and pilots and passengers of very light civil aircraft (think Cessna), do wear them. </offtopic>
klodolph 8y ago
This strikes me as the same kind of thinking as, "We oppose extramarital sex and therefore we should not teach teenagers about condoms, they should just not have sex in the first place and then they won't catch any STIs." > Not to mention that this won't work, because real sites actually need some of these features. It works like the CSP header already works, so it's origin-based.
solatic 8y ago
> How about you just do your job as a site owner and employ an ad network with a code of conduct/morals? And if the ad network suddenly changes their policy without notifying you, what are you supposed to do? Because you can't proxy the ad network (because then the ad network doesn't know which ads to serve, since they lose info on the origin request) there are two ways to deal with this: either continuously monitor your third party providers for malfeasance, or sandbox them. Isn't a sandbox better?
- Someone1234 8y ago
  > And if the ad network suddenly changes their policy without notifying you, what are you supposed to do? That's a legal question, not a technical one. If another company violates your contract with them, or the contract doesn't require notification for substantial contractual changes then you need to talk to your lawyers.
  - solatic 8y ago
    > That's a legal question, not a technical one. So we should just, what, pass a law that it's illegal to listen to traffic if you're not law enforcement with a warrant, and then we don't have to encrypt any of our traffic anymore? Who needs technical solutions when we have legal ones? (internet-required-explicit-sarcasm-notice)
Ajedi32 8y ago
You're being ridiculous. This is like saying we shouldn't have a permissions system on mobile devices because that's just a way to save lazy users the trouble of having to vet what the app they just installed actually does.
- Someone1234 8y ago
  This isn't proposing user permissions, this is proposing site permissions. A better analogy would be, that app developers are too apathetic to review their own app's permissions, so they want a way to limit what permissions a third party ad library could add to their app. It is a way for people shirking responsibility for their own site, app, or content.
  - Ajedi32 8y ago
    It doesn't matter who the permissions are for, the principle is the same. _Should_ users perform a through investigation of every app they install, checking that it does exactly what they expect and no more? Perhaps; but that's not really practical. The same applies for developers. Should these sites review the source code of every ad they embed in an iframe, whitelisting each ad individually? Maybe, but that's not going to happen. The other commenters are right, what you're suggesting is fantasy, not pragmatic reality. Permissions systems are better, because they prevent misbehavior even when manual review fails.
    - Someone1234 8y ago
      > It doesn't matter who the permissions are for, the principle is the same. It absolutely matters. Users should have minimal responsibility while consuming content. Site owners should have major responsibility while providing content. > Should these sites review the source code of every ad they embed in an iframe, whitelisting each ad individually? They absolutely should know who their ad platform is, what their policies are, and what is/isn't acceptable for an ad hosted by that platform. If their ad platform falls short, they should shop around for a better alternative.
emilfihlman 8y ago
What you are saying is extremely stupid. It's akin to advocating _not_ doing security, because of course you trust your provider, because they are cute and all with that -io ending name, right! Just because you currently trust someone doesn't mean they might not become compromised later. With this security feature, you can prevent that leak from ever happening.
- dang 8y ago
  Please follow the HN guideline that asks you not to name-call in arguments. Your comment would be fine without the first sentence. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
xenomachina 8y ago
There are uses for this besides ads. When I worked on Google Reader, something like this would have been incredibly useful. At the time, the only truly safe way to handle embed/object/iframe in post content was to completely filter it out. That's pretty terrible for usability, though. We ended up having a exceptions in our HTML sanitizer embeds of content from certain sites (eg: elves of popular video sites like YouTube and Vimeo were allowed). I always hated that solution because it made us vulnerable to any site in the whitelist (whether because they become malicious, or because they themselves have a vulnerability), it was unfair to smaller/newer sites, and it was a additional maintenance burden.

neotek 8y ago

There's the fantasy reality we wished we lived in, and there's the pragmatic reality we actually live in, and if you only ever act as though you live in the fantasy reality then the pragmatic reality will always leave you disappointed. So unless you know of a way to force site operators to act against their best interests to service yours, I would much rather that we at least have this option available. Also, let's not forget that Google itself has been guilty of letting toxic ads slip through their vetting procedures. It's not as though there's some 100% foolproof way of ensuring that you only ever run ads that are completely benign in every possible sense without doing away with 90% of the things legitimate advertisers demand to have (rich ads, tracking, javascript, etc), so again, unless you've discovered a realistic way for site operators to fund the operation of their sites without having to erect paywalls, the threat of toxic content will always exist.

Someone1234 8y ago
> So unless you know of a way to force site operators to act against their best interests to service yours, I would much rather that we at least have this option available. You seem confused about this proposal. This doesn't provide the end user any more options, and isn't meant to. This is a proposal designed to allow site operators to embed dangerous content without vetting that content. Nothing more, nothing less.

dqv 8y ago

I guess I just prefer to take the optimistic approach to things like this :). I see it as another way for the browser to tell me, a site owner, if something got through that wasn't supposed to. My immediate thought was for better defense against an evil script. Yes, the evil script shouldn't have come up in the first place, but that doesn't mean I'm perfect and an evil script will never make it onto my site. Aside from disabling misuse of features, it also uses the Reporting API [0] which means that toxic ads violating the feature policy can be reported to the site owner and then potentially removed. That's what I would do if I were a site owner pushing ads -- check on my side to make sure they aren't doing anything questionable and address it immediately if it is. > How about you just do your job as a site owner and employ an ad network with a code of conduct/morals? How would this prevent a bad actor from making an ad that looks safe but isn't? [0] https://w3c.github.io/reporting/ https://w3c.github.io/reporting/

move-on-by 8y ago
Yes, defense in depth. Do your due diligence, vet what you can, and then lock it down where trust isn't even required. Sites get hacked, whether its CDNs, ad networks, or any other trusted 3rd party. A great example would be a website with webcam and audio abilities like a conferencing site. You might have 3rd party tools embedded like newrelic or sentry.io for client-side error detection and performance monitoring. Those scripts should NEVER access the webcam or microphone. But what if one of those sites get hacked? Your users have already approved the webcam and mic access to your site, after all its a conferencing tool. But now the hacked sentry script can also link into the webcam and microphone and send that data wherever they like. The client won't see anything different. They approved the access to their microphone and mic already, they won't see anything different. If you used this new header, you have another layer of defense against the hacked scripts. You can define that only scripts from your domains should have access to the microphone and mic, and the browser will deny access to the 3rd party. Beyond that, it also supports reporting, so you can get notifications that newrelic was trying to access users webcams and can enable your incident response team to begin their work responding to the hacked 3rd party.
- greggman 8y ago

nothrabannosir 8y ago

But how do you feel about CSP? This seems analogous, and I don’t think CSP is a bad idea. What’s the difference?

nine_k 8y ago

Do you know why do aircraft pilots wear parachutes? So as not to have to use them. These headers can serve the same purpose: to add an extra layer of prevention, just in case. However well you may vet any 3rd-party content embedded on your pages, you cannot prevent a mistake from their side, at the very least. Let alone any outbreak of malicious code, because 3rd-parties' security is also necessarily imperfect. A presence of such a layer additionally disincentivizes attempts to add malicious / treacherous content, because it will just not get through. They say that good security is not like an eggshell, but like an onion.

jessaustin 8y ago
If I were getting on a plane and saw the pilot was wearing a parachute, I would get right back off.
- nine_k 8y ago
  Airliner pilots don't wear parachutes, and can't jump off. Military aircraft personnel, and pilots and passengers of very light civil aircraft (think Cessna), do wear them. </offtopic>

klodolph 8y ago

This strikes me as the same kind of thinking as, "We oppose extramarital sex and therefore we should not teach teenagers about condoms, they should just not have sex in the first place and then they won't catch any STIs." > Not to mention that this won't work, because real sites actually need some of these features. It works like the CSP header already works, so it's origin-based.

solatic 8y ago

> How about you just do your job as a site owner and employ an ad network with a code of conduct/morals? And if the ad network suddenly changes their policy without notifying you, what are you supposed to do? Because you can't proxy the ad network (because then the ad network doesn't know which ads to serve, since they lose info on the origin request) there are two ways to deal with this: either continuously monitor your third party providers for malfeasance, or sandbox them. Isn't a sandbox better?

Someone1234 8y ago
> And if the ad network suddenly changes their policy without notifying you, what are you supposed to do? That's a legal question, not a technical one. If another company violates your contract with them, or the contract doesn't require notification for substantial contractual changes then you need to talk to your lawyers.
- solatic 8y ago
  > That's a legal question, not a technical one. So we should just, what, pass a law that it's illegal to listen to traffic if you're not law enforcement with a warrant, and then we don't have to encrypt any of our traffic anymore? Who needs technical solutions when we have legal ones? (internet-required-explicit-sarcasm-notice)

Ajedi32 8y ago

You're being ridiculous. This is like saying we shouldn't have a permissions system on mobile devices because that's just a way to save lazy users the trouble of having to vet what the app they just installed actually does.

Someone1234 8y ago
This isn't proposing user permissions, this is proposing site permissions. A better analogy would be, that app developers are too apathetic to review their own app's permissions, so they want a way to limit what permissions a third party ad library could add to their app. It is a way for people shirking responsibility for their own site, app, or content.
- Ajedi32 8y ago
  It doesn't matter who the permissions are for, the principle is the same. _Should_ users perform a through investigation of every app they install, checking that it does exactly what they expect and no more? Perhaps; but that's not really practical. The same applies for developers. Should these sites review the source code of every ad they embed in an iframe, whitelisting each ad individually? Maybe, but that's not going to happen. The other commenters are right, what you're suggesting is fantasy, not pragmatic reality. Permissions systems are better, because they prevent misbehavior even when manual review fails.
  - Someone1234 8y ago
    > It doesn't matter who the permissions are for, the principle is the same. It absolutely matters. Users should have minimal responsibility while consuming content. Site owners should have major responsibility while providing content. > Should these sites review the source code of every ad they embed in an iframe, whitelisting each ad individually? They absolutely should know who their ad platform is, what their policies are, and what is/isn't acceptable for an ad hosted by that platform. If their ad platform falls short, they should shop around for a better alternative.

emilfihlman 8y ago

What you are saying is extremely stupid. It's akin to advocating _not_ doing security, because of course you trust your provider, because they are cute and all with that -io ending name, right! Just because you currently trust someone doesn't mean they might not become compromised later. With this security feature, you can prevent that leak from ever happening.

dang 8y ago
Please follow the HN guideline that asks you not to name-call in arguments. Your comment would be fine without the first sentence. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

xenomachina 8y ago

There are uses for this besides ads. When I worked on Google Reader, something like this would have been incredibly useful. At the time, the only truly safe way to handle embed/object/iframe in post content was to completely filter it out. That's pretty terrible for usability, though. We ended up having a exceptions in our HTML sanitizer embeds of content from certain sites (eg: elves of popular video sites like YouTube and Vimeo were allowed). I always hated that solution because it made us vulnerable to any site in the whitelist (whether because they become malicious, or because they themselves have a vulnerability), it was unfair to smaller/newer sites, and it was a additional maintenance burden.