drjbutler
commented
9 years ago We haven't seen anyone really pushing SSL in RTB besides Google. That said, I wouldn't object to simply removing the non-SSL recommendation and let the spec focus on content rather than infrastructure.
:JB
On Fri, May 8, 2015 at 12:40 PM, Osvaldo Pinali Doederlein < notifications@github.com> wrote:
The OpenRTB spec still "recommends" against use of HTTPS (2.2 Security). DoubleClick Ad Exchange is moving fast to requiring HTTPS for all RTB, I guess other exchanges should also be working on that, and this part of the spec is feeling obsolete. If and when we move to support OpenRTB natively, this will have to be HTTPS-only. The part "These are server-to-server calls, which can be protected in other ways" doesn't look very good anymore, now with more people deploying bidders on public cloud platforms.
Can we change this in the next release? Suggestion for something simple:
- TLS (Transport Layer Security) is not required for compliance, but recommended for RTB traffic that's routed through the public internet (i.e, bidders not hosted inside the exchange's network, or equivalent arrangement).
I feel that the spec could go a little further, in particular recommending to take advantage of improvements in HTTP 2.0 which makes TLS more secure and lower overhead. Not my area of expertise, I don't know if it's too early to expect everybody's serving platforms to already implement HTTP2 well, etc., just a suggestion.
Additionally, the DoubleClick protocol always had some fields that are encrypted because they carry sensitive information. The OpenRTB doesn't have any encrypted field; it has some hashed fields, e.g. for device IDs, and while these are useful, they are not as good as an encrypted ADID that can be fully decrypted by the bidder. Using encryption at the transport level would allow the protocol to carry sensitive fields without the complication of encrypting individual fields.
— Reply to this email directly or view it on GitHub https://github.com/openrtb/OpenRTB/issues/17.
James M. Butler, Ph.D.* | SVP Technology *millennial media Mobile: 617.834.2125 Email: jbutler@millennialmedia.com Web: www.millennialmedia.com Twitter: @millennialmedia Facebook: Facebook/millennialmedia
darobin
lpgauth
manigandham
opinali
samtingleff
The OpenRTB spec still "recommends" against use of HTTPS (2.2 Security). DoubleClick Ad Exchange is moving fast to requiring HTTPS for all RTB, I guess other exchanges should also be working on that, and this part of the spec is feeling obsolete. If and when we move to support OpenRTB natively, this will have to be HTTPS-only. The part "These are server-to-server calls, which can be protected in other ways" doesn't look very good anymore, now with more people deploying bidders on public cloud platforms.
Can we change this in the next release? Suggestion for something simple:
I feel that the spec could go a little further, in particular recommending to take advantage of improvements in HTTP 2.0 which makes TLS more secure and lower overhead. Not my area of expertise, I don't know if it's too early to expect everybody's serving platforms to already implement HTTP2 well, etc., just a suggestion.
Additionally, the DoubleClick protocol always had some fields that are encrypted because they carry sensitive information. The OpenRTB doesn't have any encrypted field; it has some hashed fields, e.g. for device IDs, and while these are useful, they are not as good as an encrypted ADID that can be fully decrypted by the bidder. Using encryption at the transport level would allow the protocol to carry sensitive fields without the complication of encrypting individual fields.