Apple to open Apple TV universal search API to third-party developers

Posted:
in iPod + iTunes + AppleTV edited October 2015
Apple CEO Tim Cook recently confirmed that developers will indeed be granted access to a universal search API set to debut with the fourth-generation Apple TV, meaning third-party apps have the opportunity to get screen time alongside big name services like HBO and Hulu.




In a follow-up to its interview with Cook published in September, Buzzfeed reports the Apple chief as saying universal search on the next-generation Apple TV will support iTunes, Netflix, Hulu, Showtime and HBO at launch, but current plans are to open the search API to developers in the near future.

"I think that many, many people will want to be in that search," Cook said. "And that's great for users. Think about your experience today. Even if you're fortunate enough to have the content you want to watch in an app, you sometimes don't remember exactly where that show is, so you're going to Netflix or Hulu or Showtime. You shouldn't have to do that. It should be very simple."

Universal search is being touted as a tentpole feature for Apple's upcoming set-top streamer. Users can type in -- or in some regions query Siri with the included Siri Remote -- search terms to surface content from a variety of sources. Being tied into a powerful search tool could be a boon for third-party developers.

Describing how universal search works, Cook said multiple results will appear if a certain show is offered on more than one service. As Buzzfeed explains, searching for a TV series or particular episode will return a rundown of all apps in which that content is available, based on a user's subscriptions. Users who pay for HBO GO and Netflix will see those two platforms show up if content is available on both.

Apple's fourth-generation Apple TV is set to debut later this month starting at $149 for a model with 32GB of onboard storage, and $199 for a 64GB version.

Comments

  • Reply 1 of 15
    fallenjtfallenjt Posts: 4,053member
    I'm ready to get 2. When will it be available?
  • Reply 2 of 15
    fallenjt wrote: »
    I'm ready to get 2. When will it be available?
    Me two!! Lol.
  • Reply 3 of 15
    asciiascii Posts: 5,936member

    A key question for me is how it works, because there's essentially two ways they could do it. 

     

    Approach One: each content provider provides a query service (e.g. over the web) which they keep up, and whenever a user issues a query, Apple sends it to these services and aggregates the results and presents them to the user. This approach has privacy issues in my opinion, because it means every time you do a search maybe 5 large corporations and 10 or 20 small ones are being informed about it.

     

    Approach Two: content providers are all required to provide Apple with a giant index of everything they have in a format Apple specifies (e.g. a 5GB mysql file using Apple's schema). Apple gets a new file once a day from each provider at e.g. midnight. Apple combines all these files in to one big index at Apple. Whenever a user does a query, it is queried against this combined database and the results are presented to the user. This approach has better privacy because only Apple knows what queries you do. Also it will be faster because there is no need to wait for all the various runtime services to return. And more reliable, because only one service (Apple's) has to be up. And easier to implement, since the database can do any aggregation/sorting for you, instead of having to mash together the output of a lot of web services yourself.

  • Reply 4 of 15
    tenlytenly Posts: 710member
    ascii wrote: »
    A key question for me is how it works, because there's essentially two ways they could do it. 
    There are a lot more than 2 ways it could be done - including a hybrid method using pieces of both approaches you've documented.
    Approach One: each content provider provides a query service (e.g. over the web) which they keep up, and whenever a user issues a query, Apple sends it to these services and aggregates the results and presents them to the user. This approach has privacy issues in my opinion, because it means every time you do a search maybe 5 large corporations and 10 or 20 small ones are being informed about it.

    If this approach were to be the one used - and I don't think it is - the privacy issue you speak of would not exist. The Siri search request would be sent to Apple and Apple would send the query out to all of the other corporations rather than sending the query parameters back to your device and have your device reach out to all of the providers directly. So - if this were the mechanism - and I'd bet it's not - there's no privacy issue to worry about.
    Approach Two: content providers are all required to provide Apple with a giant index of everything they have in a format Apple specifies (e.g. a 5GB mysql file using Apple's schema). Apple gets a new file once a day from each provider at e.g. midnight. Apple combines all these files in to one big index at Apple. Whenever a user does a query, it is queried against this combined database and the results are presented to the user. This approach has better privacy because only Apple knows what queries you do. Also it will be faster because there is no need to wait for all the various runtime services to return. And more reliable, because only one service (Apple's) has to be up. And easier to implement, since the database can do any aggregation/sorting for you, instead of having to mash together the output of a lot of web services yourself.
    The providers might be responsible for providing an index into their own content - but it's silly to think it would be updated once a day on a schedule. Much more likely would be a download to your device during initial set up and then incremental updates would be pushed when they become available - possibly once a day, possibly more frequently. I really doubt that Apple will be maintaining the index. It will be maintained on each users device since it's entirely possible that different users will have access to different subsets of content based on a subscription of some sort. We can't assume that every app will allow all users to access all possible content just because that's the way Netflix and Hulu currently operate.

    Either way - privacy should be the least of your worries. Apple has demonstrated a great deal of respect for the privacy of its customers so - it's probably safe to assume that your privacy will be protected and not ALL of the content providers will know you searched for movies with "full frontal nudity". Only Apple will know and probably only for the duration of the search. After the search result have been delivered, Apple will just save a data point that tells them that "somebody" searched for movies with "full frontal nudity" but they won't know it was you!
  • Reply 5 of 15
    asciiascii Posts: 5,936member

    Quote:

    Originally Posted by tenly View Post





    There are a lot more than 2 ways it could be done - including a hybrid method using pieces of both approaches you've documented.

     

    I'm sure there are many different ways to implement it, but I was talking about the two essential (yes, I used that word) ways to solve the problem. Content providers (1) give Apple an API or (2) give them the data. If you can think of any solution that doesn't involve one of these two I am willing to hear it.

     

    Quote:
    Originally Posted by tenly View Post



    If this approach were to be the one used - and I don't think it is - the privacy issue you speak of would not exist. The Siri search request would be sent to Apple and Apple would send the query out to all of the other corporations rather than sending the query parameters back to your device and have your device reach out to all of the providers directly. So - if this were the mechanism - and I'd bet it's not - there's no privacy issue to worry about.

     

    Yes, they could anonymise the queries, but that doesn't mean there would be no privacy issue. e.g.

     

    1. You are Google. Someone signed in to YouTube does a query for "sherlock series 2 episode 2 baskerville." A few seconds later the same query comes through your Apple TV API. Since the person was signed in to your site, you know their identity, and you now almost certainly know the identity of the Apple TV user. The same thing could happen with Amazon.

     

    2. You are Netflix. You get a query for "documentaries abot drug use" and then 3 seconds later "documentaries about drug use" (note the spelling correction). Even with all metadata scrubbed/anonymised it's almost certainly the same user.

     

    3. You are a small indy content provider who gets all these search queries from Apple. You log all the queries and keep them forever. In a few years you run in to financial difficulties and someone offers to buy the query list from you for $10,000. Little do you know they are content pirates, who use the data of what people are searching for to know exactly what to pirate, costing companies like Apple millions in lost revenue. (ok, that's not a privacy example, but it's still a good reason to use databases not APIs)

     

    Quote:

    Originally Posted by tenly View Post



    The providers might be responsible for providing an index into their own content - but it's silly to think it would be updated once a day on a schedule. Much more likely would be a download to your device during initial set up and then incremental updates would be pushed when they become available - possibly once a day, possibly more frequently. I really doubt that Apple will be maintaining the index. It will be maintained on each users device since it's entirely possible that different users will have access to different subsets of content based on a subscription of some sort. We can't assume that every app will allow all users to access all possible content just because that's the way Netflix and Hulu currently operate.

     

    Whether the content providers would provide whole new databases each day or just diffs depends on the size of the data, on whether it is worth the extra complexity of diff'ing or not. It's an implementation detail really, the essential question is whether they provide databases or APIs. As to frequency, it would have to be at least daily because new TV episodes come out daily. In the case of breaking news or live content, the content provider would have to be able to send a notification to Apple to pull the DB immediately. Maybe there could be a separate DB for any unpredictable content.

     

    I think it's highly unlikely that content indexes would be pushed to individual devices, they are space constrained enough as it is. For their own libraries maybe, but not for everything they could search for. More likely the user's subsciption details would be stored on the server, allowing query results to be filtered before they are sent to the end device.

  • Reply 6 of 15
    MacProMacPro Posts: 19,697member
    ascii wrote: »
    A key question for me is how it works, because there's essentially two ways they could do it. 

    Approach One: each content provider provides a query service (e.g. over the web) which they keep up, and whenever a user issues a query, Apple sends it to these services and aggregates the results and presents them to the user. This approach has privacy issues in my opinion, because it means every time you do a search maybe 5 large corporations and 10 or 20 small ones are being informed about it.

    Approach Two: content providers are all required to provide Apple with a giant index of everything they have in a format Apple specifies (e.g. a 5GB mysql file using Apple's schema). Apple gets a new file once a day from each provider at e.g. midnight. Apple combines all these files in to one big index at Apple. Whenever a user does a query, it is queried against this combined database and the results are presented to the user. This approach has better privacy because only Apple knows what queries you do. Also it will be faster because there is no need to wait for all the various runtime services to return. And more reliable, because only one service (Apple's) has to be up. And easier to implement, since the database can do any aggregation/sorting for you, instead of having to mash together the output of a lot of web services yourself.

    But ... but .. I thought you just asked Siri ...
  • Reply 7 of 15
    polymniapolymnia Posts: 1,080member
    ascii wrote: »
    I'm sure there are many different ways to implement it, but I was talking about the two essential (yes, I used that word) ways to solve the problem. Content providers (1) give Apple an API or (2) give them the data. If you can think of any solution that doesn't involve one of these two I am willing to hear it.


    Yes, they could anonymise the queries, but that doesn't mean there would be no privacy issue. e.g.

    1. You are Google. Someone signed in to YouTube does a query for "sherlock series 2 episode 2 baskerville." A few seconds later the same query comes through your Apple TV API. Since the person was signed in to your site, you know their identity, and you now almost certainly know the identity of the Apple TV user. The same thing could happen with Amazon.

    2. You are Netflix. You get a query for "documentaries abot drug use" and then 3 seconds later "documentaries about drug use" (note the spelling correction). Even with all metadata scrubbed/anonymised it's almost certainly the same user.

    3. You are a small indy content provider who gets all these search queries from Apple. You log all the queries and keep them forever. In a few years you run in to financial difficulties and someone offers to buy the query list from you for $10,000. Little do you know they are content pirates, who use the data of what people are searching for to know exactly what to pirate, costing companies like Apple millions in lost revenue. (ok, that's not a privacy example, but it's still a good reason to use databases not APIs)


    Whether the content providers would provide whole new databases each day or just diffs depends on the size of the data, on whether it is worth the extra complexity of diff'ing or not. It's an implementation detail really, the essential question is whether they provide databases or APIs. As to frequency, it would have to be at least daily because new TV episodes come out daily. In the case of breaking news or live content, the content provider would have to be able to send a notification to Apple to pull the DB immediately. Maybe there could be a separate DB for any unpredictable content.

    I think it's highly unlikely that content indexes would be pushed to individual devices, they are space constrained enough as it is. For their own libraries maybe, but not for everything they could search for. More likely the user's subsciption details would be stored on the server, allowing query results to be filtered before they are sent to the end device.

    OMG, boring! ????
  • Reply 8 of 15
    stuffestuffe Posts: 394member
  • Reply 9 of 15
    I have been using the free TV and Movie search service [URL=http://canistream.it]Canistream.it[/URL] and it's great because it includes Amazon.com, iTunes, Netflix, Hulu and many more. I am disappointed that Apple TV does not provide access to my Amazon.com video content.
  • Reply 10 of 15
    vfx2k4vfx2k4 Posts: 43member

    Bet Jeff Bezos is feeling like a d!ck now... Oh wait he doesn't have the capability to actually feel anything, so probably not. 

  • Reply 11 of 15
    jbdragonjbdragon Posts: 2,297member
    This sounds great. Like universal search working with PLEX!!!. Say someone in my household looking for a new movie, I already got it on disc and rooted it and put it in my Nas, now instead of some family member renting a copy of that same movie on iTunes or whatever, they would see there is also a copy in PLEX already!
  • Reply 12 of 15

    'Shipping in October'

     

    Why is there a delay? They have already sent out review models. What is the delay?

  • Reply 13 of 15
    fastasleepfastasleep Posts: 6,397member



    Quote:


    Originally Posted by AppleZilla View Post

     

    'Shipping in October'

     

    Why is there a delay? They have already sent out review models. What is the delay?


     

    It's still October.

  • Reply 14 of 15
    tenlytenly Posts: 710member
    ascii wrote: »
    Yes, they could anonymise the queries, but that doesn't mean there would be no privacy issue. e.g.

    1. You are Google. Someone signed in to YouTube does a query for "sherlock series 2 episode 2 baskerville." A few seconds later the same query comes through your Apple TV API. Since the person was signed in to your site, you know their identity, and you now almost certainly know the identity of the Apple TV user. The same thing could happen with Amazon.

    2. You are Netflix. You get a query for "documentaries abot drug use" and then 3 seconds later "documentaries about drug use" (note the spelling correction). Even with all metadata scrubbed/anonymised it's almost certainly the same user.

    3. You are a small indy content provider who gets all these search queries from Apple. You log all the queries and keep them forever. In a few years you run in to financial difficulties and someone offers to buy the query list from you for $10,000.

    Where is the privacy issue? Are you assuming that each user is assigned a static, never changing randomized (anonymized) token that links them to their device? That would defeat the purpose of anonymize for to start with...so it's safe to assume that all queries from Apple will be issued with a brand new random token or the exact same random token - but certainly not a random token that is always the same per Apple TV. Thus, there is nothing to learn for the content providers.
    I see no personal information in your examples that the content provider gets via the search - that they wouldn't get without the search.
    In your examples, all of the content providers would get an incoming search query from Apple. Only the content provider that eventually serves you the content has any hope at all of ever tying you specifically to that one search - but that does nothing to help identify who the future searches are coming from! And with or without the search, the content provider that eventually serves up your content already gets to know who you are, what you're watching and what kind of device you have - so where is the privacy issue? Right. There isn't one! For there to be a privacy issue, then someone has to gain "personally identifiable information" about you that they would not have been able to get without the Siri universal search. It doesn't matter if they all get to see what everyone is searching for. That would let them build up their database, but if they can't tie tie each piece of data back to an individual, identifiable person, it's not a privacy issue. Companies may be able to build a much bigger database that shows them what people (as a group) are searching for, but that doesn't violate anybody's privacy - and it doesn't give them any kind of competitive advantage in the marketplace since all of the other content providers will have access to the same database.... So... Where is the privacy issue?

    As for your first question about naming a mechanism which doesn't involve providing an API to Apple or sending a database to Apple, just swap Apple with "the user" and you've immediately got 2 new options.

    I still don't think we'll see Apple "pulling" databases nightly from providers. I'm not going to claim to be smart enough to devise the "best" approach for this - but I am smart enough to know that it won't be either one of your approaches as is. It won't be your first approach on any way, shape or form. It might be something that vaguely resembles your second suggestion but with significant variations that neither you nor I have thought of but which are required to deliver this type of service at the speed and scale they will need to. It will start with a distributed database of content is about all we can safely say for now. Oh - and the service will be provided without compromising our privacy!
Sign In or Register to comment.