On Thursday, February 19, 2015 at 9:19:40 AM UTC+1, Anne van Kesteren wrote:
> On Wed, Feb 18, 2015 at 7:16 PM, James Burke wrote:
> > Mobile use is really large. Native mobile apps do not have
> > restrictions from these APIs.
>
> As indicated most don't need them either.
>
>
> > If web sites
On Thu, Feb 19, 2015 at 12:18 AM, Anne van Kesteren wrote:
> On Wed, Feb 18, 2015 at 7:16 PM, James Burke wrote:
>> Mobile use is really large. Native mobile apps do not have
>> restrictions from these APIs.
>
> As indicated most don't need them either.
For email, a tcpsocket-based capability is
On Wed, Feb 18, 2015 at 7:16 PM, James Burke wrote:
> Mobile use is really large. Native mobile apps do not have
> restrictions from these APIs.
As indicated most don't need them either.
> If web sites are concerned about getting
> cross domain hits, they can get them now from native apps.
The
On Wed, Feb 18, 2015 at 3:51 AM, Anne van Kesteren wrote:
> Trying to figure out how to get sockets and "systemXHR" into the
> browser has been going on for a very long time now, I think we should
> start embracing that it's unlikely to happen and look elsewhere.
The "look elsewhere" will be nati
On Wed, Feb 18, 2015 at 1:17 PM, Dale Harvey wrote:
> systemXHR is the one I bang on about specifically due to offline, I havent
> finished my experiments with serviceWorkers but between seeing every other
> developer get confused due to CORS using pouchdb and my (and others
> https://gauntface.co
systemXHR is the one I bang on about specifically due to offline, I havent
finished my experiments with serviceWorkers but between seeing every other
developer get confused due to CORS using pouchdb and my (and others
https://gauntface.com/blog/2015/02/11/fetch-is-the-new-xhr) initial
confusion wit
On Wed, Feb 18, 2015 at 12:51 PM, Anne van Kesteren wrote:
> Trying to figure out how to get sockets and "systemXHR" into the
> browser has been going on for a very long time now, I think we should
> start embracing that it's unlikely to happen and look elsewhere.
Also, if you look at where our f
On Wed, Feb 18, 2015 at 12:20 PM, Dale Harvey wrote:
> The difference between putting up a static website available to download is
> an entirely different prospect to maintaining a live active service. Github
> has make publishing / updating static sites free and easy along with several
> other se
On 02/18/2015 03:14 AM, Anne van Kesteren wrote:
> Well, unless the application is coupled with the email server and
> there's some WebSocket bridge in place. As long as we keep stuck in
> the "web has to be like native" thinking I don't think we'll advance.
> We need to play to the web's strength
On 18 February 2015 at 11:14, Anne van Kesteren wrote:
> On Tue, Feb 17, 2015 at 8:47 PM, James Burke wrote:
> > Echoing the sentiment about "hard": it adds a lot more complication.
> > A service I now need to monitor as a developer to keep running, when
> > it is not needed if I do a native ap
On Tue, Feb 17, 2015 at 8:47 PM, James Burke wrote:
> Echoing the sentiment about "hard": it adds a lot more complication.
> A service I now need to monitor as a developer to keep running, when
> it is not needed if I do a native app. It can also require a different
> set of developer skills.
Th
Oh, I know. There are lots of huge challenges in terms of making "making a
web app" interesting, possible and affordable to people who are buying $30
phones. We have some hopefully interesting ethnographic research on that
topic:
mzl.la/bangladesh
mzl.la/kenya
(and one coming soon for our India
On Tue, Feb 17, 2015 at 11:12 AM, David Ascher wrote:
> I don't see any data saying that devs aren't making webapps because hosting
> is prohibitive. Is anyone? (I think it's too _hard_ for people who don't
> have the skills, but that's a whole different ball of wax).
Echoing the sentiment about
On Tue, Feb 17, 2015 at 8:12 PM, David Ascher wrote:
> I don't see any data saying that devs aren't making webapps because hosting
> is prohibitive. Is anyone? (I think it's too _hard_ for people who don't
> have the skills, but that's a whole different ball of wax).
Perhaps not prohibitive, alt
On Tue, Feb 17, 2015 at 8:07 PM, Benjamin Francis wrote:
> FWIW I think we should consider doing that anyway. We currently host
> packaged apps and if that makes not wanting to run a web server an argument
> for creating a packaged app rather than a web app then we should at least
> offer hosting
I love the idea of facilitating hosting of "low-end" apps, and I'd be happy
to see if the Webmaker umbrella is a good one to bring to bear, especially
for the real beginners.
But I'd say that with systems like Heroku and EC2 it's hard to argue that
hosting a server is prohibitive for a dev. Websi
On 17 February 2015 at 18:56, Anne van Kesteren wrote:
> Now if we think that hosting an application is too prohibitive we
> should offer something like https://{myapp}.mozillapp.example/
>
FWIW I think we should consider doing that anyway. We currently host
packaged apps and if that makes not w
On Tue, Feb 17, 2015 at 6:46 PM, David Ascher wrote:
> When looking at that security model, a startup hoping to bootstrap something
> like a flipboard clone (or ideally something like flipboard but with some
> innovation), without the option of SystemXHR, will create a server which
> proxies those
On Tue, Feb 17, 2015 at 8:02 AM, Marcos Caceres wrote:
> We don't want people going around taking other people's content without
> permission on scale. That's just wrong
Key point there being "scale". Doing it w/o permission "before-scale" is
how a lot of things get started, and that's just fin
On Mon, Feb 16, 2015 at 6:51 AM, Paul Theriault wrote:
> - deviceStorage:*
I don't think we can have a generic solution for this. It would
probably make sense to explore the use cases.
> - contacts
If we turned contacts into an actual web application, it could expose
APIs for other sites to in
On Tue, Feb 17, 2015 at 5:02 PM, Marcos Caceres wrote:
> On February 18, 2015 at 12:49:39 AM, Dale Harvey (d...@arandomurl.com) wrote:
>> The problem is not browser support for CORS, which has for quite a long
>> time had pretty good support. The issue is that there are applications that
>> in ord
On February 18, 2015 at 12:49:39 AM, Dale Harvey (d...@arandomurl.com) wrote:
> The problem is not browser support for CORS, which has for quite a long
> time had pretty good support. The issue is that there are applications that
> in order to function require access to arbitrary remote services
> Well, the it's going to be very amusing then when we start telling people
to use service workers,
> which rely both on CORS and TLS ^_^. The same with Geolocation, which we
hope to move to
> requiring TLS to access it. I'm sure there was a time before TLS was not
well supported on servers
> when
On February 17, 2015 at 11:01:24 PM, Benjamin Francis (bfran...@mozilla.com)
wrote:
> On 17 February 2015 at 02:27, Marcos Caceres wrote:
> Unfortunately that isn't good enough. We want to be able to build
> Instragram using the web. That won't work if the system provides the only
> camera UI a
On Tuesday, February 17, 2015 at 8:34:44 PM UTC+10, Fabrice Desré wrote:
> I agree with Dale here.
>
> Also, we can't afford to wait for standardization to happen to move
> forward.
Why? what do we win by creating a proprietary ecosystem whose apps don't work
anywhere outside a relatively tiny
On 17 February 2015 at 02:27, Marcos Caceres wrote:
>
> These are great questions. I think we should find some apps that actually
> do this (or want to do this), and talk more seriously about how to enable
> that.
>
Gaia apps are apps that do this, please don't disregard the experience that
has
On Tuesday, February 17, 2015 at 8:18:56 PM UTC+10, Dale Harvey wrote:
> It feels like this would be a more productive conversation if you used
> firefox os (as well as other mobile os's) understood at a deep level the
> feature requirements and where you think you had a better idea suggested
>
I agree with Dale here.
Also, we can't afford to wait for standardization to happen to move
forward. It took *many years* to come up with a solution to the offline
issues with Service Workers. It also took years to standardize the
vibration api, which is pretty simple. I guess we should not have
i
It feels like this would be a more productive conversation if you used
firefox os (as well as other mobile os's) understood at a deep level the
feature requirements and where you think you had a better idea suggested
alternative approaches, possibly individually
https://groups.google.com/forum/#!
On February 17, 2015 at 2:26:49 AM, Benjamin Francis (bfran...@mozilla.com)
wrote:
> On 16 February 2015 at 11:07, Marcos Caceres wrote:
>
> > > - deviceStorage:*
> >
> > Maybe the Quota Management API? I've not evaluated it, but worth having a
> > look:
> > https://dvcs.w3.org/hg/quota/raw-fil
On 17 Feb 2015, at 3:26 am, Benjamin Francis wrote:
> On 16 February 2015 at 11:07, Marcos Caceres wrote:
> > - deviceStorage:*
>
> Maybe the Quota Management API? I've not evaluated it, but worth having a
> look:
> https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html
>
> I don't think t
On 16 February 2015 at 11:07, Marcos Caceres wrote:
> > - deviceStorage:*
>
> Maybe the Quota Management API? I've not evaluated it, but worth having a
> look:
> https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html
>
I don't think this is particularly related. The underlying need of the
Devi
On 16 February 2015 at 05:51, Paul Theriault wrote:
> When you say "(and some proposed web standards)" what are you referring
> to? The subset of privileged/certified APIs that we manage to expose to the
> web? Just making sure I follow you?
>
Yes, technically you could argue that something isn'
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.
On 16 Feb 2015, at 10:07 pm, Marcos Caceres wrote:
>
>
>
> On February 16, 2015 at 3:51:34 PM, Paul Theriault (ptheria...@mozilla.com)
> wrote:
>> On Thu, Feb 12, 2015 at 8:58 PM, Benjamin Francis wrote:
>>> I would suggest we should aim to migrate the vast majority of apps
>>> (including G
On February 16, 2015 at 3:51:34 PM, Paul Theriault (ptheria...@mozilla.com)
wrote:
> On Thu, Feb 12, 2015 at 8:58 PM, Benjamin Francis wrote:
> > I would suggest we should aim to migrate the vast majority of apps
> > (including Gaia apps) to being web apps, but there are likely to be some
> >
On Thu, Feb 12, 2015 at 8:58 PM, Benjamin Francis
wrote:
> Thanks for this Marcos, it makes a lot of sense, and thanks for the offer
> of help.
>
> On 11 February 2015 at 01:13, wrote:
>
>> Thanks for putting these together. I would highly recommend that for any
>> feature people want to add to
On Thursday, February 12, 2015, Benjamin Francis
wrote:
> Thanks for this Marcos, it makes a lot of sense, and thanks for the offer
> of help.
>
No problem. I do hope more people will take us up on the offer.
>
> In support of Paul's proposals around "granting permissions to the web" I
> would
> On 12 Feb 2015, at 09:58, Benjamin Francis wrote:
>
> Thanks for this Marcos, it makes a lot of sense, and thanks for the offer of
> help.
>
> On 11 February 2015 at 01:13, wrote:
> Thanks for putting these together. I would highly recommend that for any
> feature people want to add to the
Thanks for this Marcos, it makes a lot of sense, and thanks for the offer
of help.
On 11 February 2015 at 01:13, wrote:
> Thanks for putting these together. I would highly recommend that for any
> feature people want to add to the Web, people follow the DOM team's
> guidelines for adding new thi
On Monday, February 9, 2015 at 9:41:33 PM UTC+10, Paul Theriault wrote:
> Following up on the previous discussions [1] [2] I've been doing some
> analysis of the current app permission model for FxOS. This email is to start
> discussion around exposing APIs to web content - i.e. hosted apps and r
On 11 Feb 2015, at 1:10 am, Anders Rundgren
wrote:
> On Tuesday, February 10, 2015 at 11:52:55 AM UTC+1, Julien Wajsberg wrote:
>> Hey Paul,
>>
>> Le 09/02/2015 12:41, Paul Theriault a écrit :
>>> === SMS ===
>>> SMS is risky mainly due to the cost involved. Risks include cost of sending
>>>
On 10 Feb 2015, at 9:52 pm, Julien Wajsberg wrote:
> Hey Paul,
>
> Le 09/02/2015 12:41, Paul Theriault a écrit :
>> === SMS ===
>> SMS is risky mainly due to the cost involved. Risks include cost of sending
>> SMS and also SMS are very sensitive - e.g. often used in 2-factor auth (e.g.
>> ba
Hi all,
I'd like to seize the opportunity to put out a radical permission
concept idea that emerges interesting security properties by turning the
permission system inside out.
Traditional permission systems as implemented in FxOS focus on
functionality: A photo book cloud app may access camera A
This is great! Some thoughts on prioritisation and alternative APIs below...
On 9 February 2015 at 11:41, Paul Theriault wrote:
> 1. What APIs (or use cases) are the highest priority to expose to web
> content?
>
Some criteria to consider might be:
1. The developer demand for the API (Numbe
On Tuesday, February 10, 2015 at 11:52:55 AM UTC+1, Julien Wajsberg wrote:
> Hey Paul,
>
> Le 09/02/2015 12:41, Paul Theriault a écrit :
> > === SMS ===
> > SMS is risky mainly due to the cost involved. Risks include cost of sending
> > SMS and also SMS are very sensitive - e.g. often used in 2-
Hey Paul,
Le 09/02/2015 12:41, Paul Theriault a écrit :
> === SMS ===
> SMS is risky mainly due to the cost involved. Risks include cost of sending
> SMS and also SMS are very sensitive - e.g. often used in 2-factor auth (e.g.
> banking)
>
> But there are different use cases. For example, many
On 10 Feb 2015, at 7:44 pm, Wilson Page wrote:
> Regarding access to telephony. We hoped that fxos would get to the point
> where it is so hackable that users could potentially replace the dialer app
> with something third-party. It's a bold move, but it's proof we've succeeded
> in making 't
On Tuesday, February 10, 2015 at 9:51:20 AM UTC+1, Fabrice Desré wrote:
> On 02/10/2015 12:44 AM, Wilson Page wrote:
> > Regarding access to telephony. We hoped that fxos would get to the point
> > where it is so hackable that users could potentially replace the dialer
> > app with something third-
On 02/10/2015 12:44 AM, Wilson Page wrote:
> Regarding access to telephony. We hoped that fxos would get to the point
> where it is so hackable that users could potentially replace the dialer
> app with something third-party. It's a bold move, but it's proof we've
> succeeded in making 'the phone f
Regarding access to telephony. We hoped that fxos would get to the point
where it is so hackable that users could potentially replace the dialer app
with something third-party. It's a bold move, but it's proof we've
succeeded in making 'the phone for makers'.
*W I L S O N P A G E*
Front-end Deve
Hi Paul,
Thanks for aggregating such a huge analysis. I would like to add more
information about the unclassified "presentation-device-manage" permission.
The API that depends on "presentation-device-manage" permission allows to
obtain the list of available devices that can be used as external di
Following up on the previous discussions [1] [2] I’ve been doing some analysis
of the current app permission model for FxOS. This email is to start discussion
around exposing APIs to web content - i.e. hosted apps and regular websites. I
made some notes [3] and a table of all permissions [4] and
53 matches
Mail list logo
