Google mengumumkan penutupan jaringan sosial Google+. Sulit untuk menemukan publikasi teknis yang bahkan tidak disebutkan dalam melewati akhir ambisi media sosial Google. Namun, sayangnya, perhatian diberikan pada konektivitas tinggi dari layanan perusahaan yang baik. Pada artikel ini, saya ingin menyampaikan pendapat saya tentang bagaimana layanan Google berinteraksi secara internal dan apa artinya penutupan G + untuk pengguna Google API.
Untuk pengguna akhir, transisi dari Gmail ke Foto, dan dari sana ke Documents semulus mungkin - sekilas, layanannya independen dan disatukan oleh satu titik entri layanan tunggal yang dipoles dengan layanan Single Sign-On accounts.google.com . Tetapi kita sebagai pengembang tahu bahwa kata-kata “tutup”, “serap”, “integrasikan” membawa lebih banyak makna (dan lebih banyak pekerjaan) bagi orang-orang yang mengembangkan suatu produk daripada yang terlihat pada pandangan pertama. Mari kita periksa secara dangkal bagaimana proses penyerapan Google dari salah satu layanan eksternal diatur dan apa yang terjadi dengan API layanan dan Google API.
akun dan ID pengguna
Selain pengguna yang menggunakan Gmail dan kadang-kadang menebak tentang keberadaan Google Plus, ada juga sejumlah besar API untuk pengembang yang ditembus melalui konsep seperti pengenal akun, ID pengguna terkenal. userID adalah pengenal internal Google, hal yang memungkinkan layanan Google untuk memahami siapa adalah siapa, dan adalah orang yang menghubungkan semua layanan internal satu sama lain. Itu muncul di banyak API, dan kami melihat bahwa itu tidak berubah dari satu layanan ke layanan lainnya.
Mari kita ambil contoh penyerapan layanan eksternal oleh Google
Jelas, untuk menerapkan SSO dalam layanan yang baru diserap, Anda tidak bisa hanya mengambil dan mentransfer akun dari basis data lama ke "basis data Akun Google" yang baru - saya pikir tidak ada hal semacam itu - ada banyak layanan yang saling terkait, tingkat interaksi, rantai tanggung jawab, layanan manajemen layanan. Serius, jika Anda memikirkannya, harus ada banyak, banyak, sangat banyak tingkat koneksi antara layanan Google agar semuanya berfungsi.
Namun hal-hal tidak berjalan begitu mulus - dalam upaya mempopulerkan G +, ia menggunakan pengguna ID pengguna yang merupakan bagian dari layanan SSO global.
Kembali ke tesis. Ada kebutuhan untuk membuat perubahan pada API yang ada dari sisi yang diserap API, dan dari layanan lain yang sekarang dapat mulai bekerja dengan layanan baru. Tampaknya tidak ada yang super rumit untuk mengadaptasi basis pengguna layanan yang ada ke layanan "General Google", menciptakan titik interaksi dengan layanan lain sehingga mereka dapat menggunakan layanan baru untuk tujuan mereka sendiri. Tetapi kita tidak berbicara tentang proyek-proyek kecil - perusahaan kebaikan tidak kecil dan menyerap perusahaan jutaan dolar, yang, kemungkinan besar, telah membangun infrastruktur, jika tidak mereka tidak akan dapat tumbuh sesuai ukuran mereka. Jadi, masuk akal untuk meninggalkan basis kodenya, atau lebih tepatnya, inti dari layanan, dan mengulang saluran input-output dari tautan layanan sehingga mereka menjadi kompatibel dengan Google.
Selanjutnya, layanan menjadi layanan Google. Katakanlah pada titik ini sudah diuji dan dianggap sebagai orang yang cukup tepercaya dari Google, yang bertanggung jawab untuk integrasi. Kesenangan dimulai - layanan dapat diintegrasikan ke dalam layanan lain dan / atau ditransfer dari satu layanan ke layanan lainnya.
Secara umum, ini tidak akan menakutkan jika bukan karena kecenderungan Google untuk mengubah pendaftaran layanan.
Ambil contoh foto.
Aplikasi desktop Picasa (2002) => Album Web Picasa - Google mengakuisisi Picasa (2004) => Google Plus menggabungkan Picasa (2011) => Foto Google dipisahkan dari G + (2015) => ...
Mengingat inersia proses integrasi, Google masih mendukung API yang sangat lama di sebagian besar produk. Pada saat publikasi artikel ini, Picasa API masih berjalan sejak Picasa adalah produk mandiri. Yaitu, kami menyimpulkan bahwa ketika Google mengintegrasikan Picasa dengan layanan berikutnya, ia "menciptakan cabang" dari aslinya dan meninggalkan "brunch" lama ke perangkatnya sendiri, tetapi tidak menutup API-nya.
Dan sekarang saatnya untuk mengingat alasan penutupan G +. Masalah keamanan yang dilaporkan, pada kenyataannya, bahkan mungkin ada lebih banyak masalah keamanan karena inkonsistensi API yang berbeda.
bukti konsep
Misalnya, pernah ada layanan PicasaWeb , leluhur dari Google Foto modern. Itu dimatikan kembali pada tahun 2016 . Namun menurut catatan tambahan di akhir posting, API layanan terus bekerja sejauh ini. Sudah ada tanggal berakhir untuk API ini berfungsi - 15 Maret 2019 . Layanan ini patut diperhatikan karena memungkinkan Anda untuk mendapatkan korespondensi email dan ID pengguna internal. Bagaimana ini bisa bermanfaat bagi kita?
Misalnya, kami adalah layanan verifikasi email . Dalam hal ini, API ini hanyalah manna dari surga bagi kami. Mengetahui ID Akun Google dari G +, kita bisa mendapatkan nama pengguna, foto, dan seringkali berbagai informasi tambahan. Pertanyaannya adalah bahwa biasanya tidak mungkin untuk mengetahui ID pengguna seseorang jika, misalnya, ia tidak masuk ke situs kami.
Namun di PicasaWebAlbums lama, orang dapat memposting foto ke album web yang terkait dengan email. Sebenarnya, ini mengikuti dari ini bahwa API lama memungkinkan Anda untuk mendapatkan profil seseorang melalui userID atau email pengguna.
Mari kita periksa:
https://picasaweb.google.com/data/feed/api/user/nosov@nodeart.io?deprecation-extension=true
- https://picasaweb.google.com/data/feed/api/user/ - sebenarnya titik akhir di mana API hidup;
- nosov@nodeart.io - email pengguna untuk memeriksa, seperti yang kita lihat, tidak harus gmail di sini. Pengguna Google Apps memiliki profil (yang membuat pemeriksaan seperti itu sangat berguna untuk pembuatan prospek), serta orang-orang yang telah membuat profil di Google+ dengan menautkannya dengan kotak surat pribadi layanan ketiga, misalnya, Yandex.ru;
- deprecation-extension = true - indikasi dari apa yang kita ketahui tentang akhir API.
Jika kami mencoba mentransfer email yang tidak ada , kami akan mendapatkan respons yang ditafsirkan dengan jelas. Tidak dapat menemukan pengguna dengan email noname@nodeart.io, yang darinya kami dapat menyimpulkan bahwa tidak ada email semacam itu. Dan bahkan lebih - jika kami mencoba mengirim alamat grup distribusi ke API , responsnya akan berubah menjadi pengguna Tidak Dikenal. Dengan cara ini, Anda dapat membedakan kotak surat pribadi di G Suite dari perusahaan pengirim surat perusahaan.
Ini bukan untuk mengatakan bahwa adalah mungkin untuk mengeluarkan informasi pribadi seseorang jika dia tidak secara eksplisit mempublikasikannya, tetapi untuk validasi massal milis API seperti itu sangat tepat
Bagaimana lubang peluang ini terkait dengan penutupan G +? Kesimpulan
Google menyebut alasan utama untuk penutupan masalah keamanan G +, atau lebih tepatnya, kemampuan layanan pihak ketiga untuk menerima informasi dari G + dengan cara yang tidak sepenuhnya dimaksudkan dan direncanakan pada awalnya oleh Google sendiri.
Sekarang, selain menutup G +, ada sebagian penutupan API yang berbeda. Misalnya, untuk mengakses gmail.api sekarang Anda harus melalui audit berbayar senilai 15 hingga 75 ribu USD , yang membuat API ini tidak dapat diakses oleh sebagian besar pengembang. Kutipan:
Biaya penilaian dibayar oleh pengembang dan dapat berkisar dari $ 15.000 hingga $ 75.000 (atau lebih) tergantung pada ukuran dan kompleksitas aplikasi.
Bahkan, ini memberi kita alasan untuk berpikir bahwa Google menjadi bingung dalam sistem interaksi antar layanan, sehingga tindakan yang dapat dilakukan sebelumnya dengan hanya mendapatkan ruang lingkup yang diinginkan sekarang memerlukan validasi manual seharga 15–75 ribu USD dan penyertaan manual dalam daftar putih Orang hanya bisa menebak apa lagi yang bisa dilakukan dengan menggunakan fitur tidak berdokumen lebih dari ekosistem kaya layanan Google dan layanan SSO pada khususnya.
Untuk memvalidasi milis secara kualitatif, kami masih perlu mencari aplikasi baru yang tidak standar dari API publik, jadi kami akan terus mempelajari Google \ Facebook API dan layanan lainnya. (Ngomong-ngomong, hingga saat ini, Facebook memiliki cara serupa untuk memvalidasi email.)