Add greater flexibility/control for protocol of akamai-hosted files

[#1]

Something that was a potential security concern in DTM is become a breaking defect in Launch. If I have a page that doesn't load on the typical "http" or "https" protocol, I would need to specify a protocol in my embed code, so this:

<script src="//assets.adobedtm.com/9310dd7d04eb33be499693ff5cc9558ffcacdf54/satelliteLib-38d69d073d347 9a9c730481247813276cb9fc3c0-staging.js"></script>

Would become this:

<script src="https://assets.adobedtm.com/9310dd7d04eb33be499693ff5cc9558ffcacdf54/satelliteLib-38d69d07 3d3479a9c730481247813276cb9fc3c0-staging.js"></script>

In DTM there is a potential security flaw with this, where it will load my main file as HTTPS, but any of the other files (like my appMeasurement library) get loaded as HTTP. (You can see this on Testing Launch Utility if you load the page as "http" or download it and run it locally- the main library is secure, but the appMeasurement and mbox files are non-secure ):

In Launch when a file is run locally (or through something like a mobile hybrid app, which is increasingly common), it doesn't even default to "http:" for those side files, it tries to use the protocol of the current page (even if it is "file://")... which leads to 404s. You can see this on Testing Launch Utility(though you may need to download and run the file locally).

As far as I can tell, the only current solution to this would be to self-host anything where you need to not just inherit the protocol of the page.

Can we please add some flexibility/control over this for akamai-hosted adapters?

See also Default to https:// for Launch Embed for Akamai Type Adaptors

[#2]

Thanks jenn.kunz@33Sticks​ - good find and detail. Just tested a site which present this issue.

[#3]

What would you like to see as the solution? Fallback to HTTPS if no protocol is present?  Fallback to HTTPS if file:// is present? Always use HTTPS?

[#4]

FYI, we have a specific property which is never intended to be served over HTTPS for security reasons. It works fine with DTM, but with Launch, it doesn't not properly downgrade to HTTP, which means we cannot transition it cleanly to Launch.

[#5]

Ideally, it would inherit whatever protocol I have on my overall library- so if I leave it "//", they are all that way, whereas if I specify "https://", they'd all be https.... though as a developer I know that's not a simple option.

Alternatively, if I could specify in the Launch interface for my adaptor that I want it to be https, that would be swell.

[#6]

I would vote for always https if it is not configurable in the interface (I know you love when we suggest more settings!). I'd be curious to hear @michaels87915107 's reason of never serving over https for security reasons?

[#7]

Hi philiplawrence​ reasoning is we've dealt with some IT deptartments who won't serve over certain small sites over SSL due to this vuln Heartbleed - Wikipedia

I know it sounds weird, but I've gotten this as direct feedback regarding some active/live properties which don't have any material information disclosure.

[#8]

Yikes! Sorry you're having to deal with that, because that shouldn't be an issue. Heartbleed was an issue 5 years ago... not so much anymore . New SSL certs are cheap (even free!) and take 15min to deploy. Being brutally honest here, this sounds like a lazy excuse from those departments/site owners to not implement a new SSL cert.

[#9]

I know some folks simply don't like that the handshake for https takes a little longer and for page performance reasons, prefer http.

[#10]

philiplawrence I was surprised too, never know what edge cases folks are harboring!

[#11]

BTW, it's awesome seeing all this discussion. This is good stuff, Ben.