Hi Paul,
I feel like we are talking past each other :( In the first email you sent, you
said: "This email is to start discussion around exposing APIs to web content -
i.e. hosted apps and regular websites."
What I'm trying to explain below is that, because of our market position on
mobile (i.e, <1%), one can't "expose APIs to web content" without first going
through a standardization process. Additionally, one can't just "add web
concepts to these APIs" and then expose them to the Web either. That's not how
the web platform works: or how we build the web platform.
There are, for better or for worst, gate keepers that try to keep the platform
sane (and self-correcting market forces, like developers not using an API,
other browser vendors ignoring an API, and sites like caniuse.com or even our
own MDN, which clearly marks things as "non-standard" with big red boxes, that
also intervene precisely to prevent unrestricted extensions to the platform):
Building the platform requires collaboration with other stake-holders: in
particular, with other browser vendors that are also willing to implement the
same APIs.
A company, like Mozilla, Google, Microsoft, could (and have) add whatever to
"navigator" or "window", but that doesn't necessarily make it part of the Web
platform (and in fact, harms the platform, and our credibility, in the
process). What makes something part of the web platform is getting agreement
from the other browsers to also implement stuff.
This can happen in two ways:
1) by [market] force (having a lot of browser market share, large sites making
use of feature, making the browser "broken" in the eyes of users),
2) or, by collaboration (e.g., our collaboration with Google on service
workers).
(Sometimes abusing 1 to achieve 2, again Service Workers as an example.)
We don't have 1 on mobile right now (say, compared to Safari on iOS or Chrome
on Android) - so that only leaves us with 2. Building technology that works
cross browser is the most value the Web brings (economies of scale). If we shun
that (or don't see that), then we are unlikely to succeed.
More below...
On Monday, February 16, 2015 at 9:55:50 PM UTC+10, Paul Theriault wrote:
> On 16 Feb 2015, at 10:07 pm, Marcos Caceres wrote:
> >> - contacts
> >
> > There have been various attempts to do contacts - but they got caught up on
> > the whole web intents thing. I think we should redo contacts, and do it
> > right. In particular, something that allows something as simple as:
> >
> > <input type="contact">
> >
> > Alternatively, we could be smarter about, for instance, <input type="tel">
> > or the like, and allow the user to select values from their contacts. There
> > may be other reusable things in HTML.
>
> So we already have a contact pick web activity which solves the use case that
> <input type="contact"> would solve.
Sorry, I think you've missed my point: the above ("pick web activity") is not
compatible with the Web. That is, if I can't use it, and won't be able to use
it in the future, with IE, Safari, and Chrome, and/or even Firefox desktop(!),
then it's not part of the Web. So this (reliance on web activities) is far from
solving the problem in any meaningful and scalable way.
If on the other hand there was a concrete proposal on the table, and agreement
amongst a handful of browsers to implement web activities and contacts, then
that would make this worthwhile, scalable, and meaningful to the Web at large
(and to fxos).
>Thats not really the issue here. What deviceStorage & contacts use cases all
>come back to is some kind of global store which multiple apps can talk to.
>
I'm sorry but, no. That's a (fxos) solution looking for a problem - because the
need for the global store might be symptomatic of the architectural decisions
of FxOS. That might be the ultimate solution, even the right solution - but we
are not there yet.
> I was going to suggest adding web concepts to these APIs - e.g. make them
> respect same-origin, i.e. an web page storing/reading photos can only see its
> own photos. But it occurred to me that this use case is already solved via
> indexeddb. The missing part is allowing sharing these resources between
> origins.
>
I know you are not proposing exactly this, but "adding web concepts to these
APIs" is not the right solution because it still keeps this things as FxOS
only: and that means other browser vendors are unlikely to implement them
(irrespective of them being "webby") - and then developers can't use them
outside the FxOS ecosystem (which is comparably tiny when compared to, say,
targeting Safari and Chrome on mobile). Again, the right solution would be
getting agreement amongst browser vendors to create a standard for whatever use
case we have.
However, if this is just going to be for internal use, then adding web concepts
doesn't matter. All that matters is that these APIs work well (for us - not Web
developers) and remain inaccessible to the Web, because they will just be used
internally.
> >
> >> - SystemXHR (hard to imagine this being exposed to the web)
> >
> > CORS enables SystemXHR-like capabilities on the Web. That's already a
> > solved problem.
>
> If its solved, then when why do so many Gaia apps request this permission?
AFAICT, because we were too scared to actually tell developers to do the right
thing (use/rely on CORS) :(
>(I suspect the answer is that writing an app like an RSS reader requires
>systemXHR because the endpoints are CORS enabled but we should investigate).
Yes, exactly! And that's the point. SystemXHR is a flagrant violation of the
server/client model and the same origin security policy that browsers have
worked hard to establish. Basically, we are breaking the trust model/contract
that servers have with web browsers by allowing arbitrary apps to fetch content
they would not normally have access to - and we were trying to do that on
scale. That's a bad thing.
What we should have done is actually force developers to work within the
constraints of the Web platform (i.e., "you want to access site X, then talk to
site X and get them to enable CORS - and to enable it for your app.").
> For example, I believe the calendar app uses SystemXHR to retrieve calendar
> information via caldav over XHR?
>
That's fine, that's a "system app". But we shouldn't expect normal web apps to
use systemxhr. I know you are not proposing this, but I'm just sayin'.
> Same sort of questions will come up for tcp-socket & udp-socket, which are
> basically the same thing. (unrestricted network access I mean)
>
Yes, but *what* are those apps actually trying to do? And why is there no
alternative way of doing it over, for example, Web Sockets?
If its for things like printers, then those are squarely in the "system app"
domain (e.g., how I just hit print in Firefox for Desktop, and my printers just
comes up from the underlying OS - web apps themselves don't need direct access
to printers).
> >
> >> - Camera: expose Camera API? Or add features to getUserMedia (latter seems
> >> more likely, but are their hardware risks/limitations)
> >
> > Agree. How is basic support for things like?:
> > <input type="file" accept="image/*;capture=camera">
> >
> > I see it's not supported on Firefox Desktop, for instance. Is it supported
> > on mobile or FxOS?
> >
> > I'm told that WebRTC now allows for high-quality media.
>
> I'm talking about device specific features like focus control, flash and
> other device specifics.
So am I? These are all valid use cases for getUserMedia(). As Web Audio is
supposed to explain audio on the Web, so is getUserMedia() supposed to explain
media capture. As the document clearly states: "This document defines a set of
JavaScript APIs that allow local media, including audio and video, to be
requested from a platform."
If the functionality is missing to control zoom, focus, etc. then we should ask
for it. But adding our own thing without proposing it back for standardization
would be counter-productive.
> I'm not clear on the details and I wonder if there are fingerprinting risks
> here or potentially other risks (e.g. exploiting bugs in camera drivers?)
>
Probably, but that's all part of the fun of solving these problems
collaboratively with hardware manufactures, privacy folks, other browser
vendors, developers, etc. within a standardization context.
> >
> >> - Mobile Connection API is another popular one, but this is very dangerous.
> >
> > Have you taken a look at:
> > http://w3c.github.io/netinfo/
>
> I'm familiar with this API but its very different to mobile connection
> (https://developer.mozilla.org/en-US/docs/Web/API/MozMobileConnection)
>
Sure, but almost all the use cases for that API are not relevant to web apps
(in as far as they enable the functionality - but as far as the web app is
concerned, that could just be a black box written in C++ or Rust).
> >
> > What's dangerous about it?
>
> Amongst other things:
> - allows sending MMI messages (commonly used for recharging pre-paid devices,
> subscribing to services, checking balance information, factory reset messages
> etc)
> - retrieve the carrier and country codes related to the sim card
> - choose which mobile network you want to use
Sorry, I was talking about my NetInfo API :) I was asking what's so dangerous
about my API (which was designed to work within the web)? I know what's so
dangerous about the Moz one.
> >
> >> Maybe we could look at exposing more of the read-only attributes through
> >> the mobile-network permission but it has similar privacy implications to
> >> geolocation, only more difficult to explain to the user.
> >
> > Then we can move to only enabling them through TLS, for instance. What use
> > case are we trying to address exactly? Are any of the use cases not covered
> > here:
> >
> > http://w3c-webmob.github.io/netinfo-usecases/
>
> So they are separate use cases really. There is some read only information in
> MobileConnection that could possibly be more to something more like netinfo,
> but its a lot more sensitive that what netinfo currently exposes.
Of course, because there is 0 use case to exposing the mozNetworkInfo API to
the Web.
> I'm not convinced its a priority use case though. At least not as much as the
> other ones above in this email. I only mentioned it since a lot of apps use
> it and I was curious what they use cases where.
>
> I'll do some digging for use cases in Gaia for all these APIs and then maybe
> start some separate threads to dive more specifically into these APIs.
I would urge you to go with Ben's suggestion: investigate which system apps
could actually become actual web apps - and what apps are needed as services
provided by the OS to web apps (e.g., access to printing, an application for
sending an SMS, a default mail application, a default camara application). Note
I don't say "web application" - just "application" or "core service", as other
operating systems provide.
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
