Google blocks Windows Phone YouTube app again, for “manufactured” reasons • Hacker News Board

Re: Google blocks Windows Phone YouTube app again, for “manufactured” reasons

#51

Post by 4thjuly » Fri, Aug 16, 2013, 4:34 PM UTC

ksk wrote: post #48

4thjuly wrote: post #17

Earlier quoted context omitted.

Exactly, Microsoft already does something similar by reserving some of their APIs for their own use. There are others that are available to some (eg the carriers) but nobody else. It's nothing new, they have had so-called 'private' APIs since the early days of Windows.

>It's nothing new, they have had so-called 'private' APIs since the early days of Windows Point to a single "private" API. There is no such thing. Preemptive apologies if you're a non technical person as these things are obvious to most programmers so I don't really want to berate anyone for simply not having sufficient information.

For recent examples I was thinking specifically about the Windows.Networking.NetworkOperators APIs and such. These APIs are 'private' to network operators. If you try to use them from a regular app then you'll be kicked out of the store.

Or search msdn for "This API is not intended to be used directly from your code" for examples of other APIs that are 'private' to Microsoft and will similarly get you booted.

Going back in time, there were (still are) a great many dlls and services in Windows with unnamed exports and not available to the general public (eg win32k, csrss, milcore etc).

Go back to the dark ages and as others have already mentioned there's the famous AARD example that used undocumented DOS data structures to distinguish MS-DOS from other variants.

Like I said, nothing new.

Re: Google blocks Windows Phone YouTube app again, for “manufactured” reasons

#52

Post by cantankerous » Fri, Aug 16, 2013, 4:44 PM UTC

nknighthb wrote: post #15

cantankerous wrote: post #12

Earlier quoted context omitted.

The rules are arbitrary if Google doesn't abide by them when making publishing its own versions of YouTube apps on the dominant platforms. It's behavior is anti-competitive if it uses its position as gatekeeper to YouTube to stifle Windows Phone by placing requirements on Microsoft that it doesn't place on itself.

The rule exists to ensure the continued compatibility of third-party applications with requirements of the YouTube service. Google can fix its own apps, and it can fix the content of an iframe loaded from its servers, but it can't fix apps it doesn't control. There are good reasons for this very simple rule that everyone but Microsoft seems able to comply with. By definition, such a rule cannot be "arbitrary".

It's disingenuous to say "everybody but Microsoft" when the group size of third-party apps that act as realistic YouTube viewers is something like 2-4.

If you pride yourself and market yourself on openness any rule that flies in the face of said openness is entirely arbitrary, because there shouldn't be any rules limiting your openness.

Re: Google blocks Windows Phone YouTube app again, for “manufactured” reasons

#53

Post by ksk » Fri, Aug 16, 2013, 5:50 PM UTC

4thjuly wrote: post #51

ksk wrote: post #48

Earlier quoted context omitted.

>It's nothing new, they have had so-called 'private' APIs since the early days of Windows Point to a single "private" API. There is no such thing. Preemptive apologies if you're a non technical person as these things are obvious to most programmers so I don't really want to berate anyone for simply not having sufficient information.

For recent examples I was thinking specifically about the Windows.Networking.NetworkOperators APIs and such. These APIs are 'private' to network operators. If you try to use them from a regular app then you'll be kicked out of the store. Or search msdn for "This API is not intended to be used directly from your code" for examples of other APIs that are 'private' to Microsoft and will similarly get you booted. Going b…

>If you try to use them from a regular app then you'll be kicked out of the store.

Um.. That is not a private API. Those are the terms of the STORE, not the OS. You can use the API from whatever app you want. Although as a programmer I personally dislike such restrictions, its no different from what Google or Apple are doing for their own stores.

>Going back in time, there were (still are) a great many dlls and services in Windows with unnamed exports and not available to the general public (eg win32k, csrss, milcore etc)

What the... What are you talking about? Those DLLs are internal OS DLLs. Nobody besides OS components has any use for those APIs.

>Go back to the dark ages and as others have already mentioned there's the famous AARD example

Which never shipped since it was part of a windows beta version.

>Like I said, nothing new.

You can say anything you want ofcource. You'll have to bring actual evidence if you want to be taken seriously though.

Re: Google blocks Windows Phone YouTube app again, for “manufactured” reasons

#54

Post by nknighthb » Fri, Aug 16, 2013, 6:49 PM UTC

cantankerous wrote: post #52

nknighthb wrote: post #15

Earlier quoted context omitted.

The rule exists to ensure the continued compatibility of third-party applications with requirements of the YouTube service. Google can fix its own apps, and it can fix the content of an iframe loaded from its servers, but it can't fix apps it doesn't control. There are good reasons for this very simple rule that everyone but Microsoft seems able to comply with. By definition, such a rule cannot be "arbitrary".

It's disingenuous to say "everybody but Microsoft" when the group size of third-party apps that act as realistic YouTube viewers is something like 2-4. If you pride yourself and market yourself on openness any rule that flies in the face of said openness is entirely arbitrary, because there shouldn't be any rules limiting your openness.

It's disingenuous to treat your religious dogma on the word "open" as shared by everyone else. I don't believe for a second you understand how Google is using the term nor what they are applying it to.

Re: Google blocks Windows Phone YouTube app again, for “manufactured” reasons

#55

Post by 4thjuly » Fri, Aug 16, 2013, 7:07 PM UTC

ksk wrote: post #53

4thjuly wrote: post #51

Earlier quoted context omitted.

For recent examples I was thinking specifically about the Windows.Networking.NetworkOperators APIs and such. These APIs are 'private' to network operators. If you try to use them from a regular app then you'll be kicked out of the store. Or search msdn for "This API is not intended to be used directly from your code" for examples of other APIs that are 'private' to Microsoft and will similarly get you booted. Going b…

>If you try to use them from a regular app then you'll be kicked out of the store. Um.. That is not a private API. Those are the terms of the STORE , not the OS. You can use the API from whatever app you want. Although as a programmer I personally dislike such restrictions, its no different from what Google or Apple are doing for their own stores. >Going back in time, there were (still are) a great many dlls and serv…

That's why I put 'private' in quotes. Given a decent debugger, nothing is strictly private but then it's a meaningless distinction. Perhaps there's a better term for APIs you can technically call but will get your app kicked out of the store for TOS violation? I think 'private' makes sense but I'm happy to use whatever term you think is reasonable.

As for 'internal OS DLLs' I think it's subjective as to whether those APIs have any use outside of OS components (and indeed what constitutes an 'OS component'). I happen to think there's some really useful stuff in there. Anyway, I only brought it up to highlight that there are some things Microsoft has decided we can't use for whatever reason. Again, I think it's reasonable to consider them 'private', non-public, internal. I'm not saying any of this is good\bad or that they shouldn't have the right to do this sort of thing. Just that it exists.

As for AARD, technically it did 'ship' as the code was included in Win3.1 but was benign thanks to a runtime flag. Even in beta form it highlights that this sort of thing, relying on undocumented behavior, has been used at Microsoft for a very long time. Perhaps it's an insignificant example but it did cost them close to $300M in a settlement so seemed pretty relevant to me.

Anyway, I shall leave it to other readers to decide if any of this constitutes evidence of so-called private APIs by Microsoft.

Thanks.

Re: Google blocks Windows Phone YouTube app again, for “manufactured” reasons

#56

Post by ksk » Fri, Aug 16, 2013, 7:53 PM UTC

4thjuly wrote: post #55

ksk wrote: post #53

Earlier quoted context omitted.

>If you try to use them from a regular app then you'll be kicked out of the store. Um.. That is not a private API. Those are the terms of the STORE , not the OS. You can use the API from whatever app you want. Although as a programmer I personally dislike such restrictions, its no different from what Google or Apple are doing for their own stores. >Going back in time, there were (still are) a great many dlls and serv…

That's why I put 'private' in quotes. Given a decent debugger, nothing is strictly private but then it's a meaningless distinction. Perhaps there's a better term for APIs you can technically call but will get your app kicked out of the store for TOS violation? I think 'private' makes sense but I'm happy to use whatever term you think is reasonable. As for 'internal OS DLLs' I think it's subjective as to whether those…

>Perhaps there's a better term for APIs you can technically call but will get your app kicked out of the store for TOS violation?

So, first you make a claim about "since the early days of windows" OS APIs useful to others have been hidden that apparently only MS applications get to use. Yet you have failed to point out a single shipping microsoft application that benefited from those APIs or even actually mentioned what those APIs are or what they do. And now you're talking about some fringe windows 8 RT app store restrictions. Windows history spans from 1985 to 2013. Surely you should have hundreds of thousands of examples that you can google?

> Anyway, I only brought it up to highlight that there are some things Microsoft has decided we can't use for whatever reason.

Sorry. I still have no clue what are you talking about. Internal OS DLLs contain the implementation of the OS itself. Applications run on TOP of the OS. They don't re-invent what the OS already does.

I strongly suspect you're attempting to construct a non-technical argument about a purely technical topic. Anyway, I doubt you're going to present any evidence.. So, goodbye.

Re: Google blocks Windows Phone YouTube app again, for “manufactured” reasons

#57

Post by DannyBee » Fri, Aug 16, 2013, 10:10 PM UTC

lmm wrote: post #46

DannyBee wrote: post #27

Earlier quoted context omitted.

Why? How is this any different than me releasing my code under something like the LGPL, which would allow those folks who dynamically link to not release source to their app, but force those who are required to statically link (due to platform or other reasons) to release source to their app? Note that it's a similar situation. If I release code under the LGPL, i don't have to abide by it, only others do. Twitter req…

It's anticompetitive because Google is using its dominant online video platform to promote its mobile OS, even though those are really two separate industries. It's no different from MS selling an internet server that uses nonstandard extensions and only making those available on windows.

This is honestly the silliest thing i've ever heard in my life.

Re: Google blocks Windows Phone YouTube app again, for “manufactured” reasons

#58

Post by deserted » Fri, Aug 16, 2013, 11:38 PM UTC

chx wrote: post #24

4thjuly wrote: post #17

Earlier quoted context omitted.

Exactly, Microsoft already does something similar by reserving some of their APIs for their own use. There are others that are available to some (eg the carriers) but nobody else. It's nothing new, they have had so-called 'private' APIs since the early days of Windows.

And Windows detected DR-DOS and crashed your computer to kill DR-DOS and MS paid a paltry $150M to Caldera later but they got to upkeep their monopoly in the PC market. Now they get a small serving of this medicine and it's far less sinister and they whine. Oh they irony.

Everyone thought it was $150M but it turned out to be $280M. Not that that makes much of a difference for Microsoft.

The agreement has been public since 2009.

http://www.groklaw.net/pdf2/NovvMS-104-8.pdf

> Microsoft also debated the exact language the message should contain. In the end, senior vice president Brad Silverberg said in a 1992 email that the message needed to steer users away from DR-DOS. "What the [user] is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is DR-DOS and then go out to buy MS-DOS," Silverberg wrote.

Re: Google blocks Windows Phone YouTube app again, for “manufactured” reasons

#59

Post by wslh » Sat, Aug 17, 2013, 5:14 PM UTC

jbk wrote: post #32

wslh wrote: post #18

Besides that this was heavily commented a few hours earlier in another thread, everyone can play YouTube videos without ads via VLC. Is VLC a YouTube application or not? Because it doesn't use HTML[5].

Yes, but this is a hidden feature :)

Sorry ;-) I only want to thank you then!