Re: Intent to implement: Web2Native Bridge

[Nicholas Alexander]

Hi Anders,

On Tue, Nov 29, 2016 at 9:10 AM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> There are virtually tons of developers out there using Android Intents to
> start "Apps" from the Web.
>

Aye, and Firefox does support this custom URI scheme.


> However, this mechanism sucks big-time since:
> 1. It leaves the invoking Web page in an "orphaned" state
> 2. There's no way to "talk back" to the invoked Web page
> 3. There's no Web page security context available to invoked "App"
> 4. There's no App/Web life-cycle control
>
> The Web2Native Bridge does all that:
> https://github.com/cyberphone/web2native-bridge#api


I took a look at this and don't yet see how this translates to Android.  It
all seems very Chrome OS specific: "Applications callable by the Web2Native
Bridge emulator *must* be written in Java and stored in a for the purpose
dedicated directory."

Is your intention to define a new specification for how an Android App
advertises this capability and how the browser connects to it?  (Android
Intents, an AIDL and handshake protocol, etc...)  This would be
interesting; it's similar in spirit to the Chrome Custom Tabs work, which
goes in the opposite direction: it makes Apps have better entry into the
browser (where-as you want content in the browser to have better entry into
a companion App).

Unfortunately (or maybe you guys think fortunately) I will most likely
> implement this in Chromium since there is more activity in that channel.
>

I never think it's fortunate when folks passionate enough to implement a
thing don't implement under the Mozilla umbrella!  I can provide some
guidance on doing this in Firefox for Android, if you'd like to try it
under our umbrella.  I can't speak to things like ship criteria and release
schedules, though :(

As a bizarre "Mozilla bonus point", I bet you can do this in a bootstrapped
extension using the essentially undocumented "Java addons" feature!  It's
100% non-obvious how to use it, but you can add a classes.dex to a Firefox
addon and load it using a Java class loader.  See
https://dxr.mozilla.org/mozilla-central/source/mobile/android/javaaddons/java/org/mozilla/javaaddons/JavaAddonInterfaceV1.java
and the test at
https://dxr.mozilla.org/mozilla-central/source/mobile/android/tests/browser/chrome/test_java_addons.html,
which appears to be still running in our automation.  Using this, you could
have your extension inject the `navigator.nativeConnect` method into the
content context (at least I think this is possible, I did it once -- see
https://github.com/ncalexan/bootstrapped-webapi-skeleton -- but I think
this approach may no longer work) and then use a Java addon to handle
proxying out to your test application, either using Intents or binding a
Service or whatever. Wild stuff!

But honestly, you might find it easier to hack up Fennec, since Fennec +
extensions + a new Web API + Java addons probably requires you to be a
Fennec hacker in the first place...

Mozilla have already focused on a similar concept which I doubt will ever
> be supported in Android: https://browserext.github.io/native-messaging/
> In Android Apps does a better job than "in-browser" extensions.
>

Is this the same as
https://mail.mozilla.org/pipermail/firefox-dev/2016-July/004461.html?

In general, I think there are really hard security and permission questions
that need to be raised and answered around this work.  For example, it's a
fundamental tenet of "the Web" that sites are isolated.  How does one
ensure that origin "foo.com" can only access "com.foo.application"?  What
does this even mean on Android, where the first App with an Android package
name is the winner (leading to wild security holes, some of which I have
had to fix in Fennec), regardless of who publishes the App?  These are hard
questions that can't be punted in a shipping product.  (Of course, they can
be punted in an experiment or tech demo!)

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web of Things Working Group

[Tantek Çelik]

To add to this thread, I think there are still fundamental security
issues, which have only gotten worse, that the charter does not
address, nor has the incubation to date come even close to
understanding, much less prototyping / stress-testing.


1. The rapid deployment of WoT/IoT devices poses an existential threat
to the open internet (something we, Mozilla, are particularly focused
on protecting more than other orgs are) due to their fundamentally
worse security.

Since the DDoS attack on krebsonsecurity which motivated our initial
formal objection based on lack of security considerations in the
charter and incubation, there was the subsequent DYN DDoS attack which
took down major sites (Twitter, Github, Reddit, etc.), and that's only
with the current deployment of insecure IoT devices, by rogue groups
using open source malware. Basically it proved the security point of
our formal objection.

WoT/IoT devices are both known to already have worse security, and
expected to in the future, both in initial design / development, and
with the lack of incentive to do security software updates due to such
devices being so low margin, often built by small companies that have
low life expectancy themselves, then whitelabel bundled into larger
devices, with no way of updating the embedded software, e.g. the IoT
cameras used in the DDoS attacks.

The proposed charter (nor anyone's incubation efforts) does/do not
address these low cost, low margin, low life expectancy company,
whitelabel embedding issues. All of which have been shown to be real
problems.

This threat is so bad, that it's not clear that any increased
deployment of WoT/IoT is "good" for the open internet.

That regardless of tech stack, it is in the interest of maintaining an
open internet to do what we can to actually *slow down* the deployment
of of anything WoT/IoT, up to and including opposing standardization
efforts which seek to *accelerate* the deployment of such devices.
This is not an "absolute" situation, where we might as well give up
because it's going to happen anyway like somewhere other than W3C, but
rather a set of race conditions, where slowing things down anywhere at
all may still be incrementally helpful (make the internet as a whole
less vulnerable - it's a spectrum).


2. Increased invasive surveillance.

The above IoT security threat scenarios that we've experienced were
from small groups or individuals using malware they didn't even write.
There is an even worse potential threat from insecure WoT/IoT devices,
and that is state-level actors using those very same existing and
expected security flaws to turn WoT/IoT devices into the largest mass
surveillance and data gathering effort in history.

Every sensor on every such device a user puts in their home becomes a
potential surveillance data gathering node. Note that most the
above-noted insecure devices used in the attacks were IoT *cameras*.

Nothing from the proposed WoT charter, nor experiments/incubations
shows any semblance of any of the participants taking this threat
scenario seriously, nor did any of them raise or document any concerns
like what happened to Krebs.

(The only person in the W3C context who did provide warnings of the
kinds of attacks occuring that eventually did happen was Bruce
Schneier during his talk at the May W3C AC meeting at MIT. But he's
not involved in W3C WoT/IoT efforts himself.).


I don't see any evidence to show that W3C should pursue
standardization of anything WoT/IoT, and quite the opposite, that
we're at a point of WoT/IoT industry immaturity where product
development and deployment is both hurting the internet, and
presenting a potentially even larger threat to users of such products
being transparently, illegally*, invasively surveilled by their
governments hacking the devices in their own homes (*but recently
approved in the UK[1]), and thus should be opposed.


If anything, we (Mozilla) should be reaching out to EFF and any other
W3C Members who value an open internet and respecting users privacy
more than profit (perhaps university members of W3C) and asking them
to join our formal objection to anything WoT/IoT at W3C.


Tantek

[1] http://www.wired.co.uk/article/ip-bill-law-details-passed


On Tue, Nov 29, 2016 at 7:23 AM, Benjamin Francis  wrote:
> Hi David,
>
> Have you had any more correspondence with the W3C on Mozilla's behalf
> regarding this charter?
>
> From the Web of Things Interest Group mailing list
>  it appears that the
> group is happy to remove the dependency on RDF as suggested in our feedback
> (although they claim this wasn't intended as a dependency in the first
> place). Instead I understand they would like to include an extension point
> in the Thing Description such that semantic annotations could be added
> externally to the Thing Description specification if desired. This seems
> reasonable to me.
>
> On the point of the charter being 

Intent to implement: Web2Native Bridge

[Anders Rundgren]

There are virtually tons of developers out there using Android Intents to start 
"Apps" from the Web.

However, this mechanism sucks big-time since:
1. It leaves the invoking Web page in an "orphaned" state
2. There's no way to "talk back" to the invoked Web page
3. There's no Web page security context available to invoked "App"
4. There's no App/Web life-cycle control

The Web2Native Bridge does all that:
https://github.com/cyberphone/web2native-bridge#api

Unfortunately (or maybe you guys think fortunately) I will most likely 
implement this in Chromium since there is more activity in that channel.

Mozilla have already focused on a similar concept which I doubt will ever be 
supported in Android: https://browserext.github.io/native-messaging/
In Android Apps does a better job than "in-browser" extensions.

Anders

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web of Things Working Group

[Benjamin Francis]

Hi David,

Have you had any more correspondence with the W3C on Mozilla's behalf
regarding this charter?

From the Web of Things Interest Group mailing list
 it appears that the
group is happy to remove the dependency on RDF as suggested in our feedback
(although they claim this wasn't intended as a dependency in the first
place). Instead I understand they would like to include an extension point
in the Thing Description such that semantic annotations could be added
externally to the Thing Description specification if desired. This seems
reasonable to me.

On the point of the charter being too broad I don't think much has been
done to address this. The group still seems intent on including a
language-agnostic "scripting API" in the charter, despite Google's feedback
that the Thing Description should be the central focus of the charter and
that the scripting API should be moved to a supporting research themed
status.

I'd like to share a recommendation from the IoT platform team in Connected
Devices that the charter should include only a *Web Thing Description* with
a default JSON encoding and a *Web Thing API* which is a REST API that can
be implemented using HTTP (or HTTP/2 or CoAP). We have started to draft a
potential member submission  to illustrate
this proposal (this is just a skeleton at the moment, contributions welcome
on GitHub ).

With this reduced scope no scripting API should be necessary (most
programming languages already have the capability to call a REST API via
HTTP and anyone can create a helper library to call the WoT REST API). It
should also simplify the security and privacy requirements considerably
given this is a well established and well understood technology stack on
the web.

This kind of RESTful approach is already becoming a de-facto standard in
IoT (e.g. Google Weave, Apple HomeKit, Samsung SmartThings, EVRYTHNG, AWS
IoT, Azure IoT, IoTivity, AllJoyn). What's missing is a standard data model
and common API using this pattern. This is also the direction the Open
Connectivity Foundation  is taking with CoAP
and their OIC specification, and the direction we expect the Mozilla IoT
Framework to take.

We'd very much like to collaborate on this specification via the W3C but
currently the charter still seems too broad and I would argue not in line
with the direction of the wider industry.

Ben



On 17 October 2016 at 19:15, L. David Baron  wrote:

> The comments I submitted on the WoT charter are archived at:
> https://lists.w3.org/Archives/Public/www-archive/2016Oct/0004.html
>
> -David
>
> On Friday 2016-10-14 15:03 +0100, Benjamin Francis wrote:
> > Hi David,
> >
> > We collected some feedback in a document
> >  R5E3OxPduFSiVsmOYGSWw66VVLij9FyA/edit?usp=sharing>
> > and I'm going to try to summarise it here. Please let me know if you feel
> > this feedback is appropriate and feel free to edit it before sending. I
> > also welcome further feedback from this list if it can be provided in
> time.
> >
> >
> >
> > There were some concerns expressed around the clarity of the goals set
> out
> > in the charter and whether there has been sufficient research and
> > incubation in order to proceed with the drafting of specifications via a
> > Working Group.
> >
> > We propose the charter could benefit from a reduced scope, a more
> > lightweight approach and a simplified set of deliverables. This might
> > include a simpler initial data model with a reduced set of metadata and a
> > default encoding without a dependency on RDF (e.g. plain JSON), the
> > specification of a single REST/WebSockets API and a reduced scope around
> > methods for device discovery. We propose that the deliverables could be
> > reduced down to a single specification describing a Web of Things
> > architecture, data model and API and separate notes documenting bindings
> to
> > non-web protocols and a set of test cases.
> >
> > It is suggested that the WoT Current Practices
> >  and WoT
> > Architecture  html>
> > documents referenced in the charter are not currently a good basis on
> which
> > to build a specification and that the member submission
> >  from EVRYTHNG and the Barcelona
> > Supercomputing Center could provide a better starting point.
> >
> > Mozilla welcomes the activity in this area but the charter as currently
> > proposed may need some work.
> >
> >
> >
> >
> > Let me know what you think
> >
> > Ben
> >
> > On 11 October 2016 at 02:52, L. David Baron  wrote:
> >
> > > The W3C is proposing a new charter for:
> > >
> > >   Web of Things Working Group
> > >   https://lists.w3.org/Archives/Public/public-new-work/

Re: Removing the Battery Status API?

[mail]

On Tuesday, November 29, 2016 at 4:17:21 PM UTC+1, Boris Zbarsky wrote:
> On 11/29/16 2:36 AM, JP de Vries wrote:
> > Here's a real world use case:
> > https://github.com/jpdevries/mab-recommendations/blob/low-battery/proposed/low-battery.md#-responding-to-battery-levels
> 
> This is the theoretical use case, yes.  Is anyone actually doing this in 
> practice, though?  The link is to a recommendation document saying that 
> people _should_ do this...
> 
> > I understand the privacy concerns, but why can't these be handled similar 
> > to the Geolocation API? Ask permission to use / user opts in.
> 
> Because prompting users is generally an antipattern.  If, as a user, you 
> got a battery API prompt on every single page (because the trackers on 
> it were trying to use it), what would be your reaction?
> 
> -Boris

> Is anyone actually doing this in 
practice, though?

I'm not sure.

> Because prompting users is generally an antipattern. If, as a user, you 
got a battery API prompt on every single page (because the trackers on 
it were trying to use it), what would be your reaction?

That would be super annoying. I was thinking more of a click Respond to Battery 
Levels button then approve pattern.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing the Battery Status API?

[Boris Zbarsky]

On 11/29/16 2:36 AM, m...@devries.jp wrote:

Here's a real world use case:
https://github.com/jpdevries/mab-recommendations/blob/low-battery/proposed/low-battery.md#-responding-to-battery-levels


This is the theoretical use case, yes.  Is anyone actually doing this in 
practice, though?  The link is to a recommendation document saying that 
people _should_ do this...



I understand the privacy concerns, but why can't these be handled similar to 
the Geolocation API? Ask permission to use / user opts in.


Because prompting users is generally an antipattern.  If, as a user, you 
got a battery API prompt on every single page (because the trackers on 
it were trying to use it), what would be your reaction?


-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform