“May” be that my translations in the web browser are being transferred to the internet service provider's surveillance database

[universish]

The security of our data is very important due to the fascist, religious, radical, repressive, dictatorial imaginary regime-government in an imaginary country. As an oppositionist, we need to be very careful with this. My translations made with DeepL in the browser appear as URLs. In the HTTPS encryption system, URLs are not hidden, and the internet service provider can see these URLs. Deepl translates translations by showing them as URLs. For example: https://www.deepl.com/en/translator#tr/en-us/%C3%BClkedeki%20fa%C5%9Fist%20dinci%20radikal%20bask%C4%B1c%C4%B1%20diktac%C4%B1%20rejim%20sebebiyle%20verilerimizin%20g%C3%BCvenli%C4%9Fi%20%C3%A7ok%20%C3%B6nemli. There are two fictitious internet infrastructure companies in the country. One is Ticktelecomi and the other is Tickcello.
both are in the hands of the regime and the government. Ticktelecomi, the largest internet service provider company in this country, which is the dream of Ticktelecomi, is also the infrastructure company. In addition, there is a fictitious "tick information technology unit" in the country that makes plugging with citizens' data. There's a fictitious company called TickCello that owns a giant data storage building that's also a fictitious data center. Let's assume that this company is transferring data to the information technology unit that ticks. In other words, all dissidents in this imaginary country are monitored, data recorded, reported, plugged and followed.
A frequently used platform such as DeepL also inadvertently learns to the service provider what this opponent is translating, and to whom he is doing this translation to send e-mails about what. Please make your translation system independent of the HTTPS URL. This is a vulnerability for everyone. Not only for the dissident citizens of this imaginary country.

[JanEbbing]

Hi, thanks for your report and sorry to hear that. These repos are unfortunately for our API and client libraries, not for deepl.com. However, you can translate via the API without the query parameters (by sending the translation text as a body parameter), which should cover your texts with the HTTPS encryption. I will forward the feedback about the web issue to the team responsible for that and close here.

[JanEbbing]

Edit: Sorry this answer is wrong - I thought URL parameters are included in the URL, but they are not. Please see Daniel Jones' answer below - your ISP can not see any text you send to DeepL, free or pro, API or Web or Apps.

Hi, just to follow up here - this behaviour exists on DeepL free to facilitate sharing translations with friends etc. If you require privacy guarantees, we recommend DeepL Pro, where the text will not appear in the URL and is thus covered by TLS encryption. Alternatively you can use the API as i outlined before.

[daniel-jones-dev]

Hi I wanted to extend this answer @universish,

DeepL does take data security very seriously. First of all, it is only possible to use deepl.com over SSL, which already offers great data protection of requests sent to the server. AFAIK, snooping an SSL connection will only allow an attacker to see you're connecting to www.deepl.com (via the IP address), not the query path en/translator nor the query parameter (usually follows a ?, but isn't used in this case).

Furthermore, I note that the text is included in the anchor part of the URL (after the #). From Mozilla docs:

It is worth noting that the part after the #, also known as the fragment identifier, is never sent to the server with the request.

You can inspect the requests made to DeepL by your browser yourself when you use a link like your one above. AFAIK, only the https://www2.deepl.com/jsonrpc?method=LMT_split_text and https://www2.deepl.com/jsonrpc?method=LMT_handle_jobs requests contain the text for translation, and always in the request body.

I hope that assuages your concerns.

[universish]

Thank you for your answer. My question was not about requests to deepl servers. It's about requests passing through the servers of the internet service provider. I wonder if the internet service provider also sees the part after the “#” sign? Does it see the part after the “?” sign?

[JanEbbing]

No, this is where I was wrong before. (as an aside, requests to DeepL servers are the requests passing through your ISP's routers and switches) TCP packets expose the IP* address of the server you are connecting to, but not any request parameters.

See for example Wikipedia:

Because HTTPS piggybacks HTTP entirely on top of TLS, the entirety of the underlying HTTP protocol can be encrypted. This includes the request's URL, query parameters, headers, and cookies (which often contain identifying information about the user). However, because website addresses and port numbers are necessarily part of the underlying TCP/IP protocols, HTTPS cannot protect their disclosure. In practice this means that even on a correctly configured web server, eavesdroppers can infer the IP address and port number of the web server, and sometimes even the domain name (e.g. www.example.org, but not the rest of the URL) that a user is communicating with, along with the amount of data transferred and the duration of the communication, though not the content of the communication

[universish]

links not working: https://www2.deepl.com/jsonrpc?method=LMT_split_text and https://www2.deepl.com/jsonrpc?method=LMT_handle_jobs

[JanEbbing]

Sorry I don't understand your question. These are internal (JSON-RPC) requests made by our frontend, not websites, you can't open them in your browser.

If you want to verify what your ISP can see, you can use a tool like wireshark to sniff what packets are sent to your router.

[universish]

thanks.