[HN Gopher] How Telegram Messenger circumvents Google Translate'...
___________________________________________________________________
How Telegram Messenger circumvents Google Translate's API
Author : decrypt
Score : 319 points
Date : 2021-12-31 10:35 UTC (12 hours ago)
(HTM) web link (danpetrov.xyz)
(TXT) w3m dump (danpetrov.xyz)
| Const-me wrote:
| Visiting a publicly available web page doesn't create contractual
| obligation between end users and web server owners.
|
| 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.
| dodobirdlord wrote:
| Because Telegram has their app in the Play Store, which does
| require legal agreements, that presumably forbid this sort of
| thing.
| dandiep wrote:
| One thing I don't see mentioned here is that the Google Cloud
| version of Translate is actually different than the user-facing
| one at translate.google.com. At least when I tried it a year ago,
| the Google cloud version was vastly inferior. I suspect it has to
| do with licensing agreements around certain datasets. Very
| curious if anyone knows more on this...
| zoomablemind wrote:
| Very questionable decision, rather irresponsible one to all
| parties involved. I hope this won't devolve into a 'rogue-dev'
| blame, the company has to own it up.
|
| 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.
| bacan wrote:
| Telegram is just spyware. Whatsapp is better. Signal is the best
| ilrwbwrkhv wrote:
| Nice hackers way of thinking. This is what makes telegram the
| best.
| zarzavat wrote:
| The following predictable chain of events will happen. Someone
| working at Google will read this blog post and report it
| internally. Google will contact Telegram and inform them that
| they are violating the Play Store agreement and could they please
| use the official API instead. Telegram will remove the feature as
| they can't spend the GDP of the Earth on translations. The end.
| whimsicalism wrote:
| Don't know why they can't just roll their own... At this point
| you could probably even do reasonably well on-device.
| f311a wrote:
| The entire dev team of Telegram is less than 30 people.
| That's why.
| judge2020 wrote:
| I guess this would also be in a legal grey zone/break TOS,
| but I wonder if they could reuse the offline models the
| official Google Translate app downloads.
|
| > worst case you could just self host a translation service
| mikaraento wrote:
| We do offer an official SDK that does that, see
| https://developers.google.com/ml-kit/language/translation
|
| (I work for Google but do not speak for it)
| MiroF wrote:
| I would trust a 3rd party on-device service slightly
| more, given that Google's incentives aren't exactly
| aligned with making that service high quality.
| smeyer wrote:
| I don't think their incentives are exactly misaligned
| with it being high quality, either. If better translation
| can get folks to see more ads, they might not care much
| about losing out potential api-based translation revenue.
| whimsicalism wrote:
| What? How would this violate ToS? iirc even the Google
| translate app does on device translation.
|
| 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.
| judge2020 wrote:
| As in, the translate models are owned by Google and AFAIK
| they don't allow anyone, even other developers, to use
| them. It's against ToS to use intellectual
| property/code/ml models/etc without permission from the
| owner
|
| > 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....
| 3pt14159 wrote:
| > Google's translation is good, but it's not that much
| better than what you can get OSS.
|
| 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.
| behnamoh wrote:
| Reminds me of this thread a while ago:
|
| https://news.ycombinator.com/item?id=29485904
| criticaltinker wrote:
| Another plausible alternative is that Telegram embeds an open
| source NLP model in the app so translation can be performed
| locally (offline).
|
| 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.
| mikaraento wrote:
| Google also provides an official on-device translation SDK
| that is free-as-in-beer (https://developers.google.com/ml-
| kit/language/translation).
|
| 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.
| skinkestek wrote:
| As someone who has often defended Telegram I am somewhat puzzled
| by this one.
|
| 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.
| danpetrov wrote:
| Telegram is great if you like shiny native features like
| stickers and having lightweight native clients, but at
| everything else Telegram is at risk of losing in the long-term.
|
| 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.
| RF_Savage wrote:
| Matrix still has ways to go but Elemental is now actually
| usable.
|
| 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.
| skinkestek wrote:
| > and the builds of the clients that are published to the app
| stores could be anything.
|
| 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.
| saagarjha wrote:
| Telegram doesn't even post their source code to match their
| releases on macOS and iOS. Sometimes they'll do a code dump
| somewhere around that time, but it's not a guarantee.
| stanmancan wrote:
| >Telegram is great if you like shiny native features like
| stickers and having lightweight native clients, but at
| everything else Telegram is at risk of losing in the long-
| term.
|
| 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
|
| Anything missing from this list? Also, does Matrix support
| all of that? Last time I checked Matrix out it seemed clunky
| and confusing (especially for non-technical users) and it was
| missing a ton of the 'basics' that people expect out of a
| chat app.
| godelski wrote:
| Signal seems to have everything you listed except for the
| full history transferring to a new device (works on Android
| but not as well with iOS). Though like you implied, it is
| done manually. I'm still not convinced that this can be
| done without making major sacrifices to security because I
| really do want a trustless system where my messages aren't
| stored on a company's servers (I am okay with optional
| backups though, so there's a middleground).
|
| > 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.
| tcfhgj wrote:
| > 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
|
| 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
| brimnes wrote:
| Signal desktop clients are not native. They use Electron
| and are much slower than Telegram.
| godelski wrote:
| That's true. Something I wish they would fix but I think
| now it is tech debt.
| phreack wrote:
| - An option to not have a password at all and log in just
| by having a phone.
|
| 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.
| ComodoHacker wrote:
| > Your full history to automatically load when you log in
| on a new device
|
| Most people don't actually need _full_ history in most
| situations, just recent history.
| pkulak wrote:
| I think I can speak to how Matrix deviates from your list:
|
| - 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).
| caslon wrote:
| - The native clients for Matrix suck. Even the _mobile_
| clients for Matrix are full of bugs.
|
| - 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.
| pkulak wrote:
| I also heard that Matrix will run off with your wife and
| kick your dog. It's a re-implementation of BoziBuddy, and
| will fail for the same reasons.
| tcfhgj wrote:
| > - I don't think doing what PGP does is really
| impressive, but okay, fine, one point.
|
| 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.
| behnamoh wrote:
| Telegram the app, is the best among all messenger apps.
|
| Telegram the company, maybe not.
| Andrew_nenakhov wrote:
| It is best because they don't bother encrypting user data,
| loading it directly from its own servers.
| behnamoh wrote:
| I meant feature-wise, the app is spectacular, but
| security-wise, it's not that trustworthy.
| pkulak wrote:
| Exactly. Features are way easier with everything plain
| text.
| gcr wrote:
| it's my understanding that Telegram won't automatically
| translate messages unless the user chooses to click the
| translate button, and the option to enable the translate button
| does disclose that translated message content is sent to
| google.
| judge2020 wrote:
| > without any proxying (did I get that right and has the author
| studied it carefully enough?).
|
| 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.
| Const-me wrote:
| > 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.
| judge2020 wrote:
| I mean on the play store side, where they scan app
| submissions for TOS violations before they even hit the
| store. UA rotation on the client side is rarely used for
| good.
| oauea wrote:
| Why would they? This is the Google Play Store, not the
| Apple App Store with all its inane rules.
| fao_ wrote:
| HTML requests are just text, how would you even go about
| scanning for that?
| judge2020 wrote:
| As from the blog post, the source is public[0] and the
| Android review process is almost entirely automated
| static/dynamic analysis of apps submitted, so it wouldn't
| be super hard to find UA-like strings and have some
| elevated manual review if there are a lot of them (if
| they decided to implement this sort of abuse policy).
|
| 0: https://github.com/DrKLO/Telegram/blob/c1c2ebaf4690fd9
| 1c116d...
| Const-me wrote:
| I think that's only possible if they ban TCP/IP for play
| store apps, enforce that in the OS kernel (SELinux can
| probably do), and instead expose the one and only high-
| level HTTP API for apps.
| skinkestek wrote:
| These days Google isn't up to much on a technical level ;-)
|
| 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.
| ehPReth wrote:
| Tools -> All Results -> Verbatim is confirmed broken? I
| thought something was fishy...
| skinkestek wrote:
| Hasn't worked consistently for me for years.
|
| 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.
| patcon wrote:
| > Very much of what Telegram has done security wise is very
| well thought out and has improved over time
|
| 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
| skinkestek wrote:
| > 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.
| chrisfosterelli wrote:
| > Very much of what Telegram has done security wise is very
| well thought out and has improved over time
|
| 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
| MomoXenosaga wrote:
| An advantage of Telegram is that they attract less attention
| from the authorities. Also Telegram seems to have a more,
| shall we say, lax attitude about criminal activity.
| skinkestek wrote:
| You are very precise in your criticism, have my upvote!
|
| 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?
| chrisfosterelli wrote:
| Thanks! That's kind to say.
|
| 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.
| janeroe wrote:
| > For small group or individual messaging, whatsapp ... [is]
| far better choice.
|
| The whatsapp that leaks your data to the FBI in real time
| [1], or do you mean some other whatsapp?
|
| [1]: https://news.ycombinator.com/item?id=29381917
| Egrodo wrote:
| This is entirely false, stop spreading disinformation.
| Barrin92 wrote:
| as the first response to that post says the only thing that
| the FBI got was metadata if icloud backups were enabled,
| it's impossible for whatsapp to leak your actual messages
| because they're on device encrypted.
|
| These comments on whatsapp, which appear with regularity by
| the way, are misleading and just inflammatory.
| upofadown wrote:
| Last I heard there is nothing wrong with the E2EE in Telegram
| at this point in time. OTTOMH, the stuff that people were
| complaining about wasn't anything that anyone would
| realistically care about, particularly for something not
| really that secureable like instant messaging on a
| smartphone.
| chrisfosterelli wrote:
| The current version has no publicly known issues, but
| suspicion is the only valid response when an entity rolls
| their own cryptography for production when such well-
| studied and secure options already exist.
| diebeforei485 wrote:
| > suspicion is the only valid response when an entity
| rolls their own cryptography for production
|
| Strong disagree. I would rather have multiple solutions
| in production, and Telegram's is also well-studied.
| chrisfosterelli wrote:
| Most established approaches were well studied _before_
| they were put in production, while Telegram has had the
| luxury of beta testing their protocol in real time on
| their 500 million users, and the work isn 't yet done
| with issues discovered as recently as this year:
|
| > 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/
| diebeforei485 wrote:
| I'd suggest you actually read the paper[1] you're
| referring to, because it's actually a lot less critical
| of Telegram's approach than you make it out to be.
|
| 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.
|
| 1. https://mtpsym.github.io/paper.pdf
| chrisfosterelli wrote:
| I have read this paper. Not sure where you feel I
| mischaracterized it. The section you just quoted goes on
| to discuss caveats, including a recommendation that they
| swap out their low level cryptographic implementation
| with one that uses a standard and well-vetted library,
| and then criticizes them for not having e2e on by
| default.
| lowdose wrote:
| Yandex image search is superior to google image search because it
| does not interpret the content to a string and searches for this
| "one liner" but searches actually for similar images.
|
| Yandex also has Papiamento in their text translation. Which
| Google doesn't support at all.
| littlecranky67 wrote:
| Not sure if this is a smart move, especially since they piss off
| the same company that could remove them from the Play Store in no
| time.
| 88840-8855 wrote:
| Another useful feature, interesting article to look how it works
| under the hood.
|
| 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?
| PragmaticPulp wrote:
| > Another useful feature, interesting article to look how it
| works under the hood.
|
| 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.
| iqanq wrote:
| >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"?
| pjerem wrote:
| Telegram is pretty impressive when you take into account the
| number of (well implemented) features that they managed to
| shove in the app without breaking ergonomics and performance.
|
| 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.
| BlueTemplar wrote:
| Discord ?
| sorenjan wrote:
| Does Discord have a native (not Electron) desktop app?
| BlueTemplar wrote:
| Nope. I guess though that with lots and lots of money you
| _can_ make even an Electron app work well ?
| iqanq wrote:
| I think it's the result of every one of the clients
| (desktop, android, ios) having only one developer each.
| lucb1e wrote:
| From what I gathered: a boatload of money from the rich owner
| for development and hosting, plus not caring about encryption
| in any way. Don't need to bother with tricky distributed device
| syncing protocols if your servers simply store everything and
| can index the data at leisure for fast global search etc.
|
| 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.)
| traveler01 wrote:
| Actually Pavel Durov made some very rough accusations against
| Signal and other "secure" apps for using the standard
| encryption method. For what he says, he doesn't trust others
| encryption protocols because he believes NSA made some pretty
| well hidden backdoors in them to easily decrypt them.
|
| 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?
| lucb1e wrote:
| Kleptographic backdoors in the Signal protocol is FUD. I
| work as a security consultant, which is definitely not a
| cryptographer, but I do get around and "NSA made some
| pretty well hidden backdoors in them to easily decrypt
| them" is definitely false.
|
| > 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).
| ju-st wrote:
| Wouldn't it be a good idea to use two chained encryption
| methods? AES+whatever Telegram is using? This would be
| resistant against a AES backdoor and against bugs/backdoor
| in the Telegram encryption method. Similar to TrueCrypt
| where you can select AES+Serpent+Twofish to encrypt your
| files.
| lucb1e wrote:
| That would work, but historically this hasn't proven
| necessary and double encryption means double the CPU
| power (or more, if one of them has CPU extensions and the
| other encryption method does not). Doing group calls in
| Wire is already very taxing on nowadays' energy-efficient
| laptops or not-high-end phones.
|
| 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).
| p1anecrazy wrote:
| People tend to forget that Whatsapp encryption was introduced
| years after Telegram's secret chats. Now they are
| continuously bashed for no encryption by default, but their
| original proposition was "messenger done right" as compared
| to unencrypted Whatsapp and FB.
| lucb1e wrote:
| I'm well aware of that and I don't have WhatsApp because of
| its privacy problems (much to the annoyance of some family
| members, but I imagine it saved me from a lot of printer
| queries, and if _they_ aren 't willing to switch then why
| should I).
|
| 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.
| gefhfffh wrote:
| Yeah and now every messenger uses encryption by default -
| in groups, mostly with multiple devices.
|
| Telegram is still at "open a secret chat" with worst UX
| lucb1e wrote:
| Not just UX, also availability. I simply _cannot_ use
| encrypted chats in the Telegram desktop client that I use
| the most and runs on the device that can actually get
| security updates while being fully owned by me (I, ahem,
| "rooted" my laptop and it can still install system
| updates without any hassle, it's amazing). This is why
| I'm slowly moving more and more friends to Signal but
| their UX is also very mediocre by comparison.
| gefhfffh wrote:
| Thought that could also be considered being part of the
| user experience
|
| But definitely
|
| I switched to Matrix though
| lucb1e wrote:
| I'm using Matrix with two friends and it's just a world
| of pain. Can never find any messages because search is
| not implemented on web or android (only ios seems to have
| it or an electron desktop client... no thanks to both),
| random issues with encrypted chats (it all works great if
| you leave e2ee off! Though it got a lot better already
| since a big update ~1.5 years ago) such as unavailable
| message keys, random bugs, and too complicated for use
| with non-techies (so not an option for my mom). What
| helps is having alternative contact channels for when a
| message fails to decrypt or the custom homeserver is down
| again.
|
| 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).
| gefhfffh wrote:
| I have been testing it for about 3 years now (FOSDEM 2019
| made me interested again)
|
| 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
| sorenjan wrote:
| > not caring about encryption in any way
|
| 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.
|
| https://telegram.org/faq#q-so-how-do-you-encrypt-data
| croes wrote:
| And you know that encryption for messengers means E2E not
| server to client. Privacy means even Telegram doesn't know
| what I wrote.
| lucb1e wrote:
| Of course, I find that to be a given these days. When
| people talk about encrypted chats in 2021, it's not about
| transport encryption... installing let's encrypt for your
| api is the easy part.
| Gigachad wrote:
| End to end encryption seems like an endless pain in the ass.
| So many expected features like server side searching and link
| embeds become basically impossible to do in a secure way.
| lucb1e wrote:
| The problem with having your own server instead (then you
| can just do transport encryption and call it a day) is that
| everyone needs to be on your server. Or go decentralized,
| but that has its own host of complications that may or may
| not be easier than end to end encryption.
|
| 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.
| jcelerier wrote:
| Written in C++ / Qt for the most part :-)
| drath wrote:
| On one hand, it's quite asshole-ish. On the other, google is
| serving broken frontends to their services and charge ridiculous
| prices on their API's. When I tried to make a third party search
| using google engine, I've exhausted the limit in less than an
| hour. It'd cost me like $40/mo to get what I get for free using
| their crappy frontend.
| typingmonkey wrote:
| Like telegram did with the translate api, there is also a way
| to have an unlimited api for search results. You have to find
| one of the old mobile pages of google.
| PragmaticPulp wrote:
| > On the other, google is serving broken frontends to their
| services and charge ridiculous prices on their API's.
|
| 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.
| rebolek wrote:
| Google isn't entitled to get my personal data for free to,
| yet they do it anyway.
| tyingq wrote:
| You could use the _" turnabout is fair play argument"_. If
| you publish a web page, and don't specifically block google,
| they scrape your content, and use it for their own purposes.
| And even use it for "rich snippets", products other than
| search, etc. You're basically doing the same to them...using
| their content for your own purposes until they specifically
| block you.
| PragmaticPulp wrote:
| Disagree. The web is clearly architected such that
| publishing a webpage makes it public and crawlable. You
| don't "block Google", you specify that the site is not for
| crawling in robots.txt according to well-known standards.
| This is all basically the contract of the internet and it
| shouldn't be surprising to anyone.
|
| 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.
| tyingq wrote:
| _" driving traffic to it for you."_
|
| I did mention rich snippets.
| tshaddox wrote:
| I don't understand your argument. There is no actual
| "publishing" of web sites or APIs on the web. You simply
| make something available at a URL, and it's up to anyone
| else to discover that URL. In this regard, your personal
| web site is no different than this Google Translate web
| API.
| inportb wrote:
| > this would be like a crawler ignoring robots.txt
|
| Google ignores the _noindex_ directive in robots.txt now.
| You 're supposed to put it in your HTTP response headers
| or HTML meta tags...
| ldjb wrote:
| `noindex` was a Google-specific rule that was never
| officially documented nor supported. I think they were
| perfectly entitled to withdraw support for it, especially
| considering there are alternatives.
|
| https://developers.google.com/search/blog/2019/07/a-note-
| on-...
| agentdrtran wrote:
| "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." Tell this to Google!
| yosito wrote:
| I really don't understand this. Is Telegram a legitimate app? If
| so, then why are they attempting to rip off other companies' work
| without paying them? You want an integration with a translation
| API? Then pay a fair price for one, or build your own?
|
| 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.
| rfoo wrote:
| Okay, how about I open an embedded WebView of
| https://translate.google.com/?text=..., with the viewport
| carefully set to only show the translation results?
| ssl232 wrote:
| I guess, given its popularity, Google won't kick Telegram off the
| store for obfuscating the URL and using an unauthorised (?) API
| endpoint but I imagine this will get them in some sort of
| trouble.
| robby_w_g wrote:
| > I imagine this will get them in some sort of trouble.
|
| 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.
| littlecranky67 wrote:
| I think they could do it. In Germany, Telegram is often cited
| by media as a platform for (illegal) right-wing, antivax and
| hatespeech. Some politicians openly demand to go ofter Telegram
| and/or block it. So google could kill two birds with one stone
| here. At least remove it from the Play Store in some countries.
| kaladin-jasnah wrote:
| I believe it is the same in the US.
|
| Although at the same time half my friends use it at our
| (critical) communication platform. So it's not in our best
| interests.
| littlecranky67 wrote:
| Telegram is basically opposed to any kind of censorship
| which is IMHO a good thing. Western politicians are
| outraged as hatespeech, murder threats, right-wing paroles
| etc. are openly distributed through Telegram and demand
| regulation/takedown. At the same time, when protesters in
| Belarus or HongKong use Telgram to coordinate and those
| Governments demand takedown, the West screams oppression
| and demands freedom of speech.
|
| 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.
| einpoklum wrote:
| I wonder how useful this, considering how Telegram conversations
| are unencrypted by default. If they were to change this default,
| now _that_ would be something.
| ckastner wrote:
| I think it's possible construct to construct a (very weak)
| argument for the random user agent rotation, but why split the
| spring if not to avoid being flagged.
|
| 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.
| Bombthecat wrote:
| Would deepl cheaper?
| arihant wrote:
| I'm not sure if Google will start flagging the IP addresses of
| the users because of each request having a different agent.
| That would render normal Translate unworkable for them too!
| Nextgrid wrote:
| These users will just say "google translate down", shrug and
| go to Bing or competing translate services.
| vesinisa wrote:
| Pretty sure at the point you have over a billion(!) installs,
| even Google affords some leniency towards its Play Store
| policies. Or at least we are about to find out anyway..
|
| Meanwhile, indie developers with smaller user base are subject
| to unappealable automated decisions.
| lima wrote:
| Telegram is well-known for operating in grey areas.
| wccrawford wrote:
| Isn't Google going to move to always having the user agent be
| the same anyhow? They've already decided to break that contract
| with the tech community, so I don't see that they have much
| room to talk there.
| dmurray wrote:
| That contract was torn up a long time ago. Or do you really
| browse the web with "Mozilla/5.0 (Windows NT 10.0; Win64;
| x64) AppleWebKit/537.36 (KHTML, like Gecko)
| Chrome/96.0.4664.110 Safari/537.36"?
| barnabee wrote:
| Someone deleted an interesting comment about adversarial
| interoperability [0]
|
| 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...
| zackmorris wrote:
| This is a really good idea!
|
| 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.
| 3pt14159 wrote:
| I was advocating for this for years but gave up when I talked
| to someone at Pager Duty that was just straight out against
| it. For almost irrational reasons. I kept trying to make the
| case that for a company like their that literally can't be
| taken offline without risking huge chunks of the internet why
| _wouldn 't_ they want to run their whole business on an
| abstracted away platform to, say, switch to Windows if linux
| had a 0day, etc.
|
| > 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.
| barnabee wrote:
| I totally agree.
|
| 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.
| sdeframond wrote:
| Do you know Woob ? https://woob.tech/
| crtasm wrote:
| Looks excellent.
|
| "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.
| kerneis wrote:
| Qt applications are maintained and packaged separately:
|
| pip install woob-qt
|
| https://gitlab.com/woob/woob-qt/-/blob/master/INSTALL
| crtasm wrote:
| Thanks, I'll suggest they add that to
| https://woob.tech/install
| [deleted]
| barnabee wrote:
| Thanks! This looks really cool
| xwolfi wrote:
| Ahah looking at the logos triggered my frenchness, this
| things is from the motherland.
| Fnoord wrote:
| This is nice, and feature rich. Its available in Homebrew,
| where I was able to try it out (if I ran Nix I'd been able to
| use nix-shell for such). However, its France and French
| oriented. Not the world-wide interface I expected it to be.
| Bands for example, only contains a metal database. Recipes, 5
| out of 6 entries is French. Travel, I don't see German or
| Dutch or UK or Belgian public transport.
| rakoo wrote:
| So they finally gave in to the complaints about the name (htt
| ps://lists.symlink.me/pipermail/weboob/2021-February/0016...)
| . woob is excellent but unfortunately its very existence
| means there is a problem. Hopefully they will gain visibility
| and problematic services will adopt standard protocols
| iqanq wrote:
| igammarays wrote:
| Holy s*t this is amazing! A set of web-scraper automations!
| danpetrov wrote:
| Wow that is really cool!
| folex wrote:
| such APIs could be running on https://fluence.network with an
| interoperability and composition across different services
| PragmaticPulp wrote:
| > Perhaps companies and projects would not often use these
| directly because of the risks
|
| 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.
| alpineidyll3 wrote:
| Bahhh do you want to get captchas? THIS IS HOW YOU GET
| CAPTCHAS!!!
| gregoriol wrote:
| Nobody pays for using Telegram, so why would Telegram pay for
| using... oh...
| morelish wrote:
| Quite a lot of libraries exist to do this. But doing this in an
| app with a large user base looks offensive. Solution would be for
| some decent open source translation APIs to appear.
| whimsicalism wrote:
| There are plenty of open source, decent translation APIs, the
| catch being that obviously nobody is going to pay for your
| translation compute.
| jlelse wrote:
| On iOS Telegram uses a system API, but on Android they seem to
| try to avoid the high Google Cloud fees:
| https://jlelse.blog/posts/telegram-translation
| Gigachad wrote:
| Is iOS using that local translation app added in iOS 14?
| marcellus23 wrote:
| Looks like it, but it's still an undocumented private API
| they're using.
| malf wrote:
| Is this an option for encrypted chats as well? Is there a warning
| that the content gets sent to Google?
| aquatica wrote:
| Yes.
|
| https://imgur.com/a/7UIFLxT
| cj wrote:
| As a small company who spends $70-80k per year on Google's
| official Translate API, it's disappointing if Google allows this
| type of abuse to continue.
|
| If they don't want to pay, they should be using a free open
| source alternative like
| https://github.com/LibreTranslate/LibreTranslate
| charcircuit wrote:
| Not everyone can afford to use these APIs or are able to get
| permission to use the external APIs. The internal APIs are very
| good for people who don't mind taking the risk of using a
| potentially unstable API.
| HatchedLake721 wrote:
| Then don't run a business with services you can't afford?
| charcircuit wrote:
| But using internal APIs are free. I can afford to use them
| since I don't mind having to update my usage of them / work
| around rate limiting.
| IX-103 wrote:
| Do you also only eat free samples from the grocery store?
| jokethrowaway wrote:
| Those are usually rate limited.
|
| I'd recommend pizza and beer at tech events instead
| (albeit the nutritional content of your diet could be
| more important than free food).
| Const-me wrote:
| Which part of https://translate.google.com/ web page says
| the service provided by the page is a free sample of
| commercially available API?
| yjftsjthsd-h wrote:
| The ToS, I expect
| Const-me wrote:
| I've looked for 5 minutes there, and found nothing
| relevant. They don't even have additional specific TOS
| for their translate service, the only link from
| https://policies.google.com/terms/service-specific?hl=en-
| US under "Translate" section points back to their common
| TOS at https://policies.google.com/terms?hl=en-US
|
| 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.
| dandiep wrote:
| I've spent some time looking into this and found very
| little. The closest I could get is that if you are a
| Google Cloud customer, it forbids you from reverse
| engineering other Google APIs that are not documented as
| supported, which would probably include this use case. No
| idea if they're a Google Cloud customer though.
| Const-me wrote:
| > No idea if they're a Google Cloud customer though.
|
| 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.
| alisonkisk wrote:
| alisonkisk wrote:
| kukabynd wrote:
| Definitely would love to learn more about your use case.
| Recently I started to use DeepL and it's great if the language
| selection is enough for you.
| johnisgood wrote:
| Personally I have found DeepL to be more accurate in the
| languages they support than Google Translate. They used to
| support much less, but for the languages it did, it was
| pretty great. It supports way more now though!
| billygoat wrote:
| Still no Turkish on DeepL, even though it is one of the
| most widely spoken languages across much of Europe and uses
| the Latin alphabet.
|
| 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. :-(
| johnisgood wrote:
| I am unsure if the support for those languages are better
| vs. Google Translate, but the small set of languages it
| used to support a year ago or something is definitely
| better. I remember French and Spanish being way better.
| DeepL's Polish is not that great, that I can say for
| certain! Not sure if better than Google Translate's
| though.
| Xorlev wrote:
| Qualitatively better, or quantitatively? If the latter,
| do you have some metrics you can share?
| commandnotfound wrote:
| Contrary to Turkish, Estonian, Latvian and Hungarian are
| all EU official languages. That means that all EU
| legislation is legally required to be translated to these
| languages and it is readily available in all these
| languages for free to train the AI model for translating
| to those languages.
| grandpoobah wrote:
| Crabs in a bucket.
| iqanq wrote:
| >As a small company who spends $70-80k per year on Google's
| official Translate API, it's disappointing if Google allows
| this type of abuse to continue.
|
| You mean that you are disappointed that you did not come up
| with this on your own...
|
| Also, calling this "abuse" is some sort of charged language...
| Like the word "piracy"
| cj wrote:
| > You mean that you are disappointed that you did not come up
| with this on your own
|
| I've been aware of this loophole for years, it's nothing new
| and is widely known.
|
| I just chose to build our business using legitimate above-
| board APIs and services, as should Telegram.
| jokethrowaway wrote:
| If it's public and available and Telegram didn't sign a
| contract or EULA which forbids using this endpoint, it's
| legitimate.
|
| The cons is that Google can break the endpoint at any time.
|
| That said, I wrote a similar hack for a Wordpress plugin 10
| years ago which automatically generated articles in
| multiple languages (think SEO farming).
|
| I just looked at what their frontend app was calling and
| used it.
|
| I run a business which needs to run programmatically
| searches on different search engines and using official
| APIs is out of the question. I didn't even check what their
| API offering is.
|
| The only search engine that seriously try to prevents
| scraper is Yandex which asks for a lot of captchas but I've
| built a system to allow humans to just process captchas and
| give back to the code the result.
| serioussecurity wrote:
| This definitely violates the terms of service, if that's
| what you're asking.
| iqanq wrote:
| They never agreed to the ToS, so they can't have violated
| them.
| digitaLandscape wrote:
| fault1 wrote:
| It does seem to violate the Google Play ToS in terms of
| applications not using unauthorized 3rd party resources.
|
| Google will most likely just fingerprint these calls and
| block them serverside, I'm guessing.
| kedmi wrote:
| It's smart.
|
| 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.
| AndriyKunitsyn wrote:
| Shell game street fraud (with cups and balls) is also "smart"
| in some way, but it's not really the right thing to do.
| hdjjhhvvhga wrote:
| > It's smart.
|
| 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.
| dejj wrote:
| If Telegram or Google users would pay for services, they
| wouldn't treat them like the product being sold.
| michaelmcmillan wrote:
| A rotated user agent does not hide anything from Google.
| giomasce wrote:
| It doesn't look very well hidden if there are blog posts about
| it...
| OJFord wrote:
| The users are hiding among all the web traffic to
| translate.google.tld; not that that Telegram's doing this is
| top secret undiscoverable magic sauce. It's open source
| (GPL2): https://github.com/DrKLO/Telegram/blob/9e740dfd4d2b1a
| b6b8ed2...
| xg15 wrote:
| I think Google can still cluster Telegram users pretty easily,
| especially now that that the method is in the open.
|
| 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.
| nothasan wrote:
| If they used cronet, they could get past these checks.
| [deleted]
| rossmohax wrote:
| Telegram should have disclosed that every time someone uses this
| feature, their IP address is leaked to Google.
| bencollier49 wrote:
| Ooooh, GDPR?
| Nextgrid wrote:
| Do you really expect _Telegram_ to get the GDPR hammer when
| Google and Facebook are still around and do orders of
| magnitude worse?
| [deleted]
| Krasnol wrote:
| I doubt users of Telegram care much or they wouldn't use
| Telegram in the first place.
| Gigachad wrote:
| Telegram includes google services baked in to the app for
| things like maps.
| ju-st wrote:
| There is a Telegram-FOSS fork with most Google services
| removed but the translation feature is not removed (yet?) in
| the code.
| fault1 wrote:
| I think they already do: https://imgur.com/a/7UIFLxT
|
| Well, the plain text, not the IP, but that should be implicit
| with how web services work.
| themacguffinman wrote:
| I wouldn't say it's obvious to either laymen or technical
| users, some apps will proxy a web service for the exact
| reason of hiding user info.
| Anunayj wrote:
| also the content of the translated message is leaked in plain
| text too?
| whimsicalism wrote:
| That is disclosed
| aenis wrote:
| This can't work for long. Translate is a profit center for
| google, and this also shows others that they can disregard
| google's monetization model for translate.
|
| 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.
| hdjjhhvvhga wrote:
| I'm curious what techniques they will use to differentiate
| between Telegram and non-Telegram users. If I were them, I'd
| simply use my power leverage and threaten them to remove the
| app from the Play store unless they remove/fix the offending
| code - it's much simpler than an eternal mouse-and-cat game,
| with possible collateral damage.
| [deleted]
| izacus wrote:
| > I'm curious what techniques they will use to differentiate
| between Telegram and non-Telegram users.
|
| A cease-and-desist letter from Google legal tends to work
| pretty well as a technique in these cases.
| Nextgrid wrote:
| I'm pretty sure Telegram is outside of US jurisdiction and
| can trivially respond with a middle finger.
|
| 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).
| michaelt wrote:
| Given that Google runs ReCapcha - which is almost certainly
| the world's most widely used browser fingerprinting system -
| they have ample experience with is-it-a-real-browser cat and
| mouse games.
| iqanq wrote:
| In fact if you use this API constantly, you are presented
| with a recaptcha.
| rfoo wrote:
| In this case, Telegram may just display the captcha and
| let the user solve it.
|
| 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".
| aenis wrote:
| I think they will look for a legal solution. I doubt they
| will change the API; my guess it it exists to support some
| other services google sells -- and adding heuristics to
| detect freeloaders may impact legitimate customers. Nope,
| they will get a cease and desist letter, and if they happen
| to use any other GCP services, or rely on Google to do
| business, this will likely be pretty persuasive.
| hetspookjee wrote:
| Ah, you're suggesting Google uses its position on the Play
| Store to fend of abusers of an unrelated service, that
| happens to be owned by Google as well? I don't think that
| will work in Google's favor when they try to defend any anti-
| trust cases slung their way, or being active right now.
| Google has many other subtle ways that garner less attention
| to ward of any misuses. Subtly downrank in the search index,
| throttle any traffic heading their way, suggest other
| applications in the play store on top, accidentelly flag
| Telegram as a "risky" platform, etc.
| simias wrote:
| I see what you mean but surely there must be precedents of
| apps being pulled from the Play Store because they abused
| 3rd party APIs, be it Google's or somebody else's?
|
| I mean why even bother obfuscating the URL otherwise,
| surely the expected that it could be caught in the review
| process.
| not1ofU wrote:
| stop giving them ideas.
| hetspookjee wrote:
| I don't think you're serious as most of these ideas
| aren't that novel / intricate, but in general I'd rather
| publicise these ideas so they're general knowledge and
| everything would be aware of the absurd amount of power
| Google levies.
| not1ofU wrote:
| ;-) Happy New year!
| hetspookjee wrote:
| You too =D
| hdjjhhvvhga wrote:
| Well, Apple has no qualms about it[0] so why should Google?
|
| [0] https://dcurt.is/apple-card-can-disable-your-icloud-
| account
| taubek wrote:
| I see few possible issues: 1) If this is some kind of hack to
| reduce the cost this means that Google can pull the plug to this
| at any given time 2) How many users are aware that this means
| that the content is sent to Google? Yes, there is a warning on
| the screen where you turn one the option but will the users see
| it?
| [deleted]
| mdasen wrote:
| "It's a bold strategy, Cotton. Let's see if it pays off for 'em"
|
| 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
| fault1 wrote:
| Personally, I think Telegram has enough reach that
| removing/blocking it would get a lot of unwanted political
| attention against Google - I mean, a lot of politicians and
| decision makers seem to use Telegram depending on the country.
| So I don't think they would do that.
|
| I think they will just figure out how to break this feature.
| Nextgrid wrote:
| Telegram is also popular within the crypto circles and those
| are a lucrative target for advertisers which Google's
| business relies on. Banning it from Android may shrink that
| market.
| arihant wrote:
| My guess would be (given the size of that array) that this is
| done to prevent rate limits rather than cost. It could be that
| this was advised by Google themselves because they could not
| provision the correct rate limits due to end of year. It's hard
| to imagine a client of this size isn't in direct contact with
| Google Cloud engineers. Pretty sure they're paying for it too.
| Also, this may have been done just for the open source commit of
| the project to prevent leaking token? Can't jump to conclusions
| here.
|
| 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.
| chagaif wrote:
| This sounds very reasonable and it's the only comment I found
| in a see of people talking about how Telegram is doing this
| illegally. Would be curious to see how this turns out.
| green-eclipse wrote:
| I think you're looking at this all wrong. If Telegram did this
| officially with Google, would they have had to craft this
| klunky workaround for breaking up RPC strings and randomizing
| the user agent? I don't think so.
|
| 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.
| arihant wrote:
| Yes the string split is a very odd. I agree with you there.
| Very confused that Google can't catch this. It's adding to
| the same string it should look same in the heap anyway?
| Simple college plagiarism programs like MOSS will catch this.
|
| 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.
| polote wrote:
| Is there any proof in this post that Telegram actually circumvent
| Google Translate API ? Because it is also possible that Google
| told Telegram to use the method explained in the article.
| user-the-name wrote:
| That is not how Google works.
| aenis wrote:
| Yup. And those guys will get bonus points for actively
| evading detection. IANAL, but its one thing to use an open
| api and claim ignorance, and quite another to intentionally
| defeat access restrictions/rate limits. Stupid thing to do.
| jmnicolas wrote:
| Why would they concatenate the API url string then? The only
| reason I see is to avoid detection when their app is scanned
| when submitted to the PlayStore.
| emilfihlman wrote:
| These comments are funny.
|
| 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!
| skzv wrote:
| Telegram already encourages downloading the APK directly:
| https://telegram.org/android
| ape4 wrote:
| There are bound to be duplicate phrases for translation over all
| the many Telegram users. Why not cache to avoid API calls. How
| many times do you have to use the API to translate "OK" or other
| commonly used words.
| leodriesch wrote:
| I don't understand the way this was implemented.
|
| 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?
| PragmaticPulp wrote:
| This seems like one of those features that leadership demanded
| with a "just make it happen" decree and no budget for API
| calls.
|
| 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.
| MomoXenosaga wrote:
| Telegram problem is that unlike WhatsApp they don't have a
| billion dollar corporation backing them. I wouldn't be
| surprised if they were bleeding money.
| whimsicalism wrote:
| Don't really think telegram works this way, you are imagining
| it like a Big N
| simias wrote:
| Yeah I'm a bit shocked honestly that it made it into an
| application as widely used as Telegram. It's bound to be
| detected eventually and the feature will suddenly break. Such a
| strange software engineering decision.
|
| 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.
| zenexer wrote:
| "Google cut us off--they're the bad guys, not us. Blame them."
|
| ...but with more elegant phrasing.
| sgjohnson wrote:
| s/elegant phrasing/corporate doublespeak
|
| blah blah blah on 31st of February 1970 Google unanimously
| decided to terminate our access to their Translate API blah
| blah blah blah
| skinkestek wrote:
| This is Telegram. They are actually known for elegant
| phrasing, not corporate doublespeak.
| zenexer wrote:
| Telegram knows how to play the PR game. It's going to be a
| bit more elegant than that, with a "we will rise from the
| ashes" tone. They know what they're doing, and I doubt they
| had any intention of getting away with this.
| ComodoHacker wrote:
| > They are bound to get in trouble with Google for this
|
| 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.
| ozten wrote:
| This is an interesting data point for folks designing demo pages.
| The API was discovered by playing with the demo page [1]
| according to a link from a link in the article
|
| [1] https://weblog.west-
| wind.com/posts/2011/aug/06/translating-w...
| 01acheru wrote:
| I used something like this years past for image resizing, the URL
| was: https://images1-focus-
| opensocial.googleusercontent.com/gadge...
|
| 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
| tyingq wrote:
| It still works, just not with a direct url. It's checking that
| there's a referrer, I think. So that it only works if the image
| is in a web page:
|
| https://jsfiddle.net/depxb0gn/2/
| iwillnot wrote:
| On-device translations is quiet feasible, and there are ways to
| legally do this, such as this app [1] which translates other apps
| using Google's On-device (and officially free!) APIs. Surprising
| Telegram chose such a route instead.
|
| Edit - I tried it out, and the quality of on-device translations
| is pretty garbage. Really garbage.
|
| [1] https://github.com/akhilkedia/AllTrans
| [deleted]
| bratwurst3000 wrote:
| Someone else thinks that telegramm is only a coverup by the cia
| or russians to get data from people? I mean an app that tracks
| the living shit out of you and saves all your data unencrypted on
| their server and is the host of some rly strange groups.... Pure
| gold for such agencies
| Namidairo wrote:
| I remember seeing the aforementioned API endpoint being used a
| while ago for some automatic chat translation.
|
| From what I remember, there was some minor rate-limiting that I
| hit once or twice while using it, which complicated things a
| little.
| homami wrote:
| Off topic, but this is a code smell for me: [(int)
| Math.round(Math.random() * (userAgents.length - 1))]); This leads
| to a lower probability of selecting the 0th and the last items in
| the array.
| namdnay wrote:
| It should be floor right?
| Math.floor(Math.random()*userAgents.length)
| lern_too_spel wrote:
| There's a built-in method for randomly selecting an int in a
| range. Use that.
| csears wrote:
| Are you thinking of the Lodash random() function? Or
| Crypto.getRandomValues()?
| lern_too_spel wrote:
| https://docs.oracle.com/javase/8/docs/api/java/util/Rando
| m.h...
| homami wrote:
| Yeah.
|
| > The java.lang.Math.random() method returns a pseudorandom
| double type number greater than or equal to 0.0 and less than
| 1.0.
| Jerrrry wrote:
| When a dev gets a requirement and no red tape is involved.
| Markoff wrote:
| why even bother with any API, just implement it on client side as
| regular browser with regular google translate request through URL
| like
| https://translate.google.com/?sl=auto&tl=en&text=hello%20wor...
| oefrha wrote:
| This reminds me of my own usage of Google Translate's speech
| synthesis API in a chat bot way back. It was as easy as sending a
| GET request to https://translate.google.com/translate_tts. People
| loved it.
|
| Of course, my use case was neither commercial nor large scale.
| bencollier49 wrote:
| Using undocumented API features in a commercial product seems a
| bit fly-by-night to me - doesn't convey the best impression of
| the company.
| aenis wrote:
| Yeah, and doing this client side, and with the code open
| sourced? "Achievement unlocked".
___________________________________________________________________
(page generated 2021-12-31 23:00 UTC)