Opentelemetry-specification: Proposal: Have insecure mode as default in exporter

[jan25]

Current exporter spec mentions insecure=false as default. This means the users of a exporter SDK have either options:

• Supply certificate files for secure grpc/http connection
• Set insecure=true explicitly and work with insecure connection

This issue is to discuss if we should have insecure=true as default instead.

There are few discussion points in a previous PR(https://github.com/open-telemetry/opentelemetry-specification/pull/975) about using insecure mode in localhost/sidecar setup which makes it easier to work with exporter.

[andrewhsu]

from the issue triage mtg today with TC, setting this for required-for-ga to arrive at a decision by end of day today. if no additional comments, we will keep insecure=false by default. @open-telemetry/technical-committee

[yurishkuro]

I think if we make insecure the default, we will open ourselves to a lot of criticism. Like the wifi routers that in the past used to ship with pwd=password - they stopped doing it these days. If I am not mistaken, gRPC is also secure by default, you have to opt-in for "insecure".

+1 to insecure=false by default (fail closed).

[anuraaga]

Should we change the default endpoint for OTLP from localhost to unspecified? My main argument for insecure = true as default is it matches that default. Very very few people use TLS with localhost even in production I think.

[tigrannajaryan]

Should we change the default endpoint for OTLP from localhost to unspecified? My main argument for insecure = true as default is it matches that default. Very very few people use TLS with localhost even in production I think.

What do we gain by this? Now to send to localhost you need to specify 2 env variables instead of one (endpoint=localhost and insecure=true).

[tigrannajaryan]

In maintainers meeting today there has been a discussion to allow specifying the schema in the endpoint, essentially making it a URL. In that case we could specify "http://localhost:55680" as the default value for OTEL_EXPORTER_OTLP_ENDPOINT and it would enable insecure mode because of "http" schema.

However, there is no standard schema values for grpc (I can't see one in https://en.wikipedia.org/wiki/List_of_URI_schemes) so this will only work for http/https.

Given that the default protocol is "grpc" it will look weird to have the default endpoint schema be something different.

Also unclear is what happens if the protocol is "grpc" but endpoint schema is "http" or "https"? What wins?

Unless someone has good answers to these questions I am inclined to keep the status quo and close this issue.

[jrcamp]

One way to configure grpc and TLS with scheme would be to use something like grpc+tls://localhost. Not sure how standard it is but you see it in the wild with git like git+ssh://... or (from the wiki page linked above) svn[+ssh]://<logindetails>@<repository><:port>/<modulepath>

The insecure option could also be passed: grpc+tls://localhost?insecure=true

[tigrannajaryan]

@jrcamp we would be essentially inventing a scheme for grpc. I think it is beyond Otel scope and if in the future grpc decides to register an official scheme according to rfc3986 we may have a problem because it may not match our invention. I think it is fine for protocol authors to decide (and officially register if desired) their scheme, but we are not the grpc author and I think we should refrain from doing that.

[jmacd]

allow specifying the schema in the endpoint, essentially making it a URL

I _like_ this idea.

inventing a scheme for grpc. I think it is beyond Otel scope

I agree.

Something like otlp://<...> for insecure and otlps://<...> for secure might work, but this was supposed to be decided days ago. This can be improved after GA using a new environment variable for the new scheme, such as OTEL_EXPORTER_OTLP_URL, recommend closing.

[tigrannajaryan]

If I don't hear any new ideas by tomorrow I am going to close the issue. New suggestions for URI/schema based behavior can be proposed in a separate issue.

[tigrannajaryan]

Since I haven't heard new thoughts I am closing this as "won't do".