Google დეტალებს SDK Runtime დიზაინის წინადადებას Android Privacy Sandbox-ისთვის

Google-მა გააცნო რამდენიმე დეტალი SDK Runtime დიზაინის წინადადების შესახებ. SDK Runtime შეადგენს Android Privacy Sandbox-ის ნაწილს.

ცოტა ხნის წინ, ჩვენ ვნახეთ, რომ Apple-იც და Google-იც ცდილობენ შექმნან უფრო კონფიდენციალურობის დაცვასთან დაკავშირებული ეკოსისტემა, როდესაც საქმე რეკლამას ეხება. Apple-თან ერთად, ეს იყო ღილაკის შემოღება, რომელიც ხელს უშლის აპებს თქვენს თვალყურის დევნებას, ხოლო Google-თან ერთად, ეს იყო Android Privacy Sandbox ინიციატივა. მიუხედავად იმისა, რომ ინფორმაცია მწირი იყო მისი განცხადების დროს, უფრო მეტი დეტალი გაჩნდა "SDK Runtime"-ს შესახებ, რომელიც მოიცავს Google-ის რეკლამისა და კონფიდენციალურობის გადაწყვეტის ნაწილს.

Android Privacy Sandbox შედგება ორი ძირითადი კომპონენტისგან - SDK Runtime და კონფიდენციალურობის შენარჩუნების API-ები - რომლებიც განაწილდება მოდულური სისტემის კომპონენტების სახით, რომლებიც შეიძლება გახსოვთ, როგორც პროექტის მთავარი ხაზი. მას შემდეგ Google-მა გამოაქვეყნა დეველოპერის დოკუმენტაცია SDK Runtime-ის შესახებ და როგორ გააძლიერებს ის მომხმარებლის კონფიდენციალურობას. კომპანია ამბობს, რომ SDK Runtime საშუალებას მისცემს მესამე მხარის SDK-ებს იმუშაონ სპეციალურ გაშვების გარემოში

Android 13აპლიკაციის კოდისგან მოშორებით.

Android-ში, თითოეული აპი მუშაობს ქვიშის ყუთში საკუთარი ნებართვით და განსხვავებული წვდომით სისტემაზე, მინიჭებული წვდომის მიხედვით. როგორც გუგლი ამბობს, "თუ აპი A ცდილობს რაიმე მავნე მოქმედებას, მაგალითად, წაიკითხოს B აპლიკაციის მონაცემები ან აკრიფოს ტელეფონი ნებართვის გარეშე, მას არ შეუძლია ამის გაკეთება, რადგან მას არ აქვს შესაბამისი ნაგულისხმევი მომხმარებლის პრივილეგიები." SDK Runtime კიდევ უფრო აფართოებს ამ სავარჯიშო ყუთს მესამე მხარის SDK-ების შესასრულებლად სპეციალურ გაშვებულ გარემოში, რომელიმე კონკრეტულისგან დაშორებით. აპლიკაცია.

რატომ არსებობს SDK Runtime

Google-ს სურს აღკვეთოს რეკლამის განმთავსებლების SDK-ები იმ მონაცემების შეგროვებაში, რომლებზეც მას არ უნდა ჰქონდეს წვდომა მავნე (ან თუნდაც უნებლიედ) მასპინძელი აპლიკაციის sandbox-ის გაზიარების შედეგად. როდესაც სარეკლამო SDK შესრულებულია აპის შიგნით, მას აქვს წვდომა ყველაფერზე, რასაც აპი აკეთებს და აპლიკაციის შემქმნელმა შეიძლება ბოლომდე არ იცოდეს, რამდენად დიდია ეს წვდომა. რეკლამის განმთავსებლის კოდის წაშლით და მისი შესრულების დროს, მას შეუძლია მხოლოდ იმ მონაცემებზე წვდომა, რომლებსაც დეველოპერი აშკარად უზიარებს მას.

შედეგად, Google ამბობს, რომ SDK Runtime უზრუნველყოფს შემდეგ უფრო ძლიერ დაცვას და გარანტიებს მომხმარებლის მონაცემების შეგროვებისა და გაზიარების შესახებ:

  • შეცვლილი აღსრულების გარემო
  • კარგად განსაზღვრული ნებართვები და მონაცემთა წვდომის უფლებები SDK-ებისთვის

SDK Runtime-ის პირველი ვერსია ფოკუსირებულია მხოლოდ რეკლამასთან დაკავშირებულ SDK-ებზე, მათ შორის SDK-ებზე, რომლებიც იძლევა რეკლამის განთავსებას, რეკლამების გაზომვას, რეკლამების თაღლითობას და ბოროტად გამოყენების გამოვლენას.

როგორ მუშაობს SDK Runtime

ამჟამად, SDK გაშვების გარეშე, აპლიკაციის პროცესი გამოიძახებს SDK-ს და ეს SDK შესრულდება იმავე sandbox-ში, როგორც აპლიკაციის დანარჩენი კოდი. Google-ს სურს, რომ დეველოპერებს ჰქონდეთ ინტერფეისი SDK-სთვის, რომელიც მუშაობს აპის წინა პლანზე, და ამ ინტერფეისს შეუძლია შემდეგ დაუკავშირდეს და გაუზიაროს კონკრეტული მონაცემები SDK-ს, რომელიც არსებობს გამოყენებული.

მანამდე

შემდეგ

"ადრე" დიაგრამა (პირველი) გვიჩვენებს, რომ SDK-დარეკვის კოდი, SDK-ებთან ერთად, რომლებიც იღებენ ზარებს ამ კოდიდან, ყველა მდებარეობს აპის პროცესში. ეს ნიშნავს, რომ SDK-ს შეუძლია წვდომა ყველა მონაცემზე, რაც აპს შეუძლია. "შემდეგ" დიაგრამა (მეორე) აჩვენებს, რომ აპლიკაციის წინა პლანზე პროცესში, SDK დარეკვის კოდი ურთიერთობს SDK ინტერფეისებთან. შემდეგ ეს ინტერფეისები კვეთენ პროცესის საზღვარს SDK Runtime პროცესში, რათა გამოიძახონ თავად SDK-ებში. ეს ნიშნავს, რომ გამოყენებული SDK-ს არ შეუძლია წვდომა მხოლოდ იმაზე, რაც მას სურს, მას შეუძლია მხოლოდ ინფორმაციის მიწოდება აპლიკაციიდან, რომელსაც ის მუშაობს.

ახალი სანდო განაწილების მოდელი SDK-ებისთვის

ამჟამად, როდესაც ჩამოტვირთავთ აპლიკაციას მესამე მხარის SDK-ებით, დეველოპერის მიერ ისინი შედის აპში, რომელიც ატვირთული და განაწილებულია Google Play Store-ში. სანაცვლოდ, Google-ს სურს, რომ როდესაც თქვენს ტელეფონზე დააინსტალირებთ აპს, რომელიც იყენებს ამ SDK-ებს, ისინი ჩამოიტვირთება ცალკე თავად აპლიკაციიდან. ეს ნიშნავს, რომ SDK-ის დეველოპერებს შეეძლოთ შეუცვლელი ცვლილებების შეტანა (ანუ არავითარი ცვლილება API-ებში ან მათი სემანტიკა) მათ SDK-ებზე და გაავრცელეთ ისინი მოწყობილობებზე აპლიკაციის ყოველგვარი ჩარევის გარეშე დეველოპერები.

თავის მხრივ, შეუფერხებელი SDK ცვლილებები შეიძლება განთავსდეს ან უკან დაბრუნდეს, ლოდინის საჭიროების გარეშე აპლიკაციების შემქმნელებმა განაახლონ თავიანთი აპები ახალი SDK-ებით, ან დაელოდონ საბოლოო მომხმარებლების განახლებას აპლიკაციები. ცვლილებების შეწყვეტა, რომელიც ცვლის API-ებს და მათ სემანტიკას, კვლავ უნდა განახლდეს აპლიკაციის დეველოპერების მიერ, მაგრამ SDK დეველოპერებს შეუძლიათ მიიღონ მათი უახლესი არა-დარღვევა ცვლის და ასწორებს უფრო სწრაფად და ერთგვაროვნად ერთდროულად მეტ ადამიანს, აპლიკაციის შემქმნელზე დაყრდნობის გარეშე, რათა განაახლოს მათი აპლიკაცია და პაკეტი ახალში SDK.

მანამდე

შემდეგ

"ადრე" დიაგრამა აჩვენებს ზუსტად როგორ ნაწილდება აპლიკაციები ახლა SDK-ებით. ისინი შეფუთულია აპში და აპი არის ის, რაც წარდგენილია Google Play Store-ში. "შემდეგ" დიაგრამაში, SDK დეველოპერები აღარ განათავსებენ თავიანთ SDK-ებს პირდაპირ აპებში; ამის ნაცვლად, SDK დეველოპერები ატვირთავდნენ SDK-ს და გამოაქვეყნებდნენ Google Play Store-ში. შემდეგ Google Play Store განახორციელებს აპების განაწილებას, SDK-ის ნებისმიერ დამოკიდებულებასთან ერთად, საბოლოო მომხმარებლის მოწყობილობებზე. Google ასევე განზრახ იყენებს ფრაზას "აპლიკაციების მაღაზია" თავის დიაგრამებში, რადგან ეს არის ღია და ზოგადი გადაწყვეტა, რომელსაც შეუძლია იმუშაოს სხვა მაღაზიებში.

ცვლილებები SDK-ების და აპების აგების, გაშვებისა და განაწილების შესახებ

SDK Runtime-ის თავდაპირველი წინადადება გვთავაზობს ცვლილებების სერიას ხუთ ძირითად სფეროში:

  • წვდომა
  • აღსრულება
  • კომუნიკაციები
  • განვითარება
  • დისტრიბუცია

Google-ს სურს განსაზღვროს შემდეგი ნებართვების ნაკრები SDK Runtime-ისთვის:

  • INTERNET: წვდომა ინტერნეტზე, რათა შეძლოთ ვებ სერვისთან კომუნიკაცია.
  • ACCESS_NETWORK_STATE: ქსელების შესახებ ინფორმაციის წვდომა.
  • წვდომის ნებართვები კონფიდენციალურობის შენარჩუნების API-ები, რომლებიც უზრუნველყოფენ სარეკლამო ძირითად შესაძლებლობებს აპების ჯვარედინი იდენტიფიკატორებზე წვდომის გარეშე. ნებართვების სახელები არ არის დასრულებული, მაგრამ ეს API-ები შეიზღუდება აპის მიერ ამ ნებართვებზე წვდომით.
  • AD_ID: სარეკლამო ID-ის მოთხოვნის შესაძლებლობა. ეს ასევე შეიზღუდება აპის წვდომით ამ ნებართვაზე.
  • BIND_GET_INSTALL_REFERRER_SERVICE: გამოყენების შესაძლებლობა Google Play Install Referrer API აპლიკაციის ინსტალაციის წყაროს მიკუთვნება.

კომპანიას ასევე სურს შეზღუდოს წვდომა, რომელიც SDK-ებს აქვთ გაშვებული აპლიკაციის მეხსიერებაზე, მაგრამ ასევე, თავიდან აიცილოს აპს წვდომა SDK-ის საკუთარ მონაცემებზეც. აპს არ ექნება პირდაპირი წვდომა მის SDK-ების მეხსიერებაზე და პირიქით, გარე მეხსიერება არ იქნება ღიაა SDK-ებისთვის და იქნება როგორც საცავი ხელმისაწვდომი ყველა SDK-სთვის, ასევე საცავი, რომელიც პირადია მოცემულისთვის SDK.

რაც შეეხება იმას, თუ როგორ იმუშავებს SDK-ები, ისინი იმუშავებენ ოდნავ დაბალი პრიორიტეტით, ვიდრე თავად აპლიკაცია. ეს ნიშნავს, რომ ძალიან სავარაუდოა, რომ აპლიკაცია შეწყდება SDK Runtime-ის შეწყვეტის შემდეგ მალევე, თუ შეიქმნება სიტუაცია, რომ ის სისტემამ უნდა დაიხუროს. იმ შემთხვევაში, თუ იგი ერთდროულად არ წყდება, ან თუ არსებობს სხვა მიზეზი, წინადადება აპლიკაციის დეველოპერებს სთავაზობს სასიცოცხლო ციკლის გამოძახების შესაბამის მეთოდებს, რათა გაუმკლავდნენ ამ გამონაკლისს და განაახლონ SDK გაშვების დრო. Runtime SDK-ები ვერ შეძლებენ შეტყობინებების API-ების გამოყენებას მომხმარებლის შეტყობინებების გასაგზავნად დროის ნებისმიერ მომენტში.

და ბოლოს, Google აღნიშნავს, რომ ეს არის ზოგადი წინადადება, რომელიც არ არის უნიკალური რომელიმე კონკრეტული აპლიკაციის მაღაზიისთვის. მიუხედავად იმისა, რომ ის სავარაუდოდ აშენდება Google Play Store-ში, არ არსებობს მიზეზი, რის გამოც სხვა აპლიკაციების მაღაზიებს არ შეეძლოთ მსგავსი სტრუქტურის გაერთიანება. Google ამბობს, რომ შემდეგი სარგებელი ნათელია:

  • უზრუნველყოს SDK-ების ხარისხი და თანმიმდევრულობა.
  • SDK დეველოპერებისთვის პუბლიკაციის გამარტივება.
  • დააჩქარეთ SDK-ის მცირე ვერსიების განახლებების დაყენება დაინსტალირებული აპებისთვის.

Android Privacy Sandbox პერსპექტიულად გამოიყურება

Google-ის გამოშვების ვადები არის ის, რომ 2022 წლის 1-ლი კვარტალში შედის დიზაინის საწყისი წინადადებები და დიზაინის გამოხმაურება და გამეორებები. დეველოპერების გადახედვები გამოვა წლის ბოლოს, ბეტა წლის ბოლოს. საბოლოოდ, 2023 წელს დაიწყება მასშტაბური ტესტირება. ეს გადახედვები და ბეტაები დამოუკიდებელი იქნება Android 13-ის გამოშვების კადენციისგან. პარამეტრების აპში ასევე იქნება მომხმარებლის წინაშე მდგარი კონტროლი, როგორც კი ამოქმედდება.

ჩემი აზრით, Android Privacy Sandbox გამოიყურება პერსპექტიული, მაგრამ ჩვენ უნდა დაველოდოთ და ვნახოთ, როგორ განახორციელებს კომპანია მას. სავსებით შესაძლებელია, რომ დეველოპერებს ეს არ მოეწონოთ, ან რეალურად უფრო მეტი პრობლემა გამოიწვიოს, ვიდრე აგვარებს. დეველოპერებს ურჩევენ, წაიკითხონ Google-ის მიერ გამოქვეყნებული დოკუმენტაცია, რათა უკეთ გაეცნონ მომავალს Android-ის კონფიდენციალურობის შესახებ.

ეს არის ამჟამად წინადადება და არა საბოლოო პერსპექტივა რა ზუსტად მოხდება Android-ის მომავალ ვერსიაში, მაგრამ სავარაუდოა, რომ ის საკმაოდ ახლოს იქნება. ჩვენ თვალს ვადევნებთ შემდგომ განვითარებას!


წყარო: Android დეველოპერის დოკუმენტაცია