How Telegram Messenger circumvents Google Translate's API
danpetrov.xyz
danpetrov.xyz
I’d love to see and give money to a project to create and maintain easy to use and stable “adversarial interoperability” APIs for as many services and products as possible.
Perhaps companies and projects would not often use these directly because of the risks (hopefully some would, though!) but individuals could drop the library or the URL to a server hosting it into their apps to gain extra features.
If standardised, whole open source apps could be built around them that allow querying and analysis of data from services and aggregating and automating using the services including optimising prices, taking advantage of offers, and using undocumented APIs to the users advantage.
Maybe something architected and incentivised like https://thegraph.com/ for adversarial intercom and undocumented APIs. Building as a network of nodes and funding with crypto would make it harder to attack and take down.
[0] https://www.eff.org/deeplinks/2019/10/adversarial-interopera...
"pip3 install woob" succeeds but e.g. "woob config-qt" returns "not a woob command". Are the -qt versions not available via pip? I have python3-pyqt5 installed.
pip install woob-qt
If you provide a solution to someone’s problem, it will be used all over the place.
The biggest companies won’t use these things, but plenty of smaller companies and individual programmers without oversight would use them without a second thought, at least until they’re caught.
Telegram is a relatively large business and here they are abusing an API exactly like you suggest.
Along those lines: maybe we could use a middleware pattern for APIs, frameworks, etc where the interface/package would be built as a layer above two or more services.
That way the developer could switch between them at any time, or even failover automatically.
So for example, rather than going onto GitHub to download an SDK for something like Mailgun, you'd download a middleware framework built on Mailgun and Sendgrid.
This pattern could be used to identify vulnerabilities in software at the conceptual level, by helping developers to avoid marrying their code to individual providers like AWS. Some mission critical software could even be certified as using all adversarial interoperability frameworks.
It could even help third party services pull themselves up by their bootstraps, if they get added to one of these middlewares. An instant user base without having to rely on marketing or word of mouth.
And could be used to identify monopolies when there's no middleware for a service.
> Too many moving pieces. Too much work.
It still boggles my mind that this is the way we do things. "Patch fast!" Ok cool. That's going to keep working out forever.
I would love to have applications that are more tools than products and weave together these APIs and middlewares, both in querying and visualising, combining, enriching, analysing, filtering etc. data and also taking the output and actioning it.
With the amount of data and services that are now available online we should have superhuman capabilities but the productisation of the internet has left us stuck in company run silos fighting “user journeys”, undocumented APIs and EULAs.
teller.io does similar for banks.
I would love to see a coordinated effort along the same lines for things with non public APIs. It is however a huge ask as internal APIs are unstable and constantly changing/actively working against things like this which is a huge amount of work to keep up with.
That was me. The comment was rapidly amassing upvotes, which made me feel that not only was the comment preaching to the choir but it had the potential to derail the discussion around the actual issue of Telegram's use of Google's Translate APIs.
They are bound to get in trouble with Google for this, but they can’t easily pull the feature. They can’t just be like „oh you’ve had translate for two weeks now, but now we can’t pay for it, so it’s gone.“
What is the long term thinking behind this? Or is this just developers and management not communicating?
…but with more elegant phrasing.
blah blah blah on 31st of February 1970 Google unanimously decided to terminate our access to their Translate API blah blah blah blah
They can't even plausibly pretend that they didn't know and it's all a big misunderstanding given the lengths they went to obfuscate it in the code.
Then some developers facing a deadline cobbled together something that “just made it happen” so they could kick the can down the road with something that worked, ideally long enough to collect their bonuses and find a new job so it becomes someone else’s problem.
Or maybe Telegram the company just likes to abuse other people’s things and see how long they can get away with bad behavior. Who knows.
From first look, I don't think they are. Telegram gets a new feature, Google gets more data to mine. It's a win-win. I just hope they'll be clear with their users about sending data to Google.
If they don't want to pay, they should be using a free open source alternative like https://github.com/LibreTranslate/LibreTranslate
I'd recommend pizza and beer at tech events instead (albeit the nutritional content of your diet could be more important than free food).
Even if they would have TOS for translate, pretty sure that’s unenforceable. Not unless hiding that page behind a paywall, or requiring a google account. Merely visiting a publicly available web page doesn’t create contractual relationship between end user and web server owner.
Even if they are, I have doubts that’s enforceable either. One doesn’t need to reverse engineer an API to consume that API, and it’s hard to find out who did the reverse engineering. The reverse engineering might be accomplished by someone else who’s not a Google’s Cloud customer, like an unrelated person answering a question on stackoverflow.com.
Yet tiny European languages like Latvian are supported, as are very difficult translation targets such as Estonian and Hungarian.
My hopes are dashed every time they add another tiny European language and Turkish remains off the table. :-(
> do you have some metrics you can share?
Not really. Try to have discussions using DeepL and Google Translate. Ask native speakers which one was more accurate and whatnot.
I do not know French, but DeepL allowed me to speak to someone using the language, and apparently at some point some people thought I was a native speaker!
Commercial use of those APIs is common, despite translate being pretty expensive. Also, GCP current leadership is so hell bent on nickel-and-diming their customers, and their compensation packages are so dependent on value share growth, that they simply can't afford anyone openly violating their pricing models. Especially a popular app. My guess is this will be down within the first week of January.
That's likely also why Telegram doesn't proxy every translation request over their server: so that it is users individually requesting small number of translations, from their phone, getting around quota of free APIs "naturally".
[0] https://dcurt.is/apple-card-can-disable-your-icloud-account
I mean why even bother obfuscating the URL otherwise, surely the expected that it could be caught in the review process.
A cease-and-desist letter from Google legal tends to work pretty well as a technique in these cases.
Google's only real option here is to either engage in cat & mouse trying to block this usage or threaten a Play Store removal which comes with its own drawbacks (Telegram has significant marketshare).
While the legal aspects of this might have to be decided by someone more skilled than me I feel they are morally on the same ground as early Google and if Google makes a big case of it it might backfire spectacularly.
More interesting is it that Telegram sends user texts directly to Google without any proxying (did I get that right and has the author studied it carefully enough?).
This might (again, if this blog post is correct and I read kt correctly) be an actual dangerous move from Telegram. Unlike the problems that many here worry about regarding E2E-encryption, this can potentially drag Telegram down to WhatsApp levels, sending huge amounts of user data straight into Google.
Then of course, we'll need to see. Very much of what Telegram has done security wise is very well thought out and has improved over time.
Recently for example when I started my backup of one of the groups I participate in I had to confirm from a mobile client or wait 24 hours to start backup. Account recovery is almost automagically simple but has some nifty touches to prevent account hijacking. Settings to delete the account if I fail to log in has existed for years, I wonder if they even did this before Google launched it.
So now I am anxious to know if Telegram has done something brilliant again or if this is a turning point.
Most likely, since the user-agent rotation code is in the app itself. If it were a Telegram proxy, the proxy would do its own UA and IP hopping and the clients would use their default UAs.
At a certain point, I wonder why Google's abuse team don't simply look for 3+ occurrences of User Agent strings because UA rotation is rarely used for legitimate purposes.
It’s not uncommon for hundreds of users to share a single public IPv4 IP address through an ISP-provided NAT. The same applies to corporate LANs with a single uplink channel.
These users gonna have random UA corresponding to market share of web browsers and operating systems, all coming to the same web server from a single IP address.
0: https://github.com/DrKLO/Telegram/blob/c1c2ebaf4690fd91c116d...
Anyway, regardless of that it sounds like it would be easily defeated with the following C format string:
"%s-%s: %s/%s (%s) %s/%s %s/%s"
with argument list:
"User", "Agent", "Mozilla", "5.0", "X11; Ubuntu; Linux x86_64", "Gecko", "2010000", "Firefox", "90.0"
For bonus points you can make those floating points, too, and split it up a bit further. Now nobody can scan for this without a lot of false positives (The strings are going to display in anything that embeds a web browser or references it, lol) and you get ultimate flexibility.
They cannot even fix the old verbatim feature that they broke a few years ago, so how should should they be able to stop this without breaking something else?
Yep, this is somewhat hyperbolic but I'll write it anyway. I want my old Google back.
To be precise: I think it work sometimes, but I know it doesn't work most of the time unless verbatim means something completely different from what I think ;-)
You can verify this quickly by searching for something slight unusual or very specific, apply verbatim and verify that most of the results still doesn't contain your words.
The big reason for this is that Telegram decided to roll everything mostly on their own (including e.g. MTProto), Telegram is not compatible with Matrix unless you use a bridge, it is not e2e encrypted (unless you use mobile 1-to-1 secret chats. The server side code is proprietary, and the builds of the clients that are published to the app stores could be anything.
While I love using Telegram right now for talking to some groups of friends, I would look at supporting https://matrix.org , since it will likely become the de-facto standard of building messaging platforms.
Telegram the company, maybe not.
On the Telegram security side of things my group of friends uses it as a more modern IRC. So no NSA proof security is truly even expected. We even bridge some IRC channels to Telegram with bots.
Whatever ends up winning is going to need:
- Native clients on all major platforms
- Full support for all the fun little extra's like emoji's, reactions, gifs, file transfers etc.
- True multi-device support that doesn't require any sort of forwarding from another device
- Group chats
- Searchable history
- Your full history to automatically load when you log in on a new device (manually transferring isn't going to be an acceptable solution)
- No concept of selecting a server or anything. Users need to be able to just log in with a username/password and carry on.
- E2E encryption that doesn't sacrifice the user experience
It's a 100% must have feature for a phone IM, most people will forget a password the very moment they are forced to create it.
- There are technically native clients on every platform, so best kind of correct? However, the "official/main/most popular" client is Electron on Desktop. Partial credit?
- Yup
- Yup, even when using E2E, which is a hell of an accomplishment. You transfer keys from other devices, but not entire messages.
- Yup. E2E or not, your choice.
- Searchable history plus E2E is... hard, to say the least. Some clients will index your conversations while they happen, but that's obviously not the perfect solution. That said, the APIs are so open that I've written python scripts before that download and search entire rooms. It would be possible for a client to do the same, though I don't think any do. Non-encrypted rooms are trivial to search, or course.
- This as well. As before, keys transfer from other devices, messages load from the server.
- This seems like it was engineered to exclude Matrix. The default in every client is matrix.org, and there's no reason you ever need to change it if you're not concerned with it. In fact, most clients make it a couple clicks to change it (https://app.element.io/#/login).
- Not totally sure this is possible, but Matrix comes very close. On par with Signal, though with different tradeoffs (stored history, for example).
- No custom emojis; every chat application known to man has regular emojis supported in UTF-8, so the author must be talking about custom ones. Which Matrix still does not have: https://github.com/matrix-org/matrix-doc/pull/1951
- I don't think doing what PGP does is really impressive, but okay, fine, one point.
- Matrix group chats are broken and this is why Synapse eats resources like a bear.
- No searchable history on all but one Electron client on one platform when using E2E is terrible, and further supports the argument that all clients suck.
- Point; this is pretty convenient.
- XMPP sucks. Matrix is modern XMPP. People don't like getting confused with servers and similar nonsense, and when your homeserver goes down, you're out of luck. Federation sucks. The question wasn't made to exclude Matrix, it was made to point out that federation sucks. Matrix didn't invent federation; it chose it long after it failed.
- E2E degrades experience greatly. To list my two biggest complaints: It ruins search for all but one client, and the UX around keys is terrible. I frequently have conversations with incredibly technical people and they'll still get absolutely stumped by the UX around keys, because it's awful.
Two out of eight isn't bad.
I use Matrix every day. I have for years; long before the recent rebrand, and multiple presidents have vacated office since I started using Matrix. I love Matrix. But there's no reason to act like it's some golden goose when there are problems from 2015 that are no closer to being fixed than they were at the time. It's a comfortable protocol for usage by people who have powerful computers. For everyone else, it still isn't great.
it's more than PGP, it includes variable PFS, automatic key exchanges
> - Matrix group chats are broken and this is why Synapse eats resources like a bear.
I have heard it's because Synapse is a proof of concept that went into production
> Federation sucks. The question wasn't made to exclude Matrix, it was made to point out that federation sucks. Matrix didn't invent federation; it chose it long after it failed.
I disagree. Federation is a burden, but it enables interoperability between independent parties.
> But there's no reason to act like it's some golden goose when there are problems from 2015 that are no closer to being fixed than they were at the time.
There's also no reason to do the same thing into the other direction.
> No concept of selecting a server or anything.
This has been one of the big concepts that has bugged me with Matrix. It also is why I'm confused with why people pit Matrix vs Signal. Honestly I see Signal/WhatsApp/iMessage/WeChat as competitors whereas Matrix/Slack/Teams/IRC is a different ecosystem. But I can't get my parents or grandma to use something like Matrix (or even Slack) but they are able to use things in the former category. In fact, this has been one of the great successes of WhatsApp (looking at India with all the aunties and uncles using WA or China with WeChat).
> Anything missing from this list?
- Pinned messaging
- Other class of extras/plugins: on-device translation, calendar reminders, etc
Pinning messages is important for search, but seems to be overlooked frequently (I use this a lot in slack). I often know something is important and need to find it again in a day or two (e.g. traveling) but will also be talking with the other person and that message gets pushed. Pinning lightens the load of searching. It also lightens the load of backups as most people truly want a very small subset of their messages saved but are only aware of an all or nothing approach.
Plugins will be important as well. To complement pinning calendar reminders are great. Google does stuff like this frequently like when you get an email about a flight and then your phone's home screen will have all the information on it. It's also naive to think that you can think of all the things people would want. That's why smartphones have been so successful, because they provide the ecosystem. This isn't too dissimilar from creating a super app. But there's none where the ecosystem is fully secure.
I can't get why people need to put Matrix in either Box. It's a communication protocol. Client UX is completely independent, like you can have K9Mail and Thunderbird
Most people don't actually need full history in most situations, just recent history.
I personally search my deep history regularly. I might be looking for a recipe, link, someones contact information, an address... There are many reasons having the full history available is important, and "losing" it by getting a new device is a terrible user experience.
Isn't Telegram one of very few that provides verifiable builds, (including on iOS if you root it)?
I might be wrong but I think not.
Edit, see : https://core.telegram.org/reproducible-builds
So it seems even on this point Telegram shines.
WhatsApp doesn't post source code at all.
This is not my understanding of the situation at all. There's no end-to-end encryption by default [0], and the end-to-end encryption they do have received significant controversy at launch [1] for being essentially a "roll your own" crypto solution which indeed ended up being found to have some issues [2].
They disable the OS backup and instead they effectively store all their user's contacts, messages, media, etc. directly on their servers except for the conversations that the users directly opt out of by turning on e2e. They've promised since 2014 to open source everything but the backend, which stores all this data, is still closed source.
For small group or individual messaging, whatsapp, signal, or matrix are far better choices. I think it's worth acknowledging that telegram has a much bigger focus on large groups and therefore has to make different security tradeoffs, so I think if we consider telegram a social media service it's pretty good -- but is not the best messenger.
[0]: https://www.howtogeek.com/710344/psa-telegram-chats-arent-en... [1]: https://www.vice.com/en/article/wnx8nq/why-you-dont-roll-you... [2]: https://eprint.iacr.org/2015/1177.pdf
Strong disagree. I would rather have multiple solutions in production, and Telegram's is also well-studied.
> But ultimately they prove that the four key issues “could be done better, more securely and in a more trustworthy manner with a standard approach to cryptography,” said ETH Zurich Professor Kenny Paterson, who was part of the team that uncovered the flaw.
https://www.cyberscoop.com/telegram-app-security-encryption/
We are better off that Telegram exists as an alternative. We don't need Signal's protocol (also used in Whatsapp etc) to be a potential SPOF.
To quote: The central result of this work is a proof that the use of symmetric encryption in Telegram’s MTProto 2.0 can achieve the security of a robust bidirectional channel if small modifications are made.
A couple of things:
1. the crypto has been improved significantly after the launch as far as I know. That release was back in the dark ages about half a year after WhatsApp got caught sending data unencrypted (and I'm using that word in its original meaning).
2. Can we agree to stop recommending WhatsApp soon?
I shared some notes on crypto issues more recently in another post above, but I would concede its generally more battle tested than the first version released at this point. The choice to start with home rolled crypto at all continues to concern me, but more importantly the fact that it's not default is now my biggest sticking point if I'm honest.
I think WhatsApp comes with an asterisk in that I'd certainly recommend signal over it, but most non-technical people have never heard of signal so given the choice between WhatsApp and Telegram I'd personally opt for WhatsApp based on their e2e encryption by default, but I could understand if someone personally gave more weight to a distrust of Meta (even if encrypted) than they do to Telegram and made use of Telegram's secret chats.
The whatsapp that leaks your data to the FBI in real time [1], or do you mean some other whatsapp?
These comments on whatsapp, which appear with regularity by the way, are misleading and just inflammatory.
Have you seen the source code to claim there are no backdoors? Wait, you haven't because it's a proprietary piece of crap produced by the worst corp in existence - Facebook aka Meta. The same entity that's shamelessly involved into Putin's Russia level political censorship and yet we are to trust it according to the parent comment. Right...
Excerpt from the FBI report:
> Pen Register: Sent every 15 minutes, provides source and destination of every message. [without a warrant of any kind]
(And who knows what other three letter agencies can get.)
BuT ThAt'S jUsT mEtAdAta, wE hAvE nOtHinG tO hIdE. Then keep using it, but don't spread your bullshit to others.
This is technically incorrect. They use well known cryptografic algorithms for encryption and authentication. However, their protocol is unique combination of these cryptografic algorithms to provide specific purpose. It is different thing and different perspective than ”normal” use case for saying ”don’t roll your own crypto.”
To be specific with what I mean, it is "roll your own" in the sense that 1) their protocol combines cryptographic primitives in unrecommended ways with no particular justification and in the sense that 2) they literally have invented and written many of these primitives themselves.
As a concrete example, the IGE mode used by Telegram for AES is not "well known", in fact to the best of my knowledge Telegram is the only popular software in existence that uses this mode. IGE is avoided by all modern cryptographers because the authentication is broken, however Telegram uses this mode but not the authentication. There's no particular justification for this decision over just using an AES mode that everyone uses, but there's a lot of potential pitfalls if not done carefully.
When you ask what type of authenticated encryption scheme Telegram uses, their answer is "none of them". Normally this would be a huge problem. However, they have solved this with their own custom "security checks". These are also not "well known" because Telegram invented them.
When you ask what type of PKCS they use for padding, the answer is "we came up with our own padding algorithm". This was not "well known" because Telegram invented it. The padding issue they fixed in v2, since it turned out to introduce a vulnerability, but I assume you get what I mean by this point.
Contrast this with Signal, which is also ultimately a unique protocol but is one that was implemented using robust, tested primitives in recommended combinations with boring standard choices for all of the details.
Though I'm certainly not a cryptography expert, I used to work on Tails OS and some Tor-related projects, and I feel I know where/how to listen to the experts.
Having said that, I am a hard disagree on the quoted statement.
My understanding is that there has been very few improvements that they weren't dragged into. imho telegram is a reckless tool from a cryptographic point of view, and still highly suspect
Again, I cannot speak about the crypto but I can speak about
- bugs: last time Telegram had a know bug where data could realistically leak except inside Telegrams infrastructure (which of course is a big deal) was around the time it launched as far as I know. Looking at Signal (which I recommend for anything super secret) they've had a couple of really nasty bugs in the much shorter life time: RCE in desktop client and spuriously sending images to persons except the intended recipient is just two.
- things they haven't been dragged into: anti-hijacking, deletion on account inactivity, working backup, not syncing secret chats between clients and more.
On the other hand, I find it hard to believe that Telegram would risk a Play Store ToS violation, given how many tens of millions of users use the app.
Meanwhile, indie developers with smaller user base are subject to unappealable automated decisions.
How does that make this okay? Nobody is entitled to get a company’s services for free just because you think their price is too high or their front ends aren’t built to your liking.
Google specifically does not publish their API for free consumption by other companies, yet that’s what’s happening here anyway. The company is also using specific tricks to circumvent detection of the behavior.
In your analogy, this would be like a crawler ignoring robots.txt and then scraping the content for their own website with zero attribution to the source, which is nothing like Google indexing your site with full attribution and driving traffic to it for you.
Regardless, “turnabout is fair play” is unequivocally not a legally or even ethically acceptable standard, so that argument wouldn’t actually hold up anywhere anyway.
I did mention rich snippets.
Google ignores the noindex directive in robots.txt now. You're supposed to put it in your HTTP response headers or HTML meta tags...
https://developers.google.com/search/blog/2019/07/a-note-on-...
> worst case you could just self host a translation service
And worst case you could just self host a translation service.
Google's translation is good, but it's not that much better than what you can get OSS.
e: Misunderstood your comment (I believe the quote was at the top and you edited), now I see that you were referring to your idea as the potential ToS violation. I agree, you can't violate IP law in your app.
> 11.2 If You use third-party materials, You represent and warrant that You have the right to distribute the third-party material in the Product. You agree that You will not submit material to Google Play that is subject to third -party Intellectual Property Rights unless You are the owner of such rights or have permission from their rightful owner to submit the material.
https://play.google.com/about/developer-distribution-agreeme....
Disagree on this one. For the languages of the European Union and a couple other outliers, sure it's close. For the long, long tail of languages software developers typically don't care about and are outside the wealthy world Google is the only thing that is remotely intelligible.
(I work for Google but do not speak for it)
To be fair we know that mobile hardware resources can be extremely limited, and I’d wager a server side model will always be bigger and therefore better.
But recently there’s been a lot of amazing progress in techniques to shrink large models down while preserving most of the accuracy (eg quantization aware training, etc).
With some additional constraints on scope (maybe only supporting the handful of languages the user needs?), I believe a sharp team of a few experts could deliver this fairly quickly, with reasonable results that would of course improve over time.
The models are around 20M for any single language so there is a not insignificant cost on the user in terms of delay for downloading, data usage and disk space.
Disclaimer: I work for Google and worked on the ML Kit Translate SDK, but I don't speak for Google.
Deciding to use the Google Translate API in a way that bypasses Google's API-key system seems like a dangerous game. Google controls your access to the Android platform† and now that this blog post has been published, it seems like Google could remove the app from the Play Store for unauthorized access of Google services.
If they'd found a way to use an API from some third party, maybe that third party would try and shut it down or whatnot. In this case, it feels like they're poking the bear - especially given how much traffic they might throw at it. At some point, Google might get annoyed that an API that they charge a lot of money for is being used for free and somewhat legitimately remove Telegram from the Play Store. Google can pretty legitimately claim that the Telegram app was accessing Google's servers in an unauthorized way and that they went through steps to obfuscate their access which shows that they knew what they were doing was wrong and tried to hide it.
This seems like a bold move. Google might simply shrug and not care. Google might decide that they'll remove Telegram from the Play Store permanently. Google might decide they'll only allow Telegram in the Play Store if it doesn't have translation features. If Google removes Telegram from the Play Store, that's basically the end of Telegram. As people bought new phones, the number of people reachable on Telegram would dwindle‡. As the app no longer could receive updates, eventually it would become old and stale. They'd have to start moving to another platform whether WhatsApp or Signal or Matrix.
†sure, other stores and side-loading exist on Android, but Google does control access for the vast majority of Android users (at least in the US/Europe).
‡yes, maybe one can transfer apps and side-loading does exist, but the number of users would dwindle
I think they will just figure out how to break this feature.
It allows Telegram users to hide in plain-sight, within the noise of other Google Translate web users.
I'm pretty sure that using the official pre-built java SDK, as suggested by the author, would allow Google to cluster the content of Telegram users (since app-specific id/token should be sent).
Other than that, a great read and kudos to the author for shedding light on it.
Edit: typo.
Yes, Telegram fakes the user-agent, but the rest of the request still looks very different from a request an actual browser would do. (No referrer, missing headers, different connection pooling behaviour, possibly different TLS and HTTP2 behaviour, etc).
So if Google is doing any detection for browser vs non-browser requests, those requests should show up as suspicious.
On the contrary - it's the most stupid thing to do. The only result will be their users wondering soon why this function is broken.
Well, the plain text, not the IP, but that should be implicit with how web services work.
If Telegram really can't afford an integration, just make a translate button that opens a link to https://translate.google.com/?sl=es&tl=en&text=API%20de%20tr...
Edit: not to mention the privacy implications of sending messages to Google.
It is now blocked, always responds 403, maybe tweaking some request parameters can make it work again.
Edit: if you want to try it out the parameters I used were:
- container: focus (there are other values I cannot find anymore)
- url: urlencoded URL of the image to be resized
- resize_w: width in px
- resize_h: height in px
If Google views what telegram doing as abuse, then how it’s different from what end users are doing while interacting with https://translate.google.com/ web page? Especially if these end users are running an ad blocker or two in their web browser? BTW, uBlock origin blocked 4 pieces of content on that web page.
Huggingface offers a few models that are pre-trained [0], OpenNMT is a good framework [1] as is MarianMT [2]. Many of the best MarianMT models have been ported to HuggingFace.
If you don't want to self host, huggingface offers these APIs at a cost.
[0]: https://huggingface.co/models?pipeline_tag=translation [1]: https://opennmt.net/ [2]: https://marian-nmt.github.io/
Although at the same time half my friends use it at our (critical) communication platform. So it's not in our best interests.
In general I am pro Telegram, as I think any democracy needs to have censorship-free communication for whistleblowers etc. and to prevent attacks against democracy itself. Even if this means we have to live with stupid/illegal opinions being expressed too.
I'm not sure about this.
I bet Google is happy to collect the text data of up to 500 million users with zero restrictions from Telegram's end on how the data is used. I'm not a lawyer, but my hunch is that Google's data privacy policy applies to the official, premium service: https://cloud.google.com/terms/data-processing-terms
Google might make the determination that they'll get more value from allowing Telegram to abuse the unofficial API. However, they might face some angry customers who are paying a premium to use the official API now that this loophole has been published.
> The java.lang.Math.random() method returns a pseudorandom double type number greater than or equal to 0.0 and less than 1.0.
And again, i wonder how a tiny team can push such great and useful features into such amazing UI. And then I'm looking at other alternatives, from naked WhatsApp over laggy wechat to horrible UX in signal.
What's the reason for telegram amazing performance and features?
Wouldn't a better question be "what's the reason for other apps having crappy performance and subpar features"?
At this point, I just think the answer is top notch developers and designers with an impressive alignment about what the product should be.
I know no other free application with such an amazing usability. There must be some shitload of money behind them, for sure.
It's still impressive, though. It's not as if Facebook's chat works this well and that isn't (wasn't?) encrypted either and they've got an even bigger pile of cash. It's also a lot older though, just look at the evolution from IRC to MSN to Facebook to Telegram: each step it gets better. Maybe that's how that difference can be explained? Anyway, between normal messengers like Signal/Whatsapp/Wire/etc. and Telegram, the main difference is not caring about privacy. (To be clear, I don't mean that whatsapp is a privacy-conscious messenger as they will collect what they want behind the scenes, but on the client side they have to care about keeping the server "untrusted" and that will slow everything down a lot.)
What I think you're underappreciating is that Telegram was built on the premise of privacy and they've neglected that from day one. It was better than the status quo on day one (at release), but have fallen further and further behind ever since.
Telegram was launched when Whatsapp sent messages without transport encryption over port 443 (this was fun on public wifi!) and got big when Whatsapp was bought by Facebook because Telegram was independent and had proper end to end encryption (with air quotes around "proper" if you like; it wasn't OTR-grade but at least it was better than the status quo). Since then, nothing happened whatsoever on the privacy front. Even the legal compliance is a complete joke (gdpr data exports only work in a few clients and not very well at that), but more importantly to me, they need gdpr data exports because the servers still know everything. Whatsapp moved on, Signal got a lot more mature, Wire has also come onto the playing field, and Telegram has done nothing since before Snowden told us to turn on https basically.
Telegram is still at "open a secret chat" with worst UX
But definitely
I switched to Matrix though
There has been a lot of work on it but the smart thing to do would have been to copy Wire or Signal and build on an existing thing if you don't have the manpower to start from scratch and want to be a mainstream alternative.
I'd rather recommend Threema (best UX, not so great in features or encryption tech), Signal (network effect, best privacy, reasonable UX), or Wire (like Signal but slightly better desktop experience).
I started pulling people to it only a few months ago when I thought it was good enough (includes almost no encryption issues happening in all day usage)
My mom uses it as well. It works fine. I had to install the app though, like all the other apps.
The reasons why I found Matrix interesting, were:
- Telegram like syncing messages across all devices while adding a new device is as simple as setting up WhatsApp Web
- It's a standard for interoperability - I got sick of telling others what to use and being told so by the network effect
Copying Wire or Signal just wouldn't work for technical reasons. I also wouldn't want a copy.
I got all of your recommendations over time (including buying Threema with all my friends), but they just haven't been good enough for us and me. In practice, no one cares about Electron. It seldomly VScode or Teams are used at work
That's hyperbole and I think you know it. It's not like the messages are sent unencrypted for anyone to sniff with minimal effort.
Meanwhile I'm just here thinking, what's the matter if you're messager is super duper safe if your device OS running them is plagged with backdoors?
> what [if your] mess[en]ger is super duper safe if your device OS running them is plag[u]ed with backdoors
This is more relevant. Bugdoors more than backdoors, or perhaps just stupid bugs and enough budget to find them, but yeah basically that's how messages are decrypted these days (e.g. NSO group).
For example, people have been using Russian GOST algorithms as a hedge against the USA stuff, but it's falling out of style because it just hasn't proven necessary in the decades since the AES and SHA families came into existence. Any bugs we found, for example in SHA-1, affected everyone equally and did not create a backdoor as with Dual-EC (in which flaws were identified before release and which went unaddressed, very much unlike other common algorithms).
Also note that it's not impossible. Wire and Signal have come a very long way already, it's just the front-end (UX) that they're lacking on really. Telegram has features like a video editor and user-filtered search, but those are all client-side things and have nothing to do with e2e encryption. All the things that do (sending messages, emoji reactions, group chats, group video calls, etc.) are already implemented by both apps.
I think you might be missing the point of the article, which is that they’re misusing Google APIs to avoid paying for the proper way of doing things.
This feature will break as soon as Google throws up a captcha, because these endpoints aren’t intended to be used programmatically.
> And again, i wonder how a tiny team can push such great and useful features into such amazing UI.
The translate functionality comes from Google. They’re just sending messages to Google and getting a result back, at least until Google detects the API misuse and breaks the response.
Of course, my use case was neither commercial nor large scale.
Google does the same thing in Google Pay Indian version. Government mandated that no one app can have more than 25% transaction volume of the country for UPI. So Google partnered with 4 banks, essentially having 4 UPI apps in the eyes of government.
Also the Google Pay analogy seems off. Telegram backdooring free access to Google Translate is not at all the same as Google partnering with 4 banks for transaction processing. One is totally unofficial, the other is an actual partnership.
For Google Pay, what Google is doing is actually not legal. Government wanted each third party (non bank) app to be restricted to 25%. Google will get in trouble when government actually starts cracking down (and when they get close to the 25% mark). We don't know how government is looking at them, because they're under threshold anyway. The legal way for GPay to handle over 25% of total transactions is to register at least as a Payment Bank.
Here's a thought for you, though:
Telegram can be used just fine without Google Play Store. If Google blocks this new and cool feature and people like this feature, it only serves to push people into skipping the playstore completely because people are invested in their messaging applications.
Now, normalising downloading and installing applications from outside the Play Store is a big red flag to Google.
This is possibly the most genious and awesome thing Telegram has done, and imho an excellent play. Either TG gets cool new features easily, or people get freedom and still get cool new features.
I'm very interested in how this is going to play out!
From what I remember, there was some minor rate-limiting that I hit once or twice while using it, which complicated things a little.
I wonder if an alternative route could be somehow leveraging google's own app. The Translate app is likely already installed on user's platform. So is there a way to send the user's translation requests to the app?
It's almost a unix-approach, a tool for a task. Instead of a megatool for all-you-want.
You can, but it naturally kicks you out of your app into the Translate app, so not exactly seamless. It's fine for the occasional one-off translation I guess, but not if you possibly want to completely translate one side of the conversation.
[1] https://weblog.west-wind.com/posts/2011/aug/06/translating-w...
Yandex also has Papiamento in their text translation. Which Google doesn’t support at all.