[whatwg] Device Element

On Mon, Jan 3, 2011 at 11:28 PM, Glenn Maynard <glenn at zewt.org> wrote:
> On Mon, Jan 3, 2011 at 4:45 PM, Diego Perini <diego.perini at gmail.com> wrote:
>> You are correct, Firefox doesn't implement serial access by itself, it
>> just let me use the OS directly (if security configuration
>> restrictions are removed).
>
> Please remember that HTML5 file access does not give you a
> general-purpose serial API, regardless of whether you can access the
> serial device.  Accessing block devices (including regular files) is
> different from accessing character devices (eg. serial devices).

True but in case of character devices which continuously send a string
of max 1Kb (or less) this is not a blocking factor.

I agree that having a full set of API to handle b/c devices would be
everybody dream but we all know we have to work around some
limitations, it has always been so.

> HTML5 file APIs assume files have properties of block devices
> (seekable, with a meaningful size), and don't provide any of the
> critical APIs for character devices: true nonblocking reads
> (FileReader does async reads, which aren't the same thing);
> notification when data is available (again, not the same as

Polling for changes was enough to get the results but some sort of
mutation events would have worked better (depending on device output).

Currently the GPS device I am using only output text but it could as
well generate better data for parsing, like XML or your preferred one.

> FileReader's onprogress event).  And that's ignoring all of the
> important nitty details of serial devices, like port speed and other
> parameters.

Setting the device serial configuration can be done outside the
browser (until a proper specification and API exists). Maybe having
those settings in the "about:config" would allow access more easily to
those not willing to open the terminal.

Adding strong security will not diminish the importance of having
these capabilities in new OS centric browsers.

>
> I suspect you're hitting far more "happens-to-work" with what you're
> doing than you realize.
>

Yeah, maybe. However if you had payed attention to the discussion I am
just testing :)

I repeatedly stated that I am OK with current level of security and I
wish better and more secure methods are found and implemented (if
needed).

I added that I agree with the proposal to find alternatives that will
allow to make easy for browsers to communicate with RS232/USB devices
securely.

>> So next question is why allow Adobe Flash and plug-ins in general to
>> do that wildly and not allow others to have the same capability and be
>> so paranoid about security when that is already broken by other means
>> at higher levels ?
>
> Flash is insecure, so HTML5 should be too?  Seriously?
>

Please read it again I only asked "why" ?

I said Flash is insecure yes, the rest are your words (purposely
misinterpreted)...

HTML5 should be secure but I am not sure allowing it to run side by
side with insecure (and evil) content makes that a reality :-)

The "Device element" proposal and the parts on security that Seth put
forth in previous messages seemed a good start to me, that's all.

Have fun,

--
Diego


> --
> Glenn Maynard
>

Received on Monday, 3 January 2011 18:42:07 UTC